我把资料拆成 AI 能找到的小段，但没有使用同一套规则

哈喽，我是阿梦。这个博客，我会持续记录自己怎么把 AI 用进真实的工作，成功的、失败的、返工的，都是我的来时路～

上一篇写完“文章为什么要先被切碎”，接下来还有一个更实际的问题：

到底应该怎么切？

很多知识库工具会先让我填写一个数字：每段 500 字？1000 字？还是再长一点？

但我真的开始改自己的 Knowledge OS 后，发现这个问题问反了。

在决定切多长之前，我应该先问：这是什么资料？

一篇文章、一张表格、一组问答和一份操作步骤，本来就不是同一种东西。

如果全部按照固定字数往下切，操作很省事，资料原来的意思却可能被一起切坏。

普通文章：沿着标题和完整段落切

先说最常见的文章。

我的系统处理普通文章时，会优先识别标题和段落，不会一到固定字数，就直接从句子中间切开。

例如原文是：

方案 A 适合资料数量较少、更新频率不高的情况。如果资料每天都在变化，更适合使用方案 B。

如果刚好从中间切开，知识库可能只留下：

更适合使用方案 B。

AI 确实找到了结论，却没有找到这个结论成立的条件。

所以在我的系统里，普通正文目前以大约 1200 字作为一个参考目标，单段最多不超过约 2200 字。

但这两个数字不是标准答案。

如果一段内容在 1100 字时刚好讲完，我不会为了凑到 1200 字，再把下一个话题硬塞进来。

如果一个完整观点稍微长一点，也不会为了整齐，把原因和结论从中间拆开。

对普通文章来说，我更关注的是：

这一段能不能相对完整地说明一件事。

表格：每一块都要带着表头

表格是固定字数拆分最容易出问题的资料之一。

假设我有这样一张表：

内容类型	当前阶段	建议
新内容	测试期	先观察反馈
已验证内容	放大期	增加投入
旧内容	衰退期	重新评估

如果系统只按照长度切，很可能把第一行表头留在上一段，把下面的数据放进下一段。

AI 最后找到的可能只有：

已验证内容｜放大期｜增加投入

人看到原表时，知道这三项分别对应“内容类型、当前阶段和建议”。

但表头被切掉以后，AI 看到的只是三个并排出现的词。它可能猜对，也可能理解成完全不同的关系。

所以，我给表格使用了另一种规则：

表格可以分成几组数据，但每一组都要重新带上表头。

这样，无论系统找到表格里的哪一块，它都能知道每个数字和每句话分别代表什么。

这里出现了一点重复，但这种重复是有必要的。因为表头不是另一份证据，而是理解这一行数据所需要的说明。

问答资料：问题和答案不能分家

问答资料也不能按照普通段落来切。

例如：

问：会议截图可以直接放进知识库吗？
答：可以保留原图，但需要先通过 OCR 提取文字，再把图片和识别结果关联起来。

如果问题和答案被分开，知识库可能只找到问题，却没有找到答案；也可能只找到答案，却已经不知道它原本回答的是什么问题。

所以在我的系统里，当内容被识别为问答时，会先找到“问题”的起点，再把它后面的回答保留在同一组里。下一道问题出现时，才开始新的小段。

对问答资料来说，最小的完整单位不是一句话，而是：

一个问题，加上它对应的答案。

操作步骤：大步骤和下面的小动作要留在一起

列表和操作手册还有另一种问题。

例如：

第二步：检查资料来源

• 找到原始文件
• 确认创建时间
• 判断是否为最新版本

如果机械地切开，“第二步：检查资料来源”可能在上一段，三个具体动作却被放进下一段。

AI 找到“确认创建时间”时，不一定知道这个动作是在检查资料来源，更不知道它属于整个流程的第几步。

所以处理这类资料时，我会尽量保留大步骤的标题、它下面的小步骤和必要的执行顺序。

这里的重点不是让每个小段长度相同，而是不要让一个动作失去它所属的任务。

目录和导航：能帮助找资料，但不能直接回答问题

还有一类内容，看起来很像知识，其实只能用来带路。

例如章节目录和工具清单，可以帮助系统知道“哪份资料可能相关”，但它们本身并没有回答问题。

如果把目录也当成正式证据，AI 可能根据一个章节标题，自己补出一段听起来合理的解释。

所以在我的 Knowledge OS 里，目录、资源索引和覆盖范围说明可以参与“找资料”，但不能直接参与最后的回答，也不能增加证据数量。

路牌可以告诉 AI 往哪里走，但不能让它把路牌当成答案。

为什么我要给不同资料设计不同切法？

做这些规则，并不是为了让拆分过程显得更复杂。

我真正想解决的是三个问题。

第一，保留资料原来的意思

文章要保住完整观点，表格要保住表头，问答要保住问题，步骤要保住先后关系。

第二，减少看起来相关、实际没用的内容

目录、广告、页面提示和太短的残缺文字，不应该因为包含关键词，就进入正式回答。

被搜到，不代表有资格成为证据。

第三，让 AI 找回可以直接使用的内容

我希望 AI 找到的不是一堆散落的关键词，而是一段包含对象、条件和结论的内容。

这样切，准确性真的提高了吗？

这里我不想直接写一个“准确率 95%”。

因为目前我的项目还没有建立一套足够大的人工标准答案集，不能负责任地给出一个统一的答案准确率。

但这套切法已经完成了几层真实验证。

第一层：检查资料有没有被切坏

项目里的测试会检查长文章拆开后原文有没有丢失、每个小段有没有超过上限、表格是否仍然带着表头、问题和答案有没有放在一起，以及太短的残缺文字有没有被挡在正式证据之外。

这次全库改造完成后，后端的 465 项测试全部通过。

这个结果能证明拆分规则按照预期执行了，但不能直接等同于“AI 回答准确率为多少”。

第二层：重复提问，观察结果是否稳定

我选了两道真实业务问题作为固定测试题，分别连续运行了 5 次。

找回的核心证据保持稳定，需要覆盖的重点没有明显缺失，也没有出现系统判断为不可用的回答。

第三层：检查错误内容有没有混进答案

我的验证不只看“找到了什么”，也看“什么没有被找回来”。

目前已经验证不会直接作为正式证据的内容包括：只有标题、没有正文的伪内容，目录和导航，尚未确认的 OCR 内容，已经被新版本替代的旧资料，以及为了帮助理解而临时补回的相邻文字。

对我来说，这也是准确性的一部分。

知识库不只是要找对，还要能挡住那些不应该进入答案的内容。

写在最后

做完这轮改造后，我对知识库拆分最大的认知变化是：

不是先选一个数字，而是先理解资料原本是怎么表达信息的。

文章、表格、问答、步骤和目录，各自承担的任务不同。

如果用同一把尺子切到底，最后得到的小段可能长度很整齐，意思却已经散了。

我现在的做法也不是最终答案。它只是经过了结构测试、全库迁移和固定问题的重复验证，证明目前可以稳定工作。

但它到底有没有让最终答案变得更准？增加这些规则以后，又付出了多少处理和维护成本？

下一篇，我会继续拆：我怎么验证一套知识库拆分规则是真的变好了，而不是只是变复杂了。