从 LLM 到 Ontology：本体驱动的 AI 数据研发原理与最佳实践
BestBlog编程类文章 · 软件开发
📌 一句话摘要 本文探讨将本体（Ontology）应用于数据研发领域，通过自动抽取生产代码中的业务规则和口径，构建结构化知识资产，显著提升大模型生成 SQL 的准确性，实测字段维度提升 3 分，业务规则提升 1 分。 📝 详细摘要 本文聚焦于 AI 生成 SQL 在数据研发场景中的准确性问题，归纳出选错表、用错字段、口径对不上三类高频错误。作者指出根源在于业务知识碎片化、口径沉淀于历史代码和经验中，缺乏结构化表达。为此提出本体方法论，将隐性业务知识转化为 AI 可读、可验证、可迭代的结构化资产。文章详细阐述了本体的三层架构和五类知识（表本体、字段语义、指标口径、业务规则、生产证据），并介绍了从生产代码自动抽取本体的技术方案，包括四种方案对比、核心表+血缘入口、结构化三元组抽取以及三道校验机制。最后展示了本体如何进入 AI 生成链路，设计了按需召回和三条反馈闭环，确保知识持续迭代。技术评测显示，引入本体后字段维度准确率提升至 7/8，业务规则命中率显著改善，验证了本体方法的有效性。 💡 主要观点 识别 AI 生成 SQL 的三类核心错误：选错表、用错字段、口径对不上 通过业务案例分析，归纳出通用模型在数据开发场景中最常见的错误类型，这些错误虽然 SQL 语法正确，却导致数据不准确，凸显业务知识获取的瓶颈所在。 提出本体方法论，将隐性业务知识转化为结构化资产 通过构建本体（Ontology），把指标口径、字段语义、业务规则等沉淀于历史代码和经验中的知识，转化为 AI 可读、可验证、可迭代的结构化资产，为 AI 生成准确 SQL 提供可靠依据。 设计自动抽取机制，从生产代码中提取结构化三元组 通过核心表+血缘分析入口，自动抽取运行中的 SQL 与元数据，将业务 CASE WHEN 抽取为结构化三元组（case_group、branch_order、condition_sql、action_sql 等），并通过指纹校验、回溯 SQL、格式校验三道关防止模型幻觉。 构建按需召回和飞轮迭代机制，确保知识持续更新 设计了按需召回机制，仅提供需求相关的材料而非硬规则，避免注意力稀释；同时通过研发修正 diff、评测集驱动、线上日志三条反馈链路，将真实使用中的修正持续回注本体，形成闭环迭代。 通过技术评测验证本体方案的有效性 构建五层递进检测体系（语法、选表、字段、业务规则、数据结果），实测显示引入本体后字段维度提升至 7/8，业务规则命中率显著改善，验证了本体方法能有效提升 AI 生成 SQL 的准确性。 💬 文章金句 AI 生成 SQL 的准确性问题并非源于模型能力。实测中，同一需求换用更强的模型后，选表与语法的稳定性确有提升，但指标口径仍然存在偏差。原因在于：无论模型能力多强，都无法获取从未出现在上下文中的业务约定。 本体要做的，就是把这套个人经验变成团队共享、AI 可读的资产。 我们要的不是给人看的文档，是机器自己能查的资产。 召回给的是材料，不是硬规则。我们不改写 AI 的输出，也不强制它必须用哪条规则。 研发真实修改 diff：对比 AI 初稿与最终上线 SQL，把人工补的字段、过滤、join、CASE WHEN 和口径修正回流。 📊 文章信息 AI 初评： 90 精选文章： 是 来源： 阿里云开发者 作者： 阿里云开发者 分类： 软件编程 语言： 中文 阅读时间： 32 分钟 字数： 7759 标签： 编程与工程 , 大语言模型 (LLM) , AI Agent , 提示工程 , 系统设计 阅读完整文章