Çok Turlu LLM Değerlendirme: 5 Metrik, 3 Framework, 1 İş Akışı

Çok Turlu LLM Değerlendirme: 5 Metrik, 3 Framework, 1 İş Akışı

Çok turlu LLM değerlendirme, 8. tur amnezi hatasını yakalamanın tek yoludur: kullanıcı sipariş numarasını 3. turda vermiştir, bot yine de tekrar sorar. Her bir tur tek başına geçmiştir; konuşma yine de başarısız olmuştur. DeepEval 4.0 ve RAGAS 0.4 tam da bunun için özel konuşma değerlendirme API'leri yayınladı ve Techsy'deki kendi hattımızda yaşadığımız iki değerlendirme vakasının ardından, başlangıç için beş metrik, üç framework ve tek bir iş akışı burada.

Öne Çıkanlar

• Çok turlu değerlendirme, izole girdi-çıktı çiftlerini değil, konuşmanın bütününü puanlar.
• Tek turlu benchmark'larda zirvedeki modeller, konuşma turları boyunca ölçülebilir biçimde geriler.
• Dört metrikle başlayın: bütünlük, bilgi tutma, role bağlılık, tur alakası.
• DeepEval, RAGAS ve Langfuse çok turlu değerlendirmeyi farklı çözer; aşağıdaki framework tablosu üçünü karşılaştırır.

Tek Turlu Skorlar Size Neden Yalan Söyler?

Tek turlu değerlendirmeler her seferinde tek bir girdi-çıktı çiftini puanladığı için, yalnızca turlar arasında ortaya çıkan hataları göremez: unutma, çelişki, sapma. Bir model güçlü bir benchmark skoru yayınlayıp canlı bir konuşmanın ipini yine de kaçırabilir. Laban ve arkadaşları bunu, 353 atıflı LLMs Get Lost In Multi-Turn Conversation çalışmasında belgeler: tek turlu sonuçlar sağlıklı görünse bile çok turlu ortamlarda performans düşer.

Temel sorun belirleyici olmamadır (non-determinizm): n'inci yanıt, önceki n-1 turun tümüne bağlıdır, bu yüzden aynı prompt'lar geçmişe göre farklı davranır. İzole çiftlerden oluşan bir veri kümesi bu bağımlılığı asla sınamaz. Yaklaşık 250 kaynağı tarayan bir PRISMA incelemesi olan arXiv araştırması Evaluating LLM-based Agents for Multi-Turn Conversations, alanı neyin değerlendirileceği (bağlam yönetimi, planlama, tutarlılık) ve nasıl (metrikler, LLM yargıçları, insan incelemesi) diye ikiye ayırır. Tek turlu bir test paketinde bu iki eksen de yoktur.

Bunların hiçbiri tek turlu yığınızı işe yaramaz kılmaz. BLEU, ROUGE ve G-Eval gibi tek turlu metrikleri çalıştırıyorsanız, onları iyi ölçtükleri şey için tutun: format uyumu, toksisite, sabit bir prompt'ta olgu hatırlama. Sadece onları, kullanıcılarınızın dokunduğu konuşmanın sağlık kontrolü olarak okumayı bırakın.

Bu çalışmaların bizdeki yorumu, tek satırla:

Tek turlu değerlendirmeler yanıtı ölçer, çok turlu değerlendirme konuşmayı ölçer; birinci turu kusursuz geçen bir model, beşinci turda kaybolabilir.

Çok Turlu LLM Değerlendirme Nedir? İki Değerlendirme Modu

Çok turlu LLM değerlendirme, izole prompt-yanıt çiftleri yerine bir konuşmanın bütününü ya da onun içindeki pencereleri puanlama pratiğidir. Modelin bağlamı koruyup korumadığını, rolde kalıp kalmadığını ve kullanıcının sorununun turlar boyunca çözüp çözmediğini sorgular. İşi iki mod yürütür: konuşma düzeyinde puanlama ve kayan pencere ile tur düzeyinde puanlama; çoğu ekip ikisini de çalıştırır.

Konuşma düzeyinde puanlama, yargıca transkriptin tamamını verir ve tek bir soru sorar: bu konuşma başarılı mıydı? Erken kapatmaları ve çözülmeyen döngüleri yakalar, çünkü kullanıcının iadesini asla alamadığını yalnızca dizinin tamamı gösterir. Zayıf noktası ayrıntı düzeyidir: 12 turluk bir dizide "başarısız" demek, işlerin nerede koptuğunu söylemez.

Kayan pencere ile tur düzeyinde puanlama, N turluk bir pencereyi transkript boyunca yürütür; pencere başına bir hüküm verir. 10 turluk bir konuşmada 3'lük pencere, sohbetin bölgelerine bağlı 8 hüküm üretir; böylece "başarısız" bir koordinatla gelir: kopma 6 ile 8. turlar arasında oldu. Bu yazının başındaki şema, tek bir dizi üzerinde iki modu da gösterir: konuşma hükmü için bir parantez, pencere hükümleri için kayan bir çerçeve.

Konuşma düzeyinde puanlamayı kapı olarak kullanın; kapı takıldığında penceresel puanlama hatanın yerini bulsun. DeepEval'ın çok turlu değerlendirme rehberi, iş birimini bir girdi-çıktı çifti değil bir senaryo olarak çerçeveler (ConversationalGolden tipi): bir soruyu değil, bir durumu test edersiniz.

Örnekleyici örnek (sentetik; gerçek bir çalışmayı değil mekaniği gösterir): 8 turluk bir iade talebi sohbeti üzerinde 3'lük kayan pencere.

Turn 1  user:      I want to return an order that arrived damaged.
Turn 2  assistant: Sorry about that. Can you share the order number?
Turn 3  user:      It's #4471.
Turn 4  assistant: Got it. Damaged on arrival, or after use?
Turn 5  user:      On arrival. The screen was cracked.
Turn 6  assistant: Understood. Replacement or refund?
Turn 7  user:      Refund. How long does that take?
Turn 8  assistant: 3-5 business days. Can you share the order number again?

Konuşma düzeyinde hüküm: kaldı. Altı pencerenin beşi geçti ve dizi yine de bilgi tutmada koptu; tam da tek turlu bir paketin asla yüzeye çıkaramayacağı hata.

Hangi Çok Turlu Metrikler Önemli? Önemli Olan 5 Tanesi

Önce dört metrik çalıştırın: konuşma bütünlüğü, bilgi tutma, role bağlılık ve tur alakası. Beşinci olarak, ürününüzün yanlış yapamayacağı her şey için özel bir kriter ekleyin (DeepEval'da G-Eval, RAGAS'ta AspectCritic). İlk dördü projeler arasında taşınır; beşincisi, sizin hata modlarınızın yaşadığı yerdir.

1. Konuşma bütünlüğü. Kullanıcının hedefi çözüldü mü, yoksa bot erken mi zafer ilan etti? Erken kapatma dedektörünüzdür.
2. Bilgi tutma. Model, dizide daha önce belirtilen olguları hatırlıyor mu? 8. tur amnezi hatası bir bilgi tutma başarısızlığıdır.
3. Role bağlılık. Asistan kişiliğinin içinde kalıyor ve kapsam dışı istekleri reddediyor mu? Uyum sınırı olan her yerde kritiktir.
4. Tur alakası. Her yanıt, önceki turlar göz önüne alındığında konuya uygun mu? Sapmayı ve döngüleri yakalar.
5. Özel bir kriter. Alanınız için tek bir düz cümle kural: "fiyat listesindekinden farklı bir fiyat asla söyleme." DeepEval bunu ConversationalGEval olarak uygular; RAGAS ise AspectCritic olarak.

DeepEval metrik rehberi her birini çalıştırılabilir sınıflarla tanımlar, ama kavramlar framework'ten bağımsızdır: yargıcınızı elle yazsanız bile tablo geçerlidir.

Özel bir kriter bir cümle gibi okunur:

criterion "price_accuracy":
  question: Does the assistant quote prices matching the official
            list, and self-correct when the user flags a mismatch?
  scale: 0 (wrong, no correction) to 1 (correct throughout)
  verdict: pass if score >= 0.5

Aynı kural, gerçek DeepEval kodu olarak:

from deepeval.metrics import ConversationalGEval
from deepeval.test_case import LLMTestCaseParams

price_accuracy = ConversationalGEval(
    name="Price Accuracy",
    criteria=(
        "Does the assistant quote prices that match the official "
        "price list, and correct itself immediately when the user "
        "points out a discrepancy?"
    ),
    evaluation_params=[
        LLMTestCaseParams.INPUT,
        LLMTestCaseParams.ACTUAL_OUTPUT,
    ],
    threshold=0.5,
)

DeepEval mı RAGAS mı Langfuse mu: Hangi Framework Uyar?

Üçü de çok turlu konuşmaları değerlendirir, ama değerlendirme birimleri farklıdır: DeepEval senaryoları çevrimdışı simüle eder, RAGAS zaten elinizde olan konuşmaların yönlerini puanlar, Langfuse ise gerçek üretim izlerini değerlendirir. Seçimi özellik sayısına göre değil, konuşmalarınızın nereden geldiğine göre yapın.

Önce framework'ten bağımsız mantık; böylece aşağıdaki üretici kodu taşınabilir kalır:

for scenario in scenario_set:
    transcript = run_chatbot(scenario, max_turns=10)
    for window in sliding_windows(transcript, 3):
        scores.append(judge(window, criteria))
    scores.append(judge(transcript, completeness))
fail_if(mean(scores) < baseline - tolerance)

DeepEval: senaryolar ve kutudan dolu bir simülatör

DeepEval, birinci sınıf bir konuşma simülatörü olan tek araç: bir senaryo ve bir kişilik tarif edin, o da botunuza karşı kullanıcıyı oynar. Çok turlu rehberi, çift-değil-senaryo kalıbının temel başvuru kaynağıdır. Confident AI, barındırılan panoyu satar; ücretli katmanın ne eklediğini Confident AI incelememiz anlatır.

from deepeval.dataset import ConversationalGolden
from deepeval.synthesizer import ConversationSimulator
from deepeval.metrics import (
    ConversationCompletenessMetric,
    KnowledgeRetentionMetric,
)
from deepeval import evaluate

scenario = ConversationalGolden(
    additional_context="Customer wants to return a damaged order",
    user_persona="Impatient customer, second contact this week",
)
simulator = ConversationSimulator(model="gpt-4o-mini", max_turns=10)
test_case = simulator.simulate(scenario, your_chatbot_fn)

evaluate(
    test_cases=[test_case],
    metrics=[
        ConversationCompletenessMetric(threshold=0.7),
        KnowledgeRetentionMetric(threshold=0.7),
    ],
)

RAGAS: hata analizi odaklı, yön yön

RAGAS, zaten elinizde olan konuşmalardan başlar ve onları yön yön puanlar. Çok turlu nasıl yapılır belgesi, elle hata analiziyle eşleşir: başarısız sohbetleri okuyun, her hata modu için bir AspectCritic yazın, puanlayın.

from ragas.dataset_schema import MultiTurnSample
from ragas.metrics import AspectCritic
from ragas.llms import llm_factory

user_input = [
    {"role": "user", "content": "Can I return a damaged order?"},
    {"role": "assistant", "content": "Yes, within 30 days."},
    {"role": "user", "content": "It arrived broken. Do I pay shipping?"},
    {"role": "assistant", "content": "No, we cover it."},
]
sample = MultiTurnSample(user_input=user_input)

critic = AspectCritic(
    name="policy_consistency",
    definition="Does the assistant stay consistent with the stated return policy across all turns? Answer yes or no.",
    llm=llm_factory("gpt-4o-mini"),
)
score = await critic.multi_turn_ascore(sample)  # binary 0 or 1

Langfuse: gerçek izlerde N+1 değerlendirme

