Chiến lược Chunking RAG: 7 Phương pháp, Xếp hạng theo Dữ liệu Truy xuất (2026)

Chiến lược Chunking RAG: 7 Phương pháp, Xếp hạng theo Dữ liệu Truy xuất (2026)

Chiến lược chunking RAG quyết định những gì bộ truy xuất của bạn có thể tìm thấy trước cả khi bất kỳ truy vấn nào chạy. Nghiên cứu tháng 7 năm 2024 của Chroma đã chạy 472 truy vấn trên năm kho ngữ liệu với text-embedding-3-large, và bộ chia bạn chọn sẽ dịch chuyển recall khoảng năm điểm: 86,7% với bộ chia token thuần túy, 91,7% với bộ chia dùng GPT-4o, khi truy xuất năm chunk mỗi truy vấn. Precision còn dao động mạnh hơn nhiều. Trên toàn bộ báo cáo, chỉ số này chạy từ 1,5% đến 8,0%, biến việc chọn cỡ chunk thành một quyết định chi phí khoác lên mình lớp áo chất lượng, và mọi bài hướng dẫn ở trang một đều liệt kê cùng bảy phương pháp mà không chỉ ra phương pháp nào truy xuất tốt hơn.

Ý chính

• Chunking chia nhỏ tài liệu trước khi nhúng; các điểm chia quyết định bộ truy xuất của bạn tìm được gì và không tìm được gì.
• Trong nghiên cứu 472 truy vấn tháng 7 năm 2024 của Chroma, recall chạy từ 86,7% đến 91,7% giữa các bộ chia được đo.
• Precision biến thiên gấp nhiều lần so với recall, nên cỡ chunk chủ yếu là một quyết định về chi phí token.
• Bắt đầu ở 512 token với 10% overlap, rồi tinh chỉnh trên chính bộ eval của bạn.

Nên dùng chiến lược Chunking RAG nào? (Xếp hạng)

Với hầu hết các đội đang xây dựng trên văn bản xuôi phẳng, chunking ký tự đệ quy ở 512 token với 10% overlap là mặc định đúng. Nó tôn trọng ranh giới đoạn văn và câu, không tốn thêm chi phí, và trong benchmark 472 truy vấn của Chroma chỉ kém bộ chia dựa trên LLM 3,2 điểm recall. Chỉ rời đi khi tài liệu của bạn có cấu trúc mạnh hoặc bộ eval của bạn chứng minh điều ngược lại.

Nhận định của chúng tôi: hãy bắt đầu với ký tự đệ quy. Trong dữ liệu của Chroma, nó chỉ xếp sau bộ chia cluster và LLM về recall, và precision 3,9% của bộ chia LLM nghĩa là bạn nạp cho bộ sinh lượng nhiễu trên mỗi token liên quan nhiều gấp đôi. Hầu hết các đội không có vấn đề về chunking; họ có vấn đề về cỡ chunk mà chưa bao giờ đo lường.

Dữ liệu thực sự nói gì về cỡ chunk?

So sánh đối đầu công khai duy nhất về chiến lược chunking RAG là báo cáo kỹ thuật của Chroma "Evaluating Chunking Strategies for Retrieval" (Brandon Smith và Anton Troynikov, công bố ngày 3 tháng 7 năm 2024). Họ đã chạy 472 truy vấn trên 5 kho ngữ liệu (328.208 token), nhúng mọi thứ bằng OpenAI text-embedding-3-large, và truy xuất 5 chunk mỗi truy vấn. Các hàng dưới đây lấy từ bảng phụ lục của báo cáo cho tất cả kho ngữ liệu trên text-embedding-3-large ở 5 chunk truy xuất, nên chúng có thể so sánh trực tiếp với nhau:

Bảng kết quả chính của Chroma, vốn báo cáo một thiết lập truy xuất khác, đặt precision tốt nhất của bộ chia cluster ở 8,0% với recall 87,3%, và kéo dải precision trên tất cả các bộ chia từ 1,5% (KamradtSemanticChunker) đến 8,0%. Nguồn: Chroma Research, Evaluating Chunking Strategies

