基于本体的 AI 数据研发落地：淘宝行业经营分析实战

AI 生成 SQL 的三类典型错误

当大模型作为辅助开发工具进入数据场景，其代码生成速度虽快，却因缺乏业务上下文而难以做出正确判断。以“查询上月各品类 top 品牌成交额及同比”为例，通用大模型能快速生成语法完整的 SQL，但在表选择、字段映射和口径定义上极易出错。

高频错误归纳

真实开发中，通用 AI 的生成错误主要集中在以下三类：

• 选错表：同一数据域下存在明细、汇总、快照等多张相似表，粒度各异。AI 难以区分差异，易选中不满足需求的表。
• 用错字段：同名字段在不同表中含义不同，或同一含义对应不同字段名。AI 仅靠关键词匹配，易导致字段误用。
• 口径对不上：指标计算包含分子分母取值、特殊数据剔除、时间窗口定义等约定俗成的口径。这些规则通常不在文档中，而是隐藏在历史代码里，AI 无法获取。

共同特征：SQL 能跑，数据不对

上述错误的共同点是 SQL 能正常执行且不报错，但返回的数据结果错误。这意味着常规测试无法拦截，错误数据会直接流入看板。其根本原因在于 AI 缺失做出正确判断所需的业务知识，包括语义理解（表和字段的业务含义）和规则理解（指标口径与实体关系处理）。

根因分析：AI 的知识缺口

AI 生成 SQL 的准确性瓶颈并非源于模型能力不足，实测显示更强模型虽能提升语法稳定性，但无法解决从未出现在上下文中的业务约定问题。例如：

• “店铺类型”歧义：在不同业务域（决策、服饰、国际）对应完全不同的分类逻辑，模型无法判断当前语境应适用哪一套。
• 全网品牌归一：模型无法识别“Apple”与“苹果”、“Nike”与“耐克”的同指关系，也不知晓“宝洁”与“佳洁士”的母子层级，这些隐藏映射依赖特定算法和业务规则。

要让 AI 写准 SQL，必须将隐性业务知识变得可读、可召回、可验证。这正是本体（Ontology）旨在解决的核心问题。

本体：将隐性业务理解结构化

本体的定义与价值

本体是将资深数据研发脑海中的个人经验（核心表、字段含义、指标算法、历史坑点）转化为团队共享、AI 可读的结构化资产。其核心价值体现在：

• 消除歧义：将多义词绑定到具体业务域、字段和枚举。
• 补全规则：显式化散落在历史代码中的 CASE WHEN、映射表及兜底逻辑。
• 可迭代：支持人工修正与 Bad Case 回流，实现系统自我优化。

本体与相邻概念的区别

简言之，数据库管理数据存储，语义层统一口径，知识图谱处理关系推理，而本体专注于赋予 AI 写对 SQL 所需的完整业务理解能力。

本体的三层架构与五类知识

参考 Palantir 框架并重新界定边界，本体包含表本体、业务规则、指标定义、SQL 事实、血缘及值域等五类结构化知识。每条规则均可追溯至线上代码的具体位置。

本体三层架构

基于此构建的 OntSQL Agent 由本体资产、按需召回和飞轮迭代组成。

OntSQL Agent 架构

从生产代码中自动抽取本体

本体构建的核心挑战在于来源。相比人工整理或文档编译，直接从生产代码中自动抽取并验证是更高效的路径。

方案对比与选择

• 仅给 DDL：只能解决表结构问题，无法提供“表该怎么用”的语义信息。
• 人工整理知识库：维护成本高，容易过期，难以跟上业务迭代。
• 文档编译成知识库：依赖人工文档，覆盖面不全且自然语言难以机器校验。
• 代码自动抽取（本方案）：直接读取生产代码，知识源最准确，且通过结构化三元组实现机器可验证。

本体构建流程

1. 入口：核心表 + 血缘
从业务交付表和看板表识别核心表，结合数据血缘自动解析上下游表。约四成的本体表资产是通过血缘分析挖掘出来的。

