引言
做RAG的团队越来越多，但检索效果不达标的问题也越来越普遍。多数人会去调embedding模型、换向量数据库、优化prompt，折腾一圈，收益有限。问题往往不在这些地方------真正的答案藏在最容易被忽视的前置环节：文档分块（Chunking）。
分块，就是把长文档切成一段段"知识块"。它直接决定了两件事：检索阶段能否召回正确的内容，以及送入LLM的上下文质量。分块质量差，后面所有环节都会受影响------再强的模型也救不回来。
这篇文章的核心目的很直接：把2025-2026年间公开的5项主流基准测试数据摆出来，交叉对比7种分块策略的实测表现，再给出一套可以直接落地的选型决策框架。不吹某一种方法"万能"，也不贬低任何一种思路------因为数据告诉我们一个很清晰的结论：没有放之四海皆准的最优策略，只有匹配场景的正确选择。
第一章：分块为什么是RAG系统的生死线
1.1 分块质量直接决定检索精度
2025年NAACL发布的同行评审研究（arXiv:2410.13070，Vectara团队）对25种分块配置与48种嵌入模型进行了系统测试，结论很明确：分块策略对检索质量的影响，与嵌入模型的选择相当甚至更大。 换句话说，你在选模型上花的精力，可能不如先把分块策略搞对。
Chroma的评测数据更直观：在相同语料上，最优与最差分块策略之间的召回率差距达到9个百分点。这意味着什么？假设你的RAG系统召回率只有60%，换一个好的分块策略可能直接把它拉到69%------这比换模型靠谱得多。
1.2 "上下文悬崖"现象
arXiv 2601.14123（2026年1月发表，以下简称"arXiv 2601"）揭示了一个值得警惕的现象：当输入上下文超过约2500 tokens后，生成回答的质量出现断崖式下降。 他们称之为"Context Cliff"。
这不只是学术发现。Vecta在2026年2月的基准测试中也验证了类似趋势------chunk_size超过1024 tokens后，检索的F1分数开始明显走低；超过2500 tokens，问题更加严重。
原因不复杂：一个chunk里混入了多个主题，向量表示被"稀释"，检索精度下降。同时，大chunk里充斥无关信息，LLM的注意力被分散，生成质量也跟着掉。
1.3 分块不当的三种典型症状
在实际项目中，分块问题通常以这三种形式暴露出来：
症状一：语义碎片化。 关键信息被从中间切断，一个完整的定义或操作步骤被拆到两个chunk里，每个chunk单独看都不完整。
症状二：上下文丢失。 chunk被检索到了，但LLM拿着它生成不出答案------因为缺少必要的背景信息。比如chunk里写着"该方案的成本为350万元"，但没说是什么方案、什么时间范围。
症状三：冗余噪声。 chunk过大，包含了大量与查询无关的内容，向量相似度被稀释，真正相关的部分反而排不上去。
53AI在多个企业项目中反复验证过：先花时间诊断分块策略是否合理，再决定后续优化方向，往往比一上来就换模型有效得多。
第二章：7大主流分块策略原理与适用场景
在动手对比之前，先把7种主流策略的原理和适用场景说清楚。
2.1 策略总览
|-------------|------------------------------------|-----------|------------------|---------------|
| 策略 | 核心原理 | 实现复杂度 | 计算成本 | 典型适用场景 |
| 固定长度分块 | 按预设token数硬切，不考虑文本结构 | 极低 | 极低 | 通用基线、纯文本预处理 |
| 递归字符分块 | 按层级分隔符（段落→句子→空格）递归切分，LangChain默认策略 | 低 | 低 | 通用文本、综合性语料 |
| 句子级分块 | 先按句子边界切分，再聚合到目标大小 | 低 | 低 | 法律文本、FAQ、新闻公告 |
| 语义分块 | 用embedding模型计算相邻句子相似度，在语义突变处切分 | 中 | 高（需逐句调embedding） | 主题跳跃的长文档、会议记录 |
| 文档感知分块 | 利用文档结构（标题、章节、表格）定义chunk边界 | 中高 | 中 | 合同、技术手册、金融报告 |
| QA问答对分块 | 将文档内容转化为问答对形式存储 | 中 | 高（需LLM参与） | 客服知识库、FAQ系统 |
| 表格专用分块 | 针对表格数据的结构化切分，保留行列关系 | 中 | 中 | 数据报表、价格表、财务报表 |
2.2 各策略详解
固定长度分块（Fixed-size Chunking）
最朴素的方法。设定chunk_size=512，就每512个token切一刀。优点是实现极简单、速度快、对任何文本都能处理。缺点是会无视语义边界，可能把一句话从中间截断。
Ertas在2026年3月的基准测试中，固定长度分块的Recall@5为71.3%，排在5种策略的最后一位。但它胜在稳定------不同文档类型之间的表现波动最小。
递归字符分块（Recursive Character Splitting）
LangChain的默认实现。它按照分隔符优先级递归切分：先试双换行符（\n\n），不行就试单换行符（\n），再不行试句号、空格，直到切到目标大小以内。
Vecta在2026年2月的基准测试中，递归字符分块（512 tokens）以69%的端到端准确率排名第一。Ertas的测试中，它的Recall@5为78.6%，仅次于文档感知分块。
句子级分块（Sentence-based Chunking）
先按句子边界（句号、问号、感叹号）把文本切开，再把若干句子聚合成满足chunk_size的块。好处是保证了最基本的语义完整性------至少不会出现一句话被截断的情况。
arXiv 2601的研究显示，在5k tokens的上下文预算内，句子级分块与语义分块的效果统计上无显著差异（BERTScore差异≤0.004），但计算成本低得多。
语义分块（Semantic Chunking）
通过embedding模型计算相邻句子的余弦相似度，在相似度骤降的地方切分。块内主题高度聚焦。
听起来很美好，但实际表现有坑。Vecta的测试发现，语义分块产生的碎片平均仅43 tokens，端到端准确率只有54%------远低于递归分块的69%。原因很直接：碎片太小，LLM拿着这些碎片生成不出有意义的答案。
不过Ertas的测试中语义分块排名靠前（Recall@5 83.2%），说明在结构化企业文档场景下，语义分块仍然有竞争力。关键区别在于阈值调参和碎片合并策略。
文档感知分块（Document-aware Chunking）
利用文档自身的结构标记来切分------Markdown的##标题、HTML的<h2>标签、Word的段落样式。一个章节加上它的标题组成一个chunk，表格保持完整不被横切。
Ertas测试中表现最佳，Recall@5达到86.7%。在合同（89%）、技术手册（91%）、金融报告（88%）这类结构化文档上优势明显。但在非结构化的客服工单上反而最差（78%）------因为没有可靠的结构标记可用。
QA问答对分块
把文档内容转化为"问题-答案"对的形式存储。比如原文写着"退款政策为7天无理由退货"，转化为chunk："Q: 退款政策是什么？A: 7天无理由退货"。
这种策略在客服场景下效果很好，因为用户提问的方式与QA对的形式高度匹配。但成本较高------通常需要LLM来生成问答对。53AI在实践中发现，QA分块在FAQ类知识库中的检索准确率能比纯文本分块提升15-20个百分点。
表格专用分块
表格是RAG系统的难点。如果按普通文本分块，表头和数据会分离，行列关系丢失。表格专用分块会保留结构化信息，通常将表头作为元数据附加到每个数据行，或者将整个表格作为一个chunk处理。
53AI在处理数据报表类项目时，表格专用分块相比直接文本切分，检索准确率提升了约30%。
第三章：权威基准测试结果对比
2025-2026年间，多项独立基准测试给出了各自的答案。有意思的是------不同benchmark的结论并不一致。
3.1 五大基准测试核心数据
测试一：arXiv 2601.14123（2026年1月）
来源：学术预印本，使用Natural Questions数据集，SPLADE检索器 + Mistral-8B生成器。
|----------|-----------------------|-----------------|---------------------|
| 分块方法 | BERTScore | Exact Match | 备注 |
| Sentence | 基准最高 | 基准最高 | 性价比最优 |
| Semantic | ≈Sentence | ≈Sentence | 仅在>5k tokens上下文时略优 |
| Token | 显著低于Sentence/Semantic | 显著低 | 固定长度硬切 |
| Code | 最差 | 最差 | 不适合文本类任务 |
核心发现：
• 重叠（overlap）无可测量的收益，BERTScore差异≤0.004，EM差异≤0.001
• 句子级分块是性价比最高的方法
• 上下文超过2500 tokens后出现"上下文悬崖"
• 最优上下文大小取决于任务目标：语义质量在小上下文时最优，精确匹配在大上下文时更优
测试二：Chroma基准测试（2024年7月发布，持续更新）
来源：Chroma官方技术报告，13种分块策略，token级评估框架。
|--------------------|----------------|----------------|----------|------------|
| 策略 | 最优配置 | 召回率 | 精度 | IoU |
| LLMChunker | ~240 token无重叠 | 91.9±26.5% | 3.9±3.2% | 3.9±3.2% |
| ClusterSemantic | 400 token无重叠 | 91.3±25.4% | 4.5±3.4% | 20.7±14.5% |
| ClusterSemantic | 200 token无重叠 | 87.3±29.8% | 8.0±6.0% | 34.0±19.7% |
| RecursiveCharacter | 参数调优后 | 85-89% | - | - |
核心发现：
• LLMChunker召回率最高，但精度很低（召回多但噪声也多）
• ClusterSemantic的IoU表现最优（综合相关性与效率）
• 不同策略间的召回率差距可达9个百分点
• 启发式方法（如递归字符分块）在参数调优后表现稳定
测试三：Vecta基准测试（2026年2月）
来源：50篇学术论文语料（90.6万tokens），7种策略，端到端评估。
|---------------------|------------|-----------|-----------------------|
| 策略 | 端到端准确率 | 页面级F1 | 平均chunk大小 |
| Recursive 512-token | 69% | 0.92 | ~512 tokens |
| Fixed 512-token | 67% | 0.90 | 512 tokens |
| Semantic | 54% | 0.42 | 43 tokens （碎片化严重） |
| Proposition | 51% | - | 变长 |
| Fixed 1024-token | 57-61% | 0.88 | 1024 tokens |
| Page-per-chunk | 60% | 0.88 | 整页 |
核心发现：
• 递归分块和固定512-token分块在学术文本上表现最好
• 语义分块因碎片化（平均43 tokens）导致生成阶段上下文严重不足
• 语义分块需要精心调参（阈值、合并策略），否则表现脆弱
• 所有策略使用相同的embedding模型和检索pipeline
测试四：Ertas基准测试（2026年3月）
来源：200篇企业文档（合同50+技术手册50+财务报告50+客服工单50），5种策略，400个QA对。
|----------------------|--------------|---------------|-------------|----------|
| 策略 | Recall@5 | 平均延迟 | Token效率 | 索引大小 |
| Document-aware | 86.7% | 16ms | 0.88x（最优） | 0.91x |
| Semantic | 83.2% | 38ms （最慢） | 0.92x | 0.95x |
| Recursive character | 78.6% | 14ms | 1.05x | 1.02x |
| Sliding window (50%) | 76.8% | 13ms | 1.82x（最差） | 1.45x |
| Fixed-size (512) | 71.3% | 12ms | 1.0x | 1.0x |
分文档类型结果：
|----------------|--------|----------|----------|--------------|
| 策略 | 合同 | 技术手册 | 财务报告 | 客服工单 |
| Document-aware | 89% | 91% | 88% | 78%（最差） |
| Semantic | 80% | 84% | 82% | 87% （最好） |
| Recursive | 72% | 81% | 76% | 85% |
| Fixed-size | 64% | 73% | 68% | 80% |
核心发现：
• 结构化企业文档（合同、手册、报告）首选文档感知分块
• 非结构化文本（客服工单）语义分块反而更好
• 固定长度分块虽然准确率最低，但延迟最低、成本最可控
测试五：arXiv 2504.19754（2025年4月）
来源：Late Chunking vs Contextual Retrieval对比研究，使用NFCorpus和MSMarco数据集。
|----------------------|----------|----------|------------------|------------|
| 方法 | 语义保持 | 计算效率 | 资源需求 | 适用场景 |
| Late Chunking | 较好 | 高 | 需长上下文embedding模型 | 资源受限但需语义保持 |
| Contextual Retrieval | 最好 | 低 | GPU显存≥20GB | 高精度需求场景 |
| 传统分块 | 一般 | 高 | 低 | 通用基线 |
核心发现：
• Contextual Retrieval在语义连贯性上优于Late Chunking，NDCG@5提高约5.3%
• 但计算成本高得多（需要LLM为每个chunk生成补充上下文）
• Late Chunking效率高但牺牲了一定的相关性和完整性
• 两种方法都不能保证在所有数据集上全面超越传统分块
3.2 五大基准的交叉对比
把五个基准的结论放在一起看，几个关键发现：
发现一：不同benchmark的"冠军"不同。 Vecta选递归分块，Ertas选文档感知，arXiv 2601选句子级，Chroma选LLMChunker------没有任何一种策略在所有测试中排第一。这恰恰说明"没有万能最优"。
发现二：数据质量 > 策略选择。 arXiv 2601.14123（2026年6月发表的另一个系统性评估，arXiv:2606.00881）明确指出：计算成本更高的分块方法并未带来有意义的有效性提升。换句话说，很多高级策略看起来复杂，实际收益有限。
发现三：文档类型决定策略选择。 这是所有基准测试中最一致的结论。合同、手册、报告用文档感知分块效果最好；学术文本用递归分块或句子级分块；非结构化文本用语义分块；FAQ用QA分块。
第四章：分块参数调优指南
选定了策略，还有参数要调。下面三个参数的调优，直接决定最终效果。
4.1 chunk_size的最佳实践区间
不同研究的推荐区间不完全一致，但综合来看：
|----------------|------------------|---------------------------|
| 任务类型 | 推荐chunk_size | 依据 |
| 事实性问答（短答案） | 256-512 tokens | arXiv 2601 + Vecta基准 |
| 通用知识库问答 | 512 tokens | Vecta 69%准确率 + FloTorch验证 |
| 需要多段落上下文的分析型问题 | 512-1024 tokens | 多篇研究一致 |
| 技术手册/法律合同 | 1000-1500 tokens | bswen.com实测 + Ertas建议 |
| 客服FAQ | 128-256 tokens | 掘金技术社区实测 |
一条经验法则：256-512 tokens是大多数场景的安全起点。 在这个区间内，向量语义足够聚焦，LLM生成也有足够上下文。超过1024 tokens需要谨慎评估收益是否值得。
DLR（德国航空航天中心）2026年的研究（arXiv:2606.00881的引用研究）进一步验证：中等大小（256-512 tokens）在跨领域测试中表现最优，过小（128 tokens）和过大（1024 tokens）都会降低性能。
4.2 overlap是否还有价值？
这是2026年最有争议的话题之一。
反对overlap的证据： arXiv 2601.14123给出了最直接的结论------"overlap provides no measurable benefit and increases indexing cost"。在他们的实验中，添加10-20%的overlap，BERTScore差异≤0.004，EM差异≤0.001，但索引大小增加了25%（overlap=0.2时）。
支持overlap的观点： Chroma和LangChain的官方文档仍然推荐10-20%的overlap，理由是防止chunk边界截断关键信息。bswen.com的实测文章也分享了overlap=0时信息丢失的痛苦经历。
53AI的实践经验： 在结构化文档（合同、手册）中使用文档感知分块时，overlap的价值确实不大------因为结构标记本身就保护了语义边界。但在纯文本的递归分块场景下，保留10%的overlap（约50 tokens）能减少边界截断的概率，成本也可接受。
务实建议： 先用overlap=0跑基线。如果发现检索结果中出现"关键信息被截断在两个chunk之间"的情况，再加10%的overlap试试。超过20%通常没有额外收益，反而增加存储和计算成本。
4.3 embedding模型选择对分块效果的影响
Vectara的NAACL 2025研究表明，分块策略和embedding模型需要一起评估，不能孤立选择。
几个关键发现：
• 更大的embedding模型不等于更好的效果。DLR的研究发现模型大小与mean IoU分数之间存在轻微的负相关
• 开源小模型（如bge-m3、nomic-embed-text）在跨领域稳定性上优于部分商业模型
• 不同chunker-embedding组合在不同领域的表现差异很大，没有"通用最佳搭配"
建议： 先锁定一个embedding模型（推荐先试开源中等规模模型），再在这个模型上测分块策略。不要同时改两个变量。
第五章：53AI实战经验------5种专业分块策略
53AI Brain在大量企业项目中积累了一套分块策略体系。这里分享核心设计思路，不做推销------因为我们的经验恰恰是：不存在一种策略通吃所有场景。
5.1 为什么是5种而不是1种
53AI Brain提供5种分块策略：
-
通用语义分块 ------ 处理一般性文本知识
-
QA问答对分块 ------ 处理FAQ、客服话术等问答场景
-
表格数据分块 ------ 处理数据报表、价格表等结构化数据
-
产品方案分块 ------ 处理产品手册、解决方案等长文档
-
产品目录分块 ------ 处理商品目录、SKU信息等
为什么不是"万能一种"？因为在实际项目中，企业的知识库几乎总是混合了多种文档类型。一份合同里有文字段落（适合语义分块），有价格表（适合表格分块），有FAQ条款（适合QA分块）。用一种策略硬处理，效果必然打折扣。
Ertas的基准测试从数据上支持了这一点：文档感知分块在结构化文档上Recall@5高达91%（技术手册），但在非结构化的客服工单上只有78%。反过来，语义分块在客服工单上达到87%，但在合同上只有80%。文档类型决定策略选择，这是硬规律。
5.2 两级分块体系
53AI在实际部署中采用两级分块架构：
第一级：知识块（Knowledge Chunk）
• 目标：保留原始语义完整性
• 粒度：相对较大，一个知识块通常是一个完整的语义单元（一个章节、一个表格、一组FAQ）
• 用途：存储原始文档内容，保持可追溯性
第二级：检索块（Retrieval Chunk）
• 目标：面向检索优化
• 粒度：相对较小，面向embedding检索优化
• 特殊处理：添加元数据前缀（如"所属章节：退款政策 | 文档来源：客服手册v3.2"），增强检索时的语义匹配度
• 用途：实际参与向量检索的单元
这种"小块检索、大块生成"的父子架构，在实际项目中效果显著。小块保证检索精准度，大块保证LLM生成时有足够上下文。
5.3 混合使用 > 单一策略
53AI在多个项目中验证了一个规律：混合使用多种分块策略的效果，持续优于全程使用单一策略。
一个典型案例：某制造企业的质量管理体系文档库，包含操作手册（约200份）、检验标准（约100份）和故障案例表（约50张表）。
• 操作手册用文档感知分块（按章节标题切分）
• 检验标准用句子级分块（每条标准是独立的句子级条目）
• 故障案例表用表格专用分块
混合部署后，端到端检索准确率从单一递归分块的约65%提升到约82%。提升最大的部分来自表格和结构化内容的处理质量改善。
53AI的经验是：先对知识库做一次文档类型分析（通常是按文件格式和内容特征），再为每类文档选择对应的分块策略。这一步花的时间，往往比后续优化embedding模型值得多。
关于投标材料准备的沟通纪要如下：
1.确认杨总作为法人亲自参与投标，无需填写《法人授权书》，仅需提供法人身份证明（身份证复印件及营业执照）；
2.在商务偏离表备注说明：本项目由法人亲自参与，无需委托代理人；
3.原模板中《法人授权书》页面留白不填，若模板无独立法人身份证明页，需新增一页适配样式的法人身份证明页；
4.投标相关商务谈判的联系方式、邮件均留杨总的信息；
5.投标邮箱使用指定邮箱，后续由对方提供杨总邮箱具体信息；
6.修改文档时开启审阅修订模式，对存疑内容插入批注标注，统一整理后再集中反馈，避免零散询问；
7.投标材料整体样式需统一，不适用内容留白处理，无需额外添加投标专用说明。
第六章：场景化选型决策框架
把前面的数据和经验汇总，下面给出一个可以直接使用的决策框架。
6.1 决策树
你的文档有清晰的层级结构吗？（标题、章节、表格）
├── 是 → 文档感知分块
│ ├── 文档是合同/手册/报告 → chunk_size可大一些（512-1024 tokens）
│ └── 文档是技术API文档 → 考虑按函数/类切分
└── 否 → 继续判断
│
你的查询类型是什么？
├── 事实性短问答（"退款政策是什么"）→ 句子级分块 / 递归字符分块，256-512 tokens
├── 需要多段上下文分析的问题 → 递归字符分块，512-1024 tokens
├── FAQ/客服话术查询 → QA问答对分块
└── 不确定 → 递归字符分块 512 tokens，overlap=0，作为基线
│
知识库中包含表格数据吗？
├── 是 → 表格部分用表格专用分块，文本部分用上面的策略
└── 否 → 按上面的选择执行
6.2 场景化选型表
|------------|-----------------------------|------------------|------------------|---------------------|
| 文档类型 | 推荐策略 | 推荐chunk_size | 推荐overlap | 预期效果 |
| 技术文档/API文档 | 递归字符 / 文档感知 | 512 tokens | 0-10% | 准确率高，延迟低 |
| 产品手册/方案书 | 文档感知分块 | 512-1024 tokens | 0-15% | 结构化优势明显（Ertas: 91%） |
| FAQ/客服知识库 | QA问答对分块 | 128-256 tokens | 10% | 查询匹配度高 |
| 数据报表/价格表 | 表格专用分块 | 按行/按表 | 不适用 | 结构化信息完整 |
| 合同/法律文件 | 文档感知 + 句子级 | 256-512 tokens | 15-20% | 条款完整性有保障 |
| 学术论文 | 句子级 / 递归字符 | 512 tokens | 0%（arXiv 2601建议） | 性价比最高 |
| 会议记录/散文 | 语义分块（设最小chunk下限≥100 tokens） | 256-512 tokens | 10% | 主题聚焦 |
| 混合文档库 | 多策略混合 + 自动路由 | 按类型分配 | 按策略设定 | 整体效果最优 |
6.3 通用调优流程
不论选择哪种策略，53AI推荐的调优流程：
-
先跑基线 ：用递归字符分块（512 tokens，overlap=0）跑通整个pipeline，记录检索准确率
-
诊断问题 ：看检索结果中哪些chunk不相关（太大/太小/截断了关键信息）
-
针对性调整 ：根据问题选择------太大就缩小chunk_size或换语义分块，截断就加overlap或换文档感知分块
-
A/B测试 ：每次只改一个变量，对比效果
-
持续评估 ：知识库更新后重新评估分块策略
第七章：常见误区
误区一："分块越小，检索越准"
听起来有道理------chunk越小，向量语义越聚焦，相似度判别越精准。但Vecta的测试直接打了这个假设的脸：语义分块产生的碎片平均只有43 tokens，检索时可能命中了，但LLM拿着43 tokens生成不出有意义的回答，端到端准确率反而只有54%。
正确的认知是：检索精度和生成质量需要同时优化。 分块大小要在这两个目标之间找到平衡点。256-512 tokens是大多数场景下的安全区间。
误区二："overlap越多越好"
arXiv 2601.14123给出了目前最有力的反面证据：overlap在BERTScore和EM指标上无可测量收益，但会让索引大小膨胀25%。Ertas的测试中，sliding window策略（50% overlap）的token效率为1.82x（最差），索引大小是其他策略的1.45倍。
这不是说overlap完全没用。在纯文本递归分块场景下，10%的overlap确实能减少边界截断。但超过20%基本没有额外收益，只会增加成本。
误区三："语义分块一定优于固定长度"
语义分块是最"看起来高级"的策略------用embedding模型检测语义断点，听起来比硬切聪明多了。但Vecta和arXiv 2601的数据都显示：在默认参数下，语义分块不一定比简单的递归分块好。
Vecta的语义分块准确率54%，递归分块69%。arXiv 2601显示sentence≈semantic（在5k tokens上下文内）。Ertas的语义分块倒是排名靠前（83.2%），但延迟是递归分块的2.7倍（38ms vs 14ms）。
关键问题是：语义分块的默认阈值往往不合适。 Vecta自己承认，他们用的余弦相似度阈值0.7可能没调好。调好阈值+碎片合并策略后，语义分块确实能超过简单方法------但"调好"本身就需要大量实验。
误区四："一次分块，永远不分"
分块策略不是一劳永逸的决策。随着知识库增长、文档类型变化、查询模式演进，原来的分块策略可能不再适用。
53AI建议：每季度或知识库发生重大变更时，重新评估分块策略。具体做法是抽取50-100条代表性查询，检查检索到的chunk质量，对比上次的基线数据。
误区五："高级策略一定比简单策略好"
arXiv 2606.00881（2026年6月）的系统性评估给出了一个让人意外的结论：计算成本更高的分块方法并未带来有意义的有效性提升。 FloTorch 2026年2月的基准测试也得出了类似结论------递归字符分块（最简单的策略之一）击败了语义分块、命题分块等复杂方法。
这不是说高级策略没有价值。在特定场景下（如非结构化文本、长文档），语义分块和文档感知分块确实更好。但在通用场景下，简单策略往往够用，甚至更好。
FAQ
Q1：RAG分块到底选什么策略最好？
没有"最好"的策略，只有"最合适"的策略。如果你的文档有清晰结构，选文档感知分块；如果是通用文本，选递归字符分块512 tokens作为起点；如果是FAQ场景，选QA问答对分块。详见第六章的决策框架。
Q2：chunk_size设多少合适？
256-512 tokens是安全起点。事实性问答偏向256-512，需要多段上下文的分析型问题可以扩大到512-1024。不建议超过2500 tokens------arXiv 2601的研究表明超过这个值会出现"上下文悬崖"。
Q3：overlap到底要不要设？
先用overlap=0跑基线。如果发现边界截断问题，加10%的overlap试试。不要超过20%。arXiv 2601.14123的研究显示overlap在多数场景下无可测量收益，但会增加索引成本。
Q4：语义分块是不是比固定长度分块好？
不一定。Vecta的测试中语义分块准确率54%，远低于递归分块的69%。语义分块需要精心调参（阈值、合并策略），调不好反而更差。建议先用递归字符分块跑通，再根据实际需求决定是否升级。
Q5：混合文档库怎么处理？
按文档类型路由到不同分块策略。结构化文档（合同、手册、报告）用文档感知分块，非结构化文本用递归或语义分块，表格用表格专用分块，FAQ用QA分块。53AI的实际项目经验表明混合策略效果优于单一策略。
Q6：分块策略和embedding模型哪个更重要？
两者影响相当。Vectara（NAACL 2025）的研究表明，分块策略对检索质量的影响与embedding模型选择相当甚至更大。建议先把分块策略搞对，再优化embedding模型------因为分块策略的调优成本通常更低。
Q7：Late Chunking和Contextual Retrieval有什么区别？
Late Chunking先对整篇文档embedding再切分，效率高但可能牺牲相关性。Contextual Retrieval分块后用LLM为每个chunk生成补充上下文，语义保持更好但计算成本高（需要GPU显存≥20GB）。据arXiv 2504.19754的研究，Contextual Retrieval在语义连贯性上更优，但两种方法都不能保证全面超越传统分块。
Q8：知识库更新后需要重新调整分块策略吗？
建议定期评估。当文档类型发生变化、查询模式出现新模式、或者检索准确率明显下降时，应重新检查分块策略。每季度做一次抽检（50-100条查询）是个不错的节奏。
关联知识
向前引用
本系列第1篇：2026企业AI知识库选型指南：架构对比、RAG能力评估与落地路径------ 如果你还在规划阶段，建议先看第1篇了解知识库的整体技术选型逻辑。
向后预告
本系列第3篇：《企业RAG检索优化实战》 ------ 聚焦检索层面的进阶优化技巧，包括混合检索（BM25+向量）、重排序（Reranking）、查询改写等，是本文的延伸和深入。
本文由53AI团队撰写，基于公开研究数据和 53AI 企业项目实战经验。文中引用的数据均标注了来源和年份，如有更新变化请以原始来源为准。