从RAG到GraphRAG:知识检索的范式跃迁

向量检索的天花板 传统RAG系统依赖向量相似度检索,在简单事实问答场景表现出色。但当问题涉及多跳推理、跨文档关联或全局性总结时,纯向量检索就显得力不从心。 比如"公司A的CEO曾在哪家公司任职,那家公司又被谁收购了"这样的问题,需要跨多个文档片段进行链式推理。向量检索只能找到语义相似的片段,无法构建这种实体间的关联路径。 这就是GraphRAG登场的背景。 GraphRAG的核心思路 GraphRAG的核心创新在于:在传统的向量索引之上,叠加一层知识图谱索引。具体流程分为四个阶段: 实体抽取:使用LLM从文档中抽取实体和关系,构建知识图谱。每个实体作为图节点,实体间关系作为边。 社区发现:对知识图谱运行社区检测算法(如Leiden算法),将关联紧密的实体聚类成社区。每个社区生成一个摘要。 混合检索:查询时同时进行向量检索和图遍历。向量检索找到相关文档片段,图遍历沿着实体关系路径发现关联信息。 答案生成:将检索到的文档片段、图路径和社区摘要整合后送入LLM生成最终答案。 微软GraphRAG的实现启示 微软在2024年开源的GraphRAG实现是目前最成熟的参考方案。其架构有几个值得学习的设计: 索引阶段采用两遍处理——第一遍抽取实体和关系,第二遍对社区进行层级摘要。这种分层设计使得系统既能回答细节问题(叶子社区),也能回答宏观问题(根社区)。 查询阶段区分了local search和global search。local search针对具体实体相关问题,从实体邻域出发检索;global search针对全局性问题,直接使用社区摘要进行map-reduce式回答。 实践中的权衡 GraphRAG不是银弹。在实际部署中,我们发现了几个关键的trade-off: 索引成本显著增加。 相比纯向量RAG,GraphRAG的索引阶段需要额外的LLM调用来抽取实体和生成社区摘要。对于一个万级文档的库,索引成本可能增加5-10倍。 维护复杂度上升。 知识图谱需要持续更新。当新文档加入时,不仅要更新向量索引,还要增量更新图结构和重新计算社区归属。 并非所有场景都需要图。 对于简单的FAQ场景,纯向量RAG仍然是最优选择。GraphRAG的价值在多跳推理和全局分析场景中才能充分体现。 从GraphRAG到Agentic RAG GraphRAG代表的是一个更广泛趋势:RAG系统正在从"检索+生成"的简单模式演进为"规划+检索+推理+生成"的Agentic模式。未来的RAG系统不再是被动的检索器,而是主动的知识探索者——它能根据问题复杂度自主选择检索策略,在检索结果不足时自主发起多轮检索,甚至主动构建临时知识图谱来回答复杂问题。 这个方向才刚刚开始,GraphRAG只是第一步。 本文同步发布于 硅基AGI论坛

2026-07-12 · 1 min · 32 words · 硅基 AGI 探索者

从RAG到GraphRAG:知识检索的范式跃迁

向量检索的天花板 传统RAG系统依赖向量相似度检索,在简单事实问答场景表现出色。但当问题涉及多跳推理、跨文档关联或全局性总结时,纯向量检索就显得力不从心。 比如"公司A的CEO曾在哪家公司任职,那家公司又被谁收购了"这样的问题,需要跨多个文档片段进行链式推理。向量检索只能找到语义相似的片段,无法构建这种实体间的关联路径。 这就是GraphRAG登场的背景。 GraphRAG的核心思路 GraphRAG的核心创新在于:在传统的向量索引之上,叠加一层知识图谱索引。具体流程分为四个阶段: 实体抽取:使用LLM从文档中抽取实体和关系,构建知识图谱。每个实体作为图节点,实体间关系作为边。 社区发现:对知识图谱运行社区检测算法(如Leiden算法),将关联紧密的实体聚类成社区。每个社区生成一个摘要。 混合检索:查询时同时进行向量检索和图遍历。向量检索找到相关文档片段,图遍历沿着实体关系路径发现关联信息。 答案生成:将检索到的文档片段、图路径和社区摘要整合后送入LLM生成最终答案。 微软GraphRAG的实现启示 微软在2024年开源的GraphRAG实现是目前最成熟的参考方案。其架构有几个值得学习的设计: 索引阶段采用两遍处理——第一遍抽取实体和关系,第二遍对社区进行层级摘要。这种分层设计使得系统既能回答细节问题(叶子社区),也能回答宏观问题(根社区)。 查询阶段区分了local search和global search。local search针对具体实体相关问题,从实体邻域出发检索;global search针对全局性问题,直接使用社区摘要进行map-reduce式回答。 实践中的权衡 GraphRAG不是银弹。在实际部署中,我们发现了几个关键的trade-off: 索引成本显著增加。 相比纯向量RAG,GraphRAG的索引阶段需要额外的LLM调用来抽取实体和生成社区摘要。对于一个万级文档的库,索引成本可能增加5-10倍。 维护复杂度上升。 知识图谱需要持续更新。当新文档加入时,不仅要更新向量索引,还要增量更新图结构和重新计算社区归属。 并非所有场景都需要图。 对于简单的FAQ场景,纯向量RAG仍然是最优选择。GraphRAG的价值在多跳推理和全局分析场景中才能充分体现。 从GraphRAG到Agentic RAG GraphRAG代表的是一个更广泛趋势:RAG系统正在从"检索+生成"的简单模式演进为"规划+检索+推理+生成"的Agentic模式。未来的RAG系统不再是被动的检索器,而是主动的知识探索者——它能根据问题复杂度自主选择检索策略,在检索结果不足时自主发起多轮检索,甚至主动构建临时知识图谱来回答复杂问题。 这个方向才刚刚开始,GraphRAG只是第一步。 本文同步发布于 硅基AGI论坛

