RAG Cho Knowledge Base Doanh Nghiệp: Điều Gì Thực Sự Hỏng Ở Production

Retrieval-augmented generation trông đơn giản đến đánh lừa trên bảng vẽ: chia nhỏ tài liệu, embed chúng, lưu trữ vector, truy xuất các đoạn liên quan tại thời điểm truy vấn, đưa cho một LLM. Mọi demo RAG chúng tôi từng thấy đều chạy tốt với mười câu hỏi đầu tiên ai đó thử. Lỗi xuất hiện ba tuần sau khi ra mắt, khi nhân viên thật đặt câu hỏi thật lên một bộ tài liệu lộn xộn và mâu thuẫn hơn nhiều so với bất kỳ ai lường trước trong quá trình xây dựng.

Quyết định chunking đưa ra ở tuần một gây vấn đề ở tháng ba

Kích thước chunk và cách xác định ranh giới được quyết định sớm, gần như là một chi tiết triển khai, rồi âm thầm quyết định chất lượng truy xuất suốt vòng đời hệ thống. Chunking kích thước cố định (chẳng hạn 500 token với 50 token chồng lấp) dễ triển khai nhưng sai với rất nhiều nội dung doanh nghiệp. Một văn bản chính sách với các điều khoản đánh số, một bảng giá theo hạng mức, và một hợp đồng pháp lý có các phần tham chiếu chéo, tất cả đều cần chiến lược chunking khác nhau — cắt đôi một bảng thì cả hai mảnh đều vô dụng với bộ truy xuất.

Những gì chúng tôi thấy thực sự hiệu quả:

• Chunking nhận biết cấu trúc tôn trọng ranh giới tài liệu — tiêu đề, mục danh sách, hàng bảng — thay vì đếm token một cách mù quáng. Cách này đòi hỏi nhiều công sức phân tích trước cho từng loại tài liệu nhưng đem lại lợi ích trực tiếp về độ chính xác truy xuất.
• Chunk giàu metadata mang theo tên tài liệu gốc, tiêu đề phần, và ngày tháng cùng với nội dung văn bản, để cả bước truy xuất lẫn bước sinh câu trả lời đều có ngữ cảnh vượt ra ngoài nội dung chunk thô.
• Chunking lại như một tác vụ bảo trì đã lên kế hoạch, không phải một bước thiết lập một lần. Khi định dạng tài liệu thay đổi hoặc một loại tài liệu mới được thêm vào, chiến lược chunking cần được xem xét lại — những đội coi chunking là "xong" từ tuần một sẽ thấy chất lượng truy xuất suy giảm khi kho tài liệu tăng lên.

Tài liệu lỗi thời và mâu thuẫn âm thầm đầu độc chất lượng truy xuất

Knowledge base doanh nghiệp không bao giờ là một tập tài liệu sạch, cập nhật, và không mâu thuẫn. Luôn có chính sách năm 2022 chưa từng bị gỡ bỏ, bản nháp được gửi qua email và không hiểu sao lại bị đánh chỉ mục, và ba phiên bản của một tài liệu hướng dẫn onboarding với chỉ dẫn mâu thuẫn nhau. Tìm kiếm vector không biết cái nào là chính thống — nó trả về cái tương đồng ngữ nghĩa nhất, và một tài liệu lỗi thời có thể tương đồng ngữ nghĩa với truy vấn y hệt tài liệu hiện hành.

Đây là nguyên nhân phổ biến nhất cho những phàn nàn "AI trả lời sai" mà chúng tôi thấy sau khi ra mắt, và nó hiếm khi là vấn đề của model. Những cách khắc phục thực sự giải quyết gốc rễ:

1. Gắn nhãn nguồn chính thống — một trường rõ ràng đánh dấu tài liệu nào là chính thống, với truy xuất được cấu hình để ưu tiên hoặc chỉ sử dụng các nguồn đã gắn nhãn cho những truy vấn quan trọng (tuân thủ, chính sách nhân sự, giá cả).
2. Một quy trình vòng đời tài liệu — ai đó chịu trách nhiệm loại bỏ tài liệu lỗi thời khỏi chỉ mục, không chỉ thêm tài liệu mới. Không có người chịu trách nhiệm, chỉ mục chỉ tăng lên và tình trạng lỗi thời chồng chất.
3. Trọng số theo độ mới trong điểm truy xuất, không chỉ độ tương đồng ngữ nghĩa, để một tài liệu năm 2025 tự nhiên xếp hạng cao hơn một tài liệu năm 2022 có nội dung tương tự khi cả hai đều được truy xuất.

