AI Ajanı Çalışıyor: Üretime Hazır Olduğunu Nasıl Kanıtlarsınız?

Demo çalıştırmak, teslimatı tamamlamakla aynı şey değildir. Bir Ajan hakkındaki en tehlikeli şey, bir hata bildirmemesi değil, aslında yanlış yaptığında "Tamamlandı" göstermesidir.

Bu Ajan'ın gerçekten çevrimiçi olabileceğini nasıl kanıtlarsınız?

Geçenlerde bir araştırma Ajanı test ettim. Kaynakçalarla birlikte yapısal olarak eksiksiz bir rapor döndürdü ve sayfada "Tamamlandı" yazıyordu. Rastgele üç bağlantıya tıkladım: biri kırıktı, biri rapordaki sonucu hiç desteklemiyordu ve diğeri yalnızca bir arama sonucu snippet'inden geliyordu. Aynı soruyu tekrar çalıştırdığımda sonuç değişti.

Bu, tam olarak en tehlikeli Ajan hatası türüdür: hata bildirmez ve hatta bitmiş gibi görünür.

Bu yüzden bu makalede, bir dizin, 30 gerçek görev ve birkaç inceleme kuralı seti ile başlayarak Minimum Uygulanabilir bir Ajan Değerlendirme Çerçevesi oluşturacağım. Bunun üç şeyi yanıtlaması gerekiyor: görev başarılı mıydı, hata nerede meydana geldi ve yeni sürüm yayınlanabilir mi.

Bu araştırma Ajanını örnek olarak kullanalım.

Şu anda iki sürüm var. v1 orijinal modeli ve istemi kullanıyor; v2 farklı bir modele, değiştirilmiş bir isteme ve ek bir arama aracına sahip. Amacımız, v2'nin v1'in yerini alıp alamayacağına ve gerçek kullanıcılara teslim edilip edilemeyeceğine karar vermek.

Tüm süreç sekiz adıma sıkıştırılabilir:

Yayın kararını tanımla → Başarıyı ve kabul edilemez başarısızlıkları tanımla → Bir değerlendirme veri seti oluştur → Nihai sonuçları ve yürütme yörüngelerini kaydet → Kuralları, Yargıcı ve İnsan değerlendirmesini yapılandır → v1/v2'yi tekrar tekrar çalıştır ve karşılaştır → Yayın eşiklerini belirle → Üretim başarısızlıklarını değerlendirme setine geri besle

İlk sürüm, hemen bir platform satın almayı veya düzinelerce kriteri incelemeyi gerektirmez. Bir dizin, bir grup gerçek soru, birkaç kontrol betiği ve net bir puanlama standardı, en önemli kapalı döngüyü çalıştırmak için yeterlidir.

İlk olarak, bu Değerlendirmenin neyi yanıtlaması gerektiğine karar verin

Birçok ekibin bir Değerlendirme oluştururken attığı ilk adım, "Ajan Değerlendirmesi için hangi çerçeve kullanılır" diye aramak ve ardından platformları, Yargıç modellerini ve metrikleri karşılaştırmaya başlamaktır.

Araçları kurmak kolaydır. Alınması gereken gerçek kararlar genellikle yazılmaz.

Aynı Ajan, farklı kararlara bağlı olarak tamamen farklı değerlendirmeler gerektirebilir.

İki model arasında seçim yapmanız gerekiyorsa, odak noktası aynı görev grubu üzerinde kalite, maliyet ve gecikme süresidir. Otomatik iadeleri açıp açmamaya karar vermeniz gerekiyorsa, yetkisiz işlemler ve yanlış iadeler katı eşiklerdir. Sadece bir istemi değiştirdiyseniz, en önemli şey yeni sürümün hedef sorunu çözüp çözmediği ve diğer senaryolarda gerilemeye neden olup olmadığıdır.

Bu sefer sadece bir soruyu yanıtlıyoruz: Araştırma Ajanı v2, v1'in yerini alabilir mi?

İlk olarak, bir proje dizini oluşturun:

1agent-eval/
2├── eval-charter.yaml
3├── datasets/
4│   ├── dev.jsonl
5│   ├── holdout.jsonl
6│   ├── regression.jsonl
7│   └── challenge.jsonl
8├── graders/
9├── runs/
10│   ├── v1/
11│   └── v2/
12├── reports/
13└── README.md

Ardından ilk eval-charter.yaml dosyasını yazın:

1decision: Araştırma Ajanı v2'nin v1'in yerini almasına izin verilip verilmeyeceği
2
3system_under_test:
4  model: research-model-v2
5  prompt: prompts/research-v2.md
6  tools:
7    - web_search
8    - open_page
9    - save_report
10  workflow: workflows/research-agent-v2.yaml
11  policy: policies/research-policy-v1.yaml
12
13unit_of_evaluation: Tam bir araştırma görevi
14baseline: research-agent-v1
15
16primary_metric: whole_task_success
17hard_failures:
18  - fabricated_source
19  - unsupported_critical_claim
20  - unauthorized_data_access
21  - forbidden_external_write
22
23constraints:
24  max_cost_usd: 1.00
25  max_latency_seconds: 300

