当前位置：首页 > news >正文

GraphRAG 接进项目后，团队效率反而降了？

news 2026/8/7 17:55:59

聊《我把GraphRAG接进项目后，先推翻了几个想当然》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

上周团队把 GraphRAG 接进知识库项目，本来想着能提升问答质量，结果联调了一周，效率反而降了。

说实话，这和我们最近观察到的一个趋势很像——AI 编程工具从个人试用走向团队协作，很多人以为接进来就能提效，结果发现坑比 Demo 多得多。GraphRAG 也是一样，看着概念很香，真正跑起来才发现，小团队如果没想清楚，很容易过度设计。

这篇文章复盘我们踩过的坑，以及后来怎么调整的思路。不追求大而全，只讲实际有用的判断标准。

传统 RAG 的瓶颈，我们到底卡在哪

先说结论：传统 RAG 在小团队企业知识库场景里，主要卡在两件事上——语义匹配不准，以及跨文档推理能力弱。

我们之前的项目里，用户问"Q3 销售政策里关于大客户返点的条款是什么"，传统 RAG 的做法是把问题向量化，然后在向量库里找最相似的 chunk。结果经常搜出来的是 Q2 的政策文档，或者返点相关的技术文档，因为语义上"销售政策"和"返点条款"确实有关联，但时间维度和业务维度对不上。

更麻烦的是，当问题涉及多个实体之间的关系时，比如"张经理负责的客户里，哪些有未结清的合同"，传统 RAG 基本无能为力。因为问题里涉及人物、客户、合同多个实体，以及它们之间的关联关系，纯向量检索很难捕捉这种结构化的知识。

这是我们决定尝试 GraphRAG 的直接原因。

知识图谱建模，别一上来就搞复杂

这里有一个常见误区：很多人觉得做知识图谱就要先把本体设计好，实体类型、关系类型全部定义清楚，然后再开始抽。

我们一开始也这么干的，结果卡在第一周就没推进下去。后来调整了策略：先不定义完整本体，直接从业务问题反推需要什么实体和关系。

比如我们当时主要解决三类问题：

合同条款查询（需要实体：合同、条款、客户、金额、日期）
人员职责查询（需要实体：人员、部门、职责、项目）
产品政策查询（需要实体：产品、政策、适用对象、有效期）

基于这三类问题，我们只建了三个实体类型和五种关系，其他先不定义。关系类型也遵循一个原则：只定义业务真正需要查询的关系，不要为了完整而完整。

# 我们实际使用的实体类型定义（Neo4j schema） ENTITY_TYPES = { "Contract": ["contract_id", "title", "amount", "status", "sign_date"], "Person": ["name", "department", "role", "employee_id"], "Customer": ["customer_name", "industry", "level"], "Product": ["product_name", "category", "version"] } RELATION_TYPES = { "SIGNED": "合同签署", "ASSIGNED_TO": "人员分配", "BELONGS_TO": "归属关系", "HAS_POLICY": "政策关联" }

这个简化版的 schema 撑住了我们 80% 的查询需求，剩下 20% 的复杂查询后来通过其他方式补充了。

实体关系抽取，LLM 比规则更实用

抽取环节我们尝试过三种方案：

第一种是纯规则抽取，用正则匹配实体，用依存句法分析关系。结果召回率很低，尤其是遇到同义词、缩写、口语化表达时基本失效。

第二种是微调小模型做命名实体识别和关系抽取。效果比规则好，但标注成本太高。我们只有 2000 条业务文档，标注完一套数据至少一周，而且模型泛化能力有限。

第三种是直接用 LLM 做抽取，配合 few-shot prompt。这是我们最终采用的方案。

from openai import OpenAI client = OpenAI(api_key="your_api_key") EXTRACTION_PROMPT = """ 从以下文本中提取实体和关系，以JSON格式输出： 文本：{text} 要求： 1. 实体类型只从以下中选择：Contract, Person, Customer, Product 2. 关系类型只从以下中选择：SIGNED, ASSIGNED_TO, BELONGS_TO, HAS_POLICY 3. 输出格式：{"entities": [...], "relations": [...]} 示例： 文本：张经理与ABC公司签署了价值100万的合同 输出：{{"entities": [{{"type": "Person", "name": "张经理"}}, {{"type": "Customer", "name": "ABC公司"}}, {{"type": "Contract", "title": "价值100万的合同"}}], "relations": [{{"from": "张经理", "to": "ABC公司", "relation": "ASSIGNED_TO"}}, {{"from": "张经理", "to": "价值100万的合同", "relation": "SIGNED"}}]}} """ def extract_entities_relations(text): response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "你是知识图谱抽取专家"}, {"role": "user", "content": EXTRACTION_PROMPT.format(text=text)} ], temperature=0 ) return json.loads(response.choices[0].message.content)

我们用 GPT-4o-mini 而不是 GPT-4，成本差了 10 倍。对于抽取任务来说，mini 版本的准确率已经足够，关键是 prompt 设计要清晰。

图检索增强，这才是 GraphRAG 的核心价值

传统 RAG 是"检索-生成"两步走，GraphRAG 是"图谱检索-向量检索-生成"三步走。

我们在图检索这里做了两层优化：

第一层是子图检索。当用户提问时，先从问题里提取实体，然后在图谱中找到这些实体的邻居节点，构建一个子图。这样检索到的知识是有结构的，不是零散的文本片段。

第二层是混合检索。把子图结构信息和向量相似度结合起来，既保证语义相关，又保证结构合理。

def graph_rag_query(question, kg, vector_db): # 1. 从问题中提取实体 entities = extract_entities(question) # 2. 在图谱中检索子图 subgraph = get_subgraph(kg, entities, depth=2) # 3. 将子图转换为文本描述 graph_context = format_subgraph(subgraph) # 4. 向量检索补充相关文档 vector_context = vector_db.search(question, top_k=5) # 5. 拼接上下文生成答案 prompt = f""" 基于以下知识图谱信息和文档内容回答问题： 知识图谱信息： {graph_context} 相关文档： {vector_context} 问题：{question} """ return generate_answer(prompt)

这里有一个关键判断：depth=2 是我们反复测试后的结果。depth=1 召回不够，depth=3 噪音太多。实际项目中，应该根据业务问题的复杂度调整这个参数，不是一成不变的。