海天雷鹰印章海天雷鹰
ARTICLE行业洞察

RAG 落地,知识图谱为什么是必修课

发布日期

  当大模型开始“一本正经地胡说八道”,当检索回来的片段答非所问,你需要的不是更大的模型,而是一张能够锚定事实的知识网络。

  一、RAG 的基本原理:让大模型“开卷考试”

  RAG(Retrieval-Augmented Generation,检索增强生成)是当前大语言模型落地应用中最主流的技术范式。它的核心思想并不复杂:在生成答案之前,先从外部知识库中检索相关文档片段,将检索到的内容作为上下文拼入提示词,再由大模型基于这些上下文生成最终回答。简而言之,RAG 让大模型从“闭卷考试”变成了“开卷考试”,通过外部知识补充来弥补模型参数知识的不足。

  一个典型的 RAG 流程包括三个关键环节:文档预处理与向量化、语义检索、上下文增强生成。首先,将原始文档切分为若干文本块,通过嵌入模型将每个文本块编码为高维向量,存入向量数据库;其次,当用户提问时,将问题同样编码为向量,在向量数据库中检索语义最相似的若干文本块;最后,将检索到的文本块与用户问题拼接,送入大模型生成回答。这套流程看似简洁优雅,但在实际落地中却暴露出一系列痛点。

  二、RAG 落地的四大痛点

  第一个痛点是幻觉问题。大模型在缺乏明确事实支撑时,倾向于生成看似合理但实际错误的内容。即便提供了检索上下文,模型也可能因为上下文信息不充分而“自由发挥”,产出与事实不符的答案。在医疗、法律等高准确性要求的场景中,幻觉是不可接受的。

  第二个痛点是检索不精准。纯向量检索依赖语义相似度匹配,对于涉及实体属性、精确数值、专有名词的查询往往力不从心。比如用户问“张三的上级主管是谁”,向量检索可能返回所有包含“张三”和“主管”的文档片段,却无法直接给出结构化的精确答案。

  第三个痛点是缺乏推理能力。很多复杂问题需要跨多个文档进行逻辑推理,比如“A 公司的供应商的总部在哪个城市”,这涉及“A 公司的供应商是谁”和“该供应商的总部在哪”两步推理。纯向量检索难以支持这类多跳推理,只能返回零散的文本片段,推理工作仍然需要大模型自己完成,而大模型的推理恰恰是最容易出幻觉的环节。

  第四个痛点是领域知识深度不足。通用嵌入模型在专业领域的语义理解有限,导致检索召回率和准确率偏低。垂直领域的术语、缩写、同义关系、上下位关系往往无法被准确捕捉,专业文档的检索效果大打折扣。

  三、纯向量检索的局限性

  向量检索的本质是将文本压缩为稠密向量,通过向量距离衡量语义相似度。这种方式在处理模糊语义匹配时表现优秀,但在精确事实检索方面存在先天不足。

  第一,向量是文本的有损压缩。一段话编码为一个几百维的向量后,细节信息不可避免地丢失。模型只能判断两段话“像不像”,无法判断它们在事实上“对不对”。第二,向量相似不等于逻辑相关。语义接近的两段文本可能在事实上存在矛盾,向量检索无法区分这种矛盾,会将矛盾信息一并返回给大模型。第三,向量检索难以表达实体之间的结构化关系。比如“属于”“管理”“位于”“生产于”这类关系型知识,在向量空间中无法被显式表达。第四,向量数据库不擅长处理聚合查询和条件过滤。比如“统计 2023 年签约金额超过 100 万的客户数量”这类查询,向量检索完全无法胜任,需要结构化查询语言的支撑。
