这篇我按“先跑起来、再讲取舍”的方式写《GraphRAG火了之后，为什么团队反而更关心维护成本？》。概念会讲，但重点放在代码怎么组织、哪里容易踩坑。

摘要

最近业务方提了个需求：用GraphRAG做企业知识库，复杂问答要能溯源到具体文档段落。团队里有人用Codex本地跑过Demo，效果看着不错，信心满满。结果真正开始联调，几个关键问题全暴露了——实体抽取不稳定、图更新跟不上、检索结果对不上文档版本，最后连权限和日志都理不清。

这不是GraphRAG本身的问题，而是从个人Demo到团队协作，缺了一层工程化判断。今天把这套流程复盘一遍，重点是踩过的坑和选型判断。

目录

• 传统RAG的瓶颈，不只是召回率
• 知识图谱建模，别一上来就搞全量
• 实体关系抽取，开源模型够用但要有校验
• 图检索增强，核心是路径查询
• 评估与优化，别只看准确率
• 总结

传统RAG的瓶颈，不只是召回率

先说结论：纯向量检索做企业知识库，三个硬伤绕不开。

第一，跨文档推理能力弱。问"张总和李总上周的决策冲突在哪"，传统RAG只能分别召回两段内容，无法建立人物关系链，答案大概率是拼凑的。

第二，事实一致性难保证。向量检索本质是相似度匹配，容易召回语义相近但事实矛盾的内容，大模型直接生成，幻觉风险高。

第三，可解释性差。业务方问"这个答案从哪来的"，只能给一段文本片段，无法追溯到实体和关系路径。

GraphRAG解决的是第一个问题：把知识结构化，让模型能在图上做推理。但引入图谱后，维护成本呈指数上升，这也是团队翻车的主要原因。

知识图谱建模，别一上来就搞全量

很多项目踩的第一个坑：先把所有文档喂进图谱，结果实体爆炸，关系混乱，后续维护成本极高。

我的判断标准是：先做最小可用图谱。

针对企业知识库场景，核心实体就三类：人物、文档、概念。关系也只需要三类：人物-撰写-文档、文档-引用-概念、人物-参与-概念。够用了，其他关系等业务方提需求再补。

建模时注意两点：

1. 实体命名统一。人名用"姓名+职务"格式，避免"张总"和"张三"被识别成两个实体。
2. 文档切片保留元数据。每段文本要带文档ID、页码、来源，否则检索回来不知道从哪来的。

实体关系抽取，开源模型够用但要有校验

GraphRAG开源后，微软的方案是用GPT-4做实体抽取，成本高、延迟长。实际项目里，我们试过几个方案：

• GPT-4：效果好，但企业知识库每天更新量大，成本扛不住
• Claude 3.5 Sonnet：抽取质量接近GPT-4，价格低一半，团队试用后选了这个
• 本地Qwen2.5-72B-Instruct：部署后抽取质量下降明显，尤其是长文档的关系抽取，召回率低

关键判断：抽取质量直接影响图检索效果，宁可多花点钱用好的模型，也不要为了省成本用本地小模型凑合。

抽取后的校验环节不能省。我们加了个规则层：人名必须匹配HR系统，文档ID必须能在文档库找到，否则直接标记异常让业务方确认。这一步在个人Demo里常被省略，但团队协作时，数据不准会引发连锁问题。

图检索增强，核心是路径查询

传统RAG的检索是向量相似度，GraphRAG的检索是图遍历。

Neo4j的Cypher查询是核心能力。举个例子，业务方问"技术部最近三个月的所有决策"，查询逻辑是：

MATCH (person:Person)-[:MEMBER_OF]->(dept:Department {name: '技术部'})
MATCH (person)-[:MADE_DECISION]->(decision:Decision)
WHERE decision.date >= datetime() - duration({months: 3})
RETURN decision.title, decision.content, decision.date
ORDER BY decision.date DESC
LIMIT 10

这个查询能直接返回决策标题、内容和时间，比向量检索的召回更精准。

但图检索也有坑：

1. 图太小检索路径少，效果不如向量。我们踩过这个坑，图谱建完只有几百个实体，检索效果反而比纯向量差。后来补了三个月的业务数据，图规模上来后才稳定。
2. 查询构建依赖业务方输入。业务方问的问题格式多变，需要有个意图识别层把自然语言转成Cypher，这一步用规则模板比用LLM更稳定。

评估与优化，别只看准确率

团队接手后，评估维度要和Demo阶段不一样。

个人Demo看准确率就够了，团队协作还要看：

1. 图谱更新时效。业务方每天新增文档，图谱多久能同步？我们定的是T+1，关键文档支持实时入库。
2. 检索可追溯性。答案能追溯到具体文档段落和实体关系，这是GraphRAG的核心价值，也是业务方最看重的。
3. 权限控制。不同部门的人问同一个问题，返回结果要按权限过滤。这一步在Demo阶段常被忽略，但企业场景是刚需。

优化方向上，我们做了两件事：

一是检索策略混合。复杂问题走图检索，简单事实问题走向量检索，用分类器自动路由，兼顾效果和成本。

二是日志和权限打通。每个检索请求记录输入、查询路径、返回结果，方便排查问题；同时接入企业SSO，权限判断前置到检索层，避免答案泄露。

总结

GraphRAG不是银弹，它解决的是跨文档推理和可追溯性问题，但引入了图谱维护和权限控制的复杂度。

个人跑通Demo和团队接手上线是两回事。Demo阶段关注的是效果，团队协作阶段关注的是维护成本、权限安全和日志可追溯。选技术路线时，先想清楚业务方要解决什么问题，再决定要不要上GraphRAG，而不是因为火就跟进。

团队里有人用AI编程工具快速搭出Demo，这是好事。但Demo能跑和能上线之间，隔着工程化能力的差距。把权限、日志、数据校验这些环节补上，GraphRAG才能真正在企业里用起来。

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。