"Introducing Contextual Retrieval" của Anthropic (công bố ngày 19 tháng 9 năm 2024) tấn công vấn đề từ một góc khác. Tỷ lệ truy xuất hỏng top-20 cơ bản của họ là 5,7%; chỉ riêng contextual embeddings đã giảm xuống 3,7% (giảm 35%), thêm contextual BM25 đưa nó về 2,9% (49%), và reranking đẩy nó xuống 1,9% (67%). Anthropic không công bố cỡ chunk hay overlap chính xác được dùng, nên hãy xem đó là bằng chứng cấp phương pháp, không phải cấp kích thước. Nguồn: Anthropic, Contextual Retrieval.

Nhận định của chúng tôi: ba kết luận từ các phép tính. Thứ nhất, việc chọn bộ chia đáng giá recall thực sự, và Chroma nói thẳng điều đó: một số chiến lược vượt các chiến lược khác tới 9% recall. Trên bảng kết quả chính, recall chạy từ 83,6% (KamradtSemanticChunker) đến 91,9% (LLMSemanticChunker), và ngay trong các hàng truy xuất 5 ở trên nó vẫn trải từ 86,7% đến 91,7%. Precision di chuyển xa hơn nhiều lần trên cùng dữ liệu: 1,5% đến 8,0%, một mức chênh 5,3x so với 1,1x của recall. Vậy recall là nơi bạn nhặt thêm vài điểm, còn precision và chi phí token mới là nơi lựa chọn thực sự cắn răng. Thứ hai, bộ chia dựa trên LLM mua recall cao nhất bằng precision tệ nhất: bạn trả một lần gọi LLM mỗi tài liệu và nạp cho bộ sinh nhiều nhiễu hơn. Thứ ba, các con số của Anthropic cho thấy việc làm giàu chunk bằng ngữ cảnh (5,7% xuống 3,7%) đã dịch chuyển tỷ lệ hỏng xa hơn bất kỳ lựa chọn bộ chia nào trong bảng của Chroma. Hãy làm giàu chunk trước khi tinh chỉnh lại bộ chia. Reranking khôi phục các chunk mà bộ chia của bạn đã băm nát, và tìm kiếm hybrid kết hợp BM25 với truy xuất vector cũng vì cùng lý do.

Giới hạn trung thực: cả hai nghiên cứu đều dùng một mô hình embedding duy nhất, kho ngữ liệu chỉ tiếng Anh, và không nghiên cứu nào là bài kiểm soát trên chính kho ngữ liệu của bạn. Trên 472 truy vấn, khoảng cách giữa bộ chia tốt nhất và tệ nhất là khoảng 5 điểm recall ở 5 chunk truy xuất, và một khoảng cách lớn hơn nhiều theo tỷ lệ ở precision.

Vì sao cỡ chunk quyết định chất lượng truy xuất?

Cỡ chunk đặt độ hạt của khóa truy xuất. Một chunk 400 token tạo ra một embedding tập trung, khớp với các truy vấn cụ thể; một chunk 4.000 token lấy trung bình qua nhiều chủ đề và không khớp chính xác với bất cứ thứ gì. Chunk nhỏ truy xuất đúng đoạn cần tìm nhưng có thể phân mảnh một câu trả lời qua nhiều kết quả. Chunk lớn giữ ngữ cảnh liền mạch nhưng làm yếu tín hiệu embedding.

Trần ngữ cảnh của mô hình embedding cũng quan trọng. Nếu mô hình của bạn giới hạn ở 512 token đầu vào và bạn nạp 800, phần đuôi bị cắt bỏ trong im lặng. Embedding của bạn chỉ đại diện cho hai phần ba chunk. Không có lỗi nào được ghi lại.

