GitHub’a göre yapay zekâ ile kodlamada verimlilik token sayısından ibaret değil

Yapay zekâ ile kodlama verimliliği neden yalnızca token hesabı değildir?

GitHub’ın GitHub Copilot üzerine yayımladığı açıklama, yapay zekâ ile kodlama verimliliği tartışmasında sık kullanılan token sayısına farklı bir çerçeve öneriyor. Şirkete göre bir kodlama ajanının tek tek araç çağrılarında daha az token kullanması, görevin toplamda daha hızlı ya da daha düşük maliyetle tamamlandığı anlamına gelmiyor.

Buradaki temel ayrım, yerel bir ölçüm ile görevin tamamına ait ölçüm arasındaki fark. Bir komutun çıktısını kısaltmak ilk bakışta tasarruf gibi görünebilir. Ancak çıkarılan ayrıntı ajan için gerekliyse, model aynı bilgiyi yeniden aramak, komutu yeniden çalıştırmak veya önceki çıktıya tekrar erişmek zorunda kalabilir. Bu da ek adımların yanı sıra daha fazla bağlamın sonraki aşamalara taşınmasına yol açabilir.

GitHub’ın ortaya koyduğu yaklaşımda amaç, mümkün olan en az tokenı kullanmak değil; işi ilerletmek için yeterli ve doğru bağlamı sağlamak. Dolayısıyla değerlendirme, kullanıcının talebinden başlayıp elde edilen nihai sonuca kadar uzanan bütün görev üzerinden yapılmalı.

Kısa çıktı bazen neden daha pahalıya gelebilir?

GitHub, bu durumu RTK adı verilen ve kabuk çıktısını bir ajan okumadan önce kısaltan bir araçla yaptığı değerlendirmeyle açıklıyor. Şirketin kendi ajan tabanlı kodlama kıyaslamaları ve yapılandırmasında RTK bazı yanıtları kısalttı. Ancak atılan metin önemli olduğunda model, ihtiyaç duyduğu bilgiyi almak için özgün çıktıyı yeniden açtı ya da komutu tekrar çalıştırdı.

GitHub’a göre bu telafi adımları, tur sayısını artırdı ve daha fazla bağlamın görev boyunca taşınmasına neden oldu. Sonuçta tekil araç yanıtı kısalsa da görevin ortalama token kullanımı yükseldi ve görev daha uzun sürdü. Şirket bunu, yerelde token tasarrufu sağlanırken genel süreçte daha fazla harcama yapılması olarak tanımlıyor.

Bu bulgu, GitHub’ın özellikle kendi entegrasyonu ve test ettiği iş yükleri için geçerli. Şirket, sonucun RTK’nin her yapılandırmasına veya genel olarak tüm çıktı sıkıştırma yöntemlerine uygulanamayacağını da açıkça belirtiyor. Buna rağmen örnek, kısa yanıtın otomatik olarak daha verimli bir çalışma anlamına gelmediğini gösteriyor.

GitHub Copilot hangi tür çıktıları sıkıştırmayı hedefliyor?

GitHub’ın kıyaslama çalışmaları, kurulum, derleme, test ve lint çıktılarında sıkça tekrarlanan gürültü bulunduğunu gösterdi. Buna karşılık kaynak kod benzeri çıktılar ile rastgele komut sonuçlarının, bir ajanın görevi bitirmesi için gerekli bilgileri içerme olasılığının daha yüksek olduğu belirtildi.

Bu gözlem, seçici bir çıktı sıkıştırıcısının geliştirilmesine yön verdi. Mantık, her çıktıyı aynı ölçüde kısaltmak yerine, tekrarlayan ve göreve değer katmayan bölümleri azaltırken gerekli bağlamı korumak. GitHub’ın ifadesiyle hedef, modelin daha önce yaptığı işi yeniden yapmasına neden olmadan tekrarlayan çıktıyı azaltmak.

Şirket, prototipi ajan tabanlı kodlama kıyaslamalarında ve açık kaynak depolardan oluşan bir aralıkta değerlendirdiğini aktarıyor. Bu süreçte depoların derleme, test ve lint sistemleri kullanıldı. Verilen metinde, bu testlerin sonraki ayrıntıları yer almıyor; ancak seçici yaklaşımın, bütün komut sonuçlarını körlemesine kısaltmaktan ayrıldığı açık.

Dört değişiklik aynı ilkeye dayanıyor

GitHub, Copilot’ta bu ilkeyi uygulamak için dört değişikliği incelediğini söylüyor. Bunlar, yararlı bağlamı korurken tekrarlayan çıktıyı azaltmak; göreve değer katmayan biçimlendirmeyi kaldırmak; yararlı davranışı değiştirmeden talimatları kısaltmak ve tamamlanmış arka plan çalışmasını ek bir geri getirme adımı olmadan sunmak olarak sıralanıyor.

Bu maddelerin ortak noktası, tekil bir işlemde görünen tasarruftan çok gereksiz tekrarları azaltmaya odaklanmaları. Örneğin eksik bir araç yanıtı, modelin daha sonra aynı bilgiyi edinmek üzere yeni araç çağrıları yapmasına yol açabiliyor. Bu nedenle bağlamın ne kadarının korunacağı, maliyet kadar görev akışını da etkileyen bir karar haline geliyor.

GitHub, olası değişiklikleri önce çevrimdışı olarak ajan tabanlı kodlama kıyaslamalarında değerlendirdiğini, en umut verici olanları ise kullanıma sunmadan önce kontrollü çevrimiçi deneylerle doğruladığını belirtiyor. Şirketin paylaştığı grafikte dört ayrı A/B deneyi aynı yapay zekâ kredisi metriğiyle karşılaştırılıyor; ancak etkilerin zorunlu olarak doğrudan toplanamayacağı notu da düşülüyor.

Bu yaklaşım geliştiriciler için ne ifade ediyor?

GitHub’ın açıklaması, üretken yapay zekâ araçlarının kullanımını değerlendirirken yalnızca ekranda görülen yanıtın uzunluğuna bakmanın eksik kalabileceğine işaret ediyor. Bir ajanın ihtiyacı olan detay erken aşamada korunursa, aynı detay için tekrar komut çalıştırma veya çıktı yeniden okuma ihtiyacı azalabilir. Buna karşılık gereksiz tekrarlar ve işe yaramayan biçimlendirme, görev boyunca taşınan bağlamı büyütebilir.

Şirketin örnekleri GitHub Copilot CLI’dan geliyor. Ancak GitHub, GitHub Copilot uygulaması ve Copilot kod incelemesi gibi başka Copilot ürünlerinin de aynı temel altyapıyı kullandığını ve bu iyileştirmelerden verimlilik açısından yararlandığını ifade ediyor.

Bu anlatının ana sonucu bir ürün özelliğinden çok bir ölçüm yöntemi: Yapay zekâ destekli kodlama işinde verimlilik, tek bir araç çağrısının ne kadar kısa olduğu ile değil, görevin kaç tekrar gerektirdiği, gerekli bağlamın korunup korunmadığı ve sonucun ne kadar doğrudan elde edildiği ile birlikte ele alınmalı.