让AI真正懂数据：猫超Matra项目中的AI知识库建设之路

近年来，人工智能技术正以快速的发展重塑各行各业。大模型(LLM)的突破性进展，使得自然语言理解、生成与推理能力显著提升，AI不再局限于图像识别或推荐系统，而是逐步向复杂决策和自主执行演进。在这一背景下，“Data Agent”成为企业智能化升级的一个探索方向。

1.1 数据研发提效：历史积累带来的治理挑战

猫超数据资产历经十年建设，已形成规模庞大的数据体系：

• 累计沉淀 数万张表、近万个调度节点，其中核心保障任务约占30%+。
  

• 涵盖供应链、交易、日志、商品、直播等数据域。

然而，长期发展过程中也积累了诸多结构性问题：

• 规范问题：大量表字段与指标缺乏统一命名标准和清晰语义描述，存在“同名异义”和“异名同义”现象；
  

• 冷资产问题：因业务变迁、组织融合等原因，遗留了无人维护、低使用频率的“僵尸表”与过时口径；
  

• 逻辑口口相传：各域虽已逐步厘清内部数据模型，但关键业务知识（如指标口径、维度解释、依赖关系）仍散落在大数据平台脚本、报表系统、内部协作文档等非结构化载体中，缺乏统一归集与管理机制。

与此同时，数据研发团队需同时承担日常站点维护、高频数据答疑、临时取数支持及新需求开发等多重任务，导致精力分散，难以专注于核心模型建设和资产优化。

1.2 AI的需求驱动：迈向智能取数的新范式

面向猫超小二、助理等一线业务角色，日常工作中存在大量数据依赖型任务，例如手动汇总多系统数据（ERP、报表平台、线下表格）定期更新日报、周报、专项分析。当前这些工作普遍依赖人工操作，存在三大痛点：

• 人力成本高：重复性取数与整理耗费大量时间；
  

• 效率低下：跨系统取数流程繁琐，响应周期长；

在此背景下，我们启动 Matra 项目 —— 一款面向猫超场景的 AI 数据助手，旨在通过自然语言交互实现“低门槛、高灵活性”的智能取数与分析服务，让AI能像专业的数据工程师、数据分析师一样，听懂业务问题、自动规划取数路径、生成并执行SQL并输出洞察结论，实现从“人找数”到“AI取数、分析、用数”的转变。

然而，一个高效、可靠的Data Agent离不开强大且结构化的知识支撑体系。没有高质量的知识库，AI难以准确理解语义、正确生成逻辑、稳定交付结果。

因此，构建一套面向 AI 的、可理解、可检索、可推理的 AI-知识库体系，已成为推动数据研发提效、赋能智能取数的核心基础设施。本文将以 Matra-AI 项目实践为基础，系统总结我们在知识库方案设计、内容构建、维护挑战、图谱召回及平台化落地等方面的探索与经验，旨在打造一个支持 Data Agent 高效运行的“数据认知中枢”。

维护方式

基于以上数据资产现状，在建设Matra知识库时主要考虑以下三点：

• 不重构数据模型：数据资产太多，需求压力大，数研精力有限，无法面向AI重构数据模型，优先在知识库层面让LLM理解现有表设计。
  

• 知识库可拓展性：猫超历史上未建设指标管理中心，而前期知识库结构、内容可能会面临不断调整、适配，需要一个灵活的知识库前期进行探索，通过钉钉表格、文档进行前期知识库维护。

• 知识库质量：数据资产质量参差不齐，不能全量维护，若对所有资产“一刀切”地纳入AI可用范围，将导致模型输入噪声大、推理结果不可信，筛选核心数据资产进行维护，从小而精致的知识库慢慢开始扩展。

这样可以通过较小的代价来维护面向AI的数据资产，对于初期LLM产品来说，这样可以牺牲一些全面性，但能提升准确性。

维护种类

一个好的知识库应该包括哪些信息？从数据研发工作角度来看，一个数据需求必须要明确以下内容才可以进行开发。

• 指标定义：包括指标的名称/公式/是否可加；

• 数据粒度：数据的聚合粒度；

• 数据范围：数据底表的范围，包括日期限制/业态限制/取数限制等；

这些信息正好构成了书写SQL中必要信息，自然而然我们也分别构建指标（Metric Logic）/实体（Entity）/属性（Attribute）/表（Table）/字段（Columns）等知识库。

大图一览

内容构建

知识库构建经历了2个阶段，第一阶段是通过钉钉文档的方式进行快速维护&更新，主要是核心数据资产，并供给知识图谱和下游Agent使用，用于跑通POC案例，并在实践的过程中不断完善知识库的设计方案。随着下游应用场景的扩展，更多的数据资产需要通过知识库维护，同时知识库结构相对稳定，知识库逐渐走到了第二阶段——产品化建设。