2. 形态：结构化三元组
不生成自然语言描述，而是将 SQL 中的业务逻辑抽取为结构化三元组（条件、动作、源码指纹）。例如“店铺类型”判断逻辑被拆解为分支序号、判断条件和结果动作，并绑定生产节点 ID。

case_group:      shop_type               # CASE组
branch_order:    1                       # 分支序号
condition_sql:   shop_name IN (条件A,条件B)  # 判断条件
action_sql:      结论A                   # 结果动作
source_sql_hash: bbbd38537a7ba41e        # 源码指纹
evidence_sql_node: 308513553             # 生产节点ID

3. 校验：三道关卡防幻觉

• 对指纹：抹平格式差异后比对源码指纹，确保规则源自真实 SQL。
• 回溯 SQL：将规则放回生产 SQL 验证对应分支，删除无落脚点的虚构规则。
• 查格式：检查字段完整性与格式规范性。

4. 人工介入最小化
仅在核心表首次接入和线上发现逻辑冲突时进行人工复核，其余拉取元数据、抽取规则、校验指纹等环节均由自动化完成。

本体如何进入 AI 生成链路

本体资产构成

除了表本体和业务规则，本体还包含时间切换逻辑（如旧版/新版映射表）、血缘关系、值域画像及 SQL 事实（惯用写法）。其中，业务规则是解决复杂口径问题的核心。

本体资产

按需召回：给材料，不给硬规则

为避免上下文过长导致注意力稀释，采用渐进式披露策略。Agent 根据需求自动召回相关度最高的表本体、指标口径、业务规则、历史 SQL 参考及值域证据。

召回结果示例

设计原则是“给材料而非硬规则”。早期尝试强制约束规则导致模型灵活性下降，现改为由本体提供证据，模型自行判断如何使用。召回逻辑由确定性程序控制，确保同一需求召回结果的一致性。

迭代飞轮：三条反馈链路

为解决知识库老化问题，建立三条反馈链路持续优化本体：

• 研发修改 Diff：对比 AI 初稿与最终上线 SQL，回流人工修正的逻辑。
• 评测集驱动：基于客观评测集分析 Bad Case，补充本体缺口或调整召回策略。
• 线上使用日志：收集业务用户的提问、失败日志及修正操作，补充场景规则。

飞轮闭环：三条本体反馈链路

技术复用性

该技术具备跨场景和跨平台复用能力。生成本体的技术方案可快速复制到其他业务域；本体资产标准化为 Turtle/JSON/Markdown，不绑定特定 AI 平台，仅需薄入口即可读取。

效果验证：技术评测

评测体系

构建基于真实业务工单的动态评测集，每条 Case 包含需求、依赖表及 Ground Truth SQL。实施五层递进检测（语法、选表、字段、业务规则、数据结果），其中业务规则权重最高（40%）。

实测对比

引入本体后，字段维度提升明显，业务规则维度的规则完整度显著改善。无本体时 AI 基本靠猜，引入本体后能通过历史代码和值域分布补齐关键规则分支。

效果验证：业务落地

引入 OntSQL Agent 后，数据开发模式从“逐行手写”转向“审核与兜底”，效率显著提升。

• 需求承接量：月均处理量提升数倍，单需求交付周期大幅缩短。
• AI 代码占比：从个位数提升至八成以上，AI 已成为实际生产力。

承接需求量统计

需求开发效率统计

AI行占比指标统计

总结：数据研发角色的重新定义

通用模型写 SQL 的瓶颈不在于代码生成能力，而在于缺乏准确的业务知识。本体的引入实现了人与系统的分工重构：

• 模型负责确定性：执行既有规则、查阅历史逻辑、对齐字段口径、实现语法编码。
• 人负责不确定性：定义业务规则、进行价值判断、把关结果质量。

这一转变使单个需求的整体耗时从数人日缩短至约一人日。省下的时间从“执行”转移至“定义与判断”，推动数据研发角色从代码执行者升级为规则定义者与质量把关者。