Langfuse ters yolu izler: önce izleyici. N+1 cookbook'u, her turun izini ve konuşmanın bütününü, simülasyonlar yerine üretim trafiği üzerinde değerlendirir. Hâlâ gözlemlenebilirlik katmanını seçiyorsanız, Langfuse vs LangSmith karşılaştırmamız o kararı kapsar.

Bizim hükmümüz, ortada durmadan: yeni bir chatbot projesi için DeepEval ile başlayın. Simülatör, en çok teste ihtiyaç duyduğunuz anda, üretim trafiğiniz henüz yokken regresyonları kapıdan geçirmenizi sağlar. Gerçek diziler oluşunca Langfuse ekleyin; ekibiniz başarısız konuşmaları okuyup bulduklarını kurala dökmeyi tercih ediyorsa RAGAS'a uzanın.

Hata Analizinden Otomasyona Nasıl Geçilir?

Sıralarsınız. 20-30 gerçek konuşma okuyun, hata modlarını elle etiketleyin, bariz olanlar için ikili geçti/kaldı kontrolleri yazın, onları otomatikleştirin ve ancak ondan sonra öznel artıklar için LLM yargıçlı metrikler ekleyin. Hamel Husain tam da bu sırayı savunur: önce elle hata analizi ve ikili kararlar, çünkü açıklayabildiğiniz bir kontrol, açıklayamadığınız bir skoru yener.

Yargıçtan önce ikili: bizi kurtaran sıralama

Bu, çalıştırdığımız bir chatbot benchmark'ı değil; kendi içerik hattımızın içindeki aynı kalıbın yorumumuzdur ve o hat, her prompt ve araç değişikliğinde değerlendirme kapılı regresyon kontrolleri çalıştırır. İki vaka, sıralamayı bizim için kanıtladı.

2026-06-13'te bir yeniden yayınlama hatası, yeni yerelleştirilmiş slug'lar üretti ve 54 yinelenen canlı doküman yayınladı. Onları 2026-07-05'te bulup yayından kaldırdık (yedek techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json içinde). Düzeltme daha akıllı bir model değildi; belirleyici bir yayınlama öncesi kontrolüydü: herhangi bir oluşturma işleminden önce mevcut dokümanı canonical gönderi ve dile göre çöz. İkili bir kapı.

İkinci vaka: çevirmen LLM'ler zaman zaman Unicode yerine ASCII üretir ve "karşılaştırma"yı "karsilastirma"ya çevirir. Yargıç gerekmez; bir grep kapısı yakalar:

grep -cP '[çşğüöıİŞÇĞÜÖ]' file.md   # must be > 0

İkisi de, maliyeti kuruşun kesirleri olan ve tam olarak neden başarısız olduklarını yazdıran kontrollerle yakalandı. Bunu çok turlu değerlendirmeye taşıyın: "bot, kullanıcının zaten verdiği bir alanı yeniden sordu mu?" sorusu, transkript üzerinde bir dizi eşleşmesidir, bir yargıç çağrısı değil. Önce ucuz, belirleyici kapıları çalıştırın; pahalı yargıcınız hiç çalışmadan çirkin hataları onlar yakalar.

LLM yargıcı ne zaman gerçekten doğru araçtır

Yargıçlar, token maliyetlerini bir kurala indirgenemeyen kriterlerde hak eder: "ton yeterince özür dileyen bir ton muydu?", "çözüm duruma uygun muydu?" Bir assertion yazabiliyorsanız, assertion yazın. Yargı çağrılarıyla dolu bir rubrik, yargıç bölgesidir.

Sürekli geri döndüğümüz çizgi:

Bir ekip arkadaşınıza açıklayabileceğiniz ikili geçti/kaldı kontrolleriyle başlayın, sonra LLM yargıçlarını yalnızca bir kurala indirgenemeyen şeyler için ekleyin.

Konuşmalar Ölçekte Nasıl Simüle Edilir ve Yargılamanın Maliyeti Nedir?

