天猫超市数据AI实践总结

数据资产规模上来了，治理的坑也一个接一个地暴露出来。天猫超市这次选择用AI来解这道难题——从零开始搭一个知识库，让机器能听懂业务问什么，再自动把数取出来。这个探索路径，值得聊一聊。

先说说面临的实际困境。业务跑了十年的数据体系，沉淀下来的是数万张表、近万个调度节点，核心保障任务占了三成以上，覆盖供应链、交易、日志、商品、直播等多个数据域。规模大是好事，但历史遗留问题也不少：大量字段和指标缺乏统一命名标准和清晰语义描述，“同名异义”和“异名同义”的情况比比皆是；业务变迁、组织融合带来的“僵尸表”和过时口径长期无人清理；关键业务知识，比如指标口径、维度解释、依赖关系，散落在脚本、报表和内部文档里，缺乏统一归集。与此同时，研发团队还得应付日常的站点维护、数据答疑和临时取数需求，精力被严重分散。

另一边，业务同学的日子也不好过。日常工作中大量依赖手动汇总多系统数据来更新日报、周报和专项分析，重复劳动多、响应周期长。正是在这个大背景下，AI数据助手项目启动了。

目标很直接：让AI像专业的数据工程师一样，听懂业务问题，自动规划取数路径，生成并执行SQL，输出分析结论。从“人找数”变成“AI取数、分析、用数”。

背景

大模型在自然语言理解、生成与推理上的突破，让AI不再局限于图像识别或推荐系统，开始向复杂决策和自主执行演进。“Data Agent”也因此成为企业智能化升级的一个重要方向。

不过，一个高效、可靠的Data Agent，离不开强大且结构化的知识支撑体系。没有高质量的知识库，AI很难准确理解语义、正确生成逻辑、稳定交付结果。所以，构建一套面向AI的、可理解、可检索、可推理的知识库体系，就成了推动数据研发提效、赋能智能取数的核心基础设施。下面就以AI项目实践为基础，系统梳理在知识库方案设计、内容构建、维护挑战、图谱召回及平台化落地等方面的探索与经验。

知识库设计

在确定建设方案之前，先想清楚三个问题。

。数据资产太多，研发精力有限，不可能面向AI重构数据模型，只能优先在知识库层面让LLM理解现有表设计。知识库结构要灵活，前期可以用钉钉表格、文档来维护，因为业务指标和知识本身会不断调整。最后，数据资产质量参差不齐，不能全量维护，必须先筛选核心资产，从小而精的知识库开始慢慢扩展。牺牲一些全面性，但能提升准确性。

。一个数据需求要明确哪些信息才能开发？指标定义（名称、公式、是否可加）、数据粒度（聚合粒度）、数据范围（日期限制、业态限制、取数限制）。这些信息正好构成了写SQL的必需条件。所以，知识库自然而然分成了五类：指标逻辑、实体、属性、表、字段。

。从大图来看，结构设计遵循了这样的原则：业务范围极低频变更，主要用于声明表包含了什么业态的数据；数据域低频变更，作用是划分后续维护知识的小组；实体较低频变更，主要划分属性信息；属性区分数仓中的叫法，这里的属性既指实体的属性，也指数据分析中的维度；指标只包括原子指标和拓展指标，不维护衍生指标，让LLM自己去理解属性和指标的组合；表清单作为图谱输入的标准化数据资产；字段则结合人工维护和模型优化来改写DDL。

的核心在于，借助大模型对表和字段进行关键词提取和备注描述优化，同时通过人工维护、模型优化后的表备注、表关键词、标准名称来改写DDL，只保留需要消费的字段，无关字段不进入图谱。

知识库实践与效果

知识库构建经历了两个阶段。第一阶段是通过钉钉文档快速维护核心数据资产，供给知识图谱和下游Agent使用，跑通POC案例，在实践中不断完善方案。随着应用场景扩展，知识库结构相对稳定，就进入了第二阶段——产品化建设。

。基于方案，结合元数据对表、字段、指标进行筛选，借助大模型提取关键词并进行泛化。比如，“支付金额”这个标准名称，泛化后覆盖了成交金额、GMV、支付金额、交易金额、子订单支付金额等多个别名；“供应商编码”泛化后包括供应商编码、商家编码、二级供应商编码、supplier_code等。实践证明，问GMV能正确找到对应字段，查找商家、供应商都能定位到商家维表。

