Chunking là gì? Cách chia nhỏ dữ liệu cho hệ thống RAG

Chunking là quá trình phân tách tài liệu lớn thành những đoạn văn bản nhỏ hơn (gọi là chunk) để phục vụ việc nhúng (embedding) và truy xuất dữ liệu trong hệ thống RAG.

Kỹ thuật này đảm bảo dữ liệu đầu vào nằm trong giới hạn cửa sổ ngữ cảnh của mô hình nhúng, đồng thời giữ cho mỗi vector một ý nghĩa độc lập. Chọn sai chiến lược chia nhỏ có thể tạo ra khoảng cách tới 9% về độ phủ (recall) của toàn hệ thống.

Năm 2024, tỷ lệ doanh nghiệp áp dụng RAG tăng từ 31% lên 51%. Nhưng phần lớn kỹ sư vẫn loay hoay ở khâu hiệu năng. Chất lượng một hệ thống RAG không nằm ở chỗ bạn dùng mô hình ngôn ngữ lớn (LLM) đắt tiền đến đâu, mà nằm ở cách bạn cấu trúc dữ liệu đầu vào. Một chiến lược chunking cẩu thả sẽ khiến hệ thống trả về thông tin rác, làm loãng ngữ cảnh và đẩy mô hình vào trạng thái ảo giác.

Chunking là cầu nối giữa dữ liệu thô và không gian vector. Chia quá nhỏ thì mất ngữ cảnh, chia quá lớn thì làm nhiễu kết quả tìm kiếm. Muốn hệ thống vừa chính xác vừa kiểm soát được chi phí, bạn phải làm chủ các con số thực nghiệm thay vì tin vào lời quảng cáo về cửa sổ ngữ cảnh vô hạn.

Một tài liệu dài được chia thành nhiều chunk nhỏ, mỗi chunk trở thành một điểm vector trong không gian tìm kiếm của hệ thống RAG

Vì sao RAG bắt buộc phải chia nhỏ tài liệu?

Mọi mô hình nhúng đều bị ràng buộc bởi giới hạn vật lý của cửa sổ ngữ cảnh (context window). Khi bạn cố nén một tài liệu dài hàng chục trang vào một vector duy nhất, mô hình buộc phải lược bỏ chi tiết nhỏ để ưu tiên ý nghĩa tổng thể. Kết quả là hiện tượng "lost-in-the-middle": những thông tin quan trọng nằm giữa văn bản bị lu mờ hoàn toàn trong không gian vector, và hệ thống không tìm thấy chúng khi bạn truy vấn.

Chia nhỏ còn giúp giảm nhiễu ngữ nghĩa (semantic noise). Một đoạn văn bản chứa quá nhiều ý tưởng rời rạc sẽ làm loãng trọng tâm của vector. Khi đó phép tìm kiếm theo độ tương đồng cosine (cosine similarity) trở nên thiếu chính xác, vì vector đại diện cho chunk ấy không đủ gần với bất kỳ chủ đề cụ thể nào. Chunking giữ cho mỗi phân đoạn một ý nghĩa độc lập, để thuật toán tìm kiếm trúng đúng thông tin bạn cần.

Chia nhỏ tài liệu cũng là bước chuẩn bị để LLM xử lý thông tin hiệu quả nhất. Một chunk gọn gàng giúp mô hình tập trung vào dữ liệu liên quan thay vì bị xao nhãng bởi thông tin thừa xung quanh. Giảm bớt rác trong prompt giúp tăng độ chính xác và cắt đáng kể chi phí token hằng tháng. Bạn trả tiền cho từng token gửi đi, nên gửi những đoạn văn bản không liên quan là một sai lầm về mặt kinh tế.

