Evaluasi LLM Multi-Turn: 5 Metrik, 3 Framework, 1 Workflow

Evaluasi LLM Multi-Turn: 5 Metrik, 3 Framework, 1 Workflow

Evaluasi LLM multi-turn adalah satu-satunya cara untuk menangkap bug amnesia di turn ke-8: user sudah memberikan nomor pesanan di turn ke-3, tapi bot memintanya lagi. Setiap turn lolos saat diuji sendirian, namun percakapannya tetap gagal. DeepEval 4.0 dan RAGAS 0.4 merilis API eval percakapan khusus untuk kasus seperti ini, dan setelah dua insiden eval di pipeline kami sendiri di Techsy, berikut lima metrik, tiga framework, dan satu workflow untuk memulai.

Poin Penting

• Evaluasi multi-turn menilai percakapan secara utuh, bukan pasangan input-output yang terisolasi.
• Model yang memuncaki benchmark single-turn tetap menurun performanya seiring bertambahnya turn percakapan.
• Mulai dari empat metrik: completeness, knowledge retention, role adherence, turn relevancy.
• DeepEval, RAGAS, dan Langfuse menyelesaikan eval multi-turn dengan cara berbeda; tabel framework di bawah membandingkannya.

Kenapa Skor Single-Turn Membohongimu?

Eval single-turn menilai satu pasangan input-output pada satu waktu, jadi ia tidak bisa melihat kegagalan yang hanya muncul lintas turn: lupa, kontradiksi, drift. Sebuah model bisa mencetak skor benchmark yang tinggi tapi tetap kehilangan alur percakapan live. Laban et al. mendokumentasikan ini di LLMs Get Lost In Multi-Turn Conversation, 353 sitasi: performa menurun di setting multi-turn bahkan ketika hasil single-turn terlihat sehat.

Masalah intinya adalah non-determinisme: respons ke-n bergantung pada semua n-1 turn sebelumnya, sehingga prompt yang identik bisa berperilaku berbeda tergantung riwayat. Dataset berisi pasangan terisolasi tidak pernah menguji dependensi itu. Survei arXiv Evaluating LLM-based Agents for Multi-Turn Conversations, sebuah review PRISMA terhadap sekitar 250 sumber, membagi bidang ini menjadi apa yang dievaluasi (manajemen konteks, perencanaan, koherensi) dan bagaimana (metrik, judge LLM, review manusia). Kedua sumbu itu absen dari suite single-turn.

Tidak ada dari ini yang membuat stack single-turn-mu tidak berguna. Jika kamu menjalankan metrik single-turn seperti BLEU, ROUGE, dan G-Eval, pertahankan untuk hal-hal yang memang bisa ia ukur dengan baik: kepatuhan format, toksisitas, recall faktual pada prompt tetap. Cukup berhenti membacanya sebagai cek kesehatan untuk percakapan yang disentuh user-mu.

Interpretasi kami atas studi-studi itu, dalam satu baris:

Eval single-turn mengukur jawaban, evaluasi multi-turn mengukur percakapan, dan model yang sempurna di turn pertama bisa tersesat di turn kelima.

Apa Itu Evaluasi LLM Multi-Turn? Dua Mode Evaluasi

Evaluasi LLM multi-turn adalah praktik menilai seluruh percakapan, atau jendela-jendela di dalamnya, alih-alih pasangan prompt-respons yang terisolasi. Ia bertanya apakah model mempertahankan konteks, tetap dalam peran, dan menyelesaikan masalah user lintas turn. Dua mode melakukan pekerjaan ini: penilaian level percakapan dan penilaian level turn dengan sliding-window, dan kebanyakan tim menjalankan keduanya.

Penilaian level percakapan menyerahkan transkrip penuh ke judge dan mengajukan satu pertanyaan: apakah percakapan ini berhasil? Ia menangkap penutupan prematur dan loop yang tak terselesaikan, karena hanya utas utuh yang mengungkap bahwa user tidak pernah mendapat refund-nya. Kelemahannya adalah granularitas: "gagal" pada utas 12 turn tidak memberi tahu di mana segalanya rusak.

Penilaian level turn dengan sliding-window menggeser jendela berisi N turn melintasi transkrip, satu vonis per jendela. Jendela 3 pada percakapan 10 turn menghasilkan 8 vonis yang terikat ke wilayah chat, sehingga "gagal" datang dengan koordinat: kerusakannya terjadi di turn 6 sampai 8. Diagram di bagian atas postingan ini menunjukkan kedua mode pada satu utas: tanda kurung untuk vonis percakapan, bingkai geser untuk vonis per jendela.