表备注需要描述清楚业务范围、数据内容、数据粒度、回刷策略、取数限制等信息，关键词则帮助模型理解表的用法。DDL字段与标准指标和标准属性绑定，只维护需要消费的字段。

。维护过程中，钉钉文档的SOP暴露出不少问题。知识库中五类知识必须强关联，否则大模型理解不了；知识发生变更需要研发手动修改所有关联项，容易遗漏；人工填写多套相似中英词组合、判重、重复写入等工作量巨大。仅仅维护一个域的4个中间层表，就需要研发2人时的精力。

为了解决这些问题，团队通过与AI自然语言交互搭建了一套资产维护平台。平台支持自动解析ODPS数据表信息，字段维护时系统会自动识别指标和维度，研发只需要确认。实体、属性、指标的管理都支持泛化词生成和重复校验，极大减少了人工操作。

。数据资产涉及大量表及字段，传统RAG方法难以准确刻画多表关联关系，容易产生“幻觉表”。采用GraphRAG技术，通过构建结构化的知识图谱，全面表达和推理表与字段之间的关联关系，显著提高召回准确性。

的流程是：接收到用户查询后，先进行分词和实体映射，借助模糊词库和公式库识别模糊表达和相关业务公式。比如，“今年美妆某场域的笔单价是多少”这个问题，“美妆”映射为“大组名称”，“笔单价”通过公式识别为“笔单价 = 支付金额 / 支付父订单量”。分词结果映射到知识图谱中的标准实体后，从图谱中检索能覆盖所有目标实体的最优路径，输出Top K的路径结果。

。项目底层算法能力尚未对基座模型做SFT，仅通过基座模型的编排和串联实现，这对算法框架设计、知识库查询速度和准确性、Prompt设计提出了更高要求。在NL2SQL过程中，主要面临用户意图识别与数据表召回困难、自然语言映射SQL困难、复杂任务执行风险三个问题。

解决方案是设计三个核心模块：意图识别+知识图谱模块，精准识别问题并召回对应数据表；ReAct框架，通过提示词工程引导大模型分步推理，利用上下文验证机制对生成SQL进行双重校验；Plan&Execute框架，将任务拆解为原子子查询，使用任务调度器管理中间状态与依赖关系。

。面向技术同学的资产查询功能上线后，累计问答数千次，知识库范围内准确率85%以上。比如，输入“货品交易并给出SQL代码”，模型能正确返回货品交易表并提供货品维度的成交SQL；输入“行业线维度的周转怎么获取”，模型能返回周转汇总表以及行业线配置表，并给出关联逻辑正确的SQL。

面向业务同学的智能问数功能，上线后累计问答数千次，知识库范围内准确率75%以上。输入“FYTD等多周期销量计划准确率分别多少？”时，模型能返回多个时间周期的准确率；输入“需要获取新业务场景8月全月采购小二维度的父订单数和子订单数，导出excel格式”时，模型能理解新业务识别逻辑，多表关联正确找到小二映射表。

在开发提效方面，得益于知识库的能力，维护一条商品属性、更新图谱后，就能支持场域、大盘等场景的多品类多维度的问数和取数，传统开发流程需要2到4个人日的工作量大幅缩减。

未来规划

当前AI知识库已在指标理解、语义映射、基础召回等方面取得阶段性成果，但距离“好用、可信、自进化”的理想状态还有较大差距。未来将围绕三个方向持续推进。

。当前因语义歧义、别名覆盖不全、上下文缺失导致的误匹配现象依然存在。比如，用户输入“2025年7月的用户中，新客、老客分别的购买客单价和购买笔数是多少？同比2024年7月的数据是怎样的？”时，模型可能错误地认为新客、老客都是用户分层标签，忽略了纯新客关联不到标签表的特殊逻辑。解决方案是建立案例库，收录高频、典型SQL模板和解决方案，同时对表、字段、指标、维度的维护质量和召回质量建立打分机制，推动高质量的数据资产维护。

。知识库的价值不仅在于“建得好”，更在于“跟得上”。目前正在搭建的数据资产维护系统，从事前强化研发维护意识、事中自动比对现有指标库并嵌入知识沉淀动作、事后监听元数据变更事件触发更新、借助线上代码和大模型解析实现知识自动补全几个方向探索，让知识库真正“活”起来。