用于智能体AI的知识图谱:超越向量RAG的四种模式
向量搜索能找到相似的文本,而非相关联的事实。智能体的四种图模式:基于事实的提示、规划、执行验证与自我修正。
来源: From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs
大多数构建人工智能系统的团队都会遇到同样的问题。首先搭建向量数据库,将文档分割成小块,再接入大语言模型,最终将其称为RAG流程。这种方案在用户提出的需求只需整合来自不同数据域的三个事实时还能正常运行,但一旦遇到此类需求,系统要么给出看似有根据的答案,要么返回在技术上正确却在实际应用中毫无用处的结果。
通常问题并不出在大语言模型本身,而在于其底层的检索层。向量相似度搜索本质上是在查找语义相近的文本片段,因此它只能找到在语义上相近的文字,却无法识别出在因果或关联关系上紧密相连的事实。对于那些需要多步推理、采取行动并依次做出决策的智能体而言,这一限制会进一步加剧问题,一个错误的答案就会导致整个推理链上接连出现错误。
值得认真考虑的观点是,知识图谱并非仅仅是一种更先进的检索机制,它是让智能体能够进行推理而非仅做检索的结构基础。
核心理念
智能体人工智能常常被视为一个流行术语:在大型语言模型周围添加一些工具调用功能,便宣称取得了成功。而更为严谨的方法则是专门为多步骤推理设计知识层,而非用于单次问题解答。
这种转变是从扁平的检索模型转向结构化图谱,在图谱中实体、关系和上下文都处于核心地位。图谱不仅会记录产品X存在缺陷,还会记录产品X由供应商Y生产、被运送到区域Z,并受合规框架W的约束。查询该图谱的智能体可以沿着这些关联路径探索,从而获得向量检索永远无法发现的洞察。
在数据库理论中,这些内容并非新鲜事物。将其严格应用于智能体系统才是创新之处,而且当前时机也恰到好处。得益于更出色的大语言模型推理能力、改进过的工具调用接口以及更完善的编排框架,智能体处理流程已足够成熟,如今知识层反而成了瓶颈。即便智能体架构毫无缺陷,如果其底层知识表示方式过于简单且相互孤立,依然会产生错误结果。
该方法分为四种架构模式,分别对应智能体生命周期中的不同阶段:知识对齐、规划、执行和自我修正。这些模式合在一起构成了实际生产系统的设计蓝图,而非纯粹的理论探讨。
为何这很重要
基于检索的生成模型往往较为脆弱,其故障也难以追踪。当输出错误答案时,原因往往隐藏不见:可能是检索效果不佳、分块边界设置错误,或是模型与给定上下文相矛盾。而使用平面向量搜索时,则只能靠猜测。若将知识图谱引入流程,可几乎免费实现可解释性,因为遍历路径本身就是推理轨迹。
在受监管的行业里,这一点尤为重要。医疗、金融和法律科技领域都需要能够展示工作过程的AI。能够说明某个答案背后的三个图节点及两次关系跳转的系统可以被审计,而仅能提供前k个余弦相似度结果的系统则无法被审计。对于那些在严格合规要求下部署AI的团队而言,这正是能否将技术投入实际应用与仅停留在实验室概念验证之间的区别。
还存在一种可靠性方面的优势。在代理系统中,错误的决策会引发连锁反应,链条初期的一个错误决定就会影响之后的所有环节。图结构则起到了结构化防护的作用:代理在继续处理之前可以将其中间结论与图结构进行比对,从而及早发现偏差。这就好比在推理流程中内置了事实核查机制,而非在流程末尾才添加。
或许最被低估的优势在于无需重新训练即可更新知识。使用嵌入模型时,添加新事实往往意味着需要重新嵌入大量数据,还可能扰乱现有的检索行为。而使用图结构,只需添加节点和边,代理的推理就能立即反映这些变化。在金融市场、医学研究以及不断发展的软件生态系统等变化迅速的领域,这无疑具有巨大的运营优势。
实际应用中的四种模式
1. 基于知识的提示
第一种模式将智能体的初始上下文锚定在结构化事实中,而非模糊相似性结果中。无需检索看似相似的段落,而是查询图结构以找到与用户意图相关的子图,再将该结构化上下文注入提示词中。
from neo4j import GraphDatabase
import json
def get_grounded_context(user_query: str, entity_extractor, driver) -> str:
# Step 1: Extract entities from the user query
entities = entity_extractor(user_query) # e.g., ["Product X", "Supplier Y"]
# Step 2: Pull a relevant subgraph from Neo4j
with driver.session() as session:
result = session.run(
"""
MATCH (e)-[r]-(connected)
WHERE e.name IN $entities
RETURN e.name AS entity,
type(r) AS relationship,
connected.name AS related_entity,
connected.attributes AS attributes
LIMIT 50
""",
entities=entities
)
subgraph = [record.data() for record in result]
# Step 3: Format subgraph as structured context
context_str = json.dumps(subgraph, indent=2)
grounded_prompt = f"""
You are a reasoning agent. Use ONLY the following structured knowledge to answer.
If the answer isn't derivable from this context, say so explicitly.
KNOWLEDGE GRAPH CONTEXT:
{context_str}
USER QUERY: {user_query}
"""
return grounded_prompt
看看这里发生了什么。智能体并非寻找与问题相似的文档,而是提取具体的实体,获取这些实体的关联信息,并将其作为结构化上下文注入。大语言模型得到的是一张地图,而之前它得到的一只是一堆关联松散的段落。
2. 图谱引导的规划
第二种模式用于多步骤规划。智能体会将复杂目标分解为可执行的步骤,而这些步骤必须基于当前知识状态下实际可行的内容。图谱使得规划不再那么随意。
比较一下没有地图和有地图时的公路旅行规划。没有地图时,路线只是看似合理;而有地图时,路线会遵循真实的道路、距离和限制条件。图谱就起到了地图的作用。
def plan_with_graph(goal: str, graph_schema: dict, llm) -> list[dict]:
schema_str = json.dumps(graph_schema, indent=2)
planning_prompt = f"""
You are a planning agent. Given the goal below, decompose it into steps.
Each step must reference a valid entity type or relationship from the schema.
Do not invent steps that require knowledge outside this schema.
GRAPH SCHEMA:
{schema_str}
GOAL: {goal}
Return a JSON list of steps. Each step must include:
- "action": what to do
- "graph_query": the Cypher query to retrieve required context
- "depends_on": list of prior step indices this step requires
"""
raw_plan = llm.complete(planning_prompt)
plan = json.loads(raw_plan)
return plan
关键在于将graph_schema注入规划器中。智能体只能规划图结构所支持的步骤,这大大减少了错误规划的出现,因为它无法提出依赖于知识模型中不存在的数据关系的操作。
3. 带有图结构验证的执行
在执行过程中,智能体会逐步采取行动并生成部分结果。第三种模式要求在接受每个中间结果之前先对其与图结构的一致性进行验证。例如,如果智能体判定是供应商Y导致了产品X出现的缺陷,系统应立即确认图中是否存在该供应商与该产品之间的关联,若不存在则标记该结论为错误。
def execute_with_validation(step: dict, intermediate_result: str, driver, llm) -> dict:
# Extract claims from the intermediate result
claim_extraction_prompt = f"""
Extract all factual claims from this text as a list of (subject, predicate, object) triples.
TEXT: {intermediate_result}
Return as JSON array.
"""
claims = json.loads(llm.complete(claim_extraction_prompt))
validation_results = []
with driver.session() as session:
for claim in claims:
result = session.run(
"""
MATCH (s {name: $subject})-[r]-(o {name: $object})
WHERE type(r) = $predicate OR $predicate IN r.aliases
RETURN count(r) AS match_count
""",
subject=claim["subject"],
predicate=claim["predicate"],
object=claim["object"]
)
record = result.single()
validation_results.append({
"claim": claim,
"validated": record["match_count"] > 0
})
unvalidated = [v for v in validation_results if not v["validated"]]
return {
"result": intermediate_result,
"validated": len(unvalidated) == 0,
"flagged_claims": unvalidated
}
可以说,这正是大多数实际应用价值所在。它将连续幻觉检测器作为推理过程的结构性组成部分嵌入执行循环中,而非事后添加的机制。未经验证的声明不会导致系统崩溃,而是会被标记出来,以便智能体对其进行修正或提交给人类审核。
4. 通过图遍历实现自我修正
第四种模式实现了循环闭合。在检测到不一致或收到负面反馈时,智能体不会盲目重试,而是通过图结构寻找其他推理路径,从而让智能体能够在遇到错误输入时优雅地处理问题,而非陷入无限循环。
假设该智能体正在调查合规检查失败的原因。它从触发故障的实体开始,沿着关联关系向外查找,最终发现某个缺失的环节,比如还有尚未与受影响的产品类别关联的法规更新。这是图结构中的漏洞,而非大语言模型本身的问题,智能体可以明确报告这一点:由于指定的法规更新与医疗产品类别之间不存在关联关系,因此无法验证该结论。这是一种可处理的错误,而非幻觉。
应如何处理
不要急于移除向量数据库。首先要弄清楚在当前领域中哪些地方需要结构化处理。列出涉及的实体及其相互关系,然后分析智能体需要回答的问题,统计其中有多少问题需要连续查询多个事实中的链接。如果大多数难题都属于这种情况,那么根本问题就是图论问题。
在工具方面,Neo4j是最成熟的图数据库,其Python SDK能与LangChain和LlamaIndex很好地集成。根据运行环境的不同,Amazon Neptune和Memgraph也是不错的替代选择。在任务编排方面,可以考虑LangGraph,它的状态处理方式类似于图遍历。智能体的推理状态本身就存在于图结构中,因此将外部知识图谱与之结合使用显得十分自然。
一个可行的实施步骤是从模式一开始,该模式要求对您已有的RAG系统进行最小的改动。首先围绕最重要的实体和关系构建第一个图结构,然后将基于真实信息的提示的幻觉率与基准值进行比较。如果这些比率如预期般下降,那么您就有了为其余三种模式争取采用的依据。
需要注意的是:图结构的构建绝非易事。杂乱、不一致或标注不当的源数据会导致图结构混乱,进而使智能体行为也出现问题,因此“垃圾进,垃圾出”的原则在这里同样适用。在投入图结构基础设施之前,应先重视数据质量与本体设计。一个结构清晰、包含10,000个节点的图,其性能会优于一个庞大但杂乱、包含1000万个节点的图。
其意义所在
未来的发展方向是那些不仅能检索和生成内容,还能持续维护其所处世界结构化模型的智能体。它们利用这些模型进行推理、规划,并在开放环境中自我修正。能够区分仅能回答问题的AI与真正能解决问题的AI的关键,在于知识的表现形式,而图结构正是目前最有效的解决方案之一。
在任何系统中都可以验证这一点:如果某个智能体明天做出了错误决策,能否准确找出原因?若无法做到,生产过程就会在盲目状态下进行。这四种特征表明,理想的智能体应当能够展示其推理过程、检验自身结论,并以可调试的方式出错,而这正是生产级AI所需具备的形态。率先实现这一目标的团队,必将超越那些仍停留在计算余弦相似度、困惑于智能体为何屡次失误的团队。
相关阅读
- 实用指南:构建可用于生产环境的智能欺诈检测系统 — 详细讲解如何构建可用于生产环境的智能欺诈检测系统:包括相关合同、验证步骤以及供采用该架构的团队直接使用的代码片段。
- 为企业多智能体平台实现真正的语义检索 — 如何将企业多智能体平台升级为具备真正语义检索功能的系统:包括基于词义的分块处理、ChromaDB中的余弦距离计算、测试层以及后续的RetrievalAgent开发步骤。