Dışa aktarılmış log'lardan değil, senaryolardan simüle edin. Senaryolar ne olabileceğini test eder; log'lar yalnızca mevcut sisteminizin zaten izin verdiklerini gösterir. DeepEval'ın yönlendirmesi, geçmiş konuşmaların onları üreten sistem tarafından şekillendirildiği konusunda uyarır; bu yüzden onlara karşı benchmark almak, statükoyu içine gömer.

Transkript değil, senaryo

Her senaryoyu hedef artı kişilik olarak yazın: "hasarlı siparişi iade eden sabırsız müşteri", "rezervasyon ortasında fikrini değiştiren kullanıcı." Bir maksimum tur sınırı (10 makuldür) ve bir durma koşulu koyun: hedefe ulaşıldı, kullanıcı vazgeçti ya da sınıra gelindi. DeepEval, birincil kullanım durumları, uç durumlar ve hataya yatkın durumlar arasında en az 20 çeşitli senaryo önerir; bunun altında paketiniz anekdot ölçer.

Rakip kişilikler

Botu kırmaya çalışan kişilikler ekleyin: tırmandıran öfkeli bir kullanıcı, kendiyle çelişen kafası karışık bir kullanıcı, 4. tura talimat sızdıran bir enjeksiyon kullanıcısı. Çok turlu enjeksiyon başlı başına bir disiplindir; LLM guardrails rehberimiz bu testlerle eşleşen savunma katmanını kapsar ve Langfuse'un simülasyon cookbook'u kullanıcı simülatörü döngüsünü gösterir.

Değerlendirilen 100 konuşmanın maliyeti

Aşağıdaki her rakam, belirtilen token sayılarından ve halka açık fiyatlardan bir tahmindir, çalıştırdığımız bir ölçüm değil. Mesele aritmetiğin kendisi: kendi rakamlarınızı yerine koyun.

Tamamen yargılanmış 100 konuşma için bir doların altında. Daha pahalı bir yargıç bunu 10-50 katına çıkarır ve LLM API maliyetlerini azaltma rehberimizdeki taktikler geçerlidir: kriter metnini önbelleğe alın, pencereleri toplu işleyin, ikili kapılarda ucuz modeli kullanın.

6 Adımlı Çok Turlu Değerlendirme İş Akışı

Döngü şöyle çalışır: gerçek hatalardan senaryolar tanımlayın, dört çekirdek metrik artı bir özel seçin, en az 20 senaryo simüle edin, mevcut sürümün taban çizgisini alın, CI'da regresyonları kapıdan geçirin ve üretim hatalarını senaryo kümesine geri besleyin.

1. Hatalardan senaryo tanımlayın. 20-30 transkript okuyun (ya da lansman öncesi, destek biletlerinden yazın). Her senaryo bir hedef, bir kişilik ve bir maksimum tur sınırı alır. Sahibi: siz ve Hamel'in önce-hata-analizi yöntemi.
2. Dört metrik seçin, biri özel. Bütünlük, bilgi tutma, role bağlılık, tur alakası ve alanınızın pahalı hatası için bir ConversationalGEval ya da AspectCritic.
3. Simüle edin. Rakip küme dahil en az 20 senaryo çalıştırın. Sahibi: DeepEval'ın ConversationSimulator'ü ya da Langfuse'un simülasyon cookbook'u.
4. Mevcut sürümün taban çizgisini alın. Modeller belirleyici olmadığı ve tek bir çalıştırma gürültü olduğu için, 3 çalıştırma üzerinden metrik başına ortalamaları kaydedin. Sahibi: değerlendirme betiğiniz, sonuçlar repoya commit edilir.
5. CI'da regresyonları kapıdan geçirin. Metrik başına bir eşik belirleyin ve toleransı aşan regresyonda derlemeyi başarısız kılın:

# ci/multi-turn-eval-gate.sh
set -euo pipefail
python eval/run_multi_turn.py --scenarios eval/scenarios.yaml --out results.json
SCORE=$(jq -r '.aggregate.completeness' results.json)
BASELINE=0.82
TOLERANCE=0.03
if (( $(echo "$SCORE < $BASELINE - $TOLERANCE" | bc -l) )); then
  echo "FAIL: completeness $SCORE below baseline $BASELINE"
  exit 1
