Ajanınız bağlam penceresinin %80'ine ulaşır. Sıkıştırma devreye girer ve en eski konuşma turlarını atar. On dakika sonra, daha önce okuduğu bir dosyayı yeniden okur ve zaten yanıtladığı bir soruyu yeniden sorar.
Eşik, yerinizin kalmadığını biliyordu. Neleri güvenle kaybedebileceğiniz hakkında hiçbir şey bilmiyordu.
Bu, şu çalışmanın dikkatli bir okumasından yola çıkan, uzun vadeli ajan tasarımı serisinin üçüncü yazısıdır: BEACON (Zhejiang Üniversitesi, arXiv:2605.06078). Serinin ilk yazısı ilerlemenin durduğunu tespit etmeyi, ikinci yazısı kilometre taşı tasarımını ele alıyordu.
Kendi uygulamamızdan başlayalım
Orkas, çok ajanlı bir masaüstü istemcisidir. Burada uzun görevler olağandır, bu yüzden sıkıştırma her gün gündeme gelir. Bizim uygulamamız bir token eşiğinde tetiklenir ve bağlam, pencerenin yaklaşık %80'ine ulaştığında sıkıştırma yapar. Bunu yazıya dökene kadar hiçbirimiz bunda bir sorun olduğunu düşünmemiştik.
Pratikte yaklaşık üç yaygın sınır kullanılır: pencerenin yüzdesi, konuşma turu sayısı veya modelin eski içeriği kapsayan bir özet yazmasına izin vermek. Bizimki ilk türden.
İlk ikisi içeriğe hiç bakmaz. Üçüncüsü bakar, ancak neyin önemli olduğu sorusunun tamamını modele bırakır.
Üçü de şu soruyu yanıtlar: ne zaman bir şeyleri atmak zorundayım. Asıl sorunuz ise şudur: neleri güvenle atabilirim. Eşikte kesmek, en önemsiz içeriği değil, en eski içeriği atar.
Kilometre taşı sınırı ve altında yatan varsayım
Önceki yazıdaki kilometre taşları, bu üçünün herhangi birinden daha iyi bir sınır sağlayabilir. Ancak burada bir tuzak var ve önceki yazı bunu biraz fazla sorunsuz göstermişti.
BEACON, kilometre taşı Markov özelliği adlı bir varsayım içerir. Basitçe ifade edersek: bir kilometre taşına ulaştığınızda, bundan sonra ne olacağı oraya nasıl geldiğinize değil, yalnızca geriye kalan alt hedeflere bağlıdır. Anahtarı elde ettikten sonra önemli olan onu nasıl bulduğunuz değil, hangi kapıyı açtığınızdır.
Bu, sıkıştırma yapmak için bir izin gibi görünüyor: bir kilometre taşını geçince öncesindeki bölüm kaldırılıp bir kenara konabilir.
Ancak bu bir varsayımdır, gerçek değil. Makalede = değil, ≈ yazıyor ve yazarlar bunun nerelerde geçersiz kaldığını tartışıyor.
Eğitim için yeterli, sıkıştırma için yetersiz
Aynı varsayım, iki kullanım; gereken kesinlik arasında bir büyüklük mertebesi fark var.
Eğitimde yalnızca istatistiksel olarak geçerli olması gerekir. Birkaç bin yürütme örneğinin birkaç düzinesinde geçersiz kalırsa sapma, ortalamada dengelenir. Eğitim ayrıca güvence olarak altta yörünge düzeyinde bir sinyal de kullanır; bu katmanı kaldırdığınızda ALFWorld, 91.4'ten 23.4'e düşer; bu, hiçbir şey yapmamaktan bile çok daha kötüdür.
Sıkıştırmada ise her bir durumda, yani önünüzdeki tek yürütmede geçerli olması gerekir. Yanlış şeyi bir kez atarsanız o görev biter. Ortalaması alınacak bir şey yoktur.
Dolayısıyla makalenin bu varsayıma dayanması, onu sıkıştırmaya taşıyabileceğiniz anlamına gelmez. İki kullanım, varsayımdan aynı şeyi beklemez.
Geçersiz kaldığı dört durum
Bir sıkıştırma politikası üzerine düşünürken bunları kontrol listesi olarak kullanıyoruz.
1. Yol boyunca biriken örtük bilgi. Başlarda bir adım, belirli bir API'nin zaman damgalarını UTC olarak döndürdüğünü ortaya koyar. Bu, hiçbir kilometre taşına ait değildir ama sonraki her adım buna ihtiyaç duyar.
2. Zaten tüketilmiş kaynaklar. Token bütçesi, çağrı kotası, kalan süre. Bir kilometre taşı şunu kaydetmez: Bütçenin %60'ını harcadım, ancak yeniden denemenin hâlâ karşılanabilir olup olmadığını bu sayı belirler.
3. İzlenen yola bağlı yan etkiler. Kilometre taşı şöyle der: yeniden düzenleme tamamlandı. Hata ayıklama başlar başlamaz, gerçekte hangi beş dosyaya dokunulduğunu bilmeniz gerekir.
4. Kilometre taşının kendisi yeterince açık tanımlanmamıştır. Dördü arasındaki en kötü durum budur. Makalede bir kilometre taşı, ortamın eksiksiz durumudur — anahtar ya sizdedir ya da değildir, belirsizlik yoktur. Bir plan adımı ise doğal dilde tek bir cümledir. "Veri temizliğini bitir" ifadesi, o bölümde olup bitenleri kapsamaya yaklaşamaz bile.
Bunun yerine neler aktarılmalı?
Yalnızca bir özet tutmayın. Özeti model yazar ve neyin önemli olduğuna sezgisel olarak karar verir.
Bir insanın seçtiği sabit bir alan kümesi tutun. En az şu dört alan:
- Çalışma alanının şu anki durumu — hangi dosyalara dokunulduğu ve hangi duruma getirildikleri.
- Kalan bütçe — tokenlar, çağrı kotası, süre.
- Kesinleştirilen bilgiler — UTC bilgisi ve sonraki kararları şekillendirecek benzeri her şey.
- Hâlâ açık olan konular — bir kez engel çıkaran, etrafından dolaşılan ve yeniden ortaya çıkabilecek şey.
Bunları yukarıdaki dört başarısızlık durumuyla karşılaştırdığınızda bire bir örtüştüklerini görürsünüz. Bu eşleşme, bir sıkıştırma politikasının yeterli olup olmadığını değerlendirmenin en basit yoludur.
Bunun yarısı neredeyse bedavaya gelir. Önceki yazıda anlatıldığı gibi, ana sistem her araç çağrısından sonra deterministik gerçekleri zaten kaydeder: bir dosyanın gerçekten yeniden yazılıp yazılmadığını, bir komutun gerçekten çalışıp çalışmadığını. Bu veriler kilometre taşlarını doğrulamak için toplandı, ancak bunlar tam olarak çalışma alanının anlık görüntüsüdür; dolayısıyla sıkıştırma, bir modelden yeniden özetlemesini istemeden bunları doğrudan aktarabilir.
Zor olan yarı, diğer iki alandır. Kesinleştirilen bilgiler ve hâlâ açık olan konular şu anda ancak model bunları yazıya dökerse var olur; sıkıştırmada ilk kaybolanlar olmalarının nedeni de tam olarak budur.
Bu tartışılacak değil, ölçülecek bir şey
Sıkıştırmadan sonra ajan, sıkıştırmayla çıkarılmış bir dosyayı yeniden okursa veya zaten yanıtlanmış bir soruyu yeniden sorarsa varsayım o görevde geçersiz kalmıştır ve kanıt tam oradadır.
Ölçüm altyapısı basittir: sıkıştırma noktasından sonra okunan dosya yolları ile öncesinde kaydedilenlerin kesişimini alın.
Bu sayıyla, hangi görev türlerinin yoğun biçimde sıkıştırılabileceği, hangilerinin sıkıştırılamayacağı bir tasarım tartışması olmaktan çıkıp bir sorguya dönüşür. Bu, serinin ilk yazısındaki yaklaşımla aynıdır: önce ölçün, sonra bir şeyleri değiştirin.
Bunun hangi noktalarda ihtiyatla ele alınması gerekiyor?
Bunların hiçbiri henüz kullanıma sunulmadı. Tasarım ve ölçüm altyapısı aşamasındayız.
Hangi alanların, hangi ayrıntı düzeyinde tutulacağı, gerçekte nelerin yeniden getirildiğine ilişkin verilerden çıkarılmalı. Şimdi karar vermek, yanlış karar vermenin iyi bir yoludur.
Üstelik bu, çeşitli yaklaşımlardan yalnızca biri. Sınırın nereye konduğu ve alanların nasıl tanımlandığı, başka türde bir üründe tamamen farklı görünebilir. Dört durumlu kontrol listesi başka yerlere taşınabilir; belirli çözüm taşınamaz.
Serinin bir sonraki ve son yazısı öz değerlendirmeyi ele alıyor: bir ajanın deneyimlerinden çıkardığı dersler neden sürekli "daha dikkatli ol" kadar genel kalıyor ve girdilerinin neleri içerip neleri içermediğiyle ilgili gerçekten şaşırtıcı bir nokta.