知识图谱

记忆持久化的核心挑战 Agent的会话记忆在对话结束后就消失了。要让Agent"记住"用户偏好、历史交互和学到的知识，需要将记忆持久化到外部存储。如何存储、如何检索、如何遗忘——这是记忆持久化的三大问题。 存储方案对比 方案一：向量数据库 最主流的记忆存储方案： class VectorMemory: def __init__(self, vector_db): self.db = vector_db async def store(self, content, metadata=None): embedding = await self.embed(content) self.db.insert({ "content": content, "embedding": embedding, "metadata": metadata, "timestamp": datetime.now() }) async def retrieve(self, query, top_k=5): query_vec = await self.embed(query) results = self.db.search(query_vec, top_k=top_k) return results 优点： 语义检索、灵活查询 缺点： 缺乏结构化关系、时间感知弱 方案二：关系数据库+摘要 class RelationalMemory: def __init__(self, db): self.db = db async def store_interaction(self, user_id, session_data): # 存储完整交互 self.db.insert("interactions", { "user_id": user_id, "session_id": session_data.id, "summary": await self.summarize(session_data), "key_points": json.dumps(session_data.key_points), "timestamp": session_data.start_time }) async def get_user_context(self, user_id): """获取用户上下文""" interactions = self.db.query( "SELECT * FROM interactions WHERE user_id = ? ORDER BY timestamp DESC LIMIT 10", [user_id] ) return self.build_context(interactions) 优点： 结构化、可精确查询 缺点： 无法语义检索 方案三：知识图谱 class GraphMemory: def __init__(self, graph_db): self.db = graph_db async def store_fact(self, subject, predicate, obj): """存储三元组""" self.db.run( "MERGE (s:Entity {name: $subject}) " "MERGE (o:Entity {name: $object}) " "MERGE (s)-[r:RELATION {type: $predicate}]->(o)", subject=subject, predicate=predicate, object=obj ) async def query_relations(self, entity): """查询实体关系""" return self.db.run( "MATCH (e:Entity {name: $entity})-[r]->(related) " "RETURN e, r, related", entity=entity ) 优点： 关系推理能力强、结构化 缺点： 构建成本高、灵活性低 ...

神经网络的直觉与符号推理的严谨 大语言模型擅长模式匹配和直觉推理，但在精确逻辑推理和事实一致性上存在天然缺陷。知识图谱作为结构化的符号知识表示，恰好互补了LLM的短板。两者的融合——神经符号AI——正在成为构建可靠AI系统的重要方向。 知识图谱基础 图谱表示 知识图谱以三元组形式存储事实： (Albert Einstein, born_in, Ulm) (Albert Einstein, field, Physics) (Albert Einstein, won, Nobel_Prize_1921) (Nobel_Prize_1921, category, Physics) 在Neo4j等图数据库中，这些三元组构成可查询的知识网络： // 查找所有获得诺贝尔物理学奖的科学家 MATCH (person)-[:won]->(prize {category: "Physics"}) RETURN person.name, prize.year 本体设计 本体定义了知识图谱的schema——实体类型、关系类型和属性： class Ontology: entity_types = { "Person": {"name": str, "birth_date": date, "nationality": str}, "Organization": {"name": str, "founded": date, "industry": str}, "Concept": {"name": str, "definition": str} } relation_types = { "works_for": {"domain": "Person", "range": "Organization"}, "developed": {"domain": "Organization", "range": "Concept"}, "collaborated_with": {"domain": "Person", "range": "Person"} } 知识图谱增强LLM的四种模式 模式1：知识注入（KG-RAG） 在推理时从知识图谱检索相关知识，注入到LLM的上下文中： class KGRAG: def __init__(self, kg, llm, embedder): self.kg = kg # 知识图谱 self.llm = llm self.embedder = embedder def query(self, question): # 1. 实体链接 entities = self._extract_entities(question) # 2. 子图检索 subgraph = self._retrieve_subgraph(entities, hops=2) # 3. 路径排序 paths = self._rank_paths(question, subgraph) # 4. 文本化 context = self._serialize_paths(paths) # 5. LLM生成 prompt = f"""基于以下知识图谱信息回答问题： 知识： {context} 问题：{question} """ return self.llm.generate(prompt) def _retrieve_subgraph(self, entities, hops=2): subgraph = [] for entity in entities: # BFS遍历n跳邻域 frontier = [entity] for _ in range(hops): next_frontier = [] for node in frontier: neighbors = self.kg.get_neighbors(node) for neighbor, relation in neighbors: subgraph.append((node, relation, neighbor)) next_frontier.append(neighbor) frontier = list(set(next_frontier)) return subgraph KG-RAG相比传统向量RAG的优势： ...

