Daha fazla kod mu, daha fazla bilgi mi?
Bir programın kaynak kodu yok, ama çalıştırılabilir dosyası ve kullanım belgeleri var. Aynı davranışı yeniden üretmekle görevlendirilen geliştirici için ilk sorun kaç satır kod yazacağı değil, hangi davranışları henüz bilmediği. Cohere’nin yeni çok eylemcili kodlama deneyinde ProgramBench bu durumu oluşturuyor. Yardımcılar yalnızca kod üretmek için eklenmiyor; özgün programa farklı sorular yöneltip yanıtları yöneticiye taşıyor. Bu kurulumda planlama desteğinin katkısını, daha fazla kod yazan el ile daha fazla davranış bilgisi sağlayan göz arasında ayırmak gerekiyor.[1]
ProgramBench’in yöntem ön baskısı, yeniden yazılan programı gizli davranış testleriyle sınamayı tarif ediyor. Mimari veya programlama dili özgün yazılımla aynı olmak zorunda değil. Cohere, bu 200 görevde geçen testlerin payını ortalıyor; tamamen çözülen programların payını kullanmıyor. Ayrım, sonuç yorumunun merkezinde. Bir test puanı artışı, bazı davranışların daha iyi yeniden üretildiğini gösterebilir; bir uygulamanın bütün işlevlerinin hazır olduğu anlamına gelmez. Sonlu test kümesi, özgün programın bütün olası girdilerini kapsayan eksiksiz bir tarif de sağlayamaz.[1]
Cohere, planlama, uygulama ve doğrulama desteğini ayrı ayrı karşılaştırdığında ProgramBench’te planlamanın belirgin katkısını bildirdi. Çoğu ana düzen aynı görevlerde üç kez çalıştırılmış; tek eylemciyle karşılaştırmalar görevler eşleştirilerek yapılmış. Benim için en açıklayıcı gözlem puandan önce iş akışında: planlayıcılar çoğaldığında özgün programın daha çok davranışı deneniyor ve yöneticiye daha geniş raporlar ulaşıyor. Daha çok uygulayıcı ise daha küçük kod parçalarını üstleniyor; birleşen programın referansla kontrolü aynı ölçüde artmıyor. Bu, bilgi toplama açıklamasını destekliyor, ancak görev dağıtma talimatlarının başka düzenlerde aynı sonucu vereceğini kanıtlamıyor.[1]
Tarif hazır olduğunda değişen görev
İkinci sınama, açıklamayı başka bir görev yapısıyla karşılaştırıyor. Commit0-Lite’ta 16 Python kütüphanesinin kod iskeleti, belgeleri ve birim testleri baştan veriliyor. Cohere burada en çok katkının uygulama desteğinden geldiğini bildiriyor. Görev yine yazılım üretmek, fakat neyin üretileceği daha açık. Aynı araştırma içinde yardımın değerli olduğu aşamanın değişmesi, planlama eylemcisini evrensel üstün çözüm saymayı zorlaştırıyor. Tek eylemci zaten görevlerin 12’sinde bütün testleri geçiyor; bu küçük ikinci örneklemde ekibin iyileştirebileceği alan da sınırlı.[1]
İki sınama arasındaki fark tek başına nedenselliği kesinleştirmiyor. Program aileleri ve zorlukları da değişiyor; yalnızca aynı görevdeki bilgi miktarı değiştirilmiş değil. Bu, planlamanın kazancının bilgi eksikliğinden kaynaklandığı görüşüne karşı gerçek bir alternatif. Sabit yardımcı sayısıyla yapılan bazı düzenlerin yalnızca bir kez çalıştırılması da küçük puan farklarını büyütmemeyi gerektiriyor. Yine de kaynak programı deneme davranışıyla ikinci sınamanın yönü birbirini tamamlıyor. Çalışmadan çıkarılabilen daha dar sonuç, yardımın değerinin görevin koşullarıyla birlikte ölçülmesi gerektiği.[1]
Bu deney, geliştirme ekibine daha kullanışlı bir başlangıç sorusu bırakıyor: iş, davranışı keşfetmekte mi, bilinen davranışı koda dökmekte mi, yoksa çıkan parçaları birlikte doğrulamakta mı takılıyor? Cohere’nin düzeninde yönetici, yardımcı raporlarını birleştiren karar noktası olarak kalıyor. Ben bu sonucu, ekip büyüklüğünden önce darboğazın adını koymak için değerli buluyorum. Aynı görevlerin açık bir tarifle ve yalnızca çalıştırılabilir dosyayla karşılaştırılması, bilgi toplama açıklamasını daha doğrudan sınayabilir. Böyle bir karşılaştırma, planlamaya ayrılan emeğin nerede işe yaradığını daha temiz ayırır.[1]