为什么数据团队总是在“踩同一个坑”？
问题的症结往往不在于算力不足，而在于表太多、定义太多、经验散落太多。同一个“活跃用户”指标，在不同数据表中的计算口径可能截然不同。即便选对了表，要写出一段上百行且逻辑正确的 SQL 也绝非易事，任何一个连接条件的错误都可能导致前功尽弃。
为此，OpenAI 在其内部进行了一项更为激进的尝试：构建了一个由 Codex 驱动的数据智能体，让它来接管“找表、懂表、写 SQL、校验结果”的全链路。该智能体通过一套创新的六层上下文架构，实现了数据语义的自动补齐、组织知识的无缝接入以及经验教训的持续沉淀，最终让工程师和数据使用者能够通过“提问”代替“搬砖”。
数据查询不再需要手动查表
一位 OpenAI 工程师的日常抱怨道出了数据工作者的普遍困境：“我们有大量结构相似的表，我花费了大量时间试图弄清楚它们之间的区别以及该使用哪一个。”
在 OpenAI 内部，数据平台的规模达到了惊人的 600 PB，分布在超过 7 万个数据集中。想象一下，当工程师需要分析 ChatGPT 用户增长时，面对的是数十个名称类似、都声称记录“用户活跃度”但定义各不相同的表。选错表意味着数天的努力白费，更严重的是可能导致基于错误数据做出关键决策。
即便选对了表，生成正确的结果也充满挑战。下图展示了一个长达 180 多行的复杂 SQL 语句，其中包含了多层公用表表达式（CTE）、表连接和聚合操作。
-- 6) Attach customer geography; compute monthly aggregates
order_enriched AS (
SELECT
r.*,
g.c_name,
g.c_mktssegment,
g.c_acctbal,
COALESCE(g.region_name, 'UNKNOWN') AS region_name,
COALESCE(g.nation_name, 'UNKNOWN') AS nation_name,
DATE_TRUNC('MONTH', r.o_orderdate) AS order_month
FROM order_rollup r
LEFT JOIN cust_geo g
ON g.c_custkey = r.o_custkey
),
monthly_segment AS (
SELECT
order_month,
region_name,
c_mktssegment,
COUNT(*) AS orders,
SUM(order_gross_revenue) AS gross_revenue,
SUM(order_gross_revenue_with_tax) AS gross_revenue_with_tax,
AVG(avg_ship_to_receipt_days) AS avg_ship_to_receipt_days
FROM order_enriched
GROUP BY
order_month,
region_name,
c_mktssegment
)
SELECT
order_month,
region_name,
c_mktssegment,
orders,
gross_revenue,
gross_revenue_with_tax,
avg_ship_to_receipt_days
FROM monthly_segment
如今，由 Codex 驱动、具备自主学习能力的数据智能体让这一切变得简单。工程师不再需要编写冗长的 SQL，只需用自然语言提问，就能从数据海洋中获取所需信息。
六层架构的“数据大脑”
将自然语言转换为 SQL 的工具并不少见，而 OpenAI 内部数据智能体的核心创新在于其多层上下文架构。
架构的最底层（第1层）是基础元数据，包含了表结构、列类型等基本信息，为智能体提供了数据图谱的骨架。
其上一层（第2层）是人工标注。这由领域专家精心编写的表和列描述组成，旨在捕捉那些无法从数据模式或历史查询中轻松推断的业务意图、语义和注意事项。这一层相当于为智能体提供了针对每个数据表的“岗前培训”。
第三层是Codex增强。智能体通过分析生成这些数据表的源代码（如数据管道代码），推导出代码级的表定义。这一层能提供关于值唯一性、数据更新频率、数据范围等关键信息，帮助智能体理解不同表在构建和更新逻辑上的根本差异，这是传统元数据所不具备的深度认知。
第四层是机构知识。智能体能够访问 Slack、Google Docs 和 Notion 等内部协作工具，获取关键的公司背景信息，例如产品发布时间线、重大可靠性事件、内部代号、工具说明以及核心指标的标准定义和计算逻辑。
正是凭借这些外部的文本背景信息，智能体得以避免常识性错误。例如，当用户询问“12月连接器使用量为何大幅下降”时，智能体没有简单报告数字下降，而是通过机构知识发现这主要是测量/日志记录问题，与 ChatGPT 5.1 版本发布导致的数据收集方式变更有关，而非真正的使用量崩溃。
第五层是记忆，这是让智能体拥有“终身学习”能力的关键。当它从用户那里获得纠正，或自行发现数据中的细微差别时，能够将这些经验保存下来供未来使用。记忆可以由智能体自动创建，也支持用户手动编辑和维护，既可以全局共享，也可以限定为个人使用。
最顶层（第6层）是运行时上下文。当现有上下文信息缺失或已过时时，智能体能够通过实时查询数据仓库，直接检查和查询目标表。它还能够与其他数据平台系统（如元数据服务、Airflow、Spark）通信，以获取更广泛、更实时的数据上下文。
离线检索与在线查询间的动态切换
那么，上述六层系统是如何协同工作的呢？具体可分为离线和在线两个阶段。
每天凌晨，一个离线作业会系统性地扫描成千上万张数据表的实际用法与调用轨迹，汲取数据专家们留下的批注与洞察，并调用 Codex 来解读代码深处的逻辑，衍生出表格背后更丰富的业务语义。所有这些分散的“知识碎片”最终被融合成一个统一、标准化的“知识图谱”。
随后，通过 OpenAI 的嵌入模型，这些知识被转化、压缩为一组组向量嵌入，存入高速向量数据库中。至此，一个为 AI 智能体准备的、立即可用的“数据记忆宫殿”便铸造完成。
当用户的一个问题抵达时，智能体不再需要像人类分析师那样手动在元数据的海洋中搜寻。它通过检索增强生成技术，精准定位并提取出与当前问题最相关的上下文信息（来自前五层）。这个过程快速、可扩展，且延迟极低。
对于那些需要最新数据或现有知识无法覆盖的请求，智能体会同步启动实时查询通道，直接向数据仓库发起查询，并可能与其他系统交互以获取运行时上下文。这就实现了离线知识的深度与实时数据的即时性相结合，让复杂业务问题在“闪电检索”与“精确制导”的协同下，化为秒级可得的清晰洞察。
从静态工具到动态队友的范式转变
这个智能体最令人惊叹的，或许并非其技术复杂度，而是它如何无缝融入日常工作流程，成为一个真正的“队友”。与传统的“一问一答”式工具不同，它被设计为一个“可以与之推理的队友”。它是对话式的、始终在线的，既能处理快速问答，也能支持迭代探索。
例如，当产品经理的提问不够明确时，智能体会主动提出澄清问题。如果用户没有回应，它会应用合理的默认假设来推进工作（比如，当询问业务增长但未指定日期范围时，默认分析最近30天）。这让协作过程更加流畅。
为了避免智能体在持续学习中“跑偏”，OpenAI 团队利用 Evals API 为其配备了一位严格的“监考老师”。每个重要问题都配有手动编写的、可作为“黄金标准”的参考查询和答案。智能体的每次表现都会被持续监控和评分。
这些评估不仅检查生成的 SQL 语法是否正确，还会比较查询结果数据集的准确性。当智能体表现异常时，系统会立即发出警报，确保问题在影响用户前被及时发现和修复。
在数据安全方面，该智能体遵循最小权限原则：用户只能查询他们已经有权访问的表。当访问权限缺失时，它会明确标记这一点，或尝试回退到用户有权限的替代数据集。
为了确保分析过程的透明和可验证，智能体会在每个答案旁总结其做出的假设和执行步骤，暴露其推理链条。同时，它会直接链接到底层的查询结果，允许用户随时检查原始数据，验证分析的每一个环节。
怎么搭建一个数据分析智能体？
OpenAI 的上述数据智能体并未开源，但其工程师分享了构建过程中的一些关键经验与踩过的“坑”。
最初，智能体被授予访问完整数据集的权限，但这很快导致它在功能重叠的大量表中迷失。为了提高查询的准确性和可靠性，开发者不得不对智能体可访问的数据表进行合理限制和梳理。
另一个教训来自过于刻板的系统提示词。虽然许多分析问题共享相似的模式，但细节变化很大，僵化的指令往往会适得其反。当开发者将“如何实现”的决策权更多地交给智能体本身，而非通过冗长的系统级提示词硬性规定时，智能体反而变得更加稳健，能产生更好的结果。
最关键的一点认知是：相比专家对数据表给出的事后标注，数据的真正意义存在于生成它的代码中。查询历史能更精准地描述表的实际形状和用法，捕获那些从未在 SQL 注释或元数据中浮现的业务假设。通过使用 Codex 分析代码库，智能体能从根本上理解数据集是如何被构建的，从而更好地推理每个表里实际包含什么，以及应该在何时使用它。
总结
随着企业数据环境日益复杂，类似 OpenAI 内部数据智能体的工具很可能成为未来企业数据分析的标准配置，推动整个行业向更高效、更智能的数据驱动决策范式转变。这些智能体的目标不是替代数据分析师，而是增强其能力，将分析师从繁琐的 SQL 查询编写、表结构梳理和调试中解放出来，使其能更专注于更高级别的指标定义、假设验证和战略决策。
欢迎在 云栈社区 的数据库与中间件板块，或 云栈社区 的人工智能板块，与更多开发者交流此类前沿数据智能应用的技术细节与落地实践。
参考资料：
发表于 2 小时前
|
查看: 4|
回复: 0