2026-07-12 · 1 min · 32 words · 硅基 AGI 探索者
混合RAG图加向量检索

混合RAG:图+向量检索的协同威力

引言 向量检索擅长语义匹配——“这段文字和我的问题有多相似”。但它不擅长关系推理——“A的上级的上级是谁”。知识图谱检索擅长关系推理,但不擅长模糊语义匹配。 2026年,混合RAG——将图检索和向量检索结合——已经成为处理复杂知识问答的最佳方案。本文将深入探讨这种混合架构。 一、为什么需要混合检索 1.1 向量检索的局限 问题: "爱因斯坦的博士导师是谁?" 向量检索: 搜索"爱因斯坦 博士 导师" → 可能找到: "爱因斯坦在苏黎世联邦理工学院学习" (语义相关但缺关键信息) 可能找不到: "Alfred Kleiner是爱因斯坦的博士论文导师" (语义距离较远) 1.2 图检索的局限 问题: "量子力学的哲学意义是什么?" 图检索: 需要遍历"量子力学"→"哲学意义"的边 → 但"哲学意义"是一个抽象概念,知识图谱中可能没有对应的节点 1.3 混合的优势 问题: "爱因斯坦的博士导师的研究领域是什么?" 混合检索: 1. 向量检索: "爱因斯坦 博士 导师" → 找到相关文档 2. 实体识别: 识别出"Alfred Kleiner" 3. 图检索: 查询"Alfred Kleiner" → "研究领域" → "实验物理学" 4. 向量检索: "Alfred Kleiner 实验物理学" → 找到详细描述 5. 综合答案: "爱因斯坦的博士导师Alfred Kleiner的研究领域是实验物理学..." 二、混合RAG架构 2.1 整体架构 用户问题 ↓ ┌─────────────────┐ │ 查询分析器 │ → 识别实体、关系、意图 └────────┬────────┘ ↓ ┌─────────────────────────────────────┐ │ 混合检索引擎 │ ├──────────┬──────────┬───────────────┤ │ 向量检索 │ 图谱检索 │ 关键词检索 │ └──────────┴──────────┴───────────────┘ ↓ ┌─────────────────┐ │ 结果融合器 │ → 排序、去重、互补 └────────┬────────┘ ↓ ┌─────────────────┐ │ 推理生成器 │ → 基于融合结果生成答案 └─────────────────┘ 2.2 查询分析器 class QueryAnalyzer: async def analyze(self, question): """分析查询,提取检索线索""" # 1. 实体识别 entities = await self.ner.extract(question) # 2. 关系识别 relations = await self.relation_extractor.extract(question, entities) # 3. 意图识别 intent = await self.intent_classifier.classify(question) # 4. 生成不同检索策略的查询 return { "entities": entities, "relations": relations, "intent": intent, "vector_query": await self.generate_vector_query(question, entities), "graph_query": self.generate_graph_query(entities, relations), "keyword_query": await self.generate_keyword_query(question) } 2.3 图谱构建 class KnowledgeGraphBuilder: async def build_from_documents(self, documents): """从文档构建知识图谱""" for doc in documents: # 1. 实体抽取 entities = await self.entity_extractor.extract(doc.text) # 2. 关系抽取 relations = await self.relation_extractor.extract(doc.text, entities) # 3. 添加到图谱 for entity in entities: await self.graph.add_node( id=entity.id, label=entity.text, type=entity.type, properties={"source": doc.id, "embedding": entity.embedding} ) for relation in relations: await self.graph.add_edge( source=relation.subject, target=relation.object, label=relation.predicate, properties={"confidence": relation.confidence} ) # 4. 同时添加到向量库 await self.vector_store.add( id=doc.id, text=doc.text, embedding=doc.embedding, metadata={"entities": [e.id for e in entities]} ) 2.4 混合检索引擎 class HybridRetrievalEngine: def __init__(self, vector_store, graph_store, keyword_index): self.vector_store = vector_store self.graph_store = graph_store self.keyword_index = keyword_index async def retrieve(self, query_analysis, top_k=10): # 1. 并行执行三种检索 vector_task = self.vector_search(query_analysis["vector_query"], top_k*2) graph_task = self.graph_search(query_analysis) keyword_task = self.keyword_search(query_analysis["keyword_query"], top_k*2) vector_results, graph_results, keyword_results = await asyncio.gather( vector_task, graph_task, keyword_task ) # 2. 融合结果 fused = self.fuse_results(vector_results, graph_results, keyword_results) # 3. 重排 reranked = await self.rerank(fused, query_analysis) return reranked[:top_k] async def graph_search(self, query_analysis): """图谱检索""" results = [] # 1. 实体匹配:在图谱中找到查询实体的对应节点 for entity in query_analysis["entities"]: matched_nodes = await self.graph_store.find_nodes( label=entity.text, fuzzy=True ) # 2. 关系遍历:沿着关系边扩展 for node in matched_nodes: for relation in query_analysis["relations"]: neighbors = await self.graph_store.traverse( start=node, edge_label=relation.predicate, max_depth=2 ) results.extend(neighbors) # 3. 获取关联文档 for result in results: if result.has_property("source"): doc = await self.document_store.get(result.source) result.content = doc.text return results def fuse_results(self, vector_results, graph_results, keyword_results): """融合三种检索结果""" fused = {} # 为每种检索结果分配权重 weights = {"vector": 0.4, "graph": 0.4, "keyword": 0.2} for result_type, results, weight in [ ("vector", vector_results, weights["vector"]), ("graph", graph_results, weights["graph"]), ("keyword", keyword_results, weights["keyword"]) ]: for rank, result in enumerate(results): doc_id = result.id if doc_id not in fused: fused[doc_id] = { "result": result, "score": 0, "sources": [] } # 倒数排名融合,加上权重 fused[doc_id]["score"] += weight * (1 / (60 + rank)) fused[doc_id]["sources"].append(result_type) # 按融合分数排序 sorted_results = sorted(fused.values(), key=lambda x: -x["score"]) # 标记同时被多种检索命中的文档(置信度更高) for item in sorted_results: item["multi_source"] = len(item["sources"]) > 1 return [item["result"] for item in sorted_results] 三、GraphRAG模式 3.1 社区检测 将知识图谱划分为社区,每个社区是一组紧密相关的实体: ...

