这是什么

我们注意到掘金一篇技术长文，拆解了 RAG（让 AI 检索自有文档来回答问题的技术）流水线里「最容易被忽视、却决定检索质量」的一环——文档切割。LangChain 这类工具箱里塞了 180 多种加载器（Loader，负责把 Word、PDF、网页读进来），但真正决定 AI 答得好不好的，是把这些文档切分成小块（chunk）时的策略：切得太大，检索捞不到关键句；切得太碎，语义断裂；切错位置，整段上下文丢失。

一句话收束：AI 读不懂你公司文档，锅往往不在大模型，在切菜刀。

行业怎么看

主流共识是「语义优先，大小兜底」——优先按段落、句子等自然边界切，再用字符数兜底防止单块过长。这正是 LangChain 默认的 RecursiveCharacterTextSplitter（递归字符分割器）的设计思路。但也有反对和补充的声音，值得关心：

  • 结构派：对合同、产品手册这类结构化文档，按字符数切会破坏条款完整性，应该按章节、表格、列表等结构单元切，而不是一刀切到底。
  • 务实派：中小企业没必要追求完美切割，先用默认策略上线，再根据 bad case（AI 答错的样本）反推调参，比从一开始就死磕更划算。

另外值得警惕：切割只是 RAG 的一环。上游要不要剔除导航和广告等噪音、下游用什么向量化模型、纯向量检索还是混合检索，每个环节都会放大或抵消切割阶段的问题。把这步单独当胜负手看，是把复杂问题过度简化。

对普通人的影响

  • 对企业 IT：如果公司正打算上 AI 知识库，验收标准不该只是「能不能跑通」，而是「能不能把我们的合同和手册答对」——这取决于切分策略，多数采购方目前没意识到这一点。
  • 对个人职场：以后让 AI 总结一本书、读一摞合同，与其一次扔一个大文件，不如自己先按主题分段喂，AI 的回答质量会肉眼可见地变好。
  • 对消费市场：市面上所有「AI 助手读不懂我的文档」的吐槽，背后多半是切分或加载环节出问题，而不是 AI 本身不行——这件事行业内知道的人还不多，是普通用户的认知盲区。