Meta'nın yeni LLM tabanlı test üreticisi
(read.engineerscodex.com)Meta'nın yeni LLM tabanlı test üreticisi, geliştirmenin geleceğine göz atma fırsatı sunuyor
- Meta, "Automated Unit Test Improvement using Large Language Models at Meta" başlıklı bir makale yayımladı.
- Bu makale, yapay zekanın geliştirme hızını artırmak ve yazılımdaki hataları azaltmak için nasıl kullanılabileceğini gösteriyor.
- LLM'leri geliştirici iş akışına entegre ederken, mevcut kod kapsamını iyileştiren doğru ve eksiksiz yazılım iyileştirme önerileri sunuyor.
Ana noktalar
- TestGen-LLM, 'Assured LLM-based Software Engineering' (Assured LLMSE) yaklaşımını kullanıyor.
- Birden fazla LLM, prompt ve hiperparametre kullanarak kod iyileştirme önerileri üretiyor ve en iyi öneriyi seçen bir ansambl yaklaşımı benimsiyor.
- TestGen-LLM, özellikle mevcut insan yazımı testleri iyileştirmek için tasarlandı.
İstatistikler
- Instagram'ın Reels ve Stories ürün değerlendirmelerinde, TestGen-LLM'in ürettiği test vakalarının %75'i sorunsuz derlendi, %57'si güvenilir şekilde geçti ve %25'i kapsamı artırdı.
- TestGen-LLM, uygulandığı tüm sınıfların %10'unda iyileştirme sağlayabildi ve geliştiriciler test iyileştirme önerilerinin %73'ünü kabul ederek prodüksiyona aldı.
- Meta mühendislerinin Instagram'ın test kapsamını artırmak için test ürettiği bir "test-a-thon" sırasında, TestGen-LLM testlerinin eklediği kod satırı sayısının medyanı 2,5 oldu.
Uygulanabilir içgörüler
- Bu, LLM'lerle geliştirici üretkenliğini ve yazılım güvenilirliğini verimli biçimde artırmanın iyi bir örneği.
- LLM'lerin gerçek değeri, beklenmedik edge case'leri bulup yakalamakta yatıyor.
- LLM'leri prodüksiyonda kullanmak için orkestrasyon, pipeline ve işleme gerekiyor.
TestGen-LLM nasıl çalışıyor
- TestGen-LLM, Meta'nın dahili LLM'i tarafından üretilen aday çözümlere bir dizi anlamsal filtre uygulayarak yalnızca en değerli testleri koruyor.
- Filtre 1: derlenebilirlik, Filtre 2: çalıştırma (testin geçip geçmediği), Filtre 3: kararsızlık, Filtre 4: kapsam iyileştirmesi.
- Bu işleme filtreleri, test paketinin iyileştirilmesini garanti ediyor.
Sonuç
- Bu makale, birçok geliştiricinin zaten LLM kullandığı yazılım güvenilirliği alanında LLM ilerlemesini takip etmek için iyi bir yöntem.
- LLM'ler giderek daha karmaşık yazılım sistemlerinde hata bulup test edebilecek.
GN⁺ görüşü
- Bu yazı, yapay zekanın yazılım geliştirmenin geleceğini nasıl etkileyebileceğine dair ilgi çekici içgörüler sunuyor.
- TestGen-LLM gibi araçlar, geliştiricilerin işini otomatikleştirmede ve verimliliği artırmada büyük yardımcı olabilir.
- Bu tür teknolojik gelişmeler, yazılım geliştirmenin karmaşıklığını azaltma, kaliteyi artırma ve geliştiricilerin zamanından tasarruf etme yönünde ilerliyor.
1 yorum
Hacker News yorumları
LLM’leri uygulama kodu yazmadan önce test kodu yazmak için kullanma eğilimi ilginç
Belki fazla TDD yaptığım içindir; bence testler, sistemin nasıl davranması gerektiğini açıklayan şeylerdir ve bu kısmı insanlar tanımlamalı. Kod, testlerin oluşturduğu korkulukların içine oturmalı
Yine de LLM, spesifikasyonun eksik kaldığı alanları işaret etmekte yardımcı olabilir. Burada olan şey, daha az tanımlanmış kısımlar için birim testleri önermesini sağlamak da olabilir
LLM’lerden önce de, testlerin hepsi yazılmışsa bir maymun daktiloyla uygulama geliştirebilir mi diye ara sıra düşünürdüm
Bunlar, insanların kodun nasıl davranması gerektiğine inandığını değil, mevcut kod tabanının gerçekte nasıl davrandığını tanımlayan testlerdir
Bu sayede regresyonları en aza indirerek yeniden yazma, refactoring ve yeniden tasarım yapılabilir. Birçok legacy kodun sorunu, amaçlanan davranışı kimsenin anlamamasıdır; hatta bazen kullanıcılar bile sistemin, gerçek davranışından farklı şekilde çalışması gerektiğine inanır
Bu yüzden açıkça istenen bir değişiklik değilse en önemli şey davranışı değiştirmemektir
Temel fikir, kod davranışına dair zayıf önermeleri, tam ve kapalı biçimli bir ispat sistemi yerine “özellikler” olarak ifade etmek ve bunları doğası gereği olasılıksal sınırlar içinde doğrulamaktır
Klasik örnek string ters çevirmedir. Bir string’i iki kez ters çevirirseniz genellikle girdiyi geri almalısınız. Tek satır kodla, zaman ve elektrik elverdiği ölçüde tuhaf Unicode uç durumlarını da kontrol edebilirsiniz
Örnek önemsiz görünebilir ama PyTorch’a dönüşen otomatik türevleme ve kernel işleri üzerinde çalışan CUDA ustalarının bu yöntemi inanılmaz iyi kullandığını, yarı çaba ve maliyetle yaklaşık 5 kat kod güvenilirliği elde ettiğini gördüm
Her zaman iyi uymaz ama uyduğunda harikadır; LLM’ler de sıfırdan başlamaktan ziyade Hypothesis örneklerine epey yaklaşabiliyor gibi görünüyor
Buna karşılık test yazarken, uygulamanın ne yapması gerektiğini aşırı uzun ve çok kısıtlayıcı bir dille açıklamak, birkaç süslenmiş if/else koymak için onlarca ya da yüzlerce satır kurulum kodu yazmak gerekir
C++ veya Java gibi dillerde birim testleri sıkıcılıktan ibaret olduğundan, bu işi LLM’e devretme içgüdüsünün ortaya çıkması hiç şaşırtıcı değil
Günlerce kod yazdıktan sonra, sistemin çalıştığını “kanıtlayan” birkaç testi mecburen sonradan yazan çok mühendis gördüm. Kapsama oranı düşüktür ve genelde kırılgandır
Böyle düşünüp çalışan bir mühendis için bu tür bir sistem gökten inmiş bir nimet gibi görünür
Testleri önce yazmayı yavaşlatıyor diye yasaklayan bir yöneticim de olmuştu. Neyse ki dış görevde olduğum için “bunu yöneticimle konuşun” diyerek görmezden gelebildim; muhtemelen yukarıdaki mühendislerle aynı şekilde düşünüyordu
Başka bir açıdan bakarsak çoğu geliştirici dokümantasyondan hoşlanmaz. Koddan harika dokümantasyon yazan bir yapay zeka varsa bunu seveceklerdir. Ve bu geliştiriciler için yazmak zorunda olmadıkları dokümantasyon, harika dokümantasyondur
Test kodu çoğu zaman düşük öncelikli kod olarak görülüp daha junior mühendislere bırakılıyor; bu, istenen yönün tam tersi gibi görünüyor
Tamamını incelemek istemiyorum ama bir nokta özellikle fena şekilde ıskalanmış görünüyor
Orijinal makaleyi yayınlanır yayınlanmaz kabaca okumuştum, şimdi de göz gezdiriyorum; bu yüzden hafızamın bulanık olduğu varsayımıyla konuşuyorum
Blog, Meta’nın TestGen-LLM testlerinin çoğunun yalnızca ek 2,5 satır kapsadığını, ancak bir testin 1326 satırı kapsadığını ve o tek testin değerinin “üstel olarak daha büyük” olduğunu; LLM’in aktif biçimde kalıpların dışında düşünerek beklenmedik uç durumları yakalamasının büyük değer taşıdığını yazmış
Ama “üstel olarak daha değerli” ifadesi başlı başına saçmalık alarmını çaldırmalı. Makaleye bakınca yazarlar bu 1326 satırlık kapsama oranını jackpot vuran tekil bir test olarak açıklıyor ve tek bir TestGen-LLM testinden beklenebilecek gerçekçi ek satır kapsamının medyanının 2,5 satır olduğunu söylüyor
Yazarlar “beklenmedik uç durumlar” ya da “kalıpların dışında düşünme”den söz etmiyor. Aksine bunu, berbat bir switch ifadesinin bir dalına dokunmuş olabilecek ya da kod kapsamı hesaplama yönteminin tesadüfü olabilecek istisnai bir örnek olarak sunuyorlar
“Nitel sonuçlar” bölümünde de bunun daha fazla kurcalanmamış olması dikkat çekici. Hatalı yorum kimseye fayda sağlamaz. İnternette okumuş gibi yaptığı şeyi anlamış gibi yapan insan zaten fazlasıyla var
Bazı yorumların benim görüşüm olduğu daha net anlaşılsın diye yazıyı düzelttim
Bu yazı, makalenin özetinden çok makale sonuçlarının ne anlama geldiğine dair bir yorum niteliğinde. Sonuçta Hacker News tartışma için var
Yine de “üstel olarak daha değerli” kısmının hâlâ doğru olduğunu düşünüyorum. LLM’in test kapsamı açısından tesadüfen “jackpot” vurabilmesi, değerin tam da özü
Sürekli çeşitli kombinasyonları denerken makaledeki gibi tek bir jackpot bile tuttursa, bu ekip için çok değerli olur. İnsanın elle yazması için bariz olmayan ya da fazla sıkıcı olan bir test olabilir
Big Tech kod tabanlarında (F/G) neyin test edilmesi gerektiğini zaten bilip yalnızca “nasıl test edileceğini” bulmak için fazlasıyla zaman harcamış biri olarak bunun değerli olduğunu düşünüyorum
Bu ekibin de kod satırı sayısı ve diff sayısı odaklı itildiği açık. Sonuçta bu, debug etmesi zor bir kod dağı daha yaratan bir kod üretme aracı olmaktan öteye gitmeyecek
İyi test yazmak zordur ve kapsam koşulsuz olarak iyi bir şey değildir
Çok fazla test yazarak programı katılaştırmak ve fiilen bir değişiklik algılama programı yapmak kolaydır. “Bir şeyi değiştirmişsiniz, tüm testler bozuldu. Sorun değil, artık LLM’e yeniden ürettiririz! %100 kapsam! Şaşırtıcı! İlerleme!” gibi bir hale gelir
Bana göre bu, değişikliğin amaçlanan bir değişiklik olup olmadığını doğrulamak için bir fırsat. Bu yoksa programın yapması gereken şeyi yaptığını nasıl bilirsiniz?
Bunun dışında, beş başka kişinin iyi test diye düşündüğü şeyleri okumak gerekir. Hepimiz test yazmada kötüyüz; sadece herkes kendi yöntemiyle yapıyor
Sonrasında her değişiklikte geliştirici doğal olarak yeniden üret düğmesine basıp her şeyi commit ediyordu. Diff boldu ama sinyal şüpheliydi
Yarı iletken sektöründe, özellikle hesaplamalı litografide test odaklı tasarımın standart olduğu yerlerde çalıştıktan sonra buna pek ikna olamıyorum
Bu, production kodundan önce her zaman test yazmak gerektiği anlamına gelmiyor. Ama testler de kod tabanının diğer parçaları kadar kodun bir parçasıdır ve mutlaka test edilen kodla birlikte yazılmalıdır
Testlerin en önemli kısmı geliştiricinin niyetini göstermesidir. Test suite’i kodun nasıl kullanılması gerektiğini, ne yaptığını, ne yapmadığını ve ne için yazıldığını gösterir
Böylece başka bir geliştirici o kodu kullanırken ya da değiştirirken kod tabanında Sherlock Holmes gibi ipucu aramak zorunda kalmaz
Testler bir hikâye anlatmıyorsa testleri yanlış yazıyorsunuz demektir
Bilgisayarlar zihin okuyup niyeti daha iyi anlayabilir hale gelene kadar AI/LLM tabanlı üreticiler bu işi üstlenemez
Elbette test suite’inin tek hedefi commit öncesi kontrolde yeşil onay işareti almak ve havalı kapsam sayıları göstermekse, AI ile üretkenliğinizi ikiye katlayabilirsiniz
Otomatik kod üreticiler, kötü kodu ışık hızında daha çok yazmanıza yardım edecektir. Boilerplate çok olduğu için kodun şişkin ve anlaşılması zor olduğundan biri şikâyet ederse, AI ile halletmesini söylersiniz. Sizde işe yaradı sonuçta
Geliştirmenin geleceği gerçekten böyle görünüyor, ama benim umut ettiğim gelecek bu değil
Anlattığınız şey kodun “özünü” test etmeye benziyor. Belgeleme, doğrulama ve kararlılığın bir kısmını da üstlenen testler
Fuzzing gibi başka testler tamamen farklı bir değer sunar. AI tabanlı testlerin, dağılımın kuyruk tarafını; insan enerjisi ve zamanı yetmediği için ihmal edilen, değeri düşük çok sayıdaki testi hedefleyen bir alanı doldurabileceğini düşünüyorum
Mevcut AI araçlarının durumunu da böyle görüyorum. Bunlar bilişsel yardımcı araçlar
Bu araştırma yönü önümüzdeki birkaç yıl içinde epey sonuç vermezse asıl o zaman şaşırırım
Makalenin kendisi yayımlandığında yazdıklarımı biraz düzenleyip yeniden alıntılıyorum. Yazıları istatistikleri yanlış sunuyor
https://news.ycombinator.com/item?id=39406726
Özet, gerçek makale içeriğiyle uyuşmuyor. Özet, test case bazlı oranlar gibi “%75’i doğru şekilde build edildi, %57’si kararlı şekilde geçti, %25’i kapsamı artırdı” diye okunacak şekilde yazılmış
Asıl rapor ise test class’ı bazında konuşuyor; her class’ta bir veya daha fazla test case var
Anlamı şu: “Test class’larının %75’inde doğru şekilde build edilen en az bir yeni test case vardı”, “test class’larının %57’sinde doğru şekilde build edilen ve kararlı şekilde geçen en az bir test case vardı”, “test class’larının %25’inde aynı build target’taki diğer test class’larına kıyasla build edilen, geçen ve satır kapsamını artıran en az bir test case vardı”
Bunlar tamamen farklı cümleler. Her test class’ını genişletme denemesinde birden fazla test case üretme girişimi olabildiği için, test case başına başarı oranının genelde test class’ı başına başarı oranından çok daha düşük olduğuna dair bir dipnot bile var
Buna rağmen sonuç bölümünde, özette olduğu gibi sonuçları yine yanlış sunuyorlar. Deney modunda TestGen-LLM kullanıldığında test case başına başarı oranının %25 olduğunu, satır kapsamı şartı gevşetilip yalnızca build ve geçme şartı arandığında başarı oranının %57’ye çıktığını yazıyorlar
İleride bu berbat LLM legacy kodunu bakımını üstlenecek insanlarla empati kuruyorum
Çirkin olacak
Hatta oldukça benzer görünebilir; yorumlar ve dokümantasyon daha dolu olabilir, aktif biçimde yanlış olma ihtimali de daha düşük olabilir
LLM’ler asla bugünkünden daha iyi olmayacak ve son 2 yılda hiç ilerleme kaydetmediler. Sadece süslü Markov zincirleri
Kod yazmayı bilmeyen birinin, hiçbir inceleme yapmadan kodu körlemesine production’a commit ettiği durumlarda kod yazmak için kullanılabilirler ancak
Kod yazmayı bilen biri için işe yarama ihtimalleri yok ve üretkenliği de artıramazlar
Dünyayı hiç değiştirmeyen bu LLM saçmalığını görmezden geleceğim; sizin de kesinlikle öyle yapmanız gerekir
İyi ayrıştırılmazsa, bilgisiz bir yöneticinin yüksek coverage talep etmesi ve hevesli junior’ların gizlice büyük miktarda AI testi eklemesiyle kolayca geliştiriciye düşman bir ortama dönüşür
Sonunda her iş tesliminde, bakımı zor LLM tarafından üretilmiş test kodundan onay almak zorunda kalınan bir duruma gelinir
Bazı testleri yazmak hızlanabilir, ama bakımın hızlanacağının garantisi yoktur. Test edilen kodun bakımı için de aynı şey geçerlidir. Çünkü iyi testlerin üretileceğinin garantisi yoktur
Test yazarken çekilen zahmet, genelde geliştiricinin tasarımı erken aşamada gözden geçirmesine de yardımcı olur. Test etmesi zorsa çoğu zaman iyi bir tasarım değildir; örneğin başkalarıyla birlikte kod yazılması gereken bağlamlarda, bileşen sözleşmesi çoğunlukla yeterince soyutlanmamıştır
Gözden kaçması kolay nokta, testlerin feda edilebilir kod olduğudur. Çoğu, ömrü boyunca hiçbir şey yakalamayacaktır ve bu sorun değildir. Çünkü otomatik bir güvence sağlar ve hata olduğunda yanlış ipuçlarını azaltır
Ancak olasılıksal güvenlik önlemlerine azami yatırım yapmak her zaman karşılık vermez. Coverage tepeye yaklaştıkça marjinal fayda azalır. Standart kütüphane gibi trafiği yoğun çalıştırma yolları değilse, yüksek coverage ile övünmek genellikle karşılığını bulmaz
Üstelik neredeyse her zaman yalnızca birim testleri değil, entegrasyon testleri, sistem testleri gibi bir test ekosistemi de gerekir ki bütün sistem işlesin. LLM tasarım toplantısına oturup mimariyi anlayarak bu testleri de yazacak mı? Yoksa yapabilecekleri abartılıp yapılması gerekenlerin önüne mi geçecek?
Teste emek yatırırken yalnızca yazım anında değil, tasarım ve bakım sırasında da “neyin ilgili olduğu”nu ayırt etme sezgisi gerekir. İnsanlar bunu oldukça iyi yapar, AI araçları ise yapamaz
LLM’in zaman kazandırabileceği kısım, neyin test edilmesinin iyi olup olmadığını zaten sezen deneyimli geliştiricinin tuş vuruşlarıdır. Aynı zamanda pek ilgili olmayan şeyleri koda gizlice sokarak engel de olabilir; nitekim oldu da
Tuş vuruşu üreten bir ekonomi istemiyoruz. Yeterince düşünülmüş, yüksek alaka düzeyine sahip tuş vuruşları kümesi istiyoruz. Ve ikincisinin birinciden iyi ayrışmasını, zamanla nesnel faydasının ya da faydasızlığının ortaya çıkmasını umuyoruz
Bunu zaten GPT-4 ile denedim
Bir TypeScript modülü gösterip birim testleri üretmesini istedim; yalnızca normal akışı değil, birkaç sınır durumunu da kapsayan çalışan testler üretti
ChatGPT birçok açıdan beklentimin üstüne çıktı. Testler, GPT’nin yetenekleri açısından kolay görünüyor
Geçen hafta AST’yi dolaşıp React Flow grafiği ve bileşenleri oluşturan Python kodu yazdırdım. Düzenleme yapmadım; prompt geri bildirimini birkaç kez tekrarlayınca gayet iyi çalıştı. GPT’de buna benzer pek çok ilginç yetenek gördüm
AI hangi testlerin yazılması gerektiğini nasıl bilebilir?
İlginç bir deney, ama biraz şüpheli. Yazılım geliştirmede AI’ın en iyi yardımcı olabileceği yolun, programcı kendi kodu ya da başkasının kodu hakkında soru sorduğunda AI’ın yanıt vermesi olduğunu düşünüyorum. Bazen kod önerisi de içerebilir, ama her zaman gerekmez
“Bu kodu basitleştirmenin bir yolu var mı?”, “Hangi girdiler hataya yol açabilir?” gibi soruları yanıtlayabilmeli
AI, kodu ve onu nasıl iyileştireceğimizi anlamamıza yardımcı olmalı. Ne yapmasını istediğimizi söylemezsek AI ne istediğimizi bilemez; bu yüzden her şeyi kendi başına yazmasına izin vermemeliyiz
Testler bunun iyi bir örneği. Neyi test etmesini istiyoruz?
Sonunda ikna edici bir AI kod üretimi çıktı