上一篇讲了 RAG 的整体架构和适用边界。从这一篇开始拆离线链路，第一环就是切分。这件事听起来简单——按长度切开不就行了——但它其实是整条链路里最容易被低估的一步。切错了，后面所有环节都白做：再好的向量模型、再准的重排，都救不回一个本来就切坏的块。

一、为什么切分这么关键

先理清一件事：切分决定了检索的基本单位。

检索时，用户的问题会去和每一个块比相似度。也就是说，检索只能找到"块"，不能找到"块里的一句话"。这带来一个直接后果：

• 如果块切得太大，一个块里混着五六个话题。用户问其中一个小问题，这个块整体被召回，然后一大段无关内容被塞进上下文——噪音稀释了信号，模型容易被带偏。
• 如果块切得太小，一个完整的论述被拆成七八个碎片。任何单个碎片都缺少完整含义，向量表示也就模糊了——召回不准，或者召回了但信息不足以回答。

所以切分是在两个失败模式之间找平衡：太大引噪音，太小丢上下文。 这个平衡点取决于你的资料类型和提问方式，没有通用答案。

还有一点常被忽略：切分是唯一"一旦入库就很难反悔"的环节。 你改提示词、换模型、调重排参数，都是线上即时生效的。但切分策略变了，意味着全部资料要重新切、重新向量化、重新入库。资料量大时这是一次完整重建。所以这件事值得在动手之前想清楚，而不是先随便切一版上线再说。

二、三种切分策略

固定长度切分

最简单的做法：按字符数或 token 数切，每块 500 字，切到 500 就断开。

优点是快、可控、不依赖任何解析能力。缺点是完全不理解内容，会把一句话拦腰截断，也可能把一个完整章节切散。

它适合什么场景？

• 格式混乱、没有结构可依赖的文本，比如 OCR 出来的结果、聊天记录导出、用户自由填写的备注；
• 作为兜底方案，在结构化切分失败时的默认路径。

但如果你手上的资料是有标题层级、有段落的文档，固定长度切分就是明显浪费——结构本身是最好的切分信号，你不用它，等于把免费的信息扔了。

按结构切分

利用文档自带的层级：Markdown 的 # 标题、Word 的标题样式、HTML 的标签层级、代码的函数边界。

核心思路是先按结构切成大块，再在大块内部按长度细分。

为什么这样更准？因为同一个标题下的内容，主题天然相关。按标题切出来的块，语义是聚合的，向量表示也更集中。检索时命中的概率明显更高。

这也是为什么 Markdown、Confluence、语雀这类有明确层级的知识库，是 RAG 最容易做好的资料类型——层级就是现成的切分依据。

一个务实的处理方式：

• 把标题路径拼进块的元数据（比如"退款政策 > 时效说明 > 特殊情况"）；
• 块本身不需要塞进完整路径，但检索时可以拿路径做辅助匹配；
• 层级很深的文档（四级以上标题），考虑把中间层的小节合并进父块，避免切出只有两行字的碎块。

按语义切分

不看结构也不看长度，而是看语义是否发生转折：把相邻句子做向量化，计算相似度，相似度骤降的地方就是切分点。

这听起来最"智能"，但要清楚它的代价：

• 要额外做大量向量计算（每一对相邻句子都要比一次），建库时间和成本都会上去；
• 结果不稳定。同一份文档，换个阈值就切出完全不同的块，调参过程比较别扭；
• 不保证切在人类认为合理的地方。语义转折检测不认章节标题，可能会把"前言"和"第一章"的过渡处当成一个切点。

务实的顺序是：先用好结构切分，只有在资料本身没有结构（比如长篇访谈、会议记录）时才考虑语义切分。 多数场景下，结构 + 长度兜底已经够用，而语义切分带来的复杂度往往抵不上收益。

三、块大小：一个必须自己试的数

块大小（chunk size）没有标准答案，但有几个可以判断的线索。

看你的提问粒度。 如果用户的问题通常很短很具体（"退款要几天到账"），块应该偏小，让检索更精准；如果问题通常是开放式的（"帮我总结一下这份政策"），块可以偏大，保证信息完整。

看你的资料密度。 技术文档、API 说明这类信息密集的文本，块要小一些，因为一小段就包含完整信息；叙事性内容、访谈记录，块可以大一些。

看上下文预算。 这是常被忽略的一条：如果你一次召回 5 个块，每块 1000 token，那就是 5000 token 的输入。第九篇算过输入成本会累积——块大小直接决定了你的检索成本。块越大，虽然召回数量可能少，但单次输入涨得更快。

一个可行的起步方式：

• 先定一个中间值，比如 300~500 token；
• 准备 20 个左右真实问题，看召回结果里有没有"缺了关键那句话"或"混了一堆无关内容"的情况；
• 往两个方向各调一档（比如 200 和 800），对比召回质量。

关键在于用真实问题去验证，而不是凭感觉。这一步的成本很低，但能避免你在错误的分块上继续叠加工夫。

四、重叠：收益与代价都要算

重叠（overlap）指的是相邻块之间留一部分重复内容，比如每块 500 字、相邻块重叠 50 字。

它解决的问题是"边界切断"。 如果一句话正好落在两个块的分界线上，两个块各拿到半句，谁都读不通。有了重叠，这句话至少在一个块里是完整的。

代价有两点：

• 存储和计算成本上升。重叠 10% 意味着总量多 10%，向量化也多 10%。
• 召回结果可能重复。同一个句子在相邻两个块里，可能两个块同时被召回，白占上下文位置。