Gunakan penilaian level percakapan sebagai gerbang, dan penilaian berjendela untuk melokalisasi kegagalan saat gerbang itu tersandung. Panduan evaluasi multi-turn DeepEval membingkai unit kerja sebagai skenario, bukan pasangan input-output (tipe ConversationalGolden miliknya): kamu sedang menguji sebuah situasi, bukan sebuah pertanyaan.

Contoh ilustratif (sintetis; menunjukkan mekanismenya, bukan run sungguhan): sliding-window 3 pada chat permintaan retur 8 turn.

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?

Vonis level percakapan: gagal. Lima dari enam jendela lolos, dan utasnya tetap jebol di knowledge retention, persis kegagalan yang tidak pernah dimunculkan suite single-turn.

Metrik Multi-Turn Mana yang Penting? 5 yang Penting

Jalankan empat metrik terlebih dahulu: conversation completeness, knowledge retention, role adherence, dan turn relevancy. Tambahkan yang kelima, kriteria custom (G-Eval di DeepEval, AspectCritic di RAGAS), untuk apa pun yang tidak boleh salah di produkmu. Empat yang pertama bisa dipindahkan antar proyek; yang kelima adalah tempat mode kegagalanmu hidup.

1. Conversation completeness. Apakah tujuan user terselesaikan, atau bot menyatakan menang terlalu cepat? Detektor penutupan prematur-mu.
2. Knowledge retention. Apakah model mengingat fakta yang dinyatakan sebelumnya di utas? Bug amnesia turn ke-8 adalah kegagalan knowledge-retention.
3. Role adherence. Apakah asisten tetap di dalam persona-nya dan menolak permintaan di luar cakupan? Kritis dengan batas kepatuhan.
4. Turn relevancy. Apakah setiap respons sesuai topik mengingat turn-turn sebelumnya? Menangkap drift dan loop.
5. Kriteria custom. Satu aturan berbahasa sederhana untuk domainmu: "jangan pernah menyebut harga yang berbeda dari daftar harga." DeepEval mengimplementasikannya sebagai ConversationalGEval; RAGAS sebagai AspectCritic.

Panduan metrik DeepEval mendefinisikan masing-masing dengan kelas yang bisa dijalankan, tapi konsepnya netral-framework: tabel ini tetap berlaku bahkan jika kamu membuat judge sendiri.

Kriteria custom terbaca seperti sebuah kalimat:

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

Aturan yang sama sebagai kode DeepEval sungguhan:

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 vs RAGAS vs Langfuse: Framework Mana yang Cocok?

Ketiganya mengevaluasi percakapan multi-turn, tapi unit evaluasinya berbeda: DeepEval mensimulasikan skenario secara offline, RAGAS menilai aspek-aspek percakapan yang sudah kamu miliki, dan Langfuse mengevaluasi trace produksi sungguhan. Pilih berdasarkan dari mana percakapanmu berasal, bukan jumlah fitur.

Logika netral-framework dulu, supaya kode vendor di bawah bisa dipindahkan:

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: skenario dan simulator lengkap-baterai

DeepEval adalah satu-satunya dengan simulator percakapan kelas satu: deskripsikan skenario dan persona, lalu ia memainkan user melawan bot-mu. Panduan multi-turn-nya adalah referensi kanonik untuk pola skenario-bukan-pasangan. Confident AI menjual dashboard hosted; ulasan Confident AI kami membahas apa yang ditambahkan lapisan berbayar itu.

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: didorong analisis error, aspek demi aspek

RAGAS berangkat dari percakapan yang sudah kamu miliki dan menilainya aspek demi aspek. How-to multi-turn-nya berpasangan dengan analisis error manual: baca chat yang gagal, tulis satu AspectCritic per mode kegagalan, nilai.

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: evaluasi N+1 pada trace sungguhan

Langfuse mengambil jalur sebaliknya: tracer duluan. Cookbook N+1-nya mengevaluasi trace tiap turn ditambah percakapan secara utuh, pada traffic produksi alih-alih simulasi. Jika kamu masih memilih lapisan observability, perbandingan Langfuse vs LangSmith kami membahas keputusan itu.

Vonis kami, tanpa main aman: untuk proyek chatbot baru, mulai dengan DeepEval. Simulatornya memungkinkan kamu meng-gate regresi sebelum punya traffic produksi, justru saat kamu paling butuh tes. Tambahkan Langfuse begitu utas sungguhan sudah ada; raih RAGAS ketika timmu lebih suka membaca percakapan yang gagal dan mengkodifikasi apa yang mereka temukan.