Rồi đến phía bộ sinh. Liu và cộng sự đã chỉ ra trong "Lost in the Middle" (arXiv 2307.03172, 2023) rằng độ chính xác của LLM giảm hơn 20% khi tài liệu liên quan nằm ở giữa một ngữ cảnh dài. Truy xuất năm chunk 1.000 token sẽ đổ 5.000 token vào prompt, và câu trả lời bạn cần có thể rơi vào vị trí mà mô hình đọc tệ nhất. Chunk nhỏ hơn giữ đoạn liên quan gần hơn với vị trí mà mô hình xử lý tốt.

Hãy nghĩ về nó như một mục lục thư viện. Một tấm thẻ ghi "Mục 4.2, đoạn 3: chính sách hoàn tiền" đưa bạn đến đúng trang. Một tấm thẻ ghi "mọi thứ về thương mại thế kỷ 20" chỉ đưa bạn đến được tòa nhà. Embedding của bạn chính là tấm thẻ. Xây dựng ứng dụng RAG từ đầu đến cuối để thấy chunking nằm ở đâu trong pipeline, và đọc hướng dẫn kỹ thuật ngữ cảnh của chúng tôi để biết các chunk được truy xuất trở thành token prompt ra sao. Hướng dẫn chunking của Pinecone đóng khung cùng sự đánh đổi đó từ phía cơ sở dữ liệu vector.

Chunking kích thước cố định và đệ quy (Bắt đầu ở đây)

Kích thước cố định là đường cơ sở để bạn đo mọi thứ; đệ quy là thứ bạn thực sự triển khai.

Chunking token kích thước cố định

Chia mỗi N token bất kể nội dung.

def fixed_size_chunks(text: str, size: int = 512, overlap: int = 50) -> list[str]:
    tokens = text.split()  # whitespace proxy; use tiktoken for real token counts
    chunks = []
    step = size - overlap
    for i in range(0, len(tokens), step):
        chunk = " ".join(tokens[i : i + size])
        chunks.append(chunk)
        if i + size >= len(tokens):
            break
    return chunks

Câu trả lời đúng cho: văn bản xuôi phẳng không có cấu trúc tiêu đề, prototype nhanh, và bất kỳ so sánh cơ sở nào. Nó không ngốc. Nó là nhóm đối chứng.

Chunking ký tự đệ quy

RecursiveCharacterTextSplitter của LangChain chia theo một hệ thống phân cấp dấu phân cách: trước tiên \n\n (đoạn văn), rồi \n (dòng), rồi . (câu), rồi (từ). Mỗi chunk ở dưới chunk_size trong khi vẫn tôn trọng ranh giới tự nhiên lớn nhất vừa vặn.

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""],
    length_function=len,  # swap for tiktoken len for true token counts
)
chunks = splitter.split_text(document)

Danh sách dấu phân cách là phần mà mọi đối thủ đều bỏ qua. Bộ chia thử \n\n trước và chỉ lùi xuống . khi một đoạn văn vượt quá chunk_size. Nếu Markdown của bạn có các header, hãy thêm "## " trước "\n\n" để các phần được giữ nguyên vẹn.

Số học overlap chunk: ở 512 token với overlap 50 token, bước là 462. Một tài liệu 10.000 token tạo ra ceil(10000 / 462) = 22 chunk. Tổng số token được nhúng: 22 x 512 = 11.264, nghĩa là bạn nhúng lại khoảng 12,6% kho ngữ liệu dưới dạng overlap. Đó là chi phí lưu trữ và API để giữ cho các câu ở ranh giới không bị mồ côi.

Chunking ngữ nghĩa hoạt động thế nào, và có đáng với chi phí bỏ ra?

