从LLM到Ontology：本体驱动的AI数据研发原理与最佳实践
阿里云开发者 · 软件开发
左文雯、张哲旸 2026-11-06 09:48 浙江 阿里妹导读 当前大模型已能稳定生成语法正确的SQL，但在真实业务场景中，选表错误、字段误用与指标口径偏差仍普遍存在。其根因不在模型能力，而在于业务知识碎片化，指标口径与判定规则大量沉淀于历史生产代码和资深研发的经验判断中，缺乏结构化表达，模型无从获取。本文介绍将本体（Ontology）应用于数据研发领域的实践，把隐性业务知识转化为AI可读、可验证、可迭代的结构化资产，并给出自动抽取链路、召回与迭代机制的设计，以及技术评测与业务落地两层的验证结果。（文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。） 01 AI 生成 SQL 的三类典型错误 当大模型作为辅助开发工具进入数据开发场景，矛盾变得突出：模型的代码生成速度远超人类，但做出正确判断所需的业务知识，它无从获取。 1.1 一个看似简单的需求 以一个常见需求为例：业务方说「帮我查一下上月各品类的 top 品牌成交额及同比数据。」 需求只有一句话，看上去也不复杂。通用大模型几秒就能生成一段语法完整的 SQL，SELECT、FROM、WHERE、GROUP BY 结构齐全，逻辑通顺。但对照需求细看，问题就会暴露：品类下的品牌数据该从哪张表取？成交额对应哪个字段、是否包含退款？同比的口径又是什么？ 这些判断在 SQL 里没有标准答案。研发凭经验秒懂，模型只能猜。 1.2 三类高频错误 真实开发中上述问题很常见，我们把通用 AI 的生成错误归纳为三类： ① 选错表。 同一数据域下常有明细表、汇总表、快照表等十余张相似表，粒度各不相同。AI分不清这些表之间的区别，容易选一张看着对实则不满足需求的表。 ② 用错字段。 同名字段在不同表中含义不同，同一含义在不同表中对应的字段名也不同。AI直接按关键词匹配字段名，很可能选中与需求不符的字段。 ③ 口径对不上。 指标计算往往有一套约定俗成的口径：分子分母各取什么、是否剔除特殊数据、时间窗口怎么定义。成交额是实付金额还是剔退款金额？这些约定通常不在需求文档里，而在历史代码和个人经验中。 1.3 共同特征：SQL能跑，数据不对 这三类错误有一个共同特征： SQL能正常执行、能返回结果、不报任何错，但数据就是不对。 这也意味着它们无法被常规测试拦截：没有异常、没有报错，只有错误的数据流进看板。 本质：AI缺的不是语法能力，是做出正确判断所需的业务知识。 下一章拆解这个「业务知识」具体缺在哪。 02 根因分析：AI 的知识缺口 在谈解法之前，先要看清 AI生成SQL时，缺的业务知识到底是什么？拿两个需求拆开看。 第一个："店铺类型" 。听着是一个语义明确的业务概念，但在不同场景下对应完全不同的计算逻辑：决策域、服饰行业、国际行业分别依据不同的分类字段做判定。同一个业务概念对应多套判定逻辑，模型无法判断当前需求应走哪一套。 第二个：全网品牌归一 。目标是把多源品牌名称自动对齐到唯一品牌实体，包含多项难点： 难点 举例 表达高度碎片化与非标准化 同一品牌在不同渠道呈现为 Apple / 苹果 / APPLE Inc. / 苹果公司等多种形态 跨语言/跨形态的共指识别 Nike与耐克、Samsung与三星在数据中无显式关联，需要从共现、分布等隐式信号中挖掘 母子品牌嵌套 母公司品牌下常有多个子品牌（如宝洁↔佳洁士、海飞丝、潘婷） 保证归一化ID的权威性、稳定性与可追溯性 —— 模型看到的只是字面字符串，它不知道"Apple"和"苹果"指向同一实体，不知道 Nike 和耐克是跨语言同指，更不知道宝洁和佳洁士是母子关系。这些隐藏映射关系的处理依赖不同算法，模型不知道。 两个案例指向同一个根因： 语义理解 （表和字段的业务含义）、 规则理解 （指标口径与实体关系处理），这两层业务知识 AI 都获取不到。 由此可见，AI 生成 SQL 的准确性问题并非源于模型能力。实测中，同一需求换用更强的模型后，选表与语法的稳定性确有提升，但指标口径仍然存在偏差。原因在于：无论模型能力多强，都无法获取从未出现在上下文中的业务约定。 如果想让 AI 写准 SQL，就必须先让这些业务知识变得可读、可召回、可验证。这正是本体（Ontology）要解决的问题。 03 本体：将隐性业务理解结构化 既然瓶颈在业务理解，解法就要回答一个问题：如何让 AI 真正读到业务？ 我们的答案是 本体（Ontology） ：把指标口径、字段语义、业务规则、历史代码经验等隐性知识，沉淀为一份 可复用的结构化业务资产 。有了它，AI才有稳定的业务上下文，把 SQL 写对。 3.1 本体是什么：数据研发的「业务说明书」 一名有经验的数据研发接到需求时，脑海里的知识大致包括：这个业务域有哪些核心表、每个字段代表什么、关键指标怎么算、历史