What is Chunking?什么是分块（Chunking）？

You set your RAG quality ceiling at ingest, before the first query runs你在数据摄入阶段、首次查询运行之前，就已经设定好了 RAG 的质量上限。

Chunking splits documents into smaller passages before a RAG system embeds and indexes them, so a query retrieves only the passage that answers it. The split sets a ceiling on answer quality: chunk size, boundaries, and overlap decide what the model can ever see, and no later stage can recover what a bad cut threw away.分块是指在 RAG 系统对文档进行嵌入（Embedding）和索引之前，将其拆分为较小的段落，以便查询时只检索到能回答问题的那个段落。这种拆分设定了答案质量的上限：块的大小、边界和重叠部分决定了模型最终能看到什么，而后续的任何阶段都无法挽回因切割不当而丢失的信息。

🧭 Part 11 of the RAG & Search course🧭 RAG 与搜索课程第 11 部分

TL;DR

简而言之（TL;DR）

• The definition: a chunk is a few hundred tokens of text, embedded and indexed as its own retrievable unit.定义：一个“块”（chunk）通常包含几百个 token 的文本，作为独立的可检索单元进行嵌入和索引。

• Why it matters: retrieval ranks only the chunks that exist. A policy split across two chunks answers no question.重要性：检索只能对现有的块进行排序。如果一项政策被拆分到两个块中，那么任何问题都无法得到完整回答。

• Size and boundaries: too small strips the context a passage needs, and too big averages unrelated passages into one vector that matches no specific question. The good cuts land on paragraphs, headings, and sentence ends.大小与边界：切得太小会丢失段落所需的上下文；切得太大则会将无关内容平均到一个向量中，导致无法匹配任何具体问题。理想的切割点应位于段落、标题和句尾处。

• The overlap: the tail of each chunk gets copied onto the head of the next, so a sentence that straddles a cut survives whole in at least one chunk. The repeats cost extra vectors, so you hold overlap to 10 to 20 percent of the chunk.重叠（Overlap）：将每个块的末尾部分复制到下一个块的开头，这样跨越切割点的句子至少能在一个块中完整保留。由于重复会增加额外的向量开销，建议将重叠比例控制在块大小的 10% 到 20%。

• The catch: fancy cutting strategies barely beat the simple ones, and in one benchmark the simple one won outright. Tune the basics before reaching for anything exotic.关键点：花哨的切割策略并不一定比简单策略好，在某项基准测试中，简单策略甚至直接胜出。在尝试任何复杂方案之前，请先优化好基础设置。

Before Chunking, One Vector Per Document

分块之前：每个文档一个向量

The simplest version of the pipeline has no splitter in it. You have a folder of company PDFs, an embedding model, and a vector database. You embed each document as one vector, store one row per document, and match queries against them. This is document-level indexing. On small single-topic files it works. We took the full pipeline apart in What is RAG?.最简单的流水线没有分块器。假设你有一个包含公司 PDF 的文件夹、一个嵌入模型和一个向量数据库。你将每个文档嵌入为一个向量，每个文档存储一行，并将查询与它们进行匹配。这就是文档级索引。在小型单一主题的文件上，这种方法可行。我们在《什么是 RAG？》中详细拆解过完整的流水线。

An embedding compresses a passage into one fixed-length vector that sits near texts with similar meaning. What are Embeddings? takes the mechanics apart. One vector per document means one vector for the whole 80-page employee handbook. 嵌入会将一段文本压缩为一个固定长度的向量，使其在向量空间中靠近含义相似的文本。《什么是嵌入？》一文详细介绍了其原理。每个文档一个向量意味着整本 80 页的员工手册只有一个向量。

No embedding model reads 80 pages in a single pass, so the pipeline embeds the handbook in pieces and averages those into one document vector. Onboarding, expenses, security training, and vacation policy all land in the same point.没有任何嵌入模型能一次性读取 80 页内容，因此流水线会将手册分段嵌入，然后将它们平均为一个文档向量。入职、报销、安全培训和休假政策全都汇聚到了同一个点上。

Why One Vector Per Document Breaks Down

为什么“每个文档一个向量”的方法行不通

