GraphRAG 跑通 Demo 后，为什么团队接手第一天就翻车？

聊《GraphRAG到底能不能干活别只看 Demo 和跑分》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要上个月我们团队把 GraphRAG 接入了一个企业内部知识库项目。Demo 阶段挺好看问答准确率从 68% 提到 82%汇报 PPT 做得漂漂亮亮。结果交接给运维和后端同学上线第一天就炸了——权限配置对不上日志查不到链路文档里连图构建的触发时机都没写清楚。我复盘了一下发现 GraphRAG 最难的从来不是跑通而是从 Demo 到生产这段路。今天就把这次踩过的坑和判断标准摊开讲讲。目录传统 RAG 的瓶颈GraphRAG 能解决什么知识图谱建模我们怎么建的实体关系抽取踩过的最大坑图检索增强怎么和向量检索配合权限、日志和可观测Demo 到生产的真正门槛适用边界什么时候该用 GraphRAG总结传统 RAG 的瓶颈GraphRAG 能解决什么我们之前用的传统 RAG 方案本质上是把文档切片后做向量检索召回 Top-K 片段喂给模型。这种做法有几个硬伤第一切片丢失了文档结构。一段技术文档里第三章和第四章的关系、同一个实体在不同段落出现的关联向量检索抓不住。第二答案分散。一个问题涉及多个文档片段时模型需要自己拼凑容易出现幻觉或遗漏。第三可解释性差。用户问为什么审批流程要三天传统 RAG 只能给你几个相似片段但你没法告诉用户这个结论来自哪些实体之间的关系。GraphRAG 的思路是把文档结构化抽实体、抽关系、建图然后检索时先走图结构再结合向量召回。这样答案有迹可循也更容易做权限控制。知识图谱建模我们怎么建的项目场景是企业的制度知识库包含员工手册、审批流程、财务规定等文档。我们的建模思路比较朴素没有上复杂的本体设计直接按业务域分层# 实体类型定义 ENTITY_TYPES { Policy: {label: 制度, properties: [doc_id, version, effective_date]}, Process: {label: 流程, properties: [process_id, step_count]}, Role: {label: 角色, properties: [dept, level]}, Rule: {label: 规则, properties: [condition, action]} } # 关系类型定义 RELATION_TYPES { BELONGS_TO: {source: Policy, target: Policy, properties: [parent_doc]}, APPLIES_TO: {source: Rule, target: Role, properties: [scope]}, REQUIRES: {source: Process, target: Role, properties: [approval_level]} }这里有个取舍我们没有做全量本体建模而是先按业务域划分实体类型关系也只在有明确业务含义时才定义。好处是前期投入小能快跑起来坏处是后期如果业务域扩展图结构可能不够灵活。实体关系抽取踩过的最大坑抽取环节我们用 LLM 做信息提取输入是文档段落输出是三元组。这个环节的问题比想象中多。失败原因一实体标准不统一一开始模型把员工和申请人当成两个实体但实际上在审批流程里它们是同一个角色。后来我们在 prompt 里加了实体归一化规则强制映射到预定义的实体类型。失败原因二关系抽取漏掉嵌套结构制度文档里经常有除以下情况外这样的嵌套条件模型容易只抽到主关系漏掉例外情况。我们后来加了多级抽取策略先抽主关系再对例外条款单独抽取。失败原因三抽取质量直接影响检索效果图构建完之后如果实体关系抽得差检索时走图的路径就会断裂。我们遇到过这种情况用户问请假超过三天需要什么审批图检索只召回了三天以内的路径因为超过三天和三天被建模成了两个不相连的实体。排查过程我们加了图连通性检查发现很多实体是孤立节点。后来在抽取阶段增加了实体链接步骤把同义实体合并连通率从 72% 提升到 94%。图检索增强怎么和向量检索配合我们的检索策略是混合的1. 先根据用户问题在图上做多跳检索找到相关实体和关系路径2. 再用向量检索召回补充片段3. 最后把图路径和文本片段一起喂给模型# 图检索核心逻辑 def graph_rag_query(question, top_k3): # 1. 实体识别 entities extract_entities(question) # 2. 图多跳检索 graph_paths [] for entity in entities: paths multi_hop_search(entity, hops2) graph_paths.extend(paths) # 3. 向量补充召回 vector_results vector_search(question, ktop_k) # 4. 融合排序 combined rerank(graph_paths, vector_results, question) return combined[:top_k]代码解释extract_entities用 NER 模型识别问题中的实体输入是用户问题输出是实体列表multi_hop_search是图遍历从实体出发做 2 跳搜索返回路径列表vector_search是传统向量召回作为补充rerank是融合排序图路径权重更高因为可解释性强这里有个取舍我们没有做实时图更新而是每天定时构建。好处是稳定坏处是制度变更后有延迟。后来加了增量构建策略只更新变更文档相关的子图。权限、日志和可观测Demo 到生产的真正门槛这才是这次项目最痛的地方。权限问题GraphRAG 的图里存了制度原文和关系但不同部门看到的制度范围不一样。传统 RAG 可以通过文档级权限控制但图检索时一个实体可能关联多个文档权限怎么降我们的做法是在图检索结果出来后加一层权限过滤但这样会破坏图的完整性——被过滤掉的关系可能导致路径断裂。后来我们改为在实体层面做权限标记检索时优先走有权限的路径。日志问题传统 RAG 的日志好记用户问题 → 检索结果 → 模型输出。GraphRAG 多了图检索这一步链路变成问题 → 实体识别 → 图检索 → 向量召回 → 融合 → 模型输出。我们在日志里记录了每一步的中间结果但第一次排查问题时才发现图检索的路径没有序列化存储只能重跑一遍才能看到路径是什么。后来我们改了设计把图路径作为独立字段存到日志里。可观测性GraphRAG 的准确率评估也比传统 RAG 复杂。我们不仅要看最终答案对不对还要看实体识别准确率图检索路径覆盖率融合排序的合理性这些指标传统 RAG 不需要关注但 GraphRAG 需要。我们后来做了一个监控面板实时显示这些指标。适用边界什么时候该用 GraphRAGGraphRAG 不是银弹我有几个判断标准1. 文档之间有强关联如果知识库里的文档是孤立的传统 RAG 就够了。只有当问题需要跨文档推理时图的价值才体现出来。2. 需要可解释性如果业务方要求告诉我这个结论来自哪里GraphRAG 的路径比向量召回更有说服力。3. 团队有工程能力GraphRAG 的维护成本比传统 RAG 高需要有人懂图数据库、会调抽取质量、能处理权限和日志问题。4. 制度类文档我们这个项目是制度知识库天然适合图结构。如果是问答对这种结构化数据可能没必要上 GraphRAG。不适用场景文档量小几千条以内、问题简单不需要跨文档推理、团队资源紧张没有时间维护图结构。总结GraphRAG 从 Demo 到生产最难的不是算法而是工程化。权限怎么降、日志怎么记、图质量怎么监控这些才是团队接手时的真实门槛。我们这次项目最大的收获是不要只盯着准确率看。图检索的链路更长每个环节都可能出问题。早点把权限、日志、监控这些 boring的事情做好比追求 2% 的准确率提升更重要。如果你也在做 GraphRAG建议先在 Demo 阶段就把权限模型和日志设计想清楚别等上线前夜再补。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。