从一个真实的失败开始一家技术团队花了两个月搭建了一套 RAG 知识库系统：文档 PDF 解析、分块、向量化、存入 Pinecone、接 GPT-4 生成答案。上线后 Recall@5 = 0.87，看起来不错。然后来了第一个真实用户问题：“上次我们评估过 Acme 供应商，当时的结论是什么，跟现在的备选方案比有什么差异？”RAG 系统完全答不上来。不是因为技术不行，而是因为这个问题在任何单一文档里都找不到完整答案——它需要找到当时的评估报告、理解结论、和现在的文档做比较推理。向量相似度匹配的是局部的语义相关性，不是跨文档的推理链。这个失败不是偶然的。它暴露了企业知识库和普通文档搜索之间的本质差距。企业知识库面临的四类真实挑战在看技术方案之前，先把问题说清楚。企业知识库的挑战大多数不是检索算法的问题，而是数据层面的问题。挑战一：数据质量差企业文档的真实状态：PDF 是扫描件，OCR 错误率 5-15%Word 文档里嵌着无法解析的表格和图表同一个概念在不同部门的文档里叫三种名字版本混乱，最新版本不在最显眼的地方这些问题在任何 RAG 框架里都是前置条件。向量化一个 OCR 错误的文档，检索结果会系统性偏差。挑战二：知识碎片化企业知识分散在多个孤岛：Confluence 里有设计文档飞书里有会议记录邮件里有关键决策代码注释里有实现细节口头传授的经验根本没有文档RAG 能索引文档，但无法把这些碎片自动组织成有结构的知识。"上次那个需求怎么做的"这类问题，在没有显式关联的情况下 RAG 大概率答不全。挑战三：多模态混杂企业文档远不是纯文本：技术架构图（PNG/SVG）数据分析报告（含图表、Excel）产品截图（说明操作步骤）视频会议录音经典 RAG 只索引文本，这些内容对它来说是黑盒。挑战四：知识老化文档的半衰期：API 文档：发版即过期流程规范：每次组织调整都会失效技术调研报告：6 个