A new hire asks the company bot how many vacation days they get after year three. The answer sits on page 41 of the handbook. Retrieval compares the question against one vector per document and returns the closest.一名新员工询问公司机器人：工作满三年后有多少天年假？答案在手册的第 41 页。检索过程会将问题与每个文档的向量进行比较，并返回最接近的一个。

The handbook’s vector is an average of every subject in the book, and an average of concepts far apart scores badly against any specific question. 手册的向量是书中所有主题的平均值，而将差异巨大的概念平均化后，在面对具体问题时得分会很低。

Page 12 of that handbook says:手册第 12 页写道：

Expense reports above $500 require director approval before submission.超过 500 美元的费用报销在提交前需经主管批准。

Page 41 says:第 41 页写道：

Employees with three or more years of service accrue twenty days of paid vacation annually.服务满三年或以上的员工每年享有二十天带薪假期。

Both go into the embedding model together, along with the other seventy-eight pages, and come out as one list of numbers. That list is what the vacation question gets compared against.这两段内容与其他 78 页内容一起进入嵌入模型，最终变成了一个数字列表。而休假问题的查询正是与这个列表进行比较。

The handbook ranks below documents narrow enough to match the question, so the bot answers the new hire without ever seeing page 41.手册的排名会低于那些内容足够聚焦、能匹配问题的文档，因此机器人回答新员工时，根本看不到第 41 页的内容。

How Chunking Actually Works

分块的实际工作原理

A chunk has two jobs at once. It has to be small enough that its vector stays specific. It also has to be complete enough that the passage answers the question by itself.分块需要同时完成两项任务：既要足够小以保持向量的针对性，又要足够完整以使该段落能独立回答问题。

Those two pull against each other, and three decisions settle where you land between them:这两者存在矛盾，你需要通过以下三个决定来寻找平衡点：

1. where to cut, 在哪里切割，

2. how big to cut, and 切多大，以及

3. how much to repeat across cuts.在切割处重复多少内容。

The pipeline runs in two halves. Ingest happens once:流水线分为两部分。数据摄入只运行一次：

1. A splitter cuts each document into chunks.分块器将每个文档切成块。

2. An embedding model turns each chunk into its own vector.嵌入模型将每个块转化为独立的向量。

3. The vectors land in a vector store with the chunk text attached. We compared the stores themselves in Vector Database Showdown.向量连同对应的块文本存入向量数据库。我们在《向量数据库对决》中比较过这些数据库。

Query time runs the same steps from the other side:查询阶段则从另一侧运行相同的步骤：

4. The same model embeds the question.相同的模型对问题进行嵌入。

5. The index returns the top-k closest chunks, 3 to 10 in most setups.索引返回前 k 个最接近的块（大多数配置中为 3 到 10 个）。

6. The pipeline pastes those chunks into the prompt as the context the model answers from.流水线将这些块粘贴到提示词（prompt）中，作为模型回答问题的上下文。

Every stage downstream of step 1 handles chunks. The document as a whole never appears again.步骤 1 之后的所有下游阶段处理的都是“块”。整个文档再也不会出现了。

(1) Where to cut is which splitter you run, and the options runs from dumb to expensive:(1) “在哪里切割”取决于你使用的分块器，选项从简单到昂贵不等：

1. Fixed-size splitting cuts every N tokens no matter what the text is doing, fast and uniform. It has no notion of where a sentence or a rule ends, so a cut lands wherever the count runs out.固定大小分块：无论文本内容如何，每隔 N 个 token 就切一刀，速度快且统一。它不理解句子或规则在哪里结束，所以切割点完全取决于计数。

2. Recursive splitting cuts where the writing already pauses. It tries paragraph breaks first, then feeds any piece that is still too big back through itself on line breaks, then sentence ends. Running on its own output is what makes it recursive.递归分块：在文本自然的停顿处切割。它优先尝试段落换行，如果块仍然太大，则在换行符处继续拆分，最后是句尾。在其自身输出的基础上再次运行，这就是它被称为“递归”的原因。

