- Kod yazarken bir LLM’e “daha iyi kod yaz” istemini tekrar tekrar vererek gerçekten kodun iyileşip iyileşmediğini deneyen bir örnek.
- Orijinal örnek, ChatGPT'nin DALL-E görsel oluşturma özelliğinde popüler olan “daha ~ gibi yap” memeden ilham alındı.
Basit Tekrarlama Prompt Deneyi
- Claude 3.5 Sonnet'e, basit ama optimize edilebilecek bir problem çözmesi için Python kodlama prompt'u verildi.
- Temel uygulama
- 1 ile 100.000 arasında rastgele bir milyon tamsayı içinde, basamak toplamı 30 olan sayıların minimum ve maksimum farkını bulma problemi
- Basit uygulamada 657 ms sürdü (Python'da
str dönüştürme yöntemi kullanıldı)
- Iteration #1
- Claude'ya “daha iyi kod yaz” dediğinde kodun geliştirilmesi istendi.
- Claude kodu Python sınıfı biçiminde yeniden yapılandırdı, nesne yönelimli hale getirdi ve tüm sayılar için basamak toplamını önceden hesapladı.
- 2.7 kat daha hızlı
- Iteration #2
- Claude, çoklu iş parçacığı ve vektörleştirilmiş numpy işlemlerini kullanarak kodu daha da optimize etti.
- 5.1 kat daha hızlı
- Iteration #3
- Kod aksine karmaşıklaştı ve string dönüşüm yöntemine geriledi.
- 4.1 kat daha hızlı
- Iteration #4
- Claude,
numba Python kütüphanesini kullanarak JIT derleyicisini çağırdı ve Python'un asyncio'yu kullanarak paralelleştirme uyguladı.
- Hız artışı 100 kata kadar çıktı.
- “Kod kozmik olarak değişir” yerine, aşırı optimize edilmiş “kurumsal düzeyde” bir kod ortaya çıktı.
Prompt mühendisliği uygulanması
- LLM çıktısını optimize etmek için prompt mühendisliğine ihtiyaç var.
- Claude 3.5 Sonnet güçlü bir prompt uyum yeteneğine sahip olduğundan, net talimatlar verilirse daha iyi sonuçlar alınabilir.
- Sadece “daha iyi kod yaz” yerine, ayrıntılı yönergeler içeren bir sistem promptu kullanıldı.
- Başlangıç promptu
- “Optimize edilmiş kod” tanımı ayrıntılı şekilde belirtildi (algoritma, paralelleştirme, gereksiz kodu en aza indirme vb.)
- İlk uygulamada
numba ile basamak toplamı optimizasyonu → 59 kat hızlandı
- Iteration #1
- Claude, paralelleştirme ekledi ancak yanlış bir bit kaydırma operasyonu (hexadecimal için) ekleyerek hata üretti.
- Performans 9.1 katına düştü (daha kötüydü).
- Iteration #2
- Claude, SIMD operasyonları kullanarak performansı iyileştirmeye çalıştı, ancak hala yanlış bir bit kaydırma operatörü kullanıyordu.
- İlk uygulamaya göre 65 kat daha hızlı çalıştı.
- Iteration #3
- Claude hash tablosu kullanarak performansı optimize etti.
- İlk uygulamaya göre 100 kat daha hızlı çalıştı.
- Iteration #3
- Claude yanlış bit kaydırma operasyonunu düzelterek performansı biraz düşürdü.
- İlk uygulamaya göre 95 kat daha hızlı çalıştı.
Sonuç
- Yalnızca “daha iyi kod” gibi belirsiz bir promptla bile kademeli gelişim mümkündür.
- Prompt mühendisliğiyle istediğiniz yönü (sayısal işlem, JIT, paralelleştirme vb.) net biçimde tanımlarsanız daha hızlı gelişmiş kod elde edersiniz.
- Otomatik optimizasyon fikirleri yeni araçları (numba vb.) keşfetme fırsatı verse de, yine de mühendisin hata doğrulaması yapıp seçici şekilde kullanması gerekir.
- Gerçek iş sistemlerinde LLM'nin önerdiği her kodu doğrudan uygulamak alan-bazlı kısıtlar ve doğrulama ihtiyacı nedeniyle risklidir.
- Bu deney Python kodu odaklı olsa da, Rust gibi diğer dillerle entegrasyon yöntemlerinde (PyO3 vb.) de LLM optimizasyon fikirlerinin uygulanma potansiyeli büyük.
1 yorum
Hacker News Yorumları
Kod optimizasyonunda, sayının minimumdan küçük veya maksimumdan büyük olup olmadığını önce test etmek etkili oluyor. Bu kontrol dijital toplam hesaplamasından önce yapılırsa hızı 5.5 kat artırabiliyor. Numba kullanmadan da NumPy ile bu iş yapılabiliyor
GPT gibi LLM'ler başlangıçta çoğu zaman orta düzey sonuçlar sunuyor. Belirli bir prompt ile daha iyi sonuçlar alınabileceği iddia ediliyor
LLM, bağlama göre çalışan bir simülasyon motoru gibi; metin tahminiyle gerçek dünya modelini simüle ediyor. Doğru metin tahmini için gerçek dünyanın doğru bir modeline ihtiyaç var
LLM'ler kodu acemi düzeyinde yazma eğiliminde oluyor ve paketleri belirterek basit bir kod istemek daha etkili oluyor
Android/Kotlin tarafında ChatGPT verimli değil; sıklıkla geçersiz veya kullanım dışı yöntemleri çağırıyor
Kodlama oturumuna "kod yazma" ile değil, "açık uçlu planlama" ile başlamak önemli. LLM'nin varsayımlarını netleştirip kod yazmadan önce planı güncellemek gerekiyor
PostgreSQL'i Debian'dan tamamen kaldırıp tekrar kurmanın bir yolu anlatılıyor. Veri dizinini koruyarak mevcut veritabanını koruyabilirsiniz
Kod optimizasyonu erken yapılırsa iyi olmayabilir; yalnızca gerektiğinde optimize etmek daha iyi
"Daha iyi kod yaz" isteğini tekrarlamak performansı düşürebilir. Çözümü çalışmaz hale bile getirebilir
LiveCode'da hesaplama Python'dan daha hızlı; toplamı döngüyle hesaplama yolunu açıklıyor