为什么我的 GraphRAG 上线就崩？把知识图谱和 RAG 结合起来后的真实踩坑-平芜编程栈

这篇不先堆名词。我们把《一次GraphRAG项目复盘，问题最后出在流程而不是模型》拆成几级台阶，看完至少知道下一步该学什么、该练什么。

摘要

摘要：传统 RAG 在小团队落地时往往在检索阶段“卡脖子”，本文结合一次实际项目复盘，从实体抽取、图结构建模到检索增强，分享避免过度设计、提升可用性的具体做法与代码示例。

目录：
1. 传统 RAG 的瓶颈
2. 知识图谱建模：从“全量”到“关键路径”
3. 实体关系抽取：用轻量级模型 + 后处理兜底
4. 图检索增强：把 RAG 查询变成图遍历
5. 评估与优化：关注 recall@k 和响应延迟
6. 总结

---

传统 RAG 的瓶颈

之前我们做了一个内部知识库问答系统，只用向量检索（RAG），初期效果还行：用户问“怎么申请报销”，系统能从文档里找到匹配段落返回。但实际测试中，遇到多步推理或跨文档关联的问题，比如“报销流程里，哪些岗位需要二级审批？”，RAG 只能返回单篇文档片段，答案拼起来不一致，甚至出现矛盾。

在小团队里，我们没有资源去训练大型多跳推理模型，只能从检索端入手。于是想到把知识图谱（KG）和 RAG 结合：用图表达实体与关系，让检索不只是相似度匹配，还能沿着关系链跳转。但真正落地时，问题出在“建模太全”“抽取太贵”“检索太慢”。

知识图谱建模：从“全量”到“关键路径”

最初我们想把公司所有制度、流程、人员角色都建进图谱，结果图谱节点上万、边数更多，查询时遍历开销极大，响应时间从秒级变成分钟级。后来我们做了取舍：只保留高频查询涉及的实体和关系，比如“岗位 - 审批权限”“文档 - 适用部门”“员工 - 所属团队”，其余用向量检索兜底。

建模策略上，不追求完整，而是围绕典型问题反向推导。例如，针对“报销”类问题，我们提取以下核心实体和关系：

实体：报销单、岗位、审批层级、适用政策文档
关系：岗位 -> 需要 -> 审批层级，报销单 -> 关联 -> 岗位，政策文档 -> 规定 -> 审批层级

这样图谱规模控制在几百个节点，查询时只需沿着几条关键边遍历，速度明显提升。

实体关系抽取：用轻量级模型 + 后处理兜底

我们尝试用过大的 NER+RE 模型（如 Llama3-70B），不仅推理慢，而且对小语料的适配差。后来改用轻量模型（如 BERT + CRF 做命名实体，规则+小模型做关系抽取），再结合后处理校验：

1. 抽取实体后，用规则过滤掉明显不合理的组合（如“岗位 - 审批层级”关系不能出现在非制度类文档中）；
2. 对抽取结果进行人工抽检，修正错误样本，训练一个小的纠错模型；
3. 最终图谱中的关系，只保留置信度 >0.8 的边。

示例抽取代码（简化版）：

import spacy nlp = spacy.load("zh_core_web_sm") def extract_entities(text): doc = nlp(text) return [(ent.text, ent.label_) for ent in doc.ents] # 示例 text = "财务报销需要二级审批，适用于研发部员工" print(extract_entities(text)) # 输出: [('财务报销', 'ORG'), ('二级审批', 'MISC'), ('研发部', 'ORG')]

后续再结合规则匹配，将“二级审批”与“岗位”关联，生成(研发部, 需要, 二级审批)这样的三元组。

图检索增强：把 RAG 查询变成图遍历

在检索时，我们不再只依赖向量相似度，而是把用户查询解析成图查询模式。例如问“哪些岗位需要二级审批？”，系统会：

1. 识别出关键词“岗位”“二级审批”，映射到图中的实体和关系；
2. 执行图遍历：从岗位节点出发，沿着需要 -> 审批层级边，筛选出值为“二级审批”的节点；
3. 将图检索结果与向量检索结果融合：图返回的文档 ID 作为召回种子，再在向量空间做二次排序。

伪代码示例：

def graph_rag_query(query, graph, vector_store): # 1. 图检索：获取相关节点和文档 IDs node_ids = graph.traverse(query) # 返回候选节点/文档 ID 集合 # 2. 向量检索：在种子基础上做语义排序 docs = vector_search(query, candidates=node_ids, top_k=5) return docs

这种混合检索方式在多跳问题上表现更稳定，尤其在图谱覆盖范围内，答案更准确、更少矛盾。