从"会写 SQL"到"懂业务"：智能问数 Agent 的三层 Grounding 实践
分享场景 ：AI+Data 主题技术沙龙
预计时长 ：30 分钟演讲 + 15 分钟 Q&A
目标受众：数据工程师、AI 应用开发者、数据产品经理
🎙️ 开场白：一个典型的"翻车"现场
大家好。在开始之前，我想请大家回想一个场景：
业务方在聊天框里问："上周华东区的复购率为什么下降了？ "
你的 NL2SQL 系统迅速生成了一段 SQL，执行无误，返回了一个数字。
但业务方看了一眼说："不对，这个复购率定义不含退款订单，而且华东区应该包含上海仓。"
这就是当前智能问数领域的最大痛点：模型学会了 SQL 语法，却没学会业务语义。
今天，我想基于 OpenAI 最新披露的《Inside OpenAI's in-house data agent》技术文章，和大家拆解一个核心命题：如何让我们的 Data Agent 从"会写 SQL 的翻译官"，进化为"懂业务的分析师"？
核心答案在于一个概念：三层 Grounding（接地）体系。
🛑 第一部分：困境------为什么传统 NL2SQL 走不远？
过去两年，我们见证了 Text-to-SQL 技术的爆发。但我们在落地中发现，准确率往往卡在 60%-70% 的瓶颈。为什么？
- Schema 歧义 ：数据库里有 5 张表都叫
users，哪张才是含 VIP 信息的？ - 逻辑黑盒 ：指标计算逻辑写在几百行的 ETL 代码里，Schema 里只有一列
revenue，但没说是否含税。 - 缺乏验证：模型生成 SQL 后直接执行，哪怕结果是空集或异常值，也不会自我怀疑。
结论：仅靠 Prompt Engineering 和微调，无法解决"业务上下文缺失"的问题。我们需要给 Agent 装上"业务眼镜"。
💡 第二部分：破局------OpenAI 的三层 Grounding 体系
OpenAI 在其内部数据 Agent 中，构建了一个分层的上下文系统。这不是简单的 RAG，而是多维度的语义对齐。
🧱 Layer 1: Table Usage（技术层 grounding）
解决"表怎么用"的问题。
- 传统做法：只给 Agent 看 DDL（列名、类型）。
- 进阶实践 ：
- 血缘关系：告诉 Agent 表 A 是表 B 的聚合结果，避免重复计算。
- 查询模式 ：学习历史高频 JOIN 路径。例如，
orders表通常要和order_items连，而不是直接连users。 - 使用热度：标记哪些表是"核心生产表"，哪些是"废弃测试表"。
💡 技术要点：利用 SQL 日志解析 JOIN 图谱，构建表级的共现矩阵。
🧱 Layer 2: Human Annotations（业务层 grounding）
解决"词什么意思"的问题。
- 痛点 ：技术名词 vs 业务术语。开发叫
status=1，业务叫"已完成"。 - 进阶实践 ：
- 领域专家标注：让数据分析师为关键表添加自然语言描述。
- 陷阱预警：标注已知数据质量问题（例："2023 年之前的数据缺失地区字段"）。
- 术语对齐：建立业务词汇表（Glossary），将"复购率"、"留存"映射到具体 SQL 逻辑。
💡 技术要点：这不是静态文档，而是可检索的向量库，Agent 在规划阶段主动查询。
🧱 Layer 3: Codex Enrichment（代码层 grounding）⭐ 核心创新
解决"数据从哪来"的问题。
这是 OpenAI 方案中最具突破性的一点。数据的真实含义，往往不在 Schema 里，而在生成数据的代码里。
- 实践做法 ：
- Agent 不仅读表结构，还通过 Codex 读取ETL Pipeline 代码。
- 案例 ：Schema 里有一列
active_user。通过读代码，Agent 发现这列数据过滤了login_count > 0且region != 'CN'。 - 价值 ：当用户问"包含中国的活跃用户"时，Agent 能意识到这张表不满足条件，从而自动切换数据源或调整逻辑。
🚀 核心洞察 ：Meaning Lives in Code（语义存在于代码中）。通过理解数据生产逻辑，Agent 获得了超越元数据的"深层语义"。
🔄 第三部分：进化------从"翻译官"到"分析师"
有了三层 Grounding，Agent 就不再是一个简单的翻译器，而具备了闭环推理能力。
1. 自主规划与执行
Agent 不再是一次性生成 SQL，而是像人类分析师一样思考：
- Plan：我需要哪些表？先查总量还是先查细分？
- Execute：生成 SQL 并执行。
- Verify ：关键步骤 。检查结果是否合理？
- 如果是空集，是不是过滤条件太严？
- 如果数值异常大，是不是 Join 成了笛卡尔积？
2. 异常回溯与自愈
OpenAI 的 Agent 具备"自我纠错"能力。如果验证失败，它不会直接报错给用户，而是：
- 回溯上下文，检查是否选错了表。
- 调整查询策略（例如放宽时间范围）。
- 保留记忆，继续尝试，直到得出合理结果或明确告知用户障碍。
3. 人机协作设计
- 渐进式澄清：当问题模糊时（如"看增长"），主动追问"是环比还是同比？"。
- 可中断执行：用户可以在 Agent 思考过程中介入，修正方向，Agent 会吸收反馈继续执行。
🛡️ 第四部分：保障------如何建立信任？
智能问数最大的障碍是"信任"。如果用户不敢信，就不会用。OpenAI 的工程化实践给出了答案：系统化评估优于人工抽检。
构建自动化质量门禁（Evals）
- 黄金问答对：构建业务关键问题集 + 人工验证的正确 SQL + 预期结果。
- 语义等价评估 ：不依赖字符串匹配。使用 LLM 评估生成的 SQL 与黄金 SQL 在语义上是否等价。
- 结果一致性检查：执行生成的 SQL，对比结果分布是否与预期一致。
- CI/CD 集成：每次模型更新或 Prompt 调整，必须通过回归测试，防止"修好一个 bug，引入十个新 bug"。
💡 工程启示：没有评估体系的 AI 应用就是"裸奔"。必须将 Eval 作为基础设施先行建设。
🎯 第五部分：落地建议------我们明天能做什么？
听完 OpenAI 的实践，回到我们的实际工作，我建议分三步走：
-
收敛场景，Less is More
- 不要试图一开始就支持全库查询。
- 选择 3-5 个核心业务域（如销售、用户增长），打磨高质量的 Grounding 上下文。
- 减少工具集，避免 Agent 在过多的 API 中迷失。
-
上下文即竞争力
- 不要只 dump schema。去梳理 ETL 代码，去采访分析师，把"隐性知识"显性化。
- 尝试构建简单的"代码 - 数据"映射关系，让 Agent 理解数据来源。
-
评估先行
- 在开放给用户之前，先建立内部"黄金测试集"。
- 监控 Agent 的"自我纠错率"，这是一个衡量 Agent 智能程度的关键指标。
🔚 结语
智能问数的下半场，竞争焦点将从"能否生成 SQL "转向"能否理解业务、自主推理、持续进化"。
OpenAI 的实践告诉我们：技术决定下限，上下文决定上限。
当我们不再把 Agent 当作一个 SQL 生成器，而是当作一个需要被"培养"的初级分析师，为它提供足够的业务土壤（Grounding）和反馈机制（Eval），它才能真正成为数据团队的得力副驾驶。
从"会写 SQL"到"懂业务"，这不仅是技术的升级，更是我们对数据价值交付方式的重新定义。
谢谢大家！
❓ Q&A 互动环节
- Q: 解析 ETL 代码成本高吗？如何维护？
- A: 初期成本高，但收益大。建议只解析核心链路代码，并利用 LLM 自动总结代码逻辑存入向量库，代码变更时触发增量更新。
- Q: 如何处理数据权限问题？
- A: 在 Grounding 层加入权限元数据。Agent 规划时先校验当前用户是否有表权限，无权限则自动过滤或申请。
- Q: 小团队没有资源做三层 Grounding 怎么办？
- A: 先从 Layer 2（业务标注）做起。维护一份高质量的"指标字典"，比优化模型参数更有效。
(本文基于 OpenAI 官方技术博客《Inside our in-house data agent》分析及行业最佳实践总结)