检索增强生成技术（RAG）概述

1. 背景与意义检索增强生成（Retrieval Augmented Generation，简称RAG）技术是一种结合信息检索与大型语言模型的创新方法。该技术致力于解决大型模型在推理过程中可能出现的不准确问题，即所谓的“幻觉”问题。

2. 技术原理RAG技术的核心在于利用知识库来提升内容生成的质量。它通过检索相关文档，并将其作为上下文信息，一并提供给大型语言模型，以生成更为可靠的答案。

3. 技术应用RAG技术的应用范围广泛，可以与多种技术相结合，例如：

提示词工程（Prompt Engineering）：通过精心设计的提示词来引导模型生成更准确的回答。
模型微调（Fine Tuning）：针对特定领域或任务对模型进行进一步训练，以提高其性能。
知识图谱（Knowledge Graph）：构建和利用丰富的知识结构来辅助模型理解问题和生成答案。

4. 开源框架我们设计了一个通用的开源RAG框架，旨在满足未来多样化的基础研究和工程化应用需求。该框架具有高度的兼容性和扩展性，能够适应不同的研究和应用场景。

5. 结论RAG技术的发展为AI领域带来了新的机遇和挑战。随着研究的深入和开源框架的推广，我们期待RAG技术能够在专业领域的AI工程应用中发挥更大的作用。

检索增强型生成（Retrieval-Augmented Generation, RAG）是一种将检索技术与生成模型结合的方法，旨在提升大型语言模型在问答等任务中的性能。以下是对RAG理念及其在不同阶段的泛化应用的综述。

增强训练

REALM：通过引入知识检索器，增强了大模型的预训练过程，提高了问答质量和可解释性。

增强微调

RA-DIT：实现了对大模型和检索器的双指令微调，提升了模型性能。
RAFT：通过微调让大模型能够识别干扰文档，优化了模型的检索能力。

增强语料

MuRAG：支持多模态数据检索，提升了模型在文本/图像混合检索场景下的推理质量。

增强知识

GraphRAG：利用图社区摘要技术，解决了总结性查询任务的挑战，将知识图谱技术应用于RAG。

增强检索

CRAG：通过评估检索文档的置信度，提升了问答上下文的质量。

增强推理

RAT：结合RAG与CoT（Chain of Thought）推理方法，改进了长期推理和生成任务的效果。

Graph RAG与传统RAG的比较引入知识图谱技术后，Graph RAG在传统RAG的基础上进行了以下变化：

图数据库集成：与传统RAG相比，Graph RAG集成了图数据库，用于存储和管理知识图谱。
社区检测：Graph RAG利用社区检测算法对知识图谱进行划分，形成模块化的社区结构。
查询聚焦摘要：针对总结性查询，Graph RAG通过社区摘要生成全局答案，提升了答案的全面性和多样性。

技术方案与未来优化

蚂蚁Graph RAG：提供了一个开源的Graph RAG技术方案，支持对私有文本库的查询聚焦摘要。
向量数据库与图数据库兼容：Graph RAG能够与RAG中的向量数据库协同工作，实现高效的检索和知识管理。
未来优化方向：包括提升社区检测算法的效率，优化知识图谱的构建和更新流程，以及增强模型对于复杂查询的处理能力。以上是对广义RAG理念及其在不同应用阶段的详细介绍，展示了从传统RAG到Graph RAG的演进及其技术实现。

在探索RAG（Retrieval-Augmented Generation）模型的优化过程中，我们发现传统的RAG模型主要包含三个关键环节：

索引阶段：首先，通过Embedding技术将文档转化为向量形式，并将这些向量存储在向量数据库中。这一步骤是实现文档向量化的基础。
检索阶段：其次，利用Embedding模型对查询进行向量化处理，并通过近似最近邻（ANN）算法进行相似性搜索，以快速找到与查询最相关的topK个文档。
生成阶段：最后，将检索得到的文档作为上下文信息，与问题一起输入到大型语言模型中，以生成更加准确和丰富的回答。尽管RAG模型通过结合知识库中的相关信息来增强语言模型的问答能力，但传统RAG模型在实际应用中仍面临一些挑战和问题。

传统RAG的不足

