企业知识库系列（01）：为什么 RAG 只是起点

从一个真实的失败开始

一家技术团队花了两个月搭建了一套 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 个月后可能已经过时

知识库不更新，用户问到的答案是过期的。但通知系统更新知识库，本身就是一个工程问题。

RAG 能解决什么，解决不了什么

经典 RAG 的工作原理：

用户问题 → 向量化 → 在向量库里找相似文档块 → 把相似块喂给 LLM → LLM 生成答案

它本质上是语义相关性匹配 + 上下文补充。在以下场景下效果好：

✅ 问题的答案就在某一段文字里（单跳查询）
✅ 文档质量高，分块合理，术语一致
✅ 用户的提问方式和文档的表述方式接近

在以下场景下会失败：

❌ 需要跨多个文档推理才能得出答案（多跳查询）
❌ 问题涉及实体关系（"A 公司和 B 公司有什么合作历史"）
❌ 文档知识库里根本没有答案，但 LLM 会编造一个
❌ 需要综合大量文档做摘要（"所有关于认证的政策是什么"）

前三个失败场景，驱动了 RAG 技术的下一代演进。

技术演进：四代知识库技术

第一代：经典向量 RAG

代表项目：QAnything、LightRAG（向量模式）
核心思路：向量化 → 相似度匹配 → LLM 生成
关键改进：QAnything 的 BCEmbedding + Rerank 两阶段提升了精度；LightRAG 加入了关键词稀疏检索做混合

QAnything 的两阶段检索：
阶段1: 向量检索（Top-K 粗召回）
阶段2: BCEReranker 精排（取 Top-N 精确结果）

适合的场景：文档质量好，查询主要是单跳事实查询，对部署成本敏感。
不适合的场景：复杂推理、关系查询、大规模多跳问题。

第二代：图结构增强 RAG

代表项目：GraphRAG（微软）、HippoRAG
核心思路：在向量索引之外，额外构建实体关系图，通过图遍历回答关系性问题

GraphRAG 的核心机制是社区检测：把文档里的实体（人名、组织、概念）提取出来建成知识图谱，用 Leiden 算法发现自然聚类（社区），针对不同粒度的问题走不同路径：

GraphRAG 查询模式：
  Global search → 社区摘要 → 全局问题（"整体上讲了什么"）
  Local search  → 实体邻域 → 局部问题（"关于 X 的细节是什么"）

HippoRAG 的思路更接近人类记忆机制：仿照海马体的联想记忆原理，把关键概念存储为可互相激活的节点网络，多跳推理时通过节点激活传播而不是重新搜索。

HippoRAG 2 论文（arXiv:2502.14802）显示：在多跳检索基准（MuSiQue、2Wiki、HotpotQA）上显著优于经典 RAG，同时索引资源消耗比 GraphRAG 少。

适合的场景：实体关系密集、多跳推理频繁、需要"全局感知"的问题。
不适合的场景：知识图谱构建成本高，更新慢，对实时性要求高的场景代价大。

第三代：超图 RAG

代表项目：HyperGraphRAG（NeurIPS 2025）
核心思路：传统知识图谱是二元关系（A → B），超图可以表示多元关系（A, B, C 同时参与某个事件/概念）

普通知识图谱：甲 --[参与]--> 项目X、乙 --[参与]--> 项目X
超图：{甲, 乙, 丙} --[协作完成]--> 项目X

超图的优势在于直接编码多元关系，不需要把"三个人一起做了这件事"拆成多个二元关系再重组。对于涉及复杂多方协同、多重约束的查询，超图能给出更完整的上下文。

适合的场景：关系复杂度高，多方参与的事件/决策密集，有较强的学术严谨性需求。
现状：NeurIPS 2025 论文，目前主要是研究阶段，工程落地案例少。

第四代：Agent-native 知识系统

代表项目：GBrain（Garry Tan，YC 现任 CEO 的个人生产系统）
核心思路：知识库不再是被动的检索工具，而是一个持续学习、自我修正、主动综合的"大脑"

GBrain 的设计原则：

综合而不是检索：返回的不是"这里有 10 个相关片段"，而是"这是综合了这些来源之后的答案，以及我目前还不知道什么"。

自我修复的知识图谱：每次写入页面时自动提取实体引用、建立类型化边关系（attended、works_at、invested_in、founded、advises），不需要 LLM 调用。查询"谁在 Acme AI 工作"时通过图遍历直接答，不需要向量搜索。

持续运行的知识代理：66 个定时任务持续运行，负责摄取新内容（会议、邮件、推文）、丰富实体信息、修复引用错误、整合重复记忆。Garry Tan 的原话：

"我睡觉时代理在工作。我醒来时比睡前更聪明——它会这样。"

实测数据（来自 gbrain-evals）：146,646 页文档，P@5 = 49.1%，R@5 = 97.9%，比仅向量 RAG 高 +31.4 点 P@5。

适合的场景：个人/团队知识管理、需要持续学习和自我更新的场景、Agent 的长期记忆层。
局限：需要持续运行的后台进程，基础设施要求高，更适合作为团队级平台而不是轻量工具。

完整技术谱系

企业知识库技术谱系
│
├── 检索增强（RAG 类）
│   ├── 向量检索（Dense Retrieval）
│   │   └── QAnything、LightRAG 向量模式
│   ├── 稀疏+密集混合（BM25 + Dense）
│   │   └── QAnything v2、大多数企业方案
│   └── Rerank 增强
│       └── QAnything BCEReranker
│
├── 图结构增强
│   ├── 实体关系图 + 社区检测
│   │   └── GraphRAG（微软）
│   ├── 神经联想图（仿海马体）
│   │   └── HippoRAG
│   ├── 超图（多元关系）
│   │   └── HyperGraphRAG（NeurIPS 2025）
│   └── 轻量图 + 向量混合
│       └── LightRAG（graph 模式）
│
├── 多模态知识
│   └── RAG-Anything（文本+图像+表格+音频+视频）
│
└── Agent-native 知识
    └── GBrain（合成、图遍历、差距分析、持续学习）

这个系列要做什么

理解了技术演进路线，选型问题就变成了：你的业务场景在哪一代技术的能力范围内？

这个系列不是 Survey 论文，是工程实测：

• 先建好统一测试集（已完成，见 系列 00）
• 对每个主要方案实测，同一套 89 题，报告 RAGAS 四指标 + 边界拒答率 + P90 延迟
• 最后做横向对比和选型决策框架

Part 1 实测计划（7 篇）：

Part 2 方法论（5 篇）：知识蒸馏、选型、数据治理、部署架构、评测调优。
Part 3 案例（按进度）：真实项目的落地过程。

一个提前说清楚的期望校准：

这个系列不会告诉你"XXX 是最好的 RAG 框架"，因为"最好"依赖于你的场景、数据质量、团队运维能力。这个系列要给你的是：看懂每种方案在哪里强、在哪里弱，以及你的场景属于哪种。

如果这个系列对你有帮助，欢迎关注我的个人主页 dongqi.dev，持续更新 LLM 工程实践内容。

在 PrimeSkills，我们帮助工程团队完成企业知识库的选型和落地，从评测体系到生产部署。如果你正在为团队搭建知识库系统，欢迎联系我们。

primeskills.dev