货拉拉从RAG到GraphRAG元数据检索实践

当企业数据规模膨胀到PB级别，面对成千上万的表和字段，如何快速、准确地定位所需数据，已成为一个令人困扰的“找数”难题。传统的元数据检索方法，往往要求使用者既是业务专家又是技术专家，导致沟通成本居高不下。随着大语言模型（LLM）与检索增强生成（RAG）技术的兴起，我们看到了通过对话式问答降低找数门槛的可能性。然而，初代RAG方案在复杂的元数据场景下，表现却不尽人意。

今天，我们就来深入探讨货拉拉如何通过引入GraphRAG技术，革新元数据检索方式，有效解决传统RAG的局限性。

1. 什么是RAG？

RAG（检索增强生成），顾名思义，是一种将信息检索与文本生成相结合的技术范式。

其核心逻辑非常直观：当大模型需要回答一个问题时，不再仅仅依赖其内部参数化的知识，而是先从一个外部的、大规模的知识库中实时检索出相关的信息片段。然后，基于这些检索到的、相对可靠的“证据”来组织并生成最终答案。这一方法，极大地提升了生成内容的准确性、时效性和可信度，同时显著降低了模型“信口开河”（即产生幻觉）的风险。

因此，RAG迅速成为智能问答、文档摘要、知识辅助决策等场景下，用于增强大模型事实可靠性的关键技术。

1.1 RAG架构模式

1.2 RAG的挑战

必须清醒地认识到，RAG系统并非万能之策。它虽然通过引入外部知识提升了可靠性，但自身也面临着一系列棘手的挑战：检索的相关性与时效性往往难以兼得；基于向量的相似度召回，很容易遗漏那些表述不同但语义关键的信息；面对复杂的知识结构和多跳推理问题，传统的文档片段检索显得力有未逮；用户简单的语义查询与背后真实的复杂需求之间，常常存在一道难以逾越的鸿沟。

优化RAG系统，通常需要结合具体场景进行参数调优、改进检索算法、增强知识过滤，甚至融合大模型自身的推理能力，而不能期望某单一技术能一劳永逸地解决所有问题。

1.3 如何评价RAG系统？

2. 什么是GraphRAG？

为突破上述瓶颈，GraphRAG（图检索增强生成） 应运而生。它可以说是RAG的“增强版”，其核心创新在于引入了知识图谱来重构检索与生成的整个过程。

与传统RAG直接检索文档片段不同，GraphRAG首先从海量非结构化或半结构化数据中，构建并存储一个结构化的知识图谱。这个图谱由实体（节点）和关系（边）组成。随后，系统可以利用图算法（如社区发现、中心性分析）来深度挖掘实体间隐藏的复杂关联与全局模式。当需要回答问题时，系统从图谱中检索出相关的子图、关系路径或社区信息，以此作为生成答案的上下文。

这种方法极大地增强了对复杂问题的推理能力、对隐藏关联的发现能力，以及回答的系统性和深度，特别适用于需要深度分析、趋势挖掘和跨源知识融合的场景。

2.1 引入Graph之后的RAG架构模式

引入知识图谱后的增强型RAG架构，通常分为离线和在线两个阶段。

离线阶段：原始知识库经过文本分块（Chunking）处理，同时通过大模型进行知识抽取，识别出实体与关系。文本块经过嵌入模型转化为向量，存入向量数据库；而抽取出的实体和关系则构建成图索引，存入图数据库。

在线阶段：用户的问题首先被转化为向量，系统同时启动向量检索和图检索，分别从向量库获取相关文本片段，从图数据库获取相关的实体与关系网络。最后，将这些多源信息整合成一个丰富的提示词（Prompt），输入给大模型以生成最终答案。这套架构能够很好地支撑推荐、检索、对话等多种应用场景。

目前主流的GraphRAG方案，一般都具备以下几个核心特性：

• 多索引结合：同时维护图索引、向量索引，有时还包括全文索引。
• 混合检索：综合运用向量检索、全文检索（如BM25）、标量过滤等多种检索手段。
• 多跳推理：基于知识图谱的关系网络，能够进行多步推理，从而解决更复杂的关联性问题。

2.2 GraphRAG vs. RAG

2.3 3种Graph-based RAG对比

目前，基于图的RAG主要有三种典型范式：GraphRAG（微软开源）、LightRAG与PathRAG。它们分别从知识挖掘、轻量化部署、路径推理这三个核心维度，对传统RAG进行了突破。针对不同业务场景的差异化需求，既可以按需选择单一方案，也可以灵活组合，发挥协同效应，以更高效地满足复杂场景下的知识检索与推理需求。

它们之间的详细对比如下：

3. AI元数据检索探索之路

3.1 业务背景

在货拉拉，数据团队和业务同学在日常“找数”过程中，常常陷入困境。要精准定位一个数据字段，不仅需要理解业务含义，还要清楚它在技术上的存储位置，这导致大量时间耗费在反复的跨部门沟通上。