Cuối cùng, chunking cho phép bạn xây dựng cấu trúc tìm kiếm linh hoạt hơn. Thay vì truy xuất một tài liệu khổng lồ, bạn lấy về 5–10 đoạn nhỏ từ nhiều nguồn khác nhau rồi tổng hợp thành câu trả lời. Điều này đặc biệt quan trọng trong hệ thống doanh nghiệp, nơi câu trả lời thường nằm rải rác ở nhiều báo cáo hoặc tài liệu kỹ thuật. Không chia nhỏ, bạn sẽ không bao giờ đạt được khả năng tổng hợp đa nguồn đó.

Đánh đổi cốt lõi: chunk to hay chunk nhỏ

Chọn kích thước chunk là bài toán tối ưu giữa độ chính xác truy xuất (precision) và lượng ngữ cảnh cung cấp cho mô hình. Chunk quá nhỏ, ví dụ chỉ vài câu, cho độ chính xác rất cao khi tìm kiếm. Nhưng khi đưa những đoạn ấy vào LLM, mô hình lại "mù" ngữ cảnh xung quanh. Một con số tăng trưởng 15% trong báo cáo tài chính là vô nghĩa nếu chunk đó không chứa tiêu đề mục để biết đấy là doanh thu hay chi phí nhân sự.

So sánh chunk nhỏ và chunk lớn: chunk nhỏ cho độ chính xác truy xuất cao nhưng mất ngữ cảnh, chunk lớn giữ được ngữ cảnh nhưng làm loãng vector nhúng

Ngược lại, chunk lớn giữ được mạch tư duy và cung cấp đủ bối cảnh cho mô hình hiểu vấn đề. Nhưng chunk càng lớn thì khả năng nhiễu càng cao: vector nhúng phải đại diện cho nhiều ý khác nhau, làm giảm độ sắc nét của kết quả tìm kiếm. Lạm dụng chunk lớn còn khiến hóa đơn API tăng vọt vì mỗi lượt truy vấn đều gửi kèm hàng ngàn token dư thừa.

Theo dữ liệu thực nghiệm, các truy vấn tra cứu dữ kiện (factoid) — tên, ngày tháng, con số cụ thể — hoạt động tốt nhất ở kích thước 256–512 token. Trong khi đó, truy vấn mang tính phân tích, so sánh hoặc tóm tắt cần chunk lớn hơn, thường trên 1024 token, để mô hình không bị đứt mạch thông tin. Sai lầm phổ biến là áp một kích thước cố định cho toàn hệ thống mà không đo xem người dùng thực sự hỏi kiểu gì.

Quy tắc thực dụng nhất vẫn là kiểm chứng bằng dữ liệu của chính bạn: thử vài kích thước phổ biến rồi chạy đánh giá (evals), thay vì áp dụng mù quáng cấu hình mặc định của một thư viện. Hiểu được sự đánh đổi này chính là khác biệt giữa một kỹ sư thực thụ và một người chỉ biết sao chép cấu hình.

Các chiến lược chia chunk phổ biến

Có bốn chiến lược chia nhỏ chính: cố định (fixed-size), đệ quy (recursive), theo trang (page-level) và theo ngữ nghĩa (semantic). Phương pháp cố định đơn giản nhất nhưng thường xuyên cắt đôi câu văn. Phương pháp đệ quy thông minh hơn ở chỗ cố giữ nguyên cấu trúc văn bản, ưu tiên ngắt ở ranh giới đoạn rồi mới đến câu. Semantic chunking thì dựa vào sự thay đổi trong không gian vector để tìm điểm ngắt, đổi lại chi phí tính toán lớn hơn nhiều.

Bốn chiến lược chia chunk đặt cạnh nhau: cố định, đệ quy, theo trang và theo ngữ nghĩa

Trong benchmark năm 2024 của NVIDIA, page-level chunking thắng với độ chính xác 0,648 và độ lệch chuẩn thấp nhất. Nghĩa là với tài liệu có cấu trúc phân trang rõ ràng như PDF, tôn trọng ranh giới trang vật lý mang lại hiệu quả truy xuất ổn định hơn hẳn. Điều đó đặc biệt đúng với báo cáo tài chính, nơi mỗi trang thường là một chủ thể logic hoặc một bảng dữ liệu hoàn chỉnh mà bạn không nên xé lẻ.

