RAG tài liệu nội bộ: 4 lỗi trích dẫn sai nguồn, cách nhận ra

Câu trả lời RAG nguy hiểm nhất không phải là câu thừa nhận không biết. Đó là câu trông rất có căn cứ: diễn đạt trôi chảy, con số cụ thể, trích dẫn gắn cuối câu, và sai. Người đọc thấy trích dẫn thì ngừng kiểm tra. Con số đi vào báo cáo, vào email khách hàng, vào quy trình vận hành. Lỗi lúc này đang khoác một cái mác đáng tin. Bài viết của qbrin ngày 2026-08-09 nêu đúng cơ chế này. Trích dẫn chỉ ghi lại rằng đoạn văn A đã nằm trong cửa sổ ngữ cảnh khi mô hình viết khẳng định B. Trong pipeline RAG chuẩn, không có bước nào kiểm tra B có suy ra được từ A hay không. Trích dẫn là con trỏ, không phải bằng chứng.

Với tài liệu nội bộ, lỗi này còn nghiêm trọng hơn với tài liệu công khai. Người đọc không thể tự tra cứu nguồn bên ngoài để đối chiếu. Họ chỉ có đúng kho tài liệu nội bộ. Nếu trích dẫn trỏ sai chỗ, họ không có cách nào khác để phát hiện ngoài việc mở đúng tài liệu đó ra đọc. Bốn lỗi dưới đây là bốn cách mà một trích dẫn có vẻ đúng vẫn làm người đọc tin sai. Mỗi lỗi cần một cách phát hiện riêng. Một cách kiểm tra chung sẽ bỏ sót ít nhất một lỗi trong số đó.

1. Nguồn bịa đặt: trích dẫn trỏ tới tài liệu không tồn tại

Lỗi thứ nhất là trích dẫn bịa đặt: tài liệu được trích dẫn không tồn tại trong kho nội bộ. Mô hình sinh ra trích dẫn giống như sinh bất kỳ đoạn văn bản nào khác, theo mẫu cú pháp đã học. Một biên bản họp hay một chính sách nội bộ chưa từng được viết vẫn có thể xuất hiện. Nó xuất hiện với định dạng trích dẫn hoàn hảo. Qbrin mô tả chính xác điểm này. Nếu không có bước nào đối chiếu trích dẫn với kho tài liệu thật, trích dẫn giả và trích dẫn thật không phân biệt được. Việc phân biệt bằng mắt thường là không thể.

Cách phát hiện lỗi này là rẻ nhất và phải làm trước mọi cách khác: giải quyết trích dẫn (citation resolution). Mỗi trích dẫn trong câu trả lời phải được tra ngược về một tài liệu có thật trong kho. Tài liệu đó phải đúng mã tài liệu và đúng phiên bản. Trích dẫn nào không tra được thì câu trả lời đó bị chặn, không cần bàn tới nội dung đúng sai. Đây cũng là lý do kho tài liệu nội bộ cần mã định danh ổn định cho từng tài liệu và từng phiên bản. Nếu trích dẫn chỉ ghi tên tài liệu chung chung, bước tra ngược sẽ không thể kết luận được. Lỗi bịa đặt sẽ lọt qua dưới dạng trích dẫn mơ hồ.

Một biến thể tinh vi hơn của lỗi này là trích dẫn trỏ tới tài liệu có thật nhưng đã lỗi thời. Ví dụ: chính sách cũ đã bị thay thế. Về mặt kỹ thuật, trích dẫn vẫn giải quyết được, nhưng nội dung không còn hiệu lực. Vì vậy, bước tra ngược phải kiểm tra cả phiên bản và ngày hiệu lực. Bước này không dừng ở việc tài liệu có tồn tại hay không. Tài liệu nội bộ hay thay đổi như quy trình, bảng giá, chính sách nhân sự là chỗ nhiều hệ thống RAG bỏ sót.

2. Nguồn thật nhưng nội dung bịa: tài liệu có thật, câu trả lời không có trong đó

Lỗi thứ hai là lỗi mà doanh nghiệp gặp nhiều nhất, theo qbrin. Tài liệu có thật, nhưng khẳng định trong câu trả lời không hề nằm trong tài liệu đó. Cơ chế rất đời thường. Hệ thống truy xuất lấy về một đoạn văn cùng chủ đề với câu hỏi. Mô hình bị điều kiện hóa bởi đoạn văn đó nhưng không bị giới hạn trong đó. Vì vậy, nó điền con số hay chi tiết chính sách cụ thể từ kiến thức đã học trong quá trình huấn luyện. Trích dẫn gắn vào đoạn văn đã truy xuất, vì đoạn văn đó đã nằm trong ngữ cảnh. Lý do không phải là đoạn văn chứa khẳng định đó. Người đọc bấm vào trích dẫn, thấy đúng tài liệu, đúng chủ đề, rồi dừng lại trước khi đọc tới dòng cần kiểm tra. Khẳng định đó chưa bao giờ nằm trên trang.

