引子

把 PDF 制度、Wiki、邮件归档全部 embedding 进 RAG 系统后，业务部门用了一周回来反馈： "答案看起来对，细节都不对"。我们复盘了 4 个项目的 RAG 准确率数据，得出的结论是 ——问题不在 embedding 模型，而在企业知识本身的断层。

断层 1：切片粒度不匹配业务粒度

文档切片用 token 长度分块，业务问题却以"任务"为单位。一个"如何提报年终预算" 跨 3 份文档：制度、流程图、表格模板。RAG 召回的 3 个 chunk 来自 3 份文档，但 chunk 之间没有上下文链接——LLM 无法重组成完整答案。

做法：按业务任务建知识图谱，chunk 之上加"任务-文档"映射。

断层 2、3、4（占位）

  • 部门术语演化：同一个词在 IT 和业务部分别意指不同
  • 时间维度断层：旧规章和新规章并存，RAG 不知道哪个生效
  • 隐性知识缺失：流程之外的"惯例"从来没写进文档

（详细案例与方法论由后续内容运营展开）

写在最后

RAG 不是把文档塞进向量库就行。先治理知识，再做 RAG——这才是企业落地 LLM 的正确顺序。