上周在处理一个RAG项目时，客户反馈检索效果始终不理想。换过embedding模型、调过召回阈值、重排逻辑也改了三版，效果始终差一口气。排查到最后才发现，问题根源既不在向量化，也不在检索链路，而是卡在了一个绝大多数团队会默认忽略的环节：文本分块（Chunking）。
这个发现并不意外。在我接触过的RAG项目里，分块策略的调优空间往往比embedding模型选型更大，但它又是最容易被“差不多得了”搪塞过去的技术决策。很多人直接把固定大小+重叠的写法套上去，跑通之后就去调别的环节，直到上线后被用户问“为什么这个答案只引用了半段话”才回头补课。
这篇文章就想把分块这件事讲透。从最底层的粒度决策逻辑，到五种主流策略的原理和适用边界，再到企业级落地时真正要面对的metadata、父子分块、摘要分块等工程问题，最后附上我踩过的六个典型坑和排查思路。内容以我实际项目中的做法和实验数据为主，适配正在做RAG工程化、或者准备把RAG从demo推向生产的团队参考。
1. 分块不是切文件，是替检索做“粒度决策”
很多人把分块理解为“因为上下文窗口有限，所以要把长文档切开”。这个说法不全错，但它只解释了一个最表象的问题。
1.1 上下文窗口只是“显性约束”，检索质量才是“隐性约束”
如果我们原地扩展上下文窗口——比如暂时不考虑成本，用超长上下文模型把整篇文档塞进去——你会发现检索环节依然会出问题。向量检索返回的是相关性最高的若干段落，如果整篇文档是一个向量，那检索到的就是“整篇文档”这个粒度，而不是“用户真正需要的那段话”。这时候无论上下文窗口多大，你拿到的都是一个大粒度的命中，精细化定位完全不存在。
所以分块的本质不是应对上下文长度限制，而是：**在文档内部建立可以被检索的最小语义单元。**上下文窗口限制了单元数量的上限，检索质量才是决定单元粒度的关键因素。
我在早期踩过一个教训：当时为了“尽量保留上下文”，把单块设到2000 tokens，结果用户问一个非常具体的问题时，召回命中的块里包含了一大半无关内容，生成阶段被这些噪声干扰，答出了一个“看起来都对，但关键参数错了”的结果。后来把粒度降到400 tokens，同样的检索链路，答案反而精准了很多。
1.2 分块粒度与检索性能的“跷跷板效应”
检索质量与分块粒度之间存在一组直接矛盾的两难：
- 块越大，语义完整性越高，但向量表示的精度越低。一个块里塞十个小话题，它的embedding必然是一个“混合平均态”，跟用户具体问题的向量距离会被拉远，导致召回漂移。
- 块越小，向量表示的专指度越高，但语义上下文越单薄。单独一句话往往缺少指代消解所需的背景，生成阶段容易断章取义。
这个矛盾没有“一次定终身”的解法，只能根据业务场景调整。但有一个指导原则：**检索阶段要吃小粒度，生成阶段要吃大语义。**后面要讲的父子分块就是这个原则的直接套现。
1.3 从语言层级结构看分块的本质
文本天然有层级结构：词→句子→段落→小节→章节→篇章。人类浏览文档时，靠的是这个层级逐层定位。而RAG检索本质上是把这个多层级结构“拍扁”成一维的向量列表，然后线性搜索。
分块策略的设计目标，就是让“拍扁”过程尽可能保留语言层级中的语义边界。所以判断一个分块策略好不好，最直观的标准是：切出来的每一块，放在单独语境里读，是不是一个“自洽的信息单元”？
这句话我常跟团队强调：不要看分块代码多复杂，就看结果是否符合语言直觉。如果切出来的块是一段话的中间半截、一个列表的三分之一、一个表格被拦腰截断，那这个策略无论技术上多成熟，对检索都是负收益。
2. 主流分块策略的横向拆解：原理、代码与适用边界
市面上的分块方案看似五花八门，其实底层思路就五类：固定窗口、递归字符、结构感知、语义分块、模型分块。下面逐个拆。
2.1 固定窗口分块：最省事，也最容易伤检索
固定窗口就是按固定token数或字符数硬切，加上一定比例的overlap。比如每800字符一块，重叠200字符。代码上最典型的就是LangChain的FixedSizeSplitter、LlamaIndex的FixedTokenChunking。
优点很明显：实现简单、算力开销低、行为可预期。但致命缺陷是完全无视语言结构。一个段落可能被切成两半，一个代码块可能从函数内部断裂。对这种无差别切割，embedding模型再强也难弥补——因为向量化的输入本身就已经是“语义残片”了。
我的判断是：固定窗口分块只适合两类场景。一是日志、告警这类无结构但有固定格式的文本，它们根本没有“语义边界”可言；二是极早期验证，单纯想先把链路跑通。除此之外，任何承载知识问答的文档库，都不建议用固定窗口。
2.2 递归字符分块：工业界默认选项，但别盲目信任
递归字符分块是目前LangChain默认的分块器，RecursiveCharacterTextSplitter。它的逻辑是维护一个分隔符列表（如["\n\n", "\n", "。", "，", " "]），按优先级逐级切分：先用段落分隔符尽量接近目标块大小，切不干净就用下一级分隔符继续切，直到块大小达标。
递归策略的设计初衷很明显：尽量把切割点推向更接近语义边界的位置，段落优先于句子，句子优先于短语。相比固定窗口，它做的不是一个“机械切分”，而是“按文本结构寻找可切点”。
但我实际用下来发现两个问题。第一，它对Markdown、HTML等结构化文本没有感知——不会因为# 标题的层级而改变切分策略；第二，分隔符列表是预设死的，对特定领域文本（比如法律条款、技术规范）效果并不稳定，需要针对语料调整分隔符。所以它只是“比固定窗口聪明一点”，离“理解语义”还很远。
如果你决定用递归分块，一定要重视分隔符列表本身的调优。我见过不少团队原封不动保留默认配置，拿标准分隔符去切企业内部的非结构化文档，结果切出来的块边界经常落在“表格中间”或者“节标题之后的第一句话”，非常尴尬。
2.3 结构感知分块：标题和格式是最廉价的“人工语义标注”
结构感知分块的思路很简单：文档的标题、列表层级、代码块本身就是作者留下的语义边界标记。用Markdown标题切分（MarkdownHeaderTextSplitter）、按HTML标签切分（HTMLHeaderTextSplitter）、按代码函数切分，都是这个思路的实现。
这种策略的性价比极高。因为它不依赖任何模型，直接用文档固有格式做边界判断，开销几乎为零，而且切出来的块通常非常符合人类阅读习惯。
我特别推荐一个使用方式：在结构感知分块的同时，用标题路径增强metadata。比如切出“安装指南→环境准备→依赖列表”这个块时，把完整标题路径记入metadata，后面检索结果展示时直接显示面包屑导航。这比存一个孤立的块内容要清晰得多。
结构感知分块的核心局限是：它要求文档本身有良好的结构。对扫描件OCR出来的纯文本、无格式的导出的日志、聊天记录这类文本，这个方法几乎没有施展空间。
2.4 语义分块与模型分块：效果上限高，成本也摆在明面上
语义分块的思路是用向量相似度判断句子间的语义边界：对每个窗口内的句子做embedding，计算相邻句子向量之间的cosine距离，在距离突降的位置切块。实现上有现成方案，比如LlamaIndex的SemanticSplitterNodeParser。
它在连续叙事性文本上的效果明显优于固定窗口，因为它切出的块是“语义连贯的片段”而不是“长度刚好的片段”。但代价也很明确：
- 计算成本高。每个句子都要过一次embedding模型，对大型文档库来说预处理时间会显著增加。
- 阈值选择很敏感。断点阈值设太大，块会很长；阈值设太小，块会碎成散句。不同领域的文本，最优阈值差异很大，需要拿真实语料调。
- 流式切分不稳定。它的切分结果受前半篇文档影响，文本稍有增删，后续边界就可能整体移动，对增量更新的索引不太友好。
模型分块更进一步，用LLM直接判断语义单元边界。准确率上限最高，但token消耗也最夸张。我的建议是：模型分块只用于高价值场景——比如法律合同的语义切分、核心知识库的离线构建，不太适合数据量巨大、更新频繁的场景。在企业级实践里，我更推荐把它作为一种“离线精切工具”，而不是在线pipeline的默认处理。
2.5 策略选型速查表
| 策略 | 核心原理 | 计算开销 | 语义边界质量 | 典型适用场景 | 不适用场景 |
|---|---|---|---|---|---|
| 固定窗口 | 按token/字符机械切割 | 极低 | 差 | 日志/告警、链路验证 | 知识问答类文档 |
| 递归字符 | 按分隔符优先级迭代切分 | 低 | 中等 | 通用文本、早期原型 | 强格式文本（表格/代码） |
| 结构感知 | 按Markdown/HTML/函数边界 | 低 | 好 | Wiki、技术文档、帮助中心 | 无格式纯文本 |
| 语义分块 | 计算句子间相似度变化 | 高 | 好 | 叙事型长文、研报 | 超高频率增量更新 |
| 模型分块 | LLM判别边界 | 很高 | 最佳 | 法务/医学等高价值文档 | 大规模常态化构建 |
3. 企业级分块设计的七阶段决策框架
直接给“推荐参数”没有意义，因为参数一定是跟着场景走的。下面是我在项目里总结的决策框架，比任何单一参数建议都好用。
3.1 决策前先回答七个问题
- 文本形态是什么？纯文本、Markdown、HTML、PDF扫描件、表格、代码，形态直接决定策略下限。用固定窗口去切含大量表格的Markdown文档，基本等于主动放弃表格信息的完整性。
- 用户的检索逻辑是什么？用户是按问题查答案，还是按章节浏览文档？前者需要小粒度精准召回，后者需要保留章节完整性。检索逻辑与分块粒度必须同步设计，否则检索层会“力不从心”。
- 上下文相关依赖有多强？文档里是否有大量“该设备”“如上所述”“按照第3步”这类指代表达？如果有，chunk太碎，生成阶段会丧失指代对象；chunk太大，又丢了检索精度。
- 对重排容错容忍度如何？如果你的检索链路有重排（rerank）环节，分块可以适当偏大、多召回一些候选，让重排层去做精细筛选。如果没有重排，分块就要更精准，因为第一轮的召回结果会被直接送进生成阶段。
- 存储和token成本上限是多少？语义分块和模型分块都会显著增加预处理成本。如果数据量在百万级文档，一次全量预处理的时间可能让团队放弃迭代。
- 需要多快的迭代速度？分块策略是个需要反复调优的环节。如果你每次调整分块，都要全量重新embedding、重新构建索引，那迭代周期会拖垮新策略的验证。需要提前设计好“分块参数可配置、重建索引可增量”的工程框架。
- 现有基础设施支持什么？团队如果已经引入了LangChain或LlamaIndex，直接切换到它们的结构感知分块工具成本很低；如果一切自研，就要权衡是自己实现还是一步到位上语义分块。
3.2 一张表对应一个场景的组合建议
| 场景 | 推荐策略 | 建议chunk size | 建议overlap | 备注 |
|---|---|---|---|---|
| 通用文档问答（纯文本） | 递归字符分块 | 500-800字符 | 10%-15% | 重点调分隔符列表 |
| 帮助中心/官方Wiki（Markdown） | 结构感知分块（按标题） | 不固定，按标题段 | 0%-10% | metadata计入标题路径 |
| 研报/长文叙事 | 语义分块 | 不固定，按语义边界 | 0% | 需要专门调阈值 |
| 法律合同/技术手册 | 模型分块+父子分块 | 视条款而定 | 0% | 高价值场景可接受高成本 |
| 日志/告警 | 固定窗口 | 300-500 token | 5%-10% | 不追求语义，只求格式稳定 |
这些参数只是起点。我强烈建议团队把分块参数配成配置文件而不是硬编码，因为迭代调优一定会反复改。
3.3 为什么“先定检索逻辑，再定分块策略”
分块和检索是强耦合的两个环节。你期望的检索行为，会直接约束分块的粒度。
举个实际例子：做产品手册的语义检索时，用户的问题通常是“XX设备的功率是多少”这种事实型问题，理想命中粒度是具体参数所在的句子或相邻段落。但如果按“章节”级切块，每次命中都是一整节，生成阶段需要自己在一大段文本里找“功率”这个答案，容易出错。
反过来，做AI原生文档浏览时，用户想看某章某节的内容，分块过细反而让章节连续性被打破，生成阶段拼凑出来的答案缺乏结构。这时候应该优先保留章节完整性，比如用结构感知分块按标题切，而不是按固定大小切。
所以正确的顺序是：先想清楚“用户会怎么提问”“我们期望系统以什么粒度回答”，再倒推分块策略。如果你先拍了一个chunk size再去调检索效果，大概率会来回返工。
4. 分块参数的实测方法与调参经验
分块参数调优最怕“拍脑袋”。我见到的常规做法是：凭经验定一个chunk size，跑几个样例看效果，感觉行就上线。这种做法最大的问题是没有对照，你不知道是检索问题、embedding问题还是生成问题。
4.1 chunk size与overlap的关系模型
overlap的作用是缓解“切在语义边界上”导致的信息断裂。当关键信息横跨两个chunk时，如果完全没有重叠，检索可能只命中一半，生成阶段拿到的就是残缺内容。
但overlap不是越大越好。重叠比例过高，会导致同一段内容在多个chunk里重复出现，检索时可能返回多个几乎相同的命中块，浪费上下文窗口，还会让重排环节失效。
我的经验公式是：overlap取决于chunk内部的信息密度和时间敏感性。信息密度高、时间敏感的文本（比如操作记录、技术参数），overlap可以放到15%-20%，尽量保证关键信息被至少一个块完整覆盖；信息密度低、叙述性强的文本（比如背景介绍、业务说明），overlap控制在5%-10%即可。另外，跨文档的全局性关键内容，可以借助metadata单独索引来解决，而不是全部押在overlap上。
4.2 用命中率、MRR和上下文利用率三条曲线决定参数
我的标准做法是，准备一组有代表性的真实问题集（建议50-100个，覆盖各种提问方式），固定embedding模型、检索策略和生成prompt，只改变分块参数，跑出三条曲线：
- Hit Rate（命中率）：检索结果中确实包含参考答案的比例。这一项衡量的是“有没有找对地方”。
- MRR（平均倒数排名）：正确答案在排序中的位置。这一项衡量的是“找对的同时排得靠不靠前”。
- 上下文利用率：在最终生成时，命中的chunk中有多大比例的信息被有效引用。这一项衡量的是“召回的信息有多少真的有用”。
调参的路径不是机械地找峰值，而是先保证Hit Rate达标，再看MRR排名，最后分析上下文利用率。比如我遇到过一个案例，Hit Rate在chunk size=600时达到85%，但MRR只有0.62，打开日志发现正确答案排在第三位，前面两位都是“沾边但不对”的内容。当时判断为chunk粒度太大，把语义“平均化”了，于是降到400重新测，MRR提升到0.78，代价是Hit Rate略降到82%。最后通过重排环节补回了Hit Rate，整体效果反而更好。
这提醒我一点：分块调优的目标不是单项指标拉满，而是为后续环节提供一个“搜索空间合理、信噪比可控”的输入。单一指标好看不代表链路整体最优。
4.3 embedding模型能力与分块粒度的匹配关系
不同embedding模型对语义的理解能力差异很大。通用型embedding模型在短文本上的相关性判断通常比长文本更稳定，所以在小粒度分块下表现反而更稳。而一些面向长文优化的模型，即便输入稍长也能保持较好的区分度。
这里有一个很实际的操作建议：不要单独测embedding模型的基准分，要在目标语料和分块策略下做联合评测。选模型、定分块参数、调检索策略，这三件事必须捆绑验证。我曾见过团队单独比较两个embedding模型，A模型得分更高，但配合上分块策略后，B模型的生成质量反而更好——原因就是B在小粒度文本上的向量分布更紧凑，和当前分块参数配合得更好。
5. 企业级落地中的三个关键工程：metadata、父子分块与摘要分块
分块策略定了之后，真正的企业级工程问题才刚开始。这一节讲三个我每次做RAG项目都会用到的工程模块。
5.1 metadata是与chunk同等重要的“第二半”
很多团队建索引时只存chunk的正文向量，metadata潦草填一个文件名了事。这个做法会让检索系统失去很多能力：
- 无法按来源过滤召回结果；
- 无法给用户显示“这段内容在文档的哪个位置”；
- 无法做结构化的权限控制；
- 无法做基于时间的局部索引刷新。
我在生产环境中给每个chunk至少保留这些metadata字段：来源文件路径、一级/二级标题路径、chunk序号、块在源文档中的字符偏移量、切分策略版本号、文档语言、创建时间、最后修改时间。加这一层metadata并不费劲，但对后续的排错、权限管理、增量更新帮助极大。
5.2 父子分块：解决“检索准”和“生成全”的矛盾
这是我最推荐的企业级方案之一。思路是分两层索引：
- 父块（Parent Chunk）：语义完整性高，一般按段落、小节甚至标题段落划分，用于生成阶段；
- 子块（Child Chunk）：粒度更细，一般按句子或短段落划分，用于检索阶段；
检索时命中子块，但把子块所属的父块内容一起送入生成。这样就可以用“小粒度保证精准召回”，同时用“大粒度保证完整语义”，绕开前面说的跷跷板效应。
我实际用下来是：子块按150-300 token划分，父块按500-800 token划分，检索链路命中子块后，生成阶段拼上父块上下文。实测在同一个项目里，Hit Rate提升大约5-8个百分点，生成阶段“断章取义”的问题基本消失。代价是存储量变大，因为父子两层都要创建向量索引。如果存储和成本敏感，可以只对父块做向量索引，子块用BM25等稀疏检索，做一个混合索引来平衡成本与精度。
5.3 摘要分块：为长文档检索提供“电梯楼层”
处理超长文档（合同、技术标准、政策文件）时，常规分块最大的问题是：单一chunk无法体现全局结构，用户问“这个文件大概说了什么”这类全局性问题时，检索效果会很差。
摘要分块的做法是：为每个文档（或每个大章节）先单独生成一段摘要，摘要进索引；检索时把摘要层作为“电梯楼层”，用户从摘要层定位到相关章节，再进入具体分块。这相当于给RAG系统加了一个“导读层”，特别适合企业知识库的首轮探索式提问。
成本方面，摘要本身会消耗token，但它只对文档或大章节做一次，整体成本可控，而收益非常直接：全局性问题不再依赖具体chunk的向量质量，而是由摘要“扛”了下来。我在处理一份120页的技术规范文档时，摘要分块让“这篇文章覆盖哪些测试方法”这类问题的答案完整度大幅提升，因为常规分块的chunk里根本没有承载“全部测试方法列表”的完整信息。
6. 分块踩坑实录：六个典型事故与排查思路
这一节不按理论顺序写，完全按我实际遇到的坑排序。这些问题在demo阶段很容易被忽略，一旦上线，就会变成用户投诉的源头。
6.1 接缝处关键信息丢失
现象：用户问“设备的保修期是多久”，检索命中的块里只有“保修期自交付之日起计算”，后面那个“12个月”在下一个chunk里，两个chunk都没完整信息，生成阶段答出了“保修期自交付之日起计算，但具体时长未注明”。
排查思路：先看这条问题的召回chunk列表，发现正确答案被拆在两个相邻chunk里。进一步检查分块边界，发现正好落在了“12个月”前面。解决办法有两个：一是适当增大overlap，保证这类信息落在重叠区；二是启用父子分块，让完整句子不被拆开。
我的判断：凡是信息以“短宾语”形式放在句尾的文档（技术参数、合同条款都这样），接缝问题会特别明显。这类文档建议优先上父子分块，而不是靠overlap碰运气。
6.2 表格被横向切碎
现象：包含产品参数表格的文档，表格的行被各种分块策略切得七零八落。检索一个型号对应的功率、重量、尺寸，命中的块只包含半行数据。
排查思路：表格是最特殊的一类文本结构，常规的分隔符对它完全无效。递归分块的\n和空格分隔符会把表格的行列全部打碎。解决方式有两种：如果表格不大，整表作为一个chunk；如果表格很大，按行逻辑切分，但每一行前面保留表头字段名作为上下文。
这里我特别提醒：很多RAG项目做完之后，“表格数据查不准”是最高频的用户反馈之一。建议大家在一开始就检查语料里表格的占比，提前决定表格处理方案。
6.3 代码块与正文互相污染
现象：技术文档里夹杂着代码示例，切分后，代码块的半个函数和前面的说明文字拼在一个块里，检索“如何配置连接池”时，命中的块里代码不完整，生成阶段解释得也很别扭。
排查思路：问题出在分块策略没有识别代码块的起止。解决方式：
- 在预处理阶段用代码块语法检测（```围栏、缩进块）把代码块单独提取出来；
- 结构感知分块，优先在代码块边界切分；
- 代码块和说明文本分别走不同的分块策略，代码按函数切，文本按段落切。
这个方案起初会增加一批预处理逻辑，但对技术文档型知识库，几乎是必须配置。
6.4 chunk来源丢失，无法追溯
现象：某个答案引用了一段内容，但用户追问“这一段是哪个文档的第几章”时，系统提供不了来源信息，客户直接对系统的可信度失去信心。
排查思路：根因是chunk构建时没有保留文档路径和标题路径metadata。这个坑不是检索链路的问题，而是索引设计缺陷。修复方式是重建索引，为每个chunk补齐来源文件、章节路径、块序号等字段，并在生成阶段强制让模型输出引用时携带这些metadata。
在企业场景里，答案可信度直接决定RAG系统能不能被业务部门接受。这一步绝对不要省。
6.5 专有名词被拦腰截断
现象：领域术语“第三代半导体衬底材料GaN-on-SiC”被切到两个chunk里，检索“GaN-on-SiC”时，命中的块里只出现了半截词，向量匹配质量大幅下降。
排查思路：根本原因是分块边界没有避开专有名词，常见的做法是加一个内置词表（包括公司产品名、行业术语、缩写），在二次切分时把词表里的连续token视为不可分割单元；同时增大chunk size和overlap，把这类信息尽可能放进重叠区。
我见过更彻底的方案：在预处理阶段做一个“术语短语检测”，把识别出的术语短语先整体转换成带特殊字符的占位符，切分完成后再还原。这样专有名词在任何分块策略下都不会被切开，但实现复杂度偏高，适合术语密度极高的领域（医学、专利、技术标准）。
6.6 短文档被过度切分做出一堆“哑巴块”
现象：语料库里有大量200-300字的短文档（通知、说明、通知单），分块策略按固定参数切，每篇被切成1-2块。检索时“哑巴块”太多，命中了很多语义雷同的短块，排序混乱。
排查思路：不是所有文档都需要分块。短文档应该直接作为一个整体chunk写入索引，或者干脆用“文档级索引”而不下钻到块级。我对短文档的处理标准是：低于某个长度阈值（比如400字符），整体作为单块，并加一个“is_short_doc”标记，检索时单独给这类文档更高的排序权重。
7. 分块的下一个形态：从固定策略到分块流程编排
最后聊一点前瞻性的东西。我最近在跟进的两个方向，都和分块的定位有关。
7.1 Agentic RAG下chunk开始承担“工作单元”职责
Agentic RAG里，chunk不再只是被动等待检索的文本片段，它开始变成智能体规划过程中的“工作单元”。比如一个研究助理Agent，它需要从多个chunk中提取论据、交叉验证、合并输出，这时分块策略要考虑的不只是“用户问什么能命中”，还要考虑“这些chunk之间是否有足够的关联线索让Agent串联起来”。metadata里的标题路径、文档间引用关系，都会在这种模式下发挥更大价值。
7.2 GraphRAG用分块重新定义知识粒度
GraphRAG的方向是先把文档切块，再从块中抽取实体和关系，构建知识图谱。分块在这里变成实体抽取的“上下文窗口”——窗口太小，跨句关系抽取不出来；窗口太大，实体密度失控，图会变得稀疏且噪声大。GraphRAG项目通常需要针对实体密度做分块适配，这是一个和传统问答完全不同的分块目标。
7.3 可预期分块：先把“结构”识别出来，再决定怎么切
我越来越倾向于一个理念：分块不该是“切完了再看”，而是“先识别文档结构，再按结构切”。文档本身就是结构化的产物，我们需要做的不是用固定大小去覆盖它，而是先把标题层级、列表、表格、代码块、段落边界识别出来，再决定每个结构单元如何进入索引。
这套“结构识别→分块编排→层次索引”的pipeline，是我目前在横向项目里推进最多的方向。它比任何单一分块算法都更有鲁棒性，因为它把“格式的多样性”在预处理阶段解决掉了，后续的embedding和检索环节只需要面对一个相对规整的结构化文本集合。
写在最后。分块这件事，在RAG整个链路里看起来很小，但它直接决定了检索精度的天花板。我在项目里反复验证过，把embedding模型从通用版换到领域微调版，提升可能只有几个点；而一次合理的分块策略调整，配上metadata和父子分块，却能让端到端的生成质量上一个明显的台阶。
如果你正在做RAG项目，建议拿出一周时间，专门对分块策略做一轮评测和调优。你的数据集不适合用默认参数来跑，这是RAG工程化绕不开的一课。