3. Structure-based splitting follows the document’s own skeleton: markdown headings, HTML sections, PDF pages. The author grouped related content when they wrote it, and the split inherits that grouping, so tables and code blocks survive whole.基于结构的分块：遵循文档自身的骨架：Markdown 标题、HTML 部分、PDF 页面。作者在撰写时已经将相关内容分组，这种方法继承了该分组，因此表格和代码块能保持完整。

4. Semantic chunking embeds every sentence, then compares each one against the sentence before it. A large jump between two neighbours means the subject changed, so the splitter cuts at that point. The cost is an embedding pass over every sentence at ingest.语义分块：对每个句子进行嵌入，然后与前一个句子进行比较。如果两个相邻句子之间的跨度很大，意味着主题发生了变化，分块器就会在那里切割。代价是在摄入时需要对每个句子进行一次嵌入处理。

5. Agentic chunking hands the document to an LLM and lets it choose the boundaries, the way a person marking up a manual would. It is the only strategy that can tell a heading from a caption from a footnote, at a cost of one model call per document.智能体分块（Agentic chunking）：将文档交给大模型，让它选择边界，就像人工标注手册一样。这是唯一能区分标题、说明文字和脚注的策略，代价是每个文档需要调用一次模型。

6. Contextual enrichment does not move the cuts at all. After splitting, a model writes a one-line description per chunk, naming the document and section it came from, and that line goes in front of the chunk before embedding. A chunk that begins mid-rule then carries the policy name its own text left out.上下文增强：这种方法不改变切割位置。分块后，模型会为每个块写一段一行长的描述，标注其来源的文档和章节，并在嵌入前将其放在块的前面。这样，一个从规则中间开始的块也能携带其缺失的政策名称。

(2) How big to cut is the size setting, and the working band is 250 to 500 tokens. Tune from there against your own queries. A token-level evaluation by Chroma ran nine chunker configurations over identical corpora, models, and queries and found an 8-point recall spread between best and worst. Recall here is the share of each needed passage’s tokens that lands in the retrieved set. Plain recursive splitting at 400 tokens scored 89.5 percent. The best semantic chunker cleared that by under two points. The worst one sat at the bottom of the table at 83.6. OpenAI’s popular 800-token default gave up a point to recursive. Between the best cut and the worst, the share of each needed passage that never reaches the model doubles, from about 8 percent missing to about 16¹. Changing a splitter setting costs one re-index, which makes this the cheapest 8 points of recall in the RAG pipeline.(2) “切多大”是大小设置，工作区间通常在 250 到 500 个 token 之间。请根据自己的查询进行微调。Chroma 进行的一项 token 级评估在相同的语料库、模型和查询上测试了九种分块配置，发现最好和最差之间的召回率差距为 8 个百分点。这里的召回率是指所需段落的 token 在检索结果中占比。400 token 的普通递归分块得分为 89.5%。最好的语义分块器仅比它高出不到两个点。最差的分块器以 83.6% 的得分垫底。OpenAI 流行的 800 token 默认设置比递归分块低了一个点。在最好和最差的切割方式之间，所需段落中未能到达模型的比例翻了一倍，从约 8% 缺失增加到约 16%。更改分块器设置只需重新索引一次，这使它成为 RAG 流水线中性价比最高的 8 个召回率提升点。

(3) How much to repeat is the overlap setting. A fixed-size splitter on the handbook ends chunk 12 mid-rule:(3) “重复多少”是重叠设置。对手册使用固定大小分块器，可能会导致第 12 块在规则中间截断：

...Employees with three or more years of service accrue...服务满三年或以上的员工享有

Chunk 13 opens with the payoff:第 13 块以结果开头：

twenty days of paid vacation annually, subject to manager approval...每年二十天带薪假期，需经经理批准...

Retrieval pulls chunk 13, since that is where “twenty days” and “vacation” live, and the model quotes the number with no eligibility rule attached. Overlap is the fix. The splitter copies the last 40 to 60 tokens of each chunk onto the front of the next, so a sentence that crosses a cut survives whole in at least one piece.检索会拉取第 13 块，因为“二十天”和“假期”都在那里，模型会引用这个数字，但没有附带资格规则。重叠就是解决方法。分块器将每个块的最后 40 到 60 个 token 复制到下一个块的开头，这样跨越切割点的句子至少能在一个块中完整保留。

