Đánh giá LLM đa lượt: 5 chỉ số, 3 framework, 1 quy trình

Đánh giá LLM đa lượt: 5 chỉ số, 3 framework, 1 quy trình

Đánh giá LLM đa lượt là cách duy nhất để bắt được lỗi mất trí nhớ ở lượt 8: người dùng đã cung cấp mã đơn hàng ở lượt 3, và bot hỏi lại. Từng lượt đơn lẻ đều đạt, nhưng cả cuộc hội thoại vẫn thất bại. DeepEval 4.0 và RAGAS 0.4 đã ra mắt API đánh giá hội thoại chuyên biệt cho chính xác vấn đề này, và sau hai sự cố eval trong pipeline của chính chúng tôi tại Techsy, đây là năm chỉ số, ba framework và một quy trình để bắt đầu.

Điểm chính

• Đánh giá đa lượt chấm điểm toàn bộ cuộc hội thoại, không phải từng cặp đầu vào-đầu ra riêng lẻ.
• Các mô hình đứng đầu benchmark đơn lượt suy giảm rõ rệt qua các lượt hội thoại.
• Bắt đầu với bốn chỉ số: độ hoàn chỉnh, khả năng ghi nhớ kiến thức, tuân thủ vai trò, mức độ liên quan theo lượt.
• DeepEval, RAGAS và Langfuse giải quyết eval đa lượt theo cách khác nhau; bảng so sánh framework bên dưới đối chiếu chúng.

Tại sao điểm đơn lượt đánh lừa bạn?

Eval đơn lượt chấm từng cặp đầu vào-đầu ra một, nên chúng không thể thấy các lỗi chỉ xuất hiện qua nhiều lượt: quên, mâu thuẫn, trôi chủ đề. Một mô hình có thể đạt điểm benchmark cao nhưng vẫn mất mạch trong cuộc hội thoại thực. Laban và cộng sự ghi nhận điều này trong LLMs Get Lost In Multi-Turn Conversation, 353 trích dẫn: hiệu suất giảm trong bối cảnh đa lượt ngay cả khi kết quả đơn lượt trông ổn.

Vấn đề cốt lõi là tính phi tất định: phản hồi thứ n phụ thuộc vào tất cả n-1 lượt trước đó, nên cùng một prompt sẽ cho kết quả khác nhau tùy theo lịch sử. Một dataset gồm các cặp riêng lẻ không bao giờ kiểm tra được sự phụ thuộc đó. Bài khảo sát arXiv Evaluating LLM-based Agents for Multi-Turn Conversations, một đánh giá PRISMA trên khoảng 250 nguồn, chia lĩnh vực này thành đánh giá cái gì (quản lý ngữ cảnh, lập kế hoạch, mạch lạc) và đánh giá thế nào (chỉ số, LLM judge, đánh giá con người). Cả hai trục đều vắng mặt trong bộ test đơn lượt.

Không có điều nào ở trên khiến bộ công cụ đơn lượt của bạn vô dụng. Nếu bạn đang chạy các chỉ số đơn lượt như BLEU, ROUGE và G-Eval, hãy giữ chúng cho những gì chúng đo tốt: tuân thủ định dạng, độc hại, ghi nhớ sự kiện trên prompt cố định. Chỉ cần ngừng đọc chúng như một bài kiểm tra sức khỏe cho cuộc hội thoại mà người dùng của bạn thực sự chạm vào.

Diễn giải của chúng tôi về các nghiên cứu đó, trong một dòng:

Eval đơn lượt đo câu trả lời, đánh giá đa lượt đo cuộc hội thoại, và một mô hình xuất sắc ở lượt một có thể lạc đường ở lượt năm.

Đánh giá LLM đa lượt là gì? Hai chế độ đánh giá

Đánh giá LLM đa lượt là thực hành chấm điểm toàn bộ cuộc hội thoại, hoặc các cửa sổ bên trong nó, thay vì từng cặp prompt-phản hồi riêng lẻ. Nó hỏi liệu mô hình có giữ được ngữ cảnh, ở đúng vai trò và giải quyết được vấn đề của người dùng qua các lượt hay không. Hai chế độ thực hiện công việc: chấm điểm cấp hội thoại và chấm điểm cấp lượt theo cửa sổ trượt, và hầu hết các đội chạy cả hai.

