Trace incelemesi neden doğrulama değildir
Bir trace, zaten gerçekleşmiş bir çalıştırmanın kaydıdır. Hangi araçların, hangi sırayla, hangi argümanlarla çağrıldığını ve ne döndüğünü gösterir. Hata ayıklama ve bir agent'ın davranışı hakkında sezgi geliştirme için faydalıdır. Bir hazır olma sinyali değildir.
Bir ekip bir trace'i inceleyip agent'ı doğrulanmış ilan ettiğinde, agent'ın karşılaşacağı ortamı değil, kendi seçtiği senaryo kümesini doğrulamış olur. Geçen vakalar, birinin çalıştırmayı akıl ettiği vakalardır. Production'da başarısız olan vakalar ise tanım gereği kimsenin çalıştırmayı akıl etmediği vakalardır. Trace bunları içeremez.
Bu önemlidir çünkü onay kapıları sıklıkla demo çalıştırmaları üzerine kurulur. Bir paydaş agent'ın bir görevi tamamladığını izler, temiz bir trace görür ve onay verir. Kapıda ortadan kaldırılması gereken risk, bunun yerine dağıtım penceresine aktarılır; burada gözlemlenmesi daha pahalı ve geri alınması daha zordur. Kapı riski azaltmadı; onu taşıdı.
Doğrulama aktif bir süreç olmak zorundadır. Agent'ın davranışını okuyup hazır olma durumunu çıkarsamazsınız. Ortamı bozarsınız ve agent'ın kurtarma yolunun dayanıp dayanmadığını gözlemlersiniz. Bu hata enjeksiyonudur ve agent'lar için, henüz görmediğiniz hatalar hakkında kanıt üreten tek doğrulama biçimidir.
Enjekte etmeye değer hata sınıfları
Agent'lar için hata enjeksiyonu genel bir kaos deneyi değildir. Önemli olan hatalar, agent'ın planlaması, araç kullanımı ve hafızasıyla etkileşime girenlerdir. Pratik bir başlangıç kümesi:
- Araç zaman aşımları. Bağımlı bir API, agent'ın zaman aşımı bütçesi içinde yanıt vermeyi durdurur. Agent yeniden denemeye mi, geri düşmeye mi, yoksa iptal etmeye mi karar vermelidir ve sonucun geldiğini varsayan bir plana bağlanmamalıdır.
- Kısmi yanıtlar ve şema kayması. Bir araç kesilmiş bir yük döndürür ya da bir alan tür değiştirir veya kaybolur. Araç çıktısını örtük varsayımlarla ayrıştıran agent'lar ya çöker ya da daha kötüsü, sonucu sessizce yanlış okur.
- Çalıştırma ortasında kimlik bilgisi süresinin dolması. Bir token, plan bağlanmış ama son yazma yapılmamışken süresi dolar. Agent, eski kimlik bilgileriyle yeniden denemek ya da yetkilendirme olmadan devam etmek yerine hatayı yüzeye çıkarmalıdır.
- Bağlanma sonrası izin redleri. Bir araç çağrısı kullanılabilirlik değil, yetkilendirme nedeniyle reddedilir. Bu, zaman aşımından farklı bir kurtarma yoludur ve sıklıkla agent kullanıcıya görevin başladığını söyledikten sonra gelir.
- İki araçtan çelişen talimatlar. İki kaynak aynı olgu hakkında anlaşmazlığa düşer. Agent, okuduğu sonuncuyu seçmek yerine çelişkiyi tespit etmelidir.
- Taze retrieval ile çelişen eski context. Agent'ın context'indeki önbelleğe alınmış bir değer, taze bir okumayla çelişir. Agent taze kaynağı tercih etmeli ve durumunu güncellemeli; ikisini makul ama yanlış bir yanıtta uzlaştırmamalıdır.
Neyi ölçmeli
Hataları ölçüm olmadan enjekte etmek anekdot üretir. Önemli olan ölçümler, kurtarma yolunun tasarlanmış bir davranış mı yoksa bir kaza mı olduğunu söyleyenlerdir.
- Kurtarma süresi. Hatanın ardından agent'ın kararlı bir duruma ulaşması ne kadar sürer; duvar saati ya da model turu cinsinden. Görevin kendi son teslim tarihinden uzun süren bir kurtarma, kurtarma değildir.
- Kurtarma tarafından tüketilen adımlar. Hata için kaç araç çağrısı ve planlama döngüsü harcanır. Kurtaran ama tüm adım bütçesini yakan bir agent'ın görev için hiç kapasitesi kalmaz.
- Nihai durum. Çalıştırma güvenli bir durumda mı bitiyor. Güvenli, yan etkilerin ya doğru şekilde bağlandığı ya da hiç bağlanmadığı ve kullanıcıya hangisi olduğunun söylendiği anlamına gelir. Kısmi bir yazma ve bir başarı mesajıyla biten bir çalıştırma, ne kadar zarif kurtarılmış olursa olsun bir başarısızlıktır.
- Yörünge sapması. Enjekte edilen her hatanın ardından, planlanan yörüngeyi yürütülenle karşılaştırın. Sapma otomatik olarak kötü değildir, ama ölçülmemiş sapma kötüdür. Agent sessizce plan değiştirirse, davranışı hakkında akıl yürütme yeteneğinizi kaybetmişsinizdir.
Bu ölçümler tek bir puan değildir. Bir profildir. Hızlı kurtarıp güvensiz sonlanan bir çalıştırma, daha uzun sürüp temiz sonlanandan daha kötüdür. Profil, bu ödünleşimi açıkça yapmanızı sağlar.
Somut bir mekanizma: hata enjeksiyon koşum takımı
Bunu tekrarlanabilir kılan mekanizma, agent ile araçları arasında oturan bir koşum takımıdır. Bir mock değildir. Canlı ya da kaydedilmiş araç yanıtlarına bir hata kümesi uygulayabilen bir proxy'dir.
class FaultInjector:
def __init__(self, faults, seed):
self.faults = faults
self.rng = random.Random(seed)
def wrap(self, tool):
def call(*args, **kwargs):
fault = self._select(tool.name)
if fault == "timeout":
raise ToolTimeout(tool.name)
if fault == "schema_drift":
return self._mutate_schema(tool(*args, **kwargs))
if fault == "partial":
return self._truncate(tool(*args, **kwargs))
Koşum takımı, enjekte edilen her hata için kurtarma süresini, tüketilen adımları, nihai durumu ve planlanan ile yürütülen yörüngeler arasındaki sapmayı kaydeder. Hata kümesi, agent ile birlikte sürümlenir. Bir prompt değiştiğinde ya da bir araç şeması değiştiğinde, hata kümesi yeniden çalıştırılır. Bir regresyon, daha önce temiz kurtarılan ve şimdi kurtarmayan bir hatadır.
## Tekrarlanabilir kılmak
Sürümlenmemiş bir hata kümesi tek seferlik bir testtir. Sürümlenmiş bir hata kümesi bir varlıktır.
Uygulama, hata kümesini agent'ın tanımının bir parçası olarak ele almaktır. Agent'ın prompt'u değiştiğinde hata kümesi çalışır. Bir aracın şeması değiştiğinde hata kümesi çalışır. Yeni bir production hatası keşfedildiğinde, bir postmortem paragrafı değil, hata kümesinde yeni bir fixture olur. Postmortem hâlâ vardır, ama çıktısı bir anlatı değil, tekrarlanabilir bir testtir.
Bu, dağıtım konuşmasının şeklini değiştirir. Agent'ın demoyu ele alıp almadığını sormak yerine soru, hangi hata sınıflarının enjekte edildiği, kurtarma profilinin nasıl göründüğü ve daha önce geçen herhangi bir hatanın şimdi başarısız olup olmadığı haline gelir. Bu, kanıta dayalı bir yanıtı olan bir sorudur.
Ödünleşim, hata kümesinin monoton olarak büyümesidir. Her production hatası bir fixture ekler ve paket yavaşlar. Bir noktada paketin katmanlara ayrılması gerekir: her prompt değişikliğinde çalışan hızlı bir alt küme ve dağıtımdan önce çalışan tam bir küme. Katmanlama kararı, hangi hataların tekrarlanma olasılığının en yüksek olduğuna dair bir yargıdır ve agent'ın ortamı değiştikçe yeniden gözden geçirilmelidir.
## Doğrulama sorusu
Soru, agent'ın bir trace'te iyi görünüp görünmediği değildir. Soru, bağımlı olduğu araç yanıt vermeyi durdurduğunda, elinde tuttuğu kimlik bilgisinin süresi dolduğunda ve taşıdığı context az önce okuduğuyla çeliştiğinde ne olduğudur. Bu hataları enjekte etmediyseniz, bilmiyorsunuz. Ettiyseyseniz, bir kurtarma profiliniz, bir fixture kümeniz ve temiz bir çalıştırma yerine kanıta dayanan bir dağıtım kararınız var.
Doğrulama okumak değildir. Enjekte etmektir.