Chunking Là Gì?
Chunking là kỹ thuật chia nhỏ tài liệu dài thành các đoạn vừa phải trước khi đưa vào hệ thống RAG (Retrieval-Augmented Generation). Giống như bạn mượn sách ở thư viện, không ai đọc cả 500 trang một lúc mà chỉ photo đúng chương mình cần. Chunking đóng vai trò đó: cắt tri thức thành từng miếng nhỏ để khi có câu hỏi, hệ thống chỉ lấy ra đúng vài miếng liên quan nhất thay vì nhét cả kho tài liệu vào model.
Mình từng thấy nhiều dự án RAG thất bại không phải vì model yếu, mà vì chunking làm quá tệ. Đoạn cắt sai chỗ, câu bị đứt ngang giữa chừng, context thiếu đầu thiếu đuôi — model trả lời sai là chuyện đương nhiên.
Tại Sao RAG Cần Chunking?
Lý do đầu tiên là context window có giới hạn. Dù model hiện nay nhận được hàng trăm nghìn token, bạn vẫn không thể nhét toàn bộ tài liệu công ty vào mỗi lần hỏi. Chi phí đắt, tốc độ chậm, và độ chính xác còn giảm theo khi ngữ cảnh quá dài.
Lý do thứ hai là chất lượng truy xuất. Khi tài liệu được chia nhỏ và chuyển thành embedding, mỗi vector chỉ đại diện cho một ý riêng biệt. Tìm kiếm trở nên sắc bén hơn nhiều so với nhét cả chương dài vào một vector duy nhất — khi đó ý chính bị pha loãng giữa hàng nghìn từ rác.
Lý do thứ ba: kiểm soát chi phí. Bạn chỉ trả tiền cho vài trăm token được truy xuất, thay vì hàng chục nghìn token không liên quan.
Các Chiến Lược Chunking Phổ Biến Là Gì?
Fixed-size chunking là cách đơn giản nhất: cắt theo số ký tự hoặc số token cố định, thường kèm overlap (chồng lấn) khoảng 10-20% để tránh mất thông tin ở điểm cắt. Nhanh, dễ làm, nhưng dễ đứt câu giữa chừng.
Sentence và paragraph chunking cắt theo ranh giới câu hoặc đoạn văn. Ưu điểm là giữ được tính trọn vẹn của ý, phù hợp với bài viết có cấu trúc rõ ràng. Nhược điểm là kích thước các chunk không đều nhau.
Semantic chunking thông minh hơn: dùng embedding để đo độ tương đồng giữa các câu, rồi cắt ở những chỗ chủ đề chuyển hướng. Đoạn chat về giá cả và đoạn về chính sách bảo hành sẽ tách riêng. Tốn thêm một bước tính toán nhưng chất lượng cao hơn hẳn.
Parent-child chunking lưu cả hai cấp: chunk nhỏ để tìm kiếm chính xác, chunk cha (đoạn lớn hơn) để đưa vào model đầy đủ ngữ cảnh. Đây là cách nhiều hệ thống production đang dùng.
Chunk Size Bao Nhiêu Là Hợp Lý?
Câu hỏi được hỏi nhiều nhất, và câu trả lời thành thật là: tùy tài liệu. Tuy nhiên có vài con số tham khảo từ thực tế. Với tài liệu văn bản thông thường, 256-512 token cho một chunk là điểm khởi đầu tốt. Tài liệu kỹ thuật nhiều thuật ngữ thường cần chunk nhỏ hơn. Tài liệu pháp lý thì ngược lại, cần chunk lớn hơn để giữ trọn điều khoản.
Mẹo của mình: bắt đầu với 400 token, overlap 15%, đo chất lượng trả lời bằng bộ câu hỏi thử nghiệm, rồi tinh chỉnh. Đừng mất ba ngày chiến thuật hóa thứ mà một buổi thử nghiệm là ra kết quả.
Overlap Trong Chunking Có Tác Dụng Gì?
Overlap là phần chồng lấn giữa hai chunk liên tiếp. Nếu chunk đầu kết thúc giữa một ý đang dang dở, chunk sau sẽ chứa lại phần đó nhờ overlap, giảm nguy cơ mất thông tin ở điểm cắt.
Đánh đổi rất rõ: overlap càng lớn thì an toàn hơn, nhưng lưu trữ và chi phí truy xuất tăng theo vì cùng một nội dung bị lưu nhiều lần. 10-20% kích thước chunk là mức cân bằng mà đa số dự án dùng.
Lỗi Chunking Thường Gặp?
Thứ nhất là cắt giữa bảng biểu hoặc danh sách, khiến bảng bị xé làm đôi và model không thể hiểu. Nếu tài liệu có nhiều bảng, hãy dùng parser giữ cấu trúc thay vì cắt mù theo ký tự.
Thứ hai là bỏ qua metadata. Chunk nào thuộc tài liệu nào, chương nào, ngày cập nhật khi nào — nếu không lưu thông tin này thì sau này lọc và truy xuất theo nguồn sẽ bất khả thi.
Thứ ba là dùng một chiến lược chunking cho mọi định dạng. File PDF, trang web, slide, code mỗi loại một đặc thù. Cắt PDF bằng cách cứ 500 token một nhát thì bảng trong báo cáo tài chính thành mớ hỗn độn.
Công Cụ Nào Hỗ Trợ Chunking Tốt?
Trong hệ sinh thái Python, LangChain có sẵn các text splitter cho đủ loại chiến lược. LlamaIndex mạnh về node parsing kèm parent-child. Nếu làm việc với PDF phức tạp, Unstructured và Docling parse khá ổn về giữ cấu trúc. Với hệ thống vector database, các nền tảng như Pinecone hay Weaviate ngày nay tích hợp luôn bước chunking.
Kết Luận
Chunking nghe có vẻ là chi tiết kỹ thuật nhỏ, nhưng nó quyết định chất lượng của cả hệ thống RAG. Model giỏi đến đâu mà nhận vào ngữ cảnh bị cắt vụn thì câu trả lời vẫn tệ. Chọn kích thước phù hợp với loại tài liệu, thêm overlap hợp lý, giữ metadata cẩn thận — làm tốt ba việc này là bạn đã vượt qua phần lớn dự án RAG nghiệp dư. Khi đã vững cơ bản, hãy thử semantic chunking hoặc parent-child để nâng chất lượng truy xuất thêm một bậc.
