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

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

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

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

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

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

1. RAG的优势与短板

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

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

典型表现：

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

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

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

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

图谱查询示例：

MATCH(c:Company{name:"Apple"})-[:CEO]->(person)RETURNp.name

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

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

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

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

核心流程

🔹 示例：苹果CEO是谁？

#Step1:RAG生成候选candidate=rag_ask("WhoistheCEOofApple?")#返回"TimCook"#Step2:用Cypher验证query=f"""MATCH(:Company{{name:'Apple'}})-[:CEO]->(erson{{name:'{candidate}'}})RETURNcount(*)>0asexists"""verified=neo4j.run(query)ifverified:print(candidate)else:print("Answeruncertain")

✔ 好处：

• 泛化强：可以从未标注语料发现答案

• 可靠性高：图谱作为事实校验器

✔ 适用场景：

• 开放域问答

• 文档中表达模糊的事实推断

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

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

流程

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

#1.查询图谱query="""MATCH(c:Company{name:'Apple'})-[:CEO]->(person)RETURNp.nameasceo"""ceo=neo4j.run(query)[0]["ceo"]#2.交给模型生成自然语言answer=llm.generate(f"TheCEOofAppleis{ceo}.Expandbriefly.")print(answer)

✔ 优点：

• 结构化答案准确

• 可解释性强（图谱推理链清晰）

✔ 适用场景：

• 股权关系

• 职位/地址/比例类问题

• 企业数据问答系统

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

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

流程示意

🔹 示例代码思路

rag_answer,rag_conf=rag_with_conf("WhoisAppleCEO?")kg_answer,kg_conf=kg_with_conf("WhoisAppleCEO?")#简单融合算法ifkg_conf>rag_conf:final=kg_answerelse:final=rag_answer

✔ 优点：

• 兼顾广度 + 深度

• 综合评判，准确性更强

✔ 适用领域：

• 金融问答

• 企业问答平台

• 需要高可信度的智能问答系统

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

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

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

① 双向验证

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

伪代码示例：

ifnotkg_verify(rag_answer):rag_answer=Noneifnotrag_evidence(kg_answer):kg_answer=None

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

Cypher示例：

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

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

WHEREr.valid_until>date()

③ LLM仲裁机制

伪代码：

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

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

④ 用户反馈闭环

简单机制示例：

ifuser_flagged_wrong:log_error(question,wrong_answer)improve_kg_and_rag(question)

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

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

场景：

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

系统工作流

关键代码结构示例

KG遍历：

MATCH(a:Company{name:"A"})<-[:HOLDS*1..5]-(s:Shareholder)RETURNs.name,SUM(s.shares)astotalSharesORDERBYtotalSharesDESCLIMIT1

融合：

candidate_from_rag=rag_search("Acompanyshareholderstructure")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. 示例工作流架构图（伪代码）

defanswer_question(q):rag_candidates=rag_search(q)kg_candidates=graph_query(q)scored=fusion_score(rag_candidates,kg_candidates)best=pick_max(scored)returnllm_generate(best)

3. 可解释性展示机制

{"answer":"TimCook","evidence":{"document":"2023Appleannualreport","graph_path":"Apple->CEO->TimCook"},"confidence":0.91}

这类输出结构让系统具有审计性、可信度和企业采用价值。

八、总结

✔ RAG + KG 不是技术叠加，而是推理协同与双向校验

✔ 三种融合策略：

场景	策略
开放域推断	先RAG后KG
结构化事实问答	先KG后生成
高可信决策系统	并行融合

✔ 未来方向：

• 自动化图谱构建

• 更智能的联合推理

• 自进化反馈闭环

一句话收尾：下一代AI系统必须会“查证”，不仅会“讲话”。