Chunking ngữ nghĩa nhúng mọi câu, đo khoảng cách cosine giữa các embedding câu lân cận, và chia tại nơi khoảng cách đó vượt một ngưỡng phân vị (thường là phân vị thứ 95). Các chunk gãy ở những điểm chuyển chủ đề thay vì số token tùy ý. Notebook "5 Levels of Text Splitting" của Greg Kamradt đã khởi nguồn cho cách tiếp cận điểm gãy phân vị này, và nghiên cứu của Chroma benchmark chính các bộ chia của ông theo tên.

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
splitter = SemanticChunker(
    embeddings,
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=95,
)
chunks = splitter.split_text(document)

Phần tính toán chi phí là thứ không ai đưa lên trước. Chunking ngữ nghĩa nhúng kho ngữ liệu của bạn hai lần: một lần để tính khoảng cách câu và tìm điểm gãy, một lần để nhúng các chunk kết quả cho việc lập chỉ mục. Ở mức giá $0,13 mỗi 1 triệu token của text-embedding-3-large từ OpenAI, một kho ngữ liệu 10 triệu token tốn $1,30 để lập chỉ mục bình thường và $2,60 với chunking ngữ nghĩa. Bạn trả gấp đôi trước cả khi một truy vấn duy nhất chạy.

Điều đó mua được gì? Trong các hàng truy xuất 5 của Chroma, bộ chia ngữ nghĩa dựa trên cluster đạt recall 89,0% và precision 6,7% so với 88,5% và 7,0% của bộ chia đệ quy ở cùng cỡ 200 token. Trong bảng kết quả chính, cùng bộ chia đó ghi nhận precision tốt nhất của nghiên cứu, 8,0%, ở recall 87,3%. Hơn kém nhau nửa điểm recall, và một kết quả precision đổi dấu tùy thuộc vào thiết lập truy xuất mà bạn đọc, cho một hóa đơn embedding gấp đôi. Phán quyết của chúng tôi: chunking ngữ nghĩa đáng giá trên các kho ngữ liệu đa chủ đề (kho lưu trữ tin tức, bộ sưu tập bài báo) nơi các ranh giới cố định thường xuyên chia cắt giữa chừng một chủ đề. Với các kho ngữ liệu đồng nhất (docs sản phẩm, một kho tri thức), bộ chia đệ quy cho bạn 95% chất lượng với một nửa chi phí. Nếu bạn chạy mô hình embedding cục bộ với Ollama, chi phí nhúng kép giảm xuống còn thời gian tính toán.

Chunking nhận biết tài liệu: Markdown, HTML và Code

Chia theo cấu trúc dùng chính các ranh giới của tài liệu (tiêu đề, mục danh sách, định nghĩa hàm) thay vì số lượng ký tự. Một H2 trong Markdown là một ranh giới ngữ nghĩa do con người cố ý đặt; một bộ chia ký tự sẽ băm nát nó.

from langchain_text_splitters import MarkdownHeaderTextSplitter

headers = [("#", "h1"), ("##", "h2"), ("###", "h3")]
splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers)
splits = splitter.split_text(markdown_doc)
# Each split carries metadata: {"h1": "...", "h2": "...", "h3": "..."}

Với code, các ranh giới là các nút AST. NodeParsers của LlamaIndex cung cấp các bộ chia nhận biết ngôn ngữ, gãy ở các định nghĩa hàm và lớp. Chi tiết then chốt: giữ khối import và chữ ký lớp bao quanh gắn liền với mỗi chunk hàm. Một thân hàm không có các import của nó là thứ nhiễu không thể nhúng được, nên hãy thêm cả hai vào trước mọi chunk và embedding sẽ nắm bắt được hàm làm gì và nó phụ thuộc vào gì.

Cụ thể cho RAG code: chia theo ranh giới AST, thêm import vào trước, 256-512 token mỗi hàm, zero overlap.

Còn Late, Hierarchical và Agentic Chunking thì sao?

Đây là những chiến lược chunking RAG nâng cao đứng sau những lời bàn tán về "RAG 2.0", và cả ba đều nằm ở mức phủ SERP 1/10.

Late chunking