Bagaimana Kamu Beralih dari Analisis Error ke Otomasi?

Kamu mengurutkannya. Baca 20-30 percakapan sungguhan, labeli mode kegagalan secara manual, tulis cek lolos/gagal biner untuk yang sudah jelas, otomatiskan itu, dan baru kemudian tambahkan metrik yang di-judge LLM untuk sisa yang subjektif. Hamel Husain berargumen persis untuk urutan ini: analisis error manual dan keputusan biner dulu, karena cek yang bisa kamu jelaskan lebih baik daripada skor yang tidak bisa.

Biner sebelum judge: urutan yang menyelamatkan kami

Ini bukan benchmark chatbot yang kami jalankan; ini interpretasi kami atas pola yang sama di dalam pipeline konten kami sendiri, yang menjalankan cek regresi bergerbang eval pada setiap perubahan prompt dan tooling. Dua insiden membuktikan urutan ini bagi kami.

Pada 2026-06-13, bug republish mencetak slug terlokalisasi baru dan mengirim 54 dokumen live duplikat. Kami menemukan dan membatalkan publikasinya pada 2026-07-05 (backup di techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json). Perbaikannya bukan model yang lebih pintar; itu adalah cek pra-publikasi yang deterministik: selesaikan dokumen yang ada berdasarkan postingan kanonik plus bahasa sebelum create apa pun. Sebuah gerbang biner.

Insiden kedua: LLM penerjemah kadang mengeluarkan ASCII alih-alih Unicode, mengubah "karşılaştırma" menjadi "karsilastirma." Tidak perlu judge; gerbang grep menangkapnya:

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

Keduanya tertangkap oleh cek yang biayanya sepersekian sen dan mencetak persis kenapa ia gagal. Petakan itu ke eval multi-turn: "apakah bot meminta lagi field yang sudah user berikan?" adalah pencocokan string terhadap transkrip, bukan panggilan judge. Jalankan gerbang deterministik yang murah terlebih dahulu; ia menangkap kegagalan-kegagalan buruk sebelum judge mahalmu pernah berjalan.

Kapan judge LLM benar-benar alat yang tepat

Judge layak biaya token-nya untuk kriteria yang tidak bisa kamu reduksi menjadi aturan: "apakah nadanya cukup meminta maaf?", "apakah resolusinya cocok dengan situasinya?" Jika kamu bisa menulis asersi, tulis asersi. Rubrik yang penuh panggilan penilaian adalah wilayah judge.

Batas yang terus kami kembali kepadanya:

Mulai dengan cek lolos/gagal biner yang bisa kamu jelaskan ke rekan tim, lalu tambahkan judge LLM hanya untuk hal yang tidak bisa kamu reduksi menjadi aturan.

Bagaimana Kamu Mensimulasikan Percakapan dalam Skala Besar, dan Berapa Biaya Judging?

Simulasikan dari skenario, bukan log yang diekspor. Skenario menguji apa yang bisa terjadi; log hanya menunjukkan apa yang sudah diizinkan sistemmu saat ini. Panduan DeepEval memperingatkan bahwa percakapan historis dibentuk oleh sistem yang memproduksinya, sehingga benchmark terhadapnya mengunci status quo.

Skenario, bukan transkrip

Tulis setiap skenario sebagai tujuan plus persona: "pelanggan tidak sabar yang meretur pesanan rusak," "user yang berubah pikiran di tengah booking." Tetapkan batas maksimal turn (10 itu masuk akal) dan kondisi berhenti: tujuan tercapai, user meninggalkan, atau batas. DeepEval merekomendasikan setidaknya 20 skenario beragam lintas use case utama, edge case, dan situasi rawan gagal; di bawah itu, suite-mu mengukur anekdot.

Persona adversarial

Sertakan persona yang mencoba menjebol bot: user marah yang mengeskalasi, user bingung yang mengkontradiksi dirinya sendiri, user injeksi yang menyelipkan instruksi di turn 4. Injeksi multi-turn adalah disiplin tersendiri; panduan LLM guardrails kami membahas lapisan defensif yang berpasangan dengan tes-tes ini, dan cookbook simulasi Langfuse menunjukkan loop simulator-user.

Berapa biaya 100 percakapan yang dievaluasi

Setiap angka di bawah adalah estimasi dari jumlah token yang dinyatakan dan harga publik, bukan pengukuran yang kami jalankan. Aritmetika adalah intinya: ganti dengan angkamu sendiri.

