10 lỗi RAG phổ biến thường gặp trong quá trình triển khai thực tế

Mô hình ngôn ngữ lớn 10 lỗi RAG phổ biến chúng ta vẫn thường thấy trong sản xuất Enterprise Document Intelligence [Tập 1 #4bis] – Ghi chú của đồng tác giả về những cạm bẫy từng bước đã biện minh cho việc chia thành bốn phần, trước khi Phần II trình bày các giải pháp Kezhan Shi Ngày 9/6/2026 28 phút đọc Chia sẻ Ảnh của Jens Lelie, qua Unsplash. Tôi là đồng tác giả của loạt bài này cùng với Angela Shi. Bài viết về những cạm bẫy này liệt kê các chế độ lỗi mà cả hai chúng tôi vẫn thường thấy trên các hệ thống RAG sản xuất, và đó là điều đã thúc đẩy chúng tôi đi đến hợp đồng bốn phần ngay từ đầu. Tôi phải thừa nhận một điều. Ngay cả khi chúng tôi thực hiện loạt bài này, chúng tôi vẫn đưa các tài liệu lớn vào ChatGPT. Một tệp PDF, một câu hỏi, gửi, đọc câu trả lời. Mô hình tốt, nhà cung cấp trả tiền token, và đối với một trường hợp đơn lẻ thì đó là con đường đúng đắn. Loạt bài này tồn tại cho trường hợp khác. Trong công việc của doanh nghiệp, câu hỏi hầu như không bao giờ chỉ liên quan đến một tài liệu. Một nhân viên xử lý yêu cầu chạy cùng một câu hỏi trên toàn bộ danh mục tài liệu cũ của một nhà môi giới. Một nhóm tuân thủ quét mọi hợp đồng trong một danh mục đầu tư. Ở quy mô đó, việc đưa tài liệu vào ChatGPT không còn hiệu quả và trở nên tốn kém nhanh chóng. Sau đây là tóm tắt những lỗi chúng ta vẫn thường thấy, từng phần một. Các giải pháp nằm trong Phần II. Mười cạm bẫy, bốn phần, một giải pháp cho mỗi thẻ – hình ảnh của tác giả 1. Phân tích cú pháp: cách tài liệu mất đi hình dạng của nó Phân tích cú pháp thất bại khi nhóm xử lý tài liệu như văn bản thay vì một đối tượng có cấu trúc. Ba mô hình vẫn thường xuất hiện: loại bỏ bảng và bố cục (Cạm bẫy 1), đưa toàn bộ tài liệu vào lời nhắc (Cạm bẫy 2), và chia tài liệu thành các cửa sổ có kích thước cố định mà bỏ qua cấu trúc của nó (Cạm bẫy 3). Giải pháp là một trình phân tích cú pháp cấu trúc tạo ra các bảng có kiểu thay vì chuỗi hoặc các cửa sổ tùy ý. Một phiên bản meta của ba điều này cũng xuyên suốt phần còn lại của bài viết. Các nhóm bỏ qua tính đúng đắn của phân tích cú pháp và dành hàng tuần để điều chỉnh kích thước đoạn, ngưỡng reranker, top-K và lựa chọn nhúng, và không bao giờ đạt được độ chính xác như mong đợi. Mọi đòn bẩy họ đo lường đều nằm trên đầu ra của trình phân tích cú pháp: một trình phân tích cú pháp làm phẳng bảng trên trang 47 tạo ra nhiễu mà không có bộ chia nào có thể phục hồi, một trình phân tích cú pháp làm mất tiêu đề cột tạo ra sự mơ hồ mà không có reranker nào có thể xếp hạng. Tài liệu không giúp ích gì. Bài viết của nhà cung cấp được trích dẫn nhiều nhất về các kỹ thuật RAG dài 194 trang về việc chia đoạn và không có trang nào về phân tích cú pháp. Hãy sửa lỗi phân tích cú pháp trước. Điều chỉnh truy xuất là dành cho các quy trình mà trình phân tích cú pháp đã bảo toàn cấu trúc. 1.1 Cạm bẫy 1: Tệp PDF có bảng. Trình phân tích cú pháp trả về một chuỗi. Phản xạ mặc định là trích xuất tệp PDF dưới dạng một khối văn bản duy nhất và để LLM sắp xếp nó. Các trình phân tích cú pháp hiện đại giúp việc này dễ dàng: một lệnh gọi hàm, một chuỗi trả về, xong. Chi phí xuất hiện lần đầu tiên khi một bảng đến với các nhãn hàng được nhóm lại. Một hợp đồng bảo hiểm có bảng quyền lợi trong đó cùng một tên hàng (Premium, Deductible) xuất hiện dưới hai danh mục (Health, Dental). Khi được làm phẳng thành văn bản, các danh mục biến mất vào luồng token và LLM thấy Plan A Plan B Plan C Health Premium 100 200 300 Deductible 5 10 15 Dental Premium 50 80 120 Deductible 2 4 6. Hỏi “Premium cho Plan B là bao nhiêu?” và có hai câu trả lời hợp lệ: 200 (Health) hoặc 80 (Dental). Chuỗi phẳng không mang theo dấu hiệu nhóm. Mô hình chọn một. Nó chọn sai một số lần, và không có tín hiệu nào cho biết nó đã chọn sai. Premium của Plan B là 200 dưới Health hoặc 80 dưới Dental, và chuỗi phẳng không thể nói rõ là cái nào – hình ảnh của tác giả Vấn đề tương tự cũng xảy ra với các bố cục nhiều cột (một trang hợp đồng có thanh bên chú thích), tiêu đề và chân trang (số trang làm ô nhiễm mọi lần truy xuất) và thứ tự đọc trên các tệp PDF được quét. Mỗi trường hợp là một chế độ lỗi khác nhau, nhưng chúng có chung một nguyên nhân gốc rễ: trình phân tích cú pháp đã loại bỏ cấu trúc mà tài liệu mang theo. Giải pháp là một trình phân tích cú pháp quan hệ tạo ra các bảng được định kiểu (line_df, page_df, toc_df,...) thay vì một chuỗi phẳng. Mỗi dòng mang hộp giới hạn, trang, phông chữ, phần của nó. Các bảng có hạt riêng của chúng. Các khối hạ nguồn đọc cấu trúc, không phải các khối dữ liệu. 1.2 Cạm bẫy 2: Trả tiền cho 1200 trang trên mỗi câu hỏi Một sai lầm thứ hai trong khía cạnh phân tích cú pháp là điều mà Angela và tôi tự làm trong các dự án nhỏ: bỏ qua hoàn toàn việc phân tích cú pháp và nhồi nhét toàn bộ tệp PDF vào cuộc trò chuyện. Việc này nhanh chóng để viết, hoạt động cho một tài liệu và nhà cung cấp trả hóa đơn token trên gói miễn phí. Trên một kho ngữ liệu thực tế, phản xạ tương tự trở nên tốn kém qua ba bước. Thứ nhất, tệp PDF không còn là 12 trang, mà là 1200 trang. Thứ hai, câu hỏi không còn là một, mà là 200 câu mỗi ngày. Thứ ba, nhóm thêm năm tài liệu nữa vào cuộc trò chuyện để "cung cấp thêm ngữ cảnh cho mô hình", và số lượng token trên mỗi câu hỏi tăng tuyến tính. Hóa đơn từ vài xu lên hàng nghìn đô la mỗi tháng, và các câu trả lời trở nên tệ hơn vì mô hình có nhiều rơm hơn và cùng một cây kim. Giải pháp là điều chỉnh kỹ thuật cho phù hợp với tài liệu và câu hỏi: khi câu trả lời nằm gọn trong ba trang, hãy gửi ba trang, không phải 1200 trang. Nguyên tắc tương tự ở đây: phân tích cú pháp một lần, truy xuất có phạm vi, tạo ra trên ngữ cảnh nhỏ nhất chứa câu trả lời. Đây là hóa đơn trong một kịch bản doanh nghiệp thực tế: một hợp đồng tái bảo hiểm 1200 trang mà một nhóm tuân thủ truy vấn 200 lần một ngày. Hai cách tiếp cận, cùng một câu hỏi. Cách thứ nhất trích xuất mọi dòng văn bản từ tệp PDF và nhồi nhét kết quả vào mọi lời nhắc. Cách thứ hai là quy trình mà loạt bài này xây dựng: phân tích cú pháp tạo ra các bảng có cấu trúc, truy xuất trả về ba trang liên quan, tạo ra chỉ đọc những trang đó. 131.000 USD mỗi năm cho việc đổ dữ liệu so với 330 USD cho quy trình có phạm vi – hình ảnh của tác giả Trên một hợp đồng 1200 trang, việc đổ dữ liệu trả chi phí đầu vào gấp khoảng bốn trăm lần so với quy trình có phạm vi. Việc đổ dữ liệu tăng theo tài liệu và số lượng câu hỏi; quy trình chỉ tăng theo câu trả lời. Mỗi hợp đồng, mỗi năm với hai trăm câu hỏi mỗi ngày, đó là sự khác biệt giữa việc đốt 131.000 USD và đốt 329 USD. Bộ nhớ đệm lời nhắc làm thay đổi phép tính mà không làm đảo ngược nó. Bộ nhớ đệm đọc giảm giá 90% của Anthropic và đầu vào được lưu trong bộ nhớ đệm giảm giá 50% của OpenAI đều chỉ áp dụng khi có truy cập bộ nhớ đệm, bị loại bỏ theo TTL mà nhóm không đồng bộ.