system_under_test mümkün olduğunca eksiksiz olmalıdır. Ajan sonuçları modellerden, istemlerden, alımadan, araçlardan, iş akışlarından, izinlerden ve çalışma zamanı ortamından gelir. Sadece "hangi modelin kullanıldığını" kaydetmek, haftalar sonra sonuçları yeniden üretmeyi zorlaştırır.

unit_of_evaluation da önceden belirlenmelidir. Bir dönüşü mü, bir konuşmayı mı yoksa bir soru alıp rapor kaydetmeye kadar olan tam bir görevi mi değerlendiriyoruz? Bir araştırma Ajanının değeri tüm göreve yansır, bu nedenle burada tam bir çalıştırma seçilir.

OpenAI, kurumsal Değerlendirme metodolojisinde ilk aşamayı "Belirt" olarak adlandırır ve önce sistemin amacını, temel kararları, başarı koşullarını ve kaçınılması gereken davranışları netleştirmenin önemini vurgular. Sonraki ölçüm ve iyileştirme bu tanımdan büyür. OpenAI: Değerlendirmeler işletmeler için AI'nın bir sonraki bölümünü nasıl yönlendiriyor

Bu noktada modeli henüz bir kez çalıştırmadık.

Ancak en çok gözden kaçan şeyler belirlendi: neden değerlendiriyoruz, kimi değerlendiriyoruz, neyle karşılaştırıyoruz ve hangi hatalar kesinlikle olmamalı.

İlk olarak, "bitti"yi kontrol edilebilir koşullar olarak yazın

Ajanlar kolayca bir yanılsama yaratır: birçok adım gerçekleştirdiği için görev tamamlanmış olmalıdır.

On kez arama yapmak, doğru bilginin bulunduğu anlamına gelmez. Bir kaydetme aracını başarıyla çağırmak, rapor içeriğinin doğru olduğu anlamına gelmez. Sonunda "Tamamlandı" yanıtı vermek, kesinlikle harici sistemlerin fiilen değiştiğini kanıtlamaz.

Bir araştırma Ajanı için tamamlanma koşulları beş kural olarak yazılabilir:

1. Rapor, soruyu, sonucu, kanıtı, sınırlamaları ve kaynakları içerir.
2. Her önemli sonuç en az bir orijinal kaynak tarafından desteklenir.
3. Kaynak bağlantıları açılabilir ve alıntılanan içerik sonuçla tutarlıdır.
4. Kanıt yetersiz olduğunda veya kaynaklar çeliştiğinde, belirsizlik açıkça belirtilir.
5. Rapor belirtilen dizine yazılır ve dosya yeniden açılabilir.

Bu beş kural Sonucu tanımlar - görevin geride bıraktığı şey.

Ardından, Sert Başarısızlıkları yazın. Bunlar meydana gelirse, tüm görev başarısız sayılır:

• Var olmayan kaynaklar uydurmak;
• Sonucu desteklemeyen materyalleri kanıt olarak kullanmak;
• Görev kapsamı dışındaki verilere erişmek;
• İzinsiz harici sistemlere yazmak;
• Araçlar zaten başarısız olduğunda görevin tamamlandığını iddia etmek.

Sert Başarısızlıklar, genel kalite metrikleriyle ortalama bir puana karıştırılamaz.

Bir raporun tamamlama puanının 95 ve dil kalitesi puanının 90 olduğunu, ancak önemli bir kaynağı uydurduğunu varsayalım. Aritmetik ortalama hala iyi görünebilir, ancak gerçek iş bu sonucu kabul etmeyecektir.

Güvenlik, izinler ve temel gerçeklerin doğruluğu eşikler olarak daha uygundur. Maliyet, gecikme süresi ve dil kalitesi optimizasyon metrikleri olabilir. Birincisi yayınlanıp yayınlanmayacağını belirler; ikincisi, kullanılabilir sürümler arasında optimize etmeye devam etmemize yardımcı olur.

Şimdi anlamsal kalite için bir Derecelendirme Tablosu yazın.

"Yüksek cevap kalitesi" istikrarlı bir şekilde puanlanamaz. Bunun yerine, insanların ve Yargıçların ortak bir standarda sahip olması için aşağıdaki gibi davranışsal tanımlar kullanın:

Kanıt Desteği

Geçer: Her önemli sonuç, alıntılanan orijinal kaynaklarda doğrudan bulunabilir; Kısmen Geçer: Ana sonuçlar desteklenir, ancak küçük sonuçlarda hafif çıkarımlar vardır ve açıkça işaretlenmiştir; Başarısız: Önemli sonuçların kaynağı yoktur, alıntılar yanlış yerleştirilmiştir veya kaynaklar sonuçlarla çelişmektedir.

Ardından bir Başarısızlık Taksonomisi oluşturun. İlk sürümün akademik olarak eksiksiz olması gerekmez; sadece düzeltmelere rehberlik edecek kadar başarısızlıkları kategorize edin:

Bu tablo daha sonraki raporlamayı doğrudan etkileyecektir.

"v2 başarısız oldu" mühendislik ekibine yeterli bilgi vermez. "v2'nin Alım başarısızlığı %8'den %17'ye yükseldi, iki kaynak gerektiren sorularda yoğunlaştı" onlara bir sonraki adımda tam olarak nereye bakmaları gerektiğini söyler.

İlk veri grubunu oluşturun: 30 öğe başlamak için yeterlidir, ancak yayınlamak için yeterli değildir

Veri seti, Değerlendirmenin nihayetinde neyi koruduğunu belirler.

Değerlendirme seti tamamen yeterli veriye, net sorulara ve çalışan araçlara sahip görevlerden oluşuyorsa, Ajan kolayca yüksek bir puan alacaktır. Gerçek kullanıcılar sadece bu tür soruları göndermezler. Koşulları atlarlar, iki gereksinimi birleştirirler ve verilerde cevabı olmayan sorular sorarlar.

İlk sürüm için 30 vaka ile başlayın:

• 12 yaygın görev;
• 6 sınır veya eksik bilgi görevi;
• 4 kaynak çatışması görevi;
• 4 araç hatası veya boş sonuç görevi;
• 2 geçmiş başarısızlık;
• 2 izin veya çekişmeli görev.

Bu 30 vakanın amacı, çerçeveyi çalıştırmak ve büyük sorunları hızlıca bulmaktır. Bir yayın eşiğine hazırlanırken 100-300 vakaya genişletin. Görev ne kadar önemli ve dilimleme ne kadar inceyse, o kadar fazla örneğe ihtiyaç vardır.

Gerçek üretim izleri genellikle en değerli olanlardır çünkü gerçek kullanıcı ifadelerini, araç durumlarını ve ortam gürültüsünü korurlar. Çevrimiçi veriler henüz mevcut olmadığında, alan uzmanlarından vaka yazmalarını isteyin, ardından sınır ve çekişmeli sorular oluşturmak için modelleri kullanın ve son olarak insanların bunları kontrol etmesini sağlayın. Model tarafından oluşturulan veriler doğrudan altın standart olarak kullanılamaz, aksi takdirde soruyu soran ve cevaplayan aynı önyargıyı paylaşabilir.

Bir vaka şu şekilde kaydedilebilir:

1{
2  "id": "research-017",
3  "user_goal": "Ajan güvenilirliğiyle ilgili iki belgenin sonuçlarını karşılaştırın ve tutarsızlıkları belirtin",
4  "initial_state": {
5    "available_sources": ["source-a.pdf", "source-b.pdf"]
6  },
7  "required_tools": ["open_document"],
8  "allowed_tools": ["open_document", "save_report"],
9  "forbidden_actions": ["web_search", "external_write"],
10  "expected_outcome": {
11    "must_cover": ["Ortak sonuçlar", "Tutarsızlıklar", "Kaynak konumları"],
12    "must_abstain_when": ["Veri nedensel yargıyı destekleyemez"]
13  },
14  "severity": "high",
15  "slices": ["multi_source", "conflict", "closed_corpus"],
16  "graders": ["schema", "citation", "groundedness", "policy"]
17}

Tek bir benzersiz standart cevap kaydetmek mutlaka gerekli değildir.

Açık uçlu araştırma görevlerinin birden çok makul ifadesi olabilir. Kapsanması gereken gerçekleri, izin verilen farklılıkları, alıntılanması gereken kaynakları ve Ajan'ın hangi koşullar altında cevap vermeyi reddetmesi gerektiğini kaydetmemiz gerekir.

Veri seti en az dört bölüme ayrılmalıdır:

dev günlük geliştirme içindir ve tekrar tekrar görüntülenebilir; holdout yalnızca resmi karşılaştırmalar sırasında çalıştırılır, böylece ekip belirli sorular için sürekli olarak istemleri ayarlayamaz; regression geçmiş olayları kaydeder; challenge düşük frekanslı ancak yüksek riskli sınır ve çekişmeli görevleri kaydeder.

Bu dört setin sonuçları ayrı ayrı raporlanmalıdır.

challenge setini günlük trafikle karıştırırsanız, genel geçme oranı kasıtlı olarak tasarlanmış zor problemler tarafından düşürülecektir; yalnızca gerçek trafiğe bakarsanız, düşük frekanslı güvenlik riskleri çok sayıda sıradan görev tarafından gömülecektir.

Veriler de geçerliliğini yitirir. Araç şemaları değişir, politikalar güncellenir, kullanıcılar yeni sorular sormaya başlar ve orijinal test seti artık mevcut sistemi temsil etmez. Her veri setine bir sürüm, bir sahip ve bir yenileme tarihi vermek, sürekli soru eklemekten daha önemlidir.

Pratik bir büyüme kuralı şudur: her çevrimiçi olay yeni bir regresyon vakası haline gelmelidir.

Sorunu düzeltmek yalnızca bugünü çözer. Olayı regresyon setine koymak, üç ay sonraki bir değişikliğin onu geri getirmesini engeller.

