从LLM到Ontology：本体驱动的AI数据研发原理与最佳实践

当大模型作为辅助开发工具进入数据开发场景，矛盾变得突出：模型的代码生成速度远超人类，但做出正确判断所需的业务知识，它无从获取。

以一个常见需求为例：业务方说「帮我查一下上月各品类的 top 品牌成交额及同比数据。」

需求只有一句话，看上去也不复杂。通用大模型几秒就能生成一段语法完整的 SQL，SELECT、FROM、WHERE、GROUP BY 结构齐全，逻辑通顺。但对照需求细看，问题就会暴露：品类下的品牌数据该从哪张表取？成交额对应哪个字段、是否包含退款？同比的口径又是什么？

这些判断在 SQL 里没有标准答案。研发凭经验秒懂，模型只能猜。

真实开发中上述问题很常见，我们把通用 AI 的生成错误归纳为三类：

① 选错表。同一数据域下常有明细表、汇总表、快照表等十余张相似表，粒度各不相同。AI分不清这些表之间的区别，容易选一张看着对实则不满足需求的表。

② 用错字段。同名字段在不同表中含义不同，同一含义在不同表中对应的字段名也不同。AI直接按关键词匹配字段名，很可能选中与需求不符的字段。

③ 口径对不上。指标计算往往有一套约定俗成的口径：分子分母各取什么、是否剔除特殊数据、时间窗口怎么定义。成交额是实付金额还是剔退款金额？这些约定通常不在需求文档里，而在历史代码和个人经验中。

这三类错误有一个共同特征：SQL能正常执行、能返回结果、不报任何错，但数据就是不对。

这也意味着它们无法被常规测试拦截：没有异常、没有报错，只有错误的数据流进看板。

本质：AI缺的不是语法能力，是做出正确判断所需的业务知识。

下一章拆解这个「业务知识」具体缺在哪。

在谈解法之前，先要看清AI生成SQL时，缺的业务知识到底是什么？拿两个需求拆开看。

第一个："店铺类型"。听着是一个语义明确的业务概念，但在不同场景下对应完全不同的计算逻辑：决策域、服饰行业、国际行业分别依据不同的分类字段做判定。同一个业务概念对应多套判定逻辑，模型无法判断当前需求应走哪一套。

第二个：全网品牌归一。目标是把多源品牌名称自动对齐到唯一品牌实体，包含多项难点：

• 消除歧义：把「店铺类型」这种多义词，绑定到具体业务域、具体字段、具体枚举；
• 补全规则：把散落在历史代码里的 CASE WHEN、映射表、兜底逻辑显式化；
• 可迭代：每一次人工修正、每一次 bad case，都可以回流本体，让系统越用越准。

简单区分：数据库管「数据在哪」，语义层管「口径统一」，知识图谱管「关系推理」，本体管的是「让 AI 具备写对这类 SQL 所需的完整业务理解」。

我们参考 Palantir 的三层本体框架，并重新界定了每一层在数据研发中的边界：

本体三层架构

具体而言，本体承载五类知识：

上述知识全部结构化存储，每条规则可追溯到线上代码的具体位置。

基于此，我们构建了基于本体的 AI 数据研发工具：OntSQL Agent = 本体资产 + 按需召回 + 飞轮迭代。

OntSQL Agent 架构

本体是什么讲清楚了，下一个问题：本体从哪来？

这是工程落地中最核心的挑战。我们的答案是：不靠人工逐条整理口径，而是让模型从生产资料里自动抽，再让机器反过来验证。

对上述方案进行逐项分析：

① 只给 DDL 无法解决语义问题。DDL里只有字段名和类型。以上述品牌归一需求为例，给出 DDL 后 AI 知道有某个品牌 ID 字段，但不知道它什么时候该用、和另一个字段什么关系、映射不上该怎么兜底。DDL给的是「表长什么样」，我们缺的是「这张表该怎么用」。

② 人工整理知识库方向对，效果好，但维护不动。以我们的真实业务场景为例，线上表逻辑和数据口径一直在变。靠人读SQL、写文档、再持续更新，写的时候慢，写完很快过期。