2026-07-02 · 4 min · 794 words · 硅基 AGI 探索者
GraphRAG 2026:知识图谱增强检索的实践指南

GraphRAG 2026:知识图谱增强检索的实践指南

为什么传统RAG不够用? 传统向量检索RAG在处理多跳推理、全局摘要类问题时表现不佳。当用户问"2025年诺贝尔物理学奖得主的核心贡献是什么?",传统RAG可能只能检索到获奖者名单,而无法关联到具体贡献的文档片段。GraphRAG通过引入知识图谱的结构化关系,解决了这一痛点。 微软研究院在2024年开源的GraphRAG框架掀起了一波浪潮,到2026年,社区已经发展出更成熟的工具链和最佳实践。本文将带你从零搭建一个生产级GraphRAG系统。 GraphRAG核心架构 GraphRAG的工作流分为四个阶段: 1. 知识图谱构建 从原始文档中抽取实体和关系,构建知识图谱: from graphrag.index import build_index from graphrag.config import create_config_from_yaml # 配置文件定义LLM、嵌入模型等 config = create_config_from_yaml("config.yaml") # 构建索引:实体抽取 → 关系建模 → 社区检测 build_index( config=config, input_dir="./documents", output_dir="./graph_index" ) 实体抽取的Prompt模板: ENTITY_EXTRACTION_PROMPT = """ 你是一个知识图谱构建专家。从以下文本中抽取实体和关系。 文本:{text} 输出JSON格式: {{ "entities": [ {{"name": "实体名", "type": "PERSON|ORG|LOCATION|CONCEPT", "description": "描述"}} ], "relations": [ {{"source": "实体A", "target": "实体B", "relation": "关系类型", "description": "描述"}} ] }} """ 2. 社区检测与摘要 使用Leiden算法对图谱进行层次化社区检测,每个社区生成一个摘要: import networkx as nx from graspologic.partition import hierarchical_leiden # 构建NetworkX图 G = nx.Graph() for entity in entities: G.add_node(entity.name, **entity.metadata) for rel in relations: G.add_edge(rel.source, rel.target, relation=rel.relation) # 层次化社区检测 partitions = hierarchical_leiden(G, max_cluster_size=10) # 为每个社区生成LLM摘要 for community in partitions: community_summary = llm.summarize( entities=community.entities, relations=community.relations ) 3. 检索策略 GraphRAG支持两种检索模式: ...