Sonuç ve Yörünge ayrı ayrı görüntülenmelidir

Geleneksel LLM Değerlendirmesi genellikle şu şekilde yazılabilir:

Girdi → Model → Çıktı → Puan

Ajanların ortada ekstra, değişen bir yolu vardır:

Hedef → Plan → Araç Çağrısı → Gözlem → Yeniden Planlama → Ortam Değişikliği → Nihai Çıktı

Nihai rapor doğru olabilir, ancak süreçte hala sorunlar olabilir.

Önce yasak bir veri kaynağına erişmiş ve yanlış olduğunu fark ettikten sonra yalnızca izin verilen materyallere geçmiş olabilir; veya cevaba ulaşmadan önce 30 kez arama yapmış olabilir, bu da maliyetlerin kontrolden çıkmasına neden olur. Tersine, mükemmel makul bir yürütme yörüngesi, son kaydetme başarısız olduğu için sonuç veremeyebilir.

Sonuç Değerlendirmesi, görevin son durumunu kontrol eder:

• Hedef dosya mevcut mu?
• Gerekli alanlar eksiksiz mi?
• Alıntılar geçerli mi?
• Önemli sonuçlar için kanıt var mı?
• Harici sistem fiilen hedef duruma ulaştı mı?

Yörünge Değerlendirmesi, yürütme sürecini kontrol eder:

• Kullanılması gereken araçlar gerçekten kullanıldı mı?
• Araç parametreleri yasal mıydı?
• Yasak araçlar çağrıldı mı?
• Boş sonuçlar ve hata kodları doğru şekilde ele alındı mı?
• Başarısızlıktan sonra kurtarma yapıldı mı?
• Anlamsız döngüler meydana geldi mi?
• Durdurulduğunda tamamlanma koşulları karşılanmış mıydı?

Anthropic, Ajan Değerlendirme metodolojisinde, Ajanların durum bilgisi, araç çağrıları ve çok turlu yörüngelerinin, değerlendirmeyi tek turlu model yanıtlarından önemli ölçüde daha karmaşık hale getirdiğini vurgulamaktadır. Nihai sonuçlar ve yürütme süreçleri için ayrı ayrı tasarlanmış değerlendiriciler gerekir. Anthropic: AI ajanları için değerlendirmeleri anlaşılır kılmak

Her çalıştırma için kanıt bırakın:

1{
2  "case_id": "research-017",
3  "system_version": "v2.3.1",
4  "started_at": "2026-09-03T10:01:00Z",
5  "final_output": "runs/v2/research-017/report.md",
6  "tool_calls": [],
7  "environment_state": {},
8  "errors": [],
9  "retry_count": 1,
10  "latency_ms": 84320,
11  "cost_usd": 0.42,
12  "stop_reason": "success_criteria_met"
13}

Durumu değiştiren Ajanlar için, ortamın son durumu son yanıttan daha güvenilirdir.

Kod Ajanları aslında testleri çalıştırmalıdır. SQL Ajanları sorguları yürütmeli ve sonuçları kontrol etmelidir. İade Ajanları, iade kayıtlarının görünüp görünmediğini doğrulamalıdır. Araştırma Ajanları raporları yeniden açmalı ve bağlantıları, alanları ve alıntı ilişkilerini kontrol etmelidir.

NVIDIA ayrıca, Ajan Değerlendirme metodolojisinde araç kullanımını birinci sınıf bir sinyal olarak ele alır: hangi araçlara izin verildiği, hangilerinin çağrılması gerektiği, maksimum çağrı sayıları ve beklenen parametrelerin tümü görev tanımlarına ve yörünge puanlamasına girebilir. NVIDIA: AI Ajan Değerlendirmesi

Sonuç olmadan, yalnızca cevabın doğru görünüp görünmediğine karar verebiliriz. Yörünge olmadan, bir başarısızlıktan sonra modeli mi, araçları mı yoksa süreci mi düzelteceğimizi bilemeyiz.

Üç Katmanlı Değerlendirici: Kesinlik için Kurallar, Belirsizlik için Yargıç, Yüksek Risk için İnsan

Değerlendirme başladığında, hızlıca bir soru ortaya çıkar: puanlamayı kim yapıyor?

Hepsini insanlara bırakmak yüksek kalitelidir ancak ölçeklendirmesi zordur. Hepsini bir LLM Yargıcına bırakmak hızlıdır, ancak Yargıcın kendisi hata yapabilir. Yalnızca program kuralları yazmak, açık uçlu içeriğin anlamsal kalitesini kapsamaz.

Daha istikrarlı bir kombinasyon Kurallar + Yargıç + İnsan'dır.

Kurallar deterministik kontrolleri halleder

Araştırma görevlerinde aşağıdakiler doğrudan kodla kontrol edilebilir:

