包阅导读总结
1. 关键词:Graph RAG、RAG、知识图谱、开源框架、大模型
2. 总结:作者设计了通用开源的RAG框架,以解决大模型推理“幻觉”问题。文中介绍了RAG的目标和链路,对比了传统RAG的问题与Graph RAG的改进,阐述了通用RAG架构的设计及关键实现细节,还提到了蚂蚁首个开源Graph RAG框架所采用的技术,并指出当前存在的不足和优化方向。
3. 主要内容:
– RAG技术介绍:
– 把信息检索与大模型结合,缓解大模型推理“幻觉”。
– 研究火热,开源框架众多,有大量工程应用。
– 传统RAG的问题:
– 知识库内容缺失等知识库工程层面问题。
– 大模型自身能力导致的问题。
– RAG架构导致的回答不完整等问题。
– Graph RAG的改进:
– 引入知识图谱技术,用Graph格式存储知识。
– 核心链路分索引、检索、生成阶段。
– 通用RAG架构设计:
– 索引加工和存储分离,用“桥接模式”构建抽象依赖关系。
– 提供嵌入、抽取、翻译三类索引加工接口。
– 提供向量存储和知识图谱两类索引存储接口。
– 蚂蚁开源Graph RAG框架:
– 采用DB-GPT、OpenSPG、TuGraph。
– 介绍了索引加工的转换器和提取器。
– 说明了索引存储的抽象接口和图存储接口。
– 指出当前体验问题和优化方向。
思维导图:
文章地址:https://mp.weixin.qq.com/s/hd2FzO2p15ERbHe0w87J8Q
文章来源:mp.weixin.qq.com
作者:范志东
发布时间:2024/6/23 10:10
语言:中文
总字数:9043字
预计阅读时间:37分钟
评分:93分
标签:RAG,Graph RAG,知识图谱,开源,蚂蚁集团
以下为原文内容
本内容来源于用户推荐转载,旨在分享知识与观点,如有侵权请联系删除 联系邮箱 media@ilingban.com
-
增强训练:REALM[7]引入了知识检索器增强大模型预训练,以改进大模型的问答质量和可解释性。
-
增强微调:RA-DIT[10]实现了对大模型和检索器的双指令微调,RAFT[11]通过微调让大模型可以识别干扰文档。
-
增强语料:MuRAG[12]支持了多模态数据的检索,提升了大模型在文本/图像混合检索场景下的推理质量。
-
增强知识:GraphRAG[22]使用图社区摘要解决总结性查询任务的问题,将知识图谱技术应用到RAG。
-
增强检索:CRAG[13]通过对检索到的文档置信度进行评估,提升问答上下文的质量。
-
增强推理:RAT[8]在推理阶段将RAG与CoT相结合,以改进长期推理和生成任务的效果。
-
知识库内容缺失:现有的文档其实回答不了用户的问题,系统有时被误导,给出的回应其实是“胡说八道”,理想情况系统应该回应类似“抱歉,我不知道”。
-
TopK截断有用文档:和用户查询相关的文档因为相似度不足被TopK截断,本质上是相似度不能精确度量文档相关性。
-
上下文整合丢失:从数据库中检索到包含答案的文档,因为重排序/过滤规则等策略,导致有用的文档没有被整合到上下文中。
-
有用信息未识别:受到LLM能力限制,有价值的文档内容没有被正确识别,这通常发生在上下文中存在过多的噪音或矛盾信息时。
-
提示词格式问题:提示词给定的指令格式出现问题,导致大模型/微调模型不能识别用户的真正意图。
-
准确性不足:LLM没能充分利用或者过度利用了上下文的信息,比如给学生找老师首要考虑的是教育资源的信息,而不是具体确定是哪个老师。另外,当用户的提问过于笼统时,也会出现准确性不足的问题。
-
答案不完整:仅基于上下文提供的内容生成答案,会导致回答的内容不够完整。比如问“文档 A、B和C的主流观点是什么?”,更好的方法是分别提问并总结。
-
问题1-3:属于知识库工程层面的问题,可以通过完善知识库、增强知识确定性、优化上下文整合策略解决。
-
问题4-6:属于大模型自身能力的问题,依赖大模型的训练和迭代。
-
问题7:属于RAG架构问题,更有前景的思路是使用Agent引入规划能力。
Structured data, such as knowledge graphs (KGs), provide high-quality context and mitigate model hallucinations.
-
索引(三元组抽取):通过LLM服务实现文档的三元组提取,写入图数据库。 -
检索(子图召回):通过LLM服务实现查询的关键词提取和泛化(大小写、别称、同义词等),并基于关键词实现子图遍历(DFS/BFS),搜索N跳以内的局部子图。 -
生成(子图上下文):将局部子图数据格式化为文本,作为上下文和问题一起提交给大模型处理。
需要说明的是,从文本中提取三元组和关键词借助了现有的文本大模型的能力,传统的NLP技术如分词、句法分析、实体识别等已经不再是SOTA。另外,借助于大模型微调技术,可以针对性的构建面向知识抽取、实体识别、自然语言翻译的专有大模型。比如由蚂蚁和浙大联合研发的大模型知识抽取框架OneKE[38]在零样本泛化性能上全面超过了现有模型。以及借助于Text2GQL、Text2Cypher技术微调的图查询语言专有模型,可以直接将自然语言转换为图查询语言,代替基于关键词中心的子图搜索从而获得更精确的图谱数据。
于是一个兼容多种知识索引格式的通用RAG架构,可以按照如下方式设计。
-
为了让框架有足够的灵活性,我们将索引的加工和存储进行了分离,并使用“桥接模式”构建抽象依赖关系。
-
索引的加工接口(Transformer)提供三类特定实现:嵌入、抽取、翻译。向量索引走嵌入的方式,如Text2Vector、OpenAI Embedding等。图索引走Extractor,如三元组抽取、关键词抽取等。翻译可以作为通用能力单独对待,承载DSL的模型微调能力,如Text2SQL、Text2GQL、Text2Cypher等。索引加工的输入是Splliter切分好的文本块(未来也可以是多模态数据),输出是索引存储系统,是连接内容和存储的桥梁。
-
索引的存储接口(IndexStore)提供了向量存储和知识图谱两类实现,知识图谱接口依赖于图存储接口,也可以单独实现。从这里也能看出图存储系统的定位是数据基座而非搜索语义,它和向量存储不在同一个架构层次。
-
大模型服务的接口设计未在图中展开,我们可以将其看做索引加工过程依赖的内部能力。
4.3.2 知识图谱(@OpenSPG)
4.3.3 图数据库(@TuGraph)
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"
)
大模型让三元组抽取变成了一件非常简单的事情,但是要提高三元组的抽取质量也不是一件容易的事情。最简单的是通过提示词工程不断优化提示词模板,让通用大模型给出更理想的答案。另外使用专有的知识抽取大模型(如OneKE)可以取得更好的效果,这部分工作还在进行中,我们期望看到OnekeExtractor的社区贡献早日发布。 索引存储的统一抽象是IndexStoreBase接口,目前提供了向量、图、全文三类索引实现。知识图谱接口KnowledgeGraphBase是Graph RAG的存储底座,目前DB-GPT内置的BuiltinKnowledgeGraph实现就是基于文本大模型能力构建的,OpenSPG的接入工作已经在逐步推进。 知识图谱提供了和向量数据库同样的接口,让知识的存取过程透明化。文档内容经过三元组解析器_triplet_extractor解析后,直接写入图存储_graph_store。 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的扩展点。 具体的图存储提供了三元组写入的实现,一般会调用图数据库的查询语言来完成。例如TuGraphStore会根据三元组生成具体的Cypher语句并执行。 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)
接口ExtractorBase的另一个实现则是关键词抽取器KeywordExtractor,负责提取用户问题中涉及的实体关键词,它也是借助大模型的能力实现的,同样继承于LLExtractor,提示词模板如下。
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"
"
"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,会根据抽取的关键词召回局部子图。 @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."""
这里对接口含义做补充说明:
-
direct:搜索方向,默认双向搜索,即同时探索引用和被引用关系。 -
depth:搜索深度,控制图搜索的最大跳数,默认不做限制。 -
fan:扇出限制,控制每一跳的最大邻居数,避免数据热点问题,默认不做限制。
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}"
)
和其他向量数据库类似,BuiltinKnowledgeGraph同样实现了IndexStoreBase的相似性查询接口。 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")
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数据结构原生的理解基础上,我们相信这是当下主流大模型的基本能力。 我们使用《变形金刚》的故事材料tranformers_story.md[49]作为测试文本,验证DB-GPT上Graph RAG的效果。具体操作手册见DB-GPT的文档《Graph RAG User Manual》[31]。 启动DB-GPT后,新增Knowledge Space,选择Knowledge Graph存储类型。上传tranformers_story.md后切片自动构建图索引。 其实大家在对DB-GPT上Graph RAG实现进行初步的测试后,会发现当下仍有不少体验问题。不避讳的讲,这里除了功能完善度的原因之外,还有Graph RAG自身设计上的不足,这也为后续的进一步优化方向提供了思路。 GraphRAG, like RAG, has clear limitations, which include how to form graphs, generate queries for querying these graphs, and ultimately decide how much information to retrieve based on these queries. The main challenges are ‘query generation’, ‘reasoning boundary’, and ‘information extraction’.
像前边提到的,知识抽取/关键词/查询语言的微调模型主要专注于信息抽取和查询生成。另外,论文[24]实现的基于图的推理增强框架(RoG)则是在推理边界方向尝试的创新(思路有点类似RAT): 当然上述三个阶段也可以被简化合并为两个阶段:内容索引阶段和检索生成阶段。我们就这两个大的阶段分别讨论Graph RAG后续可能的优化方向和思路。 Graph RAG的内容索引阶段主要目标便是构建高质量的知识图谱,值得继续探索的有以下方向:
-
图谱元数据:从文本到知识图谱,是从非结构化信息到结构化信息的转换的过程,虽然图一直被当做半结构化数据,但有结构的LPG(Labeled Property Graph)除了有利于图存储系统的性能优化,还可以协助大模型更好地理解知识图谱的语义,帮助其生成更准确的查询。
-
知识抽取微调:通用大模型在三元组的识别上实际测试下来仍达不到理想预期,针对知识抽取的微调模型反而表现出更好地效果,如前面提到的OneKE。
-
图社区总结:这部分源自于微软的Graph RAG的研究工作,通过构建知识图谱时生成图社区摘要,以解决知识图谱在面向总结性查询时“束手无策”的问题。另外,同时结合图社区总结与子图明细可以生成更高质量的上下文。
-
多模态知识图谱:多模态知识图谱可以大幅扩展Graph RAG知识库的内容丰富度,对客观世界的数据更加友好,浙大的MyGO[37]框架提出的方法提升MMKGC(Multi-modal Knowledge Graph Completion)的准确性和可靠性。Graph RAG可以借助于MMKG(Multi-modal Knowledge Graph)和MLLM(Multi-modal Large Language Model)实现更全面的多模态RAG能力。
-
混合存储:同时使用向量/图等多种存储系统,结合传统RAG和Graph各自的优点,组成混合RAG。参考文章[27]提出的多种Graph RAG架构,如图学习语义聚类、图谱向量双上下文增强、向量增强图谱搜索、混合检索、图谱增强向量搜索等,可以充分利用不同存储的优势提升检索质量。
Graph RAG的检索生成阶段主要目标便是从知识图谱上召回高质量上下文,值得继续探索的有以下方向:
-
图语言微调:使用自然语言在知识图谱上做召回,除了基本的关键词搜索方式,还可以尝试使用图查询语言微调模型,直接将自然语言翻译为图查询语句,这里需要结合图谱的元数据以获得更准确的翻译结果。过去,我们在Text2GQL上做了一些初步的工作。
-
混合RAG:这部分与前边讲过的混合存储是一体的,借助于底层的向量/图/全文索引,结合关键词/自然语言/图语言多种检索形式,针对不同的业务场景,探索高质量Graph RAG上下文的构建。
-
测试验证:Graph RAG的测试和验证可以参考传统RAG的Benchmark方案,如RAGAS[32]、ARES[35]、RECALL[36]、RGB[33]、CRUD-RAG[34]等。
-
RAG智能体:从某种意义上说,RAG其实是Agent的简化形式(知识库可以看到Agent的检索工具),同时当下我们也看到RAG对记忆和规划能力的集成诉求(如RAT/RoG等),因此未来RAG向带有记忆和规划能力的智能体架构演进几乎是必然趋势。另外,Agent自身需要的长期记忆存储也会反向依赖RAG的知识库,所以RAG与Agent其实是相辅相成、互相促进的。
TuGraph-DB 图数据库: