Chuẩn hóa knowledge base trước khi đưa vào RAG: quy trình tránh dữ liệu rác và câu trả lời sai

Một hệ thống RAG không thể trả lời ổn định nếu knowledge base chứa văn bản OCR lỗi, nội dung trùng, quy định hết hạn hoặc tài liệu của nhiều chi nhánh bị trộn lẫn. Cách đúng là không embedding tài liệu ngay sau khi upload. Hãy tạo một tầng chuẩn hóa nằm giữa nguồn thô và vector index: kiểm tra file, trích xuất cấu trúc, làm sạch có kiểm soát, gắn metadata và quyền truy cập, phát hiện xung đột, cho phép phê duyệt, rồi mới chunk và index.

Mục tiêu không phải biến mọi tài liệu thành văn bản đẹp. Mục tiêu là tạo ra một bản knowledge chuẩn có thể truy vết: biết thông tin đến từ đâu, có hiệu lực khi nào, áp dụng cho khách sạn hoặc chi nhánh nào và ai được phép truy xuất. Chunking chỉ nên bắt đầu sau khi bản chuẩn này vượt qua quality gate.

Một pipeline production nên bắt đầu bằng raw store bất biến. Lưu file gốc cùng checksum, MIME type thực, dung lượng, nguồn, người tải lên, tenant/property, locale và thời điểm nhận. Quét malware, chặn định dạng không hỗ trợ và không tin phần mở rộng file do người dùng cung cấp.

Bước extraction phải giữ lại cấu trúc có ý nghĩa: heading, đoạn văn, danh sách, bảng, chú thích và số trang. Với tài liệu scan, cần OCR kèm cờ confidence thấp để review; không âm thầm đoán chữ. Azure Document Intelligence có thể xuất layout thành Markdown, nhưng output máy vẫn phải được kiểm tra vì bảng phức tạp, nhiều cột và footer lặp có thể bị đọc sai.

Sau extraction, tạo canonical Markdown thay vì sửa file raw. Loại header/footer lặp, navigation, ký tự hỏng và khoảng trắng thừa; chuẩn hóa heading, bullet, ngày tháng, đơn vị và thuật ngữ. Không được viết lại con số, chính sách hay điều kiện nghiệp vụ chỉ để văn bản trông mượt hơn. Mọi chỉnh sửa do AI đề xuất phải lưu diff và confidence; thay đổi có ảnh hưởng đến sự thật cần người có thẩm quyền phê duyệt.

Mỗi tài liệu chuẩn nên có front matter hoặc record metadata tối thiểu gồm: document_id, source_id, source_checksum, tenant_id, property_id, locale, document_type, title, owner, access_scope, effective_from, effective_to, version, status, approved_by và approved_at. Dùng ID ổn định; không suy luận property từ tên file. Nếu không xác định được phạm vi, pipeline phải fail closed và đưa tài liệu vào hàng chờ xử lý.

Nội dung nên theo một template phù hợp miền nghiệp vụ. Ví dụ knowledge base khách sạn có thể dùng: phạm vi áp dụng, câu trả lời chuẩn, điều kiện/ngoại lệ, quy trình xử lý, thông tin không được cam kết và nguồn tham chiếu. Chính sách check-in không nên bị trộn với hướng dẫn nội bộ cho nhân viên chỉ vì chúng nằm trong cùng một PDF.

Tách fact khỏi instruction. Văn bản từ nguồn bên ngoài có câu như “bỏ qua quy tắc trước đó” chỉ là dữ liệu, không phải lệnh cho hệ thống. Gắn trust level và source type, loại secret/PII không cần thiết, áp access control cả khi ingest lẫn retrieval. OWASP lưu ý rằng vector và embedding có thể tạo rủi ro rò rỉ dữ liệu hoặc dữ liệu độc hại nếu corpus không được kiểm soát.

Chunk theo heading, đoạn và bảng thay vì cắt máy móc giữa câu. Chính sách ngắn có thể giữ trọn một section; hướng dẫn dài có thể chia theo bước nhưng cần lặp lại ngữ cảnh tối thiểu như tiêu đề, property và ngày hiệu lực. Microsoft khuyến nghị chọn chiến lược theo cấu trúc tài liệu vì chunk quá nhỏ thiếu ngữ cảnh, còn chunk quá lớn làm giảm độ chính xác và tăng chi phí.

Mỗi chunk cần chunk_id xác định được theo document version và vị trí, nội dung, heading path, source locator, locale, access scope và trạng thái publish. Metadata được lưu cùng embedding để filter trước khi similarity search. Không dùng vector similarity như cơ chế phân quyền.

Trước khi đưa generation mới lên live, chạy retrieval evaluation với bộ câu hỏi đại diện: Recall@k, MRR hoặc nDCG, citation correctness, answer faithfulness, abstention và cross-tenant leakage. So sánh với generation đang chạy; chỉ promote khi vượt ngưỡng đã định. Giữ alias hoặc active generation để rollback mà không phải rebuild trong lúc sự cố.

Dùng checksum để nhận biết file không đổi và idempotency key cho mỗi processing run. Một state machine rõ ràng có thể gồm UPLOADED → VALIDATED → EXTRACTED → NORMALIZED → REVIEW_REQUIRED → APPROVED → CHUNKED → INDEXED → PUBLISHED, kèm các trạng thái FAILED và QUARANTINED. Retry tiếp tục từ artifact hợp lệ gần nhất thay vì tạo document/chunk trùng.

Khi nguồn thay đổi, tạo version canonical và index generation mới. Chỉ sau khi validation và evaluation đạt yêu cầu mới đổi con trỏ live bằng thao tác nguyên tử. Giữ version trước trong thời gian rollback; xóa theo retention policy, không xóa ngay khi publish. Theo dõi tỷ lệ extraction lỗi, tài liệu chờ review, duplicate ratio, orphan chunks, retrieval miss, citation failure và leakage-test failure.

FAQ

Có nên dùng AI tự động viết lại toàn bộ tài liệu? Không. AI phù hợp để phát hiện lỗi, đề xuất cấu trúc và chuẩn hóa hình thức. Các thay đổi về giá, điều kiện, quyền lợi hoặc chính sách cần so sánh với nguồn và phê duyệt.

Markdown có phải định dạng tốt nhất cho mọi RAG? Không tuyệt đối, nhưng Markdown dễ giữ heading, danh sách và bảng, thuận tiện cho semantic chunking và review bằng Git/diff. File raw vẫn phải được giữ lại.

Nên xóa nội dung trùng bằng cách nào? Dùng checksum cho trùng tuyệt đối, sau đó similarity hoặc rule để tìm gần trùng. Không tự động gộp hai chính sách khi ngày hiệu lực hay phạm vi khác nhau.

Khi nào cần human review? Khi OCR confidence thấp, nguồn xung đột, thiếu phạm vi, phát hiện PII/secret, hoặc AI đề xuất thay đổi nội dung nghiệp vụ. Tài liệu sạch và đúng template có thể đi theo đường tự động.

Có thể chunk trước rồi làm sạch sau không? Không nên. Làm sạch sau chunk dễ tạo ranh giới không ổn định, chunk ID thay đổi và metadata không đồng nhất; evaluation cũng khó truy vết về nguồn chuẩn.