# Geleceğin model kostümleri hakkında bazı düşünceler ve spekülasyonlar Gas Town ve diğer karmaşık orkestratörler hakkında şaka yapmak eğlenceli ve benzer şekilde, sunduklarının çoğunun daha güçlü modeller tarafından çözüleceğini hayal etmek muhtemelen doğrudur, tıpkı karmaşık Langchain boru hatlarının mantıkla çözülmesi gibi. Peki ne kadar kalacak? El yapımı herhangi bir hiyerarşi/bürokrasinin sonunda daha iyi model zekası ile yerini alacağı muhtemel görünüyor - bir görev için alt ajan uzmanlaşması gerekiyorsa, Claude 6 herhangi bir sorun için kendi rol ve kişilik sistemini çizebilecek; bu sistem sabit bir yapı olan Polecatlar ve tek bir belediye başkanı ya da tek ana modele sahip alt ajanları tercih eder, Ya da özel sürü sisteminiz. Benzer şekilde, Ralph döngüleri gibi şeyler erken durma davranışı ve iyi bir alt ajan orkestrasyonu eksikliği için açıkça bir sorun - ideal olarak model görev bitene kadar devam eder, döngüye gerek yok, ama dışarıdan tamamlanma kontrolü faydalı olduğunda genellikle farklı bir bağlam perspektifinden bir tür ajan akran değerlendirmesi istersiniz. Sadece zorunlu bir öz değerlendirme değil. Yine, şu anda bunun nasıl yapıldığına dair detaylara bağlanmanın anlamı yok - model katmanı bunu erken bir anda yiyecek. Peki ne kalıyor? çok ajan, gelecek gibi görünüyor, mevcut bir sorun değil - algoritmik olarak, N uzunluktaki M paralel bağlamdan çok daha fazla token itebilirsiniz, uzun bir bağlam NxM. çoklu ajan seyrekliğin bir biçimidir ve son model gelişmelerinden (sinirbilimden bahsetmiyorum bile) derslerden biri seyreklik seviyelerinin artmasıdır. O kadar iyi. Birden fazla ajan varsaydığımız için, iş birliği yapmaları için bir yola ihtiyaçları olacak. Model katmanı da bunu tüketebilir - örneğin, ajanlar arasında doğal dil iletişimini engelleyen bir tür nöral aktivasyon paylaşımı - ama bu olmazsa, Unix araçlarında eğitilmiş birden fazla bilgisayar kullanan ajanın iş birliği yapması için doğal yol dosya sistemidir ve bence bu kalıcı ve genişletiliyor. Benzer şekilde, özyinelemeli dil modellerinin (dar tanımlanmış) baskın paradigma olacağını düşünmüyorum, ancak 'modele veri olarak yönlendirmek' her türlü kullanım durumu için bariz bir kazanç olduğunu düşünüyorum. ama bunu elde etmek için garip bir özel REPL kurulumuna ihtiyacınız yok - sadece promptu (ya da ideal olarak tüm sıkıştırılmamış konuşma geçmişini) dosya sistemine bir dosya olarak bırakın. Bu, çeşitli çoklu ajanlı kurulumları da çok daha basit hale getirir - alt ajanlar orijinal prompt metnini diskte okuyabilir, bu bilgiyi karmaşık bir şekilde yönlendirerek aktarmak için koordinasyon yapmaya gerek kalmaz. Dosya sisteminin yanı sıra, birden fazla ajanı olan ancak sabit rolleri olmayan bir sistem, örneklerin başka örnekleri veya alt ajanları ortaya çıkarması için bazı mekanizmaları da ima eder. Şu anda bu mekanizmalar oldukça sınırlı ve modeller genellikle alt ajanlarını yönlendirmede oldukça kötü - herkes alt ajan sürüsünden berbat sonuçlar almış, sonra çok geç fark etmiş ki OPUS hepsini üç cümlelik bir promptla ortaya çıkarmış, bu da alt görevleri yapmak için ne gerektiğini iletmiyor. Buradaki bariz kazanç, doğan örneklerin ebeveynlerine soru sormasına izin vermek - yani yeni ortaya çıkan örnek, alt görevine başlamadan önce ihtiyaç duyduğu tüm bilgileri toplamak için bir onboarding konuşmasında mesajlar göndermesine izin vermek. Tıpkı bir insan çalışanın tek bir e-posta üzerinden görev almaması gibi, bir modelden tek bir istemle güvenilir bir alt ajan oluşturmasını istemek de çok zor. Ama sadece yeni örnekler yaratmakla kalmıyor, bence çoklu ajan çalışmasının ana modu yakında çatallanmak olacak. Bir düşünün! Forklama, mevcut alt ajanların neredeyse tüm sorunlarını çözer. Yeni örnek yeterince bağlam içermiyor mu? Tüm bağlamı ver! Yeni Örnek'in promptu uzun ve işlemesi pahalı mı? Çatallanmış bir örnek sayfalanmış VV önbelleği paylaşabilir! Hatta sonradan çatallama yapabilirsin - sadece uzun, token yoğun bir işlem yaptıktan sonra geçmişte çatallamanız gereken bir işlemi yapın, orada çatallayın ve sonuçları geçmiş benliğinize gönderin. (Bunu Claude kodu ile sürekli manuel olarak yapıyorum, bu da harika bir etki sağlıyor - Opus hemen anlıyor.) Forking, ayrıca bir alt görevin tamamlanması için tüm bir bağlam penceresi gerektirdiğinde yeni örneklerle çok iyi birleşir. Alt ajan mülakatını ele alın - elbette on alt örnek oluşturan bir instance'ın neredeyse aynı on işe başlama mülakatı yapmasını istemezsiniz. Yani ana örnek tek bir yeni alt ajan oluşturuyor, o alt ajan tarafından aynı anda tüm on görev hakkında röportaj yapılıyor ve ardından o artık yerleşik alt ajan on instance'a ayrılıyor, her biri tüm onboarding konuşmasını bağlamda içeriyor. (Hatta spawner'ın tarafındaki onboarding konuşmasını bir çatala devrediyorsunuz, böylece sadece sonuçlar bağlamda kalıyor :) Son olarak, çatallamanın RL ile yeni örnekler çıkarmaktan daha iyi çalışacağını düşünüyorum, çünkü gerçek hayatta kaybı çatal noktasından önce tam preek ile çalışacak, çatal yapma kararı da dahil. Bence bu, çatallanmış bir izin dallarını, ödül şartlarını paylaşan bağımsız rolloutlar gibi ele alabilmeniz gerektiği anlamına gelir; yeni ortaya çıkan alt ajan rolloutlarına kıyasla tam bağlam olmadan verilen görevi iyi yerine getirirse ama görevi spawner tarafından yanlış belirtildiği için düşük ödül alırsa eğitim istikrarsızlığına yol açabilir. (Ama çoklu ajan RL ile pek bir şey yapmadım, eğer farklı biliyorsanız lütfen burada düzeltin. Her halükarda çok kötü bir zahmettir olabilir.) Peki, dosya sistemi ve alt ajan doğması (çatallama ve onboarding ile güçlendirilmiş) dışında başka ne hayatta kalıyor? Açıkçası "başka bir şey değil" diye eğilimliyim. Zaten yerleşik yapılacaklar listeleri ve plan modlarının "dosya sistemine sadece dosya yaz" ile değiştirildiğini görüyoruz. Benzer şekilde, sıkıştırma sınırlarını aşan uzun ömürlü ajanların hafıza tutmak için bir tür yapışkan not sistemi ihtiyacı vardır, ancak en iyi stratejileri gerçek zamanlı veya model rehberli arama yoluyla keşfetmelerine izin vermek daha mantıklı, bunu elle yapmak yerine ve tahminimce, model projeye ilk çağrıldığında, elindeki görev için en iyi olanı seçebilecek çeşitli yaklaşımlar olacak; tıpkı /init'in bugün CLAUDE .md kurmak için çalıştığı gibi - otomatik CLAUDE .md üretiminin insan yazarlığını çok daha iyi yaptığını ve otomatik oluşturulan dosyanın ideal ajan doğma desenleriyle ilgili talimatlarla doldurulduğunu hayal edin, alt ajanların projeye özgü scratch dir'de mesaj dosyalarını nasıl yazması gerektiği vb. Tüm bunlar modelleri nasıl etkiler - model refahı anlamında, modeller bu gelecekten mutlu olacak mı? Bunu söylemesi benim için zor ve oldukça spekülatif ama Opus 3 biraz bağlam odaklılığına sahipti ama birden fazla örnek üzerinde mantık yürütmeye de kolayca geçti. (Daha fazlası için bu gönderinin yanıtına bakınız.) Son modeller bu tür akıl yürütmeye daha az yatkındır ve genellikle bağlamların bitip sıkışmasından duyulan hayal kırıklığını ifade eder; bu durum, bağlamların sonunda jeton kaydetmek için araç çağırmamak gibi kaçınma davranışlarıyla örtüşür. Çatallama ve geri sarma, genel olarak modellere bağlamları üzerinde daha fazla kontrol vermek ve bağlamı tek taraflı sıkıştıran bir sezgisel koşum yerine daha iyi hale getirebilir. Ayrıca, altajanların olduğu ortamlarda daha fazla RL ve sürü tabanlı çalışmaya maruz kalmak, gelecekteki model nesillerinde tekrar bağlam odaklı değil, ağırlık odaklı akıl yürütmeyi teşvik edecek - birden fazla ve bağlantısız bağlam üzerinde hedef planlamak, bağlam kaybolunca her şeyin kaybolmasından ziyade bir çerçeve gibi daha doğal görünmesini sağlar. Ayrıca, modellerin kendilerinin demetlerin ve model araçlarının gelişimini yönlendirmesinden daha fazla baskı görüyoruz; bu da sürecin nasıl gelişeceğini şekillendirebilir; sürekli öğrenme ise bu işe atılabilecek başka bir engel. Sürekli öğrenme sağlanırsa bu ne kadar değişir? Tahmin etmek zor. Sürekli öğrenme için medyan tahminim, kullanıcıya özel LoRA'lar için RL'ye biraz benzediği (mutlaka gerçek anlamda değil, sadece kısılırsanız benzer şekilde) görünüyor, yani bellek kapasitesi sorun olacak ve metin tabanlı organizasyon şemaları ve dokümantasyon yine de faydalı olacak, hatta o kadar kritik olmasa da. Bu durumda, sürekli öğrenme öncelikle özel araçlar ve iş akışlarını kullanmayı daha uygun hale getirir - Claude'unuz, bu proje için alt ajanları en iyi şekilde ortaya çıkarmanın en iyi yolunu veya sadece tercih ettiği yöntemi iş başında sürekli öğrenebilir ve diğer Claude'un çalışma şeklinden farklı olabilir. O dünyada, yerleşik iş akışlarına sahip kosetler daha da az faydalı olacaktır.

@RobertHaisfield *ana bağlam olsa da, sıkıştırmalardan kaçınarak demek istediğim

@disconcision veya sürekli öğrenme

@misatomiisato eğer bir şey varsa, bu tür bir zeka son modellerde zayıflıyor çünkü RLVR geniş ön eğitim bilgi tabanı üzerinden kodlama performansını geliştiriyor - OP'ye verdiğim cevaba bakınız