所以重叠要按需设置：

• 如果你的切分已经落在段落边界（结构切分），重叠可以很小甚至不要——因为段落边界本来就是天然的语义分界；
• 如果用的是固定长度切分，重叠比较必要，因为切点完全随机；
• 重叠比例一般 10%~20% 就够，超过这个数收益增长很慢，成本却线性上升。

顺带一个配套动作：召回后做一次去重。 如果两个块的相似度极高或者内容大段重叠，只保留一个。这个处理很便宜，能省下不小的上下文开销。

五、几个中文内容特有的坑

标点与全角。 中文的句号、逗号、顿号都是全角的。如果你的切分逻辑按英文字符判断句子边界，中文文本会被当成"一个超长句子"处理——固定长度切分尚可，语义切分和按句切分就会失效。要显式处理全角标点。

标题识别。 中文文档里，"一、""（一）""1.1"这类编号经常代替 Markdown 标题。如果你的解析器只认 #，这些文档会被当成无结构文本，白白浪费了现成的层级。

表格。 表格被切成文本后往往彻底散架——表头在一行、数据在很远的地方，模型根本对不上哪列是哪列。稳妥的做法是把表格转成"键: 值"的列表形式再入库，比如把一行记录转成"产品A | 价格 100 | 库存 20"，而不是保留原样的竖线和空格。

代码块。 代码里的空行、缩进、注释都可能被当成切分点。如果资料含代码，最好让解析器识别围栏标记，把整个代码块当成一个不可分割的单元——不要在一个函数中间切断它。

页眉页脚。 PDF 解析后经常混入页码、公司名、章节名等重复内容。这些文字会在每个块里都出现，导致不同块之间的相似度被人为拉高，检索时互相干扰。入库前要清理掉。

六、元数据必须跟块一起存

这是很多人漏掉的一步，但它的作用不小。

每个块除了文本内容，应该同时保存：

• 来源：哪份文档、哪一页、哪个章节。这直接支撑"答案标出处"（第十二篇讲过，这是用户发现检索错误的唯一机制）。
• 时间：文档的更新日期。政策类内容尤其重要——检索到一份过期文件比检索不到更危险，因为模型会自信地按旧规则回答。
• 标题路径：比如"退款政策 > 时效说明"。它既可以作为辅助检索字段，也可以直接拼进上下文帮模型定位。
• 权限标签。这一条在多人组织里是硬性要求：检索必须在权限过滤之后进行，否则就会出现"员工 A 通过 AI 问答读到了只有 B 能看的文档"。这类问题在 RAG 里特别容易被忽略，因为检索层看起来只是"查资料"，不像一个访问控制点。

前三个是功能性的，第四个是安全性的。权限标签建议在第一版就加上，因为它涉及全部资料重新标注，事后补比事后重新切分还麻烦。

七、怎么判断切得好不好

切分质量最终要落到检索效果上，所以验证方式就是看检索结果：

• 准备 20 个左右的真实问题，每个问题都预先标好"答案应该来自哪份文档的哪一段"；
• 用当前切分方案检索，看正确答案所在的块有没有被召回（召回率）；
• 同时看召回了几个块、其中几个是噪音（准确率）。

这带来一个很实际的判断：

• 答案所在块没被召回 → 块切得太大（答案被稀释了）或者切得太碎（信息不完整）；
• 答案块召回了，但混了一堆无关块 → 块太大，或者重叠太多导致重复召回；
• 同一份文档的不同块经常互相竞争 → 切分粒度太细，或者重叠比例过高。

这就是为什么第十二篇建议"先把离线链路做对，再优化在线检索"。如果切分本身有问题，你在重排、阈值、查询改写上做的一切调整，都是在给一个坏基础打补丁。 先看召回列表，比调参数省事得多。

一个朴素的验证技巧：把某个问题的召回结果原样打印出来，从头读一遍。 如果那些块连你自己读着都觉得"这跟问题有关系吗"，那不用算指标也能确定切分需要改。

八、小结与检查清单

• 定位：切分决定检索的基本单位，是唯一"入库后难以反悔"的环节，动手前想清楚
• 策略优先级：结构切分（用现成层级）→ 长度兜底 → 语义切分（只用于无结构的长篇）
• 块大小：先取 300~500 token，用 20 个真实问题往两个方向各调一档验证
• 重叠：结构切分可很小甚至不要，固定长度切分需要；比例 10%~20%，召回后要去重
• 中文坑：全角标点、中文编号标题、表格转键值、代码块不可切、清理页眉页脚
• 元数据：来源、时间、标题路径、权限标签（权限标签第一版就要加）
• 验证：看召回率，而不是感觉；把召回结果读一遍比算指标更快定位问题

一道判断标准：如果你说不出当前每个块大致多长、按什么边界切的，那切分就是失控的——而你后面所有检索效果的调优，都会建立在这个未知之上。

下一篇

块切好了，下一个问题是怎么把它变成可以被检索的向量。这里有一堆实际取舍：向量维度选多高、中文效果差多少、要不要用同一个模型做查询和文档、换了模型是不是要全部重建。下一篇讲 Embedding 选型，重点是那些选错之后代价很大的决定。

本文是「用 Java 接入大模型」系列第十三篇。上一篇讲了 RAG 的全景与适用边界，建议按顺序看。文中块大小与重叠比例为实践起点，真实取值请按你的资料类型与提问方式自行验证。