3.1.1 前期钉钉文档

基于以上方案，结合元数据，对表、字段、指标等进行了评估和筛选，借助大模型能力对提取表、字段关键词并进行泛化，对DDL进行优化和标准化，构建知识库。以下为重点构建案例。

指标/实体/属性清单

表和DDL

3.1.2 正在产品化

痛点和挑战

在经历过S1的产品迭代知识库的结构已经相对稳定，同时维护过程中发现表DDL+人工修正的维护SOP中暴露出许多问题。以下从有效性、保鲜性、维护成本三个方面分析。

1.有效性：知识库结构中需要同时维护 实体、属性、指标、表、DDL信息 五类知识，这些知识必须是可关联的信息才可以被大模型理解，否则问数任务在大模型执行中可能因某个知识无法与其他知识关联，扩大大模型幻觉的概率。

2.保鲜性：当表中维护的知识发生改变，需要依赖研发自发的修正其他知识中关联该变更的部分，如果不能及时修改，则知识库知识会失效。例如表实际DDL修改、表下线等问题。

3.维护成本：从知识库概览图中可以看发现，知识库中强依赖知识间的联动，因此每一次修改都需要联动修改很多绑定部分，并且知识库需避免冗余知识，冗余知识会显著增加模型推理相同问题的不确定性和时间，这不是问数所需要的，因此在人工维护的情况下，无疑是巨大维护成本。信息填充中大部分是简单且重复的工作，可被规则或者AI替代，却浪费大量的人时，仅仅维护一个域的4个中间层表，就需要研发2人时的精力，主要分为四种成本：

• 变更成本高：某一知识产生变更后，所有相关项需要手工扫描并更改。
  

• 扩展泛化词：为保证大模型理解用户问数中的维度和指标，并成功关联数据表的字段，需要人工填写多套可能的相似中英词组合。
  

• 唯一性校验：产生新知识后，需要人工扫描所有知识，以保证该知识与泛化词不会和历史所有的知识有重叠。
  

• 重复写入：新增了指标或者属性后，仍需要去DDL中将该标准知识重复维护在对应字段的备注中。

产品设计

为了知识库可以长期维护，知识库的管理工具从静态文档必须转为半自动化的平台能力，但考虑到团队主要投入业务需求、技术栈不匹配、QPS低，自研平台性价比低，因此通过与AI自然语言交互搭建了一套资产维护平台，研发中主要承担产品构思，而非工程落地，极大解放人时，同时具备极高的拓展性。平台功能如下图：

平台秉承着在保障知识准确的情况下，实现知识间尽量独立但强关联，且极大减少了研发人工操作，仅需要确认，实现了知识库的半自动化，有效解决了手工维护知识库中遇到的三种问题。

产品搭建

通过建知识库维护页面，同时支持启用数据库从而保存维护内容并可回流ODPS进行数据管理，页面功能点如下：

维护对比效果如下：

数据资产通常涉及大量的数据表及字段，传统的RAG方法存在一定局限性，例如：难以准确刻画多表之间的关联关系、易产生“幻觉表”（即不存在的表名或字段）、以及召回和推理过程的可解释性较弱。为提升管理和智能分析的能力，我们采用 GraphRAG 技术，通过构建结构化的知识图谱，全面表达和推理数据表与字段之间的关联关系，从而显著提高召回结果的准确性。

在接收到用户查询后，首先对 query 进行分词和实体映射处理。借助模糊词库和公式库，识别并标准化 query 中的模糊表达与相关业务公式。例如，对于“今年猫超主站美妆百亿补贴渠道的笔单价是多少？”这一问题，“美妆”可映射为标准实体名“大组名称”，“笔单价”可通过公式识别为“笔单价 = 支付金额 / 支付父订单量”。模糊词和公式替换完成后，再将分词结果映射到知识图谱中的标准实体上，得到目标实体集合。

获得实体集合后，下一步是从知识图谱中检索能够覆盖所有目标实体的最优路径。具体而言，首先依据业务意图确定检索的社区，然后针对涉及的每个实体名，确定搜索的锚点实体（通常为指标类实体）。锚点实体可能在多张表中存在，（如“支付金额”指标存在于订单、场域、商品等表中），因此需要结合用户的问题，基于节点所归属的数据表及相关属性进行筛选，选取 Top K 表中的核心节点作为锚点。以这些锚点为起点，搜索能够覆盖所有目标实体的最小子树（最短路径），并最终输出 Top K 的路径结果，每条路径包含若干连接在一起的表节点和实体节点。

3.4.1 面临挑战

Matra底层的算法能力尚未对基座模型进行Supervised Fine-Tuning，仅通过基座模型的编排和串联实现，这对于算法框架设计、知识库查询的速度和准确性、Prompt设计有更高的要求。在实现选品、问数、分析等多场景的NL2SQL的过程中，我们主要面临三个关键问题：

