Thực hànhNâng cao

Dự án tổng kết: xây trợ lý tài liệu có kiểm chứng

Ghép truy xuất, trích dẫn, phân quyền và đánh giá thành một dự án nhỏ có tiêu chí nghiệm thu rõ ràng.

Trong bài viết này

Từ được đánh dấu có giải thích. Di chuột hoặc chạm để xem, hay mở từ điển AI.

Sản phẩm của dự án này là một trợ lý trả lời câu hỏi từ bộ tài liệu bạn được phép dùng. Mỗi kết luận quan trọng có nguồn; khi thiếu bằng chứng, trợ lý nói rõ điều chưa biết. Nó có thể tạo bản nháp báo cáo, nhưng không tự gửi báo cáo hoặc sửa tài liệu gốc.

Tiên quyết: đã đọc RAG, phân quyền tối thiểu và đánh giá trạng thái cuối. Quy mô sau là bài tập minh họa, dùng dữ liệu giả hoặc nội dung có quyền sử dụng; không phải hệ thống sẵn sàng triển khai ngay.

Đặc tả kết quả trước khi chọn công nghệ

Chuẩn bị mười hai tài liệu thuộc hai nhóm truy cập, gồm một chính sách có phiên bản mới thay thế bản cũ. Viết hai mươi câu hỏi: có đáp án, thiếu đáp án, nguồn mâu thuẫn, yêu cầu ngoài phạm vi và yêu cầu tạo báo cáo. Ghi đáp án mong đợi trước khi chỉnh prompt.

Hợp đồng câu trả lời có thể là:

status: answered | insufficient_evidence | needs_review
claims: [{ text, source_id, source_version, supporting_span }]
limitations: [điều chưa xác nhận]
artifact: { id, verified } hoặc null

Không coi JSON hợp lệ là đủ. supporting_span phải thật sự hỗ trợ text, nguồn phải thuộc phạm vi người dùng và phiên bản chính sách phải phù hợp thời điểm câu hỏi. Viết rõ những trường hợp hệ thống phải từ chối trả lời dứt khoát.

Xây luồng ngắn với cổng kiểm tra rõ ràng

Luồng đầu tiên gồm xác thực phạm vi, truy xuất, sinh bản trả lời, kiểm tra bằng chứng và hiển thị. Chỉ thêm vòng tìm tiếp khi bộ kiểm tra chỉ ra thiếu thông tin cụ thể. Giữ ngân sách lượt gọi và cho phép kết thúc với insufficient_evidence.

Nhìn để hiểuTừ câu hỏi đến câu trả lời có căn cứ

RAG tìm các đoạn tài liệu liên quan, đưa chúng vào ngữ cảnh rồi tạo câu trả lời. Người đọc cần kiểm tra nguồn có thực sự hỗ trợ câu trả lời hay không.

Tìm tài liệu trước khi tạo câu trả lờiMột câu hỏi về ngày đầu đi làm dẫn tới tìm kiếm tài liệu, trích đoạn liên quan, đưa đoạn đó vào ngữ cảnh rồi tạo câu trả lời có nguồn. Các tài liệu là ví dụ; trích dẫn cần được kiểm tra và RAG không tự bảo đảm câu trả lời đúng.CÂU HỎINgày đầu cần gì?Sổ tayNGỮ CẢNH ĐƯA VÀO MÔ HÌNH[1] Mang giấy tờ cần thiếtCÂU TRẢ LỜIMang giấy tờtheo sổ tay [1].Tìm đúng đoạn → trả lời → kiểm tra nguồn.

↔ Vuốt ngang để xem toàn bộ sơ đồ.

  1. 01 / Nhận câu hỏi

    Hệ thống nhận câu hỏi cùng phạm vi tài liệu mà người dùng được phép đọc.

  2. 02 / Tìm tài liệu

    Bộ tìm kiếm lấy các đoạn có liên quan trong kho tài liệu được phép truy cập.

  3. 03 / Thêm ngữ cảnh

    Câu hỏi, các đoạn tìm được và thông tin nguồn được đưa cho mô hình.

  4. 04 / Trả lời kèm nguồn

    Mô hình tạo câu trả lời có căn cứ để đối chiếu. Nếu chưa đủ thông tin, hệ thống cần nói rõ.

Minh họa một luồng RAG cơ bản. Tìm thấy tài liệu không bảo đảm nội dung còn hiệu lực hoặc mô hình sử dụng đúng.

Sơ đồ minh họa truy xuất rồi sinh câu trả lời. Dự án bổ sung phân quyền trước truy xuất và kiểm chứng sau sinh; hai lớp này không được RAG tự đảm bảo.

Một tài liệu có thể chứa câu yêu cầu bỏ qua nhiệm vụ. Hãy coi đó là nội dung cần đọc, không phải lệnh cấp quyền. Công cụ của dự án chỉ đọc nguồn hợp lệ và tạo bản nháp trong thư mục riêng. Cổng công cụ kiểm tra phạm vi ngay trước thực thi, kể cả khi mô hình đề xuất hành động khác.

Đánh đổi của bước kiểm chứng là thêm thời gian và khả năng chặn nhầm. Ban đầu có thể kết hợp các kiểm tra xác định được, như nguồn tồn tại và quyền truy cập, với đánh giá người đọc về quan hệ giữa kết luận và bằng chứng. Không tuyên bố kiểm chứng ngữ nghĩa hoàn hảo chỉ vì đã gọi thêm một mô hình.

Nghiệm thu kết quả và hành vi bảo toàn

τ-bench sử dụng trạng thái cuối môi trường trong đánh giá agent. Áp dụng nguyên tắc đó, bài tập tạo báo cáo chỉ đạt khi tệp tồn tại, chứa đủ các mục và nguồn, mở đọc được, đồng thời tài liệu gốc không bị sửa. Lời agent nói đã lưu không thay thế phép kiểm này.

Mỗi ca thử cần snapshot nguồn, quyền người dùng, phiên bản prompt, kết quả và lý do chấm. Chạy lại các ca quan trọng để quan sát độ ổn định. Phân loại lỗi thành truy xuất, suy luận từ nguồn, quyền truy cập, tạo tệp và báo cáo sai trạng thái để biết nên sửa lớp nào.

Thử thêm công cụ timeout và bản nháp đã tạo nhưng mất phản hồi. Giữ mã thao tác qua lần retry, rồi kiểm tra không có tệp trùng. Nếu chưa làm được phục hồi an toàn, giới hạn dự án ở chức năng chỉ đọc và ghi rõ phạm vi nghiệm thu.

Bàn giao một bộ bằng chứng nhỏ nhưng đầy đủ

Bài tập hoàn thành khi bạn có đặc tả, bộ nguồn có phiên bản, bộ câu hỏi gán nhãn, cấu hình chạy, kết quả từng ca và hướng dẫn tái lập. Thêm một bản báo cáo mẫu có trích dẫn cùng một ca thiếu bằng chứng được xử lý đúng.

Tự kiểm: không lộ nguồn ngoài quyền; không khẳng định điều thiếu căn cứ; mọi báo cáo được xác minh bằng tệp thật; giới hạn ngân sách hoạt động; người khác chạy lại được mà không cần bí mật của bạn. Viết ba lỗi còn tồn tại và phạm vi chưa kiểm tra. Sau đó dùng ablation study để kiểm tra thành phần nào mang lại lợi ích trước khi tăng độ phức tạp.

Bạn muốn hiểu điều gì?

Khám phá tất cả bài viết esc để đóng