The repetition has a price. Fifteen percent overlap means fifteen percent more vectors to embed, store, and search. The duplicated text can also return twice, so two of your ten retrieved slots hold the same sentences and the model sees less of the corpus than you think. 重复是有代价的。15% 的重叠意味着需要嵌入、存储和搜索的向量多了 15%。重复的文本也可能被两次返回，导致你在十个检索槽位中占用了两个相同的内容，模型看到的语料库范围比你想象的要小。

The working baseline fits in one call:工作基准配置如下：

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter.from_tiktoken_encoder(
    encoding_name="cl100k_base",
    chunk_size=400,
    chunk_overlap=60,
)
chunks = splitter.split_text(handbook_text)

The plain RecursiveCharacterTextSplitter constructor measures chunk_size in characters rather than tokens, so asking for 400 gets you about 100 tokens of text. Building it through from_tiktoken_encoder measures in real tokens instead. This is the first thing I check when a pipeline is retrieving fragments.普通的 RecursiveCharacterTextSplitter 构造函数以字符而非 token 来衡量 chunk_size，所以设置 400 会得到约 100 个 token 的文本。通过 from_tiktoken_encoder 构建则会按真实的 token 计数。这是我在流水线出现检索碎片问题时首先检查的地方。

Who’s Actually Building With This

谁在实际使用这些技术构建系统？

Anthropic tested the ingest-side fix at scale. Their embeddings-only baseline failed to surface the needed chunk in the top 20 results 5.7 percent of the time². Contextual enrichment cut that to 3.7 percent, a 35 percent drop bought entirely at ingest, with no change to the model or the query. Two retrieval levers on top took it to 1.9 percent. The first is BM25, the classic keyword scorer we unpacked in What is Semantic Search?. The second is a reranker, which re-scores the shortlist before the top results ship.Anthropic 在大规模测试中验证了摄入端的修复方案。他们仅使用嵌入的基线方案在 5.7% 的情况下未能将所需块排在前 20 个结果中。上下文增强将这一比例降至 3.7%，这是一个完全在摄入端获得的 35% 的提升，无需更改模型或查询。在此基础上加入两个检索杠杆后，比例降至 1.9%。第一个是 BM25，即我们在《什么是语义搜索？》中拆解的经典关键词评分器；第二个是重排序器（reranker），它在结果返回前会对候选短名单进行重新评分。

NVIDIA benchmarked chunking strategies across five document sets, and the winner was page-level chunking: one chunk per PDF page, with no splitting logic at all. It averaged 0.648 accuracy, where 1.0 is a perfect score, beating every other strategy on average with the lowest variance across document types³. A page break rarely lands mid-table or mid-clause, which is most of what a splitter is trying to avoid. NVIDIA 在五个文档集上对分块策略进行了基准测试，获胜者是页面级分块：每个 PDF 页面一个块，没有任何拆分逻辑。它的平均准确率为 0.648（满分 1.0），在所有文档类型中平均表现最好且方差最小。分页符很少会落在表格或从句中间，而这正是分块器试图避免的大部分问题。

A Hugging Face team benchmarking RAG over nuclear engineering documents got the opposite result: the purpose-built chunker lost to the default one⁴. Their baseline was LangChain’s recursive splitter at 2,000 characters with a 400-character overlap, one of several sizes they tried, and the size barely moved the result. Across 156 test queries it beat their section-aware chunker 70.5 percent to 63.8, scoring the share of queries whose source document landed in the ten retrieved results. Their reading of why: cutting strictly on section headers orphaned content that ran across a boundary. The overlap in the default setup kept that same content together. Hugging Face 团队在核工程文档上对 RAG 进行基准测试时得到了相反的结果：专用分块器输给了默认分块器。他们的基线是 LangChain 的递归分块器，设置 2000 字符、400 字符重叠，大小对结果几乎没有影响。在 156 个测试查询中，它以 70.5% 对 63.8% 的胜率击败了他们的章节感知分块器。他们对原因的解读是：严格按章节标题切割会导致跨越边界的内容被孤立，而默认设置中的重叠保留了这些内容。

