Chuyển đến nội dung
MINH VO Ghi chép từ công việc
của một kỹ sư tại Việt Nam
Cơ bản10 phút đọc

Xây dựng quy trình RAG có bằng chứng kiểm tra được

Theo dõi câu hỏi chính sách qua truy xuất, ghép ngữ cảnh và trích dẫn; tái hiện lỗi mất ngoại lệ để chọn đúng bước cần sửa.

Sổ tay mở với các hình khối trừu tượng và sợi chỉ màu ô liu nối những mảnh giấy

Với lập trình viên đã quen với hàm xử lý yêu cầu và mã định danh tài liệu, retrieval-augmented generation, thường gọi là RAG, là cách cung cấp thông tin bên ngoài cho mô hình ngôn ngữ khi tạo câu trả lời. Trong ứng dụng, quy trình thường gồm tìm tài liệu, chọn đoạn liên quan và đưa chúng vào đầu vào của mô hình. Mỗi bước có thể hỏng riêng. Vì vậy, một hệ thống hữu ích cần lưu đủ dấu vết để xác định câu trả lời sai từ đâu.

Xét câu hỏi giả định của nhân viên: “Tôi có bao nhiêu ngày để nộp hóa đơn công tác?” Kho tài liệu có quy định cũ cho phép 30 ngày và quy định hiện hành cho phép 14 ngày. Câu trả lời trôi chảy nhưng dùng sai số ngày vẫn là lỗi, kể cả khi bộ tìm kiếm đã tìm thấy tài liệu về hóa đơn.

Giữ danh tính tài liệu từ lúc nhập dữ liệu

Khi nhập tài liệu, lưu mã tài liệu ổn định, mã phiên bản, ngày công bố hoặc ngày hiệu lực nếu có, cùng thông tin quyền truy cập. Mỗi chunk, tức đoạn được tách để truy xuất, phải giữ được danh tính tài liệu gốc. Nếu đoạn chỉ còn “trong vòng 14 ngày” nhưng mất tiêu đề “hóa đơn công tác”, việc diễn giải đúng về sau sẽ khó hơn.

Hai bản ghi giả định sau cho thấy điều cần giữ:

ChunkPhiên bảnTrích đoạnTrạng thái
expense-r3-12Phiên bản 3Nộp hóa đơn công tác trong vòng 30 ngàyĐã bị thay thế
expense-r4-09Phiên bản 4Nộp hóa đơn công tác trong vòng 14 ngàyHiện hành

Kết quả truy xuất chứa nhiều hơn một chuỗi văn bản. Bộ tạo câu trả lời và người kiểm tra đều cần biết phiên bản nào làm căn cứ cho số ngày. Các mã ở đây phục vụ ví dụ, không phải dữ liệu chính sách có thật.

Có thể lập chỉ mục bằng tìm kiếm từ khóa, embedding hoặc kết hợp cả hai. Bài báo RAG gốc kết hợp bộ truy xuất với bộ sinh cho các tác vụ cần kiến thức. Ứng dụng không phải tái tạo kiến trúc huấn luyện của bài báo để sử dụng truy xuất bên ngoài, nhưng cần mô tả đúng thiết kế của mình khi bàn về kết quả.

Luồng RAG chọn quy định hiện hành 14 ngày, ghép bằng chứng có nhãn và kiểm tra mã trích dẫn trong câu trả lờiMở ảnh kích thước đầy đủ ↗

Hình mô tả đường đi để trả lời về chính sách hiện hành. Bộ lọc quyền truy cập và phiên bản phải chạy trước khi ghép ngữ cảnh. Nếu tìm rộng rồi yêu cầu mô hình bỏ qua tài liệu không được phép đọc, nội dung ấy vẫn đã đến mô hình và có thể xuất hiện trong log.

Truy xuất ứng viên rồi ghép bằng chứng

Một truy vấn có thể trả về mười đoạn ứng viên. Danh sách đó chưa chắc là ngữ cảnh cuối cùng gửi cho mô hình. Cần bỏ đoạn trùng lặp, giữ phần lân cận hữu ích và bảo đảm đoạn được chọn còn đủ điều kiện để hiểu đúng. Câu “14 ngày” dễ gây hiểu nhầm nếu đoạn bên cạnh cho một loại chuyến đi thời hạn dài hơn.

Với câu hỏi trên, ngữ cảnh có thể gồm quy định hiện hành và một đoạn ngoại lệ. Gán nhãn ổn định như P1, P2, rồi yêu cầu mô hình ghi nhãn cạnh nhận định mà đoạn tương ứng hỗ trợ. Ứng dụng phải từ chối nhãn không tồn tại và ánh xạ nhãn được chấp nhận về bản ghi nguồn thật.