Các kỹ thuật nâng cao như ClusterSemanticChunker và LLMSemanticChunker cũng cho thấy tiềm năng. ClusterSemanticChunker dùng mô hình nhúng để gom những câu có độ tương đồng nội bộ cao vào cùng một chunk, tối ưu hóa tính mạch lạc về ý nghĩa. Nhưng một nghiên cứu công bố tại NAACL 2025 chỉ ra rằng chi phí của semantic chunking không phải lúc nào cũng xứng đáng: các đoạn 200 từ cố định vẫn đạt hiệu suất tương đương hoặc cao hơn trong nhiều tác vụ truy xuất và sinh câu trả lời.

Điểm khởi đầu hợp lý cho hầu hết hệ thống là RecursiveCharacterTextSplitter với thứ tự separators ["\n\n", "\n", ". ", " ", ""]. Thứ tự này quan trọng vì nó buộc bộ chia ưu tiên giữ nguyên đoạn văn trước, sau đó mới đến dòng, rồi mới đến dấu chấm câu. Tuân thủ cấu trúc ấy giúp các khối thông tin giữ được sự mạch lạc tự nhiên, tránh tình trạng nội dung bị xé nát tùy tiện làm hỏng chất lượng vector nhúng.

Chọn chunk size và overlap thế nào?

Trong triển khai thực tế, hãy bắt đầu với thiết lập mặc định: chunk size 400–512 token và overlap (độ chồng lấp) khoảng 10–20%. Một chunk 500 token thường chứa đủ 5–7 câu, tạo ra vector nhúng có đặc trưng ngữ nghĩa rõ nét. Overlap tạo một "cửa sổ trượt" để thông tin quan trọng không bị cắt đôi ngay tại ranh giới chunk, giữ được liên kết bối cảnh giữa đoạn trước và đoạn sau.

Cơ chế overlap giữa hai chunk liền kề: phần văn bản chồng lấp giúp câu bị cắt ngay ranh giới vẫn xuất hiện trọn vẹn trong một chunk

Đừng lạm dụng overlap. Một nghiên cứu hệ thống vào tháng 1/2026 dùng SPLADE retrieval và Mistral-8B trên tập dữ liệu Natural Questions cho thấy overlap không mang lại lợi ích đo lường được cho độ chính xác, trong khi vẫn làm tăng chi phí lập chỉ mục. Tăng overlap lên quá cao nghĩa là bạn lưu và trả tiền cho cùng một đoạn văn bản nhiều lần mà không thu lại hiệu quả tương xứng.

Cách duy nhất để biết con số nào đúng với dữ liệu của bạn là kiểm thử. Hãy thử ba mức — không overlap, 10% và 20% — rồi xem recall có thực sự cải thiện không. Trong nhiều trường hợp, một cấu trúc markdown sạch (đã loại bỏ HTML rác) sẽ khiến các điểm ngắt tự nhiên hoạt động tốt đến mức bạn gần như không cần overlap. Mục tiêu là hiệu suất đo được, không phải làm theo con số "best practice" trên mạng.

Nếu hệ thống của bạn xử lý văn bản nhiều liệt kê hoặc bảng biểu, overlap đóng vai trò một lớp bảo hiểm để tiêu đề cột không bị tách rời khỏi dữ liệu hàng. Còn với văn xuôi mạch lạc, một bộ chia đệ quy tốt thường đã làm xong nhiệm vụ giữ ngữ cảnh. Lời khuyên thực dụng: giữ overlap ở mức tối thiểu cần thiết để tiết kiệm tài nguyên tính toán và chi phí lưu trữ lâu dài.

Late chunking và contextual retrieval: hai cách vá ngữ cảnh bị mất