Di bawah satu dolar untuk 100 percakapan yang di-judge penuh. Judge yang lebih mahal menggeser ini 10-50x, dan taktik di panduan kurangi biaya API LLM kami berlaku: cache teks kriteria, batch jendela, gunakan model murah untuk gerbang biner.

Workflow Eval Multi-Turn 6 Langkah

Loop-nya berjalan seperti ini: definisikan skenario dari kegagalan sungguhan, pilih empat metrik inti plus satu custom, simulasikan setidaknya 20 skenario, baseline versi saat ini, gate regresi di CI, dan masukkan kegagalan produksi kembali ke set skenario.

1. Definisikan skenario dari kegagalan. Baca 20-30 transkrip (atau, pra-peluncuran, tulis dari tiket support). Setiap skenario mendapat tujuan, persona, dan batas maksimal turn. Pemilik: kamu dan metode analisis-error-dulu milik Hamel.
2. Pilih empat metrik, satu custom. Completeness, knowledge retention, role adherence, turn relevancy, dan satu ConversationalGEval atau AspectCritic untuk kesalahan mahal di domainmu.
3. Simulasikan. Jalankan setidaknya 20 skenario termasuk set adversarial. Pemilik: ConversationSimulator milik DeepEval, atau cookbook simulasi Langfuse.
4. Baseline versi saat ini. Rekam rata-rata per metrik selama 3 run, karena model non-deterministik dan satu run adalah noise. Pemilik: skrip eval-mu, hasil di-commit ke repo.
5. Gate regresi di CI. Tetapkan ambang per metrik dan gagalkan build saat regresi melampaui toleransi:

# 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. Pantau utas produksi. Kelompokkan trace live per utas, evaluasi secara asinkron, dan ubah setiap utas yang gagal menjadi skenario baru. Pemilik: Langfuse atau tracer-mu; panduan kami tentang mengevaluasi AI agent di produksi dan observability AI membahas separuh pemantauan.

Suite-nya tidak pernah selesai: langkah 6 memberi makan langkah 1, dan set skenario tumbuh dengan setiap kegagalan produksi yang kamu tangkap.

Bagaimana Kamu Mengevaluasi Nada Lintas Bahasa?

Metrik role-adherence yang ditala pada data bahasa Inggris akan meloloskan transkrip bahasa Turki atau Jepang yang dianggap kasar oleh penutur asli, karena register kesopanan itu spesifik per bahasa. Rubrik bahasa Inggrismu tidak punya kata untuk itu. Perbaikannya: satu kriteria aspek per ekspektasi register, ditulis per bahasa, bukan satu metrik nada global.

Satu kriteria per register

Interpretasi kami atas pola AspectCritic RAGAS, diperluas dari menjalankan pipeline 23 bahasa, bukan hasil tes yang dipublikasikan:

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?"

Setiap kriteria adalah kritik biner terpisah pada transkrip yang sama. Kami belum mempublikasikan skor nada lintas bahasa, dan tidak akan percaya artikel yang mencetaknya tanpa rubrik. Dari pekerjaan pipeline: kegagalan mengelompok di turn permintaan maaf dan eskalasi, tempat register runtuh lebih dulu.

Tentang Penulis

Mert Batur adalah Co-Founder Techsy.io, tempat timnya mengirim AI agent, sistem otomasi, dan pipeline voice/SDR untuk klien B2B. Ia menulis tentang stack tooling LLM yang benar-benar dipakai tim Techsy di produksi. Kredensial: Co-Founder, Techsy.io. Terhubung di LinkedIn.

Pertanyaan yang Sering Diajukan

Apa itu LLM percakapan multi-turn?

Model bahasa yang respons ke-n-nya bergantung pada semua turn sebelumnya, bukan hanya prompt terbaru. Ia mengkondisikan pada utas penuh, sehingga perilakunya berubah seiring riwayat percakapan. Ketergantungan-konteks itulah yang tidak bisa diuji tes single-turn dan yang ada untuk dinilai oleh evaluasi multi-turn.

Apa arti evaluasi LLM?

Mengukur kualitas output terhadap kriteria yang didefinisikan, secara otomatis dan dapat diulang, alih-alih berdasarkan perasaan. Evaluasi single-turn menilai pasangan prompt-respons terisolasi terhadap metrik seperti BLEU atau judge LLM. Evaluasi multi-turn memperluas itu ke seluruh percakapan, menilai retensi konteks dan penyelesaian tujuan lintas turn, bukan per prompt.

