聊《GraphRAG看起来很强，为什么一进真实项目就容易失控？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

最近看 Codex 和 Claude Code 从个人试用走向团队协作，发现一个规律：Demo 能跑通的人很多，能真正让团队用起来的人很少。很多人卡在权限、日志、可维护性这些" boring "的事情上。

GraphRAG 也一样。

去年我做了一个企业知识库项目，一开始觉得上 GraphRAG 肯定能碾压传统 RAG。结果上线后，团队反馈反而更慢了。不是模型不行，是工程细节没跟上。今天把这次踩坑的复盘写出来，希望能帮到准备入坑的人。

目录

• 传统 RAG 的瓶颈在哪
• 知识图谱怎么建才不翻车
• 实体关系抽取的坑
• 图检索怎么增强 RAG
• 评估和优化
• 总结：学习路线的取舍

传统 RAG 的瓶颈在哪

先说一个真实场景。

客户问："张总负责的项目中，哪个用了大模型技术？"

传统 RAG 的做法是把问题丢给向量检索，召回几个文档片段，然后让 LLM 回答。但问题是：

• 张总的名字在文档里可能以"张某"、"张经理"、"张XX"出现，向量匹配不到
• 项目和大模型技术的关联可能分散在多份文档里，单篇召回不够
• 即使召回了，LLM 也不确定哪些信息是相关的

我做过一个对比实验。用同一批企业制度文档，传统 RAG 回答上面那个问题的准确率只有 43%，GraphRAG 做到了 78%。差距明显，但 GraphRAG 的维护成本也高得多。

知识图谱怎么建才不翻车

建图谱最容易犯的错误是：想建一个完美的本体。

我一开始设计了三层实体类型（人、项目、技术）、五种关系、还有属性。结果抽取出来的数据乱七八糟，实体对齐也做不好。

后来我做了减法。只保留两类实体：人和项目，三种关系：负责、使用、隶属于。属性只保留名称和部门。

# 简化的实体定义
from pydantic import BaseModel
from typing import Optional

class Entity(BaseModel):
    name: str
    type: str  # "person" | "project"
    attributes: dict = {}

class Relation(BaseModel):
    head: str
    relation: str  # "负责" | "使用" | "隶属于"
    tail: str
    confidence: float = 0.0

这个设计看起来简单，但足够覆盖 80% 的查询场景。记住：先让系统跑起来，再考虑完美。

实体关系抽取的坑

抽取环节是最容易出问题的地方。我用的是 LLM 直接抽取，而不是训练专门的 NER 模型。原因很简单：企业文档的命名不规范，训练数据难收集，微调成本高。

但 LLM 抽取有几个坑：

1. 实体对齐

文档里可能写"张总"，也可能写"张伟"。如果不做对齐，图谱里会有两个实体。

我的做法是：先抽取，然后用向量相似度做合并。相似度超过 0.85 的实体归并。

import openai
from sentence_transformers import SentenceTransformer

model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2')

def merge_entities(entities):
    embeddings = model.encode([e.name for e in entities])
    merged = {}
    for i, e in enumerate(entities):
        found = False
        for key in merged:
            similarity = cosine_similarity(embeddings[i], embeddings[key])
            if similarity > 0.85:
                merged[key].append(e)
                found = True
                break
        if not found:
            merged[e.name] = [e]
    return merged

2. 关系抽取的召回率

LLM 抽取关系时，经常会漏掉一些隐含关系。比如文档里写"张总负责AI项目，该项目使用了大模型技术"，但 LLM 可能只抽取"张总-负责-AI项目"，漏掉"AI项目-使用-大模型技术"。

解决办法是：让 LLM 分步抽取。先抽实体，再抽关系，最后做关系补全。

3. 抽取速度

一份 100 页的文档，用 LLM 抽取可能需要 10-20 分钟。如果文档量大，这个成本受不了。

我的优化方案：先用传统 NER 模型做粗筛，只把不确定的部分交给 LLM。这样速度提升了 3 倍，召回率只下降了 5%。

