Vector | Graph：蚂蚁首个开源Graph RAG框架设计解读

作者：范志东

检索增强生成（RAG：Retrieval Augmented Generation）技术旨在把信息检索与大模型结合，以缓解大模型推理“幻觉”的问题。近来关于RAG的研究如火如荼，支持RAG的开源框架也层出不穷，并孕育了大量专业领域的AI工程应用。我们设计了一个通用的开源RAG框架，以兼容未来多样化的基础研究建设和工程化应用诉求。

1. 概述

RAG的目标是通过知识库增强内容生成的质量，通常做法是将检索出来的文档作为提示词的上下文，一并提供给大模型让其生成更可靠的答案。更进一步地，RAG的整体链路还可以与提示词工程（Prompt Engineering）、模型微调（Fine Tuning）、知识图谱（Knowledge Graph）等技术结合，构成更广义的RAG问答链路。

除了传统意义上的增强内容生成，RAG的理念还可以进一步泛化到链路的其他阶段：

• 增强训练：REALM引入了知识检索器增强大模型预训练，以改进大模型的问答质量和可解释性。
• 增强微调：RA-DIT实现了对大模型和检索器的双指令微调，RAFT通过微调让大模型可以识别干扰文档。
• 增强语料：MuRAG支持了多模态数据的检索，提升了大模型在文本/图像混合检索场景下的推理质量。
• 增强知识：GraphRAG使用图社区摘要解决总结性查询任务的问题，将知识图谱技术应用到RAG。
• 增强检索：CRAG通过对检索到的文档置信度进行评估，提升问答上下文的质量。
• 增强推理：RAT在推理阶段将RAG与CoT相结合，以改进长期推理和生成任务的效果。

我们希望向大家分享一下：引入知识图谱技术后，传统RAG链路到Graph RAG链路会有什么样的变化，如何兼容RAG中的向量数据库（Vector Database）和图数据库（Graph Database）基座，以及蚂蚁的Graph RAG开源技术方案和未来优化方向。

2. 传统RAG

首先回顾一下传统RAG的核心链路。

传统RAG的核心链路分为三个阶段：

• 索引（向量嵌入）：通过Embedding模型服务实现文档的向量编码，写入向量数据库。
• 检索（相似查询）：通过Embedding模型服务实现查询的向量编码，使用相似性查询（ANN）实现topK结果搜索。
• 生成（文档上下文）：Retriver检索的结果文档作为上下文和问题一起提交给大模型处理。

传统RAG希望通过知识库的关联知识增强大模型问答的上下文以提升生成内容质量，但也存在诸多问题。

论文[23]《Seven Failure Points…》 总结了传统RAG的7个问题：

1. 知识库内容缺失：现有的文档其实回答不了用户的问题，系统有时被误导，给出的回应其实是“胡说八道”，理想情况系统应该回应类似“抱歉，我不知道”。
2. TopK截断有用文档：和用户查询相关的文档因为相似度不足被TopK截断，本质上是相似度不能精确度量文档相关性。
3. 上下文整合丢失：从数据库中检索到包含答案的文档，因为重排序/过滤规则等策略，导致有用的文档没有被整合到上下文中。
4. 有用信息未识别：受到LLM能力限制，有价值的文档内容没有被正确识别，这通常发生在上下文中存在过多的噪音或矛盾信息时。
5. 提示词格式问题：提示词给定的指令格式出现问题，导致大模型/微调模型不能识别用户的真正意图。
6. 准确性不足：LLM没能充分利用或者过度利用了上下文的信息，比如给学生找老师首要考虑的是教育资源的信息，而不是具体确定是哪个老师。另外，当用户的提问过于笼统时，也会出现准确性不足的问题。
7. 答案不完整：仅基于上下文提供的内容生成答案，会导致回答的内容不够完整。比如问“文档 A、B和C的主流观点是什么？”，更好的方法是分别提问并总结。

总的来看：

• 问题1-3：属于知识库工程层面的问题，可以通过完善知识库、增强知识确定性、优化上下文整合策略解决。
• 问题4-6：属于大模型自身能力的问题，依赖大模型的训练和迭代。
• 问题7：属于RAG架构问题，更有前景的思路是使用Agent引入规划能力。

3. Graph RAG

考虑到传统RAG能力上的不足，Graph RAG从增强知识确定性角度做了进一步的改进，也就是最开始提到的知识内容增强的思路。相比于传统的基于Vector格式的知识库存储，Graph RAG引入了知识图谱技术，使用Graph格式存储知识。

正如论文[2]《Retrieval-Augmented Generation…》 所阐述的：基于知识图谱，可以为RAG提供高质量的上下文，以减轻模型幻觉。

Structured data, such as knowledge graphs (KGs), provide high-quality context and mitigate model hallucinations.

类似地，Graph RAG的核心链路分如下三个阶段：

• 索引（三元组抽取）：通过LLM服务实现文档的三元组提取，写入图数据库。
• 检索（子图召回）：通过LLM服务实现查询的关键词提取和泛化（大小写、别称、同义词等），并基于关键词实现子图遍历（DFS/BFS），搜索N跳以内的局部子图。
• 生成（子图上下文）：将局部子图数据格式化为文本，作为上下文和问题一起提交给大模型处理。

