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

• 增强训练： REALM[7]引入了知识检索器增强大模型预训练，以改进大模型的问答质量和可解释性。

• 增强微调： RA-DIT[10]实现了对大模型和检索器的双指令微调，RAFT[11]通过微调让大模型可以识别干扰文档。

• 增强语料： MuRAG[12]支持了多模态数据的检索，提升了大模型在文本/图像混合检索场景下的推理质量。

• 增强知识： GraphRAG[22]使用图社区摘要解决总结性查询任务的问题，将知识图谱技术应用到RAG。

• 增强检索： CRAG[13]通过对检索到的文档置信度进行评估，提升问答上下文的质量。

• 增强推理： RAT[8]在推理阶段将RAG与CoT相结合，以改进长期推理和生成任务的效果。

• 索引（向量嵌入）： 通过Embedding模型服务实现文档的向量编码，写入向量数据库。
• 检索（相似查询）： 通过Embedding模型服务实现查询的向量编码，使用相似性查询（ANN）实现topK结果搜索。

• 生成（文档上下文）： Retriver检索的结果文档作为上下文和问题一起提交给大模型处理。

• 知识库内容缺失： 现有的文档其实回答不了用户的问题，系统有时被误导，给出的回应其实是“胡说八道”，理想情况系统应该回应类似“抱歉，我不知道”。

• 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架构，可以按照如下方式设计。

• 所有的索引存储统一抽象为IndexStore，LLM服务作为构建索引能力依赖（文本模型、嵌入模型等）。
• 索引存储当下支持向量存储（VectorStore）和知识图谱（Knowledge Graph）两种，保留对其他索引格式的扩展能力。
• 知识图谱层负责知识的表示和语义抽象，数据底座是图存储（GraphStore）。当然也可以直接对接外部的知识图谱系统。
• 最底层接入多样化的向量数据库、图数据库、大模型服务等外部组件。

• 最上层借助于IndexStore核心抽象，搭配外围的Loader/Splitter实现文本读取切分、Transformer实现索引的构建、Retriver/Synthesizer实现知识检索与合成，构建完整的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")

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]

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"    "---------------------\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")

@abstractmethoddef 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."""

这里对接口含义做补充说明：

• subs：子图搜索的起点列表。
• direct：搜索方向，默认双向搜索，即同时探索引用和被引用关系。
• depth：搜索深度，控制图搜索的最大跳数，默认不做限制。
• fan：扇出限制，控制每一跳的最大邻居数，避免数据热点问题，默认不做限制。
• limit：结果边数限制，默认不做限制。

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}")

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())]