我要投稿

先RAG后KG，还是先KG后RAG？我们试了三种策略

发布日期：2025-12-28 17:35:14 浏览次数： 1520

作者：智能体AI

微信搜一搜，关注“智能体AI”

近两年，大模型应用从“能聊两句”走到了“能干活”，而RAG（检索增强生成）与知识图谱（Knowledge Graph，KG）几乎成了构建企业智能问答系统的标配。

但问题来了——很多团队“写了文章、拉了框图”，实际项目却效果一般，要么搜索不到关键信息，要么模型一本正经胡说八道。

根本原因：你只是把RAG和KG放在一起，而不是让它们互相校验与协同推理。

今天我们不仅讲三种融合策略，还带上工作流、示例代码、防错机制——让你既懂原理，又知道如何落地。

一、单打独斗的瓶颈，融合才是王道

1. RAG的优势与短板

✔ 擅长从海量文档中捕捉潜在线索

✘ 但容易“合理地胡说”（hallucination）

典型表现：

用户问：苹果CEO是谁？文档没说清楚 → 模型可能生成 Cook、Jobs甚至 Jony Ive。

2. 知识图谱的优势与短板

✔ 知识结构清晰、查询可靠

✘ 构建成本高，难覆盖长尾问题

图谱查询示例：

MATCH (c:Company {name:"Apple"})-[:CEO]->(p:Person)RETURN p.name

结果是Tim Cook，可靠，但前提是：你图谱里必须有这个关系。

于是——一个擅长广度，一个擅长深度，真正强大的是让两者组合。

二、策略一 ▌先RAG后KG —— 大胆假设，小心求证

先让RAG“猜”，再让KG“验”。

核心流程

🔹 示例：苹果CEO是谁？

# Step 1: RAG生成候选candidate = rag_ask("Who is the CEO of Apple?")  # 返回 "Tim Cook"# Step 2: 用Cypher验证query = f"""MATCH (:Company {{name:'Apple'}})-[:CEO]->(:Person {{name:'{candidate}'}})RETURN count(*) > 0 as exists"""verified = neo4j.run(query)if verified:    print(candidate)else:    print("Answer uncertain")

✔ 好处：

泛化强：可以从未标注语料发现答案
可靠性高：图谱作为事实校验器

✔ 适用场景：

开放域问答
文档中表达模糊的事实推断

三、策略二 ▌先KG后RAG —— 证据确凿，再娓娓道来

先取结构化答案，再让LLM写成自然语言。

流程

🔹 示例代码：查询CEO并生成自然表述

# 1. 查询图谱query = """MATCH (c:Company {name:'Apple'})-[:CEO]->(p:Person)RETURN p.name as ceo"""ceo = neo4j.run(query)[0]["ceo"]# 2. 交给模型生成自然语言answer = llm.generate(f"The CEO of Apple is {ceo}. Expand briefly.")print(answer)

✔ 优点：

结构化答案准确
可解释性强（图谱推理链清晰）

✔ 适用场景：

股权关系
职位/地址/比例类问题
企业数据问答系统

四、策略三 ▌并行融合 —— 双管齐下，看谁靠谱

RAG和KG同时独立推，然后结果合并评判。

流程示意

🔹 示例代码思路

rag_answer, rag_conf = rag_with_conf("Who is Apple CEO?")kg_answer, kg_conf = kg_with_conf("Who is Apple CEO?")# 简单融合算法if kg_conf > rag_conf:    final = kg_answerelse:    final = rag_answer

✔ 优点：

兼顾广度 + 深度
综合评判，准确性更强

✔ 适用领域：

金融问答
企业问答平台
需要高可信度的智能问答系统

五、难点剖析：如何防止“错误传播”？

融合之后最大问题不是错，而是：一个系统错了，另一个系统也跟着错。

我们需要防错体系，四大机制如下：

① 双向验证

RAG说的要图谱确认，KG说的要RAG找证据。

伪代码示例：

if not kg_verify(rag_answer):    rag_answer = Noneif not rag_evidence(kg_answer):    kg_answer = None

② 时效性过滤（信息有效期属性）

Cypher示例：

MATCH (c:Company {name:"Apple"})-[r:CEO {valid_until: null}]->(p:Person)RETURN p.name

若valid_until 已过期，则自动过滤：

WHERE r.valid_until > date()

③ LLM仲裁机制

伪代码：

if rag_answer != kg_answer:    final = llm_judge(        question=question,        evidence_rag=evidence_from_docs,        evidence_kg=graph_chain_path    )

模型作用：不是生成答案，而是做事实仲裁。

④ 用户反馈闭环

简单机制示例：

if user_flagged_wrong:    log_error(question, wrong_answer)    improve_kg_and_rag(question)

这是一套持续进化系统，而不是一次性上线。

六、实战案例：构建企业股权多跳问答系统

场景：

用户问：“A公司的最大股东是谁？”

系统工作流

关键代码结构示例

KG遍历：

MATCH (a:Company {name:"A"})<-[:HOLDS*1..5]-(s:Shareholder)RETURN s.name, SUM(s.shares) as totalSharesORDER BY totalShares DESC LIMIT 1

融合：

candidate_from_rag = rag_search("A company shareholder structure")kg_answer = neo4j.query(multihop_query)final_answer = combine(candidate_from_rag, kg_answer)

输出示例：

A公司的最大股东是B集团，持股比例45%。股权路径：A ← B投资公司 ← B集团。

七、工程化落地指南

1. 技术选型

✔ Neo4j → 图谱构建

✔ Cypher → 图查询

✔ LlamaIndex → RAG检索与上下文增强逻辑

✔ LangChain 或 Workflow Orchestration → 协同链设计

2. 示例工作流架构图（伪代码）

def answer_question(q):    rag_candidates = rag_search(q)    kg_candidates = graph_query(q)    scored = fusion_score(rag_candidates, kg_candidates)    best = pick_max(scored)    return llm_generate(best)

3. 可解释性展示机制

{  "answer": "Tim Cook",  "evidence": {    "document": "2023 Apple annual report",    "graph_path": "Apple -> CEO -> Tim Cook"  },  "confidence": 0.91}