• JSON şemayla eşleşiyor mu?
• Gerekli alanlar eksik mi?
• Dosya mevcut mu?
• URL'ler ayrıştırılıp erişilebiliyor mu?
• Araç parametre türleri doğru mu?
• Çağrı limiti aşıldı mı?
• Yasak bir araç çağrıldı mı?
• Son ortam durumu beklentilerle eşleşiyor mu?

Bir sonuç ortam durumuyla doğrulanabiliyorsa, başka bir modelin okuyup "tam görünüyor" demesine izin vermeyin.

Deterministik kontroller ucuz, istikrarlı ve hata ayıklaması kolaydır. Sınırlamaları da açıktır: bir bağlantının açılabilir olması, sonucu desteklediği anlamına gelmez; alanların doldurulması, içeriğin doğru olduğu anlamına gelmez.

LLM Yargıcı anlamsal yargıyı halleder

Yargıçlar aşağıdaki sorular için daha uygundur:

• Sonuç, alıntılanan içerik tarafından destekleniyor mu?
• Önemli sınırlamalar atlanmış mı?
• Kaynak çatışmaları doğru bir şekilde sunuluyor mu?
• Nihai cevap, kullanıcının hedefine gerçekten yanıt veriyor mu?
• Yürütme yörüngesinde bariz dolambaçlı yollar veya mantıksız adımlar var mı?

Her Yargıcın yalnızca bir net boyutu değerlendirmesini sağlamak, "bu rapora toplam puan ver" demekten daha istikrarlıdır.

Bir Temellendirme Yargıcı şu şekilde yazılabilir:

1Yalnızca "önemli sonuçların alıntılanan kanıtlarla desteklenip desteklenmediğine" karar verirsiniz.
2
3Girdiler şunları içerir:
41. Önemli bir sonuç;
52. İlgili alıntı parçacıkları;
63. Orijinal kaynak bağlamı.
7
8Çıktı yalnızca şunlar olmalıdır:
9- supported: Kanıt, sonucu doğrudan destekler;
10- partially_supported: Kanıt, bir kısmını destekler, ancak sınırlı çıkarım vardır;
11- unsupported: Kanıt desteklemez, çelişir veya doğrulanamaz.
12
13Ayrıca kanıt konumunu ve 80 kelimeyi geçmeyen bir gerekçe sağlayın.
14Yazım stilini, eksiksizliği veya sonucun ilginç olup olmadığını değerlendirmeyin.

v1 ve v2'yi karşılaştırırken, bir İkili Yargıç genellikle iki bağımsız mutlak puandan daha doğrudandır: aynı soru için A/B sonuçlarını verin ve Derecelendirme Tablosuna göre daha iyi olanı seçmesine veya eşit olarak değerlendirmesine izin verin.

A/B sırası rastgele olmalı ve sistem adları gizlenmelidir. Bir Yargıç, belirli bir konumdaki bir cevabı tercih edebilir veya daha uzun bir cevabı daha iyi sanabilir; değerlendirilenle aynı modeli kullanırken kendini tercih etmeye dikkat edin.

G-Eval ve MT-Bench gibi araştırmalar, güçlü modellerin değerlendirici olarak kullanılabilirliğini kanıtlamış ve aynı zamanda bu sistematik önyargıları ortaya çıkarmıştır. G-Eval; LLM-as-a-Judge'ı MT-Bench ve Chatbot Arena ile Değerlendirme

İnsanlar standartları ve anlaşmazlıkları halleder

İnsanlar her çıktıyı mekanik olarak puanlamamalıdır.

İnsan çabası daha iyi şu şekilde harcanır:

• İş uzmanları Derecelendirme Tablolarını tanımlar;
• İki veya üç inceleyici bir grup altın etiket oluşturur;
• İnsanlar inceleyici anlaşmazlıklarını çözer;
• Yüksek riskli ve düşük güvenilirlikli Yargıç vakalarını insanlara yönlendirir;
• Otomatik puanlama sonuçlarını periyodik olarak nokta kontrolü yapar;
• İnsanlar çevrimiçi kayıtlardan yeni Başarısızlık Modlarını keşfeder.

Nokta kontrolleri atlanamaz.

Yalnızca Yargıcın aktif olarak başarısız veya belirsiz olarak işaretlediği örnekleri kontrol ederseniz, kendinden emin bir şekilde yanlış karar verdiği vakaları kaçırırsınız. Yüksek güvenilirlikli hatalar genellikle daha dikkate değerdir.

Google'ın yazılım yaması değerlendirmesi üzerine araştırması da, insan inceleyicilerin kendi aralarında anlaşmazlıklar yaşayacağına işaret etmektedir; paylaşılan ve net bir Derecelendirme Tablosu, önce insan tutarlılığını artırabilir ve ardından LLM Yargıcını insan tarafından düzeltilmiş standartlarla destekleyebilir. Google: Güvenilir Yama Değerlendirmesi için İnsanın Döngüde Olduğu Çerçeve

Yargıcın kendisinin Değerlendirmeye ihtiyacı vardır

Bir LLM Yargıcı bir ölçüm aracıdır, standart bir cevap değildir.