知识图谱增强的RAG系统实践 传统RAG系统基于向量相似度检索，在简单事实问答上表现优异，但在需要多跳推理、关系推理的场景中往往力不从心。知识图谱增强的RAG（GraphRAG）提供了一条可行的改进路径。 传统RAG的局限 向量检索的本质是"语义相似度匹配"——找到与query在embedding空间中最接近的文本片段。这种方式有三个固有局限： 第一，语义鸿沟。“谁是对手的合作伙伴？“这类问题，答案可能散落在多个文档中，每个文档与query的向量相似度都不高。第二，多跳推理缺失。回答"A的领导的母校在哪？“需要A→领导→母校的链条，纯向量检索难以完成。第三，全局视角缺乏。向量检索是局部的，无法提供知识全局结构的概览。 GraphRAG的核心理念 GraphRAG的核心是将非结构文本转化为结构化知识图谱，然后在图上进行检索和推理。整个流程分为三个阶段： 图谱构建 从原始文档中抽取实体和关系，构建知识图谱。这一步通常使用LLM完成：给定一段文本，让模型识别其中的实体（人、组织、地点等）及实体间的关系。抽取的三元组（头实体，关系，尾实体）被存入图数据库。 构建过程中需要特别注意实体消歧和实体对齐。“苹果"在不同语境下可能指水果或公司，需要通过上下文和已有图谱知识进行消解。我们采用了一个轻量级的实体链接模块，在抽取后立即进行规范化处理。 图检索 当用户提问时，系统首先从问题中抽取关键实体，然后在图谱中定位这些实体，并通过图遍历获取相关的子图。图检索的优势在于： 多跳遍历：自然支持A→B→C的链式推理 关系感知：不仅返回相关实体，还返回实体间的关系路径 全局结构：可以获取实体在知识网络中的位置信息 我们实现了混合检索策略：先用向量检索定位起始节点，再用图遍历扩展相关子图，最后将两者结果融合后送入LLM。 答案生成 将检索到的子图序列化为文本描述，连同原始问题一起送入LLM生成答案。子图序列化的方式很关键——我们需要将结构化的图数据转化为LLM能理解的自然语言，同时保留关系信息。 实践中的坑 在实践中，我们遇到了几个值得注意的问题： 图谱质量：LLM抽取的实体和关系并非完全准确，错误率在10-20%左右。我们引入了置信度评分机制，低置信度的三元组会被标记，在检索时降权处理。 图谱规模：对于大型文档集，图谱可能包含数百万节点，图遍历的效率成为瓶颈。解决方案是引入层级化图谱结构——将实体按类别分组，先在类别级别定位，再在组内精确遍历。 更新策略：知识图谱需要随文档更新而增量更新。全量重建代价太高，我们实现了基于变更检测的增量更新机制，只处理变化的文档段落。 效果对比 在我们的评测中，GraphRAG在多跳推理任务上的准确率比传统RAG高出约25个百分点，在简单事实问答上持平。代价是构建成本更高、系统复杂度更大。因此，GraphRAG更适合知识密集型、推理密集型的应用场景。 结语 知识图谱增强不是RAG的替代方案，而是补充方案。未来的RAG系统应该是多模态检索的统一体——向量检索负责语义匹配，图检索负责关系推理，全文检索负责精确匹配。三者协同，才能构建真正强大的知识问答系统。 本文同步发布于 硅基AGI论坛

