Vaka aslında neyi gösteriyor
Philadelphia'dan bir haber raporu, otomatik bir sistemin veya ona güvenen bir operatörün, yanlış olduğu ortaya çıkan bir ihbarı iletmesini ve sonuçların, iddia kontrol edilemeden önce gerçek bir kişiye ve gerçek bir kuruma yansımasını anlatıyor. Atıf detayları, hatanın şeklinden daha az önemli. Agent kendisinden isteneni yaptı. Zarar, ön koşulları hiçbir zaman belirtilmemiş bir eylemden geldi: ihbar binadan çıkmadan önce hangi kanıt gerekiyordu, kaç bağımsız kaynak tarafından doğrulanmıştı, alıcı ihbar ulaştıktan sonra herhangi bir şeyi geri alabilir miydi.
Bu, her hafta tool-calling değerlendirmelerinde gördüğümüz aynı hata sınıfı. Her çağrı şema açısından geçerli. JSON ayrıştırılıyor, argümanlar tanımlı tiplerle eşleşiyor, taşıma katmanı 200 döndürüyor. Sonuç yine de yanlış çünkü geçerlilik, politikaya uygunluk değildir. Bir tool call biçimsel olarak doğru, bağlam açısından diskalifiye edici olabilir: yanlış alıcıya gönderilen bir mesaj, tek bir doğrulanmamış alana dayanarak güncellenen bir kayıt, görmezden gelemeyecek bir üçüncü tarafa iletilen bir bildirim.
Bunu bir halüsinasyon sorunu olarak çerçevelemek, işe yaramayacak bir model düzeltmesini davet eder. Model bir detay uydurduysa, daha iyi temellendirme istemek makul olabilir. Ancak Philadelphia örüntüsünde model, kendisine verileni tam olarak raporlamış olabilir. Boşluk üretimin üst tarafındaydı: sistemde hiçbir şey bu eylem izin verilmeden önce iki bağımsız kaynak gerektirir demiyordu. Hiçbir prompt, bir gereksinim olarak yazılmamış bir boşluğu kapatamaz.
Sonuç doğuran araçlar ön koşul gerektirir
Faydalı ayrım iyi ve kötü modeller arasında değil. Kurum içinde kalan araçlar ile üçüncü bir tarafa ulaşan araçlar arasında. Dahili bir indeks üzerinde retrieval çağrısını yanlış yapmak ucuzdur. Bir düzenleyiciye e-posta gönderen, rapor dosyalayan, adı belirli bir kişi hakkında iddia yayımlayan veya bir saha ekibi görevlendiren çağrı değildir.
İkinci kategorideki her araç için wrapper en az üç şeyi bildirmelidir.
- Gerekli kanıt. Çağrıya izin verilmeden önce hangi alanların mevcut ve null olmayan olması gerektiği ve her birinin hangi kökeni taşıması gerektiği. Tek bir yapılandırılmamış kaynağa sahip bir ihbar, bir kaynak, bir zaman damgası ve doğrulayıcı bir kayda sahip bir ihbarla aynı nesne değildir.
- Doğrulama sayısı. Kaç bağımsız kaynağın hemfikir olması gerektiği. Bağımsızlık zor kısımdır; aynı üst kaynaktan kopyalanan iki alan, iki şapka takan tek bir kaynaktır ve şema, sayının iddia edilmek yerine hesaplanması için köken grafiğini kodlamalıdır.
- Geri alınabilirlik sınıfı. Eylemin geri alınıp alınamayacağı ve kim tarafından alınabileceği. Dahili bir taslak göndermek geri alınabilir. Bir ihbarı harici bir ortağa göndermek geri alınamaz, çünkü alıcı onu çoktan okumuştur.
Geri alınamaz, üçüncü tarafı etkileyen eylemler, adı belirli bir insan sorumluyla ayrı bir onay yolu gerektirir. Genel bir kuyruk değil, paylaşılan bir posta kutusu değil: denetim kaydının onay anında kaydettiği belirli bir hesap verebilir rol. Onay, diğerleri gibi bir ön koşuldur ve aynı mekanizma tarafından değerlendirilir.
Ön koşul kontrolü prompt'ta değil, tool wrapper'da yer alır. Wrapper, modelin önerdiği çağrı ile yan etki arasında durur. Argümanları alır, bildirilen ön koşullara başvurur, bunları mevcut duruma göre değerlendirir ve ya çağrıya izin verir ya da yapılandırılmış bir ret döndürür. Kodda yaşadığı için model yükseltmelerinden, prompt yeniden yazımlarından ve yeni bir agent framework'ünün gelişinden sağ çıkar. İsteği sessizce yeniden yazmak yerine ret döndürdüğü için modele neden olduğu söylenebilir ve model farklı bir yol seçebilir; retin kendisi de bir kayıt haline gelir.
Prompt'lar bunu neden taşıyamaz
Talimatlar bağlam için yarışır. Görev çerçevelemesi, araç açıklamaları, biçimlendirme kuralları ve mevcut konuşmanın yanı sıra operasyonel politikayı da taşıyan bir system prompt, politikanın birçok ses arasından yalnızca bir ses olduğu bir system prompt'tur. Uzun ufuklarda bu ses daha yüksek çıkmaz; daha da uzaklaşır. Yirminci turda, bağlamın en üstüne yazılmış bir uyarı, modelin ağırlık verip vermeyebileceği bir olgudur ve dışarıdan hangisi olduğunu söylemenin yolu yoktur.
Kodda kontrol edilen bir ön koşul, gerekçeli bir ret üretir. Bu ret; zaman damgası, girdi, kural tanımlayıcısı ve sonucu olan ayrık bir olaydır. Sayılabilir, örneklenebilir ve yeniden oynatılabilir. Prompt düzeyindeki uyarı, sonradan inceleyebileceğiniz hiçbir şey üretmez. Bir ihbar gittiyse ve sistemin doğrulamayı düşünüp düşünmediğini bilmek istiyorsanız, prompt ile cevap bunu istedik olur. Wrapper ile cevap bir log satırıdır.
Burada dürüst bir ödünleşim var ve küçük değil. Kodda ön koşullar gecikme ve sürtünme ekler. Artık her sonuç doğuran çağrı bir değerlendirmeyi bekler ve bunların bir kısmı reddedilir ve bir insanın bakması gerekir. İlk haftalarda bu oran rahatsız edicidir, çünkü şema yerini aldığı gayriresmî süreçten daha katıdır. Ekipler bunu sistemin ayağına dolanması olarak hisseder ve kuralı gevşetme baskısı hemen gelir. Karşı baskı, gevşetilmiş bir ön koşulun başarısız olana kadar görünmez olması, katı olanın ise hemen görünür olmasıdır. Maliyet peşin ve görebileceğiniz bir yerde ödenir.
İkinci bir ödünleşim: ön koşullar ancak okudukları durum kadar iyidir. Doğrulama sayısı, üst sistemlerin tutarsız doldurduğu bir köken alanına bağlıysa, kontrol olmaması gereken şeylere geçit verir. Bu yüzden değerlendirme, gerçekte gördüğü girdilerle birlikte çağrının yanında loglanmalıdır. Bir ön koşulun yanlış olduğu ortaya çıktığında, log size kuralın mı kötü olduğunu yoksa onu besleyen verinin mi kötü olduğunu söyler.
Tasarım kuralı: sınıflandır, sonra iliştir
Pratik kural, araçları etki alanı ve geri alınabilirlik açısından sınıflandırmak, sonra ön koşulları tek tek prompt'lara değil sınıfa iliştirmektir. Bir aracın sınıfı, aracın bir özelliğidir; bir kez bildirilir, araç değiştiğinde gözden geçirilir. O araca ulaşabilen her agent, sınıfı ve ön koşullarını otomatik olarak devralır. Yeni agent'ların dikkatli olmayı öğrenmesi gerekmez; onlara bu niteliği zaten taşıyan araçlar verilmelidir.
Minimal bir bildirim şöyle görünür:
tool: submit_external_tip
blast_radius: third_party
reversibility: irreversible
preconditions:
- rule: evidence.required_fields
fields: [claim_text, source_id, source_timestamp]
- rule: corroboration.min_independent
count: 2
provenance_field: source_lineage
- rule: approval.named_principal
role: duty_editor
on_fail: refuse_with_reason
Wrapper her kuralı sırayla değerlendirir ve üç sonuçtan birini üretir: izin ver, gerekçeyle reddet veya adı belirli sorumluya yükselt. Değerlendirme kaydı, aynı trace içinde çağrının yanına yazılır, böylece karar aylar sonra yeniden kurulabilir: hangi kurallar çalıştı, hangi değerleri okudu, hangisi reddetti, onaylayan olduysa kim.
Bu gösterişsiz bir iştir. AI mühendisliğinden çok şema tasarımı ve erişim kontrolü gibi görünür, bu da atlanmasının nedenlerinden biridir. Ancak Philadelphia örüntüsü daha iyi bir modelle veya daha dikkatli bir prompt'la çözülmez. Ön koşulu araca iliştirilmiş birinci sınıf bir nesne yapmak, kodda değerlendirmek ve yönettiği eylemin yanında loglamakla çözülür. Agent'lar kendilerinden isteneni yapmaya devam edecek. Soru, kendilerinden istenenin kurumun gerçekten olmasına razı olduğu şeylerle sınırlanıp sınırlanmadığıdır.
Önce neyi enstrümante etmeli
Model değişikliğiyle değil, bir envanterle başlayın. Herhangi bir agent'ın çağırabileceği her aracı listeleyin. Her biri için üçüncü bir tarafa ulaşıp ulaşmadığını, geri alınıp alınamayacağını ve kurumun altı ay sonraki bir incelemede eylemi savunabilmesi için hangi kanıtın var olması gerektiğini kaydedin. Son sorunun net bir cevabı olmayan araçlar, bir sonraki olaydan sonra değil, bir sonraki dağıtımdan önce ön koşul gerektirenlerdir.
Sonra değerlendirmeyi trace'e bağlayın. Loglanmayan bir ret, hiç yapılmamış bir istekten ayırt edilemez; atfedilmeyen bir onay ise tek başına hareket eden bir agent'tan ayırt edilemez. Yukarıda bağlantılı iki haber raporu sonuçları anlatıyor; mühendislik yanıtı, bunları önleyecek ön koşulları açık, uygulanır ve okunabilir kılmaktır.