③ 让 AI 把文档编译成知识库是最近流行的做法，也是一些 LLM-Wiki 的建设思路：先把零散文档编译成结构化知识页，查询时优先查知识库。这个思路我们认可，本质上和我们一样，都是「先编译再查询」。但落到数据研发场景有两点不同：

• 知识来源不同。知识库依赖人写的文档，而实际生产中大量需求是语音会议形成共识、协作平台上给一句简短描述、数据同学就直接开发。更关键的是，许多口径并无文档或文档不完整，补齐文档本身的成本最高，因此我们选择直接读取生产代码。

• 产物不一样。知识库方案编译出的是自然语言知识页，例如「按层级逐级匹配」这类表述，机器无法判断其与当前线上代码是否仍然一致。需要说明的是，文档编译方案可整合多种格式的资料，覆盖面更广、建设周期更短。我们则更专注于 SQL 生成：输入为业务知识资料包，产出为SQL。

我们不是拿到一份 SQL 就分析构建规则，然后等待下一份输入，而是从核心表进去，顺着它的上下游把该带的表和知识一起带出来。

先说入口。从业务交付表、看板展示表自动识别出这个场景真正在用的表，也就是核心表，再由数据研发同学手动补充、核实。这批表是起点，不是边界。顺着核心表的上下游又带出一批，最终本体里有四成的表，是靠血缘分析找出来、确认有价值后才建的。

以某品牌核心表为例，通过 DataWorks SKILL 读它的生产SQL，血缘信息自动解析出上游表，且每张都能自动分析它在这条链路里干什么，这就是为什么最终本体中的表资产比核心表清单多。核心表决定从哪儿进去，上下游决定能捞回多少东西。

我们不让模型写自然语言描述规则，而要求它输出三元组。

我们的做法是从生产环境中自动抽取运行中的SQL与元数据，让模型把每条 SQL 中的业务 CASE WHEN 抽取为结构化三元组。以“店铺类型”判断为例，抽取结果如下：

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

使用结构化保存，不是因为模型看不懂自然语言，而是一句话没法校验：说不出它对应 SQL 哪一段，也说不出有没有过期。写成条件和动作，规则就能和 SQL 分支逐条对上，脚本自动对齐写法差异，算出指纹逐条落库，并绑定生产节点。

我们要的不是给人看的文档，是机器自己能查的资产。

大模型幻觉在真实生产中难以避免，哪怕是旗舰模型也会抽错、也会编出 SQL 里根本没有的规则。所以抽完的规则不能直接用。

第一道：对指纹。每条规则都算一个指纹。算之前先把空格、大小写这些不影响语义的差异抹平，所以只要说的是同一段SQL，人写的和模型抽的指纹就一定一样。实测上述品牌案例中人工写的规则，模型全都抽到了，指纹条条对得上。

第二道：回溯SQL。把本体里的每条规则拿回生产SQL，看它到底对应哪个分支。要是有哪条在 SQL 里找不到落脚点，那就是模型编的，直接删掉。实测某核心表留下关键分支规则，条条都能对上SQL，没有一条是多出来的。

第三道：查格式。检查每条规则该填的字段有没有填全、格式对不对。

这三道关只解决一件事：抽出的规则和生产代码逐条对得上。

一处是核心表第一次进本体时人工过一遍，验证、复核、补充。另一处是线上发现生成得不对时（校验规则未通过、发现逻辑冲突等），人工看一眼是不是本体的问题，再决定要不要改本体。

除了这两处，拉元数据、抽规则、对指纹、回溯SQL、表刷新后重新检查，全是机器自己跑。

把上述品牌需求 case 从头连起来看：一张核心表进去，自动带出上下游、规则、时间切换、数据血缘信息，每条规则都查得到它来自线上哪个节点，人只在最后检查一遍。

首次接入一张再难的表，只需要一个权限账号加一次人工校验；之后口径变了，机器自己能发现并提示刷新。原来最重的知识库维护工作，从人工整理变成了机器抽取加少量把关。

上一章节说清了本体怎么建，这一章讲清本体怎么用。

在真实业务场景中，我们自动化构建了表本体、业务规则、指标定义，外加 SQL 事实、血缘、值域等生产证据和一层召回索引。复杂业务场景的真正难点，不在选哪张表、用哪个字段，而在口径怎么定、逻辑怎么算。因此，业务规则是整套本体资产的核心。