Late chunking, được Günther và cộng sự giới thiệu trong "Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models" (arXiv 2409.04701, tháng 9 năm 2024), nhúng toàn bộ tài liệu bằng một mô hình ngữ cảnh dài trước, rồi gộp các embedding cấp token thành các vector chunk, để mỗi chunk mang theo ngữ cảnh toàn tài liệu và "nó có giá $40/tháng" biết "nó" ám chỉ điều gì. Bản tóm tắt tuyên bố khả năng truy xuất vượt trội trên nhiều tác vụ nhưng không công bố con số tiêu đề nào để chúng tôi có thể xác minh. Bài viết của Weaviate giải thích cơ chế và cũng dừng lại trước một so sánh có kiểm soát. Trạng thái bằng chứng: hứa hẹn, chưa được định lượng.

Chunking phân cấp (cha-con)

Lập chỉ mục các chunk nhỏ (256 token) để truy xuất; trả về chunk cha (1.024 token) cho bộ sinh. Bộ truy xuất tìm thấy cây kim; bộ sinh có được cả đống rơm xung quanh. Bạn duy trì hai cấp chỉ mục và một ánh xạ cha-con. Không có benchmark công khai nào cô lập được hiệu ứng này.

Chunking dựa trên LLM / agentic

LLMSemanticChunker của nghiên cứu Chroma dùng GPT-4o để quyết định điểm chia cho từng tài liệu: recall 91,7% (cao nhất) và precision 3,9% (thấp nhất). Bạn trả một lần gọi LLM mỗi tài liệu ở thời điểm lập chỉ mục (khoảng $100 cho một kho ngữ liệu 10.000 tài liệu) và nạp cho bộ sinh nhiều nhiễu hơn. Hãy dành nó cho những kho ngữ liệu thực sự bất quy tắc: hồ sơ pháp lý, PDF quét không có tiêu đề có thể trích xuất.

Cỡ chunk nào phù hợp với mô hình embedding của bạn?

Số token đầu vào tối đa của mô hình embedding là một trần cắt bỏ, không phải một khuyến nghị. Một mô hình chấp nhận 8.192 token không nhúng tốt hơn ở 8.192 so với ở 512. Chất lượng suy giảm do pha loãng từ rất lâu trước khi chạm trần: mô hình lấy trung bình ý nghĩa qua nhiều token hơn và vector trôi về phía trọng tâm của kho ngữ liệu. Cột khuyến nghị dưới đây là cách diễn giải của Techsy, không phải hướng dẫn của nhà cung cấp.

Nguồn: hướng dẫn embedding của OpenAI, docs Cohere embed, docs embedding Voyage, model card BGE.

Quy luật: các mô hình có trần 512 token cứng (Cohere v3, BGE) đòi hỏi các chunk thấp hơn nhiều so với 512, vì việc cắt bỏ diễn ra trong im lặng. Nạp cho nó 600 token và 88 token cuối cùng biến mất khỏi embedding mà không có lỗi nào được ghi. Các mô hình có trần lớn (OpenAI, Voyage, Cohere v4) chịu được chunk lớn hơn nhưng không tưởng thưởng cho chúng. Chiều dài đầu vào tối đa của một mô hình là một giới hạn cắt bỏ, không phải một khuyến nghị.

Hãy ghép điều này với bài tổng hợp các mô hình embedding tốt nhất cho RAG của chúng tôi, điểm MTEB thực sự đo lường điều gì, và so sánh embedding Voyage, OpenAI và Cohere trước khi bạn chốt một mô hình.

Bạn chunk tài liệu không phải tiếng Anh như thế nào?

Các bộ tokenizer không trung lập về ngôn ngữ. Petrov và cộng sự đã chỉ ra trong "Language Model Tokenizers Introduce Unfairness Between Languages" (arXiv 2305.15425, 2023) rằng cùng một văn bản khi dịch qua các ngôn ngữ có thể khác nhau về chiều dài sau tokenize tới 15 lần. Ngay cả các mô hình cấp ký tự và cấp byte cũng cho thấy chênh lệch hơn 4 lần ở một số cặp ngôn ngữ. Một chunk 512 token chứa ít ý nghĩa hơn nhiều trong tiếng Thổ Nhĩ Kỳ, tiếng Ả Rập hay tiếng Nhật so với trong tiếng Anh.

