Chunking Strategy: Vết Cắt Âm Thầm Phá Hỏng Retrieval
Chunk sai ranh giới không báo lỗi - nó chỉ khiến chunk đúng không bao giờ được lấy về, và bạn sẽ đi tìm nguyên nhân ở đúng mọi nơi trừ chỗ thật sự gây ra nó.
Thuộc chuỗi bài: RAG Pipeline: 5 Quyết Định Định Hình Chất Lượng Câu Trả Lời
Cách chunk mặc định mà hầu hết tutorial RAG dạy là chọn một số token cố định - ví dụ 400 - rồi cắt đều đặn theo con số đó cho tới hết tài liệu. Cách này rẻ, dễ triển khai, và là thứ đầu tiên mọi hướng dẫn RAG show ra. Đó cũng chính là lý do câu trả lời đúng nằm cách chunk được lấy về đúng ba token, bị xẻ làm đôi bởi một ranh giới không hề biết thế nào là một câu hoàn chỉnh, một hàng bảng, hay một tiêu đề section.
Chunking không phải bước tiền xử lý cấu hình một lần rồi quên - đó là một quyết định thiết kế quyết định retriever có thể tìm thấy được gì, bất kể embedding model hay reranker phía sau tốt tới đâu.
Sơ đồ Luồng Quyết Định Chunking
Vì Sao Cách Chunk Mặc Định Âm Thầm Phá Hỏng Retrieval
Fixed-size chunking theo số token coi tài liệu như một dòng token đồng nhất, không có khái niệm chỗ nào một ý kết thúc và ý khác bắt đầu - nó cắt bất cứ đâu bộ đếm chạm mốc, có thể là giữa câu, giữa hàng bảng, hoặc giữa một mệnh đề và con số nó đang nhắc tới. Lỗi này im lặng: không có gì báo lỗi, pipeline chạy trơn tru từ đầu tới cuối, và retriever vẫn trả về một chunk trông có vẻ hợp lý. Chỉ khi lần ngược một câu trả lời sai về đúng chunk nguồn thì vết cắt mới lộ ra - và lúc đó nó trông giống lỗi retrieval hay lỗi generation, chứ không ai nghĩ ngay tới chunking.
Recursive So Với Semantic Chunking: Số Liệu Thực Tế Nói Gì
Hai hướng thay thế xử lý vấn đề ranh giới theo hai cách khác nhau. Recursive chunking vẫn nhắm tới một ngân sách token, nhưng ưu tiên cắt tại điểm ngắt tự nhiên trước - đoạn, rồi câu, rồi từ - chỉ cắt cứng khi không còn lựa chọn nào khác phù hợp. Semantic chunking đi xa hơn: đo độ tương đồng embedding giữa các câu liên tiếp và cắt đúng chỗ chủ đề thực sự chuyển hướng, bất kể số token. Nghiên cứu năm 2024 của Chroma đo trực tiếp điều này: recursive chunking ở 400 token đạt khoảng 85-90% recall, semantic chunking đẩy con số đó lên khoảng 91-92% - đánh đổi bằng việc phải embed từng câu riêng lẻ trước khi có thể tạo chunk. Khoảng cách này có thật nhưng không quá lớn - và đó chính là điểm đáng chú ý: chỉ cần tôn trọng bất kỳ ranh giới tự nhiên nào cũng đã lấy được phần lớn cải thiện so với cắt cứng theo token, còn phần cải thiện thêm của semantic chunking cần cân với chi phí embed phát sinh.
Khi Kích Thước Chunk Không Phải Vấn Đề Thật, Cấu Trúc Mới Là Vấn Đề
Các cách sửa theo ranh giới câu không giúp được gì khi bản thân tài liệu không phải văn xuôi. Một bảng giá, một spec sheet, một văn bản pháp lý với các điều khoản đánh số - những tài liệu này có cấu trúc mà một bộ tách "biết câu" vẫn không nhìn thấy. Một hàng bảng bị cắt làm đôi tách nhãn khỏi giá trị của nó triệt để y như một vết cắt cứng theo token; một số điều khoản bị tách khỏi nội dung điều khoản mà nó dẫn vào thì đứng một mình cũng vô nghĩa. Với nội dung có cấu trúc, ranh giới chunk cần bám theo cấu trúc thật của tài liệu - ranh giới bảng, ranh giới section, ranh giới điều khoản - chứ không phải theo số token hay thậm chí ranh giới câu.
Soi Lỗi Ranh Giới Chunk
Điều khoản chấm dứt hợp đồng trong bao lâu?
"...bên B có quyền chấm dứt hợp đồng nếu bên A vi phạm nghĩa vụ thanh toán quá [CHUNK KẾT THÚC TẠI ĐÂY, TOKEN 400] trong thời hạn 30 ngày kể từ..."
Không tìm thấy thời hạn chấm dứt hợp đồng trong tài liệu.
Fixed-size chunking cắt đúng token thứ 400 mà không quan tâm ranh giới câu — câu điều khoản bị xẻ làm đôi, nửa sau (chứa số 30 ngày) rơi sang chunk kế tiếp không được lấy về cùng.
→ Chuyển sang recursive chunking (tôn trọng ranh giới câu/đoạn)
Mất Ngữ Cảnh Là Một Lỗi Khác, Không Liên Quan Tới Ranh Giới Cắt
Một chunk có thể tôn trọng hoàn hảo mọi ranh giới câu và bảng mà vẫn thất bại, vì bản thân câu đó phụ thuộc vào ngữ cảnh nằm ngoài chunk. "Doanh thu tăng 12% so với quý trước" là một câu hoàn chỉnh, đúng ngữ pháp - và vô dụng nếu đứng một mình, vì nó không nói rõ công ty nào, quý nào. Nghiên cứu Contextual Retrieval của Anthropic gọi tên đây là một failure mode tách biệt với lỗi cắt ranh giới: chunk mạch lạc nội tại nhưng bị cắt rời khỏi ngữ cảnh cấp tài liệu (tên công ty, kỳ báo cáo, tiêu đề section) vốn tạo ra ý nghĩa cho nó. Cách sửa của họ mang tính cơ học hơn là kiến trúc - thêm 50-100 token ngữ cảnh đó vào trước mỗi chunk trước khi embed - và cách này giảm 49% lỗi retrieval trong thực nghiệm của họ. Đây là một đòn bẩy khác hẳn với việc chọn recursive hay semantic chunking - và đáng áp dụng bất kể bạn chọn chiến lược cắt nào.
Chọn Chiến Lược Theo Loại Tài Liệu Và Loại Câu Hỏi
Không có kích thước hay chiến lược chunk nào đúng phổ quát, vì câu trả lời đúng phụ thuộc vào hai thứ thay đổi theo từng tài liệu: tài liệu được cấu trúc thế nào, và nó cần trả lời loại câu hỏi gì. Văn xuôi tường thuật dày đặc - báo cáo, bài viết - chịu được recursive chunking khá tốt, vì ranh giới đoạn/câu phần lớn trùng với ranh giới ý. Tài liệu có cấu trúc - hợp đồng, trang giá, tài liệu API - cần cách tách nhận diện cấu trúc, ưu tiên bảng, điều khoản, tiêu đề hơn số token. Câu hỏi cần một sự kiện đơn lẻ phù hợp với chunk phạm vi hẹp; câu hỏi cần tổng hợp trên một đoạn rộng hơn cần chunk đủ lớn để chứa trọn đoạn đó thay vì bị lấy về dưới dạng các mảnh rời rạc. Coi kích thước và chiến lược chunk là quyết định cần xem lại theo từng loại tài liệu, không phải một mặc định toàn cục đặt một lần lúc dựng pipeline.
Recall Theo Chiến Lược Chunk
Chunking strategy → % câu hỏi mà chunk đúng nằm trong top-k kết quả
Không tôn trọng ranh giới câu/đoạn/bảng — dễ cắt đứt thông tin liên quan giữa chừng.
Tôn trọng ranh giới đoạn/câu khi cắt — vẫn theo kích thước token nhưng ưu tiên điểm cắt tự nhiên.
Cắt theo ranh giới ý nghĩa (embedding similarity giữa các câu) — recall cao hơn, đổi lại chi phí embed từng câu tăng thêm.
Thêm 50-100 token ngữ cảnh (tên tài liệu, section) trước khi embed mỗi chunk — độc lập với việc chọn chiến lược cắt ở trên — giảm49% lỗi retrieval
3 con số này đến từ 2 thực nghiệm khác nhau (Chroma đo recall theo chiến lược cắt; Anthropic đo % giảm lỗi khi thêm ngữ cảnh) — không cộng dồn được thành một con số duy nhất. Đọc như 2 đòn bẩy độc lập: chọn chiến lược cắt tốt hơn, và thêm ngữ cảnh cho mỗi chunk — cả hai đều cải thiện recall nhưng theo cơ chế khác nhau.
Dấu Hiệu Cần Xem Lại Chiến Lược Chunking
Một chiến lược chunking từng hoạt động tốt lúc ra mắt có thể âm thầm ngừng hiệu quả khi tập tài liệu thay đổi - một loại tài liệu mới được ingest, một tài liệu cũ bị cấu trúc lại, hoặc một nhóm câu hỏi mới xuất hiện trong traffic thực tế. Tín hiệu cần theo dõi không phải cảm giác mơ hồ rằng câu trả lời "có gì đó sai sai" - mà là chỉ số recall (xem bài về đánh đổi recall/precision trong loạt bài này) giảm dần trên một loại tài liệu hoặc nhóm câu hỏi cụ thể, hoặc một mẫu lặp lại trong error analysis nơi chunk đúng vẫn nằm trong index nhưng chưa bao giờ lọt vào tập được retrieve. Cả hai tín hiệu này đều trỏ tới vấn đề ranh giới trước khi trỏ tới bất kỳ điều gì ở khâu sau.
Những Sai Lầm Thường Gặp Khi Quyết Định Chiến Lược Chunking
Một vài sai lầm lặp lại trong các pipeline RAG: chọn một kích thước và chiến lược chunk duy nhất cho một tập tài liệu thực ra chứa nhiều loại tài liệu có cấu trúc khác hẳn nhau; coi semantic chunking là bản nâng cấp tốt hơn tuyệt đối mà không cân chi phí embed phát sinh với mức recall thực sự đạt được; sửa vấn đề ranh giới nhưng bỏ qua mất ngữ cảnh, vì đây là hai failure mode tách biệt cần hai cách sửa khác nhau; và không bao giờ xem lại quyết định chunking sau khi đã ship, dù tập tài liệu nền tảng đã thay đổi hình dạng. Chunking là quyết định thiết kế đưa ra sớm trong pipeline, nhưng tác động của nó lộ ra rất muộn - trong từng câu trả lời sai mà nguyên nhân thật sự là một vết cắt được tạo ra từ nhiều tháng trước, ba bước ngược dòng.