Cách phát hiện lỗi này là kiểm tra suy ra (entailment check). Tách câu trả lời thành từng khẳng định nhỏ. Hỏi từng khẳng định có suy ra được từ đoạn văn được trích dẫn hay không. Datadog, trong bài công bố tính năng phát hiện ảo giác ngày 2025-05-28, phân biệt đúng hai nhóm cần gắn cờ ở đây. Nhóm thứ nhất là mâu thuẫn, tức khẳng định đi ngược trực tiếp với ngữ cảnh. Nhóm thứ hai là khẳng định không có căn cứ, tức phần câu trả lời không dựa trên ngữ cảnh đã cho. Với tài liệu nội bộ nhạy cảm, Datadog khuyên gắn cờ cả hai nhóm. Mô hình không được dùng thông tin ngoài ngữ cảnh hay tự suy luận thêm.

Khung đánh giá RAGAS, công bố năm 2023, đo chính điều này bằng chỉ số faithfulness. Câu trả lời được tách thành các khẳng định. Mỗi khẳng định được phán xét là có căn cứ hay không. Điểm số là tỉ lệ khẳng định có căn cứ trên tổng số khẳng định. Trong đánh giá WikiEval của chính nhóm tác giả, chỉ số faithfulness của RAGAS khớp với lựa chọn của người chấm ở mức 0,95. Mức này cao hơn hẳn cách chấm trực tiếp bằng prompt (0,72). Con số này thuộc về tập đánh giá đó, không phải tỉ lệ đúng chung cho mọi hệ thống. Nó cho thấy hướng kiểm tra đúng: đo từng khẳng định, không đo cảm giác chung về câu trả lời.

3. Trích dẫn đúng nhưng gắn sai giá trị: con số thật, đối tượng sai

Lỗi thứ ba khó phát hiện nhất, vì mọi thành phần trong câu trả lời đều có thật trong nguồn. Qbrin gọi đây là trích dẫn thật nhưng gắn kết bị vỡ (real quote, broken binding). Giữa đoạn văn được truy xuất và câu được sinh ra, một giá trị bị hoán đổi với giá trị gần đó. Hai cái tên đổi chỗ cho nhau. Một đơn vị rơi rụng khiến con số theo quý đọc thành con số theo tháng. Ngưỡng cũng có thể bị chép từ hàng kề bên trong bảng. Mọi nguyên liệu đều xuất hiện thật trong bằng chứng. Cách kiểm tra chỉ hỏi xem từ ngữ trong câu trả lời có xuất hiện đâu đó trong nguồn hay không. Cách kiểm tra đó sẽ cho qua lỗi này.

Cách phát hiện lỗi này là kiểm tra gắn kết số liệu (numeric binding check). Giá trị trong câu trả lời phải xuất hiện trong bằng chứng. Giá trị đó phải gắn với cùng một đối tượng, mang cùng một đơn vị, và cùng một kỳ hay cùng một điều kiện. Một con số doanh thu chỉ đúng khi nó gắn đúng với đúng quý, đúng đơn vị tiền tệ và đúng chi nhánh. Nó không đúng chỉ vì con số đó có xuất hiện đâu đó trong tài liệu. Với tài liệu nội bộ chứa nhiều bảng biểu, đây là lỗi hay gặp nhất ở các câu hỏi về số liệu. Đây cũng là lỗi mà kiểm tra bằng mắt thường dễ bỏ sót nhất. Người đọc thấy con số quen thuộc thì ngừng kiểm tra tiếp.

Một biện pháp phòng ngừa rẻ tiền cho lỗi này là yêu cầu hệ thống trả về cả đoạn trích nguyên văn. Đoạn trích đi kèm theo câu trả lời, thay vì chỉ trả về tên tài liệu. Khi đoạn trích nằm ngay cạnh câu trả lời, người đọc có thể đối chiếu giá trị, đối tượng và đơn vị trong vài giây. Người đọc không phải mở tài liệu và tìm lại đoạn liên quan. Đoạn trích không thay thế kiểm tra tự động. Nó rút ngắn thời gian phát hiện lỗi từ vài phút xuống vài giây. Đó là khác biệt giữa một lỗi bị bắt và một lỗi được chuyển tiếp.

4. Khẳng định đúng nhưng trích dẫn trang trí: câu đúng, bằng chứng không đỡ được câu đó

Lỗi thứ tư nghe có vẻ vô hại. Khẳng định đúng trong thực tế, nhưng đoạn văn được trích dẫn không hề chứng minh cho nó. Qbrin cảnh báo không nên bỏ qua lỗi này, vì trích dẫn trang trí tập cho cả tổ chức thói quen ngừng kiểm tra. Quy trình sinh ra khẳng định đúng tình cờ này cũng chính là quy trình sinh ra khẳng định sai. Tới ngày nó sai, trích dẫn sẽ trông y hệt như hôm nay. Một câu trả lời đúng vì may mắn không phải là một câu trả lời có căn cứ.

