聊《大家都在聊GraphRAG，企业真正需要的却不是更多 Demo》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。
摘要
前阵子帮一个金融客户做知识问答系统，Demo 阶段 GraphRAG 的召回效果确实惊艳——传统 RAG 找不到的间接关系，图检索能直接拼出来。结果上线第一天就出问题：不同部门的人查到完全不同的答案，日志里根本看不出是谁触发了哪条查询。最后发现，不是模型的问题，是权限配置和可观测性完全没跟上。
这个坑让我意识到，GraphRAG 真正的挑战从来不是图谱构建本身，而是把它从 Demo 变成可上线的系统。今天复盘一下整个过程中踩过的坑和学到的东西。
目录
- 传统 RAG 的瓶颈
- 知识图谱建模
- 实体关系抽取
- 图检索增强
- 评估与优化
- 总结
传统 RAG 的瓶颈
做 GraphRAG 之前，我们先用纯向量检索跑了一版。效果有几个明显问题：
问答"张三个人投资了哪些公司"，向量检索只能召回包含"张三"和"公司"字样的文档片段，但找不到"张三→某基金→某公司"这种间接关系。
多跳推理几乎做不到，用户问"张三的合伙人最近有什么动向"，系统直接返回不相关结果。
上下文拼接混乱，多份文档的片段混在一起，模型不知道哪些信息是相关的。
这些问题在简单场景下不明显，但一旦涉及复杂的企业知识查询，传统 RAG 的短板就暴露了。
知识图谱建模
我们选的是 Neo4j，因为它的 Cypher 查询对复杂关系遍历很友好。建模阶段最大的决策是实体粒度怎么定。
一开始我们把"公司"拆得太细，每个子公司、分公司都作为独立实体，结果图谱规模爆炸，查询性能直接崩了。后来改为只保留一级子公司，母公司关系通过属性关联，图谱大小缩减了 60%，查询延迟也从 800ms 降到了 200ms 以内。
# 实体抽取 Prompt 模板 PROMPT_TEMPLATE = """ 请从以下文本中提取实体和关系，以 JSON 格式输出： 文本：{text} 要求： 1. 实体类型：人物、公司、职位、投资金额 2. 关系类型：投资、任职、控股、关联 3. 只提取明确提及的信息，不推断 4. 输出格式：{"entities": [...], "relations": [...]} """ # 实体去重和合并 def merge_entities(entities: list) -> dict: entity_map = {} for entity in entities: name = entity["name"].strip() if name not in entity_map: entity_map[name] = entity else: # 合并属性，保留最新信息 entity_map[name].update(entity) return entity_map建模过程中另一个踩坑点：属性设计。一开始我们把所有信息都做成属性，结果属性表字段超过 200 个，查询时根本用不上这么多。后来改为核心属性放图结构，扩展属性放文档引用，查询效率明显提升。
实体关系抽取
抽取环节我们用的是"大模型 + 规则校验"的组合。纯大模型抽取的准确率在 85% 左右，但有些明显错误会被过滤掉。
比如模型把"张三和李四是合伙人"抽成"张三→任职→李四"，这种明显不符合业务逻辑的关系，我们加了规则层直接过滤。规则层虽然简单，但能挡住大部分低级错误。
增量更新也是个问题。每天新增的文档量不小，如果全量重跑抽取，成本太高。我们改为只处理新增文档，然后用图查询找出与已有实体相关的新关系，这样抽取量减少了 70%。
图检索增强
图检索的核心思路是：先用查询在图谱中找相关实体，然后扩展邻居节点作为上下文，最后和向量检索结果合并。
# 图检索核心逻辑 def graph_search(query: str, entity: str, hops: int = 2) -> list: # 第一步：找到实体节点 cypher_query = f""" MATCH (n {{name: '{entity}'}}) OPTIONAL MATCH path = (n)-[r*1..{hops}]-() RETURN path """ results = neo4j.query(cypher_query) # 第二步：提取路径中的实体和关系 entities = set() relations = [] for record in results: path = record["path"] for node in path.nodes: entities.add(node["name"]) for rel in path.relationships: relations.append({ "from": rel.start_node["name"], "to": rel.end_node["name"], "type": rel.type }) return entities, relations这里有个关键判断：跳数设为 2 还是 3。跳数越多，上下文越丰富，但查询延迟也越高。我们实测发现，跳数 2 在大多数场景下够用，跳数 3 只在复杂推理时启用，这样平均延迟控制在 500ms 以内。
另一个踩坑点是向量检索和图检索的权重分配。一开始我们简单合并结果，发现图检索的结果质量明显更高，但用户反馈"不够全面"。后来改为图检索结果优先，向量检索结果作为补充，整体满意度提升明显。
评估与优化
上线后我们做了两组对比：
| 指标 | 纯向量检索 | GraphRAG |
|------|-----------|----------|
| 平均响应时间 | 350ms | 520ms |
| 多跳推理准确率 | 42% | 78% |
| 权限问题率 | 0% | 15% |
| 日志可追溯率 | 95% | 30% |
性能差距可以接受，但权限和日志的问题让我意识到：GraphRAG 的工程化难度远高于 Demo 阶段。
权限问题主要来自不同部门的数据隔离。金融客户的数据敏感度高，不同角色能看到的内容差异很大。我们最初没考虑这个，结果查询结果可能泄露其他部门的信息。后来加了权限中间件，在图查询前做权限过滤，才解决这个问题。
日志问题更隐蔽。图查询的链路很长，从实体识别到关系遍历，每一步的耗时和结果都需要记录。我们加了详细的操作日志，包括查询路径、耗时、返回实体数量，这样出问题时可以快速定位。
# 查询日志记录 class QueryLogger: def log(self, query: str, entities: list, relations: list, duration: float, user_id: str): log_entry = { "timestamp": datetime.now().isoformat(), "query": query, "entities": entities, "relations_count": len(relations), "duration_ms": duration * 1000, "user_id": user_id } # 写入日志系统 self.logger.info(json.dumps(log_entry))总结
GraphRAG 的价值在于处理复杂关系查询，但这只是技术问题的一半。另一半是工程化：权限、日志、性能、可维护性。
我的建议是：
1. 不要一开始就追求完美的图谱结构，先用简单模型验证效果
2. 权限和日志要同步设计，不要等上线后再补
3. 跳数、权重等参数要实测，不同场景的最优值不同
4. 增量更新比全量重跑更实用，成本差几倍
GraphRAG 不是银弹，但它确实能解决传统 RAG 搞不定的问题。前提是你能把它从 Demo 变成真正可用的系统。
资料展示
下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。
如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。