图检索怎么增强 RAG

GraphRAG 的核心优势在于多跳推理。传统 RAG 是一次检索，GraphRAG 可以多次遍历。

比如查询"张总负责的项目中，哪个用了大模型技术？"

系统会这样工作：

1. 从"张总"出发，找到所有他负责的项目
2. 对每个项目，找到它使用的技术
3. 筛选出包含"大模型"的技术
4. 返回结果

from neo4j import GraphDatabase

class GraphRAGRetriever:
    def __init__(self, uri, user, password):
        self.driver = GraphDatabase.driver(uri, auth=(user, password))

    def retrieve(self, question: str) -> list:
        # 1. 先做实体识别
        entities = self.extract_entities(question)

        # 2. 图遍历检索
        results = []
        for entity in entities:
            paths = self.traverse_graph(entity, max_hops=3)
            results.extend(paths)

        # 3. 结果排序和去重
        return self.rank_and_dedup(results)

    def traverse_graph(self, entity: str, max_hops: int = 3):
        with self.driver.session() as session:
            # 多跳查询
            query = f"""
            MATCH path = (start:Entity {{name: $entity}})-[:REL*1..{max_hops}]->(end:Entity)
            RETURN path
            """
            results = session.run(query, entity=entity)
            return [record["path"] for record in results]

这个检索方式比传统向量检索慢，但准确率更高。关键是找到速度和准确率的平衡点。我的经验是：对于简单查询，先用向量检索；对于复杂多跳查询，再用图检索。

评估和优化

项目上线后，我发现 GraphRAG 的准确率确实高，但响应时间也长了。原来传统 RAG 平均 2 秒返回，GraphRAG 要 8 秒。

怎么优化？

1. 缓存热点查询

对于高频问题，把结果缓存起来。我用 Redis 做了简单缓存，TTL 设置为 1 小时。

2. 图索引优化

Neo4j 的索引配置很关键。我给实体名称加了唯一索引，给关系类型加了复合索引。查询速度提升了 40%。

3. 分层检索策略

不是所有问题都需要图检索。我设计了一个分类器，先判断问题类型：

• 简单事实查询 → 向量检索
• 多跳推理查询 → 图检索
• 模糊查询 → 混合检索

def choose_retrieval_strategy(question: str) -> str:
    """判断使用哪种检索策略"""
    # 简单的关键词匹配
    multi_hop_keywords = ["负责", "使用", "属于", "关联"]
    if any(kw in question for kw in multi_hop_keywords):
        return "graph"

    # 长度判断，长问题通常更复杂
    if len(question) > 50:
        return "hybrid"

    return "vector"

总结：学习路线的取舍

回到开头的问题：为什么 GraphRAG 容易失控？

我的判断是：很多人高估了模型能力，低估了工程成本。

如果你准备做 GraphRAG 项目，我的建议是：

先补什么：
1. 知识图谱基础：实体、关系、属性、查询语言（Cypher/SPARQL）
2. Neo4j 或类似图数据库的实操
3. LLM 信息抽取的基础用法

暂时放什么：
1. 复杂的本体设计
2. 自定义 NER 模型训练
3. 图神经网络等高级技术

真实建议：

先做一个最小可行项目。用 100 篇文档，建一个简单的图谱，实现基本的图检索。跑通之后，再考虑扩展。

我见过太多人一开始就想建一个完整的企业知识图谱，结果半年过去了，连一个能用的 Demo 都没有。

GraphRAG 不是银弹。它适合多跳推理场景，不适合简单问答。如果你的问题主要是"这篇文章说了什么"，传统 RAG 就够了。如果是"张总负责的项目里，哪个用了大模型技术"，再考虑 GraphRAG。

最后说一句：工具再厉害，也替代不了对业务的理解。建图谱之前，先搞清楚用户到底会问什么问题。这个问题想清楚了，图谱设计自然就简单了。

资料展示

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

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