博客从纯向量检索到 GraphRAG，拆解三种企业知识库 AI 架构的适用场景与真实月成本，附从 62% 到 91% 准确率的升级路径及中文 RAG 踩坑实录。
标准 RAG 的工作流很简单：文档切块 → Embedding 向量化 → 用户提问时做向量相似度检索 → 把 Top-K 文本块喂给 LLM 生成答案。这套流程对"指向明确的事实性问题"效果不错——"Kubernetes liveness probe 支持哪些配置参数？""某产品 2025 年 Q4 的毛利率是多少？"——因为答案就集中在 1-2 个文本块里。
但企业知识库的真实场景远不止于此。决策者问的是："过去一年，导致项目延期的根本原因有哪些共性？""三个事业部的技术栈演进路径有什么分歧？"这些问题散落在几十甚至上百份文档里，传统向量检索只能给你"局部最优"的几个片段，没法把信息串联成完整的推理链条。我们在《RAG 系统工程化：2026 企业级检索增强生成从原型到生产落地实战》中详细拆解过这个"局部最优陷阱"的根因。
微软在 2024 年 7 月开源的 GraphRAG（GitHub: microsoft/graphrag，目前已超 31K Star）正是冲着这个短板来的。它的核心思路很直接：检索之前，先用 LLM 把整个文档集合变成一张知识图谱，然后在图谱上做遍历和推理[1]。到 2026 年，这已成为企业 RAG 架构演进的主线。
实际落地中，路线不止"向量 vs 图谱"两条。我们把当前企业可选的方案归为三类：
| 架构类型 | 核心技术 | 适合的问题 | 不适合的问题 | 典型成本（月） |
|---|---|---|---|---|
| 纯向量检索 | Embedding + Pinecone / Milvus / Qdrant | 事实查询、政策条款、FAQ 匹配 | 跨文档推理、多跳关系、趋势分析 | ¥3,000–8,000 |
| GraphRAG | LLM 实体提取 + Neo4j / NebulaGraph + 社区摘要 | 跨文档因果链、组织关系梳理、技术演进追踪 | 高频简单问答（延迟高、成本高） | ¥15,000–40,000 |
| 混合检索 | BM25 关键词 + 向量语义 + 重排序（Reranker） | 兼顾精确匹配和语义理解，覆盖面最广 | 需要全量知识图谱推理的极端场景 | ¥8,000–20,000 |
混合检索正在成为企业级标配。BM25 保证关键词精确命中（比如产品编码"SKU-8823"），向量检索覆盖语义相近的表述（"退货"≈"退换"≈"refund"），Reranker 再做一次精排。这套组合对大多数业务场景足够——但别忘了，当问题需要"连点成线"时，仍然绕不开知识图谱[2]。
很多团队在 POC 阶段看到的是"API 调用只要几分钱一次"，一到生产环境就傻眼。我们以一个中型企业场景做一笔实际估算：
纯向量方案：一次性索引成本约 ¥2,000（Embedding API），日常查询每次平均 3,000 token 输入 + 500 token 输出，日均 2000 次 × ¥0.015/1K token ≈ ¥105/天，月费约 ¥3,200。加上向量数据库托管（Milvus 云服务 ¥2,000/月），总计约 ¥5,000–7,000/月。
GraphRAG 方案：索引阶段每份文档需调用 LLM 做实体提取和关系构建，10 万份文档的单次索引成本约 ¥20,000–35,000。查询阶段每次需在图谱上遍历多跳关系，单次 token 消耗是纯向量的 3–5 倍，月查询费约 ¥12,000–18,000。加上图数据库托管（Neo4j Aura ¥6,000/月），总计约 ¥18,000–35,000/月。贵，但能回答向量方案根本搞不定的问题。
混合方案：在纯向量基础上叠加 BM25 索引（Elasticsearch）和 Reranker 模型（如 bge-reranker-v2），月费增加约 ¥3,000–5,000，总计约 ¥8,000–15,000/月。这是目前性价比最高的选择，覆盖 80% 的查询场景。
一个关键提醒：不要低估索引更新成本。文档每周都在变——新版本、新项目、新规章。GraphRAG 的索引更新成本远高于纯向量方案，因为每次文档变更都需要重新提取实体和关系。如果文档变更频率很高（周更 > 20%），混合方案的实际成本可能只有 GraphRAG 的三分之一。
做知识库问答，第一版往往只考虑"一问一答"。但真实用户行为不是这样的。用户会追问："刚才那个供应商的合同条款里，违约金怎么算？""对比一下它和 B 供应商的付款周期。"——第二轮问题依赖第一轮的上下文，而且可能跨不同权限级别的文档。
上下文窗口管理：多轮对话中，每次都要把历史问答和检索结果一起塞进 LLM。10 轮对话下来，上下文可能膨胀到 20K token 以上，不仅贵，而且 LLM 的注意力在长上下文中会衰减——中间几轮的信息容易被"遗忘"。优码云目前的做法是：保留最近 3 轮完整对话 + 前面轮次做摘要压缩，将上下文控制在 8K token 以内。实测回答连贯性没有明显下降，但 token 消耗减少了 40%。在多 Agent 场景下，RAG 还可以作为 Agent 之间的共享记忆层，我们在《多智能体协作实战：RAG 作为共享记忆层》中有更详细的架构拆解。
权限隔离：HR 文档和财务文档不能让同一个员工都看到。这在数据库层面好办——加个 WHERE 条件就行。但在 RAG 场景下，向量检索拿到的 Top-K 文本块天然不带权限标签。解决方案是在索引阶段就为每个 chunk 打上权限元数据标签，检索后用标签做二次过滤。代价是：过滤后可能凑不够 K 个有效块，此时需要降级策略（扩大检索范围或直接告诉用户"您无权访问相关信息"）。
回到开头那个零售客户。首版系统用的是 LangChain 默认配置——RecursiveCharacterTextSplitter 按 1000 字符切块、OpenAI Embedding + Pinecone 向量检索、GPT-4 直接生成。准确率 62%，用户投诉集中在"答非所问"和"信息不完整"。
我们分三步做了升级（完整的过程记录见《RAG 系统从 PoC 到生产：检索精度提升的工程实录》）：
反面教训也很直接：直接套 LangChain 默认配置的后果不只是准确率低——默认 chunk_size=1000 在中文场景下经常把一句话切成两半，因为中文字符密度远高于英文。1000 个中文字符的信息量约等于 3000 个英文字符。中文 RAG 建议 chunk_size 设在 400–600 字符，配合 20% 重叠。
没有银弹。但有一个可操作的决策框架：
另有一条铁律：不要在系统上线第一天就上 GraphRAG。先用纯向量/混合方案跑 2-3 个月，积累真实用户查询日志，分析哪些类型的问题现有方案搞不定，再有针对性地建子图。麦肯锡的 Lilli 平台就是用渐进式策略，先 RAGOps 自动化管道，再逐步引入智能代理能力，最终覆盖了 10 万份文档、回答了超过 800 万个问题[3]。关于企业级 AI 工作流从编排到部署的完整链路，可参考《企业级 AI 工作流平台落地实战》。
Q：GraphRAG 一定要用 Neo4j 吗？
A：不一定。微软开源的 graphrag 库使用 Parquet 文件做本地存储，适合 POC。生产环境 Neo4j 和 NebulaGraph 是主流选择。前者生态成熟但商业授权贵，后者国产开源、分布式扩展性好。
Q：RAG 系统能用国产模型吗？
A：可以，而且建议这么干。DeepSeek-V3 做生成、bge-large-zh 做 Embedding、bge-reranker-v2-m3 做精排，整套国产方案在中文场景的实测表现不输 OpenAI + Cohere 组合，且支持私有化部署——对于金融、政务类客户这是硬需求。
Q：Token 成本有没有可能再降？
A：有三条路。一是用缓存——相同或相似问题的 Embedding 结果缓存复用；二是用小型精调模型做初筛（例如 7B 参数模型做第一轮过滤），再交大模型做最终生成；三是 GraphRAG 场景下用社区摘要代替全量实体遍历，可降低 50–70% 的查询 token。
Q：RAG 和微调（Fine-tuning）怎么选？
A：不是二选一。RAG 解决"知识更新"问题——文档变了，答案跟着变；微调解决"风格和格式"问题——让模型学会你们公司的术语和输出规范。企业最佳实践是微调 + RAG 叠加使用，微调管"怎么说"，RAG 管"说什么"。