⏱ 预计阅读：9 分钟
过去两年，很多企业做 AI 应用的第一反应是 RAG：把文档切块、向量化、塞进向量库，再让大模型根据相似片段回答。
这个路线能解决一类问题：文档里已经写得很清楚，用户问法和原文语义也足够接近。
但一旦问题变复杂，向量 RAG 很快会露出短板。比如在医药研发和医疗场景里，用户真正想问的往往不是“哪一段文字最像我的问题”，而是：
这个药物和哪些靶点、疾病、人群、试验、指南证据有关？这些关系从哪里来？哪些关系可信？能不能按权限给不同角色看不同答案？
GraphRAG 并不是新近出现的技术，它的基本路线也不神秘：把实体和关系纳入检索与上下文组织，再让模型结合文本证据生成回答。
真正值得重看的，不是它有没有新颖的算法标签，而是它能不能把企业 AI 从“找相似片段”推进到“按关系、证据和边界组织上下文”。
Neo4j 在 2026 年 7 月 2 日举办的 GraphTalk Pharma & Life Sciences，把这件事讲得很集中。它没有把知识图谱当成漂亮的节点连线图，而是放在 GenAI、GraphRAG、agentic AI 和生命科学业务场景里看：药物研发、候选基因发现、临床数据互操作、专利竞争、供应链洞察、QA 调查和上下文图都在同一个问题下面展开。
GraphRAG 的创新不在于多加一层检索，而在于把答案生成变成一条可追溯、可评测、可治理的上下文工程链路。
1、知识图谱不是一张大网，而是 AI 的上下文底座
很多人听到知识图谱，脑子里会出现一张很复杂的网：一堆点、一堆线、一个能拖拽缩放的可视化界面。
这只是外观，不是本质。
知识图谱真正存的是四类东西：
第一，实体。 比如药物、靶点、疾病、患者、科室、文献、试验、供应商、合同、设备、流程节点。
第二，关系。 比如药物作用于靶点，靶点关联疾病，患者符合某个入组条件，某个批次经过某个质检流程，某个供应商影响某条产线。
第三，语义。 同义词、层级、类型、约束、规则、时间有效性，都决定系统能不能把“同一件事”识别成同一件事。
第四，证据。 每条关系最好能回到论文、临床试验、指南、数据库记录、业务系统日志或人工确认记录。没有证据链，图谱很容易变成“看起来很科学的关系幻觉”。
所以知识图谱和普通数据库最大的差别，不是技术名词，而是关注点。
普通表结构擅长记录“字段”。向量库擅长找“相似片段”。知识图谱擅长表达“关系”。
而企业 AI 最缺的，恰恰是关系。
一个客服 Agent 回答客户问题，要知道客户、合同、工单、产品版本、权限和历史处理记录之间的关系。一个医疗 Agent 辅助医生整理病历，要知道患者、诊断、用药、检验、指南和风险因素之间的关系。一个药企研发团队做靶点发现，要知道基因、疾病、通路、文献、实验结果和候选假设之间的关系。
大模型很会把语言说顺，但企业真正需要的是：它说出来的每句话，都能被关系和证据托住。
2、GraphRAG 的真实价值，是把相似检索变成上下文工程
传统 RAG 的流程比较直接：切分文档，生成 embedding（文本向量），用户提问时找相似片段，把片段塞给大模型生成答案。
GraphRAG 也不是某一种固定实现。它的共同方向，是在检索和上下文组织阶段引入图结构，让系统不只按相似度取片段，也能沿着实体、关系、约束和证据路径组织上下文。
Neo4j 的技术文章把这个问题讲得很直白：当问题需要跨多个实体、多段文本、多跳关系时，纯向量检索可能会拿到重复片段，也可能漏掉真正关键的关联信息。GraphRAG 的价值，就在于把知识图谱变成检索和上下文组织的一部分。
更工程化一点说，常见实现至少有三层分工：
图谱负责关系和约束。 它告诉系统有哪些实体、它们怎么相连、关系类型是什么、路径有多远，以及哪些时间、类型和业务规则需要满足。
向量检索负责文本证据。 它补充原文段落、最新文档、长文本细节和自然语言表达，让图上的关系能够回到具体语料。
大模型负责理解问题、组织上下文并生成解释。 它把图谱路径、文档片段、用户问题和任务指令整合成可读答案，但不应单独决定事实、权限或行动。
真正的创新点也在这里：不是第一次把图数据库和大模型放在一起，而是把关系、文本、来源、时间、权限和评测纳入同一条上下文链路。对于生产系统，这意味着回答可以附着证据，规则变化可以更新，错误可以定位，Agent 执行动作前也有边界可检查。
这件事对医疗和生命科学特别重要。
因为医药问题天然不是单跳问题。
一个靶点是否值得做，不只看某篇论文提到过它，还要看疾病机制、表达谱、动物模型、临床终点、竞争管线、不良反应、患者亚群和历史失败案例。一个患者是否适合某类试验，也不只看一句入组条件，还要看诊断、用药、检验、既往史、排除条件、时间窗口和机构规则。
如果系统只找最相似的几段文本，很容易“看见局部，错过关系”。
在这类问题里，GraphRAG 的价值不是把 RAG 包装得更时髦，而是让 AI 在回答前先拿到更完整、更结构化、更可解释的上下文。
向量检索像是在一堆书里找相似句子；知识图谱像是先把人物关系、事件顺序和证据链画出来，再让模型开口。
3、为什么生命科学是知识图谱的高价值场景
Neo4j 这场 GraphTalk 很适合作为知识图谱的学习入口，因为它不是抽象讲产品能力，而是按 pharma product lifecycle 展开：研发、临床、供应链和技术底座。
其中 Bayer 的分享聚焦早期靶点发现，围绕 gene-disease associations（基因-疾病关联）和 GraphRAG 展开。这里的价值不只是提出候选关系，还要把生成式回答锚定到可查询的图关系上，形成 grounding（证据锚定）。
KWS Group 的分享讲候选基因发现。它把知识图谱、link prediction（链接预测）和生成式 AI 组合起来，用于复杂农业性状的 candidate gene discovery。它对医疗 AI 也有启发：如果一个系统给出候选假设，却解释不清假设来自哪些关系和证据，业务团队很难真的采用。
BASF 的 Plant Twin 则把 omics（组学数据）、orthology（同源关系）、pathway（生物通路）和文献等碎片化生物数据汇成图，用来补齐非模式植物物种的知识缺口。这个案例说明，知识图谱不只是给 AI 问答服务，它也可以先作为复杂科学数据的整理方式。
临床侧也一样。
Insel Gruppe 的分享讲 Swiss EHR（电子健康记录）里的 free-text medication 和 procedure mapping。核心问题不是让模型直接吞下自由文本，而是先把多语言、异构记录映射到标准词表，再把 mappings、classifications 和 semantic relationships 放入 Neo4j，用于交互式可视化、验证和 gap analysis。
这比“让大模型读病历”更接近真实临床数据工程。
真实医院数据不是干净的表格。药品名可能有缩写、商品名、不同语言、不同写法；操作名称可能在不同系统里粒度不同；同一个临床事实可能分散在医嘱、病程、检验、报告和编码里。
如果直接让 LLM 处理，很容易把“看起来像”的内容当成事实。知识图谱的作用，是先把这些异构表达映射成可查询、可验证、可更新的关系网络。
医疗 AI 的难点不是让模型会说医学中文，而是让模型知道自己正在引用哪条临床事实、哪条指南证据、哪条权限边界。
4、知识图谱不只服务研发，也能服务运营和商业
很多企业会误以为知识图谱只适合科研部门。
GraphTalk 里的供应链和 QA 场景说明，知识图谱也可以服务运营和商业。
Boehringer Ingelheim 的 SCIX 项目把供应链、质量、监管和财务数据统一成 pharma context graph，再加上自然语言层，让非技术用户不用学习底层查询接口，也能追踪产品端到端流转、评估网络风险、做 what-if 场景分析。
Amalgo 的分享把“从 30 天缩短到 10 天”作为 QA 调查的目标口径，并用 context graph simulation 评估供应链中的牛鞭效应、利润、罚金和库存成本。这里的价值不在于一个固定时长，而在于把调查过程和供应链后果放进同一张关系图里分析。
这两个方向的共同点是：它们都不是在问“AI 能不能写一段摘要”，而是在问：
一个业务问题背后涉及哪些对象、关系、约束和后果？
这恰好是图谱擅长的。
在医疗机构里，这类思路可以迁移到很多地方：
• 抗菌药物管理。 患者、用药、病原学、药敏结果、指南、科室和感染控制指标之间本来就有复杂关系。
• 临床路径管理。 诊断、检查、治疗、医嘱、费用、耗材和质控节点可以形成路径图。
• 医疗设备运维。 设备、故障、工单、备件、供应商、科室、停机时间和维保合同之间也可以建图。
• 科研队列发现。 患者、表型、检验、影像、用药、随访和结局之间需要跨系统关联。
• 药企医学事务。 适应症、KOL、文献、会议、真实世界证据、竞品和区域活动也天然适合关系建模。
知识图谱进入企业，不一定从“超级大脑”开始。更现实的入口，往往是一个跨系统、跨角色、跨证据链的高价值问题。
5、企业从 0 到 1 做知识图谱，先别追求大而全
知识图谱项目最常见的失败方式，是一开始就想把全公司的知识都建起来。
这会导致三个问题。
第一，本体设计无限膨胀。每个部门都想把自己的字段、对象、规则塞进来，最后迟迟不能上线。
第二，关系质量没人负责。图谱越大，错误关系、过期关系、重复实体和证据缺失越难治理。
第三，业务价值不清楚。图谱看起来很壮观，但没人知道它到底让哪个流程变快、哪个风险降低、哪个决策更可靠。
更稳的路线，是先做一个最小闭环。
第一步，选一个高频高价值问题。
不要问“我们能不能建企业知识图谱”，而要问“哪个问题如果回答得更准、更快、更可解释，会带来明确业务价值”。
比如药企可以选“候选靶点优先级排序”，医院可以选“抗菌药物用药与病原学证据关系”，设备企业可以选“故障工单到备件和停机风险的关联分析”。
第二步，定义最小本体。
只定义这个问题必须用到的实体、关系、属性和同义词。先别追求覆盖全业务。
第三步，接入可信数据。
结构化数据库、文档、指南、日志、人工标注都可以进入图谱，但每类数据要有来源、版本、更新时间和责任人。
第四步，建立证据链。
每条重要关系最好能回到原文、系统记录或人工审核记录。尤其在医疗和生命科学场景里，不能让 LLM 自己“推断出”一条看起来合理但没有依据的关系。
第五步，决定是否接 GraphRAG 或 Agent。
图谱不必一开始就接 Agent。先让业务用户能提问、能追溯，再根据数据质量、权限治理和评测结果，决定是否把图谱查询、向量检索、权限过滤和 LLM 生成组合起来。
第六步，做评测。
评测不能只看回答像不像人写的。至少要看准确性、覆盖率、可解释性、权限隔离、敏感信息处理和错误恢复。
第七步，上生产闭环。
上线以后要监控哪些问题答错、哪些关系被频繁使用、哪些实体缺失、哪些证据过期。知识图谱不是一次性交付物，而是持续更新的上下文资产。
先跑通一个可复用闭环，再扩大实体和场景。这比先画一张覆盖全公司的大图更有价值。
6、GraphRAG 的创新，最终体现在 AI 产品的责任边界
如果 GraphRAG 只是把向量检索换成图检索，它确实不算什么新鲜事。真正有生产价值的部分，是它把证据、权限、规则和评测固定到上下文链路里。
因为企业 AI 正在从 demo 走向生产。
demo 阶段，大家最关心模型能不能回答、界面是不是好看、效果是不是惊艳。
生产阶段，真正的问题会变成：
• 这条答案根据什么证据生成？
• 这些数据是谁有权限看的？
• 如果业务规则变了，系统怎么更新？
• 如果用户质疑答案，产品经理、算法工程师、业务负责人和合规负责人怎么一起定位问题？
• 如果 Agent 要进一步执行动作，它有没有拿到足够可靠的上下文？
这些问题不是 prompt 能单独解决的。
Prompt 能约束模型说话方式，但不能天然保证事实关系正确。向量库能提高召回能力，但不能天然理解实体之间的路径。工作流编排能让 Agent 调用工具，但不能自动告诉它哪些关系可信、哪些证据过期、哪些动作越权。
GraphRAG 的意义，是把一部分“责任”从模型黑箱里拿出来，放到可以建模、审计、更新和治理的系统层。
这也是 GraphRAG 和 agentic AI 结合时最值得关注的地方。
Agent 不是多调用几个工具就会变可靠。它需要知道工具之间的对象关系、数据边界、业务规则、用户权限和证据链。否则 Agent 的能力越强，风险也越大。
未来靠谱的企业 AI，不会只靠一个更聪明的大模型，而会靠模型、图谱、检索、权限、评测和监控共同构成的系统。
7、给医疗 AI 和企业 AI 团队的判断
如果你正在做医疗 AI、药企 AI、医院数据平台或企业知识助手，我建议用三个问题判断是否需要知识图谱。
第一个问题：用户的问题是不是经常跨多个对象？
如果只是在一份文档里找答案，普通 RAG 可能够用。如果经常涉及患者、疾病、药物、指南、检查、流程、权限和时间，知识图谱的价值会明显上升。
第二个问题：答案是不是必须解释关系和证据？
如果用户只要一段泛泛总结，图谱未必优先。但如果答案要能说清“为什么这个对象和那个对象有关”，图谱就很重要。
第三个问题：系统是不是要进入生产责任边界？
如果只是内部试用，模型偶尔答错还能人工兜底。如果要进入医生工作流、药企研发决策、供应链风险判断或合规流程，就必须考虑可追溯、可审计、可更新。
知识图谱不是所有 AI 应用的必选项。
但当一个 AI 应用需要处理复杂关系、可信证据、权限边界和多步行动时，知识图谱会从“可选增强”变成“系统地基”。
GraphRAG 的价值，不在于让 RAG 看起来更先进，而在于让 AI 的上下文具备关系、证据和边界。