随着LLM和RAG技术的成熟，我们开始尝试利用RAG系统来理解和处理复杂的元数据与业务知识，目标是打造一个对话式问答入口，降低找数门槛，把大家从隐性的沟通负担中解放出来，从而提升整体数据检索效率。

用户典型的提问包括：

• “XXX数据/业务字段，在哪个表能找到？怎么取，在哪获取？”
• “XXX业务数据，在哪个表的，哪个字段？”
• “XXX表里有XXX业务数据的字段吗？是哪个？”
• “XXX的数据口径是什么？有没有说明？”
• “XXX的业务含义是什么意思？”

3.2 关键挑战

3.3 方案1.0 —— Naive RAG

我们最初尝试了基础的RAG方案。

• 方案1.0 效果
  • 整体效果未达预期目标。
  • 回答准确率仅55%；召回率/TopK命中率只有60%左右。

问题归因：
❌ 知识库“营养不良”：仅包含库表schema和简单注释，严重缺乏业务背景、字段口径、数据血缘等关键信息。
❌ 检索能力“单一薄弱”：仅依赖向量检索，面对同义词、多实体关联、表间关系等复杂问题时，召回率表现不佳。
❌ 边界感“完全缺失”：系统无法识别超出知识库范围的问题，容易“硬着头皮”输出误导性内容。

1) 索引流程

知识库导入流程如下：

2) 检索流程

知识库检索与生成流程如下：

3) 分块（Chunking）方式

在元数据场景下，如何切割文本块（Chunking）至关重要。我们评估了两种方式：

• 方式一（不采用）：整表切割。将整个表的所有信息作为一个Chunk。这种方式虽然完整保留了表内上下文，但弊端明显：一是相似度匹配时，容易因表中某个无关字段匹配度高而误召回整张表；二是整表文档作为上下文极易导致大模型的Token长度超限。

• 方式二（采用）：单字段切割。以单个字段（或少量相关字段）为单位进行切割。这有效避免了整表切割的两个问题，但需要考虑Chunk数量激增可能带来的查询性能压力。切割格式可以按单行或多行组织。

综合来看，第二种切割方式更适合库表检索场景。

Demo效果展示

1. 用户问题：xxx字段，在哪个表里能找到？
2. 向量数据库检索结果：
{"tableName": "table1", "column": "xxx", "type": "string", "comment": "xxx"};
{"tableName": "table1", "column": "xxx", "type": "bigint", "comment": "xxx"};
...
3. LLM生成答案：
xxx字段在"table1"这个表中可以找到

4) 方案1.0的Badcase分析

我们对方案1.0的Badcase进行了详细分析，问题主要集中在三个层面：首先是知识召回环节存在不足，导致相关信息未能有效触达大模型上下文；其次是知识库本身的质量有待提升，内容准确性和覆盖度存在局限；最后是边界问题，对需求范围的界定不够清晰。其中，知识召回问题的影响最为突出。

具体案例如下：

1. 语义不匹配

Q1: 哪张表能取到司机运送实际车型啊？
标准答案: 司机宽表xxx字段，该字段含义是【物理车型】
AI答案：<回答完全不相关的表和字段>
Q2: 大佬们，想问下哪里可以取到运脉上的司机卸货位置啊
标准答案：xxx表的xxx和xxx字段可以取到司机开始卸货的经度和开始卸货的纬度
AI答案：<不会回答“司机开始卸货的经度和开始卸货的纬度”相关字段>

原因分析：向量检索无法有效处理同义词（如“实际车型”与“物理车型”）和业务口径转换（如“卸货位置”与具体的经纬度字段）。

2. 多问题/多实体/关系召回率低

Q1: 请问下这4个时间节点分别对应订单宽表哪个字段呀？司机到达发货地、司机完成装货、司机到达收货地、司机完成卸货
标准答案：xxx表有相关字段
AI答案：<只会回答其中1个或2个字段>
Q2：哪张表有存司机ID对应的手机号呢？
标准答案：你可以在table1、table2表中找到司机ID对应的手机号，其中xxx字段代表手机号。
AI答案：<可能会回答不知道>

原因分析：向量检索难以精确召回问题中涉及的所有实体，更无法回答实体之间的关联关系（如“司机ID”与“手机号”的对应关系）。

3. 无关信息干扰，回答不正确

Q1：想问下如果用户没有完单，但下单时候选择了专票，这种怎么取呢？我在你说的这个表没找到这类未完单但下单时收了专票服务费的订单
标准答案：xxx业务：table1、xxx业务：table2、字段：colomn1
AI答案：<会回答用户问题中后半句相关的内容>

原因分析：用户问题中冗长的描述（后半句）会产生干扰向量，影响核心意图的召回精度。

4. 缺乏相关知识，胡乱回答

Q1：你好，请问现在有实时订单表可以使用么？
标准答案：看看这个表xxx
AI答案：<回答不相关的表>
-- 注：这个例子中，实时订单表缺少comment和业务描述

5. 不存在相关表，胡乱回答

Q1：需要xxx业务线的已取消订单司机实际行驶距离。我看有些报表有个xxx不知道哪个可用
标准答案：没有现成的表，需要加工才能取到
AI答案：<回答完全不相关的表和字段>

