GraphRAG实战：Demo跑通了，联调时为什么还是查不到答案？

关注

原创最新推荐文章于 2026-08-15 12:15:38 发布 190 阅读 AI 写同款· GEO 优化 ›

构建企业级AI问答系统：LLM网关+RAG+Agent架构实战在AI应用开发领域，构建一个稳定、可扩展且具备业务价值的系统是核心挑战。这通常涉及从基础概念到工程实践的全链路思考。其原理在于通过合理的架构设计，将大语言模型（LLM）的能力与特定领域知识、外部工具安全可控地结合起来，从而解决模型幻觉、知识实时性及功能单一等问题。这种架构的技术价值在于实现了AI能力的服务化与中台化，能有效管理多模型调用成本、提升回答准确性并扩展应用边界。典型的应用场景包括企业智能知识库、智能客服以及需要结合内部文档与外部工具的综合助手。本文以【LLM网关】和【RAG知识库】为核心组件，详细阅读详情

聊《GraphRAG并不难，难的是知道什么时候不该用》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

GraphRAG把知识图谱和RAG结合，听起来是个合理的升级方案。但我在最近一次企业知识库项目中，GraphRAG的Demo表现完美，联调时却频频翻车——不是模型能力不够，而是权限、日志、可观测性这些"基础设施"没跟上。本文复盘这次项目，从传统RAG瓶颈讲到GraphRAG建模，最后重点讲联调失败的真实排查路径。

---

1. 传统RAG的瓶颈

文章插图 1

做过企业知识库的应该都遇到过这个问题：用户问"这个项目的预算审批流程是什么"，系统返回的文档片段里确实有相关内容，但信息是分散的——预算金额在财务文档里，审批人在人事制度里，流程节点在OA手册里。传统RAG只能做向量相似度检索，无法跨越文档边界做关联推理。

另一个典型场景是"实体歧义"。用户问"苹果最新发布什么产品"，系统可能把水果公司和手机公司混在一起。传统RAG没有实体消歧能力，召回结果经常跑偏。

我之前的项目里，用户反馈最多的就是这两类问题：跨文档信息整合差、实体指代不清。这也是为什么后来团队决定上GraphRAG——用知识图谱的结构化关系来弥补传统RAG的短板。

---

2. 知识图谱建模

文章插图 2

GraphRAG的核心在于"图"。但图怎么建，决定后期检索质量的上限。

我们当时用的是Neo4j作为图数据库，Schema设计遵循以下原则：

实体类型尽量粗粒度：不要设计成"预算申请单"、"预算审批单"这种细粒度，而是统一为"文档"，通过属性区分类型
关系类型要稳定：用"包含"、"引用"、"属于"这类通用关系，避免业务词汇
属性尽量存原文片段：方便后续溯源

from neo4j import GraphDatabase

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

    def create_entity(self, name: str, label: str, properties: dict = None):
        """创建实体节点"""
        with self.driver.session() as session:
            session.execute_write(
                self._upsert_node, name, label, properties
            )

    def create_relationship(self, from_name: str, to_name: str,
                           rel_type: str, properties: dict = None):
        """创建关系边"""
        with self.driver.session() as session:
            session.execute_write(
                self._upsert_relationship, from_name, to_name,
                rel_type, properties
            )

    def query_graph(self, entity_name: str, depth: int = 2):
        """多跳图查询"""
        with self.driver.session() as session:
            result = session.run(
                """
                MATCH (start {name: $name})
                MATCH path = (start)-[*1..$depth]-(related)
                RETURN path
                """,
                name=entity_name, depth=depth
            )
            return [record["path"] for record in result]

这里有个取舍：深度设为2还是3？2跳能覆盖大部分场景，3跳召回噪音会明显增加。我们最终选了2跳，因为业务文档的关系链通常不会超过2层。

---

优快云资料领取方式

3. 实体关系抽取

图谱建好了，关系数据从哪来？我们有两条路径：

路径一：LLM抽取
用Prompt让大模型从文本中提取实体和关系。成本低，适合快速原型。

PROMPT = """
请从以下文本中提取实体和关系，以JSON格式输出：
文本：{text}

输出格式：
{{
  "entities": [
    {{"name": "实体名", "type": "类型"}}
  ],
  "relationships": [
    {{"from": "实体A", "to": "实体B", "type": "关系类型"}}
  ]
}}
"""

路径二：规则+LLM混合
对结构化文档（如制度文件），先用正则提取关键实体，再用LLM补全关系。这条路径召回更准，但开发成本更高。

我们项目用的是路径二。原因很简单：业务文档的实体类型相对固定（人名、部门、制度名、金额），规则能覆盖70%以上的场景，LLM只做补全，既省钱又可控。

---

4. 图检索增强

图检索的核心思路是：先用图结构做初步召回，再用向量检索做精排。

def graph_rag_query(query: str, k: int = 5):
    """GraphRAG检索流程"""
    # Step 1: 从查询中提取实体
    entities = extract_entities(query)

    # Step 2: 图遍历召回相关节点
    graph_contexts = []
    for entity in entities:
        paths = graph_db.query_graph(entity.name, depth=2)
        for path in paths:
            graph_contexts.append({
                "source": entity.name,
                "path": format_path(path),
                "type": "graph"
            })

    # Step 3: 向量检索补充上下文
    vector_results = vector_db.similarity_search(query, top_k=k)

    # Step 4: 融合排序
    final_contexts = rerank(graph_contexts, vector_results, query)

    return final_contexts[:k]

图检索的优势在于"跨文档关联"。比如用户问"张三审批过哪些预算"，图检索可以直接沿"审批人"关系遍历，召回所有相关文档，而不是靠关键词匹配。

但这里埋了一个隐患——我们当时没有做权限校验。图检索返回了10个文档片段，其中3个属于用户没有访问权限的部门。Demo阶段没人发现这个问题，因为测试账号是管理员权限。

---