Chuỗi trích dẫn trông hợp lý rất dễ được sinh ra. Một đường dẫn có vẻ chính thức chưa đủ để chứng minh nó đúng. Bộ sinh nên chọn từ các mã bằng chứng do ứng dụng cung cấp. Việc dựng URL từ bảng ánh xạ này cũng tránh phải tin một đường dẫn tùy ý do mô hình tạo.

Đầu vào có thể nêu rõ quy định hiện hành là căn cứ áp dụng, còn tài liệu đã bị thay thế không được quyết định đáp án. Tốt hơn hết, bước xử lý phiên bản đã loại quy định cũ khỏi tập ứng viên. Chỉ dẫn giúp làm rõ nhiệm vụ nhưng không nên là biện pháp duy nhất chống dùng nguồn lỗi thời.

Làm cho câu trả lời có thể kiểm tra lại

Một đáp án tối thiểu có thể viết: “Chính sách công tác hiện hành yêu cầu nộp trong vòng 14 ngày, trừ trường hợp ngoại lệ trong tài liệu được cung cấp [P1, P2].” Câu này có đúng hay không còn phụ thuộc nội dung thực tế của P2. Nếu ngoại lệ chỉ áp dụng cho công tác quốc tế, đáp án phải giữ điều kiện ấy.

Theo chính sách bảo vệ dữ liệu phù hợp, lưu truy vấn, mã chunk đã chọn, mã phiên bản nguồn, phiên bản prompt, định danh mô hình và câu trả lời. Có thể không cần sao chép toàn bộ tài liệu vào log nếu đã có bản chụp nguồn có thể phục hồi và được kiểm soát truy cập. Mục đích là dựng lại đường đi của bằng chứng mà không nhân bản tài liệu nhạy cảm vào nơi lưu trữ thiếu bảo vệ.

Người đánh giá sau đó có thể hỏi từng việc: truy xuất có tìm được quy định hiện hành không, bước ghép ngữ cảnh có giữ điều kiện không, đáp án có chỉ đưa ra nhận định được hỗ trợ không, và trích dẫn có gắn đúng nhận định không. Một nhãn tổng quát “câu trả lời tốt” sẽ che mất các khác biệt này.

Tái hiện trường hợp mất đoạn ngoại lệ

Cụ thể hóa quy định giả định: phiên bản 4 cho phép 21 ngày đối với công tác quốc tế; các chuyến đi khác giữ mức 14 ngày. Đặt mã đoạn ngoại lệ là expense-r4-10. Với câu hỏi riêng về công tác quốc tế, người đánh giá đánh dấu cả hai chunk hiện hành là bắt buộc. Đây là đáp án chuẩn do con người viết cho ví dụ, không phải nhãn suy ra từ điểm tương đồng.

Giả sử bộ truy xuất trả về cả hai đoạn, nhưng giới hạn độ dài ngữ cảnh làm rơi đoạn ngoại lệ. Trích dẫn tới quy định 14 ngày vẫn có thể là mã thật, tra cứu được, trong khi câu trả lời thiếu thông tin cần thiết. Nếu chỉ kiểm tra danh sách truy xuất, ta sẽ bỏ sót lỗi này. Phải lưu ngữ cảnh sau bước cắt cuối cùng; bản xem trước của một bước ghép trước đó không chứng minh mô hình thực sự nhận được gì.

Hàm Python sau so sánh mã ở các bước. Đầu vào gồm tập mã chunk bắt buộc không rỗng, dãy mã đã truy xuất, ánh xạ nhãn ngữ cảnh cuối về mã chunk và các nhãn trích dẫn trong đáp án. Giả định bên gọi đã kiểm tra kiểu dữ liệu và ghi lại đúng yêu cầu gửi đi. Nếu mở rộng sang đoạn cha, các đoạn được thêm cũng phải có trong danh sách truy xuất/mở rộng đã ghi nhận.

def diagnose(required, retrieved, context, citations):
    if not required:
        raise ValueError("required evidence must be annotated")
    found = set(retrieved)
    supplied = set(context.values())
    checks = {
        "retrieval_miss": required - found,
        "context_loss": (required & found) - supplied,
        "unrecorded_context": supplied - found,
        "unknown_citation": set(citations) - set(context),
    }
    return {name: sorted(ids) for name, ids in checks.items() if ids}

required = {"expense-r4-09", "expense-r4-10"}
retrieved = ["expense-r4-09", "expense-r4-10"]
context = {"P1": "expense-r4-09"}
print(diagnose(required, retrieved, context, ["P1"]))