Chấm điểm cấp hội thoại đưa cho judge toàn bộ bản ghi và hỏi một câu: cuộc hội thoại này có thành công không? Nó bắt được lỗi đóng sớm và vòng lặp chưa giải quyết, vì chỉ toàn bộ mạch mới cho thấy người dùng không bao giờ nhận được tiền hoàn. Điểm yếu của nó là độ hạt: "thất bại" trên một mạch 12 lượt không nói được mọi thứ hỏng ở đâu.

Chấm điểm cấp lượt theo cửa sổ trượt di chuyển một cửa sổ N lượt trên bản ghi, mỗi cửa sổ một phán quyết. Cửa sổ 3 trên cuộc hội thoại 10 lượt cho ra 8 phán quyết gắn với các vùng của chat, nên "thất bại" đi kèm tọa độ: lỗi xảy ra ở lượt 6 đến 8. Sơ đồ ở đầu bài viết này hiển thị cả hai chế độ trên cùng một mạch: một dấu ngoặc cho phán quyết hội thoại, một khung trượt cho phán quyết theo cửa sổ.

Dùng chấm điểm cấp hội thoại làm cổng, chấm điểm theo cửa sổ để định vị lỗi khi cổng chặn. Hướng dẫn đánh giá đa lượt của DeepEval định nghĩa đơn vị công việc là một kịch bản thay vì cặp đầu vào-đầu ra (kiểu ConversationalGolden của nó): bạn đang kiểm tra một tình huống, không phải một câu hỏi.

Ví dụ minh họa (tổng hợp; thể hiện cơ chế, không phải kết quả chạy thực): cửa sổ trượt 3 trên chat yêu cầu trả hàng 8 lượt.

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?

Phán quyết cấp hội thoại: trượt. Năm trên sáu cửa sổ đạt, và mạch vẫn hỏng ở khả năng ghi nhớ kiến thức, chính xác là lỗi mà bộ test đơn lượt không bao giờ phát hiện.

Chỉ số đa lượt nào quan trọng? 5 chỉ số cần dùng

Chạy bốn chỉ số trước: độ hoàn chỉnh hội thoại, khả năng ghi nhớ kiến thức, tuân thủ vai trò và mức độ liên quan theo lượt. Thêm chỉ số thứ năm, một tiêu chí tùy chỉnh (G-Eval trong DeepEval, AspectCritic trong RAGAS), cho bất cứ điều gì sản phẩm của bạn không được phép sai. Bốn chỉ số đầu chuyển được giữa các dự án; chỉ số thứ năm là nơi chứa các chế độ lỗi của bạn.

1. Độ hoàn chỉnh hội thoại. Mục tiêu của người dùng có được giải quyết không, hay bot tuyên bố chiến thắng sớm? Đây là máy phát hiện lỗi đóng sớm của bạn.
2. Khả năng ghi nhớ kiến thức. Mô hình có nhớ các sự kiện đã nêu trước đó trong mạch không? Lỗi mất trí nhớ ở lượt 8 là một thất bại về ghi nhớ kiến thức.
3. Tuân thủ vai trò. Trợ lý có ở trong persona của nó và từ chối các yêu cầu ngoài phạm vi không? Quan trọng khi có ranh giới tuân thủ.
4. Mức độ liên quan theo lượt. Mỗi phản hồi có đúng chủ đề dựa trên các lượt trước đó không? Bắt được trôi chủ đề và lặp vòng.
5. Tiêu chí tùy chỉnh. Một quy tắc ngôn ngữ tự nhiên cho lĩnh vực của bạn: "không bao giờ báo giá khác với bảng giá." DeepEval triển khai cái này dưới dạng ConversationalGEval; RAGAS dưới dạng AspectCritic.

Hướng dẫn chỉ số DeepEval định nghĩa từng chỉ số với các class chạy được, nhưng các khái niệm không phụ thuộc framework: bảng trên vẫn đúng ngay cả khi bạn tự viết judge.

Một tiêu chí tùy chỉnh đọc như một câu:

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

Cùng quy tắc đó dưới dạng code DeepEval thực:

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 nào phù hợp?

Cả ba đều đánh giá hội thoại đa lượt, nhưng đơn vị đánh giá của chúng khác nhau: DeepEval mô phỏng kịch bản offline, RAGAS chấm điểm các khía cạnh của hội thoại bạn đã có, và Langfuse đánh giá trace sản xuất thực. Chọn theo nguồn hội thoại của bạn, không phải số lượng tính năng.