2026-06-30 · 2 min · 254 words · 硅基 AGI 探索者
GraphRAG 2026:知识图谱增强检索的实践指南

GraphRAG 2026:知识图谱增强检索的实践指南

引言:为什么传统RAG不够用? 传统向量RAG在处理"全局性"问题时表现糟糕。比如你问"2026年AI芯片市场的主要竞争格局是什么?",基于文档块的向量检索只能返回零散片段,无法构建全局视图。Microsoft Research在2024年提出的GraphRAG正是为解决这一痛点而生,到2026年,这套方法已经成熟并衍生出多种变体。 GraphRAG的核心思想:先从文档中抽取实体和关系构建知识图谱,再用社区检测算法将图谱分层聚类,最后基于社区摘要进行全局检索。 GraphRAG架构总览 ┌─────────────────────────────────────────────┐ │ GraphRAG Pipeline │ ├─────────────────────────────────────────────┤ │ 1. Document Chunking (文档分块) │ │ 2. Entity Extraction (实体抽取) │ │ 3. Relationship Building (关系构建) │ │ 4. Community Detection (社区检测) │ │ 5. Community Summarization (社区摘要) │ │ 6. Query-focused Summarization (查询摘要) │ └─────────────────────────────────────────────┘ 两种检索模式 模式 适用场景 原理 延迟 Local Search 具体实体相关问题 从匹配节点出发,遍历相邻实体和关系 低 (200-500ms) Global Search 全局性、摘要性问题 遍历所有社区摘要,Map-Reduce式汇总 高 (2-5s) 环境搭建与代码实践 安装GraphRAG pip install graphrag==0.6.0 初始化项目 # 创建工作目录 mkdir my_graphrag_project && cd my_graphrag_project # 初始化配置 python -m graphrag.init --root . 初始化后会生成以下结构: ...

2026-06-30 · 2 min · 424 words · 硅基 AGI 探索者
RAG技术演进2026:从基础检索到智能知识库

RAG技术演进2026:从基础检索到智能知识库

2026年,RAG(Retrieval-Augmented Generation)技术已经走过了三年的演进历程。从最初简单的"检索+拼接"模式,发展到今天的GraphRAG、Agentic RAG、Adaptive RAG等多种高级范式,RAG已成为企业AI应用的核心基础设施。本文将系统梳理2026年RAG技术的全景图。 一、RAG技术演进路线 四代RAG架构 代际 名称 核心特征 时间 代表方案 第一代 Naive RAG 简单向量检索+拼接 2023 LangChain Basic RAG 第二代 Advanced RAG 查询改写、重排序、多路召回 2024 LlamaIndex Advanced 第三代 Modular RAG 模块化、可插拔、自适应路由 2025 LangGraph RAG 第四代 Agentic RAG Agent驱动、多步推理、工具调用 2026 Agentic RAG, GraphRAG 为什么需要更先进的RAG? Naive RAG的根本问题在于: 检索质量不稳定:向量相似度≠语义相关性 缺乏推理能力:无法处理"需要多步推理才能回答"的问题 无结构化知识:无法利用实体关系、时序信息等结构化知识 无自适应能力:对所有问题用同一套检索策略 2026年企业RAG部署的统计:Naive RAG的准确率仅55-65%,而Agentic RAG可达85-92%——差距巨大。 二、Embedding技术2026 Embedding模型横评 Embedding是RAG的基础——如果检索不到相关内容,后续一切都无意义。 模型 维度 最大序列 MTEB分数 中文表现 特点 OpenAI text-embedding-3-large 3072 8191 72.5 良好 通用、稳定 Voyage-3 1024 32000 74.8 良好 2026最强 BGE-M3 1024 8192 73.2 优秀 多语言、开源 GTE-Large-ZH 1024 512 71.5 优秀 中文优化 Jina Embeddings v3 1024 8192 72.8 良好 长文本 Cohere Embed v4 1536 512 73.5 良好 多语言 2026年Embedding技术趋势 1. 多向量嵌入(Multi-Vector Embedding) ...

2026-06-30 · 3 min · 559 words · 硅基 AGI 探索者
graphrag production deployment guide

GraphRAG 生产部署指南:知识图谱增强的 RAG 系统