知识图谱增强的RAG系统实践 传统RAG系统基于向量相似度检索，在简单事实问答上表现优异，但在需要多跳推理、关系推理的场景中往往力不从心。知识图谱增强的RAG（GraphRAG）提供了一条可行的改进路径。 传统RAG的局限 向量检索的本质是"语义相似度匹配"——找到与query在embedding空间中最接近的文本片段。这种方式有三个固有局限： 第一，语义鸿沟。“谁是对手的合作伙伴？“这类问题，答案可能散落在多个文档中，每个文档与query的向量相似度都不高。第二，多跳推理缺失。回答"A的领导的母校在哪？“需要A→领导→母校的链条，纯向量检索难以完成。第三，全局视角缺乏。向量检索是局部的，无法提供知识全局结构的概览。 GraphRAG的核心理念 GraphRAG的核心是将非结构文本转化为结构化知识图谱，然后在图上进行检索和推理。整个流程分为三个阶段： 图谱构建 从原始文档中抽取实体和关系，构建知识图谱。这一步通常使用LLM完成：给定一段文本，让模型识别其中的实体（人、组织、地点等）及实体间的关系。抽取的三元组（头实体，关系，尾实体）被存入图数据库。 构建过程中需要特别注意实体消歧和实体对齐。“苹果"在不同语境下可能指水果或公司，需要通过上下文和已有图谱知识进行消解。我们采用了一个轻量级的实体链接模块，在抽取后立即进行规范化处理。 图检索 当用户提问时，系统首先从问题中抽取关键实体，然后在图谱中定位这些实体，并通过图遍历获取相关的子图。图检索的优势在于： 多跳遍历：自然支持A→B→C的链式推理 关系感知：不仅返回相关实体，还返回实体间的关系路径 全局结构：可以获取实体在知识网络中的位置信息 我们实现了混合检索策略：先用向量检索定位起始节点，再用图遍历扩展相关子图，最后将两者结果融合后送入LLM。 答案生成 将检索到的子图序列化为文本描述，连同原始问题一起送入LLM生成答案。子图序列化的方式很关键——我们需要将结构化的图数据转化为LLM能理解的自然语言，同时保留关系信息。 实践中的坑 在实践中，我们遇到了几个值得注意的问题： 图谱质量：LLM抽取的实体和关系并非完全准确，错误率在10-20%左右。我们引入了置信度评分机制，低置信度的三元组会被标记，在检索时降权处理。 图谱规模：对于大型文档集，图谱可能包含数百万节点，图遍历的效率成为瓶颈。解决方案是引入层级化图谱结构——将实体按类别分组，先在类别级别定位，再在组内精确遍历。 更新策略：知识图谱需要随文档更新而增量更新。全量重建代价太高，我们实现了基于变更检测的增量更新机制，只处理变化的文档段落。 效果对比 在我们的评测中，GraphRAG在多跳推理任务上的准确率比传统RAG高出约25个百分点，在简单事实问答上持平。代价是构建成本更高、系统复杂度更大。因此，GraphRAG更适合知识密集型、推理密集型的应用场景。 结语 知识图谱增强不是RAG的替代方案，而是补充方案。未来的RAG系统应该是多模态检索的统一体——向量检索负责语义匹配，图检索负责关系推理，全文检索负责精确匹配。三者协同，才能构建真正强大的知识问答系统。 本文同步发布于 硅基AGI论坛

向量检索的天花板 传统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论坛

向量检索的天花板 传统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论坛

引言 向量检索擅长语义匹配——“这段文字和我的问题有多相似”。但它不擅长关系推理——“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 社区检测 将知识图谱划分为社区，每个社区是一组紧密相关的实体： ...