Late chunking (Jina AI) và contextual retrieval (Anthropic) là hai hướng tiếp cận hiện đại cho cùng một vấn đề: chunk bị mất ngữ cảnh. Late chunking đảo ngược quy trình truyền thống bằng cách cho mô hình transformer xử lý toàn bộ tài liệu (tối đa 8.192 token) trước khi cắt. Nhờ vậy, phép mean-pooling chạy trên các token embedding đã mang thông tin attention của cả bài, và mỗi vector chunk mang theo bối cảnh của những đoạn cách nó hàng ngàn token.

Late chunking nhúng toàn bộ tài liệu trước khi cắt, còn contextual retrieval gắn đoạn mô tả ngữ cảnh vào đầu mỗi chunk trước khi nhúng

Contextual retrieval xử lý theo hướng khác: dùng một LLM giá rẻ sinh ra đoạn mô tả ngữ cảnh ngắn (50–100 token) rồi gắn vào đầu mỗi chunk trước khi nhúng. Thay vì một chunk chỉ nói "chi phí tăng 5%", nó được bổ sung bối cảnh "đây là dữ liệu từ báo cáo tài chính quý 3 năm 2023 của ACME Corp". Cách làm này khiến mỗi phân đoạn trở nên độc lập, cho phép thuật toán tìm kiếm nhận diện chính xác ngay cả khi câu hỏi của người dùng thiếu thông tin định danh.

Con số thực nghiệm của Anthropic khá thuyết phục: riêng contextual embeddings giảm 35% tỷ lệ truy xuất thất bại, kết hợp thêm contextual BM25 thì giảm 49%, và thêm một bước reranking nữa thì giảm tới 67%. Chi phí tiền xử lý một lần rơi vào khoảng 1,02 USD cho mỗi triệu token tài liệu. Đổi lại, bạn phải chấp nhận đưa hẳn một bước gọi LLM vào pipeline nạp dữ liệu — với hàng triệu chunk, đó là khoản chi không hề nhỏ.

Late chunking kinh tế hơn vì nó chỉ tận dụng chính mô hình nhúng ngữ cảnh dài, không cần thêm lượt gọi LLM nào. Đổi lại, nó đòi hỏi mô hình hỗ trợ kiến trúc mean-pooling sau transformer thay vì các mô hình CLS-token cũ. Dữ liệu trên bộ BEIR cho thấy hiệu quả rõ rệt nhất ở tài liệu dài — mức tăng nDCG@10 lên tới 6,5 điểm trên NFCorpus — trong khi với dữ liệu ngắn như Quora thì gần như không đổi.

Đo chất lượng chunking bằng cách nào?

Bạn không thể tối ưu thứ mình không đo được. Ba chỉ số bắt buộc phải theo dõi là recall (độ phủ), precision (độ chính xác) và IoU (Intersection over Union). Recall và precision cho biết hệ thống có tìm đúng đoạn chứa câu trả lời hay không, còn IoU cho biết "hiệu suất token": tỷ lệ giữa số token thực sự liên quan so với tổng số token được truy xuất. Đây là chỉ số phát hiện bạn có đang nhồi rác vào prompt của mô hình hay không.

Ba chỉ số đo chất lượng chunking: recall, precision và IoU giữa token thực sự liên quan và toàn bộ token được truy xuất

IoU thấp nghĩa là bạn đang trả tiền cho thông tin thừa, vừa tốn kém vừa làm giảm khả năng suy luận của mô hình. Một hệ thống RAG tốt cần IoU cao — các chunk trả về phải súc tích và trúng mục tiêu. Hãy chạy đánh giá trên một tập tài liệu đại diện cùng những câu hỏi thật từ người dùng để tìm điểm cân bằng cho riêng hệ thống của bạn.

Chiến lược	Độ phủ (recall)	Chi phí vận hành	Độ phức tạp
Fixed-size	Thấp	Rất thấp	Thấp
Recursive	Trung bình–cao	Thấp	Thấp
Semantic	Cao	Trung bình	Trung bình
Contextual	Rất cao	Cao	Cao