Bagaimana kamu mem-benchmark performa LLM multi-turn?

Bangun setidaknya 20 skenario dengan tujuan dan persona, simulasikan terhadap model, dan nilai dengan metrik level percakapan plus cek sliding-window. Rekam baseline selama beberapa run untuk menyerap non-determinisme, lalu bandingkan setiap versi baru terhadap baseline di CI. Trace produksi memperluas benchmark itu nantinya.

Apa cara terbaik untuk mengevaluasi LLM?

Urutkan: analisis error manual dulu, lalu gerbang lolos/gagal biner untuk semua yang bisa direduksi menjadi aturan, lalu LLM-as-a-judge untuk kriteria subjektif seperti nada dan kualitas resolusi. Cek biner lebih murah, bisa di-debug, dan tidak drift; judge milik kriteria yang benar-benar membutuhkan penilaian, setelah gerbang murah lolos.

Metrik evaluasi multi-turn mana yang harus saya mulai?

Conversation completeness, turn relevancy, dan knowledge retention; ia menangkap kegagalan paling umum (tujuan tak terselesaikan, drift, lupa) di produk chat apa pun. Tambahkan role adherence jika bot-mu punya batas kepatuhan, lalu satu kriteria custom G-Eval atau AspectCritic untuk kesalahan yang tidak sanggup ditanggung bisnismu.

Berapa biaya LLM-as-a-judge per percakapan?

Dengan sliding-window 5 pada 10 turn plus satu panggilan level percakapan, kamu melakukan 7 panggilan judge per percakapan. Dengan sekitar 2.000 token input per panggilan pada GPT-4o-mini, estimasi hitungan kami yang ditampilkan menghasilkan sekitar $0,29 per 100 percakapan. Model judge premium menaikkan itu 10-50x.

DeepEval vs RAGAS untuk evaluasi multi-turn: mana yang harus saya pilih?

DeepEval jika kamu ingin tes regresi offline dengan simulator percakapan bawaan, terutama sebelum kamu punya traffic produksi. RAGAS jika workflow-mu dimulai dari membaca percakapan gagal sungguhan dan mengkodifikasi setiap mode kegagalan sebagai AspectCritic. Satu pembagian umum: DeepEval di CI, kritik gaya-RAGAS pada log produksi.

Berapa banyak skenario yang saya butuhkan untuk suite eval multi-turn?

Setidaknya 20, mencakup use case utama, edge case, dan situasi rawan gagal; ambang itu datang dari panduan DeepEval yang dipublikasikan dan cocok dengan pengalaman kami. Di bawah 20, tingkat lolos berayun tergantung skenario mana yang kebetulan disertakan. Tumbuhkan set-nya dengan setiap kegagalan produksi.

Bisakah saya menjalankan evaluasi multi-turn di CI/CD?

Bisa. Simpan set skenario tetap di repo, jalankan pada setiap perubahan prompt atau model, dan gagalkan build ketika sebuah metrik regresi melewati toleransi terhadap baseline. Karena model non-deterministik, bandingkan rata-rata selama 3 run dengan toleransi (kami pakai 0,03), bukan ambang persis.

Bagaimana saya mengevaluasi percakapan multi-turn di produksi?

Kelompokkan trace per utas percakapan, nilai setiap utas secara asinkron sehingga evaluasi tidak pernah memblokir respons, dan arahkan utas yang gagal ke antrean review. Setiap kegagalan yang dikonfirmasi menjadi skenario baru di suite offline-mu, menutup loop antara pemantauan dan tes regresi.

Versi Singkatnya

• Skor single-turn tidak bisa melihat kegagalan percakapan; riset menunjukkan model menurun lintas turn meski benchmark-nya sehat.
• Jalankan penilaian level percakapan sebagai gerbangmu dan penilaian sliding-window untuk melokalisasi kerusakan.
• Empat metrik inti plus satu kriteria custom mencakup kebanyakan produk chat; cek biner sebelum judge, selalu.
• DeepEval untuk tes regresi simulasi, RAGAS untuk kritik yang didorong analisis error, Langfuse untuk trace produksi.
• Biaya judge kecil (di bawah satu dolar per 100 percakapan pada model mini); biaya jarang jadi penghalang.

Untuk lanskap tool yang lebih luas, kami meranking seluruh bidang di rangkuman tool evaluasi LLM terbaik kami. Dan jika kamu lebih suka membangun pipeline eval bersama seseorang, dapatkan konsultasi gratis dengan tim Techsy.