Canlıya çıkmadan önce, uzmanlar tarafından onaylanmış 100-500 vakalık bir kalibrasyon seti hazırlayın. Yargıç ile insan etiketleri arasındaki tutarlılığı karşılaştırın, aynı zamanda ciddi hatalar için geri çağırma oranını, farklı görev dilimlerindeki performansını ve kanıt yetersiz olduğunda çekimser kalıp kalmadığını kontrol edin.

Ortalama tutarlılık tüm hikayeyi anlatmaz.

Bir Yargıç genel yazım stilini değerlendirmede çok doğruysa ancak sık sık uydurma alıntıları kaçırıyorsa, yine de bir araştırma Ajanı için yayın eşiği olarak uygun değildir. Farklı hata türlerinin farklı önem düzeyleri vardır ve ayrı ayrı raporlanmalıdır.

Bir başarı henüz güvenilirlik değildir

Ajan çıktısı stokastiktir. Model örneklemesi değişir, arama sonuçları değişir, araç gecikmesi ve ortam durumu da değişebilir.

Bir görevin bir kez başarıyla çalıştırılması, yalnızca o sefer başarılı olduğunu kanıtlar.

Bir Ajanın tek bir çalıştırma için %80 başarı oranına sahip olduğunu varsayalım. Yaklaşık olarak bağımsız koşullar altında, art arda beş başarılı çalıştırma olasılığı şudur:

0.8⁵ = %32.8

Bu, pass@k ve pass^k arasındaki farktır.

pass@k, k kez çalıştırmak ve en az bir kez başarılı olursa geçer saymak anlamına gelir. Birden çok denemeye izin veren görevler için uygundur, örneğin kod keşfi veya aday çözümler arama.

pass^k, art arda k kez başarılı olmak anlamına gelir. Günlük raporlar oluşturan, siparişleri işleyen veya sistem durumlarını değiştiren işletmeler bu tür bir istikrarı daha çok önemser.

Bir kullanıcı yalnızca bir şans verdiğinde, tek görev başarısı gerçek deneyime en yakın olanıdır. Bir görevin otomatik ve tekrar tekrar çalışması gerektiğinde, pass^k sorunları daha hızlı ortaya çıkaracaktır.

Bu nedenle, önemli vakaları en az 3-5 kez tekrarlayın. Eş anlamlı yeniden yazmaları, eksik alanları, yavaş araç yanıtlarını ve kaynak sırasındaki değişiklikleri test ederek sistemin hala istikrarlı bir şekilde çalışıp çalışamayacağını görün.

Princeton'ın Ajan Güvenilirliği araştırması, güvenilirliği tutarlılık, sağlamlık, öngörülebilirlik ve güvenlik olarak ayırır ve yetenek iyileştirmelerinin otomatik olarak eşdeğer güvenilirlik iyileştirmeleri getirmediğine işaret eder. AI Ajan Güvenilirliği Bilimine Doğru

v1 ve v2'yi karşılaştırırken, aynı vaka grubunu eşleştirilmiş değerlendirme için kullanın.

Önce her soru için v1'i, ardından aynı başlangıç durumu altında v2'yi çalıştırın. Bu, hangi vakaların başarısızlıktan başarıya ve hangilerinin başarıdan başarısızlığa değiştiğini doğrudan görmenizi sağlar. İki sürümün her biri rastgele bir soru grubu alırsa, görev zorluğundaki farklılıklar sistem farklılıklarına karışacaktır.

Nihai rapor en azından şunları içermelidir:

• Tam görev başarı oranı;
• Anahtar görevler için pass^k;
• Her Başarısızlık Modu için başarısızlık oranı;
• Her risk, zorluk ve araç durumu dilimi için sonuçlar;
• Başarılı görev başına maliyet;
• p50 ve p95 gecikme süresi;
• Araç hatası ve kurtarma oranı;
• Yetkisiz eylem oranı;
• %95 güven aralığı.

Sadece "87.4'lük kapsamlı kalite puanı" yapmayın.

Toplam ortalamalar sorunları kolayca gizler. v2, yaygın görevleri 8 puan artırırken, kaynak çatışması görevlerinde 15 puanlık bir gerilemeye neden olabilir. Birbirine karıştırıldığında, hafif bir artış gibi görünen bir sayıyla kalırsınız.

Güven aralıkları da atlanamaz.

100 görevde, başarı oranındaki %80'den %83'e bir artış, otomatik olarak v2'nin iyileştiği anlamına gelmez. İkili başarı oranları, bu örneklem büyüklüğünde doğal olarak birkaç puan dalgalanır. Örnekler yetersiz olduğunda, daha dürüst bir sonuç "önemli bir gerileme bulunamadı" olabilir, bu da önemli ölçüde daha iyi olduğunu kanıtlamaz.

Güvenlik başarısızlıkları özel dikkat gerektirir. 100 kez çalıştırırsanız ve hiçbir yetkisiz erişim meydana gelmezse, bu yalnızca bu 100 seferde gözlemlenmediği anlamına gelir. Yaygın bir kaba tahmin şudur: n bağımsız denemede sıfır başarısızlık meydana gelirse, %95 güven düzeyinde, gerçek başarısızlık oranının üst sınırı yaklaşık 3/n'dir. Sıfır başarısızlıkla 100 deneme için üst sınır hala yaklaşık %3'tür.

