如果你正准备往大模型方向转《一次GraphRAG项目复盘问题最后出在流程而不是模型》这类问题别只看热度。更重要的是判断自己该补哪块能力以及怎么证明你真的会。摘要上周团队上线一个基于 GraphRAG 的企业知识库问答系统起初 demo 跑得丝滑可真正放到内部测试环境后问题一个接一个。最让人头疼的不是模型效果不好也不是知识图谱构建有误而是权限控制没跟上日志也几乎为零。最后排查了一整天才发现崩的不是代码是流程。目录传统 RAG 的瓶颈为什么越做越难知识图谱建模别一上来就造大模型实体关系抽取别全信 LLM要人工校验图检索增强怎么查才快评估与优化别只看准确率要看流程总结流程比模型更重要传统 RAG 的瓶颈为什么越做越难我们一开始用的是经典的 RAG 架构把文档切块向量化用 FAISS 检索再丢给 LLM 生成回答。效果确实不错问答准确率能到 85% 以上。但问题来了文档频繁更新向量索引需要重跑延迟高复杂问题如“上季度华东区销售额比华南高多少”需要跨多个文档推理纯文本检索根本搞不定没有上下文关系模型容易“一本正经地胡说八道”。于是我们决定引入知识图谱把实体和关系显式建模出来。这就是 GraphRAG 的初衷让模型不仅“知道什么”还“知道它们之间有什么关系”。知识图谱建模别一上来就造大模型很多人一听到“知识图谱”就想到 Neo4j、Neo4j Graph Data Science甚至想用 GNN 做实体对齐。其实我们从一个很小的点切入先画一个“最小可运行图谱”。我们以公司内部技术文档为素材用 Python 的spaCy做命名实体识别NER再结合正则规则抽取常见关系比如“作者-文档”、“主题-文档”、“依赖-技术栈”。初始图谱只包含 3 个实体类型、5 种关系总共不到 200 条边。# 示例用 NetworkX 构建简单知识图谱 import networkx as nx G nx.DiGraph() G.add_node(LangChain, typeframework) G.add_node(RAG, typemethod) G.add_edge(LangChain, RAG, relationsupports) # 添加文档节点 G.add_node(doc_001, typedocument, titleRAG 实战指南) G.add_edge(doc_001, RAG relationauthor) print(f图谱节点数: {G.number_of_nodes()}, 边数: {G.number_of_edges()})这个图谱虽然简单但已经能支持“哪些文档提到 RAG”这类查询而且查询结果可解释。我们没花一周时间调模型而是先跑通了第一个查询接口。实体关系抽取别全信 LLM要人工校验用 LLM 做关系抽取确实快比如让 LLM 从文档中输出三元组头实体关系尾实体。但我们发现一个问题LLM 很容易“幻觉”比如把“使用”误标为“开发”或者把“参考”当成“依赖”。我们的做法是先用 LLM 生成 80% 的数据剩下 20% 由人工抽检把错误样本反馈回 Prompt做几轮迭代优化。同时我们加了一个“置信度”字段对 LLM 抽取的关系打分低于 0.7 的自动标记为待审核。# 示例带置信度的关系抽取结果示例 extracted_relations [ {head: LangChain, rel: supports, tail: RAG, confidence: 0.92}, {head: RAG, rel: uses, tail: FAISS, confidence: 0.65}, # 低置信需人工确认 {head: doc_001, rel: author, tail: 张三, confidence: 0.98} ]这个流程虽然慢了点但图谱的准确性显著提升后续检索的“幻觉”也少了。图检索增强怎么查才快图检索不是把整个图谱丢给 LLM而是先做“子图提取”。比如用户问“有哪些文档使用了 LangChain”我们先在图中找到所有与 LangChain 相连的文档节点提取它们的上下文再丢给 LLM 生成回答。我们用neo4j的 Cypher 查询语言做子图提取结合向量检索做初步过滤最终只返回最相关的 5 个子图片段。这样既保留了图的结构优势又控制了 LLM 的输入长度。// 示例Cypher 查询获取与 LangChain 相关的文档 MATCH (f:framework {name: LangChain})-[:supports|uses|author]-(d:document) RETURN d.title AS 文档, d.content AS 内容, type(rel) AS 关系 LIMIT 5这个查询返回的 5 个文档再传给 LLM 做综合回答准确率明显提升。评估与优化别只看准确率要看流程我们上线前做了一个小测试用 100 个真实用户问题分别测试纯 RAG 和 GraphRAG 版本。GraphRAG 的准确率从 85% 提升到 92%但更关键的是在需要推理的问题上比如“哪个文档提到了 LangChain 且作者是李四”纯 RAG 完全无法回答而 GraphRAG 能准确定位。但真正的问题出现在权限控制上有些员工能查到内部技术文档有些不能但系统没做粒度控制导致有人能“越权”访问。日志也几乎没记录谁查了什么出了问题根本没法追溯。我们后来加了两件事1. 在检索前加入权限过滤根据用户角色动态限制图谱访问范围2. 所有查询都记录日志包括用户 ID、查询时间、返回的实体、调用 LLM 的 prompt 和响应。# 示例权限过滤伪代码 def filter_by_user(user, graph): if user.role admin: return graph elif user.role engineer: return graph.subgraph(nodes[doc_*, framework_*]) else: return graph.subgraph(nodes[doc_public_*])总结流程比模型更重要这个 GraphRAG 项目让我明白一个道理模型再强流程不行照样崩。我们花了很多时间在图谱构建、关系抽取、检索优化上但最终把系统搞崩的是权限和日志的缺失。如果你也在做类似的项目我建议别一开始就搞大模型、复杂图谱从最小可用版本开始权限控制要前置别等上线了再加日志要全包括查询、返回、用户、时间能追溯才能敢用评估别只看准确率要看实际业务场景下的可用性。最后别只盯着“模型效果”真正的护城河是可观测性、权限控制和流程稳定性。这些才是企业级 AI 应用能跑起来的关键。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。