需要说明的是，从文本中提取三元组和关键词借助了现有的文本大模型的能力，传统的NLP技术如分词、句法分析、实体识别等已经不再是SOTA。另外，借助于大模型微调技术，可以针对性的构建面向知识抽取、实体识别、自然语言翻译的专有大模型。比如由蚂蚁和浙大联合研发的大模型知识抽取框架OneKE在零样本泛化性能上全面超过了现有模型。以及借助于Text2GQL、Text2Cypher技术微调的图查询语言专有模型，可以直接将自然语言转换为图查询语言，代替基于关键词中心的子图搜索从而获得更精确的图谱数据。

4. 通用RAG设计

基于以上对传统RAG和Graph RAG的能力介绍，我们可以发现两种RAG架构的核心差异在于知识存储格式的变化（从Vector到Graph），从而导致了RAG中索引、检索和生成阶段流转数据格式的变化。而RAG的关键流程并未发生根本的改变，基于这个相似性前提，我完全可以抽象出一个更通用的RAG结构，以兼容向量索引和图索引，甚至更多的索引格式（如全文索引等）。

4.1 架构设计

于是一个兼容多种知识索引格式的通用RAG架构，可以按照如下方式设计。

• 所有的索引存储统一抽象为IndexStore，LLM服务作为构建索引能力依赖（文本模型、嵌入模型等）。
• 索引存储当下支持向量存储（VectorStore）和知识图谱（Knowledge Graph）两种，保留对其他索引格式的扩展能力。
• 知识图谱层负责知识的表示和语义抽象，数据底座是图存储（GraphStore）。当然也可以直接对接外部的知识图谱系统。
• 最底层接入多样化的向量数据库、图数据库、大模型服务等外部组件。
• 最上层借助于IndexStore核心抽象，搭配外围的Loader/Splitter实现文本读取切分、Transformer实现索引的构建、Retriver/Synthesizer实现知识检索与合成，构建完整的RAG能力。

4.2 领域建模

建模是架构落地的第一步，这里对通用RAG的核心设计做出说明：

• 为了让框架有足够的灵活性，我们将索引的加工和存储进行了分离，并使用“桥接模式”构建抽象依赖关系。
• 索引的加工接口（Transformer）提供三类特定实现：嵌入、抽取、翻译。向量索引走嵌入的方式，如Text2Vector、OpenAI Embedding等。图索引走Extractor，如三元组抽取、关键词抽取等。翻译可以作为通用能力单独对待，承载DSL的模型微调能力，如Text2SQL、Text2GQL、Text2Cypher等。索引加工的输入是Splliter切分好的文本块（未来也可以是多模态数据），输出是索引存储系统，是连接内容和存储的桥梁。
• 索引的存储接口（IndexStore）提供了向量存储和知识图谱两类实现，知识图谱接口依赖于图存储接口，也可以单独实现。从这里也能看出图存储系统的定位是数据基座而非搜索语义，它和向量存储不在同一个架构层次。
• 大模型服务的接口设计未在图中展开，我们可以将其看做索引加工过程依赖的内部能力。

4.3 技术选型

综上所述，要构建一个完整的开源Graph RAG链路，离不开三个重要的子系统：一个可以支持RAG的AI工程框架，一个知识图谱系统和一个图存储系统。开源的AI工程框架有诸多选型：LangChain、LlamaIndex、RAGFlow、DB-GPT等。知识图谱系统有：Jena、RDF4J、Oxigraph、OpenSPG等。图存储系统有Neo4j、JanusGraph、NebulaGraph、TuGraph等。

而作为蚂蚁首个对外开源的Graph RAG框架，我们采用蚂蚁全自主的开源产品：DB-GPT + OpenSPG + TuGraph。

4.3.1 AI工程框架（@DB-GPT）

DB-GPT是一个开源的AI原生数据应用开发框架，目的是构建大模型领域的基础设施，通过开发多模型管理(SMMF)、Text2SQL效果优化、RAG框架以及优化、Multi-Agents框架协作、AWEL(智能体工作流编排)等多种技术能力，让围绕数据库构建大模型应用更简单，更方便。

4.3.2 知识图谱（@OpenSPG）

OpenSPG是蚂蚁集团结合多年金融领域多元场景知识图谱构建与应用业务经验的总结，并与OpenKG联合推出的基于SPG(Semantic-enhanced Programmable Graph)框架研发的知识图谱引擎。

4.3.3 图数据库（@TuGraph）

TuGraph是蚂蚁集团与清华大学联合研发的大规模图处理系统，构建了包含图数据库、图计算引擎、图机器学习、图研发平台的完善图技术体系。支持海量多源的关联数据的实时处理，显著提升数据分析效率，支撑了蚂蚁支付、安全、社交、公益、数据治理等300多个场景应用，多次打破图数据库性能基准测试LDBC-SNB世界纪录，并跻身IDC中国图数据库市场领导者象限。

5. 开源技术方案

在DB-GPT的v0.5.6版本中，我们提供了完整的Graph RAG框架实现（PR 1506）。接下来我们结合这个PR，阐述Graph RAG的关键实现细节。

5.1 索引

索引加工的统一抽象是TransformerBase接口，目前提供了嵌入、抽取、翻译三类转换器。而图索引的构建，则通过三元组提取器TripletExtractor来实现。

ExtractorBase接口负责信息提取的职责，当下已有的三元组提取器和关键词提取器都依赖了大模型能力，所以抽象类LLExtractor