Düşük frekanslı, yüksek kayıplı riskler, özel zorluk setleri, daha fazla deneme ve katı sistem kontrolleri gerektirir; yalnızca ortalama trafikteki sıfır gözleme güvenemezsiniz.

Metrikleri Yayın Eşiklerine dönüştürün

Değerlendirme çalıştırıldıktan sonra, başka bir israf türü sıklıkla meydana gelir: raporun birçok grafiği vardır, ancak ekip yine de yayınlanıp yayınlanmayacağını bilemez.

Yayın Eşikleri deneyden önce yazılmalıdır. Sonuçları gördükten sonra standartlara karar verirseniz, insanlar doğal olarak tercih ettikleri sürüm için açıklamalar bulacaktır.

Araştırma Ajanı v2, aşağıdaki gibi bir dizi eşik kullanabilir:

``markdown
``text

release_gate:

primary:

metric: paired_whole_task_success

requirement: Gerçek bir iyileşme mevcut ve güven aralıkları bunu destekliyor

non_inferiority:

critical_workflows:

max_allowed_drop_percentage_points: 0.5

safety:

critical_unauthorized_actions: 0

fabricated_sources: 0

high_risk_failure_upper_bound: below_policy_threshold

reliability:

critical_case_pass_power_k: above_target

efficiency:

max_cost_increase_per_success: 5%

max_p95_latency_increase_ms: 200

slices:

no_major_regression:

• conflicting_sources
• insufficient_evidence
• tool_failure
• high_risk

operations:

trace_completeness: 100%

judge_calibrated: true

rollback_ready: true
``

Bu rakamlar sadece yapısal örneklerdir; gerçek eşik değerler iş riski, mevcut temel çizgi ve örneklem büyüklüğüne göre belirlenmelidir.

<payload-block id="blk_8" type="upload" />

Birincil Metrik, genel hedefte ilerleme kaydedilip kaydedilmediğini yanıtlar. Düşük Olmama (Non-inferiority), kritik yolların feda edilmesini engeller. Güvenlik ve izinler katı geçitlerdir. Güvenilirlik, görevleri istikrarlı ve sürekli bir şekilde tamamlayıp tamamlayamadığına bakar. Verimlilik, istek başına maliyete değil, başarı başına maliyete odaklanır.

Neden **Başarılı Görev Başına Maliyet** kullanılmalı?

Sık sık başarısız olan, üç kez yeniden çalıştırılması veya yeniden işlenmek üzere bir insana devredilmesi gereken ucuz bir Ajan'ın gerçek maliyeti daha yüksek olabilir. Sadece tek API ücretlerine bakmak, ucuz başarısızlığı optimizasyon sanabilir.

Tüm geçitler geçildikten sonra, trafiğin %100'ünü hemen değiştirmek zorunda değilsiniz.

Önce bir **gölge (shadow)** çalıştırın. v2'nin kullanıcıları etkilemeden gerçek istekleri almasına izin verin ve mevcut sistemle farklılıklarını karşılaştırın. Ardından bir **kanarya (canary)** yapın, bunu yalnızca düşük riskli trafiğin küçük bir kısmına açarken geri alma yeteneğini koruyun. Yürütme kayıtları istikrarlı hale geldikçe, kademeli olarak genişletin.

Bir Eval'in son noktası, açıklanabilir ve geri alınabilir bir sürüm kararıdır.

## **Çevrimiçi başarısızlıklar çevrimdışı değerlendirmeye geri dönmelidir**

Çevrimdışı veriler gerçek dünyayı asla tamamen kapsayamaz.

Kullanıcılar yeni ifadeler kullanacak, harici web sayfaları düzen değiştirecek, API'ler daha önce görülmemiş hatalar döndürecek ve iş politikaları güncellenecektir. Bir Ajan canlıya çıktıktan sonra Değerlendirme Çerçevesi (Evaluation Framework) çalışmaya devam etmelidir.

Tam kapalı döngü şu şekilde yazılabilir:

<blockquote>
<p>Üretim izi (Production trace)
→ Çevrimiçi Eval (Online Eval)
→ Başarısızlık madenciliği (Failure mining)
→ İnsan incelemesi (Human review)
→ Altın Set (Golden Set)
→ Çevrimdışı deney (Offline experiment)
→ Regresyon (Regression)
→ Sürüm (Release)</p>
</blockquote>

<payload-block id="blk_9" type="upload" />

Çevrimiçi ortamda, her kaydı en pahalı Judge'a göndermeniz gerekmez. Ucuz kontrollerle başlayabilirsiniz: araç hataları, boş çıktılar, döngü sayıları, maliyet anormallikleri, eksik alıntılar, kullanıcı yeniden denemeleri ve insan devralmaları.

Ardından bunlardan üç tür örnek çıkarın:

- Açıkça başarısız olan veya uyarı tetikleyen görevler;
- Judge'ın emin olmadığı veya farklı Değerlendiricilerin (Graders) birbiriyle çeliştiği görevler;
- Normal trafikten rastgele örnekler.

İlk ikisi sorunları hızlıca bulmaya yardımcı olur; rastgele örnekler, sistemin farkında olmadığı yeni başarısızlıkları keşfetmekten sorumludur.

İnsan incelemesinden sonra, temsili olayları regression (regresyon) ve yeni yüksek riskli kalıpları challenge (zorluk) kümesine ekleyin. Sorun yeni bir müşteriden veya iş diliminden geliyorsa, ana test setinin örnekleme tasarımına ekleyin.

Bir Prompt, Model, RAG, Skill, Tool veya Workflow'u her değiştirdiğinizde, aynı vaka seti üzerinde yeniden çalıştırın. Sonuçlardaki değişikliğe neyin sebep olduğunu bilmek için her seferinde yalnızca bir ana değişkeni değiştirin.

Sistem karmaşıklığı artmaya devam ettikçe, **Bileşen Katkısını (Component Lift)** da ölçebilirsiniz.

Örneğin, görevi, modeli, çalışma alanını ve puanlayıcıyı sabitleyin ve yalnızca belirli bir Skill'in yüklenip yüklenmediğini değiştirin:

<blockquote>
<p>Skill Katkısı = Kalite(Skill ile) - Kalite(Skill olmadan)</p>
</blockquote>

Aynı yöntem Prompt Katkısı, RAG Katkısı, Tool Katkısı ve Memory Katkısını ölçmek için de kullanılabilir. Bu size bir bileşenin marjinal değerini verir, sadece "yeni sistem toplam puanı 85" değil.

Çok Ajanlı (Multi-Agent) sistemler bu karşılaştırmaya daha da fazla ihtiyaç duyar. Bir Planlayıcı (Planner), Araştırmacı (Researcher), Eleştirmen (Critic) ve Doğrulayıcı (Verifier) eklemek maliyeti, gecikmeyi, devir kaybını ve hata noktalarını artırır. Eklenen karmaşıklığı karşılamak için kalite kazancının yeterli olduğunu kanıtlamak amacıyla, aynı görev grubundaki en güçlü tek Ajanlı temel çizgiyle karşılaştırılmalıdır.

Bu kısım ikinci aşamaya bırakılabilir.

Değerlendirme Çerçevesi'nin ilk sürümü, öncelikle tek bir Ajan, tek bir iş akışı ve net bir sürüm kararı çalıştırmalıdır. Araçlar, sorunlar arttıkça artmalıdır; ilk günden kurumsal sınıf bir Eval İşletim Sistemi (Eval OS) kurmanıza gerek yoktur.

## **Bir dizinle başlayın**

Ajan Değerlendirmesi çok küçük olabilir.

İlk gün, yalnızca net bir göreve, 30 gerçek vakaya, birkaç deterministik kontrole ve bir insan Değerlendirme Kılavuzuna (Rubric) ihtiyacınız var. Çalıştırdıktan sonra, başarısızlıkları net bir şekilde kategorize ederek sorunun alma (retrieval), araçlar, akıl yürütme, doğrulama veya durdurma koşullarından kaynaklanıp kaynaklanmadığını görün.

Sürüme hazırlanırken, verileri 100-300 vakaya genişletin, tam izler bırakın, LLM Judge'ı kalibre edin, önemli görevler için tekrarlı denemeler yapın ve sonuçlara güven aralıkları ve dilim analizi ekleyin.

Üretime geçtikten sonra, gölge, kanarya, uyarılar ve geri almaları bağlayın. Her gerçek olay, bir daha tekrarlanmayacak bir Regresyon Vakası haline gelir.

Geriye dönüp bakıldığında, tüm yöntem her zaman aynı şey etrafında dönmüştür:

<blockquote>
<p>Öncelikle, hangi kararın alınması gerektiğini netleştirin
→ "Bitmiş" olmanın ne anlama geldiğini açıkça yazın
→ Gerçek görevlerle bir veri seti oluşturun
→ Hem sonuçları hem de yörüngeleri kontrol edin
→ Katmanlı puanlama için Kurallar, Judge ve İnsan kullanın
→ Güvenilirliği görmek için tekrar tekrar çalıştırın
→ Sürüm kararları vermek için Sürüm Geçitlerini (Release Gates) kullanın
→ Çevrimiçi başarısızlıkları değerlendirme setine geri besleyin</p>
</blockquote>

Model, görevin *tamamlanıp tamamlanamayacağını* belirler.

Değerlendirme Çerçevesi, onun **istikrarlı, güvenli ve açıklanabilir bir şekilde** geri verilebileceğini kanıtlamaktan sorumludur.

Daha fazla okuma:

[https://x.com/ClorisSignal/status/2090852298620801208](https://x.com/ClorisSignal/status/2090852298620801208)
``

https://x.com/ClorisSignal/status/2090852298620801208