整合知识图谱以优化检索

密集向量 (vector) (dense vector)检索在寻找语义相似文本片段方面表现突出，但有时难以处理需要精确事实回忆、实体消歧或理解复杂关系（不使用“概念”）的查询。在此情况下，知识图谱（KGs）提供了一种有益的补充方法。知识图谱以实体及其关系网络的形式表示信息，提供结构化、真实的数据，能大幅增加传递给RAG系统生成器的上下文 (context)信息。

知识图谱的结构与优势

知识图谱由节点（代表人物、组织、产品或抽象事物等实体）和边（代表这些实体间的关系，如“是一种”、“由...开发”或“位于”）构成。例如，在一个生物医学知识图谱中，“阿司匹林”可能是一个实体，“镇痛剂”是另一个，一条“is_a_type_of”的边可以将“阿司匹林”与“镇痛剂”连接起来。这种结构化表示允许进行精确查询，并获取文本中可能隐藏或表述模糊的明确事实。

将知识图谱整合到您的RAG流程中可以带来多项益处：

1. 事实准确性提升： 知识图谱是经过验证的事实的直接来源。当查询寻求具体事实信息（例如：“海平面上水的沸点是多少？”）时，知识图谱通常能提供直接、明确的答案，减少大型语言模型（LLM）从可能含有噪声的文本段落推断事实的依赖，从而降低幻觉 (hallucination)风险。
2. 消歧能力增强： 自然语言常有歧义。“捷豹”一词可以指动物、汽车品牌或操作系统。知识图谱通过其唯一的实体标识符，能够帮助解决此类歧义。如果查询中提及“捷豹”以及其他与“发动机排量”相关的词汇，系统可以推断出汽车背景，并从知识图谱中获取关于“捷豹（汽车品牌）”的相关信息。
3. 多跳推理 (inference)： 知识图谱擅长展示间接关系。如果您想知道“哪些由总部位于加利福尼亚州的公司开发的药物与华法林产生作用？”，知识图谱可以遍历多重关系：Warfarin -> interacts_with -> Drug_X -> developed_by -> Company_Y -> headquartered_in -> California。这种多跳推断对于纯文本检索而言存在挑战。
4. 上下文 (context)丰富： 从知识图谱中获取的信息（例如，实体的属性、相关实体）可用于丰富提供给大型语言模型（LLM）的上下文，从而生成更全面、更具信息量的回应。

RAG中知识图谱集成的架构

有多种架构模式可将知识图谱纳入您的RAG系统。选择哪种模式通常取决于您应用的具体需求、知识图谱的特性以及性能方面的考量。

1. 并行检索与整合

在这种常见模式中，用户查询会同时由标准向量 (vector)检索器（作用于您的文本语料库）和知识图谱检索器（查询知识图谱）进行处理。来自这两个途径的结果随后进行合并或结合，再传递给大型语言模型（LLM）。

一种并行检索架构，其中查询被发送到向量存储和知识图谱，其结果再合并提供给大型语言模型（LLM）。

整合步骤很重要。它可能包括：

• 简单地连接文本片段和知识图谱事实。
• 使用知识图谱事实对文本片段进行重新排序或过滤。
• 将知识图谱事实格式化为自然语言句子，使其与文本更顺畅地结合。

2. 知识图谱优先用于查询增强

在此模式下，知识图谱用于在用户查询到达主要文本检索器之前对其进行预处理或增强。

1. 实体链接： 识别用户查询中的实体（例如，“苹果财报”）。
2. 知识图谱查找： 从知识图谱中获取关于这些实体的信息（例如，对于“苹果公司”，找到其官方股票代码“AAPL”、所属行业“科技”以及“iPhone”等产品）。
3. 查询扩展/重写： 原始查询使用来自知识图谱的信息进行扩展或重写。查询“苹果财报”可能变为“Apple AAPL 科技 财报 iPhone 销售”。 这个增强后的查询随后用于向量检索，可能带来更相关的文档获取。

3. 文本优先，知识图谱次之，用于上下文 (context)细化或验证

在这种方法中：

1. 初始查询由向量检索器处理，获取一组候选文本片段。
2. 从这些检索到的片段中提取实体（例如，使用命名实体识别）。
3. 随后在知识图谱中查找这些实体，以：
   • 验证信息： 检查文本中提及的事实是否与知识图谱一致。
   • 获取额外上下文： 从知识图谱中收集关于检索文本中存在的实体的相关事实或属性。
   • 重新排序文档： 优先处理其实体和关系得到知识图谱有力支持或丰富补充的文档。 现在包含知识图谱派生信息的细化上下文将传递给大型语言模型（LLM）。