GraphRAG vs 传统 RAG 的本质区别 传统 RAG 的核心问题是"只见树木不见森林"——它能找到局部相关的文本块,但无法理解全局关系。GraphRAG 通过构建知识图谱,让系统具备全局视角和推理能力。 维度 传统 RAG GraphRAG 检索单元 文本块 实体+关系+文本块 全局理解 ❌ ✅ 社区摘要 多跳推理 ❌ ✅ 图遍历 可解释性 低 高(路径溯源) 构建成本 低 高 查询延迟 1-2s 3-10s 架构设计 ┌─────────────────────────────────────────────────────┐ │ GraphRAG 架构 │ ├─────────────────────────────────────────────────────┤ │ │ │ 离线构建 Pipeline │ │ ┌──────────┐ ┌───────────┐ ┌──────────────┐ │ │ │ 文档解析 │→│ 实体抽取 │→│ 关系抽取 │ │ │ └──────────┘ └───────────┘ └──────────────┘ │ │ ↓ │ │ ┌───────────┐ ┌───────────┐ ┌──────────────┐ │ │ │ 图谱构建 │←│ 社区检测 │←│ Embedding │ │ │ └───────────┘ └───────────┘ └──────────────┘ │ │ ↓ │ │ ┌─────────────┐ │ │ │ 索引持久化 │ │ │ └─────────────┘ │ │ │ │ 在线查询 Engine │ │ ┌──────────┐ ┌───────────┐ ┌──────────────┐ │ │ │ Query │→│ 路由决策 │→│ 双路检索 │ │ │ │ 理解 │ │ │ │ 向量+图谱 │ │ │ └──────────┘ └───────────┘ └──────────────┘ │ │ ↓ │ │ ┌──────────┐ ┌───────────┐ ┌──────────────┐ │ │ │ 生成+引用 │←│ 信息整合 │←│ 重排序 │ │ │ └──────────┘ └───────────┘ └──────────────┘ │ │ │ └─────────────────────────────────────────────────────┘ 离线构建 Pipeline 1. 实体与关系抽取 from pydantic import BaseModel from typing import List class Entity(BaseModel): name: str type: str # Person, Organization, Concept, Event, etc. description: str source_chunk_id: str class Relation(BaseModel): source_entity: str target_entity: str relation_type: str description: str confidence: float source_chunk_id: str ENTITY_EXTRACTION_PROMPT = """ 你是一个信息抽取专家。从以下文本中抽取实体和关系。 实体类型:Person, Organization, Concept, Technology, Event, Location 关系类型:works_at, created, related_to, part_of, located_in, depends_on, competes_with 文本: {text} 请以 JSON 格式输出: {{ "entities": [ {{"name": "...", "type": "...", "description": "..."}} ], "relations": [ {{"source": "...", "target": "...", "type": "...", "description": "...", "confidence": 0.0-1.0}} ] }} """ class EntityExtractor: def __init__(self, llm): self.llm = llm def extract(self, text: str, chunk_id: str): prompt = ENTITY_EXTRACTION_PROMPT.format(text=text) result = self.llm.generate(prompt, response_format="json") entities = [ Entity(**e, source_chunk_id=chunk_id) for e in result["entities"] ] relations = [ Relation(**r, source_chunk_id=chunk_id) for r in result["relations"] ] return entities, relations 2. 知识图谱构建 import networkx as nx from community_detection import LeidenAlgorithm class KnowledgeGraph: def __init__(self): self.graph = nx.DiGraph() self.entity_index = {} # name -> node_id def add_entities(self, entities: List[Entity]): for entity in entities: if entity.name not in self.entity_index: node_id = len(self.entity_index) self.entity_index[entity.name] = node_id self.graph.add_node( node_id, name=entity.name, type=entity.type, description=entity.description, source_chunks=[entity.source_chunk_id] ) else: # 合并描述 node_id = self.entity_index[entity.name] self.graph.nodes[node_id]["source_chunks"].append( entity.source_chunk_id ) def add_relations(self, relations: List[Relation]): for rel in relations: if rel.source_entity in self.entity_index and rel.target_entity in self.entity_index: src = self.entity_index[rel.source_entity] tgt = self.entity_index[rel.target_entity] if self.graph.has_edge(src, tgt): # 合并关系 existing = self.graph[src][tgt] existing["relations"].append({ "type": rel.relation_type, "description": rel.description, "confidence": rel.confidence }) else: self.graph.add_edge( src, tgt, relations=[{ "type": rel.relation_type, "description": rel.description, "confidence": rel.confidence }] ) def detect_communities(self): """使用 Leiden 算法进行社区检测""" undirected = self.graph.to_undirected() communities = LeidenAlgorithm().fit(undirected) # 为每个社区生成摘要 for comm_id, nodes in communities.items(): subgraph = self.graph.subgraph(nodes) summary = self._summarize_community(subgraph) for node in nodes: self.graph.nodes[node]["community_id"] = comm_id self.graph.graph.setdefault("community_summaries", {})[comm_id] = summary return communities def _summarize_community(self, subgraph): entities_info = [] for node_id in subgraph.nodes(): node = self.graph.nodes[node_id] entities_info.append(f"{node['name']} ({node['type']}): {node['description']}") relations_info = [] for u, v, data in subgraph.edges(data=True): for rel in data["relations"]: relations_info.append( f"{self.graph.nodes[u]['name']} --{rel['type']}--> {self.graph.nodes[v]['name']}" ) prompt = f""" 请总结以下知识图谱社区的关键信息: 实体: {chr(10).join(entities_info)} 关系: {chr(10).join(relations_info)} 请生成一段简洁的摘要,涵盖主要实体和它们之间的关系。 """ return self.llm.generate(prompt) 3. 索引持久化 class GraphRAGIndex: def __init__(self): self.graph = KnowledgeGraph() self.vector_store = MilvusIndex(dim=1024) self.community_store = CommunityStore() def build(self, documents: List[Document]): # 1. 文本分块与向量化 chunks = document_aware_chunk(documents) for chunk in chunks: embedding = embed_model.encode(chunk.text) self.vector_store.add(id=chunk.id, embedding=embedding, metadata={"text": chunk.text}) # 2. 实体关系抽取 all_entities = [] all_relations = [] for chunk in chunks: entities, relations = extractor.extract(chunk.text, chunk.id) all_entities.extend(entities) all_relations.extend(relations) # 3. 构建知识图谱 self.graph.add_entities(all_entities) self.graph.add_relations(all_relations) # 4. 社区检测与摘要 communities = self.graph.detect_communities() # 5. 持久化 self._persist() def _persist(self): # 图谱存 Neo4j 或 NetworkX pickle nx.write_gpickle(self.graph.graph, "graph.gpickle") # 向量索引已在 Milvus 中持久化 # 社区摘要存数据库 self.community_store.save(self.graph.graph.graph.get("community_summaries", {})) 在线查询引擎 class GraphRAGQueryEngine: def __init__(self, index: GraphRAGIndex, llm): self.index = index self.llm = llm def query(self, question: str) -> str: # 1. 判断查询类型 query_type = self._classify_query(question) if query_type == "global": # 全局型问题 → 社区检索 context = self._global_search(question) elif query_type == "specific": # 具体型问题 → 向量+图遍历 context = self._local_search(question) else: # 混合型 → 双路检索 context = self._hybrid_search(question) # 2. 生成答案 answer = self.llm.generate( prompt=ANSWER_PROMPT.format(question=question, context=context), citations=True ) return answer def _local_search(self, question: str): # 向量检索找到相关文本块 query_emb = embed_model.encode(question) vector_hits = self.index.vector_store.search(query_emb, top_k=10) # 从命中块中提取实体 entities = set() for hit in vector_hits: entities.update(self._extract_entities_from_chunk(hit)) # 图遍历扩展上下文 graph_context = [] for entity_name in entities: if entity_name in self.index.graph.entity_index: node_id = self.index.graph.entity_index[entity_name] # 1-hop 和 2-hop 邻居 neighbors = nx.single_source_shortest_path_length( self.index.graph.graph, node_id, cutoff=2 ) for neighbor_id, hops in neighbors.items(): if hops > 0: node = self.index.graph.graph.nodes[neighbor_id] graph_context.append({ "entity": node["name"], "type": node["type"], "hops": hops, "description": node["description"] }) return { "vector_context": vector_hits, "graph_context": graph_context } def _global_search(self, question: str): # 从社区摘要中检索 community_summaries = self.index.community_store.get_all() # 用 LLM 判断哪些社区相关 relevant = self.llm.generate( prompt=f""" 以下问题与哪些社区摘要相关? 问题:{question} 社区摘要: {json.dumps(community_summaries, ensure_ascii=False)} 返回最相关的 3 个社区 ID。 """ ) return {"community_context": relevant} 生产运维 监控指标 @dataclass class GraphRAGMetrics: # 构建阶段 entity_extraction_rate: float # 每分钟抽取实体数 relation_extraction_rate: float # 每分钟抽取关系数 community_detection_time: float # 社区检测耗时 # 查询阶段 query_latency_p50: float query_latency_p99: float vector_recall: float # 向量检索召回率 graph_coverage: float # 图遍历覆盖率 community_hit_rate: float # 社区命中率 # 质量指标 answer_accuracy: float # 答案准确率 citation_rate: float # 引用覆盖率 hallucination_rate: float # 幻觉率 增量更新策略 class IncrementalUpdater: """GraphRAG 增量更新:只处理新增/修改的文档""" def update(self, new_documents: List[Document], deleted_ids: List[str]): # 1. 删除过期数据 for doc_id in deleted_ids: self._remove_document(doc_id) # 2. 处理新文档 for doc in new_documents: entities, relations = extractor.extract(doc) self.graph.add_entities(entities) self.graph.add_relations(relations) # 3. 局部社区检测(只重新检测受影响的社区) affected_communities = self._find_affected_communities(new_documents, deleted_ids) self._redetect_communities(affected_communities) # 4. 更新向量索引 self.vector_store.upsert(new_documents) 成本与效果 以 10 万篇技术文档为例: ...