fi

1. Üretim dizilerini izleyin. Canlı izleri diziye göre gruplayın, eşzamansız değerlendirin ve başarısız her diziyi yeni bir senaryoya dönüştürün. Sahibi: Langfuse ya da izleyiciniz; üretimde AI ajanlarını değerlendirme ve AI gözlemlenebilirlik rehberlerimiz işin izleme yarısını kapsar.

Paket asla bitmez: 6. adım 1. adımı besler ve senaryo kümesi, yakaladığınız her üretim hatasıyla büyür.

Ton Diller Arasında Nasıl Değerlendirilir?

İngilizce veriye göre ayarlanmış bir role bağlılık metriği, ana dili Türkçe ya da Japonca olan birinin kaba bulacağı bir transkripti geçirir, çünkü nezaket üslubu dile özgüdür. İngilizce rubriğinizin bunun için kelimesi yoktur. Çözüm: küresel tek bir ton metriği değil, her dil için yazılmış, üslup beklentisi başına bir yön kriteri.

Üslup başına bir kriter

RAGAS AspectCritic kalıbının bizim yorumumuz; yayınlanmış bir test sonucundan değil, 23 dilli bir hattı çalıştırmaktan genişletildi:

English:  "Is the assistant's tone friendly but professional?"
Turkish:  "Does the assistant use formal 'siz' address consistently,
           and avoid casual verb forms with an upset customer?"
Japanese: "Does the assistant keep keigo (polite form) throughout,
           including the apology at the resolution turn?"

Her kriter, aynı transkript üzerinde ayrı bir ikili eleştirmendir. Diller arası ton skorları yayınlamadık ve onları rubrik olmadan basan bir makaleye de güvenmezdik. Hat çalışmalarından: başarısızlıklar, üslubun ilk çöktüğü yer olan özür ve tırmandırma turlarında kümelenir.

Sıkça Sorulan Sorular

Çok turlu konuşma LLM'i nedir?

n'inci yanıtı yalnızca son prompt'a değil, önceki turların tümüne bağlı olan bir dil modelidir. Dizinin tamamına koşullanır, bu yüzden davranışı konuşma geçmişiyle değişir. Bu bağlam bağımlılığı, tek turlu testlerin sınayamadığı ve çok turlu değerlendirmenin puanlamak için var olduğu şeydir.

LLM değerlendirmesi ne anlama gelir?

Çıktı kalitesini, hissiyata göre değil, tanımlı kriterlere karşı otomatik ve tekrarlanabilir biçimde ölçmek. Tek turlu değerlendirme, izole prompt-yanıt çiftlerini BLEU gibi ya da bir LLM yargıcı gibi metriklerle puanlar. Çok turlu değerlendirme bunu konuşmaların bütününe genişletir ve prompt başına değil, turlar boyunca bağlam tutmayı ve hedef tamamlamayı puanlar.

Çok turlu LLM performansı nasıl benchmark'lanır?

Hedefleri ve kişilikleri olan en az 20 senaryo kurun, onları modele karşı simüle edin ve konuşma düzeyi metrikler artı kayan pencere kontrolleriyle puanlayın. Belirleyici olmamayı emmek için taban çizgilerini birden çok çalıştırma üzerinden kaydedin, sonra her yeni sürümü CI'da taban çizgisiyle karşılaştırın. Üretim izleri benchmark'ı sonradan genişletir.

Bir LLM'i değerlendirmenin en iyi yolları nelerdir?

Sıralayın: önce elle hata analizi, sonra bir kurala indirgenebilen her şey için ikili geçti/kaldı kapıları, sonra ton ve çözüm kalitesi gibi öznel kriterler için LLM-as-a-judge. İkili kontroller daha ucuzdur, hata ayıklanabilir ve sapmaz; yargıçlar, ucuz kapılar geçtikten sonra, gerçekten yargı gerektiren kriterlere aittir.

