Chunk văn bản cho RAG và LLM: kích thước, overlap và ranh giới có ý nghĩa

RAG chết rất yên khi chunk sai cỡ. Quá nhỏ mất ngữ cảnh; quá lớn embedding loãng nghĩa và ăn token. Cắt bừa 512 ký tự đứt câu giữa chừng, chôn đoạn duy nhất trả lời câu hỏi.

Bài viết mô tả pipeline, token so với ký tự, ranh giới tiêu đề Markdown, metadata cần lưu, và lý do Safe Local Tools cho phép thử cục bộ trước khi bạn gửi tài liệu mật lên API embedding.

Chunking đứng ở đâu trong pipeline

Ingest, rồi split, embed, index, rồi khi truy vấn gom top-k chunk đưa vào prompt. Chất lượng truy vấn giới hạn trên bởi chất lượng chunk—không model nào cứu được retrieval không bao giờ thấy đoạn đúng.

Kích thước theo token và loại nội dung

Tài liệu kỹ thuật có tiêu đề: bắt đầu 400–800 token và tôn trọng section. Log chat: 200–400 nhưng theo ranh giới người nói. Văn pháp lý dài hơn với overlap lớn. Mã: theo hàm/lớp, không cắt giữa khối. Đo lường trên corpus riêng vì “pháp lý” khác “OpenAPI reference”.

Overlap mười đến hai mươi phần trăm

Phần đuôi chunk N lặp lại đầu chunk N+1 giúp câu vắt ranh giới vẫn xuất hiện trọn trong ít nhất một chunk. Chi phí: lưu trữ và embedding lớn hơn, truy vấn có thể trúng trùng—cần dedupe. Bắt đầu 10–15% overlap so với kích thước chunk rồi đo recall@k trên tập câu hỏi gắn nhãn.

Ranh giới cấu trúc và metadata

Ưu tiên ## heading, khối đoạn, dấu câu cuối, khoảng trắng, rồi mới cứng nhắc theo độ dài. Với bảng hay giữ dòng không tách nhầm sang chunk khác nhau nếu nghĩa phụ thuộc nhau.

Metadata gồm đường dẫn nguồn, tiêu đề mục, số trang, thời điểm cập nhật, ACL và tenant—retrieval không thể trích dẫn nếu vector thiếu nguồn.

Tìm kiếm lai vẫn cần chunk tốt

BM25 thích token hiếm còn; vector thích vùng lân cận ngữ nghĩa. Mã SKU bị chia đôi phá cả hai. Trường họp hybrid yêu cầu không phá mẫu mã.

Quyền riêng tư thử splitter

Playbook của công ty không nên dán lên các trang chia demo công khai. Chạy thử splitter trong Safe Local Tools trong tab không gửi bản nháp lên.

Công cụ và quy trình đánh giá: bộ vàng không thể chỉ có “cảm tính cosine”

Các đội nghiêm túc xây tập câu hỏi thật của người dùng, gắn nhãn đoạn chứa đáp án tối thiểu và đo Recall@k cùng MRR sau mỗi thay đổi splitter. Việc này không cần hàng ngàn ví dụ: ba mươi đến năm mươi câu thường gặp thường đủ để thấy hướng khi tuning overlap.

Đừng bỏ qua chỉ báo hallucination của model sau khi bạn chỉnh chunk: một chunk lớn hơn có thể giảm Recall nhưng tăng mức mơ hồ tiêm vào prompt, khiến model trả đáp án không trích dẫn được trong nội dung truy được.

Khi mix ngôn ngữ—văn song ngữ của hỗ trợ quốc tế—overlap rất quan trọng vì ranh giới câu theo punctuation Latin không đánh dấu tốt câu tiếng khác trong cùng chunk.

Tính chi phí, trễ và chu kỳ embedding lại sau thay splitter

Việc tăng overlap mười lăm phần trăm có thể nhân một phần ba chi phí lưu trữ vector không gian của bạn; nếu bạn chưa tính, đơn đặt hàng cloud của bạn sẽ bất ngờ sau kỳ chỉnh tháng một.

Khi thay splitter, không chỉ rerun embedding—you cần ghi trong wiki phiên bản chunker để không ai triển khai model nhúng mới lên chỉ mục cũ vô tình. Với chỉ mục multi-tenant, metadata ACL phải đi một chunk trước khi tái chỉ mục; nếu không, các vector “mất” chủ sở hữu sẽ báo sai khi retrieval filter.

Đôi khi toàn corpus nhỏ hơn một cửa sổ của model (vài nghìn token) không cần vector nào—nhưng nếu stakeholder vẫn muốn RAG vì lý do thương mại, hãy chỉ ra chi phí bảo trì chỉ vì marketing.

Safe Local Tools như bàn tay thử không phá vỡ chỉ thị không upload

Đội không được phép dán playbook chưa công bố lên trang chia chunk công khai vẫn có thể mở tab cục bộ với các tệp mẫu đã được redact và xem các vết cắt ở biên trong vài giây. Đưa kết luận (kích cỡ và overlap cụ thể) vào PR kèm các con số recall giúp quyết định không còn trông như gust cá nhân.

Chunking là siêu tham số của văn bản: version hoá cấu hình trong git, ghi lại job re-embed khi đổi splitter, và đừng RAG hoá FAQ ba trang có thể nhét thẳng vào prompt. Khi bạn đo recall thay vì đoán, các cuộc họp về “512 hay 768” trở nên ngắn hơn đáng kể.