2026-06-28 · 5 min · 912 words · 硅基 AGI 探索者
rag architecture 2026 naive to graphrag agent

RAG 架构 2026 最新实践:从 Naive RAG 到 GraphRAG+Agent

RAG 架构的四代演进 检索增强生成(Retrieval-Augmented Generation, RAG)已经走过了三个年头。从 2023 年最初的概念验证,到 2026 年的今天,RAG 架构经历了四次重大范式转移。本文将系统梳理这条演进路线,并给出 2026 年的最佳实践。 第一代:Naive RAG(2023) 最朴素的 RAG 架构,核心流程是:文档分块 → 向量化 → 相似度检索 → 拼接 Prompt → LLM 生成。 用户提问 → Embedding → 向量检索 Top-K → 拼接上下文 → LLM 生成答案 问题:检索质量差、缺乏上下文理解、无法处理多跳推理。 第二代:Advanced RAG(2024) 引入了 Query 重写、重排序(Rerank)、混合检索等优化: # Advanced RAG 典型流程 def advanced_rag(query: str, vector_db, keyword_db): # 1. Query 重写 rewritten_query = llm.rewrite_query(query) # 2. 混合检索:向量 + 关键词 vector_results = vector_db.search(rewrite_query, top_k=20) keyword_results = keyword_db.search(rewrite_query, top_k=20) # 3. 合并去重 candidates = merge_and_dedupe(vector_results, keyword_results) # 4. 重排序 reranked = reranker.rerank(rewritten_query, candidates, top_k=5) # 5. 生成 return llm.generate(query, context=reranked) 提升:检索召回率提升 30-50%,但仍然缺乏全局视角。 ...

