# RAG điểm cao mà người dùng vẫn thất vọng: đọc trace thật trước khi tin chỉ số

> Bảng điểm xanh chỉ trả lời những câu hỏi bạn đã đặt, còn lý do khách hàng thất vọng nằm trong các trace chưa ai đọc.

Bản gốc: https://fdetimes.net/vi/bach-khoa/rag-diem-benchmark-tot-nhung-nguoi-dung-that-van-that-vong/

Thử hình dung tuần thứ sáu của một deployment. Bạn mở buổi review với khách hàng bằng bảng điểm đẹp: faithfulness 0,94, answer relevance 0,91. Trưởng nhóm vận hành nghe xong rồi nói nhân viên của chị đã quay lại lục thư mục tài liệu như trước.

Bảng điểm đó không sai, nó chỉ trả lời một câu hỏi khác. Tài liệu về đánh giá RAG của Anyscale cảnh báo cả hai tầng của vấn đề: điểm cao trên benchmark công khai không bảo đảm hệ thống chạy tốt trên dữ liệu production theo từng domain, và điểm tuyệt đối về faithfulness, relevance cũng không bảo đảm người dùng hài lòng.

Với một FDE, khoảng cách này quyết định deployment sống hay chết, vì khách hàng nghiệm thu bằng công việc của họ chứ không bằng dashboard của bạn.

Đừng đi tìm một chỉ số có thể đoán trước chất lượng production. Việc bạn làm được là đi từ lỗi thật, chọn chỉ số cho từng loại lỗi, rồi kiểm tra từng chỉ số với người chấm và hành vi người dùng.

## Vì sao faithfulness không biết quy định đã hết hạn?

Ragas, framework được công bố năm 2023, hấp dẫn vì đánh giá không cần tham chiếu, tức không cần nhãn do người gán. Những tuần đầu tại khách hàng, bạn thường chưa có nhãn nào. Nó cũng tách chất lượng thành các chiều riêng: retrieval lấy đúng chưa, LLM có dùng ngữ cảnh một cách trung thực không, câu trả lời sinh ra tốt đến đâu.

Nhưng hãy đọc kỹ câu hỏi mà faithfulness đặt ra: câu trả lời có bám vào ngữ cảnh được đưa cho nó không? Nếu ngữ cảnh là bản quy định đã bị thay thế, câu trả lời bám rất chặt và vẫn sai với người dùng. Metric làm đúng việc của nó, chỉ là việc đó không trùng với việc của khách hàng.

Hamel Husain viết rằng các sản phẩm AI không thành công gần như luôn chung một nguyên nhân gốc: không xây được hệ thống đánh giá vững chắc. Lời khuyên của ông cũng cụ thể: soi trace và các failure mode để tìm ra cái gì thực sự hỏng. Vì thế, bước đầu tiên không phải chọn metric mà là đọc dữ liệu.

## Một trăm trace nói nhiều hơn mọi bảng điểm

Lấy một ví dụ giả định, mọi con số dưới đây đều do ta đặt ra để minh họa. Một công ty logistics dùng trợ lý RAG để nhân viên chăm sóc khách hàng tra quy định bồi thường. Bạn lấy 100 trace thật gần nhất, ngồi cùng nhân viên giỏi nhất của họ, và với mỗi trace ghi đúng hai thứ: đạt hay không đạt, và vì sao.

Kết quả là 31 trace không đạt. Gom các lý do lại, bạn được bảng sau:

| Loại lỗi | Số trace | Faithfulness có bắt được? | Bộ đo phù hợp |
|---|---|---|---|
| Không có tài liệu đúng trong top 20 | 14 | Thường không | 1 − recall@20 trên golden set |
| Trích bản quy định đã hết hiệu lực | 9 | Không | Tỷ lệ trích bản đã hết hiệu lực |
| Đúng nhưng dài, thiếu bước tiếp theo | 5 | Không | Chấm theo tiêu chí của chuyên gia |
| Nói điều tài liệu không có | 3 | Có | Faithfulness |

Chỉ 3 trong 31 lỗi thuộc đúng loại faithfulness sinh ra để bắt. Trong khi đó 23 lỗi (14 cộng 9) nằm ở retrieval và dữ liệu, nên tuần tiếp theo mà bạn ngồi tinh chỉnh prompt sẽ là một tuần phí phạm. Bảng này đáng giá hơn mọi con số trung bình, vì nó chỉ ra việc phải làm trước.

## Golden set: câu hỏi thật, mỗi loại lỗi một chỉ số

Anyscale khuyên tạo bộ test riêng phản ánh đúng use case thực, và 100 trace vừa đọc chính là nguyên liệu. Lấy 14 câu thiếu tài liệu đúng, 9 câu trích bản cũ, thêm 27 câu đã đạt để giữ các hành vi đang tốt, thành 50 câu. Chuyên gia nghiệp vụ xác nhận bản còn hiệu lực cho từng câu và đánh dấu các bản đã bị thay thế.