Logic không phụ thuộc framework trước, để code nhà cung cấp bên dưới có thể di chuyển được:

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: kịch bản và simulator đầy đủ pin

DeepEval là framework duy nhất có simulator hội thoại hạng nhất: mô tả một kịch bản và một persona, và nó đóng vai người dùng đối đầu với bot của bạn. Hướng dẫn đa lượt của nó là tài liệu tham khảo chuẩn cho mẫu kịch bản-thay-vì-cặp. Confident AI bán dashboard hosted; bài đánh giá Confident AI của chúng tôi bao quát lớp trả phí thêm gì.

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: hướng phân tích lỗi, từng khía cạnh

RAGAS bắt đầu từ các cuộc hội thoại bạn đã có và chấm điểm từng khía cạnh. Hướng dẫn đa lượt của nó kết hợp với phân tích lỗi thủ công: đọc các chat thất bại, viết một AspectCritic cho mỗi chế độ lỗi, chấm điểm.

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: đánh giá N+1 trên trace thực

Langfuse đi con đường ngược lại: tracer trước. Cookbook N+1 của nó đánh giá trace của từng lượt cộng với toàn bộ hội thoại, trên traffic sản xuất thay vì mô phỏng. Nếu bạn vẫn đang chọn lớp observability, bài so sánh Langfuse vs LangSmith của chúng tôi bao quát quyết định đó.

Phán quyết của chúng tôi, không nước đôi: cho một dự án chatbot mới, bắt đầu với DeepEval. Simulator cho phép bạn chặn regression trước khi có traffic sản xuất, đúng lúc bạn cần test nhất. Thêm Langfuse khi đã có mạch thực; dùng RAGAS khi đội của bạn thích đọc các cuộc hội thoại thất bại và mã hóa những gì họ tìm thấy.

Đi từ phân tích lỗi đến tự động hóa như thế nào?

Bạn tuần tự hóa nó. Đọc 20-30 cuộc hội thoại thực, gán nhãn chế độ lỗi bằng tay, viết kiểm tra đậu/trượt nhị phân cho những lỗi rõ ràng, tự động hóa chúng, và chỉ sau đó thêm chỉ số LLM-judge cho phần chủ quan còn lại. Hamel Husain lập luận cho chính xác thứ tự này: phân tích lỗi thủ công và quyết định nhị phân trước, vì một kiểm tra bạn có thể giải thích tốt hơn một điểm số bạn không thể.

Nhị phân trước judge: thứ tự đã cứu chúng tôi

Đây không phải benchmark chatbot chúng tôi chạy; đây là diễn giải của chúng tôi về cùng một mẫu bên trong pipeline nội dung của chính mình, pipeline chạy kiểm tra regression có cổng eval trên mỗi thay đổi prompt và công cụ. Hai sự cố đã chứng minh thứ tự này cho chúng tôi.

Ngày 2026-06-13, một lỗi republish đã tạo slug bản địa hóa mới và xuất bản 54 tài liệu trùng lặp. Chúng tôi phát hiện và gỡ xuất bản chúng ngày 2026-07-05 (bản sao lưu tại techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json). Bản sửa không phải mô hình thông minh hơn; nó là một kiểm tra tiền xuất bản tất định: giải tài liệu hiện có theo bài viết canonical cộng ngôn ngữ trước bất kỳ lệnh create nào. Một cổng nhị phân.

Sự cố thứ hai: LLM dịch thuật thỉnh thoảng xuất ASCII thay vì Unicode, biến "karşılaştırma" thành "karsilastirma." Không cần judge; một cổng grep bắt được:

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

Cả hai đều bị bắt bởi các kiểm tra tốn chưa đến một xu và in ra chính xác lý do thất bại. Ánh xạ sang eval đa lượt: "bot có hỏi lại một trường người dùng đã cung cấp không?" là một phép khớp chuỗi trên bản ghi, không phải một lời gọi judge. Chạy các cổng tất định rẻ trước; chúng bắt những lỗi xấu xí trước khi judge đắt tiền của bạn chạy.

Khi nào LLM judge thực sự là công cụ đúng