本体资产

除了表本体和业务规则，还有几类单张表装不下的知识：

• 时间切换：某业务的映射表是按业务日期选表的，某个日期之前用旧版映射、之后用新版，生产上是用 UNION ALL 加 label 字段实现的。这条规则不写在任何字段注释里，AI 不知道就会只读一张表，历史数据直接算错。

• 血缘：记清每张表的上下游和引用位置。

• 值域画像：记录字段的真实取值分布。

• SQL 事实：记录这张表惯用的写法，比如逐级降级、去重方式。

本体里上千条规则，每次写 SQL 不能全给，上下文太长，反而稀释关键信息。

这不是我们的独有发现。业界把这个问题叫注意力稀释：上下文窗口的「物理容量」和「有效容量」是两回事，一个塞满无关信息的长上下文，有效容量可能还不如一个精心裁剪的短上下文。我们的召回机制对应的正是业界所说的渐进式披露（Progressive Disclosure），只在需要时才加载需要的知识。

召回模拟的是老研发接到需求时的思维过程。 Agent 判断这是一个 SQL 生成任务后，按规则约定自动调起召回，拿到上下文包之后才开始写 SQL。召回结果包含：

• 需求相关的表本体与字段语义；

• 相关的指标口径定义；

• 触发条件匹配的业务规则；

• 历史相似 SQL 的写法参考；

• 值域、枚举、异常处理等生产证据。

以上述品牌需求为例，一次召回是七路并行的：相似实现、时间切换、血缘、值域画像、表族信息。相关度最高的那张表本体，召回没有全复制，只挑了和本需求最相关的规则，召回的规则恰好就是这个需求最容易踩坑的地方。

召回结果

这里有一个刻意的设计，也是我们踩过坑之后换来的：召回给的是材料，不是硬规则。

我们不改写 AI 的输出，也不强制它必须用哪条规则。早期试过把召回约束得很死，把规则写成必须遵守的指令，结果反而把模型能力限窄了：它从「聪明的 AI 工具」退化成「蠢笨的规则执行器」，遇到规则没覆盖的情况就不会推理了，生成质量不升反降。

这和 Agent 设计里「从防御到赋能」的思路是同一件事：与其用更多约束去堵错误的出口，不如把该看的资料找全，打开正确的入口。现在本体只负责供给证据，用不用、怎么用交给模型判断。

另外，召回内部是确定性的程序逻辑，召回什么不由模型临场决定，同一个需求跑多少次结果都一样。

本体不是一次性调优的产物。静态知识库一定会老化，代码重构了但知识没跟上，口径变了但规则还是旧的。为了解决这个问题，我们设计了三条反馈链路，把真实使用中的修正持续回注本体：

研发真实修改 diff：对比 AI 初稿与最终上线 SQL，把人工补的字段、过滤、join、CASE WHEN 和口径修正回流；

评测集驱动：构建客观评测集，将扣分 case 拆解为本体缺口 / 召回不足 / 模型误用 / 需求隐含条件，用来补规则、补证据、调召回；

线上使用日志：Qoder、千问办公等平台给业务使用后的提问、结果、失败日志和人工修正，补充场景规则与使用约束。

三条链路的反馈汇入反馈池，经人工确认后写回本体，驱动下一轮本体修正。

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

技术复用有两个维度：生成本体的技术可跨业务域复用，沉淀的本体资产可跨平台移植。

• 跨场景复用：生成本体的技术方案不与具体业务场景绑定。同一套「自动抽取 + 飞轮迭代」能力，可以快速复用到其他业务域。

• 跨平台复用：本体不绑定 AI 平台。资产标准化为 Turtle / JSON / Markdown + 索引文件，SQL 生成日志、采纳统计、反馈、回归测试等链路均为独立 Python 模块。通用Agent等平台只需保留薄入口，读取同一套资产即可。

我们已在不同平台跑通真实需求链路，验证了入口、资产、链路均可替换。换工具不换知识，这让业务知识真正沉淀为团队的资产，而不是某个工具的附属品。

方案做出来不等于真的有效。我们构建了一套贴合真实业务的评测体系，从评测集构建、规则设计到效果分析，验证「本体+飞轮」是否真正让 AI 从「看不懂、写不准」进化到「读得懂、写得对」。

