2.3 文档解析与切片：一份 50 页产品手册怎么喂给 AI

原文都集中到 COS 之后，我以为最麻烦的活儿干完了，结果一动手才发现真正的硬茬在后面：平台的知识库节点没办法直接读懂一份 50 页的 PDF，它需要的是被切成小段的、语义完整的文本块。这一节讲我怎么理解切片这件事，以及那份 50 页手册最后是怎么被喂进 AI 的。大模型本身的能力边界与用法，可以看我写的DeepSeek 工具链，这里默认大家都清楚大模型没有长期记忆、只能按上下文窗口办事。

先把 RAG 说人话

很多文章讲 RAG 都喜欢堆术语，其实它的逻辑特别像开卷考试：

第一步，切片。把所有复习资料撕成一小段一小段，每段是一个独立的知识点。第二步，向量化。给每段文字算一串数字指纹，内容相近的段落指纹也相近。第三步，检索。用户提问时，把问题也算成指纹，去所有指纹里找最相近的前 k 个段落，行话叫 top-k。第四步，拼提示词。把找到的几段原文和用户问题一起塞给模型。第五步，生成。模型看着这些段落组织答案。

为什么非得绕这一圈，不直接把整份手册塞给模型？上下文窗口装不下是一方面，更关键的是准确率：模型在一大堆无关内容里找答案，很容易被干扰项带偏，注意力比想象的脆弱。只把最相关的几段喂进去，回答质量和稳定性都高得多，token 花费也更省。这个绕圈的收益是用准确率换来的。

再打个比方帮助理解：RAG 之于大模型，就像老工程师带徒弟。徒弟脑子聪明（模型能力强），但没见过你们公司的业务（缺领域知识）。老工程师不可能把十年经验一小时灌给他，只能把相关的图纸和操作手册挑出来递给他（检索拼提示词），让他照着干活。知识库就是那叠被挑出来的资料，而切片决定了你递过去的是完整的一页纸，还是被撕碎的半页。

整个流程里，切片是唯一完全由我们控制的环节。切得太大，一段里混了好几个话题，检索出来一半是废话，还会挤占宝贵的上下文窗口；切得太小，一句话被劈成两半，检索到了上下文也接不上。所以切片质量直接决定了后面所有环节的上限，值得花一整天认真调。我们项目后来遇到的四次回答事故，有三次根源都在切片上。

这也是很多人开始做 RAG 时不理解的一点：明明检索引擎、向量化都是平台自动完成的，为什么效果还是时好时坏？答案就在切片这一步——自动化只保证文档被切开了，不保证切得对。最终效果的天花板，就藏在这些看似自动的环节背后。

这块再补一个容易误解的点：很多人以为检索就是把用户的问题和答案做匹配，其实更像是在找话题相近的段落。用户问能不能开发票，知识库里不一定有这句原话，但有发票开具流程这一段。切得好的块能覆盖多种问法，切得不好的块换个说法就检索不到——这也是为什么要用工单里用户的原话来做切片语料，她们的表达方式比我们写文档的方式更接近真实提问。

三种切片策略怎么选

我在测试环境里把三种主流策略都试了一遍，记录如下：

结论我们也没有二选一，而是混着用：FAQ 和工单本来就是短条目，几乎不用切；帮助页按段落切；50 页手册用重叠窗口切。这就是碎片化知识库和能用之间的分水岭。

有个判断技巧可以分享：先看文档的修改频率。经常更新的内容（比如 FAQ）适合能想改就改的小颗粒度策略；相对稳定的内容（比如手册）适合一次性调好的重叠窗口。把维护成本纳入选型考量，能让策略更长久地跑下去，而不是下个月就受不了推翻重来。

50 页手册的切片实战

那份手册的完整处理记录是这样的。先按章拆成二十个小文件，每个文件是一个主题，比如计费规则、账号管理、数据导出，这一步在 2.1 篇盘点时已经做过。接下来对每个章节文件单独做切片，参数我前后试了三组：

