AI知识图谱2026：GraphRAG、实体抽取与真实用例
向量搜索能返回相似片段，却答不出这几家公司之间是什么关系。知识图谱补上了关系这一维，GraphRAG让它重新变热。这篇给一套能跑起来的技术栈和最小实验。
📜 目录
AI知识图谱2026：GraphRAG、实体抽取与真实用例
向量搜索能返回相似片段，却答不出"这几家公司之间是什么关系"。知识图谱补上了关系这一维，GraphRAG让它重新变热。这篇给一套能跑起来的技术栈和一个周末能做完的最小实验。
一、什么时候真的需要图
先别急着建图。三个信号说明你需要：
- 问题需要跨文档连接事实："供应商X的召回影响了哪些产品"，答案散在采购单、BOM、售后记录里。
- 问题要多跳：A的母公司B的子公司C，向量检索只能分别找到三段文字，拼不出路径。
- 你要聚合视角："这批文档里主要分成哪几个主题、各自涉及谁"，这是GraphRAG的社区摘要擅长的。
反例同样清楚：单文档问答、语义相似就能解决的检索、文档量小于几百篇，向量RAG加好的切块策略通常够用，建图只是给自己加账单。
二、GraphRAG的五个步骤
- 切块：按段落或语义切，每块保留来源ID，后面所有事实都要能溯源。
- 实体关系抽取：对每块调用LLM，输出实体与三元组（主语-关系-宾语）。
- 实体消歧：同一实体在不同块里写法不同（"阿里巴巴"和"阿里"），需要归并。常见做法是归一化名称 + 向量相似度聚类 + 人工抽检。
- 建图：实体做节点，关系做边，边上带来源块ID和抽取置信度。
- 查询：从实体出发做多跳遍历，或者先生成社区摘要再回答全局性问题。
三、抽取提示词：schema 先行
抽取质量取决于约束得够不够死。给它一个明确的JSON结构，并要求"抽不到就返回空数组"，比让它自由发挥稳定得多：
EXTRACT_PROMPT = '''从下面的文本中抽取实体和关系。
只输出JSON，不要解释。格式：
{"entities":[{"name":"", "type":"公司|产品|人物|地点", "desc":""}],
"relations":[{"head":"", "relation":"", "tail":""}]}
relation 只能是：供应、属于、投资、任职、合作、竞争。
抽不到就返回空数组。
文本：
{chunk}
'''
再补两条工程约束：temperature=0，输出用结构化输出或JSON模式；对解析失败的块重试两次，仍失败就记下来人工看，别把脏数据灌进图。
四、存储与查询
小规模实验用嵌入式图库最省事，生产多用 Neo4j。Cypher 写多跳查询比写SQL直观：
// 一家供应商供的零件，被哪些产品用到了
MATCH (s:Supplier {name:$name})-[:SUPPLIES]->(part:Part)
<-[:USES]-(p:Product)
RETURN DISTINCT p.name AS product
ORDER BY product
反向也常用：给定一个产品，回溯它的全部上游，找单点依赖。这类查询在向量库里没有对应写法，只能多次检索再在代码里拼，容易漏。
五、混合检索：别二选一
实践里最稳的是"向量召回 + 图扩展"：
# 1. 向量检索拿到入口片段
hits = vector_store.search(query, k=5)
# 2. 从片段里识别实体
ents = [e for h in hits for e in extract_entities(h.text)]
# 3. 在图上做1-2跳扩展，拿回关联事实
facts = graph.expand(ents, hops=2, limit=30)
# 4. 向量片段 + 图事实一起塞进上下文
context = render(hits) + render(facts)
要点是限制跳数和返回条数。不设上限的图扩展会把上下文塞满，成本上升、答案变差。
六、成本现实
| 文档规模 | 抽取调用量级 | 说明 |
|---|---|---|
| 500篇 | 数百到一千次 | 周末项目，成本可控 |
| 1万篇 | 数万次 | 需要批处理通道和失败重试队列 |
| 10万篇以上 | 数十万次 | 先算账，再考虑只对高价值子集建图 |
建图是一次性成本，但文档更新就要增量抽取。真正常态化的做法是：只为那5-10%真正多跳的问题建图，其余继续走向量检索。
七、怎么验收抽取质量
图上线前必须抽检，因为它错了很难被发现。抽50-100个块，人工核对三个指标：
| 指标 | 怎么算 | 参考线 |
|---|---|---|
| 实体精确率 | 抽出的实体里正确的比例 | 低于90%要重调提示词 |
| 关系精确率 | 抽出的三元组里正确的比例 | 低于85%不要上线 |
| 覆盖率 | 人工标注的关系被抽出的比例 | 低于70%说明漏得太多 |
为什么关系精确率要求更严：一条错误的关系会在多跳查询里被反复走到，错误被放大；而漏抽只是少一条路径，通常还有别的路。
抽样时特意挑三类块：表格、列表、跨段指代（"该公司""上述产品"）。这三处是抽取最容易出问题的地方。
八、常见问题
Q：GraphRAG 一定比向量RAG准吗？ A：在多跳和全局聚合类问题上通常更好，在"找一段相似文字"这类任务上没有优势，还更贵。按问题类型选，不要全站替换。
Q：实体消歧必须做吗？ A：必须。不消歧的图里，"阿里"和"阿里巴巴"是两个节点，多跳查询直接断链。至少做名称归一化。
Q：抽取用便宜模型行不行？ A：可以，但要用抽样人工核对。抽取错误会以边的方式永久留在图里，比检索错误更难发现。
Q：多久更新一次图？ A：跟文档更新节奏走，做增量。全量重建只在新schema上线时做。
注：各图数据库与GraphRAG实现的能力和限制以官方文档为准。
相关文章
本站文章由编辑人工撰写，收录的工具均经过实测或公开资料核验。文中链接指向工具官网或 GitHub 仓库，仅作信息参考，不构成付费推广。