实施考量

整合知识图谱并非没有挑战：

• 知识图谱构建与维护： 您可以使用公开可用的知识图谱（如维基数据、DBpedia，或像UMLS这样的专业医疗信息图谱），也可以构建自己的知识图谱。构建定制知识图谱需要投入大量精力在数据建模、提取和持续维护上，以确保数据质量和时效性。

• 实体链接： 准确地将文本（查询或文档）中的提及映射到知识图谱中的规范实体是一项复杂的自然语言处理（NLP）任务。歧义、拼写变体和新实体持续构成挑战。像spaCy的EntityLinker或专业库可以提供帮助，但通常需要进行特定方面的调整。

• 知识图谱查询： 知识图谱通常使用SPARQL（用于基于RDF的知识图谱）或Cypher（用于像Neo4j这样的属性图）等语言进行查询。您的RAG系统将需要一个组件来将用户查询的某些方面或中间结果转换为这些图查询语言。

  例如，要使用像维基数据这样的知识图谱的SPARQL端点查找法国首都，查询可能如下所示：

  SELECT ?capitalLabel WHERE {
    wd:Q142 wdt:P36 ?capital . # Q142 是法国，P36 是 '首都'
    SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
  }
  

  这将返回“巴黎”。根据用户输入动态整合此类查询需要精心设计。

• 可伸缩性与性能： 大型知识图谱在托管和查询时可能消耗大量资源。图数据库性能、索引策略和查询优化都很重要。增加知识图谱查找也可能增加RAG系统的整体延迟，因此高效的查询和缓存是必需的。

• 知识图谱输出表示： 如何将结构化的知识图谱事实呈现给大型语言模型（LLM）？

  • 自然语言句子： “法国首都是巴黎。法国人口约有6700万。”
  • 结构化格式（例如，JSON）：

    {
      "entity": "法国",
      "facts": [
        {"predicate": "has_capital", "object": "巴黎"},
        {"predicate": "population_estimate", "object_value": 67000000, "unit": "人"}
      ]
    }
    

  • 模板化提示： 将知识图谱事实插入到提供给LLM的提示中的特定占位符中。 最佳方法取决于LLM和期望的输出风格。通常需要进行试验。

一个实际例子：改进金融问答

考虑一个旨在回答公司财务问题的RAG系统。

• 用户查询： “苹果上一季度的营收是多少，与微软相比如何？”
• 无知识图谱时： 系统可能会检索提及两家公司营收数据的新闻文章或财报电话会议记录。大型语言模型（LLM）随后需要解析这些内容，提取数字，并进行比较，这存在误读日期或数字的风险。
• 集成知识图谱时（并行检索）：
  1. 向量 (vector)检索器： 获取相关新闻、报告。
  2. 知识图谱检索器：
     • 识别“苹果”和“微软”为公司实体。
     • 查询知识图谱以获取 (苹果, hasRevenue, ?revenue, financialPeriod: "Q4 2023") 和 (微软, hasRevenue, ?revenue, financialPeriod: "Q4 2023")。
     • 知识图谱返回结构化数据：Apple_revenue_Q4_2023 = $X_billion，Microsoft_revenue_Q4_2023 = $Y_billion。
  3. 结果整合： LLM接收文本片段以及这些精确的结构化事实。
  4. 生成： LLM现在可以生成更准确、更直接的回答：“2023年第四季度，苹果的营收为X亿美元，而微软的营收为Y亿美元。[基于这些数字的比较]。”

挑战与未来走向

尽管能力突出，知识图谱集成仍面临挑战：

• 知识图谱稀疏性与不完整性： 知识图谱很少是完整的。关于新实体或不常见关系的信息可能存在缺失。
• 动态知识图谱： 对于信息快速变化的方面（例如，股票价格、产品可用性），保持知识图谱的时效性是一项巨大的工程投入。
• 复杂推理 (inference)： 虽然知识图谱有助于多跳推理，但非常复杂的推断链在高效可靠地实现方面仍具挑战。
• 统一表示： 目前正在研究能够从文本和图结构中共同学习的模型，以创建本质上理解两种信息类型的统一嵌入 (embedding)或推理框架。将知识图谱嵌入（例如TransE、ComplEx）投影到与文本嵌入相同的空间，是朝着这个方向迈出的一步。

通过周全地整合知识图谱，您可以使您的RAG系统能够利用丰富的结构化事实信息。这通常会带来更准确、可靠且上下文 (context)感知的回应，特别是对于要求精确和明确关系的查询，是优化RAG系统以适应高要求生产环境的重要一步。