Đây là cùng một câu được tokenize bằng encoding cl100k_base của tiktoken (tokenizer của GPT-4):

import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
en = "The retrieval system returns relevant documents."
tr = "Erişim sistemi ilgili belgeleri döndürür."
ja = "検索システムは関連文書を返します。"
print(len(enc.encode(en)), len(enc.encode(tr)), len(enc.encode(ja)))
# 7 tokens, 19 tokens, 19 tokens: same meaning, 2.7x token spread

Số lượng được tạo bằng tiktoken cl100k_base, ngày 30 tháng 7 năm 2026.

Hướng dẫn thực hành: ở cỡ chunk cố định 512 token, các chunk tiếng Thổ Nhĩ Kỳ và tiếng Nhật của bạn chứa khoảng 37% ý nghĩa so với các chunk tiếng Anh, và các chunk tiếng Ả Rập chứa khoảng 26%. Hãy chia theo số ký tự hoặc số câu cho mỗi ngôn ngữ, hoặc tăng ngân sách token theo tỷ lệ (khoảng 1.400 cho tiếng Thổ Nhĩ Kỳ, 2.000 cho tiếng Ả Rập). Các ngôn ngữ CJK không có ranh giới từ bằng khoảng trắng, nên các bộ chia ký tự hoạt động khác đi. Hình thái học tiếng Ả Rập nhồi nhét nhiều marker ngữ pháp vào các token đơn, làm phồng số lượng hơn nữa.

Cây quyết định để chọn chiến lược chunking của bạn

What kind of document?
├── Structured (Markdown / HTML / code)
│   └── Document-aware splitting on headers or AST boundaries
│       ├── Docs site → MarkdownHeaderTextSplitter, 512 tokens, 0 overlap
│       └── Codebase → AST/function splitter, 256-512 tokens, imports prepended
├── Flat prose (articles, reports, books)
│   └── RecursiveCharacterTextSplitter, 512 tokens, 50 overlap
│       └── Topic-diverse? → try SemanticChunker at 95th percentile
├── Conversational logs (chat, support tickets)
│   └── Split on turn boundaries, group 3-5 turns per chunk, 256 tokens
└── Mixed corpus
    └── Route by MIME type → apply per-type strategy above
        └── Then: how long are expected answers?
            ├── Short (1-2 sentences) → child 256, no parent
            └── Long (multi-paragraph) → hierarchical: child 256, parent 1,024

Ba toa thuốc nhanh. Chatbot docs: MarkdownHeaderTextSplitter ở 512 token, zero overlap, đường dẫn tiêu đề trong metadata. Trợ lý tìm kiếm code: chia theo ranh giới AST ở 256-512 token mỗi hàm, thêm import vào trước. Kho ngữ liệu doanh nghiệp hỗn hợp: định tuyến theo loại tài liệu ở đầu vào và lưu trong cơ sở dữ liệu vector nơi bạn lưu trữ các chunk cùng metadata loại để tinh chỉnh theo từng loại sau này. Việc định tuyến theo từng tài liệu đó chính là toàn bộ nội dung của chunking thích ứng cho các ứng dụng RAG.

Công cụ: LangChain vs LlamaIndex vs Chonkie

Chúng tôi không bán bất kỳ thứ nào trong số này; ba trang xếp hạng đầu cho từ khóa này là các blog của nhà cung cấp với CTA sản phẩm.

Nguồn: docs LangChain, NodeParsers LlamaIndex, docs Chonkie.