这些Badcase清晰地表明，仅靠向量相似度的“朴素”RAG，在复杂的元数据检索场景中往往捉襟见肘。

3.4 方案2.0 —— GraphRAG

元数据天然具有图结构属性（表、字段、业务术语及其之间的关系），这让我们很自然地想到了Graph-based RAG的技术思路。经过深入研究和对比，LightRAG在复杂度、灵活性、可嵌入性等方面，更契合我们的场景需求。

1）知识库

知识库建设采用渐进式扩展策略，先从核心数据域（如订单域）开始验证效果，再逐步扩展到全库范围，确保每一步都走得稳健。

2）图存储设计

GraphRAG的知识图谱围绕三类实体设计：1. 表/字段：以表为核心节点，关联其字段及跨表血缘关系，节点包含类型、描述等属性；2. 业务术语/缩写词：作为独立节点存储；3. 同义词层：通过“同义”关系边连接含义相同的术语。通过节点属性和关系边，我们构建了一个结构化的知识网络，为复杂关联检索奠定了坚实基础。

3）向量存储设计

4）索引流程

知识库索引流程是一个多源融合的方案：一方面，从元数据管理平台获取表/字段详情、数据血缘等信息，经格式转换生成表/字段实体关系；另一方面，通过手工梳理结合大模型抽取数仓文档、领域知识，生成术语、问答等实体关系。两类实体关系合并后，存入图存储，同时将实体关系与对应的文档块关联，存入向量存储。

由于每个实体都有唯一名称作为ID，这为实现知识索引库的增量更新提供了极大的便利。

为了优化检索排序，我们为实体设计了权重计算模型：

• 表分数 = manual_boost_1 * ( w1 × 下游依赖得分 + w2 × 热度得分 + w3 × 收藏得分 )
• 字段分数 = manual_boost_2 × (w4 × 基础分 + w5 × 所属表因子)
• 术语词汇分数 = 1

各权重因子定义及计算公式如下：

5）检索流程

检索流程也进行了升级：用户Query首先经大模型分解为高级关键词（代表整体意图）和低级关键词（具体实体）。低级关键词结合同义词库扩展后，通过混合检索（向量+BM25）和重排得到TopK实体，再关联知识图谱获取其相关关系，形成局部查询上下文（Local Query Context）。高级关键词经向量检索得到TopK关系，再关联图谱获取相关实体，形成全局查询上下文（Global Query Context）。最后，合并两类上下文输入大模型生成答案。

3.5 效果

方案升级带来了显著的提升：

1. 问答质量有实质突破：整体准确率从56%提升至78%，其中知识召回率达到91%，TopK命中率90%，平均倒数排名（MRR）达到0.73。
2. 业务场景提效明显：AI检索相比传统关键词检索的渗透率已达到30%左右，直接为数仓答疑环节节省了20%以上的时间成本，有效减少了重复沟通与信息检索耗时。

4. 后续工作

当前GraphRAG的实践已取得预期效果，但仍有持续优化的空间。接下来，我们将从以下几个方向推进：

1. 检索能力升级：更强的混合检索，更准的结果排序
   • 引入更全面的混合检索机制，将全文检索、标量检索与现有向量检索深度结合，构建互补的检索体系，以更好地覆盖专业术语、缩写及长尾查询。
   • 持续优化Rerank模型，引入更多业务相关指标（如表重要性、字段使用频次等）来优化实体权重计算。
2. 持续完善知识库：打造更丰富的元数据生态
   • 增强领域术语体系：利用AI自动发掘业务术语、同义词和数据口径，建设领域词典，从根本上解决“叫法不同但意义相同”的检索障碍。
   • 智能元数据增强：探索语义扩展技术，将简短的字段名自动扩展为富含业务语义的自然语言描述，从而提升其向量表示的效果。
3. 向Agentic迈进：探索Agentic RAG
   • 具备规划能力：用智能体（Agent）的规划能力取代现有的固定工作流，让系统能动态决定检索策略，优化效率和精准度。
   • 实现多跳推理：让系统能够自动将复杂问题拆分为多个子问题，通过多轮“检索—验证”循环，构建完整的推理链路。
   • 增强交互能力：赋予系统“主动提问”的能力，在用户提问模糊或信息不足时主动发起澄清，从而提升最终回答的可靠性。

5. 结语

从RAG到GraphRAG的探索，给我们最深的体会是：元数据检索，本质上在于如何更好地组织现有的元数据。表、字段与业务术语之间千丝万缕的关联，仅靠语义相似度很难稳定命中；把元数据建成图谱，用实体和关系一起召回，才是提升系统召回率和准确率的关键。在元数据这个特定场景里，RAG的瓶颈往往不在大模型本身，而在于前端的检索和后端的知识组织。

后续，我们还会在混合检索、结果重排和知识库建设上持续优化，同时积极探索应用Agentic RAG的可能性。从RAG到GraphRAG，这不仅仅是一次技术架构的升级，更是对我们一直在回答的那个核心问题的实践：如何把企业里沉淀的数据知识，真正高效地用起来。