传统RAG存在多个问题，根据论文[23]《Seven Failure Points…》的总结，我们可以将这些问题归纳为以下几类：

知识库工程层面的问题

知识库内容缺失：当现有文档无法回答用户问题时，系统可能会给出不准确的回答。理想情况下，系统应该能够识别并回应“抱歉，我不知道”。
TopK截断有用文档：相似度计算不精确导致与查询相关的文档被截断，需要改进相似度度量方法。
上下文整合丢失：检索到的有用文档可能因为重排序或过滤策略而未被整合到上下文中。

大模型自身能力的问题

有用信息未识别：由于LLM能力限制，有价值的文档内容可能未被正确识别，尤其在上下文存在噪音或矛盾信息时。
提示词格式问题：提示词格式不当可能导致模型无法识别用户真正意图。
准确性不足：LLM在利用上下文信息时可能存在不足或过度，导致答案不准确。

RAG架构问题

答案不完整：仅基于上下文生成答案可能导致回答内容不完整，需要更全面的提问和总结策略。

Graph RAG的改进

为了解决传统RAG的问题，Graph RAG引入了知识图谱技术，通过Graph格式存储知识，增强了知识确定性。如论文[2所指出的，知识图谱可以提供高质量的上下文，减轻模型幻觉。

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

Graph RAG的优势

知识内容增强：使用知识图谱技术，Graph RAG能够提供更准确的知识内容。
高质量上下文：基于知识图谱，Graph RAG能够生成更高质量的上下文，提高回答的准确性和完整性。通过这些改进，Graph RAG有望在知识检索和生成方面提供更可靠的性能。

在构建基于Graph的RAG链路时，我们可以将整个流程分为三个主要阶段，每个阶段都紧密依赖于先进的LLM（Large Language Model）服务。以下是这三个阶段的详细描述：

索引阶段（三元组抽取）：在这个阶段，我们利用大型语言模型来处理文档，并从中提取关键的三元组信息。这些信息随后被存储到图数据库中，为后续的检索和生成阶段打下基础。
检索阶段（子图召回）：此阶段的核心任务是通过LLM服务提取查询中的关键词，并进行必要的泛化处理，比如统一大小写、识别别称和同义词等。基于这些关键词，我们执行图数据库中的子图遍历操作，比如深度优先搜索（DFS）或广度优先搜索（BFS），以搜索N跳范围内的局部子图。
生成阶段（子图上下文）：在这个阶段，我们将检索到的局部子图数据转换为文本格式，与问题一起作为上下文提交给大型语言模型进行处理。特别指出，文本中的三元组和关键词提取已经不再依赖于传统的NLP技术，如分词、句法分析和实体识别，而是通过现有的文本大模型能力实现。此外，通过大模型微调技术，我们可以构建专门针对知识抽取、实体识别和自然语言翻译的定制化大型模型。例如，蚂蚁集团和浙江大学联合研发的OneKE框架，在零样本泛化性能上已经超越了现有模型。同时，通过Text2GQL和Text2Cypher技术的微调，我们可以将自然语言直接转换为图查询语言，从而实现更为精确的图谱数据检索。

OneKE知识抽取模型能力透视

4. 通用RAG设计

在对传统RAG和Graph RAG进行能力分析后，我们认识到两种架构的核心差异在于知识存储的格式，即从Vector转变为Graph。这种变化导致了RAG在索引、检索和生成阶段的数据流转格式发生了变化。然而，RAG的关键流程并没有根本性变化，这为我们提供了抽象出一种更通用的RAG结构的可能性，以适应向量索引、图索引，甚至全文索引等多种索引格式。

4.1 架构设计

一个能够兼容多种知识索引格式的通用RAG架构，可以按照以下方式设计：

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

注意事项

索引存储的设计应具有高度的抽象性和扩展性，以适应未来可能的索引格式。
知识图谱层的设计应注重语义的准确性和知识的丰富性。
底层组件的选择应考虑性能、稳定性以及与现有系统的兼容性。
上层构建应确保灵活性和可维护性，以支持快速迭代和功能扩展。以上是对OneKE知识抽取模型通用RAG设计的一个概述，旨在提供一个结构化和条理化的视角，以指导实际的系统设计和开发。

通用RAG架构领域建模概述

在本节中，我们将对通用RAG架构的核心设计进行详细说明，以确保架构的灵活性和实用性。以下是对领域建模的要点概述：

索引加工与存储的分离我们采用了桥接模式来构建索引加工和存储的抽象依赖关系，以提高框架的灵活性。

索引加工接口（Transformer）

嵌入：适用于向量索引的加工，例如Text2Vector、OpenAI Embedding等。
抽取：适用于图索引的加工，如三元组抽取、关键词抽取等。
翻译：作为通用能力，承载DSL的模型微调能力，例如Text2SQL、Text2GQL、Text2Cypher等。

输入与输出

输入：由Splliter切分好的文本块，未来可能扩展至多模态数据。
输出：索引存储系统，作为内容与存储之间的桥梁。

索引存储接口（IndexStore）索引存储接口提供两种实现方式：

向量存储：用于存储向量形式的数据。
知识图谱：依赖于图存储接口，也可以独立实现。知识图谱的定位是作为数据基座，而非搜索语义，与向量存储位于不同的架构层次。

大模型服务接口虽然图中未展开大模型服务的接口设计，但它是索引加工过程中依赖的内部能力。

结构性与条理性

内容组织清晰，逻辑性强，便于理解和实施。
通过使用Markdown格式，增强了文档的可读性和专业性。以上是对通用RAG架构领域建模的重新编写，以确保内容的条理性和结构性。

构建开源Graph RAG链路的技术选型

1. 引言在构建一个高效的Graph RAG（Retrieval-Augmented Generation）链路时，我们需考虑三个核心组件：AI工程框架、知识图谱系统和图存储系统。本文将探讨这些组件的开源选型。

2. AI工程框架AI工程框架是实现RAG功能的基础。以下是一些流行的开源AI工程框架：

LangChain：提供一个自动化工作流的平台。
LlamaIndex：为LLM（Large Language Models）应用提供数据框架。
RAGFlow：基于深度文档理解的开源RAG引擎。
DB-GPT：结合AWEL（Agentic Workflow Expression Language）和智能代理的AI原生数据应用开发框架。

3. 知识图谱系统知识图谱系统是存储和查询知识的关键组件。以下是一些可用的开源知识图谱系统：

Jena：Apache基金会支持的成熟知识图谱系统。
RDF4J：Eclipse基金会支持的RDF（Resource Description Framework）处理工具。
Oxigraph：SPARQL图数据库。
OpenSPG：一个高性能的图数据库。

4. 图存储系统图存储系统负责存储和管理图数据。以下是一些流行的开源图存储系统：

Neo4j：广泛使用的图形数据库，提供丰富的图数据处理功能。
JanusGraph：一个可扩展的图数据库，支持多种存储后端。
NebulaGraph：一个分布式图数据库，适用于处理大规模数据集。
TuGraph：由蚂蚁集团开发的高性能图数据库。

5. 蚂蚁集团的开源Graph RAG框架蚂蚁集团首次对外开源的Graph RAG框架，采用了以下自主开源产品组合：

DB-GPT：作为AI工程框架的核心。
OpenSPG：作为知识图谱系统的选型。
TuGraph：作为图存储系统的选型。这种组合旨在提供一个高效、可扩展且功能丰富的Graph RAG解决方案。

6. 结语选择正确的技术栈对于构建成功的Graph RAG链路至关重要。通过上述讨论，我们可以看到开源社区提供了多种选择，可以根据项目需求和技术偏好进行定制。

蚂蚁Graph RAG开源方案

4.3.1 AI工程框架

DB-GPT 是一个致力于构建大模型领域基础设施的开源AI原生数据应用开发框架。它通过以下关键技术能力，简化并优化了围绕数据库构建大模型应用的流程：

多模型管理(SMMF)：为大模型提供统一的管理和调度能力。
Text2SQL效果优化：提升文本到SQL查询的转换效率和准确性。
RAG框架优化：增强RAG（Retrieval-Augmented Generation）框架的性能，使其更适合大模型场景。
Multi-Agents框架协作：实现多个智能体的协同工作，提升整体系统效率。
AWEL（智能体工作流编排）：通过智能体工作流编排，优化大模型应用的工作流程。 DB-GPT框架的开源特性，为开发者提供了一个灵活、高效的平台，以支持他们在大模型领域的创新和应用开发。

DB-GPT技术架构

4.3.2 知识图谱（@OpenSPG）

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

4.3.3 图数据库技术

TuGraph TuGraph 是由蚂蚁集团与清华大学联合研发的先进图处理系统，它构建了一个全面的图技术体系，包括以下几个核心组件：
图数据库：提供对大规模图数据的存储和管理。
图计算引擎：支持高效的图数据计算。
图机器学习：集成了图算法的机器学习模型。
图研发平台：为开发者提供易于使用的图数据处理工具。 TuGraph 系统能够处理海量多源的关联数据，并实现了实时数据处理功能，这大大提升了数据分析的效率。它在蚂蚁集团内部的多个业务场景中发挥着重要作用，包括但不限于：
支付系统
安全监控
社交网络分析
公益项目
数据治理 TuGraph 的卓越性能已经在多个领域得到验证。它不仅多次刷新了图数据库性能基准测试 LDBC-SNB 的世界纪录，而且在 IDC 的中国图数据库市场领导者象限中占据了一席之地。 TuGraph 的成功应用和性能表现，证明了其在大规模图数据处理和分析领域的领先地位。

TuGraph技术架构分析

5. 开源技术方案概述

在DB-GPT的v0.5.6版本中，引入了Graph RAG框架的完整实现，具体可见PR 1506。以下是对Graph RAG框架关键实现细节的阐述。

功能集成

TuGraph数据库支持：新增了对TuGraph数据库的使用，该数据库支持检索增强型生成（RAG）。
版本要求：TuGraph从4.3.0及以上版本被支持。

知识库创建

存储类型选择：用户在创建知识库时，可在以下两种存储类型中选择：
知识图谱（Knowledge Graph）
向量存储（Vector Store）
前端显示：不同存储类型在前端将显示相应的图标。

知识图谱视图

图谱查看：若用户选择创建知识图谱类型的知识库，并成功创建后，可通过点击“View Graph”按钮查看当前知识库的图谱。

聊天知识获取

对话功能：用户可通过聊天知识对话功能获取相关知识内容。

图形界面展示

知识创建：展示知识创建的界面截图。
知识图谱与开放图谱视觉：展示知识图谱和开放图谱的视觉界面截图。
图形可视化页面：展示图形的可视化页面截图。
基于图谱的聊天知识：展示通过图谱进行聊天知识获取的界面截图。以上是对DB-GPT中Graph RAG框架实现的概述。

PR-1506：DB-GPT支持了Graph RAG框架

5.1 索引

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

TransformerBase接口继承树概述

1. 信息提取职责`ExtractorBase`接口承担着信息提取的重任。目前，已有的三元组提取器和关键词提取器均依赖于大型语言模型（LLM）的能力。

2. 抽象类LLExtractor`LLExtractor`是一个抽象类，它负责处理与大型语言模型交互的公共逻辑。这意味着，具体的实现类只需提供提示词模板和结果解析机制。

3. 提示词模板三元组提取器`TripletExtractor`的提示词模板受到LlamaIndex的启发。其核心理念是利用少量样本（few-shot samples）引导大型语言模型生成三元组结构。

4. 结果解析结果解析是实现类的关键部分，它负责将大型语言模型的输出转换为所需的信息格式。

5. 接口与类的关系

ExtractorBase接口定义了信息提取的基本方法和属性。
LLExtractor抽象类实现了与大型语言模型的交互逻辑。
TripletExtractor是具体的实现类，它提供了特定于三元组提取的提示词模板和结果解析。这种设计模式允许开发者通过继承和实现特定的类和接口，来扩展和定制信息提取的功能。

1

TRIPLET_EXTRACT_PT = ( "Some text is provided below. Given the text, " "extract up to knowledge triplets as more as possible " "in the form of (subject, predicate, object).\n" "Avoid stopwords.\n" "---------------------\n" "Example:\n" "Text: Alice is Bob's mother.\n" "Triplets:\n(Alice, is mother of, Bob)\n" ...TL;DR... "Text: Philz is a coffee shop founded in Berkeley in 1982.\n" "Triplets:(Philz, is, coffee shop)\n(Philz, founded in, Berkeley)\n(Philz, founded in, 1982)\n" "---------------------\n" "Text: {text}\n" "Triplets:\n" )

三元组抽取与知识抽取技术

三元组抽取是知识抽取领域的关键技术之一，它能够从文本中识别并提取实体及其关系，形成知识三元组。虽然大模型的引入简化了这一过程，但要提升其准确性和质量，仍需深入研究和优化。

提升三元组抽取质量的策略

1. 提示词工程通过精心设计的提示词模板，可以引导通用大模型更准确地抽取三元组。这需要不断地测试和调整，以找到最优的提示词组合。

2. 专有知识抽取模型使用特定于知识抽取任务的大模型，如OneKE，可以显著提升抽取效果。目前，我们正在期待OneKE社区贡献的早日发布，以进一步推动这一技术的发展。

知识图谱的存储与索引

索引存储索引存储的统一抽象通过`IndexStoreBase`接口实现，目前支持向量、图和全文三种类型的索引。

知识图谱接口`KnowledgeGraphBase`作为Graph RAG存储的基础，提供了与知识图谱交互的能力。DB-GPT内置的`BuiltinKnowledgeGraph`实现利用了文本大模型的能力。

存储实现进展目前，`OpenSPG`的接入工作正在逐步推进，这将为知识图谱的存储和索引提供更多的选择和灵活性。

结语通过不断的技术创新和社区贡献，我们相信知识抽取技术将不断进步，为构建更加智能的知识系统打下坚实的基础。

IndexStoreBase接口的继承树

知识图谱提供了和向量数据库同样的接口，让知识的存取过程透明化。文档内容经过三元组解析器_triplet_extractor解析后，直接写入图存储_graph_store。

1

async def aload_document(self, chunks: List[Chunk]) -> List[str]: """Extract and persist triplets to graph store. Args: chunks: List[Chunk]: document chunks. Return: List[str]: chunk ids. """ for chunk in chunks: triplets = await self._triplet_extractor.extract(chunk.content) for triplet in triplets: self._graph_store.insert_triplet(*triplet) logger.info(f"load {len(triplets)} triplets from chunk {chunk.chunk_id}") return [chunk.chunk_id for chunk in chunks]

图存储接口GraphStoreBase提供统一的图存储抽象，目前内置了MemoryGraphStore和TuGraphStore的实现，分别用于本地测试和生产部署，并预留了Neo4jStore的扩展点。

GraphStoreBase接口的继承树

具体的图存储提供了三元组写入的实现，一般会调用图数据库的查询语言来完成。例如TuGraphStore会根据三元组生成具体的Cypher语句并执行。

1

def insert_triplet(self, subj: str, rel: str, obj: str) -> None: """Add triplet.""" ...TL;DR... subj_query = f"MERGE (n1:{self._node_label} {{id:'{subj}'}})" obj_query = f"MERGE (n1:{self._node_label} {{id:'{obj}'}})" rel_query = ( f"MERGE (n1:{self._node_label} {{id:'{subj}'}})" f"-[r:{self._edge_label} {{id:'{rel}'}}]->" f"(n2:{self._node_label} {{id:'{obj}'}})" ) self.conn.run(query=subj_query) self.conn.run(query=obj_query) self.conn.run(query=rel_query)

5.3 检索

接口ExtractorBase的另一个实现则是关键词抽取器KeywordExtractor，负责提取用户问题中涉及的实体关键词，它也是借助大模型的能力实现的，同样继承于LLExtractor，提示词模板如下。

1

KEYWORD_EXTRACT_PT = ( "A question is provided below. Given the question, extract up to " "keywords from the text. Focus on extracting the keywords that we can use " "to best lookup answers to the question.\n" "Generate as more as possible synonyms or alias of the keywords " "considering possible cases of capitalization, pluralization, " "common expressions, etc.\n" "Avoid stopwords.\n" "Provide the keywords and synonyms in comma-separated format." "Formatted keywords and synonyms text should be separated by a semicolon.\n" "---------------------\n" "Example:\n" "Text: Alice is Bob's mother.\n" "Keywords:\nAlice,mother,Bob;mummy\n" "Text: Philz is a coffee shop founded in Berkeley in 1982.\n" "Keywords:\nPhilz,coffee shop,Berkeley,1982;coffee bar,coffee house\n" "---------------------\n" "Text: {text}\n" "Keywords:\n" )

关键词抽取是文本分析中的一个关键技术，它涉及到实体识别等多个方面。为了提高关键词抽取的准确性，需要综合考虑多种因素，如单词的大小写、别称、同义词等。这为系统提供了进一步优化的空间。此外，将自然语言直接翻译为图查询语句，通过模型微调的方式，也是一个值得深入研究的方向。在图存储技术方面，GraphStoreBase接口提供了一个基于关键词的探索功能，名为explore。该功能能够根据识别出的关键词，快速地检索并返回相关的局部子图，为用户在图数据中进行信息探索提供了便利。

1

@abstractmethod def explore( self, subs: List[str], direct: Direction = Direction.BOTH, depth: Optional[int] = None, fan: Optional[int] = None, limit: Optional[int] = None, ) -> Graph: """Explore on graph."""

在TuGraph系统中，explore接口是一个关键功能，它允许用户对图数据进行深度搜索。以下是对explore接口参数的详细说明，以及如何将这些参数转化为Cypher查询语句的基本逻辑：

子图搜索起点 (subs): 定义了搜索的起始节点列表。这些节点将作为搜索的起始点，从它们开始进行图的遍历。
搜索方向 (direct): 指定了搜索的方向。默认情况下，搜索是双向的，即同时探索节点的引用和被引用关系。
搜索深度 (depth): 控制了搜索的最大跳数，也就是从起始点出发能够遍历的最大距离。默认情况下，搜索深度没有限制。
扇出限制 (fan): 用于限制每一跳中的最大邻居数。这是为了避免在数据中出现热点问题，即某些节点由于连接数过多而导致的搜索效率降低。默认情况下，没有扇出限制。
结果边数限制 (limit): 限制了返回结果中的边数。如果未设置，返回的结果边数将没有限制。
返回值: 搜索完成后，会返回一个Graph接口类型的子图。这个子图提供了一些便捷的API，用于对图中的节点和边进行更新操作。将上述参数转化为Cypher查询语句的过程是explore接口的核心逻辑。Cypher是一种声明式的图查询语言，用于在图数据库中执行复杂的查询和操作。在实际使用中，用户需要根据具体的搜索需求，合理设置这些参数，以确保查询的效率和准确性。

1

query = ( f"MATCH p=(n:{self._node_label})" f"-[r:{self._edge_label}*1..{depth}]-(m:{self._node_label}) " f"WHERE n.id IN {subs} RETURN p LIMIT {limit}" )

5.4 生成

和其他向量数据库类似，BuiltinKnowledgeGraph同样实现了IndexStoreBase的相似性查询接口。

1

async def asimilar_search_with_scores( self, text, topk, score_threshold: float, filters: Optional[MetadataFilters] = None, ) -> List[Chunk]: """Search neighbours on knowledge graph.""" if not filters: logger.info("Filters on knowledge graph not supported yet") # extract keywords and explore graph store keywords = await self._keyword_extractor.extract(text) subgraph = self._graph_store.explore(keywords, limit=topk) logger.info(f"Search subgraph from {len(keywords)} keywords") content = ( "The following vertices and edges data after [Subgraph Data] " "are retrieved from the knowledge graph based on the keywords:\n" f"Keywords:\n{','.join(keywords)}\n" "---------------------\n" "You can refer to the sample vertices and edges to understand " "the real knowledge graph data provided by [Subgraph Data].\n" "Sample vertices:\n" "(alice)\n" "Sample edges:\n" "(alice)-[reward]->(alice)\n" "---------------------\n" f"Subgraph Data:\n{subgraph.format()}\n" ) return [Chunk(content=content, metadata=subgraph.schema())]

关键词抽取器_keyword_extractor负责从文本中识别关键词。这些关键词随后被传递给图存储对象_graph_store，以进行子图探索。探索过程将生成的结果子图，直接格式化并整合到提示词上下文字符串content中。细心的读者可能注意到，子图探索的输出是封装为Graph接口类型的实例。此外，我们还提供了一个MemoryGraph工具类来实现这一接口。这样的设计意味着在实现图探索接口时，无需将查询结果转换为Path或Table等格式，这些格式在内存使用上可能不够高效。同时，这也减少了在提示词中编码子图数据所需的token数量。这种设计选择基于对大模型对Graph数据结构的原生理解能力的信任，我们相信这是目前主流大模型所具备的基本能力。

变形金刚宇宙编年史

创世篇

亿万年前，一个自称为“创造者”的神秘机械种族在宇宙中不断尝试创造生命。他们使用一种分子武器，将有机生命的星球表面转化为“变形金”，这是一种特殊的金属，能够用来创造和修复硅基生命形式。利用收集到的变形金，创造者们制造了赛博坦星球，并很快发展了“立方体”来为其提供动力，创造了一个有感知的机械生命种族。这些生命自称赛博坦人，并将“立方体”视为他们创造的神圣之物，命名为“全息核心”。

赛博坦的崛起

赛博坦人中，由“全息核心”直接创造的七位“元祖”联手建立了“元祖王朝”，统一了整个赛博坦。与他们的后代不同，七位“元祖”没有变形能力，但由于他们是由“立方体”直接创造的，他们的能力远超其他赛博坦人。

宇宙的扩张与冲突

在构建赛博坦之前，“创造者”还实验性地建造了另一个巨大的机械金属星球，由于实验失败，它变得自我意识——后来被称为“独角兽”。在“元祖王朝”的早期，与“独角兽”的持续战斗中，最终七位“元祖”利用“全息核心”的力量击败了“独角兽”，并将其意识隔离，将其身体推向银河系的边缘。

地球与赛博坦的诞生

6500万年前，“创造者”访问了太阳系，使用分子武器在地球表面创造大量变形金。在这个过程中，“创造者”之一的“昆特莎”也利用太阳能创造了另一批硅基生命形式，它们能够模仿地球上的恐龙并随意变形。其中一些成为了后来的“恐龙金刚”，而另一些则被选为昆特莎的守护者，“艾康骑士”。

赛博坦的内战与地球的危机2500年前，七位“元祖”之一的“麦格特朗斯元祖”不满于其他六位兄弟保守的扩张政策，开始秘密招募志同道合者，称他们为“霸天虎”，其中最信任的是“天火”和“威震天”。

现代篇2007年，坠落的“堕落金刚”（麦格特朗斯元祖）从他的石棺监狱逃脱，相信擎天柱可能会将“全息核心”送往地球，于是召唤霸天虎潜入地球调查威震天的下落。与此同时，山姆·维特维奇无意中购买了一辆实际上是大黄蜂伪装的老款雪佛兰卡玛洛。在大黄蜂的帮助下，山姆躲避了霸天虎的追捕，并决定帮助汽车人找到“全息核心”。

未来展望2022年，经过连续的赛博坦人入侵，“独角兽”——地球的核心开始觉醒，世界各地出现了巨大的角状物，并逐渐增长。擎天柱前往赛博坦面对创造者，被昆特莎立即制服并洗脑，变成了堕落战士“复仇女神擎天柱”。

结语在地球和赛博坦的未来仍然充满不确定性之际，汽车人和霸天虎的斗争远未结束。昆特莎的计划虽然暂时被挫败，但她仍然在地球上以人类的身份继续执行她的计划。

创建知识图谱

构建好的知识图谱支持快速预览。

知识图谱预览

基于知识图谱的对话测试。

在对DB-GPT上的Graph RAG实现进行初步测试后，我们发现了一些体验上的问题。这些问题不仅源于功能完善度的不足，还与Graph RAG的设计本身有关。以下是针对Graph RAG的不足之处，以及未来优化方向的概述：

优化方向

信息抽取：构建高质量的知识图谱是关键。我们需要探索如何更有效地从不同来源抽取信息，并将其组织成结构化的知识。
查询生成：在知识图谱上生成有效的查询同样重要。这涉及到如何设计查询语言，以及如何根据用户需求生成合适的查询。
推理边界：合理限制查询结果的规模是另一个挑战。我们需要确定如何平衡查询的深度和广度，以避免信息过载。

现有问题

文章[26]《From RAG to GraphRAG…》指出了Graph RAG的明显局限性，包括：

查询生成：如何形成有效的查询来查询知识图谱。
推理边界：如何确定基于查询应检索的信息量。
信息提取：如何从查询结果中提取有价值的信息。

创新尝试

论文[24]《Reasoning on Graphs…》提出了一种基于图的推理增强框架（RoG），它在推理边界方面进行了创新尝试，与RAT的思路相似：

RoG框架：通过增强基于图的推理，RoG框架旨在改进查询结果的质量和规模控制。通过这些优化方向和创新尝试，我们可以期待Graph RAG在未来能够提供更加精准和高效的知识检索体验。

在探讨Graph RAG的优化方向时，我们可以将其分为两个主要阶段：内容索引和检索生成。以下是对这两个阶段的深入分析和可能的优化策略。

内容索引阶段

构建高质量的知识图谱是内容索引阶段的核心目标。以下是一些值得探索的优化方向：

图谱元数据优化

结构化的Labeled Property Graph（LPG）有助于图存储系统的性能提升，并能增强大模型对知识图谱语义的理解，从而生成更准确的查询。

知识抽取微调

针对知识抽取任务的微调模型，如OneKE，相较于通用大模型，在三元组识别上表现出更佳的效果。

图社区总结

借鉴微软Graph RAG研究，通过生成图社区摘要来应对知识图谱在总结性查询中的不足，同时结合子图明细以生成更丰富的上下文。

多模态知识图谱

引入多模态知识图谱（MMKG），如浙大提出的MyGO框架，能显著提升MMKGC的准确性和可靠性，进而增强Graph RAG的知识库内容丰富度。

混合存储系统

结合向量和图等多种存储系统的优势，构建混合RAG，参考文章[27]《GraphRAG: Design Patterns…》提出的架构，如语义聚类、向量双上下文增强等，以提升检索质量。

检索生成阶段

此阶段重点讨论如何利用构建好的知识图谱进行有效的信息检索和内容生成，具体策略待进一步分析。

总结

Graph RAG作为一个动态的系统，需要不断地在内容索引和检索生成两个阶段进行优化和迭代，以适应不断变化的信息需求和提升用户体验。

图 RAG 技术演进与应用探索

图 RAG（Retrieval-Augmented Generation）技术是结合了知识图谱与大型语言模型的先进方法，旨在提高信息检索与生成的准确性和可靠性。本文将探讨图 RAG 的关键技术阶段，并展望其未来的发展方向。

6.2 检索生成阶段的探索方向

在图 RAG 的检索生成阶段，我们关注以下几个值得探索的方向：

图语言微调：利用自然语言在知识图谱上进行检索，通过图查询语言对模型进行微调，以实现更准确的翻译结果。
混合 RAG：结合多种检索方式，包括关键词、自然语言和图语言，以适应不同的业务场景。
测试验证：参考传统 RAG 的 Benchmark 方案，如 RAGAS、ARES、RECALL 等，进行系统测试和验证。
RAG 智能体：预见 RAG 向具有记忆和规划能力的智能体架构演进的趋势，并探讨 RAG 与 Agent 的相辅相成关系。

7. 总结

本文介绍了从 RAG 到 Graph RAG 的技术演进，并提出了一个通用的 RAG 框架，该框架支持多种索引形式，并在开源技术中实现。同时，探讨了 Graph RAG 未来的优化方向，以及 RAG 向 Agent 架构演化的可能性。

8. 参考资料

以下是关于图 RAG 技术的相关参考资料链接，涵盖了从理论到实践的多个方面。

RALM_Survey
Retrieval-Augmented Generation for Large Language Models: A Survey
A Survey on Retrieval-Augmented Text Generation for Large Language Models …（此处省略其他参考资料链接，以符合内容长度要求）注意：请根据上文内容，使用 Markdown 格式编写结构化和条理化的新内容，并将特定词替换为 aaaaaaa。

文章目录