Herkes Sürekli Öğrenme'den bahsederken sadece tek bir anlama geldiğini varsayar: model ağırlıklarını güncellemek. Ancak ajan ekosistemiyle ilgili göz ardı edilen bir gerçek var: bugün üretimdeki ajanların büyük çoğunluğu kapalı sınır modellerini kullanıyor. Ağırlıklara sahip olmadığınızda, onları ince ayarlayamazsınız. Çoğu ajan geliştiricisi için, ağırlık düzeyinde sürekli öğrenme masadan kalkmıştır, özellikle de yeteneklerin en sınırında çalışırken (Fable 5 veya GPT 5.6 gibi).
Bu, ajanların öğrenemeyeceği anlamına gelmez. Ajan sistemleri üç katmanda iyileştirilebilir: model, koşum ve bağlam [0] ve son ikisi tamamen sizin kontrolünüzdedir. İşte burada büyük (ama genellikle göz ardı edilen) bir fırsat yatıyor: koşum düzeyinde öğrenme, ajanınızın her örneğini çalıştıran kodu, araçları ve talimatları sistematik olarak iyileştirmek için üretim izlerini kullanmanıza olanak tanırken, bağlam düzeyinde öğrenme, ajan, kullanıcı ve kuruluş düzeyinde kişiselleştirme yapmanızı sağlar, böylece ürününüz her etkileşimde daha iyi hale gelir. Tüm bunları yaparsanız, her gün dağıtabileceğiniz birikimli iyileştirmeler elde edersiniz.
Bu yazının geri kalanında, geçtiğimiz yıl boyunca Replit Agent'a sürekli öğrenmeyi nasıl uyguladığımızı ve bu süreçte öğrendiğimiz tüm dersleri paylaşacağım.
Replit Agent'ı ölçekte değerlendirme ve iyileştirme
Çoğu Replit Agent kullanıcısı bir fikirle başlar. Hedefi doğal dilde tanımlarlar - bir depo, test paketi veya seçilmiş bir çerçeve olmadan - ve ajanın bunu çalışan bir uygulamaya dönüştürmesini beklerler. Sonuç bir web sitesi, slayt destesi, mobil uygulama, birbirine bağlı birkaç yapıt veya tamamen başka bir şey olabilir.
Vibe kodlayıcılar genellikle farkları veya test çıktılarını kontrol etmezler. Replit Agent için başarı aldatıcı derecede basittir: kullanıcılar tıkladığında uygulama çalışmalıdır.
Bu, değerlendirmenin işini değiştirir. Tek bir puan, belirli bir dağıtım kararına yardımcı olabilir, ancak haftadan haftaya Replit Agent'ın kullanıcılar için daha iyi hale gelip gelmediğini söyleyemez. Bu soruyu yanıtlamak için değerlendirme, iyileştirme döngüsünün bir parçası haline gelmelidir.
NASA Lewis Araştırma Merkezi, Motor Araştırma Binası Merkez Kontrol Odası, 1968 — Ölçüm, neyin dağıtıldığını değiştirdiğinde önemlidir.
Değerlendirme artık daha fazlasını yapmak zorunda
Ajan değerlendirmesi eskiden tek yönlü bir süreç gibiydi: değerlendirmeyi çalıştır, bir puan üret ve bir dağıtım kararı ver. Bu, sürümler yavaş olduğunda ve ölçülen şey nadiren değiştiğinde işe yarar. Modeller, istemler, araçlar ve ürün yüzeyleri hızla değiştiğinde bozulur.
Eski döngü, değerlendirmeyi sınırlı hissettiriyordu. Ancak Replit Agent, tek bir puanın tüm kararı taşıması için çok hızlı değişiyor. Bir puan, iki adayı tek bir görev diliminde karşılaştırabilir. Kullanıcıların neyi önemsediğini, üretimin nerede bozulduğunu veya bir sonraki adımda neyin iyileştirileceğini açıklayamaz.
Değerlendirme, bir lansman kontrolünden bir iyileştirme döngüsüne geçmek zorundaydı.
Eski değerlendirme işi, bir insanın dağıtım kararıyla sona erer; yenisi ise üretimden öğrenen ve iyileştirilmiş ajanlar dağıtan sürekli bir sistemi besler.
Sistemin iki ölçüm ayağı ve bir optimizasyon döngüsü vardır. Çevrimdışı kıyaslamalar, aday değişikliklerin simüle edilmiş uygulama oluşturma görevlerini dağıtmadan önce tamamlayıp tamamlayamayacağını söyler. Çevrimiçi A/B testleri ve üretim izleri, değişiklikler dağıtıldıktan sonra gerçek kullanıcıların nasıl etkilendiğini gösterir. Bu sinyaller daha sonra değerlendirmelere ve dağıtım kararlarına geri akar.
Hiçbir katman tek başına yeterli değildir. Kıyaslamalar, sürümden önce gerilemeleri yakalar. A/B testleri, üretim davranışının hareket edip etmediğini gösterir. İz kümeleri, toplu metriklerin altındaki başarısızlıkları açıklar. İnsan yargısı, iyileştirme döngüsünü doğru ürün ve mühendislik sonuçlarına yönlendirir. Şekil, güvenlik mühendisliğindeki İsviçre peyniri modeline benzer: her katmanın delikleri vardır, ancak birlikte herhangi bir katmanın tek başına yakalayabileceğinden daha fazlasını yakalarlar.
Mevcut kıyaslamalar kullanıcının ihtiyacını karşılamıyor
SWE-bench [1] ve Terminal-Bench [2] gibi ajan kodlama kıyaslamaları, kısıtlı, tekrarlanabilir ortamlarda kodu derecelendirir. Bu kıyaslamalar değerlidir ve yaygın olarak benimsenmiştir, ancak bir vibe kodlayıcının önemsediği sinyali kaçırırlar.
Replit Agent genellikle kod tabanını sıfırdan oluşturur. Kullanıcılar sabit rotalar, işlev imzaları, seçiciler veya testler getirmez; bir ürün talebi getirirler. Ajan, yığını, şemayı, rotaları, bileşenleri ve etkileşim akışlarını seçer.
Bu, işlevsel bir doğruluk boşluğu yaratır. Bir ajan, bir kodlama kıyaslamasının yerel kısıtlamalarını karşılayabilir ve yine de kullanıcının gördüğü şeyde başarısız olabilir: bitmiş uygulamanın isteneni yapıp yapmadığı. Vibe kodlama için değerlendirme hedefi, yapıtın kendisidir: yükleniyor mu, temel iş akışı çalışıyor mu ve sonuç talebe uyuyor mu?
ViBench'i Tanıtıyoruz
Bu tür uçtan uca değerlendirmeye olan ihtiyaç, tam da bu nedenle ViBench'i [3] oluşturduk. Vibe kodlama için halka açık kıyaslamamız, basit ama önemli bir sinyali ölçer: ajan tarafından oluşturulan uygulama şartnameyi karşılıyor mu?
ViBench, anonimleştirilmiş Replit üretim izlerinden alınan, düz İngilizce bir ürün gereksinimleri belgesi (PRD) ile başlar. Buradan itibaren ajan, PRD'yi alır ve geleneksel kodlama kıyaslamalarının gerektirdiği iskele, rotalar veya referanslarla kısıtlanmadan sıfırdan çalışan bir uygulama oluşturur.
Bununla birlikte, ViBench'i gerçekçi kılan aynı esneklik, eşit derecede esnek bir değerlendirme ajanı gerektirir; PRD'ye bağlı kalan bir ajan. SWE-bench tarzı kıyaslamalarda proje zaten mevcuttur, bu nedenle değerlendirme yüzeyi sabittir. Vibe kodlamada ajan, yığını, rotaları, bileşenleri ve akışı seçer. Değerlendirme, ne icat ettiyse onu keşfetmek zorundadır.
Bu amaçla, her ViBench görevi, PRD'yi, bitmiş uygulamanın karşılaması gereken özellik düzeyindeki etkileşimleri ve iddiaları tanımlayan bir dizi doğal dil test planıyla eşleştirir. Değerlendirme ajanı, esnek bir omurga olarak Playwright'ı kullanır ve bu da çevrimdışı simülasyon, dosya işleme ve çok kiracılılık gibi karmaşık özellikleri kullanmasına olanak tanır. Uygulamanın konumlandırıcılarını veya yapısını önceden bilmediği için, bir not defteri ortamında çalışır, uygulamanın nasıl oluşturulduğunu aşamalı olarak keşfeder ve adım adım onunla etkileşime girer; bu yaklaşım Replit'in otomatik kendi kendini test etme üzerine daha önceki araştırmalarından alınmıştır [4].
ViBench'i ve genel olarak değerlendirmelerimizi Replit ölçeğinde çalıştırmak aynı zamanda güçlü bir altyapı desteği gerektirir [5]. Dahili olarak, uygulama oluşturmak ve ajanlarımızı çalıştırmak için izole, iyi kaynaklara sahip sanal alanlar oluşturmamızı sağlayan aynı üretim altyapısına güveniyoruz. Bu sanal alanları hızla çatallayabildiğimiz için [6], değerlendirmelerin çoğunu, değerlendirmeler arası bulaşma riski olmadan paralel olarak yürütüyoruz.
Sıfırdan uygulama oluşturmanın ötesinde, aynı ViBench temeli, doğal dil test planları tarafından derecelendirilen doğal bir dil PRD'si, bir dizi vibe kodlama senaryosuna uyum sağlar. Bir ajanın mevcut bir uygulama içinde nasıl çalıştığını, Replit'in orta yörünge iş yüklerine daha yakın bir şekilde değerlendirmek için, onu mevcut bir kod tabanında başlatırız ve bir özellik PRD'sinden özellik uzantılarını ne kadar iyi dağıttığını ölçeriz. Bu kod tabanı, kendi referans uygulamalarımızdan veya ajanın kendi vibe kodladığı uygulamalardan gelebilir; buna yayınımızda Vibe-to-ref ve Vibe-on-Vibe adını veriyoruz. Yeni ürün yüzeyleri dağıttığımızda, aynı omurga, Ajan 4'ün paralel-ve-birleştirme ve alt ajan ayrıştırmaları için yaptığımız gibi, yeni etkileşim modellerini değerlendirmek için hızla yeni problemler türetmemizi sağlar.
ViBench, davranışsal değerlendiriciyi sabit tutarken girdi ve oluşturma stratejisini değiştirir.
Erken ViBench sonuçları bize iki yararlı ders verdi. Birincisi, sınır kodlama kıyaslama puanları her zaman tam uygulama oluşturmaya aktarılmaz, özellikle açık ağırlıklı modeller için. İkincisi, çoğu model kendi kodlarını genişletirken daha da kötüleşir, çünkü hatalar genellikle birbirini tamamlar. Birlikte, bu dersler bize tırmanılacak daha iyi bir tepe verir: sadece testleri geçen kod yazmak değil, bir sonraki kullanıcı talebine dayanabilecek uygulamalar oluşturmak.
A/B testi kendimizi dürüst tutma yöntemimizdir
Çevrimdışı değerlendirmelere derinden güveniyoruz, ancak bunlar tek yargıç değildir. Kontrollü ortamlarda iyi görünen, ancak gerçek kullanıcı davranışını gerileten yeterince ajan güncellemesi gördük ki üretimin kendi ölçüm katmanına ihtiyacı olduğunu biliyoruz.
Kullanıcılar senaryosuzdur, her zaman açıktır ve hiçbir çevrimdışı kıyaslamanın tam olarak yeniden üretemeyeceği bir ölçekte çalışır. Projeleri terk ederler, fikirlerini değiştirirler, özellikleri şaşırtıcı şekillerde birleştirirler ve test etmeyi bilmediğimiz başarısızlık modlarını keşfederler.
Bu nedenle, ajanı etkileyen güncellemelerin çoğunda A/B testi yaparız: istemler, araçlar, koşum revizyonları, model değişiklikleri ve daha büyük davranış değişiklikleri. Birden fazla deney genellikle eşzamanlı olarak yürütülür - etkileşim efektlerini gizlemekten kaçınmak için atıf net tutulur. A/B testleri, kullanıcı davranışını, duyarlılığını ve başarısını ortaya çıkarır: kullanıcılar devam etti mi, maliyet beklenmedik şekilde davrandı mı, duyarlılık değişti mi ve kullanıcılar bir şey dağıttı mı?
A/B testleri bize üretim davranışı hakkında kontrollü bir okuma sağlar, ancak toplu metrikler kendilerini açıklamaz. Bu bir kazanç mı? Temel davranış değişikliği nedir?
A/B testiyle ilgili bir zorluk, sonuçların yorumlanmasının zor olmasıdır. Çalışma süresi artarsa, ajan daha fazla yararlı iş mi yaptı yoksa takılıp mı kaldı? Maliyet düşerse, verimliliği mi artırdık yoksa ajan sessizce değerli bir şey yapmayı mı bıraktı? Duyarlılık düşerse, hangi kullanım durumları geriledi, hangi başarısızlık modları yeni ve hangi kullanıcılar pes etti?
Telescope: neyin bozulduğu
A/B testi bize üretim davranışının ne zaman hareket ettiğini söyler. Telescope - iz analizi ve kümeleme sistemimiz - nedenini açıklamaya yardımcı olur.
Üretim ölçeğinde hiçbir mühendis her izi okuyamaz. Telescope, tekrarlanan kalıpları, mühendislerin ve ajanların üzerinde hareket edebileceği sorun kümeleri halinde düzenler. Başarısızlık yörüngelerini özetler, onları gömer, benzer vakaları kümeler ve dağıtım değiştikçe yeni oturumları sınıflandırır. Amaç sadece başarısızlıkları saymak değil, göz önünde saklı olanları keşfetmektir.
GIF
Ne arayacağımızı bilmediğimiz şeyleri kümeleme.
Telescope, Clio [7] ile aynı aşağıdan yukarıya yaklaşımdan ilham alan kısa, kanıta dayalı yönler kullanır. İzler için, kullanıcı mesajlarından, görünür ajan yanıtlarından, araç çağrılarından, hatalardan, meta verilerden ve diğer bağlamlardan oturumu yeniden oluşturur. Buradan Telescope, neyin yanlış gittiğini özetler, bu özetleri gömer ve ortaya çıkan sorun gruplarını oluşturmak için yoğunluk tabanlı kümeleme [8] kullanır.
Yönler, özellikle kümeleme tek başına yeterli olmadığında, araştırmayı hızlandırır. Destek raporları, bağlantı noktası hataları gibi geniş bir soruna işaret ettiğinde, mühendisler ve ajanlar önce kompakt katmanda arama yapabilir, ilgili yönleri keşfedebilir ve ardından bunu açıklamak için gereken günlükler ve gözlemlenebilirlik bağlamıyla temsili oturumlara derinlemesine inebilir.
Toplu olarak, aynı yapı, dağınık başarısızlıkları ürün sorularına dönüştürür: hangi iş akışları baskın, hangileri terk ediliyor, ne tekrar tekrar bozuluyor ve bir hafifletme, amaçlanan kümeyi küçültüyor mu?
Bu temel mimari hakkında daha fazla bilgi için, Braintrust'taki işbirlikçilerimizden Konular hakkındaki derinlemesine yazıya bakın [9].
Döngü: kanıttan ajan iyileştirmelerine
Ölçüm var olduğunda, darboğaz hareket eder. ViBench, A/B testleri ve Telescope bize neyin başarısız olduğunu, nerede başarısız olduğunu ve ne sıklıkta olduğunu söyleyebilir. Yine de bu kanıtı makul düzeltmelere dönüştürmek zorundayız.
Bunu ele almak için bir kendini iyileştirme döngüsüne başvuruyoruz. Çalışma prensibi basittir: ajanlar yazılım oluşturmak için kullanışlıysa, ajanı iyileştirmek için de kullanışlı olmalıdırlar. Her geçiş, kovalamaya değer bir hipotez bulmak için üretim günlüklerini, iz kümelerini ve son başarısızlıkları okuyarak başlar. Ardından bir aday oluşturur, ekli gerekçeyle birlikte bir taslak PR açar, sonucu ViBench, A/B sonuçları, yörünge verileri ve son taban çizgilerine karşı ölçer ve dağıtmayı, yinelemeyi veya bırakmayı önerir.
Optimizasyon döngüsü sorunları keşfeder, ajan değişiklikleri önerir, bunları değerlendirir ve dağıtmaya, yinelemeye veya bırakmaya karar verir.
Dağıtım otomatik hale gelmez. Döngü, kanıtı ve ilk geçiş uygulamasını hazırlayabilir; mühendisler yine de sonucu inceler ve lansman kararını sahiplenir.
Her çalıştırma, ne denediğini ve ne olduğunu, başarısızlıklar dahil, kaydeder. Bu kayıt, döngüyü zamanla iyileştirir: gelecekteki çalıştırmalar işe yarayanı yeniden kullanabilir, bilinen çıkmaz sokaklardan kaçınabilir ve genelleme yapan değişiklikler önerebilir.
Ajan yinelemesi, mühendislik kontrolünden vazgeçmeden hızlanır. Yeni bir model, ürün yüzeyi veya güvenilirlik hedefi verildiğinde, döngü, mühendisler sistemi daha büyük ürün optimumuna yönlendirirken, istem düzenlemeleri, beceri önerileri, araç düzeltmeleri ve koşum değişiklikleri bulabilir.
Somut bir örnek
Yakın tarihli bir çalıştırma, küçük ama büyüyen bir Telescope kümesiyle başladı. Ortam kurulumu, soğuk başlatma senaryolarının uzun bir kuyruğunda sessizce bozuluyordu. Bu oturumlar toplu metriklerden belli değildi, ancak küme araştırmaya değer bir kalıp gösteriyordu.
Kalıbı yüzeye çıkardıktan sonra döngü, etkilenen yörüngeleri okudu, bir yama önerdi, bir regresyon testi ekledi ve mutlu yolun gerilemediğini doğrulamak için adayı ViBench'e karşı çalıştırdı. Mühendisler kanıtı inceledi, değişikliği onayladı ve aynı gün üretime gönderdi.
Yama dağıtıldıktan sonra duyarlılık düzeldi ve etkilenen kullanıcıların önü açıldı. İstediğimiz şekil bu - gerçek bir başarısızlık kalıbı bulan, onu etkilenen kullanıcılara bağlayan, doğru düzeyde düzeltme öneren ve bir insanın dağıtıp dağıtmayacağına karar vermesi için yeterli kanıtı geri getiren bir döngü.
İnsan zevkinin hala en çok önemli olduğu yer
Bunun çoğu otonom olarak çalışabilir: başarısızlıkları kümeleme, hipotezler önerme, adaylar oluşturma, değerlendirmeleri çalıştırma ve kanıtları bir araya getirme. İnsanlar yine de yönü belirler ve çoğu çıkışı kontrol eder, bunlar dahil:
- Hipotez seçimi. Bir sistem binlerce başarısızlığı yüzeye çıkarabilir, ancak insanlar hangi soruların döngünün bir gecelik bütçesini hak ettiğine karar verir. Her küme eşit derecede önemli değildir ve her gerileme doğru ürün sorununa işaret etmez.
- Uygulama mimarisi. İzler, kullanıcıların bir iş akışını terk ettiğini gösterebilir, ancak bu yolu düzeltmeye, ajanın davranışını değiştirmeye veya yüzeyi yeniden tasarlamaya karar vermek bir mühendislik ve ürün yargısıdır.
- Değerlendirme küratörlüğü. Bu idari bir iş değildir; ajanın tırmandığı tepeyi şekillendirir. Değerlendirme yanlış davranışı ödüllendirirse, optimizasyon döngüsü sadakatle yanlış şeye doğru optimize edecektir.
- Lansman onayı. Bir ajan değişikliğini dağıtmak sadece bir sayıyı okumak değildir. Lansman onayı, kanıtı okumak, etki alanını anlamak, riskin kabul edilebilir olup olmadığına karar vermek ve dağıtımı sahiplenmek anlamına gelir.
Bu denge önemlidir: döngü, arama, ölçüm ve sentezin daha fazlasını yapabilir. Mühendisler yine de yönü seçer, ürün kararlarını verir ve neyin dağıtılacağına karar verir.
Döngüyü kapatmak
Değerlendirme artık sadece lansmandan önceki bir kapı değildir. Neyin düzeltileceğine, neyin test edileceğine ve neyin yayınlanacağına karar vermeye yardımcı olur.
Amaç daha iyi bir sayı üretmek değildir. Kullanıcı başarısızlıklarını daha iyi sürümlere dönüştürmek, böylece daha fazla fikrin insanların yayınlamaktan gurur duyacağı uygulamalar haline gelmesini sağlamaktır.
Otonom ajanların sınırlarını zorlamaya devam etmekten heyecan duyuyoruz, en karmaşık kodlama görevleri için güvenilirliğe odaklanarak. Otonom kodlama ajanları üzerinde çalışmakla ilgileniyorsanız, Replit AI ekibinde her zaman işe alım yapıyorum - bana şu adresten ulaşın: [email protected]
Yazarlar: Daniel Furman, Peter Zhong, Zhen Li, Michele Catasta
Referanslar
[0] AI ajanları için sürekli öğrenme
[1] SWE-bench: Dil Modelleri Gerçek Dünyadaki GitHub Sorunlarını Çözebilir mi?
[2] Terminal-Bench: Komut Satırı Arayüzlerinde Zorlu, Gerçekçi Görevlerde Ajanları Kıyaslama
[3] ViBench: Vibe Kodlama Üzerine Bir Kıyaslama
[4] REPL Tabanlı Doğrulama ile Ajan 3'ün Ölçekte Kendi Kendini Test Etmesini Sağlama
[5] Ajan kodlama değerlendirmelerinde altyapı gürültüsünü ölçme
[6] Replit'in Anlık Görüntü Motorunun İçinde: AI Ajanlarını Güvenli Kılan Teknoloji
[7] Clio: Gerçek Dünya AI Kullanımına Gizlilik Korumalı Bilgiler
[8] Veri Kümeleme, Görselleştirme ve Aykırı Değer Tespiti için Hiyerarşik Yoğunluk Tahminleri
