Chunking và Corrective RAG: vì sao RAG trả lời sai và cách sửa

Người dùng hỏi "hàng sale có trả được không?", hệ thống RAG của bạn trả lời "không, hàng sale là hàng final". Câu trả lời đó sai — tài liệu ghi rõ hàng lỗi vẫn trả được trong 90 ngày, kể cả hàng sale.

Không component nào trong stack bị hỏng. Bài này đi qua hai chỗ thật sự gây ra lỗi đó: ranh giới chunk, và việc không ai kiểm tra evidence trước khi generate.

Một câu bị cắt đôi là đủ để sai

Ví dụ kinh điển đến từ một bài phân tích chunking trên dev.to. Đoạn policy gốc có câu "Sale items are final and cannot be returned unless defective", kèm một câu nữa: hàng lỗi được trả trong 90 ngày bất kể có sale hay không.

Cho đoạn đó qua một fixed-size chunker — loại cắt cứ mỗi N ký tự — và tuỳ ranh giới rơi vào đâu, bạn nhận được một chunk kết thúc đúng ở chữ unless. Retriever tìm thấy nó vì nó chứa gần như nguyên văn câu hỏi, model trả lời đúng những gì context nói. Ngoại lệ "unless defective" bị chặt mất; mốc 90 ngày nằm ở chunk khác, điểm thấp hơn, không lọt vào prompt.

Embedding model không sai. Vector database không sai. LLM làm đúng phần việc của nó. Cái sai là off-by-one trong hàm splitting mà không ai mở lại từ hồi prototype.

Vì sao chỉnh chunk size không cứu được

Phản xạ đầu tiên thường là tăng chunk size cho khỏi bị cắt — đổi một failure mode lấy một cái khó thấy hơn. Mô hình tư duy: embedding nén chunk thành một điểm duy nhất trong vector space, đại diện cho nghĩa trung bình của chunk. Từ đó:

• Chunk nhỏ cho retrieval chính xác nhưng context mất trí nhớ: "It must be unopened" vô dụng khi "it" được định nghĩa ở đoạn trước.
• Chunk lớn cho context nhưng similarity bị pha loãng. Chunk 2.000 token trùm cả refund, shipping lẫn warranty embed thành điểm giữa nhoè nhoẹt, và một chunk chặt hơn có thể vượt mặt nó. Chưa kể prompt budget: ba chunk như vậy là 6.000 token cho một câu hỏi nằm gọn trong một dòng.

Không kích thước nào đúng phổ quát. Với phần lớn tài liệu văn xuôi, tác giả đề xuất 200-500 token là điểm khởi đầu hợp lý, rồi đo.

Overlap là băng dán, không phải cách sửa

Cách giảm thiểu quen thuộc là overlap: mỗi chunk lặp lại 10-20% cuối của chunk trước. Nó có ích nhưng có giá — overlap 15% là lưu thêm 15% token vĩnh viễn mỗi lần re-ingestion, và hai chunk overlap trùng nghĩa nên hay retrieve cùng nhau, biến top 3 thành top 2 thực chất. Quan trọng hơn: nó vá các nhát cắt tuỳ tiện chứ không làm nhát cắt bớt tuỳ tiện.

Cắt ở chỗ tài liệu đã tự cắt sẵn

Tài liệu không phải dòng ký tự — nó có heading, section, đoạn, list item, dòng bảng. Thuật toán chunking tốt nhất gần như không phải thuật toán: nó là việc tôn trọng cấu trúc tác giả đã cho sẵn.

Thứ tự ưu tiên: cắt theo heading trước; section quá dài thì cắt theo đoạn; đoạn vẫn dài thì cắt theo câu; cắt theo số ký tự là phương án cuối. Framework nào cũng có bản recursive character splitting với separator xếp từ nhiều nghĩa đến ít nghĩa, còn markdown-header splitter làm sẵn việc này cho docs — đủ để loại trọn nhóm lỗi cắt-giữa-câu ở trên.

Gắn breadcrumb trước khi embed