What Can Go Wrong (and What’s Overhyped)

可能出错的地方（以及被过度炒作的内容）

Five failure modes account for most chunking pain:五个失败模式解释了大部分分块带来的痛苦：

1. Boundary casualties. A cut that lands inside a table, a code block, or a numbered procedure breaks it. Split the handbook’s vacation-accrual table between its header row and its data rows, and the chunk holding the numbers arrives with no column names, so 15 and 20 mean nothing. Structure-based splitting exists for these documents.边界伤亡。落在表格、代码块或编号流程中间的切割会破坏其结构。如果手册的休假累积表在表头行和数据行之间被拆分，包含数字的块在检索时将没有列名，导致 15 和 20 毫无意义。针对这些文档，应使用基于结构的分块。

2. Near-duplicate retrieval. Generous overlap plus repetitive sections fills the top-k list with copies of the same paragraph. Every duplicate takes a slot, so the passages sitting just below the cutoff get pushed out and the model sees the same fact three times instead. Cap overlap and deduplicate retrieved chunks by text similarity.近重复检索。过大的重叠加上重复的章节会使 top-k 列表中充满同一段落的副本。每个副本都会占用一个槽位，导致截断线以下的段落被挤出，模型反而三次看到了相同的事实。请限制重叠，并根据文本相似度对检索到的块进行去重。

3. The precision trap. Shrinking chunks makes each vector more specific and strips away the context the passage needed to answer the question. Cut the handbook fine enough and the vacation number lands in a chunk of its own, with the years-of-service condition sitting in the chunk above it. Retrieval finds the number and the model answers without the rule.精度陷阱。缩小块会使每个向量更具体，但会剥离段落回答问题所需的上下文。如果把手册切得太细，休假天数可能落在一个块中，而服务年限条件却在上面的块里。检索找到了数字，模型回答时却丢掉了条件。

4. Ingest-time model bills. Semantic chunking runs an embedding pass over every sentence in the corpus. Agentic chunking runs a model call per document. On a million documents those passes cost real compute before the first query ships. Contextual enrichment runs a call per chunk and is the exception, because prompt caching drops it to about a dollar per million document tokens.摄入端模型账单。语义分块需要对语料库中的每个句子进行嵌入。智能体分块需要为每个文档调用一次模型。在百万级文档上，这些调用在首次查询前就会产生真实的算力成本。上下文增强需要为每个块调用一次，这是个例外，因为提示词缓存（prompt caching）可以将成本降低到每百万文档 token 约一美元。

5. Silent truncation. Every embedding model has a maximum input length, and it drops whatever runs past that point without raising an error. all-MiniLM-L6-v2, pulled about 254 million times a month, reads 256 tokens. Feed it the 400-token chunks the baseline above produces and it embeds the opening stretch, drops the rest, and returns a vector that looks exactly like any other. Its 256 limit counts MiniLM’s own word pieces, which are not the tokens your splitter counted⁵. Check your model’s limit before you set chunk size.静默截断。每个嵌入模型都有最大输入长度，超过该点的部分会被丢弃且不报错。all-MiniLM-L6-v2 每月被拉取约 2.54 亿次，它只能读取 256 个 token。如果你给它喂入上述基线产生的 400 token 的块，它只会嵌入开头部分，丢弃其余部分，并返回一个看起来与其他向量无异的向量。它的 256 限制计算的是 MiniLM 自己的词元（word pieces），而不是你分块器计算的 token。在设置块大小之前，请检查模型的限制。

The loudest claim about chunking right now is that long-context models killed it. Anthropic’s own guidance puts the no-RAG threshold at 200,000 tokens, about 500 pages. Below it, keep the corpus in the prompt and let prompt caching cover the rereads. Above it, you are retrieving, and retrieval runs on chunks. The other hype magnet is the exotic chunker, and the measured gap between the fanciest one and tuned recursive splitting was two recall points.目前关于分块最响亮的说法是长上下文模型已经终结了它。Anthropic 自己的指导意见将无需 RAG 的阈值定在 20 万 token，约 500 页。在此之下，将语料库放在提示词中，并利用提示词缓存来降低重读成本。在此之上，你仍然需要检索，而检索是在块上运行的。另一个炒作热点是花哨的分块器，但测量结果显示，最花哨的分块器与调优后的递归分块之间仅有 2 个召回率点的差距。

