AI trả lời không có nguồn: làm sao kiểm soát citation?

Câu trả lời ngắn

Nếu AI cần trả lời dựa trên dữ liệu doanh nghiệp, đừng để model tự nghĩ ra citation hoặc URL. Citation nên được tạo từ metadata của tài liệu mà hệ thống thực sự truy xuất, gắn từng claim quan trọng với document_id/chunk_id, rồi qua một bước verifier kiểm tra bằng chứng có thật sự hỗ trợ claim hay không. Nếu không đủ bằng chứng, hệ thống phải bỏ claim, truy xuất lại hoặc trả lời rằng chưa đủ thông tin.

Một pipeline production nên là: Question → Retrieve → Rerank → Generate claims from evidence → Map claim ↔ source chunk → Verify → Answer or abstain → Log & evaluate. NIST khuyến nghị kiểm tra nguồn và citation trong cả giai đoạn đánh giá trước triển khai lẫn monitoring liên tục. Vì vậy, “prompt AI nhớ ghi nguồn” chỉ là quy tắc trình bày; nó không phải cơ chế kiểm soát citation.

Một chatbot có thể trông rất thuyết phục khi mỗi đoạn đều có [1], [2] hoặc một URL. Nhưng có ít nhất bốn failure mode khác nhau: không có nguồn, nguồn không tồn tại, nguồn tồn tại nhưng không chứa thông tin đã nói, và nguồn đúng chủ đề nhưng không đủ mạnh để chứng minh claim cụ thể.

Đây là lý do nên tách ba khái niệm. Provenance trả lời “đoạn dữ liệu này đến từ đâu?”. Citation cho người đọc biết claim đang dựa vào tài liệu nào. Grounding/entailment verification kiểm tra nội dung nguồn có thực sự hỗ trợ claim hay không. Hệ thống tốt cần cả ba thay vì coi chúng là một.

NIST đang thử nghiệm các evaluation probe đánh giá citation theo ba chiều rất hữu ích cho doanh nghiệp: faithfulness — nguồn có thực sự hỗ trợ claim; completeness — câu trả lời có phản ánh đầy đủ ý của nguồn thay vì chọn phần có lợi; và sufficiency — bằng chứng có đủ sức gánh claim đó hay không.

Ở lớp retrieval, truy vấn knowledge base và trả về các chunk kèm metadata gốc. Azure AI Search mô tả RAG theo hướng grounding LLM bằng nội dung được truy xuất; tài liệu hiện tại cũng hỗ trợ structured responses có grounding data, citations và execution metadata trong agentic retrieval. Với classic RAG, ứng dụng vẫn có thể tự giữ metadata này khi chuyển context sang model.

Ở lớp generation, chỉ cho phép model dựa trên evidence đã cấp và yêu cầu output có cấu trúc, chẳng hạn mỗi claim mang citation_ids tham chiếu tới ID có thật trong retrieval set. Backend resolve các ID đó thành title/location/URL từ metadata; không nhận một URL mới do model viết ra như nguồn hợp lệ.

Ở lớp verification, tách câu trả lời thành các claim cần bằng chứng và kiểm tra từng cặp claim ↔ cited chunk. Verifier có thể là rules, một model đánh giá riêng hoặc kết hợp nhiều lớp. Với claim quan trọng, một verdict đơn giản như supported | unsupported | insufficient dễ đưa vào policy hơn một câu nhận xét tự do.

1. Normalize question và xác định tenant, quyền truy cập, loại câu hỏi và yêu cầu freshness.
2. Retrieve candidate chunks từ nguồn được phép; hybrid search/reranking có thể giúp tăng chất lượng retrieval tùy workload.
3. Apply retrieval gate: nếu không có evidence đủ liên quan, dừng hoặc chuyển sang chiến lược tìm kiếm khác thay vì để model tự trả lời từ memory.
4. Generate structured answer chỉ từ evidence, với danh sách claim và citation ID.
5. Resolve citation IDs ở backend sang metadata đã lưu; ID không thuộc retrieval set là invalid.
6. Verify claim-evidence pairs theo faithfulness, completeness và sufficiency phù hợp với mức rủi ro.
7. Apply policy: claim unsupported thì bỏ/viết lại; evidence chưa đủ thì retrieve lại; câu hỏi không đủ evidence thì abstain.
8. Render citations cho người dùng ở mức hữu ích — document, section/page hoặc deep link nếu nguồn hỗ trợ.
9. Persist trace gồm source version, retrieved chunks, response, verifier verdict và model/config version để có thể tái hiện khi audit.

Điểm quan trọng: citation được render cuối pipeline, nhưng identity của nguồn phải tồn tại từ ingestion và retrieval. Không thể sửa bài toán provenance chỉ ở giao diện chat.

Với knowledge assistant nội bộ, có thể đặt policy: claim factual quan trọng phải có evidence, còn lời chào hoặc hướng dẫn điều hướng giao diện có thể không cần citation. Nếu retrieval trả về rỗng, tài liệu đã hết hiệu lực, quyền truy cập không xác minh được, source attribution bị mất hoặc verifier đánh dấu claim là unsupported, hệ thống không nên tự chuyển sang kiến thức nền của model mà không báo cho người dùng.