• 用户意图识别与数据表召回困难：如何准确理解用户的真实需求，并快速找到正确可用的数据底表。

• 自然语言映射SQL难题：如何把用户输入的自然语言，准确转换成数据库能执行的查询语句。

• 复杂任务执行风险：当需要处理多个数据表或复杂计算时，如何确保整个过程不出错。

针对上述问题，我们设计了三个核心模块来解决：

1. 意图识别+知识图谱模块：通过意图识别+知识图谱对用户问题进行精准识别，并召回对应数据表。

2. 搭建ReAct框架：ReAct框架通过提示词工程引导大模型进行分步推理（如识别字段映射、计算规则），并利用上下文验证机制对生成SQL的语法与语义进行双重校验。

3. 搭建Plan&Execute框架：利用Plan&Execute框架将任务拆解为原子子查询，使用任务调度器管理中间状态与依赖关系，优化任务拆解的准度与计算链路的执行效率。

3.4.2 方案设计

整体框架实现了从自然语言输入到数据输出的全链路过程，通过分层模块化设计（意图解析→执行规划→任务执行→结果输出）确保取数Agent的可扩展性和稳定性。

1. 用户需求输入与意图解析，对用户输入进行意图识别解析，例如“今年618期间百亿补贴渠道的gmv是多少？”，提取其中日期、渠道以及计算指标并与用户二次确认。

2. 取数核心流程

• 核心Agent整合意图识别结果和知识库信息，启动Plan&Execute Planer框架。

• Planning节点对任务生成生成分步执行计划（如先筛选时间范围，再关联区域表）。

• Execute节点调用ReAct框架的子Agent对子任务进行执行。取数Agent中包括data_collector与sql_executor两个子Agent，分别负责数据收集与SQL生成。

• 当检测执行异常时（如SQL语法错误/数据缺失），触发Replan节点进行重新规划。

• 当所有子任务执行结束，启用Summarize节点，验证完整性后进入输出阶段。

3. 输出形式

• Markdown表格：适合前端展示。

• Excel文件：包含完整数据集的可编辑文件。

3.5.1 资产查询：AI资产找表面面俱到

面向猫超的技术同学包括数开、数科、前后端技术同学等，8月上线并进行推广，累计问答数数千+，知识库范围内准确率85%+。

3.5.2 智能问数：AI探索灵活取数新解法 

面向猫超的业务同学，8月上线并进行推广，累计问答数数千+，知识库范围内准确率75%+。

3.5.3 维护案例：开发提效

当前，Matra-AI知识库已在指标理解、语义映射、基础召回等方面取得阶段性成果，初步支撑了自然语言取数场景的落地。但面对更复杂、多变、高精度的业务需求，我们仍处于“能用”的初级阶段，距离“好用、可信、自进化”的理想状态还有较大差距。未来，我们将围绕 准确性提升、知识持续保鲜、能力边界拓展 三大方向持续推进，打造一个更具智能性与生命力的知识基础设施。

当前AI在解析用户问题时，仍存在因语义歧义、别名覆盖不全、上下文缺失导致的误匹配现象，原文如下：

为此，下一步将重点提升知识库的语义表达能力和推理精度，我们在以下几个方向探索：

• 拓宽边界：建立案例库，收录高频、典型SQL模版以及解决方案；在BAD CASE复盘中，我们发现了一个现象,对于部分设计复杂的表，Marta生成 SQL可用性会大大降低，这些案例通常会稳定复现，对于这类用法稍显特殊或者复杂的表，我们的解法是给出案例库，BY表给出一些典型的CASE SQL。当用户问到该类问题时，将案例SQL作为知识输入prompt，辅助使用该表。

• 资产质量：知识库维护质量，从表、字段、指标、维度的维护质量、召回质量、回答质量进行建立打分机制，推动高质量的数据资产维护，避免“数据中毒”。

如今我们正在依托平台能力，搭建了简单的数据资产维护系统，但知识库的价值不仅在于“建得好”，更在于“跟得上”。业务迭代、表结构调整、口径变更频繁发生，若知识无法同步更新，AI输出的结果将迅速“过期”。目前我们对知识保鲜方面在以下几个方向探索：

• 事前：强化研发维护意识，将知识登记纳入关键交付节点（如需求上线、模型发布），提升团队主动维护意愿；
  

• 事中：当业务方提交新取数需求时，系统自动比对现有指标库，判断是否已有可复用口径；若发现“未建设”等问题，强制跳转至资产管理平台进行确认或注册；在研发流程中嵌入知识沉淀动作；
  

• 事后：建立多通道的知识更新触发机制，通过监听元数据变更事件（如ODPS表DDL修改、节点下线），触发告警并提示责任人更新知识库；
  

• 解析：借助线上代码以及大模型解析，实现知识自动补全。