Chính xác, có trích dẫn và lỗi thời hai năm: Đo lường hiện tượng rò rỉ phiên bản trong RAG

Hệ thống RAG được xây dựng dựa trên chín bản sửa đổi thường niên của các quy định mua sắm liên bang Mỹ nhằm trả lời các câu hỏi tính đến mốc thời gian cụ thể ("as of"). Mô hình RAG thông thường trả lời sai phiên bản tới 80% số trường hợp — dù câu trả lời trôi chảy và có trích dẫn đầy đủ. Việc bổ sung cơ chế xử lý ngày tháng khắc phục triệt để vấn đề này mà không làm suy giảm độ bao phủ (recall). Phạm vi nghiên cứu: Giới hạn trong FAR/DFARS, các bản sửa đổi theo chu kỳ năm (2017–2025), văn bản thuộc phạm vi công cộng của Mỹ, sử dụng một mô hình sinh cục bộ 1,8B tham số, giải mã tham lam (greedy decoding), không dùng LLM làm giám khảo (việc đánh giá độ bao hàm thực hiện bằng so khớp chuỗi). Đây là nghiên cứu đo lường kỹ thuật, không cấu thành tư vấn pháp lý. Vấn đề chưa từng được đo kiểm chuẩn Các quy định pháp luật luôn thay đổi. Hạn mức mua sắm vi mô biến động, các điều khoản được đánh số lại, các đoạn văn được thêm mới hoặc bãi bỏ. Một hệ thống RAG xử lý kho ngữ liệu mà không tính đến yếu tố thời gian sẽ dùng văn bản năm 2024 để trả lời cho câu hỏi năm 2022 — trích dẫn chính xác nhưng nội dung hoàn toàn sai lệch. Hiện tượng này được gọi là "rò rỉ phiên bản" (version leakage). Trước nghiên cứu này, chưa có bộ đo chuẩn (benchmark) mở nào đo lường hiện tượng trên đối với kho dữ liệu có lịch sử mốc thời gian chính thức. Do đó, một bộ dữ liệu thử nghiệm đã được thiết lập gồm: 15.485 mục × 9 bản sửa đổi (90.301 phiên bản) trong cơ sở dữ liệu Postgres với các dải thời gian hai chiều (bitemporal ranges), 12.456 cặp năm có thay đổi, cùng 6.920 câu hỏi được tạo từ các khác biệt thực tế (trong đó 1.000 câu dùng để kiểm thử cố định, 200 câu được chọn để kiểm tra thủ công). Xử lý ngày tháng hầu như không ảnh hưởng đến độ bao phủ, đồng thời triệt tiêu hiện tượng rò rỉ Hệ thống recall@5 Cung cấp sai phiên bản …sai về bản chất RAG lai thông thường (plain hybrid RAG) 0,70 0,80 0,32 + bộ lọc năm (+ year filter) 0,72 0,65 0,28 + đồ thị phiên bản + xếp hạng lại (+ version graph + rerank) 0,84 0,00 0,00 Tra cứu trực tiếp theo mục (section lookup - đối chứng gian lận) 0,99 0,83 0,66 Bảng đánh giá gồm hai cột phản ánh lỗi rò rỉ, do tiêu chí rò rỉ nghiêm ngặt có thể phản ánh quá mức: một đoạn văn bản năm 2020 trả về cho câu hỏi năm 2021 vẫn bị tính là lỗi ngay cả khi nội dung trùng khớp tuyệt đối từng byte. Tỷ lệ rò rỉ thực chất (sai phiên bản VÀ nội dung mục đó thực sự có thay đổi) mới phản ánh đúng thực tế — và thứ bậc hiệu quả giữa các phương pháp vẫn giữ nguyên ở cả hai tiêu chí. Đáng chú ý là phương pháp ưu tiên SQL (sql-first): đạt độ bao phủ gần như tuyệt đối nhưng lại có tỷ lệ rò rỉ thực chất cao nhất. Việc tìm đúng mục quy định là không khó; thách thức then chốt nằm ở việc xác định chính xác phiên bản áp dụng. Mô hình tạo sinh có hiện tượng lặp lại nguyên văn (được đo lường độc lập thay vì bỏ qua) Lượt chấm điểm ban đầu cho thấy phương pháp tiếp cận theo hướng tác tử (agentic) đạt kết quả trả lời cao nhất (0,21 so với 0,03–0,16). Tuy nhiên, khi loại bỏ phần văn bản bằng chứng trích dẫn trong câu trả lời và chấm điểm lại, kết quả chỉ còn 0,075. Mô hình 1,8B có xu hướng sao chép nguyên văn các đoạn dữ liệu; điểm số vượt trội trước đó thực chất chỉ phản ánh việc trích xuất khối lượng bằng chứng dài hơn, chứ không phải chất lượng câu trả lời tốt hơn. Tất cả các phương án đều có khả năng tổng hợp nội dung ở mức khiêm tốn, dao động trong khoảng 0 đến 0,08. Cả hai thông số đều được công bố đầy đủ: phát hiện then chốt nằm ở hiệu quả phân tầng truy xuất; khâu tạo sinh đòi hỏi một mô hình mạnh hơn. Hai vấn đề kỹ thuật trong môi trường triển khai thực tế Bộ nhớ đệm bằng chứng dùng khóa văn bản thuần túy (text-keyed evidence cache) trả về dữ liệu sai phiên bản tới 49 trên 50 trường hợp — do đó bắt buộc phải đưa tham số ngày tháng vào khóa bộ nhớ đệm, hoặc không áp dụng bộ nhớ đệm. Một kết quả phủ định đáng chú ý khác: tìm kiếm vector có lọc vẫn duy trì độ bao phủ ở mức 1,0 ngay cả khi độ chọn lọc (selectivity) giảm xuống 0,01% ở cả hai chế độ quét. Hiện tượng sụt giảm hiệu năng nghiêm trọng từng được ghi nhận trong các báo cáo khác có thể chỉ xuất hiện trên các bộ chỉ mục có quy mô lớn hơn nhiều so với mức 101.000 vector của thử nghiệm này. Chi phí vận hành hệ thống Thời gian xử lý: BM25 đạt khoảng 1 ms, tìm kiếm dày đặc (dense search) mất 0,15 giây, xếp hạng lại (rerank) mất 15–20 giây trên CPU (chiếm 80% tổng tài nguyên thời gian — cần chuyển sang xử lý trên GPU), và khâu tạo sinh mất 3,5 giây. Toàn bộ mã nguồn, các tệp dữ liệu không kèm trọng số và số liệu thống kê chi tiết được dẫn liên kết ở phần dưới.