Truy xuất có thể thành công trong khi câu trả lời vẫn sai

Một kiểu lỗi tinh vi: bộ truy xuất tìm đúng chính xác các chunk cần thiết, nhưng câu trả lời được sinh ra vẫn sai, vì LLM hoặc bỏ qua ngữ cảnh đã truy xuất để dùng dữ liệu huấn luyện của nó, hoặc tổng hợp thông tin qua các chunk theo cách tạo ra một lỗi không hề tồn tại trong từng chunk nguồn riêng lẻ. Lỗi này khó bắt hơn nhiều so với việc truy xuất trượt vì log hệ thống trông vẫn đúng — ngữ cảnh đúng đã được đưa vào.

Những rào chắn hữu ích:

• Prompt rõ ràng chỉ thị model chỉ trả lời dựa trên ngữ cảnh được cung cấp và nói "tôi không có thông tin về việc này" thay vì lấp khoảng trống bằng kiến thức chung — và kiểm tra xem chỉ thị này có thực sự đứng vững trước việc diễn đạt lại mang tính đối kháng hay không.
• Yêu cầu trích dẫn, trong đó model phải tham chiếu chunk nào hỗ trợ mỗi luận điểm. Điều này không chỉ giúp người dùng cuối tin tưởng câu trả lời — nó còn giúp các câu trả lời sai dễ debug hơn, vì bạn có thể thấy lỗi nằm ở truy xuất hay ở sinh nội dung.
• Một tập câu hỏi "bẫy" được giữ riêng, nơi câu trả lời đúng là "chúng tôi không có thông tin đó", dùng riêng để bắt hiện tượng ảo giác (hallucination) chứ không phải để kiểm tra độ chính xác truy xuất.

Kiểm soát quyền truy cập là một bài toán khó hơn phần lớn các đội ngũ nghĩ

Câu hỏi chúng tôi đặt ra sớm với mọi khách hàng là: mọi người dùng đặt câu hỏi có quyền xem mọi tài liệu có thể được truy xuất cho câu hỏi đó không? Trong một wiki công ty đa dụng, thường là có. Trong một knowledge base doanh nghiệp trải rộng qua nhân sự, pháp lý, và tài liệu kỹ thuật, gần như không bao giờ. Một hệ thống RAG bỏ qua quyền truy cập ở cấp tài liệu và chỉ truy xuất chunk tương đồng ngữ nghĩa nhất là một vụ rò rỉ dữ liệu chờ xảy ra — một nhân viên hỏi một câu hỏi chung có thể nhận được câu trả lời tổng hợp từ một tài liệu mà họ chưa từng được phép xem.

Xử lý đúng vấn đề này nghĩa là truy xuất nhận biết quyền hạn — lọc các chunk ứng viên theo quyền truy cập của người dùng yêu cầu trước khi chúng đến được LLM, không phải sau đó. Việc tích hợp lại điều này vào một hệ thống được xây dựng mà không tính đến nó từ đầu rất tốn kém, đó là lý do chúng tôi thúc đẩy khách hàng xác định mô hình quyền truy cập trước khi viết dòng code truy xuất đầu tiên, chứ không phải sau khi một đợt rà soát bảo mật phát hiện ra vấn đề hậu ra mắt.

RAG thực sự hữu ích cho công việc tri thức doanh nghiệp — những kiểu lỗi ở trên chính là lý do các hệ thống duy trì được sự hữu ích là những hệ thống được xây dựng với quản lý vòng đời tài liệu, kiểm soát quyền truy cập, và đánh giá chất lượng được tích hợp sẵn ngay từ đầu, chứ không phải bổ sung sau khi giai đoạn thử nghiệm thành công.