文档切片怎么做?切了 3 种方法才搞明白

我搜“李四提的需求”，三层漏斗全跑完了，精排也排了，top-1 是一段 800 字的内容。

我读完前 200 字，发现是讲张三的。李四的部分在第 600 字之后。

不是搜的问题。是我切文档的时候，把完整的意思切碎了。

就像切菜——你买了好食材，用了好锅，火候也到位了，但菜切得大小不一，炒出来有的生有的糊。

01我手动切了 2 小时

上个月我手上有 11 个工作文档：2 个 50 页的方案文档，5 个 30 页的说明文件，4 个 20 页的会议记录。加起来 200 多页。

我第一次试着手动切——开 Word，Ctrl+C 一段，Ctrl+V 进数据库。2 小时切了 50 块。

按这速度，切完 422 块我要干 17 小时。

所以问题是：怎么自动切？

02最简单粗暴：按字数切

最天真的想法：每 500 字切一块。

200 页的文档 → 800 块。

我用了 1 次，发现问题大了。比如一段：

按 500 字切，可能被切成两段：

· 段 1：“供应商合同约定：乙方需在 2026 年 3 月前完成物料交”

· 段 2：“付，甲方负责验收。”

“交付”被腰斩了——AI 搜“交付”找不到完整信息。

按字数切有三个问题：标题被切到中间，一个完整概念被腰斩，AI 检索时找不到完整意思。

03真正的解法：按“意思”切

后来我想明白一件事：切菜不是切得越小越好，是每一刀都落在该落的地方。

按“意思”切，不按“长度”切。一段话讲完一个完整的意思，就切一刀。讲到另一个意思，再切一刀。

具体是三个策略叠加：

50 行代码搞定。核心逻辑是：段落切分 → 标题分组 → 合并到每块不超过 800 字 → 加 100 字重叠。

04实测对比

同一个 50 页文档，两种切法对比：

naive 切 100 块 vs smart 切 38 块：

· 存储：100 × 1024 维向量 ≈ 400KB；38 块 ≈ 152KB

· 检索速度：100 块扫一遍 50ms；38 块扫一遍 20ms

· 检索准确度：naive 切断“交付”；smart 完整

smart 切 4 项全胜。

我 11 个文档，用 smart 切法，最终切出 422 块。方案文档约 160 块，说明文件约 200 块，会议记录约 60 块。跟预期差不多。

05切文档的 3 个反直觉

06这件事的本质

后来我意识到，切片这件事的本质不是“怎么切”，是“切决定了搜的上限”。

如果你的切片是 800 字一大块，那搜索最好也只能找到这 800 字。AI 拿到这一块，还得自己从里面找重点。切片没做好的工作，变成了搜索的负担。

如果你的切片是每块只讲一个意思，那搜索找到的就是那个意思。AI 拿到直接能用，不需要再做一次“从 800 字里找 200 字”的工作。

我优化了搜索、优化了精排，还是找不到对的东西——因为问题不在搜索本身。

07这件事不止出现在文档里

后来我发现，“切得不对导致下游出问题”这件事，不止出现在文档切片里。

这些事情看起来不一样，但本质是同一个：上游的“切分”方式，决定了下游的“使用”效率。

08什么情况下不适用

按“意思”切有一个前提：你得能判断“一个意思”在哪里结束。

如果内容是高度结构化的（比如表格、代码），按“意思”切反而容易切错——结构化内容有自己的边界，按字段切更准。

还有一种情况：如果你的内容本来就是短句、短段落，那“按意思切”和“按段落切”区别不大。这时候不用纠结，怎么切都行。

所以，按“意思”切适合的是：内容是自然语言、段落长度不均匀、语义边界不明显的场景。

09切完怎么“翻译”入库

切完之后，还要“翻译”成向量存进数据库。

流程就三步：切好的每一块 → 调模型翻译成 1024 个数字 → 存进向量库。一行 collection.add() 搞定。

最爽的是加新文档的时候。之前手动切 2 小时，现在跑一次脚本 30 秒。新文档的几十块自动进柜子。

这一项升级，值 100 倍。

10一个反直觉的发现

我以为切文档的难点是“怎么切”——段落、句子、字数、智能算法……但实测发现：

我 11 个文档里，2 个旧版方案文档切了也没人搜——因为业务早变了。切之前应该先想：这个文档未来会被搜几次？没人搜就别切，浪费存储。

切文档是体力活，“决定切哪个”才是脑力活。