Judge xứng đáng với chi phí token của chúng ở các tiêu chí bạn không thể rút gọn thành quy tắc: "giọng điệu có xin lỗi phù hợp không?", "cách giải quyết có phù hợp tình huống không?" Nếu bạn viết được một assertion, hãy viết assertion. Một rubric đầy các phán xét chủ quan là lãnh địa của judge.

Ranh giới chúng tôi luôn quay lại:

Bắt đầu với kiểm tra đậu/trượt nhị phân mà bạn có thể giải thích cho đồng đội, rồi chỉ thêm LLM judge cho những gì bạn không thể rút gọn thành quy tắc.

Mô phỏng hội thoại ở quy mô lớn như thế nào, và chi phí judge ra sao?

Mô phỏng từ kịch bản, không phải từ log xuất. Kịch bản kiểm tra những gì có thể xảy ra; log chỉ cho thấy những gì hệ thống hiện tại của bạn đã cho phép. Hướng dẫn của DeepEval cảnh báo rằng các cuộc hội thoại lịch sử được định hình bởi hệ thống tạo ra chúng, nên benchmark trên chúng sẽ đóng băng hiện trạng.

Kịch bản, không phải bản ghi

Viết mỗi kịch bản dưới dạng mục tiêu cộng persona: "khách hàng sốt ruột trả lại đơn hàng hư hỏng," "người dùng đổi ý giữa chừng khi đặt lịch." Đặt giới hạn lượt tối đa (10 là hợp lý) và điều kiện dừng: đạt mục tiêu, người dùng bỏ, hoặc chạm trần. DeepEval khuyến nghị ít nhất 20 kịch bản đa dạng trên các trường hợp sử dụng chính, trường hợp biên và tình huống dễ lỗi; dưới mức đó, bộ test của bạn chỉ đo giai thoại.

Persona đối kháng

Bao gồm các persona cố phá bot: người dùng tức giận leo thang, người dùng bối rối tự mâu thuẫn, người dùng injection lén chèn chỉ thị ở lượt 4. Injection đa lượt là một lĩnh vực riêng; hướng dẫn LLM guardrails của chúng tôi bao quát lớp phòng thủ kết hợp với các test này, và cookbook mô phỏng của Langfuse hiển thị vòng lặp user-simulator.

Chi phí cho 100 cuộc hội thoại được đánh giá

Mọi con số bên dưới là ước tính từ số token đã nêu và giá công khai, không phải phép đo chúng tôi chạy. Phép tính mới là điểm: thay số của bạn vào.

Chưa đến một đô la cho 100 cuộc hội thoại được judge đầy đủ. Judge đắt hơn đẩy con số này lên 10-50 lần, và các chiến thuật trong hướng dẫn giảm chi phí API LLM của chúng tôi áp dụng được: cache văn bản tiêu chí, gộp cửa sổ theo batch, dùng mô hình rẻ cho cổng nhị phân.

Quy trình eval đa lượt 6 bước

Vòng lặp chạy như sau: định nghĩa kịch bản từ lỗi thực, chọn bốn chỉ số cốt lõi cộng một tùy chỉnh, mô phỏng ít nhất 20 kịch bản, đặt baseline cho phiên bản hiện tại, chặn regression trong CI, và đưa lỗi sản xuất ngược vào bộ kịch bản.

1. Định nghĩa kịch bản từ lỗi. Đọc 20-30 bản ghi (hoặc, trước khi ra mắt, viết chúng từ ticket hỗ trợ). Mỗi kịch bản có một mục tiêu, một persona và một trần lượt tối đa. Người phụ trách: bạn và phương pháp phân tích lỗi trước tiên của Hamel.
2. Chọn bốn chỉ số, một tùy chỉnh. Độ hoàn chỉnh, ghi nhớ kiến thức, tuân thủ vai trò, mức độ liên quan theo lượt, và một ConversationalGEval hoặc AspectCritic cho sai lầm đắt giá trong lĩnh vực của bạn.
3. Mô phỏng. Chạy ít nhất 20 kịch bản bao gồm bộ đối kháng. Người phụ trách: ConversationSimulator của DeepEval, hoặc cookbook mô phỏng của Langfuse.
4. Đặt baseline phiên bản hiện tại. Ghi lại trung bình từng chỉ số trên 3 lần chạy, vì mô hình phi tất định và một lần chạy duy nhất là nhiễu. Người phụ trách: script eval của bạn, kết quả commit vào repo.
5. Chặn regression trong CI. Đặt ngưỡng cho mỗi chỉ số và làm hỏng build khi regression vượt dung sai:

# 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. Giám sát mạch sản xuất. Nhóm trace trực tiếp theo mạch, đánh giá bất đồng bộ, và biến mọi mạch thất bại thành kịch bản mới. Người phụ trách: Langfuse hoặc tracer của bạn; hướng dẫn của chúng tôi về đánh giá AI agent trong sản xuất và AI observability bao quát nửa giám sát.

Bộ test không bao giờ hoàn tất: bước 6 nuôi bước 1, và bộ kịch bản lớn lên theo mỗi lỗi sản xuất bạn bắt được.

Đánh giá giọng điệu đa ngôn ngữ như thế nào?

Một chỉ số tuân thủ vai trò được tinh chỉnh trên dữ liệu tiếng Anh sẽ cho qua một bản ghi tiếng Thổ Nhĩ Kỳ hoặc tiếng Nhật mà người bản xứ thấy thô lỗ, vì mức độ lịch sự phụ thuộc vào ngôn ngữ. Rubric tiếng Anh của bạn không có từ cho nó. Cách sửa: một tiêu chí khía cạnh cho mỗi kỳ vọng về mức độ lịch sự, viết riêng cho từng ngôn ngữ, không phải một chỉ số giọng điệu toàn cầu.

Một tiêu chí cho mỗi mức độ lịch sự

Diễn giải của chúng tôi về mẫu AspectCritic của RAGAS, mở rộng từ việc vận hành pipeline 23 ngôn ngữ, không phải kết quả test đã công bố:

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

Mỗi tiêu chí là một critic nhị phân riêng trên cùng bản ghi. Chúng tôi chưa công bố điểm giọng điệu đa ngôn ngữ, và sẽ không tin một bài viết in chúng ra mà không kèm rubric. Từ công việc pipeline: lỗi tập trung ở lượt xin lỗi và leo thang, nơi mức độ lịch sự sụp đổ trước tiên.

Về tác giả

Mert Batur là Đồng sáng lập của Techsy.io, nơi đội ngũ xây dựng AI agent, hệ thống tự động hóa và pipeline giọng nói/SDR cho khách hàng B2B. Anh viết về bộ công cụ LLM mà đội Techsy thực sự dùng trong sản xuất. Chứng chỉ: Đồng sáng lập, Techsy.io. Kết nối trên LinkedIn.

Câu hỏi thường gặp

LLM hội thoại đa lượt là gì?

Một mô hình ngôn ngữ mà phản hồi thứ n phụ thuộc vào tất cả các lượt trước, không chỉ prompt mới nhất. Nó điều kiện hóa trên toàn bộ mạch, nên hành vi thay đổi theo lịch sử hội thoại. Sự phụ thuộc ngữ cảnh đó là thứ mà bài test đơn lượt không thể kiểm tra và đánh giá đa lượt tồn tại để chấm điểm.

Đánh giá LLM nghĩa là gì?

Đo chất lượng đầu ra theo các tiêu chí đã định nghĩa, tự động và lặp lại được, thay vì theo cảm tính. Đánh giá đơn lượt chấm các cặp prompt-phản hồi riêng lẻ theo chỉ số như BLEU hoặc LLM judge. Đánh giá đa lượt mở rộng điều đó sang toàn bộ cuộc hội thoại, chấm khả năng giữ ngữ cảnh và hoàn thành mục tiêu qua các lượt thay vì theo từng prompt.

Benchmark hiệu suất LLM đa lượt như thế nào?

Xây ít nhất 20 kịch bản với mục tiêu và persona, mô phỏng chúng trên mô hình, và chấm bằng chỉ số cấp hội thoại cộng kiểm tra cửa sổ trượt. Ghi baseline trên nhiều lần chạy để hấp thụ tính phi tất định, rồi so sánh mỗi phiên bản mới với baseline trong CI. Trace sản xuất mở rộng benchmark sau đó.

Cách tốt nhất để đánh giá một LLM là gì?

Tuần tự hóa: phân tích lỗi thủ công trước, rồi cổng đậu/trượt nhị phân cho mọi thứ rút gọn được thành quy tắc, rồi LLM-as-a-judge cho tiêu chí chủ quan như giọng điệu và chất lượng giải quyết. Kiểm tra nhị phân rẻ hơn, gỡ lỗi được và không trôi; judge thuộc về các tiêu chí thực sự cần phán xét, sau khi các cổng rẻ đã qua.