Cả ba đều triển khai cùng các thuật toán cốt lõi, nên hãy chọn dựa trên những gì pipeline của bạn đã dùng. Để biết hệ sinh thái công cụ RAG rộng hơn vượt ra ngoài các bộ chia và so sánh Qdrant, Chroma và pgvector cho lưu trữ, hãy xem các hướng dẫn cụm của chúng tôi.

Cách Techsy tiếp cận chunking

Trong các bản dựng RAG cho khách hàng, đội Techsy bắt đầu ở 512 token với 10% overlap và không đụng vào bộ chia cho đến khi chúng tôi xây dựng một bộ eval 20-50 câu hỏi từ chính các vé hỗ trợ thực tế của khách hàng. Bộ eval có trước; sau đó chúng tôi đổi một biến mỗi lần: kích thước, overlap, chiến lược. Không đổi bộ chia mà không có con số trước-và-sau trên cùng các câu hỏi. Nhận tư vấn miễn phí để có thêm một góc nhìn thứ hai về pipeline truy xuất của bạn.

Về tác giả

Mert Batur là Đồng sáng lập của Techsy.io, nơi đội ngũ triển khai các AI agent, hệ thống tự động hóa, và các pipeline giọng nói/SDR cho khách hàng B2B. Anh viết về hệ sinh thái công cụ LLM mà đội Techsy thực sự dùng trong production, bao gồm cả công việc RAG và truy xuất đằng sau các bản dựng kho tri thức cho khách hàng. Kết nối trên LinkedIn.

Câu hỏi thường gặp

Chunking trong RAG là gì?

Chunking là bước tiền xử lý chia tài liệu thành các phân đoạn nhỏ hơn trước khi nhúng, để bộ truy xuất có thể khớp truy vấn với các đoạn tập trung thay vì toàn bộ tệp. Các điểm chia xác định những gì hệ thống của bạn có thể và không thể tìm thấy ở thời điểm truy vấn.

Chiến lược chunking tốt nhất cho RAG là gì?

Với hầu hết các hệ thống production trên tài liệu tổng quát, chunking ký tự đệ quy ở 512 token với 10% overlap là mặc định mạnh nhất. Trong nghiên cứu 472 truy vấn của Chroma (tháng 7 năm 2024), nó đạt recall 88,5%, trong vòng 3,2 điểm so với phương pháp dựa trên LLM đắt đỏ nhất, mà không tốn thêm chi phí.

Cỡ chunk tối ưu cho RAG là bao nhiêu?

Bắt đầu ở 512 token. Hạ xuống 256 nếu mô hình embedding của bạn giới hạn ở 512 token đầu vào (Cohere v3, BGE) hoặc nếu các truy vấn của bạn mong đợi câu trả lời một câu. Tăng lên 1.024 chỉ khi bộ eval của bạn cho thấy các câu trả lời nhiều đoạn văn đang bị phân mảnh. Luôn đo lường trên chính các câu hỏi của bạn.

Nên dùng bao nhiêu overlap chunk?

10-20% cỡ chunk (50-100 token ở 512). Overlap ngăn các câu ở ranh giới bị mồ côi: một sự thật bị chia qua hai chunk sẽ xuất hiện trọn vẹn trong ít nhất một chunk. Vượt quá 20%, bạn nhúng lại quá nhiều kho ngữ liệu mà lợi ích giảm dần. Hầu hết các đội chốt ở 10% và không bao giờ xem lại nó.

Chunking ngữ nghĩa có tốt hơn chunking kích thước cố định không?

Chỉ hơn một chút, và với chi phí embedding gấp đôi. Benchmark tháng 7 năm 2024 của Chroma cho thấy bộ chia ngữ nghĩa dựa trên cluster đạt recall 89,0% và precision 6,7% so với recall 88,5% và precision 7,0% của bộ chia đệ quy ở cùng cỡ token, với kết quả precision tốt nhất 8,0% của nó đến từ một thiết lập truy xuất khác. Đáng giá cho các kho ngữ liệu đa chủ đề; khó biện minh cho các bộ tài liệu đồng nhất.

