Đánh Giá RAG 2026: RAGAS vs DeepEval — Hướng Dẫn Production
So sánh RAGAS vs DeepEval, bốn metric cốt lõi (faithfulness, context precision, recall, answer relevancy) và kiến trúc đánh giá 3 lớp cho RAG production 2026, kèm code Python và pipeline CI/CD.
Đánh giá RAG (RAG evaluation) là quá trình đo lường chất lượng của hệ thống Retrieval-Augmented Generation qua hai trục riêng biệt, chất lượng truy xuất (retrieval) và chất lượng sinh câu trả lời (generation), bằng các metrics chuyên dụng như faithfulness, context precision, context recall và answer relevancy. Trong năm 2026, RAGAS và DeepEval là hai framework thống trị, mỗi công cụ phục vụ một giai đoạn khác nhau trong vòng đời sản phẩm. Bài viết này chia sẻ cách tôi đã triển khai một pipeline đánh giá đầy đủ cho các hệ thống RAG production tại Việt Nam.
Bốn metric cốt lõi cần theo dõi: faithfulness (ngưỡng 0.85), context precision (0.8), context recall (0.8) và answer relevancy (0.75).
Metric truyền thống như BLEU, ROUGE không phân biệt được lỗi retrieval và lỗi generation, nên đừng dùng chúng cho RAG.
RAGAS phù hợp cho giai đoạn khám phá và tạo golden dataset tổng hợp; DeepEval phù hợp cho quality gate CI/CD kiểu pytest.
Không bao giờ dùng cùng model để sinh câu trả lời và làm judge; điểm số sẽ bị thổi phồng nghiêm trọng.
Tách rubric theo từng chiều đánh giá. Đánh giá đa chiều trong một prompt tạo kết quả thiếu nhất quán.
Kết hợp golden dataset offline (50–200 cặp Q&A) với monitoring online (TruLens hoặc Langfuse) để bắt regression trong vài giờ.
Tại sao metric truyền thống thất bại với RAG?
Các metric NLP kinh điển như BLEU, ROUGE và BERTScore được thiết kế cho dịch máy và tóm tắt. Chúng đo độ tương đồng bề mặt giữa văn bản sinh ra và một tham chiếu cố định. Nhưng RAG có hai chế độ lỗi hoàn toàn khác nhau mà những metric này không phân biệt được: lỗi retrieval (truy xuất sai chunk hoặc thiếu chunk quan trọng) và lỗi generation (bỏ qua hoặc bóp méo ngữ cảnh đã truy xuất). Một hệ thống có thể trả lời "gần đúng" theo BLEU nhưng thực chất đang bịa đặt (hallucinate) từ tham số của model thay vì dùng knowledge base. Đây chính là lỗi nghiêm trọng nhất trong doanh nghiệp.
Thật lòng mà nói, tôi gặp bug này khi ship một pipeline RAG cho một fintech Việt Nam đầu năm 2026. Hệ thống tra cứu quy định KYC ban đầu cho điểm BLEU 0.72, nhìn có vẻ ổn. Nhưng khi tôi bổ sung faithfulness của RAGAS, điểm chỉ còn 0.61: gần 40% câu trả lời chứa ít nhất một mệnh đề không được ngữ cảnh hỗ trợ. Model đang "sáng tạo" điều khoản không tồn tại. Đây chính là lý do các đội production 2026 chuyển hoàn toàn sang bộ metric chuyên biệt cho RAG.
Một điểm nữa: đánh giá RAG phải tách được lỗi ở tầng nào. Nếu chỉ dùng một chỉ số end-to-end, bạn biết có vấn đề nhưng không biết cần sửa retriever hay sửa prompt của LLM. Đánh giá theo thành phần (component-wise evaluation) là tiêu chuẩn ngành hiện nay và là cơ sở cho mọi pipeline eval nghiêm túc.
Bốn metric cốt lõi trong đánh giá RAG 2026
Bộ metric chuẩn năm 2026 gồm bốn chỉ số chia đều cho hai tầng. Mỗi cái trả lời một câu hỏi cụ thể về pipeline của bạn.
Faithfulness (Độ trung thực)
Faithfulness đo tỷ lệ mệnh đề trong câu trả lời được ngữ cảnh truy xuất hỗ trợ. Đây là metric phát hiện hallucination trực tiếp nhất. Ngưỡng production khuyến nghị là ≥ 0.85. Dưới ngưỡng này nghĩa là ít nhất 15% câu trả lời chứa thông tin không dựa trên nguồn, không chấp nhận được trong ngành tài chính, y tế hay pháp lý.
Context Precision (Độ chính xác ngữ cảnh)
Context Precision đo tỷ lệ tín hiệu/nhiễu trong tập chunk truy xuất và cả thứ tự xếp hạng của chúng. Chunk liên quan hơn phải đứng trước. Ngưỡng khuyến nghị: ≥ 0.8. Nếu bạn dùng reranker (như Cohere Rerank v3 hay bge-reranker-v2), chỉ số này thường tăng 15–25 điểm phần trăm.
Context Recall (Độ tái hiện ngữ cảnh)
Context Recall trả lời câu hỏi: "Đã lấy được TẤT CẢ thông tin cần thiết chưa?" Điểm faithfulness đạt 1.0 kết hợp với context recall thấp là dấu hiệu nguy hiểm; hệ thống đang tóm tắt chính xác từ ngữ cảnh không đầy đủ. Ngưỡng: ≥ 0.8. Muốn tính chỉ số này bạn phải có ground truth.
Answer Relevancy (Độ liên quan câu trả lời)
Answer Relevancy đo mức độ câu trả lời bám sát câu hỏi gốc. Nó phát hiện các phản hồi lan man hoặc lạc đề. Ngưỡng: ≥ 0.75. Metric này reference-free, không cần ground truth.
RAGAS vs DeepEval: so sánh chi tiết
Hai framework này không cạnh tranh trực tiếp. Chúng phục vụ giai đoạn khác nhau trong lifecycle. Bảng dưới đây tổng hợp các chiều so sánh mà tôi đánh giá trong 6 tháng gần nhất khi tư vấn cho ba khách hàng doanh nghiệp lớn.
Tiêu chí
RAGAS
DeepEval
Đối tượng chính
Data scientist / researcher
Software engineer / MLE
API paradigm
Function-call trên dataset
Pytest-native, assertion-based
Tạo synthetic dataset
TestsetGenerator sẵn có
Synthesizer + custom rules
CI/CD integration
Cần code adapter
Cắm thẳng vào GitHub Actions
Chọn LLM judge
Bất kỳ provider nào qua langchain
OpenAI, Anthropic, Azure, local
Vấn đề đã biết
NaN scores khi judge trả JSON lỗi
Recursive LLM calls dễ bị rate-limit
Phù hợp giai đoạn
Exploration, prototype
Regression testing, quality gate
License
Apache 2.0
Apache 2.0
Kinh nghiệm cá nhân: tôi dùng RAGAS trong 2–3 tuần đầu để khám phá không gian metric và tạo golden dataset đầu tiên (khoảng 100 cặp Q&A). Sau khi golden dataset ổn định, tôi chuyển toàn bộ sang DeepEval để gắn vào GitHub Actions. Mỗi PR chạm vào retriever hoặc prompt sẽ tự động chạy test và block merge nếu điểm giảm quá 5%. Đây là mô hình được cộng đồng khuyến nghị rộng rãi trong tài liệu chính thức của RAGAS.
Code thực hành với RAGAS
Ví dụ dưới đây đánh giá một hệ thống RAG với bốn metric cốt lõi. Tôi giả định bạn đã có LangChain retriever và OpenAI hoặc Claude API key. Code chạy được trên Python 3.11+ với ragas ≥ 0.2.
from ragas import evaluate
from ragas.metrics import (
faithfulness,
answer_relevancy,
context_precision,
context_recall,
)
from datasets import Dataset
from langchain_openai import ChatOpenAI
# Mỗi hàng phải có: question, answer, contexts (list), ground_truth
eval_data = {
"question": [
"Ngân hàng ABC yêu cầu giấy tờ gì khi mở tài khoản doanh nghiệp?",
"Thời hạn xử lý hồ sơ vay tiêu dùng là bao lâu?",
],
"answer": [
"Cần CMND người đại diện, giấy đăng ký kinh doanh và điều lệ công ty.",
"Thông thường 3-5 ngày làm việc kể từ khi đủ hồ sơ.",
],
"contexts": [
["Hồ sơ mở tài khoản doanh nghiệp bao gồm: CMND/CCCD người đại diện pháp luật, giấy phép đăng ký kinh doanh, điều lệ công ty..."],
["Thời gian xử lý hồ sơ vay tiêu dùng: 3-5 ngày làm việc sau khi khách hàng nộp đủ giấy tờ theo checklist..."],
],
"ground_truth": [
"CMND/CCCD đại diện, đăng ký kinh doanh, điều lệ.",
"3-5 ngày làm việc.",
],
}
dataset = Dataset.from_dict(eval_data)
# Judge phải khác model dùng để sinh câu trả lời
judge_llm = ChatOpenAI(model="gpt-4o", temperature=0)
result = evaluate(
dataset=dataset,
metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
llm=judge_llm,
)
print(result.to_pandas())
# faithfulness answer_relevancy context_precision context_recall
# 0.92 0.88 0.85 0.90
Với dataset 100 câu, chạy RAGAS mất khoảng 8–12 phút và tiêu tốn 1.5–2.5 USD tiền OpenAI (dùng gpt-4o làm judge). Nếu ngân sách hạn chế, chuyển sang gpt-4o-mini giảm chi phí 90% nhưng độ nhất quán của judge giảm khoảng 8–12%.
Code thực hành với DeepEval và pytest
DeepEval biến eval thành unit test. Mỗi PR chạy như test suite bình thường. Đây là mẫu tối thiểu tôi khuyên dùng làm quality gate:
import pytest
from deepeval import assert_test
from deepeval.metrics import (
FaithfulnessMetric,
AnswerRelevancyMetric,
ContextualPrecisionMetric,
ContextualRecallMetric,
)
from deepeval.test_case import LLMTestCase
from my_rag_app import run_rag_pipeline # hàm production của bạn
# Golden dataset — parametrize để mỗi case là một test riêng
GOLDEN_DATASET = [
{
"input": "Ngân hàng ABC yêu cầu giấy tờ gì khi mở tài khoản doanh nghiệp?",
"expected_output": "CMND/CCCD đại diện, đăng ký kinh doanh, điều lệ.",
},
# ... 100-200 case
]
@pytest.mark.parametrize("case", GOLDEN_DATASET)
def test_rag_pipeline(case):
output, retrieved_ctx = run_rag_pipeline(case["input"])
test_case = LLMTestCase(
input=case["input"],
actual_output=output,
expected_output=case["expected_output"],
retrieval_context=retrieved_ctx,
)
# Ngưỡng nghiêm ngặt cho production
metrics = [
FaithfulnessMetric(threshold=0.85, model="gpt-4o"),
AnswerRelevancyMetric(threshold=0.75, model="gpt-4o"),
ContextualPrecisionMetric(threshold=0.80, model="gpt-4o"),
ContextualRecallMetric(threshold=0.80, model="gpt-4o"),
]
# assert_test raise nếu bất kỳ metric nào dưới ngưỡng
assert_test(test_case, metrics)
Trong GitHub Actions, thêm bước sau vào workflow:
- name: Run RAG evaluation gate
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
run: |
pip install deepeval==2.4.0
deepeval test run tests/test_rag_eval.py --parallel 4
Cờ --parallel 4 chạy 4 test case đồng thời, giảm wall-time gấp 4 lần nhưng cẩn thận rate limit của OpenAI. Với gói Tier 2 (5M TPM), song song 4 an toàn cho dataset dưới 500 case.
Kiến trúc đánh giá lớp cho production
Đội production RAG thành công không chọn "một framework để cai trị tất cả". Họ xếp chồng ba lớp riêng biệt, mỗi lớp giải quyết một câu hỏi khác nhau. Đây là kiến trúc tôi đã tinh chỉnh qua ba dự án tại Việt Nam trong 2025–2026.
Lớp 1: Offline test suite (pre-deployment)
Duy trì golden dataset 50–200 cặp Q&A do domain expert xác thực. Chạy DeepEval qua GitHub Actions trên mỗi PR chạm vào retriever, prompt template, embedding model hoặc knowledge base. Ngưỡng phải chặt; dưới target là block merge. Không thoả hiệp trong lớp này.
Lớp 2: Staging shadow eval
Trước khi promote lên production, chạy 500–2000 câu hỏi thật (đã ẩn danh) từ log staging. So sánh phân phối điểm faithfulness và context precision với baseline tuần trước. Regression > 5% trong bất kỳ metric nào cần điều tra thủ công. Lớp này bắt các drift mà offline set bỏ sót.
Lớp 3: Production monitoring liên tục
Wire toàn bộ RAG span vào TruLens, Langfuse hoặc Patronus. Sample 5–10% traffic thật để chấm điểm real-time. Alert khi rolling median faithfulness giảm > 3 điểm trong 24 giờ. Đây là cách bạn phát hiện khi thị trường thay đổi và query distribution shift đến mức retriever không còn phù hợp.
Nếu bạn đang xây dựng nền tảng RAG từ đầu, tham khảo bài Context Engineering cho AI Production 2026 để hiểu cách chuẩn bị nguồn tài liệu trước khi indexing; pipeline eval chỉ tốt khi source được xử lý đúng. Đối với tích hợp tool và MCP, xem thêm bài xây dựng MCP server với FastMCP để mở rộng RAG thành agentic workflow.
Lỗi thường gặp khi đánh giá RAG và cách tránh
Sau khi debug hàng chục pipeline eval sai, tôi thấy năm lỗi lặp đi lặp lại nhiều nhất trong các đội đang chuyển RAG từ prototype lên production.
1. Dùng cùng model để sinh và làm judge
Nếu gpt-4o sinh câu trả lời rồi gpt-4o chấm, điểm bị thổi lên trung bình 15–20%. Luôn dùng model khác họ (Claude 3.5 Sonnet chấm output GPT, và ngược lại), hoặc ít nhất là size khác. Judge độc lập là nguyên tắc số một của eval nghiêm túc.
2. Bỏ qua đánh giá theo thành phần
Chỉ đo end-to-end nghĩa là bạn biết pipeline hỏng nhưng không biết ở tầng nào. Luôn log riêng metric retrieval (precision, recall) và metric generation (faithfulness, relevancy). Không có phân tách này, debug thành đoán mò.
3. Đánh giá đa chiều trong một prompt
Đừng hỏi LLM chấm faithfulness, relevancy, precision cùng một lúc. Nghiên cứu của DeepEval cho thấy điểm số dao động > 25% khi rubric bị gộp. Mỗi metric một prompt riêng, dù chi phí API cao hơn.
4. Bỏ qua human review của synthetic dataset
Synthetic test case do LLM sinh trông rất hợp lý, nhưng thường chứa lỗi factual hoặc tham chiếu tài liệu không tồn tại. Luôn có domain expert review ít nhất 20% dataset tổng hợp trước khi dùng làm benchmark.
RAGAS và DeepEval khác nhau ở điểm nào cơ bản nhất?
RAGAS là framework function-call phù hợp cho khám phá metric và tạo golden dataset tổng hợp. DeepEval là framework pytest-native được thiết kế cho quality gate trong CI/CD. Nhiều đội production dùng cả hai trong các giai đoạn khác nhau của lifecycle.
Cần bao nhiêu câu hỏi trong golden dataset để đánh giá RAG có ý nghĩa?
Tối thiểu 50 cặp Q&A cho domain hẹp; 100–200 cho use case doanh nghiệp phức tạp. Dưới 30 case điểm số dao động ngẫu nhiên quá lớn để có ý nghĩa thống kê. Ưu tiên chất lượng và độ phủ edge case hơn số lượng.
Có thể chạy đánh giá RAG mà không cần ground truth không?
Có. Ba trong bốn metric cốt lõi (faithfulness, answer relevancy, context precision) là reference-free. Bạn chỉ cần ground truth để tính context recall. Đây là lý do tại sao đội mới có thể bắt đầu đo lường ngay lập tức mà không cần chờ dataset gán nhãn hoàn chỉnh.
Chi phí chạy đánh giá RAG production tốn bao nhiêu?
Với dataset 100 case dùng gpt-4o làm judge, một lần chạy đầy đủ RAGAS mất 1.5–2.5 USD và 8–12 phút. Với gpt-4o-mini, chi phí giảm còn 0.15–0.25 USD nhưng độ nhất quán giảm 8–12%. Production monitoring sampling 10% traffic thường tốn 50–200 USD/tháng.
Faithfulness thấp thì fix ở đâu, retriever hay LLM?
Faithfulness thấp gần như luôn là vấn đề tầng generation: prompt yếu, temperature quá cao, hoặc model bị lôi kéo bởi kiến thức nội tại. Xử lý bằng cách siết prompt (yêu cầu "chỉ trả lời từ ngữ cảnh"), giảm temperature xuống 0, và thêm citation forcing. Nếu context recall cũng thấp thì mới cần sửa retriever.
Hướng dẫn xây dựng MCP Server bằng Python và FastMCP 3.0 — từ cài đặt, code ví dụ thực tế, tích hợp Claude Desktop, đến deploy production với OAuth 2.1, OpenTelemetry và Docker.