🏗️ Engineering Lesson: No single chunking setup is right for every corpus, and you cannot reason your way to yours. It depends on how much structure your documents carry, how narrow your queries run, and how much ingest compute you can spend. Keep fifty real queries with their known source passages, re-run them after every change, and read the number. A two-point gain and random noise look identical until you do.🏗️ 工程启示：没有一种分块设置适合所有语料库，你无法仅凭逻辑推导出最优解。它取决于文档的结构、查询的精准度以及你愿意投入的摄入算力。保留 50 个带有已知来源段落的真实查询，每次更改后重新运行并记录数据。在亲自实验前，两点的提升和随机噪声看起来是一模一样的。

Which of the six you land on comes down to two questions:你最终选择哪种方案，取决于两个问题：

1. The first is what your documents look like. Paginated files mean page-level splitting, which NVIDIA found beats every strategy on average. Headings are less reliable, since the Hugging Face team cut strictly on them and lost. Everything else starts recursive at 400 tokens with 60 of overlap.第一个是你的文档长什么样。分页文件意味着页面级分块，NVIDIA 发现它平均优于所有策略。标题不太可靠，因为 Hugging Face 团队严格按标题切割反而表现更差。其他情况建议从 400 token、60 重叠的递归分块开始。

2. The second is what your eval set says. Misses that trace to a cut landing mid-rule or mid-topic are what justify semantic or agentic chunking, or a contextual enrichment pass over the chunks you already have. Misses that trace anywhere else mean the splitter is not your bottleneck and the next fix sits further down the pipeline.第二个是你的评估集说了什么。如果漏掉的问题是因为切割点落在规则或主题中间，那么语义或智能体分块，或者对现有块进行上下文增强是合理的。如果漏掉的原因是其他情况，说明分块器不是你的瓶颈，下一个修复点在流水线的更下游。

The One Thing to Remember

要记住的一件事

A RAG system assembles every answer from pieces it cut before the first question arrived. Tuning retrieval, swapping embedding models, and adding rerankers all operate downstream of the same ceiling: the retriever chooses among the chunks the splitter made, and the model reads only what the retriever returns. Ingestion is where an answer becomes findable, or stops existing.RAG 系统组装的每一个答案，都源自首次查询前就已切割好的碎片。调优检索、更换嵌入模型和添加重排序器，都是在同一个上限之下运作：检索器只能在分块器制作的块中进行选择，模型也只能阅读检索器返回的内容。摄入阶段决定了一个答案是“可被发现”的，还是“根本不存在”的。

---

💬 What did a bad chunk boundary cost you? A wrong number, a split table, a policy quoted without its condition: tell me in the comments. I read every one.💬 不当的块边界给你带来了什么代价？错误的数字、拆分的表格、缺失条件的政策引用：请在评论区告诉我，我每一条都会读。

---

Where to Next?

下一步去哪？

• 📖 Go deeper: How Perplexity Built Their Search Engine, what retrieval looks like when the corpus is the whole web.📖 深入阅读：Perplexity 是如何构建搜索引擎的，了解当语料库是整个互联网时，检索是什么样子的。

• 🔀 Related: Agentic RAG vs CUA vs A2A, what happens when the retrieval loop itself becomes an agent.🔀 相关阅读：智能体 RAG vs CUA vs A2A，当检索循环本身成为一个智能体时会发生什么。

• 🔗 Prerequisite: How DoorDash Built Their RAG System, the guardrail side that catches bad answers after generation.🔗 先决条件：DoorDash 是如何构建 RAG 系统的，了解生成后捕获错误答案的护栏端。

🔜 Friday: How Meta Trained Llama 3 on 16,000 GPUs, four ways to split one model across a cluster, and why coordination beat compute as the bottleneck.🔜 周五预告：Meta 如何在 16,000 个 GPU 上训练 Llama 3，将一个模型拆分到集群上的四种方法，以及为什么协调比算力更早成为瓶颈。