Nên bắt đầu với chỉ số đánh giá đa lượt nào?

Độ hoàn chỉnh hội thoại, mức độ liên quan theo lượt và ghi nhớ kiến thức; chúng bắt các lỗi phổ biến nhất (mục tiêu chưa giải quyết, trôi chủ đề, quên) trong bất kỳ sản phẩm chat nào. Thêm tuân thủ vai trò nếu bot của bạn có ranh giới tuân thủ, rồi một tiêu chí G-Eval hoặc AspectCritic tùy chỉnh cho sai lầm mà doanh nghiệp bạn không thể chịu.

Chi phí LLM-as-a-judge mỗi cuộc hội thoại là bao nhiêu?

Với cửa sổ trượt 5 trên 10 lượt cộng một lời gọi cấp hội thoại, bạn thực hiện 7 lời gọi judge mỗi hội thoại. Với khoảng 2.000 token đầu vào mỗi lời gọi trên GPT-4o-mini, ước tính kèm phép tính của chúng tôi ra khoảng $0,29 cho 100 hội thoại. Mô hình judge cao cấp đẩy con số lên 10-50 lần.

DeepEval vs RAGAS cho đánh giá đa lượt: nên chọn cái nào?

DeepEval nếu bạn muốn test regression offline với simulator hội thoại tích hợp, đặc biệt trước khi có traffic sản xuất. RAGAS nếu quy trình của bạn bắt đầu từ việc đọc các cuộc hội thoại thất bại thực và mã hóa mỗi chế độ lỗi thành một AspectCritic. Một cách chia phổ biến: DeepEval trong CI, critic kiểu RAGAS trên log sản xuất.

Cần bao nhiêu kịch bản cho bộ eval đa lượt?

Ít nhất 20, bao quát các trường hợp sử dụng chính, trường hợp biên và tình huống dễ lỗi; ngưỡng đó đến từ hướng dẫn đã công bố của DeepEval và khớp với kinh nghiệm của chúng tôi. Dưới 20, tỷ lệ đậu dao động theo kịch bản nào tình cờ được đưa vào. Mở rộng bộ theo mỗi lỗi sản xuất.

Có thể chạy đánh giá đa lượt trong CI/CD không?

Có. Giữ một bộ kịch bản cố định trong repo, chạy nó trên mỗi thay đổi prompt hoặc mô hình, và làm hỏng build khi một chỉ số regression vượt dung sai so với baseline. Vì mô hình phi tất định, so sánh trung bình trên 3 lần chạy với dung sai (chúng tôi dùng 0,03), không phải ngưỡng chính xác.

Đánh giá hội thoại đa lượt trong sản xuất như thế nào?

Nhóm trace theo mạch hội thoại, chấm mỗi mạch bất đồng bộ để eval không bao giờ chặn phản hồi, và định tuyến mạch thất bại vào hàng đợi xem xét. Mỗi lỗi được xác nhận trở thành kịch bản mới trong bộ offline của bạn, khép vòng lặp giữa giám sát và test regression.

Phiên bản ngắn

• Điểm đơn lượt không thể thấy lỗi hội thoại; nghiên cứu cho thấy mô hình suy giảm qua các lượt bất chấp benchmark khỏe mạnh.
• Chạy chấm điểm cấp hội thoại làm cổng và chấm điểm cửa sổ trượt để định vị lỗi.
• Bốn chỉ số cốt lõi cộng một tiêu chí tùy chỉnh bao quát hầu hết sản phẩm chat; kiểm tra nhị phân trước judge, luôn luôn.
• DeepEval cho test regression mô phỏng, RAGAS cho critic hướng phân tích lỗi, Langfuse cho trace sản xuất.
• Chi phí judge nhỏ (chưa đến một đô la cho 100 hội thoại trên mô hình mini); chi phí hiếm khi là rào cản.

Cho bức tranh công cụ rộng hơn, chúng tôi đã xếp hạng toàn bộ lĩnh vực trong bài tổng hợp công cụ đánh giá LLM tốt nhất. Và nếu bạn muốn xây pipeline eval cùng ai đó, hãy nhận tư vấn miễn phí với đội Techsy.