Cách phát hiện lỗi này nằm trong cùng một kiểm tra suy ra ở mục 2, nhưng với một quy tắc xử lý khác. Khẳng định đúng nhưng không suy ra được vẫn phải bị giữ lại hoặc viết lại có căn cứ. Khẳng định đó không được cho qua chỉ vì người kiểm tra biết nó đúng. Đây là điểm mà nhiều đội cảm thấy khó chịu nhất, vì nó làm tăng tỉ lệ từ chối trả lời. Nhưng qbrin nêu đúng cái giá của việc nới lỏng. Từ chối trả lời thì nhìn thấy được, có thể truy vết và có thể khắc phục bằng cách tìm tài liệu thật. Câu trả lời sai khoác trích dẫn thì không có đặc điểm nào trong ba đặc điểm đó.

Để đo mức độ nghiêm trọng của bốn lỗi, đừng chỉ đo tỉ lệ câu trả lời đúng trên tập câu hỏi thông thường. Hãy thêm câu hỏi bẫy. Đó là những câu hỏi mà kho tài liệu đã xác minh là không thể trả lời được. Ví dụ: hỏi về một thực thể không xuất hiện trong bất kỳ đoạn nào của kho. Câu hỏi cũng có thể mang tiền đề mà kho tài liệu mâu thuẫn. Một hệ thống tốt phải từ chối trả lời các câu bẫy này thay vì bịa ra câu trả lời có trích dẫn. Qbrin báo cáo trên bộ kiểm tra của riêng họ. Cổng kiểm tra của họ bắt được 211 trên 211 trích dẫn nguồn bịa đặt với 0 trường hợp chấp nhận sai. Cổng đó ghi nhận 0 câu trả lời bịa đặt trên 120 câu hỏi bẫy. Những con số này chỉ mô tả đúng bộ kiểm tra và kho tài liệu đó, không phải tỉ lệ chung. Phương pháp đo thì dùng được cho mọi đội: đếm câu trả lời bịa đặt trên câu hỏi bẫy, không đếm điểm cảm tính.

Bằng chứng từ nghiên cứu độc lập cho thấy vấn đề này không phải là trường hợp cá biệt. Nhóm Stanford RegLab kiểm tra các công cụ nghiên cứu pháp lý dùng RAG. Các sản phẩm này được xây dựng riêng để giải quyết bài toán truy xuất. Nhóm vẫn ghi nhận tỉ lệ ảo giác từ 17% đến 33% (Magesh và cộng sự, 2024). Ngay cả công cụ chuyên ngành, nơi trích dẫn sai có thể làm hỏng sự nghiệp của người dùng, vẫn sai ở mức đó. Vì vậy, một hệ thống RAG nội bộ không có cổng kiểm tra khó có thể tốt hơn chỉ nhờ gắn thêm trích dẫn.

Quy trình kiểm tra 4 bước trước khi tin một câu trả lời RAG

Kết luận thực hành cho đội xây RAG tài liệu nội bộ: đừng hỏi "câu trả lời có trích dẫn chưa". Hãy hỏi bốn câu sau theo thứ tự. Trích dẫn có tra được về tài liệu thật và phiên bản còn hiệu lực không. Từng khẳng định có suy ra được từ đoạn trích đó không. Con số có gắn đúng đối tượng, đơn vị và kỳ không. Và hệ thống có từ chối trả lời khi bằng chứng không đủ không. Chỉ khi cả bốn câu đều trả lời được bằng kiểm tra máy, trích dẫn mới bắt đầu có giá trị làm bằng chứng. Cách chọn mô hình truy xuất cho kho tài liệu tiếng Việt là bước đầu tiên của chuỗi kiểm tra này. Truy xuất sai thì mọi bước sau đều kiểm tra trên đoạn văn sai. Xem thêm: RAG tiếng Việt: chọn embedding nào. Khi hệ thống được cấp quyền truy cập thêm công cụ bên ngoài, hãy đối chiếu với hướng dẫn về chuẩn kết nối. Việc đối chiếu diễn ra trước khi mở quyền. Mỗi kết nối mới là một nguồn trích dẫn mới cần kiểm tra. Xem thêm: MCP là gì: hướng dẫn cho người mới. Và cách viết câu lệnh hệ thống cũng quyết định mô hình có chịu từ chối trả lời hay cứ bịa cho đủ câu. Cần viết rõ quy tắc trích dẫn ngay trong câu lệnh hệ thống. Xem thêm: prompt hệ thống cho agent bán hàng.

— Quang Minh, từ phòng đo kiểm 3A.