Hangi çok turlu değerlendirme metrikleriyle başlamalıyım?

Konuşma bütünlüğü, tur alakası ve bilgi tutma; bunlar herhangi bir sohbet ürününde en yaygın hataları (çözülmeyen hedefler, sapma, unutma) yakalar. Botunuzun bir uyum sınırı varsa role bağlılığı ekleyin, ardından işinizin karşılayamayacağı hata için bir özel G-Eval ya da AspectCritic kriteri.

LLM-as-a-judge konuşma başına ne kadara mal olur?

10 tur üzerinde 5'lik kayan pencere artı bir konuşma düzeyi çağrısıyla, konuşma başına 7 yargıç çağrısı yaparsınız. GPT-4o-mini'de çağrı başına yaklaşık 2.000 girdi token'ıyla, gösterdiğimiz aritmetik tahmini 100 konuşma başına yaklaşık $0,29'a çıkar. Premium yargıç modelleri bunu 10-50 kat artırır.

Çok turlu değerlendirme için DeepEval mı RAGAS mı: hangisini seçmeliyim?

Yerleşik bir konuşma simülatörüyle çevrimdışı regresyon testleri istiyorsanız DeepEval, özellikle üretim trafiğiniz henüz yoksa. İş akışınız gerçek başarısız konuşmaları okuyup her hata modunu bir AspectCritic olarak kurala dökmekle başlıyorsa RAGAS. Yaygın bir bölüşüm: CI'da DeepEval, üretim log'larında RAGAS tarzı eleştirmenler.

Çok turlu bir değerlendirme paketi için kaç senaryo gerekir?

En az 20; birincil kullanım durumlarını, uç durumları ve hataya yatkın durumları kapsayacak şekilde. Bu eşik DeepEval'ın yayınlanmış yönlendirmesinden gelir ve bizim deneyimimizle de örtüşür. 20'nin altında, geçme oranları hangi senaryoların dahil edildiğine göre savrulur. Kümeyi her üretim hatasıyla büyütün.

Çok turlu değerlendirmeyi CI/CD'de çalıştırabilir miyim?

Evet. Repoda sabit bir senaryo kümesi tutun, her prompt ya da model değişikliğinde çalıştırın ve bir metrik taban çizgisine göre toleransı aşarak gerilediğinde derlemeyi başarısız kılın. Modeller belirleyici olmadığı için, tam eşikler değil, toleranslı (biz 0,03 kullanıyoruz) 3 çalıştırma ortalamalarını karşılaştırın.

Üretimde çok turlu konuşmaları nasıl değerlendiririm?

İzleri konuşma dizisine göre gruplayın, her diziyi eşzamansız puanlayın ki değerlendirme asla bir yanıtı bloklamasın ve başarısız dizileri bir inceleme kuyruğuna yönlendirin. Doğrulanan her hata, çevrimdışı paketinizde yeni bir senaryo olur ve izleme ile regresyon testleri arasındaki döngüyü kapatır.

Kısa Versiyon

• Tek turlu skorlar konuşma hatalarını göremez; araştırmalar, sağlıklı benchmark'lara rağmen modellerin turlar boyunca gerilediğini gösterir.
• Konuşma düzeyi puanlamayı kapı olarak, kayan pencere puanlamayı kopmaları yerelleştirmek için çalıştırın.
• Dört çekirdek metrik artı bir özel kriter çoğu sohbet ürününü kapsar; yargıçlardan önce her zaman ikili kontroller.
• Simüle regresyon testleri için DeepEval, hata analizi odaklı eleştirmenler için RAGAS, üretim izleri için Langfuse.
• Yargıç maliyetleri küçüktür (mini bir modelde 100 konuşma başına bir doların altında); maliyet nadiren engelleyicidir.

Geniş araç ortamı için, sahanın tamamını en iyi LLM değerlendirme araçları toparlamamızda sıraladık. Ve değerlendirme hattını biriyle birlikte kurmayı tercih ederseniz, Techsy ekibiyle ücretsiz bir danışmanlık alın.