Đừng nhảy ngay vào các chiến lược đắt tiền. Hãy đo recall của phương pháp đệ quy trước đã: chia đệ quy đạt 88,1% recall ở chunk 200 token và 89,5% ở chunk 400 token. Nếu hệ thống của bạn đã nằm quanh ngưỡng đó, việc nâng cấp lên semantic chunking chưa chắc xứng với chi phí — benchmark tháng 2/2026 của Vecta cho thấy semantic chunking chỉ đạt 54% độ chính xác, so với 69% của recursive 512 token, do sinh ra những mảnh vụn trung bình chỉ 43 token.

Cửa sổ ngữ cảnh triệu token có khai tử chunking không?

Nhiều người tin rằng khi mô hình hỗ trợ cửa sổ ngữ cảnh một triệu token thì không cần chunking nữa. Đó là quan niệm sai cả về kinh tế lẫn kỹ thuật. Chi phí xử lý một triệu token cho mỗi lượt truy vấn cực kỳ đắt so với việc chỉ truy xuất khoảng 20 chunk nhỏ. Bên cạnh đó, hiện tượng "context rot" — được ghi nhận trong nghiên cứu tháng 7/2025 trên 18 mô hình — cho thấy hiệu suất của các mô hình cửa sổ ngữ cảnh dài vẫn giảm dần khi độ dài đầu vào tăng lên, ngay cả với những tác vụ đơn giản.

Context rot: chất lượng phản hồi của mô hình giảm dần khi độ dài ngữ cảnh đầu vào tăng lên

Dữ liệu thực nghiệm còn xác định một "context cliff" ở ngưỡng khoảng 2.500 token. Vượt qua mốc đó, chất lượng phản hồi bắt đầu sụt giảm rõ rệt vì mô hình khó duy trì sự tập trung giữa một biển dữ liệu không cần thiết. Nạp quá nhiều thông tin không chỉ làm tăng độ trễ (latency) mà còn tăng khả năng xảy ra lỗi logic và ảo giác trong câu trả lời.

Chunking vẫn là nền tảng để kiểm soát chi phí và độ trễ. Với các ứng dụng đòi hỏi phản hồi nhanh như chatbot hỗ trợ khách hàng, bắt người dùng chờ mô hình đọc hết một triệu token là điều không thể chấp nhận. Truy xuất đúng vài chunk chất lượng cao luôn cho trải nghiệm tốt hơn và tiết kiệm tài nguyên hơn hẳn việc nạp toàn bộ tài liệu vào prompt.

Chunking cũng là cách duy nhất để mở rộng kho tri thức vượt xa giới hạn của bất kỳ cửa sổ ngữ cảnh nào. Kho dữ liệu doanh nghiệp thường chứa hàng tỷ token — không cửa sổ ngữ cảnh nào nuốt nổi. Dù mô hình có tiến xa đến đâu, nguyên tắc "rác vào thì rác ra" vẫn đúng: một kỹ sư RAG giỏi luôn ưu tiên tinh lọc dữ liệu đầu vào thay vì dựa dẫm vào sức mạnh tính toán thô.

Nên bắt đầu với chiến lược nào?

Hãy bắt đầu với RecursiveCharacterTextSplitter ở mức 400–512 token và overlap 10%. Đây là phương án đáp ứng phần lớn nhu cầu thực tế mà không đòi hỏi hạ tầng phức tạp hay thêm chi phí API cho khâu chia nhỏ, đủ tốt để bạn dựng một sản phẩm khả thi tối thiểu (MVP) và lấy đó làm mốc đo lường.

Chỉ nâng cấp lên semantic chunking hay contextual retrieval khi chính các chỉ số recall và IoU của bạn chứng minh bộ chia đệ quy đang bế tắc. Chunking là nơi đáng đầu tư thời gian nhất trong một pipeline RAG, nhưng cũng là nơi dễ tiêu tiền vô ích nhất nếu bạn chọn kỹ thuật đắt tiền trước khi có số liệu đối chứng.