Üretimde Yapay Zeka Ajanları Nasıl Değerlendirilir: Canlı İzlerde Kullandığımız 3 Katmanlı Sistem

Üretimde Yapay Zeka Ajanları Nasıl Değerlendirilir: Canlı İzlerde Kullandığımız 3 Katmanlı Sistem

Üretimde yapay zeka ajanlarını değerlendirmek, ajanın çok adımlı tüm yörüngesini, yalnızca nihai yanıtını değil, canlı trafik üzerinde puanlamak demektir: her akıl yürütme adımını kontrol etmek, doğru araçları doğru argümanlarla çağırdığını doğrulamak ve yayından sonra görev başarısını, maliyeti ve güvenliği sürekli izlemek. Çünkü ajanlar sessizce ve deterministik olmayan bir şekilde başarısız olur.

2026 Haziran'ında kendi Techsy içerik pipeline'ımızın bir çalıştırmasında, ajan kusursuz görünen bir blog yazısı teslim etti ve nihai çıktı puanı bunu geçirdi. Temizdi. Ama üç adım geriye gidince brief-creator yanlış internal-link lookup aracını çağırmıştı, bu yüzden küme bağlantılarının yarısı hiçbir yere gitmiyordu. Üretimde yapay zeka ajanlarını nasıl değerlendireceğinizi bilmek, ajanın rastgele ulaştığı yanıtı değil, izlediği tüm yolu puanlamak demektir.

Temel çıkarımlar:

• Sadece nihai yanıtı değil, tüm yörüngeyi puanlayın: yanlış yoldan geçen doğru bir yanıt yine de başarısızdır.
• Araç çağrılarını üç eksende doğrulayın: doğru araç, doğru argümanlar, doğru adım.
• Aynı metrikleri hem çevrimdışı hem çevrimiçi olarak, canlı üretim izlerinde, sürekli bir döngüde çalıştırın.
• Dağıtımları yalnızca düşük doğruluk puanlarına değil, güvenlik açıklarına (jailbreak, PII, araç kötüye kullanımı) göre de kapıdan geçirin.

Üretimde Yapay Zeka Ajanlarını Değerlendirmek, LLM Değerlendirmesinden Neden Farklıdır?

Üretimde yapay zeka ajanlarını değerlendirmek, model değerlendirmesinden daha zordur; çünkü bir ajan birden fazla adım atar, dış araçları çağırır ve gerçek durumu değiştirir, ve bunların hepsini deterministik olmayan bir şekilde yapar. Aynı girdi, her çalıştırmada farklı bir araç çağrısı sırası üretebilir; bu yüzden erken bir yanlış adım, sonrasındaki her adımı bozabilir.