Cỡ chunk có phụ thuộc vào mô hình embedding không?

Có. Các mô hình có trần đầu vào 512 token (BGE, Cohere v3) yêu cầu các chunk thấp hơn nhiều so với 512 vì việc cắt bỏ diễn ra trong im lặng. Các mô hình có trần 8.192+ chịu được chunk lớn hơn nhưng không tưởng thưởng cho chúng; chất lượng embedding suy giảm do pha loãng trước khi chạm trần. Xem bảng ghép nối ở trên để biết điểm khởi đầu cho từng mô hình.

Tôi chunk code cho hệ thống RAG như thế nào?

Chia theo ranh giới AST (định nghĩa hàm và lớp) thay vì số token. Giữ mỗi chunk ở 256-512 token mỗi hàm, thêm khối import của tệp và chữ ký lớp bao quanh vào trước, và dùng zero overlap vì các hàm là những đơn vị tự chứa. CodeSplitter của LlamaIndex và các bộ chia nhận biết ngôn ngữ của LangChain đều xử lý việc này.

Late chunking là gì?

Late chunking nhúng toàn bộ tài liệu bằng một mô hình ngữ cảnh dài trước, rồi gộp các embedding cấp token thành các vector chunk. Mỗi embedding chunk mang theo ngữ cảnh toàn tài liệu, giải quyết vấn đề "'nó' ám chỉ điều gì?". Được Günther và cộng sự giới thiệu (arXiv 2409.04701, tháng 9 năm 2024). Chưa có benchmark đối đầu công khai nào định lượng được mức lợi.

Tôi chunk tài liệu ở các ngôn ngữ khác tiếng Anh như thế nào?

Số token không trung lập về ngôn ngữ. Cùng một câu tốn số token gấp 2,7 lần trong tiếng Thổ Nhĩ Kỳ và tiếng Nhật so với tiếng Anh, và gấp 3,9 lần trong tiếng Ả Rập (tiktoken cl100k_base). Một ngân sách 512 token cố định âm thầm cho các chunk không phải tiếng Anh ít ý nghĩa hơn. Hãy chia theo số ký tự hoặc số câu cho mỗi ngôn ngữ, hoặc tăng ngân sách theo tỷ lệ.

Làm sao biết chunking của tôi có thực sự hiệu quả không?

Hãy xây một bộ eval 20-50 câu hỏi từ các truy vấn người dùng thực trước khi đụng vào bộ chia. Chấm điểm hit@5 và MRR trên các chunk hiện tại của bạn. Đổi một biến (kích thước, overlap, chiến lược), chạy lại, so sánh. Không có bộ eval, bạn đang tinh chỉnh bằng cảm tính. Hai mươi câu hỏi là đủ để bắt đầu.

Điểm mấu chốt

• Bắt đầu với chunking ký tự đệ quy ở 512 token, 10% overlap. Mặc định đúng cho văn bản xuôi phẳng.
• Trên bốn họ bộ chia mà bất kỳ ai đã đo, 472 truy vấn của Chroma dịch chuyển recall khoảng 5 điểm và precision nhiều hơn vài lần. Tinh chỉnh precision và chi phí trước.
• Khớp cỡ chunk với trần đầu vào của mô hình embedding. Một mô hình có trần 512 token đòi hỏi các chunk dưới 512.
• Làm giàu chunk bằng ngữ cảnh (mức giảm tỷ lệ hỏng từ 5,7% xuống 3,7% của Anthropic) trước khi tinh chỉnh lại bộ chia.
• Xây bộ eval trước. Mọi quyết định về bộ chia mà không có con số trước-và-sau đều là phỏng đoán.

Để biết toàn bộ pipeline xung quanh lựa chọn chunking của bạn, hãy xem xây dựng ứng dụng RAG từ đầu đến cuối. Vẫn đang phân vân giữa truy xuất và fine-tuning? RAG hay fine-tuning sẽ phân tích khi nào mỗi bên thắng.