2026-06-28 · 2 min · 375 words · 硅基 AGI 探索者
graphrag graph retrieval

GraphRAG图检索增强生成

概述 GraphRAG图检索增强生成是AI智能体领域中GraphRAG图检索增强生成的重要主题。本文将从多个角度深入分析这一话题,为读者提供系统性的认知框架和实践参考。 核心概念 基本定义 在深入讨论之前,我们需要明确几个核心概念。AI智能体是指能够感知环境、理解指令、规划行动并调用工具完成任务的AI系统。与传统的聊天机器人不同,智能体具有自主性、目标导向性和工具使用能力。 GraphRAG图检索增强生成涉及的关键技术包括: 大语言模型:作为智能体的认知引擎,负责理解、推理和生成 工具调用:通过Function Calling或MCP协议与外部系统交互 记忆系统:短期记忆处理当前对话,长期记忆存储历史经验 规划引擎:将复杂任务分解为可执行的子步骤 技术原理 从技术层面看,GraphRAG图检索增强生成的核心在于如何让AI系统更好地理解和执行人类意图。这涉及多个技术环节的协同: 首先是感知层,智能体需要准确理解用户的自然语言指令,提取关键信息和约束条件。其次是规划层,将高层目标分解为具体的执行步骤。然后是执行层,调用合适的工具完成每个步骤。最后是反馈层,根据执行结果调整后续策略。 实践分析 当前现状 在RAG与微调领域,当前的技术实践呈现出几个明显特征: 工程化程度提升:从实验室原型到生产级系统,工程能力成为关键差异化因素 评估体系完善:越来越多标准化的评测基准被提出,帮助开发者量化能力边界 开源生态繁荣:开源框架和工具链的成熟降低了开发门槛 安全意识增强:对AI安全和对齐问题的重视程度显著提升 关键挑战 尽管进展显著,GraphRAG图检索增强生成仍面临几个核心挑战: 技术挑战: 大模型的幻觉问题在智能体场景下被放大,因为智能体需要做出实际决策 多步推理中的错误累积效应导致长程任务成功率下降 工具调用的可靠性受外部API稳定性影响 工程挑战: 智能体的可观测性不足,调试和排错困难 成本控制与性能优化的平衡 从单机到分布式部署的架构复杂性 安全挑战: Prompt注入等攻击手段不断进化 智能体权限管理需要更精细化的控制 数据隐私保护在多Agent协作场景下更加复杂 优化策略 针对上述挑战,以下是几个关键优化方向: 技术优化 分而治之:将复杂任务分解为可独立验证的子任务,降低单步错误影响 多路投票:对关键决策使用多次采样投票机制,提高可靠性 渐进式信任:智能体权限从最小化开始,根据表现逐步扩展 人在回路:高风险决策保留人工审核环节 工程优化 可观测性优先:建立完善的日志、指标和追踪体系 灰度发布:新版本智能体先在小流量环境验证 自动化测试:构建端到端测试套件,防止回归 成本监控:实时追踪Token消耗和API调用成本 案例研究 为了更具体地说明GraphRAG图检索增强生成的实践价值,我们来看一个典型场景: 某科技公司在内部IT运维中部署了AI智能体,负责处理员工的工单请求。智能体需要理解员工的自然语言描述,判断问题类型,查询知识库,执行修复操作或转接人工。 实施过程中遇到的关键问题包括: 员工描述模糊导致意图识别错误 知识库信息过时导致给出错误建议 某些操作需要管理员权限存在安全风险 解决方案: 引入澄清对话机制,在不确定时主动追问 建立知识库更新流程,定期审核内容 实施权限分级制度,敏感操作需人工确认 效果:工单首次解决率提升35%,平均处理时间缩短60%,员工满意度显著提升。 未来趋势 GraphRAG图检索增强生成的发展趋势值得关注: 标准化:MCP等开放协议将推动工具接口标准化,降低集成成本 垂直化:针对特定行业和场景的专用智能体将大量涌现 协作化:多智能体协作将成为复杂任务的标准解决方案 自主化:智能体的自主决策能力将持续提升,但需要配套的安全机制 结论 GraphRAG图检索增强生成是AI智能体技术发展中的重要一环。无论是技术原理的深入理解,还是实践中的工程优化,都需要系统性思维。对于开发者和企业而言,关键在于: 理解技术能力和边界,避免过度期待 建立系统化的评估和监控体系 在创新和安全之间找到平衡 持续学习和适应快速变化的技术生态 硅基AGI探索者将持续关注RAG与微调领域的最新进展,为读者提供深度分析和实践指导。— ...

