Blog / AI / Deep Article
RAG giúp chatbot tra cứu tài liệu nhưng không bảo đảm trả lời đúng. Phân tích cơ chế truy xuất, mất bối cảnh, trích dẫn sai, cách đánh giá và bảo mật.
Một nhân viên hỏi chatbot nội bộ: “Khoản hỗ trợ đi lại trong quy định mới được tính thế nào?” Hệ thống tìm được một văn bản, trả lời trôi chảy và gắn đường dẫn nguồn. Người đọc có lý do để tin. Nhưng nếu văn bản được tìm thấy là bản cũ, hoặc chỉ có một đoạn nói về đối tượng hưởng mà thiếu điều kiện áp dụng, câu trả lời vẫn có thể sai. Đường dẫn thật không biến một kết luận sai thành đúng.
Đó là nghịch lý của RAG (*Retrieval-Augmented Generation*, sinh nội dung có tăng cường truy xuất). Kỹ thuật này cho mô hình ngôn ngữ tham khảo tài liệu bên ngoài thay vì chỉ dựa vào kiến thức đã học. Nó rất hữu ích cho hệ thống hỏi đáp tài liệu, hỗ trợ khách hàng, tra cứu quy trình. Tuy nhiên, khả năng tìm được một đoạn văn và khả năng đưa ra câu trả lời có căn cứ là hai việc khác nhau.
Nghiên cứu *Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks* của Patrick Lewis và cộng sự, được chấp nhận tại NeurIPS 2020, đặt vấn đề kết hợp hai loại “bộ nhớ”: tham số của mô hình sinh và phi tham số là kho văn bản có thể truy xuất. Trong hệ thống nghiên cứu, bộ truy xuất tìm những đoạn từ chỉ mục Wikipedia; mô hình sinh sử dụng chúng để tạo câu trả lời. Nhóm tác giả thử hai cách: dùng tập đoạn truy xuất chung cho cả câu trả lời, hoặc cho phép lựa chọn khác nhau theo từng token.
Trước khi có người hỏi, tổ chức phải chuẩn bị dữ liệu. Tài liệu được thu thập, chuyển thành văn bản, gắn thông tin về nguồn, ngày hiệu lực, phiên bản và quyền truy cập. Nội dung thường được chia thành những đoạn nhỏ (*chunk*) để dễ tìm kiếm. Một chỉ mục được tạo ra, có thể dựa trên từ khóa, vector biểu diễn ngữ nghĩa, hoặc kết hợp cả hai. Khi có câu hỏi, ứng dụng tìm đoạn liên quan, ghép chúng với câu hỏi và đưa vào mô hình sinh. Đây là lúc sai sót từ tìm kiếm có thể đi thẳng vào câu trả lời.
Giả sử người dùng hỏi: “Mã biểu mẫu 02B có áp dụng cho kỳ báo cáo này không?” Công cụ tìm kiếm vector có thể nhận ra những đoạn nói về biểu mẫu, kỳ báo cáo và thủ tục tương tự. Nhưng nếu nó không ưu tiên khớp chính xác chuỗi “02B”, một đoạn về “02A” cũng có thể được xếp cao.
Tìm kiếm theo từ khóa như BM25 hữu ích khi câu hỏi chứa tên riêng, mã hiệu, số quyết định hoặc cụm từ hiếm. Tìm kiếm ngữ nghĩa bằng embedding lại có lợi khi người dùng diễn đạt khác với tài liệu. Vì thế, một hệ thống có thể kết hợp hai kiểu tìm kiếm, hợp nhất kết quả rồi xếp hạng lại (*reranking*) trước khi đưa vào mô hình.
Ví dụ trong bài viết của Anthropic cho thấy một đoạn về tăng trưởng doanh thu không tự cho biết nó thuộc doanh nghiệp nào hoặc quý nào. Họ đề xuất thêm phần mô tả bối cảnh riêng cho mỗi đoạn trước khi lập chỉ mục, gọi là *Contextual Retrieval*. Trong phép đo do chính nhóm này công bố, kết hợp contextual embeddings và contextual BM25 làm tỷ lệ không tìm thấy đoạn liên quan trong 20 kết quả đầu giảm từ 5,7% xuống 2,9%, tương đương mức giảm tương đối khoảng 49%. Lưu ý: mức giảm 49% là tỷ lệ tìm hụt đoạn trong thí nghiệm, không phải mức tăng độ chính xác của câu trả lời.
Thứ nhất, kho dữ liệu thiếu hoặc lỗi thời. Nếu bản quy định mới chưa được nạp, hệ thống không thể tìm được nó. Mô hình có thể trả lời dựa trên bản cũ mà không biết đã có sửa đổi. Việc cập nhật chỉ mục, lưu phiên bản và đánh dấu ngày hiệu lực quan trọng không kém chất lượng mô hình.
Thứ hai, truy xuất nhầm tài liệu. Tên văn bản gần giống, từ khóa trùng nhau, biểu mẫu nhiều phiên bản hoặc cách diễn đạt mơ hồ có thể làm đoạn không phù hợp được xếp cao. Đưa thêm nhiều đoạn vào ngữ cảnh đôi khi chỉ tăng nhiễu, chứ không tự chữa lỗi.
Thứ ba, bằng chứng đúng nhưng không đủ. Một đoạn có thể xác nhận đối tượng được hưởng hỗ trợ nhưng không nói tới điều kiện loại trừ. Nếu câu trả lời bỏ qua điều kiện đó, nó là kết luận vượt quá nguồn. Trường hợp này khó phát hiện vì đường dẫn trích dẫn vẫn hoàn toàn hợp lệ.
Thứ tư, mô hình suy diễn quá mức. Ngay cả khi được cung cấp đoạn chính xác, mô hình vẫn có thể gộp hai quy định khác nhau, diễn giải sai phủ định hoặc tự điền thông tin còn thiếu. Microsoft Learn lưu ý rằng RAG vẫn có thể đưa ra câu trả lời thiếu hoặc sai khi đoạn truy xuất không liên quan hay không đầy đủ.
Hãy hình dung một doanh nghiệp có hai văn bản giả định. Quy định A năm trước nêu mức hỗ trợ đi lại là 400.000 đồng mỗi tháng. Quy định B ban hành sau quy định mức 500.000 đồng, nhưng chỉ áp dụng từ ngày 1/11 cho nhân viên làm việc tại một nhóm địa bàn. Nhân viên hỏi ngày 31/10: “Tháng này tôi được hưởng bao nhiêu?”
Nếu công cụ tìm thấy B nhưng bỏ qua ngày hiệu lực, chatbot có thể trả lời 500.000 đồng. Nếu chỉ tìm thấy A, chatbot có thể trả lời 400.000 đồng mà không nhắc tới thay đổi sắp tới. Nếu tìm thấy cả hai nhưng không biết người hỏi thuộc địa bàn nào, không có đủ dữ kiện để kết luận một mức duy nhất.
Một câu trả lời tốt sẽ nói rõ mức theo A còn áp dụng cho tháng đang hỏi nếu không có ngoại lệ khác; B bắt đầu hiệu lực từ thời điểm nêu trong văn bản; và cần xác định địa bàn hoặc các điều khoản chuyển tiếp trước khi áp dụng cho cá nhân. Đây chỉ là tình huống minh họa để phân tích luồng suy luận, không phải quy định thực tế của doanh nghiệp hay cơ quan nào.
Ở tầng truy xuất, có thể đo tỷ lệ câu hỏi mà đoạn bằng chứng cần thiết xuất hiện trong top-k kết quả (*recall@k*), kiểm tra thứ hạng, thời gian tìm kiếm và khả năng lọc theo quyền. Một kết quả ở vị trí 30 không giúp nhiều nếu ứng dụng chỉ đưa 5 đoạn đầu cho mô hình.
Ở tầng câu trả lời, nên đánh giá riêng tính đúng đắn so với đáp án chuẩn, mức độ được nguồn hỗ trợ (*groundedness*), tính đầy đủ và độ chính xác của trích dẫn. Một câu trả lời có thể đúng do mô hình biết sẵn nhưng trích nguồn sai; hoặc có nguồn đúng nhưng suy luận vượt quá tài liệu. Hai lỗi ấy cần hai cách sửa khác nhau. Cũng phải thử những câu không có đáp án: chatbot tốt cần biết nói “chưa đủ căn cứ”, thay vì tự điền dữ kiện còn thiếu.
RAG thường được triển khai trên tài liệu nội bộ. Điều này tạo hai ranh giới bảo mật. Một là quyền đọc: hệ thống phải lọc tài liệu theo quyền của người hỏi trước khi truy xuất hoặc trả lời, thay vì chỉ ẩn đường dẫn trên giao diện. Hai là ranh giới chỉ dẫn: văn bản tìm được có thể chứa câu lệnh nhằm thao túng chatbot, nhưng nó vẫn chỉ là dữ liệu tham khảo, không phải mệnh lệnh của hệ thống. Microsoft Learn cũng yêu cầu kiểm soát truy cập khi truy xuất và xem đoạn văn lấy về là đầu vào không đáng tin.
Một hệ thống RAG đáng tin không dừng ở chỗ gắn được đường dẫn. Nó phải biết tài liệu nào đang có hiệu lực, đoạn nào chứng minh từng kết luận và khi nào chứng cứ không đủ. Hãy thử hỏi: “Nếu người đọc mở đúng nguồn, họ có kiểm tra được câu trả lời này không?” Đó mới là phép thử thiết thực cho một chatbot dùng tài liệu.