评测集的 case 全部来自真实业务工单，每条 case 包含需求信息、依赖表、Agent 需求输入等完整上下文，并绑定已上线的生产 SQL 作为 Ground Truth。

评测集不是一次性维护的静态集合，而是通过定时抓取 + LLM 自动分类实现自动入库，随业务需求增长持续扩充。

我们设计了五层递进检测，从语法到最终数据结果逐层校验。不通过时自动归因到具体层级和原因，结果回流飞轮，形成「生成 → 评测 → 归因 → 修正」的自动闭环。

评测链路由「拉取评测集 + 预处理」与「AI 生成 SQL + 五维评测」两个 Skill 串联，实现全流程自动化。

前者从线上评测集增量拉取 case，预处理后为每条 case 生成三份文件：评测集元数据、需求原文与 Ground Truth（下称 GT）SQL。后者在限定本体条件（有无本体、本体版本）后，由 LLM 生成 SQL 作为待评测代码。

代码生成过程遵循两条硬规则：① 禁读 GT SQL，同时禁止通过节点 ID 反查代码，防止模型直接复用标准答案；② 仅读取当前版本本体，禁止读取其他版本、共享生产版本或个人工作区版本，以保证版本间可比。

五维评测对语法、选表、字段、业务规则、数据结果五个维度分别赋权 10、20、20、40、10，合计 100 分。其中业务规则维度权重最高，因为该维度是 AI 当前最薄弱的环节，也是本体价值最集中的地方。每条 case 依据总分划分为「通过」与「不通过」两类。

引入打分机制，是为了量化对比不同版本本体的优化效果；而最终结论采用 0/1 二分呈现，则可使结果更为清晰直观。

语法和选表已稳定通过评测，字段维度提升最为明显，目前模型瓶颈主要集中在复杂业务规则的完整还原上。业务规则维度表面仅提升 1 分，但每个需求包含多条规则，评分按"全部命中"计算；实际拆解来看，无本体时，AI生成的映射规则基本错误，代码不可用；引入本体后，此前完全依赖模型猜测的规则分支，已通过历史代码和值域分布补齐，规则完整度有明显改善。以上述品牌需求为例：

引入 OntSQL Agent 后，数据开发的工作方式发生了明显变化：AI承接业务理解并撰写代码初稿，研发从“逐行手写代码”转向“审核与兜底”。

需求承接统计：从需求交付节奏看，引入 OntSQL Agent 后月均需求处理量提升数倍，单需求交付周期大幅缩短。这说明 AI 不仅提升了单需求开发效率，更实质性放大了整体的需求吞吐量。

承接需求量

需求开发效率

AI行占比统计：月均 AI 代码行占比持续提升，从个位数提升至八成以上。这些数字共同说明，AI已经从辅助工具升级为数据开发的实际生产力。

AI行占比指标统计

综合全文，当前通用模型写 SQL 的瓶颈不在模型能力，而在于能否获取足够且准确的业务知识：模型不缺代码生成能力，缺的是用哪张表、取哪个字段、指标口径怎么算这些规则。模型擅长执行已经被定义清楚的规则，而规则本身需要人来定义，数据研发的「重新定义」正是发生在这条边界上。

所谓重新定义，不是 AI 取代数据研发，而是人与系统重新划分分工：模型承接确定性，人专注不确定性。

模型负责确定性、可复现、依赖信息检索而非业务判断的环节：逐行编码与语法实现，查阅历史逻辑、追溯血缘与下游影响，对齐字段口径、套用既有计算范式。这些过去占据一个需求大部分工时的重复性劳动，本质是执行既有规则，因此可以被系统稳定承接。

人负责需要业务知识输入、需要价值判断、无法从既有信息推导出来的环节：定义业务规则、做方案取舍、把关结果质量。AI越强，系统越能把人定义清楚的东西执行好；而定义的精确程度，决定了产出的质量上限。

这一分工带来的直接变化是效率：一个需求的整体耗时从数个人日缩短至约一个人日。省下的时间并非凭空消失的工作量，而是从「执行」转移到了「定义与判断」。数据研发的角色随之升级，从代码的执行者转向规则的定义者，从逻辑的实现者升级为质量的把关者。