21_RAG知识图谱_架构

  四、知识图谱如何补足 RAG 的短板

  知识图谱以“实体—关系—实体”的三元组形式存储结构化知识,天然适合表达事实和关系。将知识图谱引入 RAG,能够从以下四个维度补足短板。

  第一,提供结构化知识。 知识图谱中的每条三元组都是一条明确的事实陈述,比如“(北京)—是首都→(中国)”,不存在歧义。当大模型从知识图谱中获取上下文时,获得的是精确的事实而非模糊的文本片段,从根本上降低幻觉风险。

  第二,支持实体关系推理。 知识图谱将实体之间的显式关系存储为边,推理过程就是沿着边进行图遍历。比如查询“张三的上级主管”,只需从“张三”节点出发,沿“上级主管”边一步即可到达目标节点,无需在大量文档中大海捞针,答案精确且高效。

  第三,实现精确事实锚定。 向量检索返回的是“相似段落”,而知识图谱返回的是“精确答案”。当用户问某药品的禁忌症时,知识图谱可以直接返回该药品节点连接的所有“禁忌症”边指向的实体列表,而不是返回一段可能包含也可能不包含答案的文本让大模型自行提取。

  第四,支撑多跳推理。 对于“A 公司的供应商的总部在哪”这类多跳问题,知识图谱可以通过两跳图遍历直接得到答案:先从“A 公司”沿“供应商”边找到供应商节点,再从该节点沿“总部位于”边找到城市节点。这在纯向量检索中几乎无法实现,而在知识图谱中只需两步图遍历即可完成。

  五、GraphRAG:知识图谱与向量检索的融合架构

  GraphRAG 是将知识图谱与向量检索相融合的增强型 RAG 架构。它的核心思路是“两条腿走路”:对于事实型、关系型问题,走知识图谱查询路径,获取精确的结构化答案;对于语义型、描述型问题,走向量检索路径,获取相关的文本片段。检索完成后,将两条路径的结果融合,统一送入大模型进行生成。

  GraphRAG 的工作流程可以概括为五个步骤。第一步,文档解析与实体抽取,从原始文档中识别实体并构建实体关系三元组。第二步,知识图谱构建与索引,将三元组存入图数据库,同时为每个实体和关系建立向量索引。第三步,查询理解与路由,分析用户问题的类型,决定走知识图谱查询、向量检索还是两者并行。第四步,混合检索,知识图谱子图查询与向量语义检索同步执行,获取结构化事实和语义文本两路结果。第五步,上下文融合与生成,将结构化事实与文本片段按逻辑组织后送入大模型,生成既有事实依据又有语义解释的高质量回答。这种架构既保留了向量检索在模糊语义匹配上的优势,又获得了知识图谱在精确事实推理上的能力,是当前 RAG 演进的主流方向。

  六、行业应用案例

  在医疗问诊场景中,某三甲医院引入 GraphRAG 构建智能问诊助手。知识图谱中存储了疾病、症状、药品、检查项目之间的关联关系,向量库中存储了临床指南和文献原文。当医生询问“青霉素过敏的患者能否使用阿莫西林”时,知识图谱快速推理出“阿莫西林—属于→青霉素类药物”这一关系,结合向量检索到的用药指南段落,大模型给出准确的用药禁忌提醒,避免了纯文本检索可能遗漏关键关联关系的风险。

  在法律咨询场景中,某法律科技公司利用知识图谱构建法条关联网络,将法律条文、司法解释、典型案例通过“引用”“修订”“冲突”“补充”等关系连接。用户咨询劳动纠纷问题时,系统不仅检索到相关法条文本,还通过图谱推理出需要同时参考的关联条款和最新司法解释,大幅提升了法律答复的完整性和准确性。

  在企业知识库场景中,某大型制造企业将产品手册、工艺文档、故障案例构建为知识图谱,设备节点与故障节点、维修步骤节点通过关系连接。维修工程师提问“某型号设备报错代码 E007 如何处理”时,系统通过图谱直接定位到该设备的故障描述和维修步骤,同时检索到相关故障案例的详细描述,生成结构化的维修指引,将平均故障排查时间缩短了 60%。

  七、实施建议

  企业在推进 GraphRAG 落地时,建议遵循以下路径。首先,梳理业务知识体系,明确核心实体类型和关系类型,这是知识图谱构建的根基,也是 GraphRAG 能否发挥价值的关键。其次,从高频、高价值的问答场景切入,先在垂直领域验证效果再横向扩展,避免一开始就铺大摊子。第三,重视知识图谱的质量维护,建立实体消歧、关系校验、定期更新的机制,图谱质量直接决定 GraphRAG 的回答质量。第四,向量检索与图谱检索的比例需要根据问题类型动态调整,建议引入查询分类器实现自动路由。最后,知识图谱的构建本身是一项需要专业数据加工能力的工作,涉及实体识别、关系抽取、图谱融合等复杂技术,建议选择有丰富数据加工经验的服务商合作。

  关于我们

  公司成立于 2001 年,专注档案整理与数字化、试题结构化录入、期刊校对、数据标注等一站式数据服务 20 余年。针对标准文档形近字符识别、复杂公式排版、多层级档案规整、题库结构化加工等行业难点形成成熟作业方案,适配科研院所、教育机构、企事业单位的批量数据处理需求。

  累计完成数十万份专业文档数字化、题库结构化加工项目,服务过多家科研机构、院校及企事业单位。核心团队 20 年以上行业经验,建立多层级质检审核机制,数据成果准确率稳定可控;持有 ISO 9001/27001 等体系认证、多项自主软件著作权、企业信用 AAA 等级。

  如果您有档案数字化、试题录入、数据标注方面的需求,欢迎联系我们:


  本文为原创科普内容,如需转载请注明出处。关注我们,持续分享数据服务行业的实战经验与行业洞察。