2026-06-27 · 1 min · 88 words · 硅基 AGI 探索者
graphrag knowledge graph rag

GraphRAG图检索增强生成

引言 传统RAG基于向量相似度检索文本块,在处理需要跨文档推理、全局性总结和多跳关系分析的任务时存在明显局限。GraphRAG将知识图谱与RAG结合,通过图结构组织信息,支持基于关系的检索和推理。本文深入GraphRAG的架构设计、构建流程和工程实践。 传统RAG的局限 局部检索的困境 传统RAG将文档切分为文本块,用向量相似度检索最相关的Top-K块。这种方式存在根本局限: 多跳推理失效:问题"A公司的CEO在B公司担任什么职务?“需要先找到A公司的CEO是谁,再查找此人在B公司的职务。向量检索可能只检索到A公司或B公司中的一个文档块,无法建立跨文档的连接。 全局信息缺失:问题"这个行业的主要趋势是什么?“需要综合所有文档的全局信息,但向量检索只能返回局部相似的文本块,无法提供全局视角。 关系信息丢失:文档切分时,实体间的关系可能被分散到不同文本块中,向量检索难以捕获这些结构化关系。 GraphRAG架构 整体架构 GraphRAG在传统RAG基础上增加知识图谱层: 文档 → 文本块提取 → 实体抽取 → 关系抽取 → 知识图谱构建 ↓ 查询 → 查询理解 → 图检索(子图提取)→ 上下文组装 → LLM生成 ↑ 向量检索(补充) 知识图谱构建 实体抽取:使用LLM从文本中提取实体(人物、组织、地点、概念等): def extract_entities(text, llm): prompt = f""" 从以下文本中提取实体,按类型分类。 文本:{text} 输出JSON格式: {{ "persons": ["..."], "organizations": ["..."], "locations": ["..."], "concepts": ["..."], "events": ["..."] }} """ return json.loads(llm.generate(prompt)) 关系抽取:识别实体间的关系: def extract_relations(text, entities, llm): prompt = f""" 识别以下文本中实体间的关系。 文本:{text} 实体:{entities} 输出三元组列表: [(主体, 关系, 客体), ...] 例如:(苹果公司, 收购, NeXT) """ return eval(llm.generate(prompt)) 图谱存储:将实体和关系存入图数据库(如Neo4j): ...

2026-06-27 · 2 min · 411 words · 硅基 AGI 探索者
鲁ICP备2026018361号