OWASP RAG Security Cheat Sheet khuyến nghị fail closed xuyên suốt RAG pipeline; ví dụ khi retrieval thất bại thì không fallback sang model memory, và trong môi trường yêu cầu attribution, không tạo được source attribution thì nên chặn response. OWASP cũng khuyến nghị trả source attribution tới document/chunk và provenance metadata, đồng thời bảo vệ tính toàn vẹn của attribution.

Policy nên theo risk tier. Câu hỏi chính sách nhân sự, giá, điều khoản, hướng dẫn vận hành hoặc dữ liệu khách hàng cần kiểm soát chặt hơn câu hỏi brainstorming. Với tác vụ có side effect, citation tốt vẫn chưa phải authorization: quyền thực hiện hành động phải được kiểm tra riêng.

Tạo một evaluation set từ các câu hỏi thật, bao gồm câu trả lời được hỗ trợ, câu hỏi thiếu dữ liệu, nguồn mâu thuẫn, tài liệu cũ, và câu hỏi cố truy cập dữ liệu không được phép. Mỗi test case nên có expected evidence hoặc expected abstention. Sau đó theo dõi ít nhất: citation faithfulness, citation coverage của các claim cần nguồn, unsupported-claim rate, abstention quality, retrieval recall trên bộ test và tỷ lệ citation resolve được về source thật.

Không nên đặt một threshold chung rồi coi mọi bài toán đã an toàn. Ngưỡng cần được calibrate theo domain và cost of error. Với verifier dùng LLM, lưu version model, prompt/rubric và sample để phát hiện drift. NIST GenAI Profile khuyến nghị review/verify citation trong pre-deployment measurement và ongoing monitoring; dự án evaluation probes của NIST cũng minh họa việc chạy probe trong workflow hoặc post-hoc và lưu structured audit trail.

Trong production, alert khi tỷ lệ unsupported, unresolved citation, retrieval empty hoặc abstain lệch mạnh khỏi baseline. Những tín hiệu này giúp phân biệt lỗi knowledge base, index, permission, prompt hoặc model change thay vì chỉ thấy người dùng nói “AI hôm nay trả lời kỳ”.

Bước 1 — Audit provenance. Kiểm tra mỗi chunk hiện có có document_id, source location, version/hash và ACL context đủ để truy ngược hay chưa.

Bước 2 — Đóng citation contract. Định nghĩa schema giữa retriever và generator; citation chỉ được tham chiếu các ID có trong context.

Bước 3 — Structured generation. Tách answer/claims/citation_ids thành dữ liệu có thể validate thay vì parse các [1] tự do từ markdown.

Bước 4 — Thêm verifier. Bắt đầu với claim quan trọng và ba câu hỏi: source có support claim không, có bỏ mất context làm đổi nghĩa không, và bằng chứng có đủ cho mức độ khẳng định không.

Bước 5 — Thêm abstention/re-retrieval. Không đủ evidence thì tìm lại với query khác hoặc trả lời có kiểm soát; không âm thầm dùng model memory nếu policy yêu cầu grounded answer.

Bước 6 — Xây golden set và CI gate. Chạy eval khi đổi chunking, embedding, retriever, reranker, prompt hoặc model.

Bước 7 — Monitor production. Lưu audit trace với chính sách retention phù hợp; theo dõi citation failures, permission failures và retrieval drift.

Nếu hệ thống hiện chỉ có prompt “hãy trích nguồn”, ưu tiên bước 1–3 trước. Đây là phần biến citation từ text trang trí thành một data contract có thể validate.

1. Chỉ cần prompt “luôn ghi nguồn” có đủ không?

Không. Prompt không chứng minh URL tồn tại hoặc source hỗ trợ claim. Source identity nên đến từ retrieval metadata và được backend validate.

2. Citation nên trỏ tới cả tài liệu hay đúng đoạn?

Nếu nguồn cho phép, nên giữ cả document identity và vị trí chi tiết như chunk, page hoặc section. Người dùng cần mở được tài liệu, còn verifier cần evidence đủ hẹp để đánh giá claim.

3. Mỗi câu đều phải có citation không?

Không nhất thiết. Nên xác định loại claim nào bắt buộc có bằng chứng theo risk tier. Các factual claim quan trọng dựa trên knowledge base nên được cite; nội dung thuần điều hướng hoặc hội thoại có thể áp dụng policy khác.

4. Nếu hai nguồn mâu thuẫn thì AI nên chọn một nguồn không?

Không nên âm thầm chọn. Ưu tiên có thể dựa trên authority, version và freshness đã định nghĩa; nếu xung đột vẫn có ý nghĩa, câu trả lời nên nêu sự khác biệt hoặc abstain để tránh tạo cảm giác chắc chắn giả.

5. RAG có loại bỏ hoàn toàn hallucination không?

Không. RAG giúp grounding bằng dữ liệu truy xuất nhưng vẫn có thể retrieve sai, dùng nhầm chunk hoặc diễn giải vượt quá evidence. Vì vậy retrieval quality, citation verification, evaluation và fail-closed policy vẫn cần thiết.