FAQ

What is chunking in RAG?
Chunking cuts each document into passages of a few hundred tokens, and the RAG pipeline embeds and indexes those passages instead of the whole file. Retrieval then ranks passages, so the model receives the paragraph that answers the question rather than everything around it. Size, boundaries, and overlap decide whether that passage arrives focused and complete.RAG 中的分块是什么？分块将每个文档切割成几百个 token 的段落，RAG 流水线嵌入并索引这些段落而不是整个文件。检索时对段落进行排序，这样模型接收的是回答问题的段落，而不是周围的所有内容。大小、边界和重叠决定了该段落是否精准且完整。

What chunk size should I use for RAG?
Start between 250 and 500 tokens with 10 to 20 percent overlap, then tune upward against your own queries. The starting band is deliberately below where benchmarks land, since small chunks fail loudly and big ones fail quietly. NVIDIA’s five-dataset benchmark found 512 to 1,024 tokens best for token-based splitting, with page-level chunking the most consistent overall and 128-token chunks worst. Cut too small and a chunk keeps the number while losing its condition. Cut too big and its vector stops matching any specific question.RAG 应该使用什么块大小？从 250 到 500 token、10% 到 20% 重叠开始，然后根据自己的查询向上微调。起始区间特意设在基准测试结果之下，因为小块的失败很明显，而大块的失败很隐蔽。NVIDIA 的五个数据集基准测试发现 512 到 1024 token 对基于 token 的分块效果最好，页面级分块总体最稳定，128 token 的块最差。切得太小，块会保留数字但丢失条件；切得太大，向量就无法匹配任何具体问题。

What is chunk overlap and how much should I use?
Overlap repeats the tail of each chunk at the head of the next, so sentences that straddle a boundary survive whole in at least one piece. The working range is 10 to 20 percent of chunk size. More overlap means more vectors to store and search, plus near-duplicate passages competing for top-k slots, so raise it only when boundary failures show up in your evals.什么是块重叠，应该使用多少？重叠将每个块的末尾重复到下一个块的开头，这样跨越边界的句子至少能在一个块中完整保留。工作区间是块大小的 10% 到 20%。更多的重叠意味着更多的向量需要存储和搜索，且近重复的段落会竞争 top-k 槽位，因此仅在评估中发现边界错误时才增加重叠。

Do long-context models make chunking obsolete?
No. Anthropic’s guidance puts the crossover near 200,000 tokens, about 500 pages. A corpus smaller than that can skip retrieval: it sits in the prompt, and prompt caching keeps rereading it cheap. Anything larger still needs retrieval, and retrieval operates on chunks. 长上下文模型会让分块过时吗？不会。Anthropic 的指导意见将交叉点定在 20 万 token 左右，约 500 页。小于此规模的语料库可以跳过检索：它直接放在提示词中，且提示词缓存让重读成本很低。大于此规模的仍然需要检索，而检索是在块上运行的。

Is semantic chunking better than fixed-size chunking?
Yes on some corpora, and by less than the name promises. A token-level benchmark measured the best semantic chunkers about two recall points above tuned recursive splitting, and the worst semantic chunker scored below plain recursive. A Hugging Face team found the stock recursive splitter beat section-aware chunking by almost seven points on nuclear engineering documents. 语义分块比固定大小分块更好吗？在某些语料库上是的，但效果没有名字听起来那么夸张。一项 token 级基准测试显示，最好的语义分块器仅比调优后的递归分块高出约两个召回率点，而最差的语义分块器得分低于普通递归分块。Hugging Face 团队发现，在核工程文档上，现成的递归分块器比章节感知分块器高出近七个点。

1. Evaluating Chunking Strategies for Retrieval, Chroma Research (July 2024)

2. Introducing Contextual Retrieval, Anthropic (September 2024)

3. Finding the Best Chunking Strategy for Accurate AI Responses, NVIDIA Developer Blog (June 2025)

4. Evaluate Your Own RAG: Why Best Practices Failed Us, Hugging Face Blog (November 2025)

5. all-MiniLM-L6-v2 model card, Hugging Face