Về retrieval, Anthropic chọn một cách đo dễ hiểu là 1 − recall@20, tức tỷ lệ thất bại trong top 20 chunk. Bản quy định cũ thì cần phép đo riêng, vì nó có thể nằm trong top 20 cạnh bản mới mà recall vẫn báo đạt. Vài dòng Python là đủ để chạy cả hai:

```python
def failure_at_k(golden, retrieve, k=20):
    """Trả về 1 - recall@k và danh sách câu bị trượt để đọc lại."""
    recalls, misses = [], []
    for case in golden:
        top_ids = {c.doc_id for c in retrieve(case["query"])[:k]}
        expected = set(case["expected_doc_ids"])
        recall = len(top_ids & expected) / len(expected)
        recalls.append(recall)
        if recall < 1:
            misses.append(case["query"])
    return 1 - sum(recalls) / len(recalls), misses


def stale_citation_rate(golden, answer):
    """Trả về tỷ lệ câu trả lời trích bản hết hiệu lực và danh sách câu đó."""
    stale = []
    for case in golden:
        cited = set(answer(case["query"]).cited_doc_ids)
        if cited & set(case["stale_doc_ids"]):
            stale.append(case["query"])
    return len(stale) / len(golden), stale
```

Đi tiếp với ví dụ giả định: mỗi câu có một tài liệu đúng, và ở cả 9 câu trích bản cũ, bản mới vẫn nằm trong top 20. Lần chạy đầu, 1 − recall@20 chỉ báo 14 trên 50 câu, tức 28%, còn 9 câu kia lọt qua. Hàm thứ hai mới thấy chúng: 9 trên 50 câu, tức 18%.

Các con số này không phải tỷ lệ lỗi thật của hệ thống, vì bộ test cố tình nhồi ca khó; chúng chỉ dùng để so trước và sau.

Hai loại lỗi cần hai cách sửa. Bạn gỡ các bản cũ khỏi index, số câu trích bản cũ còn 1, tức 2%, và câu đó cho biết vẫn có tài liệu chưa gắn đúng phiên bản. Bạn thêm reranking, số câu trượt top 20 còn 8, tức 16%, rồi đọc tiếp danh sách `misses`.

Anthropic báo cáo phương pháp contextual retrieval của họ giảm được 49% số lần retrieval thất bại, và 67% khi kết hợp reranking. Hãy xem đó là bằng chứng rằng retrieval là chỗ đáng đầu tư, không phải kết quả bạn có thể hứa với khách hàng. Đúng tinh thần cảnh báo của Anyscale, con số ấy phải được đo lại trên dữ liệu của họ.

## Metric tự động phải qua kỳ kiểm tra của con người

Một nghiên cứu đăng trên arXiv tháng 7/2026 so các metric của Ragas, DeepEval, RAGChecker và Opik với điểm của hai người đánh giá và các chỉ số chuẩn như recall. Bạn nên mượn ý tưởng so sánh đó ở phiên bản rút gọn cho công việc tại khách hàng. 50 trace và một buổi chiều là quy mô dành cho bạn, không phải thiết lập của nghiên cứu.

Hai người chấm độc lập, thường là bạn và một chuyên gia nghiệp vụ. Sau đó cả hai ngồi lại xem những trace lệch kết luận và thống nhất theo tiêu chí đã chốt; nếu vẫn không ngã ngũ, chuyên gia nghiệp vụ quyết định. Mỗi trace lúc này chỉ còn một kết luận chung.

Giờ chạy metric tự động trên cùng 50 trace. Con số cần xem là số trace metric cho qua nhưng kết luận chung đánh trượt. Giả sử metric cho qua 40 trace và 13 trong số đó bị đánh trượt: 32,5% số trace được cho qua thực ra không đạt.

Khi đó có hai lựa chọn. Hoặc chỉnh ngưỡng và chạy lại, hoặc hạ metric xuống vai trò còi báo động: chạy hằng ngày trên traffic để bắt tụt điểm đột ngột, nhưng không dùng làm tiêu chí nghiệm thu.

Nếu chính hai người chấm thường xuyên bất đồng, vấn đề nằm ở chỗ chưa ai định nghĩa thế nào là đạt, và đó phải là cuộc họp tiếp theo của bạn.

**Điểm mấu chốt:** Một chỉ số chỉ đáng tin khi đã được đối chiếu với người dùng thật trên dữ liệu thật.

## Người dùng đã chấm điểm, chỉ là chưa ai ghi lại

Eugene Yan xem vòng phản hồi của người dùng, gồm cả phản hồi ngầm, là cách đánh giá hiệu năng tổng thể của hệ thống trong production. Với trợ lý ở công ty logistics kia, thumbs down sẽ hiếm, nên hành vi mới là nguồn chính: hỏi lại ngay sau khi nhận câu trả lời, mở tài liệu nguồn rồi vẫn gọi đồng nghiệp, chuyển sang kênh hỗ trợ khác.

