AI trả lời sai số liệu: grounding bằng MCP và RAG production

Bạn hỏi assistant một con số cụ thể — mức phí năm nay, hạn mức mới, giá gói dịch vụ — và nó trả lời dứt khoát bằng số của năm ngoái. Không có cảnh báo, không có dấu hiệu nghi ngờ, chỉ là một câu trả lời sai nghe rất chắc chắn. Bài này đi qua hai lớp kỹ thuật để xử lý đúng gốc vấn đề: đưa số liệu thật vào qua MCP, và vận hành RAG ở mức production thay vì mức tutorial.

Lỗi không nằm ở model, nằm ở dữ liệu

Một developer xây site so sánh bảo hiểm y tế Hà Lan mô tả ca điển hình: hỏi assistant mức khấu trừ bảo hiểm y tế bắt buộc của Hà Lan cho năm 2027, bạn thường nhận được 385 euro. Đó là con số của 2026. Con số 2027 là 400 euro.

Tác giả tóm đúng bản chất: "The model isn't broken. It was trained on last year's data and has no idea it's stale." Với phần lớn chủ đề thì không sao. Với một lĩnh vực mà giá, phạm vi chi trả và hợp đồng thay đổi hằng năm, kết quả là những câu trả lời sai một cách tự tin.

Đây là bug dev Việt Nam gặp khi ghép LLM vào sản phẩm có bảng giá hay hạn mức đổi theo năm. Prompt kỹ hơn không sửa được: model thiếu dữ liệu, không phải không hiểu câu hỏi.

Lớp 1: đưa số liệu thật vào qua MCP server

Hướng xử lý trong bài là dựng một MCP server cấp số liệu hiện hành kèm nguồn cho ChatGPT, Claude, Cursor, VS Code và Gemini CLI. Vài quyết định kiến trúc đáng mượn:

• MCP server stateless chạy trên Cloudflare Worker, với 12 tool chỉ-đọc, và "one response envelope with sources and assumptions" — mỗi phản hồi đi kèm nguồn và giả định, không trả số trần trụi.
• Engine thuần, tất định, có version viết bằng TypeScript với golden test, dùng chung cho cả MCP server, site SSR và browser. Một logic tính toán, ba nơi gọi.
• Cùng handler nằm sau một REST API, nên MCP không phải là một nhánh code riêng phải bảo trì song song.

Phần pipeline dữ liệu mới là chỗ quyết định độ tin cậy. Theo mô tả của tác giả: 607 tài liệu từ các hãng bảo hiểm được đưa qua Claude để trích xuất dữ liệu có cấu trúc, rồi qua bước validation và diff với năm trước, rồi con người review từng thay đổi — 8.540 mục đã review, 1.407 mục bị loại.

Tỷ lệ loại đó đáng chú ý: trích xuất bằng LLM không phải bước cuối. Định xây nguồn dữ liệu để assistant trích dẫn thì phải tính sẵn ngân sách cho vòng review thủ công và bước diff giữa hai kỳ.

Lớp 2: năm chỗ RAG tutorial không nói

Một developer khác kể lại việc đưa prototype RAG lên production. Sau hai tuần, hệ thống trả lời cũ, đốt ngân sách LLM, và bị gắn cờ hallucination mà chỉ số retrieval nói là không thể xảy ra.

1. Chỉ số retrieval nói dối khi lên production

Test set của bạn nhỏ, chọn lọc, thiên về câu hỏi đã biết có đáp án trong corpus. Query thật đến từ góc khác: sai chính tả, thiếu ngữ cảnh, hỏi thứ tài liệu không đề cập, hoặc hỏi xuyên nhiều tài liệu. Theo tác giả, Recall@5 trên test set không dự đoán được chất lượng production. Thứ dự đoán được là một query log 7 trường — query, chunk ID đã lấy, câu trả lời sinh ra, hành động của user, latency, cost, timestamp — cộng với kỷ luật thật sự ngồi đọc các dòng tệ mỗi tuần.

2. Chunking và chi phí re-embed

Tác giả cho rằng chiến lược chunking âm thầm lấy đi 30-50% chất lượng retrieval, và khuyến nghị: semantic chunking cho tài liệu dạng tường thuật, structural chunking cho code và markdown, parent-child retrieval cho PDF có bảng. Chi tiết dễ bỏ qua nhất là một cột version cho chunker, để re-embed có chọn lọc thay vì re-embed lại toàn bộ corpus mỗi lần chỉnh chiến lược. Tác giả cho biết mẫu delta-reindex — hash từng chunk, chỉ re-embed chunk đã đổi — cắt 99% chi phí embedding khi corpus chỉ sửa nhỏ. Đây là con số tác giả đưa ra, hãy tự đo trên corpus của bạn trước khi đưa vào kế hoạch chi phí.

3. Hình dạng chi phí của vector DB

Theo bài viết, billing theo read-unit của Pinecone trông rẻ ở mức 100 query/ngày; ở mức 10.000 query/ngày nó vượt qua mức giá phẳng của Qdrant Cloud. pgvector miễn phí nếu bạn đã chạy Postgres — cho tới khi bạn quên tạo index HNSW và mỗi query biến thành sequential scan. Tác giả chốt: câu hỏi đúng không phải "vendor nào tốt nhất", mà là "what's my query volume in 6 months, and what's my ops capacity?"

4. Eval harness

Không có eval harness thì mọi lần chỉnh prompt chỉ là cảm tính. Bài viết nêu điều kiện để LLM-as-judge dùng được: ghim model dùng làm judge, hiệu chỉnh rubric, và kiểm tra mức đồng thuận giữa các lượt chấm. Theo tác giả, 50 query trong test set là đủ để có tín hiệu thật, với điều kiện test set được xây theo một quy trình review 5 bước có người tham gia, chứ không phải scrape query mù quáng.

5. Observability của RAG khác observability của API

Khuyến nghị rất cụ thể: chỉ ba alert — retrieval trả về zero chunk, cost per query vượt ngưỡng, p95 latency phá SLO. Mọi thứ còn lại đưa lên dashboard xem hằng tuần, không đưa vào pager. Kèm theo là một script debug nhận query, replay lại retrieval, in ra các chunk lấy được và chỉ rõ chunk nào LLM thực sự dùng. Không có script này, mỗi khiếu nại "câu trả lời sai" tốn khoảng một giờ để truy.

Chọn lớp nào cho bài toán của bạn

Tình huống	Hướng phù hợp
Số liệu có thẩm quyền, thay đổi theo kỳ, cần trích dẫn nguồn	MCP server chỉ-đọc, envelope kèm nguồn, engine tất định có golden test
Khối tài liệu lớn, câu hỏi mở, không có một bảng số duy nhất	RAG, kèm query log, chunker có version và eval harness
Cả hai	Dùng MCP cho con số, RAG cho phần diễn giải — đừng để RAG đoán số

Việc nên làm trước khi ghép LLM vào sản phẩm có số liệu

• Liệt kê mọi con số trong sản phẩm thay đổi theo kỳ — đó là danh sách thứ model sẽ trả lời sai.
• Bật query log 7 trường ngay từ ngày đầu — bổ sung sau sẽ mất đúng giai đoạn dữ liệu cần nhất.
• Thêm cột version cho chunker trước lần re-embed đầu tiên, không phải sau.
• Dựng đúng ba alert, phần còn lại để dashboard.
• Nếu trích xuất dữ liệu bằng LLM, giữ bước diff giữa hai kỳ và vòng review của con người.

Đáng theo dõi tiếp: khi càng nhiều assistant hỗ trợ MCP, lợi thế sẽ nghiêng về bên có nguồn dữ liệu sạch, có version và trích dẫn được — chứ không phải bên có prompt khéo hơn.