Khi đã cắt theo heading, bạn biết vị trí mỗi chunk trong cây tài liệu và có thể prepend nó trước khi embed — kiểu Returns & Refunds > Refund policy > Sale items.

Một chunk chỉ vỏn vẹn "Yes, within 30 days, in original packaging" embed trần thì vô nghĩa — nó có thể nói về trả giày hay thuê giàn giáo. Kèm breadcrumb, nó nằm cạnh mọi truy vấn về returns và model biết "Yes" trả lời cho cái gì. Chi phí vài chục token mỗi chunk, cứu đúng nhóm section ngắn phụ thuộc ngữ cảnh — FAQ là ca kinh điển vì một nửa câu trả lời bắt đầu bằng "Yes" hoặc "No". Tác giả lưu ý "contextual retrieval" của Anthropic là phiên bản cầu kỳ hơn của cùng ý tưởng.

Similarity score không phải evidence quality

Chunking tốt vẫn chưa đủ. Pipeline RAG production thường rút gọn thành query → retrieve top-K → generate, với một giả định ở khúc giữa: đã retrieve được document thì hẳn nó là evidence dùng được. Giả định đó sai.

Theo bài hướng dẫn về Corrective RAG, retriever có thể trả về evidence không liên quan, đúng một phần, lỗi thời, trùng lặp, mâu thuẫn nhau, xếp hạng sai, hoặc knowledge base đơn giản là không đủ thông tin. Điểm similarity chỉ cho biết query và document khớp nhau đến đâu dưới một retrieval model — nó không nói gì về tính đúng đắn, độ đầy đủ, độ mới hay khả năng trả lời được.

Corrective RAG (CRAG) chèn một lớp quyết định vào giữa: Yan et al. đề xuất một retrieval evaluator nhẹ, chấm document lấy về rồi kích hoạt hành động tuỳ chất lượng retrieval. Pipeline thực tế phân evidence thành ba trạng thái — CORRECT, AMBIGUOUS, INCORRECT.

Sửa nguyên nhân, đừng retry y hệt

Điểm quan trọng nhất: đừng retry y hệt — sửa lý do retrieval fail. Các chiến lược nên có sẵn:

Chiến lược	Dùng khi
Query rewriting	Đổi câu hỏi hội thoại thành truy vấn hướng retrieval — luôn giữ query gốc trong state để không bị query drift
Query decomposition	Câu hỏi nhiều vế — tách thành Q1/Q2/Q3, đánh giá coverage từng vế
Hybrid retrieval	Dense fail nhưng thông tin vẫn tồn tại — Dense + BM25, hợp với mã lỗi, tên sản phẩm, số phiên bản, ngày tháng
Metadata filtering	Query thiếu ràng buộc — thêm document_type, version
Broader retrieval	Document đúng nằm ngoài candidate set — Top-K 5 → 20 → rerank → 5
Alternative sources	Vector store nội bộ bí — xuống structured DB, documentation store, rồi external search đã duyệt. Nguồn ngoài không được tự ghi đè nguồn nội bộ có thẩm quyền

CRAG map tự nhiên vào một StateGraph: state rõ ràng, node, conditional routing, vòng lặp có chặn. Đừng quên retry_count và max_retries trong state — thiếu nó, corrective loop gặp câu hỏi mà knowledge base không có đáp án sẽ quay vòng tới khi hết ngân sách.

Làm gì tuần này

Trước khi đổi embedding model hay thêm reranker, hãy dựng golden question set: 30-50 câu hỏi thật, mỗi câu gắn nhãn document hoặc section chứa đáp án. Rồi đo retrieval hit rate — với mỗi câu, có chunk nào trong top-k đến từ đúng nguồn đã gắn nhãn không.

Có con số đó rồi, hai thay đổi đáng thử trước tiên là chunking theo heading và gắn breadcrumb trước khi embed — đều rẻ, không đụng tới model, và đánh trúng nhóm lỗi mà chỉnh chunk size không bao giờ sửa được.