Đừng mặc định tín hiệu nào cũng đúng. Mở tài liệu nguồn có thể là nghi ngờ, cũng có thể là kiểm tra có trách nhiệm trước khi trả lời khách. Vì thế mỗi tuần hãy lấy mẫu các trace có tín hiệu xấu và đọc: tín hiệu nào đi cùng trace bị chấm trượt thì giữ lại làm chỉ báo sớm.

Vòng này chỉ sống nếu việc đọc trace đủ dễ. Husain viết rằng bạn phải gỡ bỏ mọi ma sát khỏi quá trình nhìn vào dữ liệu. Nếu xem một trace cần ba công cụ và một câu SQL, sau tuần thứ hai sẽ không còn ai đọc nữa.

## Những cái bẫy biến eval thành đồ trang trí

Bẫy phổ biến nhất là golden set do kỹ sư tự nghĩ ra câu hỏi. Những câu đó thường viết đúng thuật ngữ trong tài liệu, trong khi người dùng thật gõ tắt, gõ sai và hỏi theo tình huống. Điểm cao khi đó chỉ cho thấy hệ thống trả lời tốt những câu do chính người xây nó nghĩ ra.

Bẫy thứ hai là gộp mọi thứ thành một điểm trung bình, khiến một loại lỗi nghiêm trọng biến mất sau hàng trăm câu dễ.

Trả lời sai mức bồi thường gây hậu quả nặng hơn nhiều so với một câu trả lời hơi dài, nên hãy báo cáo theo loại lỗi.

Khách hàng cũng dễ hành động hơn khi nghe "9 câu dùng quy định cũ" so với "điểm giảm 0,03".

Bẫy thứ ba là đóng băng bộ test. Tài liệu đổi, người dùng đổi cách hỏi, và golden set của tháng trước dần đo một hệ thống không còn tồn tại, nên mỗi lần đọc trace hãy bổ sung các ca lỗi mới. Bẫy cuối là tự chấm một mình: bạn không đủ kiến thức nghiệp vụ để biết câu trả lời nghe hợp lý nhưng sai ở đâu.

## Kỹ năng này thể hiện thế nào khi đi xin việc?

Khi đọc JD của một vị trí FDE về AI, hãy chú ý những từ như evals, error analysis, production feedback. Trong phỏng vấn, hỏi ngược: nhóm chấp nhận một deployment RAG dựa trên tiêu chí nào, và ai đọc trace? Câu trả lời cho bạn biết công việc là deployment thật hay chỉ là demo kéo dài.

Trên CV, thay "xây RAG pipeline" bằng một câu có cả quy trình lẫn kết quả, với số liệu thật của bạn: đã đọc bao nhiêu trace cùng người dùng, tìm ra loại lỗi nào, đưa 1 − recall@20 từ mức nào xuống mức nào.

Nếu chưa có khách hàng, hãy làm trên một bộ tài liệu công khai, nhờ một người ngoài ngành đặt câu hỏi và công bố cả phần phân loại lỗi.

Bài tập của tuần này: lấy 30 trace thật của hệ thống bạn đang làm, chấm tạm đạt hay không đạt, rồi nhờ một chuyên gia nghiệp vụ xác nhận lại. Sau đó đếm xem metric hiện tại bắt được bao nhiêu lỗi trong số đã xác nhận. Nếu con số ấy thấp, bạn đã biết buổi review tới với khách hàng nên mở đầu bằng slide nào.

**Thử ngay tuần này:**

- Dựng một trang xem trace đơn giản: câu hỏi, các chunk đã lấy, câu trả lời, phản hồi và nút đạt/không đạt trên cùng một màn hình.
- Xin 30 phút với một chuyên gia nghiệp vụ của khách hàng để cùng chốt tiêu chí thế nào là câu trả lời đạt.
- Log ba tín hiệu ngầm: hỏi lại ngay sau khi nhận câu trả lời, mở tài liệu nguồn, chuyển sang kênh hỗ trợ khác.

## Nguồn

- [RAG evaluation](https://docs.anyscale.com/rag/evaluation)

- [Ragas: Automated Evaluation of Retrieval Augmented Generation](https://arxiv.org/abs/2309.15217)

- [Your AI Product Needs Evals](https://hamel.dev/blog/posts/evals/)

- [Introducing Contextual Retrieval](https://www.anthropic.com/news/contextual-retrieval)

- [Evaluating RAG Metrics in Applied Contexts: An Experiment, Its Findings and Its Limitations](https://arxiv.org/abs/2607.07302)

- [Patterns for Building LLM-based Systems & Products](https://eugeneyan.com/writing/llm-patterns/)