Lần chạy này báo context_loss cho expense-r4-10. Thêm P2 ánh xạ tới chunk ấy thì kết quả là dictionary rỗng, nghĩa là các phép kiểm tra mã trên đã qua. Nó chưa chứng minh đáp án đề cập công tác quốc tế, nêu đúng 21 ngày, gắn đúng trích dẫn hoặc từ chối yêu cầu phê duyệt ngoài thẩm quyền. Muốn kết luận các điều đó cần đọc cả đáp án và văn bản nguồn.

Bảng dấu vết phân biệt thiếu kết quả truy xuất, mất đoạn khi ghép ngữ cảnh, mã trích dẫn bịa và trường hợp có thể chuyển sang kiểm tra nhận địnhMở ảnh kích thước đầy đủ ↗

Dấu vết này tạo ra bài tập kiểm tra hồi quy có thể lặp lại. Bỏ đoạn ngoại lệ khỏi cả truy xuất lẫn ngữ cảnh: kết quả phải có retrieval_miss. Giữ truy xuất đầy đủ nhưng bỏ ánh xạ ngữ cảnh của nó: phải có context_loss. Cung cấp cả hai đoạn nhưng trích dẫn P9: phải có unknown_citation. Cuối cùng, dùng nhãn hợp lệ nhưng cố tình trả lời 30 ngày. Hàm không báo lỗi mã nào; bước kiểm tra nhận định riêng phải bác bỏ đáp án đó. Nếu bài kiểm thử xem dictionary rỗng là xác nhận sự thật, chính bài kiểm thử đang thiếu điều kiện.

Trong bài viết ngày 30 tháng 7 năm 2023 về các mẫu thiết kế hệ thống LLM, Eugene Yan xem truy xuất là thành phần cung cấp kiến thức bên ngoài, còn đánh giá là một mối quan tâm riêng của hệ thống. Cách tách ấy giúp định hình dấu vết trên. Bài viết cũng phân biệt recall của ANN so với láng giềng chính xác với các thước đo chất lượng và vận hành khác. Ví dụ chính sách ở đây không đo hiệu năng của những hệ thống được nguồn đó dẫn lại; tìm được vector gần nhất chưa đồng nghĩa tìm đủ bằng chứng cho câu hỏi.

Thiết kế đường đi khi không đủ căn cứ trả lời

Nếu người dùng hỏi “Bộ phận tài chính có duyệt hóa đơn nộp trễ của tôi không?”, tài liệu có thể chỉ quy định thời hạn mà không trao cho trợ lý quyền phê duyệt ngoại lệ. Hệ thống nên giải thích quy định đã ghi và chỉ ra quyết định phê duyệt còn thiếu. Không thể suy ra quyết định của quản lý từ một đoạn chính sách gần chủ đề.

Điểm truy xuất không tự giải quyết được việc này. Tương đồng cao có thể chỉ cho biết đoạn nói về hóa đơn trễ, trong khi không có đáp án về phê duyệt. Kiểm tra khả năng trả lời phải xét nhận định đang được hỏi và bằng chứng đang có. Trợ lý có thể yêu cầu bổ sung mục chính sách liên quan hoặc hướng người dùng tới người xét duyệt mà không giả vờ biết kết quả.

Tài liệu thực hành đánh giá, truy cập ngày 20 tháng 9 năm 2026, khuyến nghị tập đánh giá phù hợp với tác vụ. Với quy trình này, hãy có câu hỏi về quy định hiện hành, bẫy dùng phiên bản cũ, trường hợp ngoại lệ và yêu cầu phê duyệt mà tài liệu không quyết định được. Lưu mã bằng chứng kỳ vọng cùng yêu cầu của đáp án.

Một tập kiểm thử nhỏ chưa chứng minh chất lượng trên mọi chính sách hay ngôn ngữ. Nó có thể làm lộ một bước hỏng cụ thể. Nếu đoạn hiện hành chưa bao giờ tới prompt, cần sửa truy xuất hoặc lập chỉ mục. Nếu đoạn đã tới nhưng đáp án vẫn nói 30 ngày, cần kiểm tra yêu cầu sinh câu trả lời và ngữ cảnh xung đột. Dấu vết bằng chứng giúp chọn đúng việc cần sửa.

Nguồn tham khảo & đọc thêm

  1. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
  2. OpenAI evaluation best practices
  3. Eugene Yan: Patterns for Building LLM-based Systems & Products
← Về trang bài viết

Hình minh họa

100%