文档切片

它是什么

文档切片是把长文档拆成可独立索引、可独立取回、且取回来能看懂的小单元。切分依据可以是标题层级、段落、句子或语义边界。

它不是一个预处理的小步骤，而是决定检索上限的一环：向量是一块一块生成的，检索是一块一块取回的，模型看到的也是一块一块拼起来的片段。所以切片切得不对，后面无论换多好的嵌入模型或重排器，都救不回来。

顺带一件事：每一块除了文本，还要带上元数据——来自哪份文件、哪一章、什么权限、什么时候生效。缺了来源，你无法给出可核对的引用；缺了权限，你无法做到「不同的人召回到不同的片段」。

为什么需要它

两端都有硬约束，切片是中间那个平衡点。

往大了说：整份文档变成一个向量，语义会被稀释成平均值。 一份 50 页的制度压成一个向量，它在向量空间里代表的是「制度这件事」的笼统印象，不是「住宿上限是多少」。

往小了说：切碎会丢条件。 一条规则常常带着「除……外」「仅适用于……」「自 2026 年起」这类限定；把限定切到另一块里，检索命中规则正文时，模型看到的就是一条没有例外的错规则。

所以切片质量的真正判据不是「长度均匀」，而是每一块单独拿出来读，是否已经是完整而正确的意思。

它如何工作

典型流程是：解析文档结构 → 按边界与长度规则切块 → 相邻块适度重叠 → 给每块挂上标题与父级路径 → 逐块生成嵌入 → 写入索引。

四个机制细节值得知道：

• 解析器先于规则。 PDF、网页、Markdown 的结构信息差别很大；解析阶段丢了标题层级，后面就只剩「按字数切」这一条路。
• 重叠是为了不让边界切断语义。 相邻块共享一小段，代价是索引冗余、召回时可能出现近似重复的块——这是要主动权衡的，不是默认越多越好。
• 标题与父级路径要随块保存。 一块正文单独拿去检索时会失去上下文；把「第三章 > 报销标准」一起带上，嵌入和生成才都拿得到正确语境。
• 切片策略必须用评测来定。 块大小、重叠长度、是否按标题切——这三个选择没有先验最优值，只能拿你自己的问题集去比。

必须澄清的误会

切片 ≠ 预处理的杂活。 这是最需要纠正的定位。团队常常把精力花在「换哪个嵌入模型」上，而实际收益往往来自「按标题切」这一个改动。原因很简单：嵌入模型决定「像不像」，切片决定「有没有得比」。 一块里如果混了三件事，再好的模型也只能给你一个模糊的平均。

切片 ↔ 上下文窗口是乘出来的，不是各自独立的。 窗口能装 10 块，而每块 800 Token，和每块 300 Token，能带上的证据量差一倍多。改了切片，窗口预算和成本都会跟着变——上线前要一起算。

切片 ↔ Top-K 也是一对。 切得碎 → 需要更大的 K 才凑得齐答案 → 带进来的噪声更多 → 你开始怀疑重排。很多「Top-K 调不好」的根因在切片，先回去看块是不是切散了，比在 K 上反复试更有效。

块大小没有普适答案。 法律条款、技术文档、FAQ 的最优切法完全不一样；任何「按 512 Token 切」的建议都只是起点，不是结论。

真实例子

一份差旅报销制度，按结构切成五块：适用范围、额度、所需凭证、审批流程、例外。

用户问「住宿一晚最多能报多少」，系统只需要取回「额度」那一块，以及它的适用条件——干净、聚焦、答案完整。

如果改成按固定 500 字硬切，最可能发生的是：「额度」这一块在末尾写「以上标准不适用于境外差旅」，而「境外例外」被切进了下一块。检索命中了额度块，模型于是给出了一个看起来很确定、但漏掉前置条件的答案——这个失败模式最危险的地方在于它答得条条是道，你不会想到去查它漏了哪一句。

什么时候适合与不适合

适合：说明书、制度、知识库、产品文档这类有清晰结构的长文本——按标题层级切，收益最大。

不适合硬切的对象：表格（一行一行的数据被从中间切断）、代码（函数被切开）、跨页论证（前提与结论分家）。这些需要专门的解析策略——按行、按函数、按小节，而不是按字符数。

一个实用的判断顺序：先看结构能不能用，再定长度。 如果一份文档有稳定的标题层级，就先按标题切、再处理过长的小节；反过来先定 512、再指望它自动对齐结构，几乎一定会踩到边界。

还要留一笔运维账：切片策略一改，整个索引必须重建。 和换嵌入模型一样，这是全量重跑的成本——所以上线前值得花一天把切片调对，而不是上线后每周重建一次。

亲自试一下

选一篇你真正关心的、有三级标题的文档，切两个版本：一版按固定长度，一版按标题结构。

然后拿同样 5 个问题，逐条检查召回的那一块是否包含完整答案及其适用条件——注意是「包含条件」，不只是「包含答案词」。

全程约 25 分钟。观察点是哪一种切法把「例外条款」和它修饰的那条规则切散了。 一旦你亲眼看到那个条件掉到另一块里，你就再也不会把切片当成预处理杂活了。

顺手记下两种切法下各题召回的块数——这个数字直接换算成 Token 成本和窗口预算。

接下来学什么

文档切片是第 3 站 给知识 · 怎么让它知道你家的资料 的第一环——整条链路是从「切好一块」开始的。

顺着这条链路的顺序走：切片之后是 嵌入（每一块怎么变成可比较的向量）与 向量数据库（这些向量存在哪、怎么查），然后是 检索、重排 与 Top-K（怎么从一堆候选里挑出真正要用的那几块）。

想理解「一次能带几块」这条边界，读 上下文窗口；想知道切片策略改完到底有没有变好，读 评测——这也是第 7 站 给判断 的第一个动作。

来源与修订

「让每一个知识单元自包含、可独立理解」这一写作与切分原则，参考 AWS 的 Writing best practices to optimize RAG applications 指南；切片的定义与常见策略（固定长度、按结构、重叠窗口等）参考 DigitalOcean 的 Data Services Chunking Strategies 文档（均访问于 2026-09-19）。

一处边界要说明：本文刻意不给任何「最佳块大小」的数字。 最优值依赖文档类型、嵌入模型与问题分布，只能由评测确定；把一个数字写进词条，等于制造一个会被盲目套用的错误答案。

修订日期 2026-09-19：本条由生成模板改为决策页——补「必须澄清的误会」一节（对上下文窗口、对 Top-K），把「四个机制细节」与「例题里条件被切散」写实，去掉生成期的引用标记，补 boundaries 与 minAction。