GraphRAG实战：真正难的不是调用，而是稳定交付

关注

原创 2026-08-07 22:26:15 292 阅读 AI 写同款· GEO 优化 ›

LightRAG与GraphRAG技术选型实战指南检索增强生成（RAG）作为大模型落地知识服务的核心范式，正从通用架构走向场景深度适配。LightRAG通过语义锚点切分、稀疏向量嵌入与query指纹缓存等技术，将检索压缩为毫秒级向量狙击，显著提升FAQ类高频单点查询的响应效率与稳定性；GraphRAG则依托实体关系抽取、动态子图检索与路径可验证推理，在多跳逻辑、因果推演与强合规场景中构建语义网络，实现答案的可追溯与逻辑完备。二者并非迭代替代，而是面向‘关系密度’与‘决策确定性’差异的技术分治：前者重性能与轻运维，后者重推理与可解释。本文基于医疗、制造、法律阅读详情

聊《GraphRAG实战：真正难的不是调用，而是稳定交付》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

上周做需求评审，为了一个“内部制度智能问答”项目，我和架构组吵了一架。

起因是 PM 拿着一个基于 LangChain 的 Demo 视频，信心满满地演示：上传 PDF，问“差旅报销标准是多少”，回答精准，引用来源清晰。大家掌声雷动，觉得这就够了。

但我心里咯噔一下。这个 Demo 有个致命缺陷：它不知道“不知道”的时候该怎么回答，更不知道多个文档之间的冲突怎么处理。

比如，A 文档写“差旅住宿标准 500 元”，B 文档写“一线城市 600 元”，C 文档写“总监级以上 800 元”。传统 RAG 会把这三段都扔进向量库，检索时可能混在一起，给出一坨模棱两可的答案。而在真实业务中，这种错误比“回答不出来”更可怕，因为用户会信任它。

这就是为什么我坚持要在 GraphRAG（知识图谱 + RAG）上投入资源。今天这篇，不聊虚的概念，就聊聊从 Demo 到生产环境，GraphRAG 到底难在哪里，以及我们是如何一步步啃下来的。

传统 RAG 的瓶颈：向量检索的“盲区”

文章插图 1

在引入图谱之前，我们用的是纯向量检索。效果如何？用两个字形容：散乱。

向量检索的核心逻辑是“语义相似度”。当你问“公司年假政策”，它会找到包含“年假”、“假期”、“福利”等语义相近的片段。这听起来很美，但存在三个顽疾：

1. 实体关联断裂：用户问“张总签字的报销流程”，向量库很难理解“张总”和“财务总监”是同一人，除非文本里明确写了“张总，即财务总监”。
2. 多跳推理缺失：用户问“通过 ISO27001 认证的项目有哪些”，这需要先找到“ISO27001”对应的“安全标准”，再找到“通过该标准认证的项目”。传统 RAG 只能做单层检索，多跳问题直接翻车。
3. 全局视野不足：向量检索是局部的，它只看最相似的几个 chunk。如果答案分散在文档的不同章节，它根本拼不出来。

我们在一次内测中发现，关于“项目立项”的问答，准确率只有 65%。主要问题就是上述三点。PM 急了，但业务确实有这种复杂查询需求。这时候，GraphRAG 就进场了。

知识图谱建模：别急着写代码，先画草图

文章插图 2

很多开发者一上来就装 Neo4j，跑抽取脚本。我劝你慢点。

图谱建模是 GraphRAG 的灵魂，也是最大的坑。模型建歪了，后面全是灾难。

我们当时的做法是：拉着业务专家，在白板前画了三个小时。我们定义了三个核心实体：项目、制度、责任人。然后定义了三种关系：属于、依据、审批。

为什么要这么精简？因为复杂度是准确率的敌人。实体越多，关系越复杂，抽取的错误率呈指数级上升。我们故意忽略了很多细枝末节，比如“文档版本号”、“起草人”，只保留业务最关心的核心链路。


# 简单的本体定义示例（伪代码，基于 Pydantic）
class Project(BaseEntity):
    name: str
    type: str  # 如：研发类、基建类
    status: str

class Policy(BaseEntity):
    name: str
    level: int  # 制度等级
    effective_date: date

class Approval(BaseRelation):
    source: Project
    target: Policy
    approver: str  # 责任人
    condition: str  # 审批条件

记住：少即是多。先跑通一条核心链路，再逐步扩展。

优快云资料领取方式

实体关系抽取：LLM 是笔，规则是墨

图谱建好了，怎么填数据？靠 LLM 抽取。

这里有个取舍：是用开源小模型（如 Llama 3）还是闭源大模型（如 GPT-4）？

我们的结论是：混合使用。

结构化实体抽取：用 Llama 3 8B，速度快，成本低，准确率在 90% 以上，足够应付。
复杂关系抽取：用 GPT-4。因为关系抽取需要理解上下文语境，小模型容易幻觉。

我们踩过的最大坑是实体标准化。LLM 抽出来的“张总”和“张伟”，在库里是两个实体。我们必须在抽取后加一道实体对齐工序，用规则 + 向量匹配的方式，把同义词合并。


# 实体对齐逻辑示例
def align_entities(llm_output, existing_graph):
    for entity in llm_output.entities:
        if entity.type == "Person":
            # 检查是否已存在
            match = existing_graph.query(f"MATCH (p:Person {{name: '{entity.name}'}}) RETURN p")
            if not match:
                # 模糊匹配现有实体
                similar = find_similar_name(entity.name, existing_graph)
                if similar:
                    merge_entities(entity, similar)
                else:
                    create_new_entity(entity)

图检索增强：Cypher 才是杀手锏

这是 GraphRAG 最迷人的地方。我们不再只是返回文本片段，而是返回推理路径。

当用户问“张总签字的报销流程”时，我们的检索逻辑是：

1. 先用向量检索找到“张总”对应的实体 ID。
2. 然后用 Cypher 查询他的审批权限范围。
3. 再关联到具体的制度文档。
4. 最后将路径和原文片段一起喂给 LLM 生成答案。

// Cypher 查询示例
MATCH (p:Person {name: '张伟'})-[:APPROVES]->(policy:Policy)
MATCH (policy)-[:GOVERNS]->(project:Project)
RETURN policy.content, project.name, p.title

这种检索方式，让模型有了“全局视野”。它知道“张伟”是“财务总监”，所以他的审批涉及的是“财务类项目”。这种逻辑，纯向量检索做不到。