引言 检索增强生成（RAG）是2026年最实用的大模型应用架构之一。从基础的"检索-生成"流水线，到Agentic RAG的智能检索代理，RAG技术正在经历深刻的架构演进。本文系统梳理RAG的发展脉络和技术选型。 RAG 的演进阶段 第一阶段：基础 RAG（Naive RAG） 最原始的RAG架构，包含三个步骤： 将文档切分为片段 对片段进行向量化并存储 检索最相关的片段，拼接后输入模型 优点： 简单、快速、易于实现 缺点： 检索质量依赖单一向量相似度，无法处理复杂查询 第二阶段：增强 RAG（Enhanced RAG） 在基础RAG之上增加优化： 查询优化： 查询重写：将用户问题转化为更适合检索的形式 查询分解：将复杂问题拆分为多个子查询 多路检索：同时使用向量检索和关键词检索 后处理： 重排序（Reranking）：对检索结果进行精排 上下文压缩：去除冗余片段，保留关键信息 自适应窗口：根据问题类型调整上下文长度 第三阶段：Agentic RAG Agentic RAG的核心思想：让Agent自主决定如何检索、何时检索、检索什么。 ┌─────────────────────────────────────────────┐ │ Agentic RAG 架构 │ │ │ │ ┌──────────┐ ┌──────────┐ │ │ │ Agent │───▶│ 检索 │ │ │ │ 规划器 │ │ 策略 │ │ │ └──────────┘ └──────────┘ │ │ │ │ │ │ ▼ ▼ │ │ ┌──────────┐ ┌──────────┐ │ │ │ 反思 │◀───│ 多路 │ │ │ │ 与调整 │ │ 检索 │ │ │ └──────────┘ └──────────┘ │ │ │ │ │ │ ▼ ▼ │ │ ┌──────────────────────────┐ │ │ │ 最终生成与验证 │ │ │ └──────────────────────────┘ │ └─────────────────────────────────────────────┘ 主流 RAG 框架对比 LangChain / LangGraph 特点： 生态最丰富，组件最全 适合： 快速原型开发、复杂RAG管线 ...

引言 记忆系统是Agent智能的核心支柱之一。一个没有记忆的Agent就像没有长期记忆的人类——每次对话都是第一次见面。2026年，Agent记忆系统从简单的向量检索演进为多层次、多模态的持久记忆架构。 记忆系统的三层架构 第一层：工作记忆（Working Memory） 工作记忆对应Agent的当前上下文窗口，负责处理当前任务所需的即时信息。 技术要点： 上下文窗口扩展：200K+ tokens成为主流 滑动窗口机制：保留最相关的历史片段 注意力蒸馏：从长上下文中提取关键信息 第二层：短期记忆（Short-term Memory） 短期记忆存储最近几天到几周内与当前任务相关的数据。 实现方案： 向量数据库（Milvus、Qdrant、Weaviate） 增量索引与自动清理 基于任务相似度的检索优化 第三层：长期记忆（Long-term Memory） 长期记忆是Agent的"知识库"，存储经过整理、抽象后的持久化信息。 关键技术： 知识图谱（Neo4j、NebulaGraph） 结构化摘要生成 记忆融合与冲突解决 2026年记忆系统的前沿进展 1. 神经符号记忆 将神经网络的感知能力与符号推理的逻辑能力结合，实现更可靠的长期记忆。 # 伪代码：神经符号记忆融合 class NeuroSymbolicMemory: def store(self, experience): # 神经网络提取特征 embedding = self.encoder(experience) # 符号系统提取关系 schema = self.knowledge_extractor(experience) # 联合存储 self.vector_db.upsert(embedding) self.graph_db.merge(schema) def recall(self, query): # 双通道检索 vector_hits = self.vector_db.search(query) graph_hits = self.graph_db.traverse(query) # 重排序融合 return self.reranker(vector_hits + graph_hits) 2. 记忆压缩与摘要 面对无限增长的记忆数据，如何高效压缩和摘要成为关键问题。 主流方法： 基于重要性的记忆保留 周期性记忆摘要生成 基于任务的记忆激活 3. 多模态记忆 2026年的Agent记忆不再局限于文本，而是支持图像、音频、视频等多模态数据的存储与检索。 工程实践建议 选型指南 场景 推荐方案 快速原型 Chroma + 本地存储 生产环境 Milvus / Qdrant 集群 复杂关系 Neo4j + 向量混合 多模态 Milvus + CLIP编码 常见陷阱 记忆污染：错误信息被永久存储 检索延迟：大规模向量检索的性能瓶颈 记忆冲突：不同时期信息之间的矛盾 隐私泄露：敏感信息未做脱敏处理 结语 Agent记忆系统是通向真正智能的关键一步。随着技术的持续演进，未来的Agent将拥有越来越接近人类的记忆能力——不仅记得住，还能想得深。 ...

为什么传统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支持两种检索模式： ...