Bu rehber, genel LLM değerlendirmesini zaten bildiğinizi varsayıyor. Bilmiyorsanız önce eksiksiz LLM değerlendirme rehberimize bakın, ardından model bir ajana dönüştüğünde nelerin değiştiğini öğrenmek için buraya geri dönün. (Değerlendirmeye hazırlandığınız ajanları henüz mi kuruyorsunuz? En iyi yapay zeka ajan framework'leri derlememiz altındaki katmanı kapsıyor.)

Bir LLM kendi başına hareket etmeye başladığı anda dört şey bozulur:

• Çok adımlı. Bir destek ajanı bir bilgi tabanında arama yapabilir, bir sipariş API'sini çağırabilir, sonra bir yanıt taslağı hazırlayabilir. Yalnızca yanıtı puanlarsanız, onu belirleyen iki adıma karşı kördesiniz.
• Deterministik değil. Sıcaklık (temperature) ayarı, model ağırlığı güncellemeleri ve araç gecikmesi, aynı isteğin her çalıştırmada farklı bir yol izlemesine yol açar. Değerlendirmenizin hareketli bir hedefe karşı ayakta kalması gerekir.
• Durumsal (stateful). Ajanlar veritabanlarına yazar, e-posta gönderir, sipariş iadesi yapar. Yanlış bir eylem kötü bir cümle değildir; geri alamayacağınız bir yan etkidir.
• Katlanarak büyüyen hatalar. 12 adımlık bir çalıştırmada hafifçe yanlış giden 2. adım, sonrasındaki her şeyi zehirler ve nihai yanıt yine de sorunsuz görünebilir.

Galileo'nun Şubat 2026 tarihli State of Eval Engineering raporu, 500'den fazla uygulayıcıyı anketleyerek ekiplerin %84,9'unun yayına aldıktan sonraki altı ay içinde bir yapay zeka olayıyla karşılaştığını buldu. Anthropic'in mühendislik ekibi ajan değerlendirmeleri üzerine denemesinde bunu açıkça ortaya koyuyor: ajanlar yalnızca nihai çıktıda değil, adımlar, araçlar ve niyet genelinde başarısız olur.

Yanlış bir yörüngeden geçerek doğru yanıta ulaşan bir ajan geçmiş sayılmaz. Sessizce başarısız olmuştur ve şanslı kurtarma bir dahaki sefere gerçekleşmediğinde yüksek sesle başarısız olacaktır.

Üretimdeki Yapay Zeka Ajanları İçin Gerçekten Önemli Olan Metrikler Nelerdir?

Üretimdeki ajanlar için en çok önem taşıyan metrikler doğruluğun ötesine geçer: görev başarı oranı, başarılı görev başına maliyet, gecikme yüzdelik dilimleri, araç çağrısı doğruluğu, doğruluk/temellendirme, insan müdahale oranı, sapma (drift) ve güvenlik kapısını geçme oranı. Bu yapay zeka ajan değerlendirme metrikleri birlikte, tek bir çıktı puanının kaçırdığı sessiz, deterministik olmayan başarısızlıkları yakalar.

Kendi çalıştırmalarımızda gerçekten izlediğimiz sekiz metrik bunlar. Bunlardan kaçının nihai yanıtın iyi okunup okunmadığıyla ilgilendiğine dikkat edin:

Bunların çoğu bir LLM-as-a-judge'a (bir modelin başka bir modelin çıktısını puanlaması) dayanır. Bu standart bir numaradır ve ölçeklenir, ama gürültülüdür: hakem model genellikle ajanla aynı kör noktaları paylaşır, bu yüzden puanlarını kesin gerçek değil, sinyal olarak ele alın. Hakem modeli kalibre etmeye yedinci bölümde geri döneceğiz.

Bir metrik özellikle öne çıkmayı hak ediyor. Başarılı görev başına maliyet, bir bütçe incelemesinden sağ çıkan sayıdır. Düz görev başına maliyet, ucuz başarısızlıkları ödüllendirir; çünkü hızlı ve yanlış vazgeçen bir ajan, tablo üzerinde verimli görünür.

Bir Ajanın Yörüngesini, Nihai Yanıtı Yerine Nasıl Puanlarsınız?

Bir ajanın yörüngesini puanlamak için izi değerlendirirsiniz: ajanın ürettiği her akıl yürütme adımının, araç çağrısının ve ara çıktının sıralı kaydı. Yayılım düzeyinde (span-level) değerlendirme, yalnızca genel çalıştırmanın ters gittiğini öğrenmek yerine, tam olarak hangi adımın (yayılımın) başarısız olduğunu belirleyebilmeniz için her bir adımı ayrı ayrı puanlar.

İzi, akıl yürütme için bir stack trace gibi düşünün. Her yayılım (span) bir adımdır: bir geri alma (retrieval), bir araç çağrısı, bir alt-ajana devir. Gözlemlenebilirlik bu yayılımları yakalar; değerlendirme ise onları puanlar. (Henüz izleme kurmadınız mı? Yapay zeka gözlemlenebilirlik rehberimiz puanlamanın üzerine oturduğu izleme katmanını kapsıyor, LangGraph, CrewAI ve OpenAI Agents SDK karşılaştırmamız ise her birinde bir izin nasıl göründüğünü gösteriyor.)

Neden yalnızca uç noktayı değil, her yayılımı puanlamalısınız? Katlanan hatalar yüzünden. 2. adım yanlış belgeyi getirirse, 3'ten 12'ye kadar olan adımlar çöp üzerine inşa edilir ve şanslı bir nihai ifade yine de yalnızca çıktıya bakan bir kontrolden sıyrılabilir. Yayılım düzeyinde puanlama, çalıştırmanın yalnızca bir yerde değil, tam olarak 2. adımda başarısız olduğunu size söyler.

Önce framework'ten bağımsız versiyonu (bir iz nesnesi üzerinde düz bir assertion) görelim, ardından DeepEval'ın iz tabanlı Task Completion metriğini kullanan kısayolunu:

# Framework'ten bağımsız: yörünge geçerli adımlarla hedefe ulaştı mı?
def score_trace(trace):
    assert trace.steps[-1].status == "success", "final step failed"
    assert all(s.error is None for s in trace.steps), "a mid-run step errored"
    assert "internal_link_lookup" in [s.tool for s in trace.steps], "skipped a required step"

# DeepEval: görev tamamlama için tüm çok adımlı izi puanla
from deepeval.tracing import observe
from deepeval.metrics import TaskCompletionMetric

@observe(metrics=[TaskCompletionMetric(threshold=0.7, model="gpt-4o")])
def content_pipeline(topic):
    ...  # sizin researcher -> brief -> writer -> validator çalıştırmanız
    return final_post

Framework'ten bağımsız assert, katı, deterministik kontroller için gayet yeterlidir. Task Completion ise başarı bir eşitlik kontrolünden daha bulanık olduğunda başvurduğunuz şeydir: izden hedeflenen görevi ve ulaşılan sonucu çıkarır ve bunların ne kadar örtüştüğünü puanlar.

Bir Ajanın Doğru Aracı Çağırdığını Nasıl Doğrularsınız?

Bir ajanın araç çağrılarını doğrulamak için üç şeyi ayrı ayrı kontrol edin: araç seçimi (doğru aracı seçti mi), argüman doğruluğu (doğru parametreleri ve değerleri geçirdi mi) ve yürütme yolu geçerliliği (o aracı doğru adımda, doğru sırayla çağırdı mı). Yanlış bir araç çağrısıyla birlikte geçen bir nihai yanıt, henüz yüzeye çıkmamış bir hatadır.

Bu, ajana en özgü tek değerlendirmedir ve neredeyse kimsenin derinlemesine ele almadığı bir konudur. Çoklu ajan araç kullanımı değerlendirmesi üç soruya ayrılır:

1. Seçim. Mevcut araçlar arasından ajan doğru olanı seçti mi? Herhangi bir aracı çağırmak, doğru olanı çağırmakla aynı şey değildir.
2. Argümanlar. Doğru parametreleri geçirdi mi? Yanlış bir slug veya hatalı biçimlendirilmiş bir tarihle doğru araç bile yine de başarısızlıktır.
3. Yürütme yolu. O aracı doğru adımda, doğru sırayla çağırdı mı? Siparişi doğrulamadan önce iade yapmak, doğru araçların yanlış sırada kullanılmasıdır.

DeepEval'ın Tool Correctness metriği üçünü de ele alır: tools_called'ı expected_tools'a karşı karşılaştırır, girdi parametrelerinde eşleşme yapabilir ve should_consider_ordering=True ile sırayı da puanlar.

# Framework'ten bağımsız: doğru araç, doğru argümanlar, doğru adım
call = trace.steps[2].tool_call
assert call.name == "internal_link_lookup", f"wrong tool: {call.name}"
assert call.args == {"slug": "llm-evals-guide"}, f"wrong args: {call.args}"

# DeepEval: araç seçimini + argümanları puanla, sıraya duyarlı
from deepeval.test_case import LLMTestCase, ToolCall, ToolCallParams
from deepeval.metrics import ToolCorrectnessMetric

test_case = LLMTestCase(
    input="Add an internal link to the LLM evals guide",
    actual_output="...",
    tools_called=[ToolCall(name="sitemap_search")],
    expected_tools=[ToolCall(name="internal_link_lookup")],
)
metric = ToolCorrectnessMetric(
    evaluation_params=[ToolCallParams.INPUT_PARAMETERS],
    should_consider_ordering=True,
)
metric.measure(test_case)
print(metric.score, metric.reason)  # 0.0  "expected tool not called"

İşte o 0.0, kendi pipeline'ımızda yakaladığımız tam olarak o hatadır: beklenen araç internal_link_lookup iken ajan sitemap_search'e uzanmıştı. Bitmiş yazı yine de çıktı puanını geçti. Bozuk yolu işaretleyen tek şey araç çağrısı metriğiydi.

Değerlendirmeleri Çevrimiçi Olarak, Canlı Üretim İzlerinde Nasıl Çalıştırırsınız?

Çevrimiçi değerlendirme, metriklerinizi yalnızca dağıtım öncesi bir test kümesine karşı değil, gerçek zamanlı olarak canlı üretim izlerine karşı çalıştırır. Bu, üç katmanlı bir sistemin üçüncü katmanıdır: altın bir küme üzerinde çevrimdışı testler, dağıtım öncesi bir QA kapısı, ardından canlı trafik üzerinde çevrimiçi değerlendirmeler; üretim izleri, döngü gelişmeye devam etsin diye veri setlerine geri derlenir.

Çevrimdışı testler, gerilemeleri yayına çıkmadan önce yakalar. Ama ajanlar üretimde hiçbir altın kümenin öngörmediği girdilerle karşılaşır, bu yüzden aynı metriklerin yayından sonra da çalışmaya devam etmesi gerekir. En üstteki diyagramın haritaladığı tüm döngü şöyle:

1. Çevrimdışı. Metriklerinizi CI içinde altın bir veri seti üzerinde çalıştırın. Bir gerilemede build'i başarısız kılın.
2. Dağıtım öncesi QA kapısı. İnsan sahipliğindeki bir kontrol noktası: bu, hem doğruluk barajını hem de güvenlik barajını (altıncı bölüm) geçiyor mu?
3. Çevrimiçi. Aynı metriklerle canlı üretim izlerini gerçek zamanlı olarak puanlayın.
4. Derleme. Gerçek izleri (özellikle başarısızlıkları) otomatik olarak toplayıp değerlendirme veri setlerinize geri ekleyin.
5. Yeniden çalıştırma. Altın kümeniz, ilk gün elle yazdığınız 20 örnek yerine gerçeklikten büyür.

Bir çevrimiçi değerlendirmeyi bağlamak, izlemeyle aynı enstrümantasyon artı bir metrik koleksiyonudur. Confident AI, DeepEval'ın 50'den fazla puanlayıcısını canlı izlere karşı çalıştırır ve OpenTelemetry uyumludur; bu yüzden LangGraph, CrewAI, OpenAI ve Vercel AI SDK özel adaptör gerektirmeden dışa aktarır:

# Geliştirmede çalıştırdığınız aynı metrikler, şimdi canlı üretim trafiğini puanlıyor
from deepeval.tracing import observe, update_current_span
from deepeval.test_case import LLMTestCase

@observe(metric_collection="Production Agent Quality")
def support_agent(query: str) -> str:
    answer = run_agent(query)  # canlı ajanınız
    update_current_span(
        test_case=LLMTestCase(input=query, actual_output=answer)
    )
    return answer
# Koleksiyonun metrikleri artık her izde, gerçek zamanlı olarak çalışıyor.

Asıl kazanç, derleme adımındadır. Her gerçek üretim başarısızlığı kalıcı bir regresyon testine dönüşür; böylece test paketiniz statik bir anlık görüntü olmaktan çıkar ve ajanınızın gerçek dünyada gerçekten neyle karşılaştığını takip etmeye başlar.

Sadece Doğruluğu Değil, Güvenliği de Kapıdan Geçirin

Bir güvenlik kapısı, yalnızca düşük bir doğruluk puanında değil, bir güvenlik açığında da dağıtımı engeller. Ajanlar için bu, jailbreak'leri, araç kötüye kullanımını ve PII sızıntısını arayan, hem dağıtım öncesi hem de çevrimiçi çalıştırılan adversarial ve kırmızı takım değerlendirmeleri anlamına gelir. Bir jailbreak, ortalamayla eritip geçebileceğiniz düşük bir puan değildir. Bir sürüm engelleyicisidir.

Her rakip, güvenliği birçok metrikten biri olarak ele alır. Bu, gerçek bir sisteme karşı gerçek bir aracı çağırmaya ikna edilebilen ajanlar için tersine işler. Bu yüzden kapıları ayırın: bir doğruluk kapısı puanların ortalamasını alır; bir güvenlik kapısı ise herhangi bir adversarial denemenin geçip geçmediğine göre geçti/kaldı şeklinde çalışır. Ajanınızın başarısızlık modlarını, denetçilerin zaten tanıdığı çerçevelere eşlemekle başlayın:

Sonra bu kategorilere karşı adversarial değerlendirmeler çalıştırın. LLM Uygulamaları için OWASP'ın İlk 10 Listesi, NIST Yapay Zeka Risk Yönetimi Çerçevesi ve MITRE ATLAS size ortak bir kelime dağarcığı verir; kırmızı takım tatbikatı ise size testi verir. DeepEval'ın arkasındaki aynı ekibin açık kaynak kırmızı takım çerçevesi olan DeepTeam, her biri OWASP, NIST AI RMF ve MITRE ATLAS'a eşlenmiş, 8 kategoride ve 20'den fazla saldırı vektöründe 120'den fazla güvenlik açığı sunar.

Araçlar konusunda dürüst bir nüans: DeepTeam OSS ücretsiz yoldur ve güvenlik açığı setini kapsar; Confident AI'daki yönetilen, platform içi kırmızı takım modülü ise bir Enterprise katmanı özelliğidir, $9.99'luk Starter planının içinde gelmez. Ne olursa olsun, kırmızı takım tatbikatını yayından önce bir kez çalıştırdığınız, sonradan akla gelen bir şey olarak değil, birinci sınıf bir kapı olarak kurun.

Bunu Kendi Pipeline'ımızda Çalıştırırken Neyi Yakaladık

Bu üç katmanlı sistemi kendi çoklu ajan içerik pipeline'ımızda çalıştırıyoruz: dört ajan (researcher, brief-creator, content-writer, validator) işi bir zincir boyunca birbirine devrediyor. 2026 Haziran ve Temmuz ayları boyunca DeepEval v4.0.5'i bu pipeline'a, Confident AI çalışma alanımıza karşı bağlamamız, girişte anlattığımız hatayı tam da böyle yakalamamızı sağladı. Puanlayıcı çıktısı şöyle görünüyordu:

ToolCorrectnessMetric  score=0.00  threshold=0.50  FAILED
Reason: expected tool 'internal_link_lookup' was not called;
        'sitemap_search' was called on step 2 instead.

Yazı, çıktı kalitesi puanını çoktan geçmişti. Bitmiş makalede yanlış görünen hiçbir şey yoktu. Bozuk adımı yalnızca yörünge değerlendirmesi gördü, tam olarak yalnızca çıktıya bakan bir kontrolün gözden kaçırdığı hata sınıfı.

r/LLMDevs, r/MachineLearning veya r/LocalLLaMA'da uygulayıcıları takip ediyorsanız, sürekli aynı bir avuç şikayetin gündeme geldiğini ve bunların üç katmanlı sistemin yakalamak üzere tasarlandığı şeylerle neredeyse birebir örtüştüğünü görürsünüz:

• Pazartesi-çalışıp-Çarşamba-bozulan problemi. Deterministik olmama, aynı girdinin her çalıştırmada farklı bir yol izlemesine yol açar; bu yüzden ekipler kararsız (flaky) değerlendirmeleri görmezden gelmeyi öğrenir. Canlı izlerde yayılım düzeyinde puanlama, daha büyük bir altın kümeyi geride bırakır.
• Altın veri seti yorgunluğu. Tek bir akıl yürütme değişikliğinin geçersiz kıldığı bir test paketini elle etiketlemek için haftalar harcamak. Üretim izlerini otomatik derlemek, statik bir dosyayı elle bakımını yapmaktan daha iyidir.
• LLM hakemine güvensizlik. Tekrarlayan şikayet, hakemin ajanla aynı kör noktaları paylaştığıdır; bu da ekiplerin döngüde bir insanı neden tuttuğunun tam sebebidir.

Bu son nokta önemli olandır. Alan uzmanları, hakemin emin olamadığı çıktıları etiketler ve bu etiketler metrik uyumuna geri beslenir. Bu, Confident AI incelememizde anlattığımız ve ajan belleğini nasıl ele aldığımıza komşu olan aynı kapalı döngüdür. Hakem ölçeklenir; insanlar onu dürüst tutar.

Hangi Platform Sizin Yığınınıza Uyuyor?

Tek bir araç her ekip için doğru değildir, bu yüzden platformu bulunduğunuz noktaya uydurun. İşte bu rehberin dayandığı beş yetenek üzerinden ana seçeneklerin nasıl karşılaştırıldığı ve kapıdan nasıl gireceğiniz:

Kurumsal ve ekipler arası kullanım senaryosunda zirvede Confident AI yer alıyor. Tüm kalite yaşam döngüsünü tek bir yerde kapsıyor (geliştirme zamanı değerlendirmeleri, üretim gözlemlenebilirliği, DeepTeam üzerinden adversarial güvenlik, organizasyon genelinde bir kalite kapısı) ve gerçek farkı kodsuz ekip erişimi: mühendisler bir kez kurar, sonra PM'ler, QA ve alan uzmanları tam değerlendirme döngülerini kendileri çalıştırır. Giriş fiyatı, ücretsiz bir katmanla birlikte $9.99/kullanıcı/ay. LLM değerlendirme araçları derlememizde 1. sırada ve yapay zeka gözlemlenebilirlik platformları karşılaştırmamızda 2. sırada; bir listenin zirvesine çıkması bizim için bu ilk sefer değil.

Ayrı konumlandırılan ise DeepEval: aynı ekip tarafından geliştirilen, 50'den fazla puanlayıcıya ve pytest-native test desteğine sahip, önde gelen açık kaynak çerçeve. Confident AI platform; DeepEval ise onun kısaltılmış bir sürümü değil, OSS kütüphanesidir. Şunlardan birini istiyorsanız bunu seçin:

• DeepEval: açık kaynak standardını istiyorsanız ve Python ile pytest'te yaşıyorsanız.
• Langfuse: kendi barındırabileceğiniz açık kaynak izleme istiyorsanız.
• LangSmith: yığınınız uçtan uca LangChain ve LangGraph ise.
• Arize Phoenix: OpenTelemetry-native izleme istiyorsanız ve Elastic License 2.0'ın kaynak erişilebilir, OSI onaylı olmayan lisansını kabul ediyorsanız.
• Braintrust: cömert bir ücretsiz katmanla hepsi bir arada değerlendirmeler artı deneyler istiyorsanız.
• Promptfoo: CLI'da yaşıyorsanız ve kırmızı takım tatbikatını aynı araçta istiyorsanız.
• Ragas: ajanınız aslında bir RAG pipeline'ıysa ve geri alma odaklı metrikler istiyorsanız.
• Galileo: kutudan çıktığı gibi yönetilen bir halüsinasyon ve kalite endeksi istiyorsanız.
• Maxim: çok turlu ajanlar için bir simülasyon-ve-değerlendirme iş akışı istiyorsanız.
• W&B Weave: zaten Weights & Biases kullanıyorsanız ve eğitim çalıştırmalarınızın yanında izleme istiyorsanız.

Confident AI için dürüst bir sınır: yönetilen kırmızı takım modülü ve şirket içi (on-prem) dağıtım Enterprise katmanı özellikleridir ve ABD/AB veri yerleşimi, kayıt sırasında evrensel bir seçenek değil, Team/Enterprise özelliğidir. Tek bir ajan yayınlayan solo bir geliştirici, ücretsiz olarak DeepEval OSS ile başlayabilir ve tüm bir ekip değerlendirme çalıştırması gerektiğinde platformu ekleyebilir.

Sıkça Sorulan Sorular

Yapay Zeka Ajan Değerlendirmesi Nedir?

Yapay zeka ajan değerlendirmesi, özerk bir ajanın yalnızca nihai yanıtını değil, tüm davranışını puanlama pratiğidir. Çok adımlı yörüngeyi, çağırdığı araçları, görev başarısını, maliyeti, gecikmeyi ve güvenliği ölçer. Ajanlar deterministik olmayan bir şekilde davrandığı ve gerçek durumu değiştirdiği için, değerlendirme hem geliştirme sırasında hem de canlı üretim trafiğinde sürekli olarak çalışır.

Bir Ajanın Yörüngesini Nihai Çıktısına Karşı Nasıl Değerlendirirsiniz?

Nihai çıktı değerlendirmesi yalnızca son yanıtı puanlar. Yörünge değerlendirmesi ise tüm izi puanlar: her akıl yürütme adımını, araç çağrısını ve ara sonucu. Yayılım düzeyinde puanlama, tam olarak hangi adımın başarısız olduğunu bulabilmeniz için her adımı ayrı ayrı değerlendirir. Bir çalıştırma, bozuk bir yörünge üzerinden doğru bir yanıt üretebilir; bunu yörünge değerlendirmesi yakalar, yalnızca çıktıya bakan kontroller ise kaçırır.

Bir Ajanın Doğru Aracı Çağırdığını Nasıl Doğrularsınız?

Üç şeyi ayrı ayrı kontrol edin: araç seçimi (görev için doğru araç), argüman doğruluğu (doğru parametreler ve değerler) ve yürütme yolu geçerliliği (doğru adım ve sıra). DeepEval'ın Tool Correctness metriği gibi çerçeveler, gerçekte çağrılan araçları beklenen araçlarla karşılaştırır, girdi parametrelerinde eşleşme yapar ve etkinleştirdiğinizde çağrı sırasını da puanlayabilir.

Üretimdeki Yapay Zeka Ajanları İçin En Çok Hangi Metrikler Önemlidir?

Önce görev başarı oranı ve başarılı görev başına maliyet gelir, ardından gecikme yüzdelik dilimleri (p50, p90, p99), araç çağrısı doğruluğu, doğruluk (faithfulness), insan müdahale oranı, sapma (drift) ve güvenlik kapısı geçme oranı. Başarılı görev başına maliyet, ham maliyetten daha önemlidir; çünkü düz görev başına maliyet, hızlı ve ucuz başarısız olan ajanları sessizce ödüllendirir.

Çevrimdışı ve Çevrimiçi Ajan Değerlendirmeleri Arasındaki Fark Nedir?

Çevrimdışı değerlendirmeler, gerilemeleri yakalamak için metriklerinizi dağıtım öncesi, genellikle CI içinde, sabit bir altın veri setine karşı çalıştırır. Çevrimiçi değerlendirmeler ise yayından sonra aynı metrikleri canlı üretim izlerine karşı gerçek zamanlı olarak çalıştırır. İkisine de ihtiyacınız var: çevrimdışı bilinen başarısızlık modlarını yakalar, çevrimiçi ise hiçbir altın kümenin öngörmediği girdileri yakalar ve bunları veri setlerinize geri besler.

Ajan Değerlendirmelerini Ne Sıklıkla Yeniden Çalıştırmalısınız?

Çevrimdışı değerlendirmeleri, CI'da kapılandırılmış şekilde her prompt, model veya araç değişikliğinde çalıştırın. Çevrimiçi değerlendirmeleri canlı trafiğe karşı sürekli çalıştırın; çünkü sapma (drift) ve model ağırlığı güncellemeleri, dağıtımlar arasında ajanları sessizce bozar. Üretim yeni bir başarısızlık modu ortaya çıkardığında altın veri setinizi yeniden derleyin; böylece test paketiniz ilk gün yazdığınız örnekler yerine gerçekliği takip eder.

Jailbreak'leri ve PII Sızıntılarını Yayına Almadan Önce Nasıl Yakalarsınız?

Dağıtım öncesi bir kapı olarak adversarial kırmızı takım değerlendirmeleri çalıştırın ve bunları çevrimiçi olarak da çalıştırmaya devam edin. Başarısızlık modlarını LLM'ler için OWASP İlk 10 Listesi'ne, NIST AI RMF'ye ve MITRE ATLAS'a eşleyin, ardından açık kaynak DeepTeam gibi bir çerçeveyle her kategoriye karşı saldırıları simüle edin. Yalnızca düşük bir ortalama puanda değil, geçen herhangi bir güvenlik açığında da sürümü engelleyin.

Bir Yapay Zeka Ajan Değerlendirme Platformunu Kendiniz mi Kurmalısınız, Yoksa Satın mı Almalısınız?

Solo bir geliştiriciyseniz veya kodda rahat olan küçük bir mühendislik ekibiyseniz açık kaynak araçlarla (metrikler için DeepEval, CLI testleri ve kırmızı takım tatbikatı için Promptfoo) kendiniz kurun. Tüm bir ekip organizasyon genelinde kodsuz erişime, yönetilen güvenlik testine ve projeler arasında standartlaştırılmış üretim gözlemlenebilirliğine ihtiyaç duyduğunda Confident AI gibi bir platform satın alın. Çoğu ekip OSS ile başlar ve zamanla büyür.

LLM-as-a-judge, Ajanları Puanlamak İçin Güvenilir mi?

Yararlıdır ama gürültülüdür. Bir LLM hakemi, binlerce ize ucuza ölçeklenir; ama deterministik değildir ve genellikle ajanla aynı kör noktaları paylaşır, bu yüzden makul-ama-yanlış bir yanıtı damgalayabilir. Bir örneklem üzerinde insan veya alan uzmanı etiketlerine karşı kalibre edin, puanları yönlü bir sinyal olarak ele alın ve yüksek riskli kararları mümkün olduğunca deterministik kontrollere bağlayın.

3 Katmanlı Sistem, Tek Nefeste

Yalnızca yanıtı değil, yörüngeyi puanlayın. Araç çağrılarını üç eksende doğrulayın: doğru araç, doğru argümanlar, doğru adım. Aynı metrikleri çevrimdışı ve çevrimiçi olarak, canlı izlerde, gerçek başarısızlıkları veri setlerinize geri derleyen bir döngüde çalıştırın. Ve dağıtımı yalnızca doğruluğa değil, güvenliğe de bağlı kılın.

En çok acı veren katmanla başlayın: kör bir şekilde yayına alıyorsanız önce çevrimiçi değerlendirmeleri kurun; güvensiz bir şekilde yayına alıyorsanız önce güvenlik kapısını inşa edin. Açık kaynak DeepEval ve Promptfoo ile kendiniz kurun, ya da tüm bir ekip kodsuz erişime ve yönetilen güvenliğe ihtiyaç duyduğunda Confident AI gibi bir platform satın alın. Mühendislerin tüm döngüyü sizin için kurmasını tercih ediyorsanız, bu tam olarak ekibimizin her hafta yaptığı bir şeydir.