最终落地的参数是每块约 400 字、相邻块重叠 80 字。为什么是这两个数：400 字是我们一轮轮试出来的临界点，再小就开始出现半句话，再大就开始一段混两题；80 字的重叠专门用来对付跨段引用——手册里常有此外还需满足上一条规则这类表述，没有重叠的话这句话根本捞不到上一条的内容，重叠也不宜太大，超过四分之一就出现明显冗余。另外还有两条补充规则：块尽量在句号处截断而不是硬切字数，以及每个块前面自动拼接所属章节的标题。手册里承上启下的指代词太多，加了章节标题之后，单独看任何一块都知道它在讲哪章哪节。

块大小的选择还有个隐藏考量：检索的 top-k 数量。一块 400 字，取 5 块就是两千字塞进提示词，这个量级大多数模型接得住，也不会稀释注意力。如果你选了 800 字的大块，同样取 5 块就是四千字，模型在长上下文里找答案反而更容易漏。切片大小和检索数量是跷跷板的两头，调参数时要一起想。切完之后平台会自动完成向量化和建索引，我们要做的就是观察每个块的内容是否说得通。

不同文档要区别对待

手册搞定了不代表所有文档都能一套参数走天下。我们知识库里四种来源最终用的是四套处理方式，区别对待比统一参数效果好得多：

这里核心的判断标准是文档本身的结构强度：结构越是天然完整的（比如问答对），越要尊重原结构不要硬切；结构越是松散的（比如长篇叙述），越需要重叠窗口来兜住上下文。很多教程一上来就告诉你固定 500 字加 50 字重叠，那是把所有文档当成同一种文档，实际项目里一定要分开试。这份分类处理的经验，后来成了我们团队迭代知识库时的标准动作，每接进一类新文档，先小批量试参数再全量放开。

说个真事，我们最开始犯的正是这个错误。图省事全库统一用了固定 400 字参数，结果 FAQ 的标准答案被从中间切开，问退款的检索到半句退款说明加半句发票流程，回答自然驴唇不对马嘴。改成按类型分参数之后，这类错误当场就消失了。参数不怕多，怕的是图统一。

切片质量自检表

切完不算完，我抽了二十个块逐个人工看，标准就下面这张表。这套自检后来每周迭代知识库时都会跑一遍，成本不高，但能拦住大部分低级问题。

这里还有个偷懒但有效的办法：把自己当成用户，随机挑十块只读块本身，问自己这块内容能不能回答一个具体问题。读着通顺、信息完整的块，检索回来大概率也能用；读着像电报或者需要脑补上下文的，就是参数没调到位。另外强烈建议把切片参数和每轮测试结论一起记在文件里，我当时换了个参数三天后已经不记得哪版对应什么效果了，只能重跑一遍。

这一套走完，二十个章节文件切出了约三百个块，加上 FAQ、工单和帮助页，知识库总规模不大，但胜在干净。这一步是在为 AI 准备教材，教材拆得好，后面提示词调试才能省力气，这一点在 3.2 篇会接着讲。

回过头看，整个切片环节最值得花的精力其实是看人工抽检那一小时。自动切完很容易自我感觉良好，只有逐块读过去才会发现承上启下的指代、半截的表格、混进的页眉这些细碎毛病。切完到平台里把检索返回的结果点开看几眼，也能快速暴露问题——如果命中段落读起来像电报，那参数就得调。换个角度想，切片这一步省下的时间，后面提示词调试都会加倍还回来，这是我在这个项目里验证过三次的结论。切片和解析脚本本身，有不少是我让 AI 编程工具帮我写的，完整流程见我另一本Claude Code 指南。

延伸阅读

• 大模型的能力边界与工具选型，见DeepSeek 工具链。
• 用 AI 编程工具批量写解析脚本的流程，见Claude Code 指南。
• 切完怎么验证知识库质量，见下一节知识库质量评估。