当向量相似度开始骗你
一家三甲医院的 AI 问答系统上线三个月后，主任医师发现了一个诡异现象：问"糖尿病合并肾病的胰岛素首选用药"，系统答得很顺；问"过去两年我院终末期肾病合并感染患者的平均住院日变化"，要么答非所问，要么直接拒答。
问题不是模型不够大。问题在于这道题本身就不该走向量检索。
传统的 RAG（Retrieval-Augmented Generation）把文档切成 chunk、向量化、按余弦相似度召回。语义匹配听起来很美，但碰到跨文档、多跳、全局这三种问题时基本哑火。Google Cloud 在 2026 年 4 月更新的 Agentic AI 架构文档里也指出，向量搜索擅长语义近似，无法反映多源数据之间真实的关联结构。[^1]
这不是哪一家医院的问题。一家中型券商的投研底稿库同样卡在类似瓶颈上：研究员问"新能源车产业链上，电池正极材料磷酸铁锂供应商中，哪几家近两年拿到国资入股"，系统返回的是三篇标题带"磷酸铁锂"的研报摘要，真正的供应商关系链完全没串起来。
这些场景共享一个特征：答案不在某一段话的语义相似度里，而在实体与实体之间的结构里。这条路，向量检索走不通，GraphRAG 才是答案。
为什么是 GraphRAG，不是更贵的向量库
先说清楚一件事：GraphRAG 不是向量检索的替代品，而是它的搭档。
微软研究院在 2024 年提出 GraphRAG 时就强调，向量检索擅长"找相似"，知识图谱擅长"找关系"。两者的组合能解决单一向量检索三个长期短板：
- 全局性问题无力：用户问"这批报告里最常见的三类风险"，向量只能返回与"风险"两字相近的若干片段，无法跨文档汇总；而 GraphRAG 的社区检测算法（Leiden 等）能够对整库做主题聚类，输出真正的全局摘要。
- 多跳推理断裂：向量召回是平铺的，没有"A 是 B 的供应商，B 工厂位于 X"这种链式可达信息。知识图谱天然建模 N 跳关系，复杂医疗和金融问询在这里才有解。
- 企业术语不一致：同一份报告里"信达生物"和"信达"指同一家公司；不同科室对"急性心梗"有 ICD-10 编码和临床简称两种写法。实体对齐（Entity Resolution）只能在图谱层完成，纯向量识别不了。
IBM 的官方教程也把这一逻辑讲得很直接：当你需要查询的是网络化、关系型信息时，矢量搜索的局限性会暴露，此时应该让图数据库顶上来。[^2]
这也是为什么 GraphRAG 在企业里"看起来贵、用起来省"——它前期的实体抽取与图构建成本不低，但每跳关系推理的 Token 消耗远低于"塞进更大上下文让模型自己推"的做法。在 2026 年 Token 不经济的大背景下，这一点尤其要命（关于 Token 成本的另一面，可以读读《Llama 5 预览背后，模型厂商开始认真算 Token 账》）。
案例一：三甲医院 DRG 病案的多跳问答
某省级三甲医院在 2025 年下半年把过去 8 年的出院病案首页（超过 60 万份）喂给了 GraphRAG 系统。建设过程拆成四步：
第一步：实体抽取的专科化。直接用 Llama 3 系列或 Qwen3 做通用抽取，效果一定拉胯。专业医学实体不是"病名"那么简单，需要 ICD-10 编码、解剖部位、手术操作码、检验项目、医院科室等 8 类节点同时落地。最终方案是：用一份由 5 位主治医师标注的 5000 条样本做 instruction-tuning，让模型在出现"DKA"时能自动绑定"糖尿病酮症酸中毒 / E11.100"这一对齐关系。
第二步：关系比节点更重要。病案图谱里，节点抽取之间是稀疏的，真正值钱的是"主诊断→并发症→手术→转归"这条链。GraphRAG 的实现要点是把"主诊断与其他诊断的合并症关系"显式建边，而不是只把它写成节点属性。在后续测试中，"糖尿病合并肾病患者使用胰岛素后的住院日变化"这类问询，依靠图上的 3 跳遍历 2.5 秒内返回准确结果，比纯向量方案准确率高了 38 个百分点。
第三步：混合检索而不是图替向量。每条查询先走一遍向量召回拿到 Top-K 候选文档，再由图谱查询补充跨文档实体关系；当两个召回通道给出矛盾答案时，依靠 GraphRAG 的可信度评分做仲裁。Google Cloud 的多模态 GraphRAG 架构白皮书也是这个思路——把向量搜索与图查询并联，而不是串联替换。[^1]
第四步：图谱的冷启动。60 万份病案不是一日抽取完的。医院实际方法是先抽 5 万份高质量病案冷启动图谱，再以每周 1 万份的速度增量更新；每周由医师抽检 200 条三元组，把错抽率压在 4% 以下。
这套系统上线后，医院统计处反馈：原本需要 2 名编码员花 3 天才能跑完的"季度病种亚组分析"，现在 5 分钟出结果，且路径可追溯。
案例二：券商投研底稿库
券商那边的麻烦略有不同：文档格式高度异构——既有 PDF 研报，也有 Excel 财务底稿、半结构化的 Wind 行业表、还有从企查查导出的工商关系树。在 GraphRAG 落地之前，他们用的就是"切 chunk + embed"那套，准确率长期在 50% 上下徘徊。
改造路径上有三个工程决策值得拎出来：
表格先于文本被建模。Vector RAG 处理表格基本靠 RAG 教程里最不推荐的"按行转文本"。GraphRAG 团队改用了结构优先：先由一个独立的 Vision-Language 模型把表格解析成多组行/列三元组入库，再回头跑文本抽取。这一步让他们对"营业收入同比"这类字段的检索准确率直接回到 95% 以上。关于表格处理的具体雷区，我们此前在《别光写正则》中详细拆过。
知识图谱选 Neo4j 还是 NebulaGraph。中小规模（亿级边以内）选 Neo4j，省心；超过这个量级，且要跑多跳 PageRank 风格的图算法，迁移到国产 NebulaGraph 的项目在 2026 年已经不少见。券商最终选的是 Neo4j + 国产图数据库双写，核心交易关系在 Neo4j，外部工商图谱进 NebularGraph。
实体对齐是企业知识库的命门。同一家公司有"宁德时代 / CATL / 300750"多种写法；不同报告里"电池正极材料供应商"可能包含 20 家关联合并子公司的不同表述。他们的做法是先跑一套规则化别名合并，再让 LLM 做模糊语义对齐，最后人工抽检 500 条决策边界样本。这种做法在医疗叫术语标准化，在金融叫实体合并，名字不同，逻辑完全一致。
结果上，过去需要研究员手动交叉 6 份研报才能整理出的"某新能源车企供应链全景图"，现在一次提问拿得到完整关系链，且每条边都能溯源到原始研报段落。
落地清单：如果你要在自己企业复刻
把这两个案例合并起来看，GraphRAG 在 2026 年企业落地大致有五条共性结论：
第一，先想清楚要解决的是不是"关系"问题。简单 FAQ 类需求，向量库够用；只有碰到跨实体、跨文档的链式查询，才值得投入图谱。盲目上 GraphRAG 只会换来一个没人维护的 Neo4j 实例。
第二，实体抽取的准确度上限取决于业务标注。5000 条高质量样本强于 500 万条无标签样本。这条规律在医疗和金融都反复验证过——模型能力天差地别，业务理解全看语料。
第三，混合检索才是落日线。把图谱当作向量的补充，而不是替代。Google Cloud、阿里云、IBM 的官方文档都把"向量 + 图谱"作为推荐架构，单图方案只适合极其专门的关系数据库场景。[^1][^2][^3]
第四，Token 成本要算账。图谱构建阶段一次性投入大，但每次查询的 Token 消耗随图谱完整度递减；纯向量方案初期便宜，话术越复杂、上下文越塞越贵。Llama 5 预览团队公开数据印证了这种"先苦后甜"的曲线。
第五，从一开始就设计可解释链路。医疗要给医师看"我为什么这么诊断"，金融要给合规留"我为什么引用这条研报"。图谱天然有溯源能力，把这条能力留住，反而是 Agent 时代企业知识库的核心竞争力之一。在最近的《Agent 的记忆宫殿》一文里我们讨论过类似的可解释记忆设计，可对照参考。
一个没说出口的判断
向量检索不会消失。它仍然是最便宜的语义召回入口。但凡涉及"跨实体、跨文档、可追溯、需要全局总结"这四个关键词之一，就该把 GraphRAG 摆上桌。
2026 年下半年，企业级 RAG 系统的比拼已经开始从"召回率"转向"复杂查询准确率"与"单查询 Token 成本"。后两个指标，单纯堆向量库已经追不上。在这个意义上，GraphRAG 不是 2.0，是企业知识库从"能用"走向"敢用"的必经一步。
至于本地要不要打通边缘网关、要不要把推理推到端侧，那是另一个故事——可以回头看看《把开源模型搬进边缘网关》里关于内存与算子不匹配的讨论，这两条线在企业 AI 的最终拼图里必然会相遇。
[^1]: Google Cloud Architecture Center, 智能体 AI 应用场景：多模态 GraphRAG 资源编排, 最后修订于 2026-04-06。 [^2]: IBM, 使用知识图谱实现 Graph RAG。 [^3]: 阿里云开发者社区, GraphRAG 技术探究及实践路径。
