深入了解 OpenAI 的内部数据智能体

📢 转载信息

原文链接：https://openai.com/index/inside-our-in-house-data-agent

原文作者：Bonnie Xu, Aravind Suresh, and Emma Tang

---

数据驱动着系统的学习、产品的演进以及公司的决策制定。然而，快速、准确且带有正确上下文地获取答案，通常比预期的要困难得多。为了在 OpenAI 规模不断扩大的背景下简化这一过程，我们构建了我们自己的定制内部 AI 数据智能体，用于探索和推理我们自己的平台上的数据。

我们的智能体是一个仅供内部使用的定制工具（并非外部产品），专门围绕 OpenAI 的数据、权限和工作流程构建。我们展示了如何构建和使用它，以帮助挖掘出 AI 在我们各个团队的日常工作中支持实际影响力的用例。用于构建和运行该智能体的 OpenAI 工具（Codex、我们的 GPT‑5 旗舰模型、Evals API⁠（在新窗口中打开），以及Embeddings API⁠（在新窗口中打开））与我们向全球开发者提供的工具是相同的。

我们的数据智能体让员工能够在几分钟内而不是几天内，从问题转变为洞察。这降低了跨所有职能部门（而不仅仅是数据团队）提取数据和细微分析的门槛。今天，OpenAI 工程、数据科学、市场营销、财务和研究等团队都依靠该智能体来回答高影响力的数据问题。例如，它可以帮助回答如何评估产品发布和了解业务健康状况，所有这些都通过直观的自然语言格式实现。该智能体将 Codex 驱动的表级知识与产品和组织上下文相结合。其持续学习的记忆系统意味着它会随着每一次交互而不断改进。

在本文中，我们将深入探讨为什么我们需要一个定制的 AI 数据智能体，是什么让其代码丰富的上下文和自我学习如此有用，以及我们在此过程中学到的经验教训。

OpenAI 的数据平台为超过 3.5k 名内部用户提供服务，这些用户分布在工程、产品和研究部门，横跨 70k 个数据集中的超过 600 PB 的数据。在如此庞大的规模下，仅仅找到正确的表就可能成为分析中最耗时的部分之一。

正如一位内部用户所说：

“我们有很多相似的表，我花费大量时间试图弄清楚它们之间的区别以及该使用哪一个。有些包含未登录用户，有些则不包含。有些字段有重叠；很难分辨哪个是什么。”

即使选择了正确的表，产生正确的结果仍然具有挑战性。分析师必须对表数据和表关系进行推理，以确保转换和筛选条件得到正确应用。常见的失败模式——多对多连接、筛选下推错误和未处理的空值——可能会在不知不觉中使结果失效。在 OpenAI 的规模下，分析师不应将时间浪费在调试 SQL 语义或查询性能上：他们的重点应该是定义指标、验证假设和做出数据驱动的决策。

让我们一起看看我们的智能体是什么，它是如何策划上下文的，以及它如何保持自我改进。

我们的智能体由GPT‑5.2驱动，旨在推理 OpenAI 的数据平台。它在员工常驻的工作环境中随处可用：作为一个 Slack 智能体、通过 Web 界面、在 IDE 内部、通过 Codex CLI via MCP⁠（在新窗口中打开），以及直接在OpenAI 的内部 ChatGPT 应用中通过 MCP 连接器⁠（在新窗口中打开）。

用户可以提出复杂的、开放式的问题，这些问题通常需要多轮手动探索。以这个使用测试数据集的示例提示为例：“对于纽约市的出租车行程，哪些上车点到下车点的 ZIP 组合最不可靠，其典型行程时间和最坏情况行程时间差距最大，并且这种变化发生在什么时候？”

该智能体可以端到端地处理分析，从理解问题到探索数据、运行查询和综合发现结果。

该智能体的超能力之一是它如何对问题进行推理。它不是遵循固定的脚本，而是评估自己的进度。如果中间结果看起来不正确（例如，由于不正确的连接或筛选导致行数为零），智能体会调查哪里出了问题，调整其方法，然后重试。在此过程中，它会保留完整的上下文，并在步骤之间继承学习成果。这种闭环、自我学习的过程将迭代从用户转移到智能体本身，从而实现比手动工作流程更快的结果和持续更高质量的分析。

该智能体涵盖了完整的分析工作流程：发现数据、运行 SQL 以及发布 Notebook 和报告。它理解内部公司知识，可以搜索外部信息，并通过学习到的使用情况和记忆不断进步。

高质量的答案取决于丰富、准确的上下文。没有上下文，即使是强大的模型也可能产生错误的结果，例如严重低估用户数或误解内部术语。

为了避免这些失败模式，该智能体构建在多层上下文之上，这些上下文将其植根于 OpenAI 的数据和机构知识中。

• 元数据基础： 智能体依赖于架构元数据（列名和数据类型）来告知 SQL 编写，并使用表沿袭（例如，上游和下游表关系）来提供关于不同表之间如何关联的上下文。
• 查询推理： 摄取历史查询有助于智能体理解如何编写自己的查询以及哪些表通常被连接在一起。

• 领域专家提供的表和列的精选描述，捕捉了意图、语义、业务含义以及无法仅从模式或过去查询中推断出的已知注意事项。

仅有元数据是不够的。要真正区分表，你需要了解它们的创建方式和来源。

• 通过推导出表的代码级定义，智能体对数据实际包含的内容建立了更深入的理解。
  • 关于表中存储的内容以及数据如何从分析事件派生的细微差别提供了额外信息。例如，它可以提供关于值唯一性、表数据更新频率、数据范围（例如，如果表排除某些字段，它具有此粒度）等的上下文。
• 这通过展示表在 SQL 之外如何在 Spark、Python 和其他数据系统中被使用，提供了增强的使用上下文。
• 这意味着智能体可以区分看起来相似但存在关键差异的表。例如，它可以判断某个表是否只包含第一方 ChatGPT 流量。此上下文也会自动刷新，因此它无需人工维护即可保持最新。

• 智能体可以访问 Slack、Google Docs 和 Notion，这些平台捕获了关键的公司背景信息，例如产品发布、可靠性事件、内部代号和工具，以及关键指标的规范定义和计算逻辑。
• 这些文档被摄取、嵌入并与元数据和权限一起存储。检索服务在运行时处理访问控制和缓存，使智能体能够高效且安全地提取此信息。

• 当智能体获得更正或发现有关某些数据问题的细微差别时，它能够保存这些学习成果供下次使用，从而允许它与用户一起不断改进。
  • 因此，未来的答案从更准确的基线开始，而不是重复遇到相同的问题。
  • 记忆的目标是保留和重用那些对数据正确性至关重要但仅从其他层难以推断出的非明显更正、筛选条件和约束。
  • 例如，在某案例中，智能体不知道如何筛选特定的分析实验（它依赖于与实验门控中定义的特定字符串匹配）。记忆在这里至关重要，以确保它能够正确筛选，而不是模糊地尝试字符串匹配。
• 当你向智能体提供更正或它从你的对话中发现学习内容时，它会提示你将该记忆保存以备下次使用。
  • 用户也可以手动创建和编辑记忆。
  • 记忆在全局和个人级别上都是有范围的，智能体的工具使得编辑它们变得容易。

• 当不存在表的先验上下文或现有信息已过时，智能体可以通过向数据仓库发出实时查询来直接检查和查询该表。这使它能够验证模式、实时了解数据并据此作出响应。
• 智能体还可以根据需要与其他数据平台系统（元数据服务、Airflow、Spark）交互，以获取存在于数据仓库之外的更广泛的数据上下文。

我们运行一个每日离线管道，将表使用情况、人工注释和 Codex 派生的增强内容聚合为单一的、标准化的表示。然后，使用OpenAI embeddings API⁠（在新窗口中打开）将此增强的上下文转换为嵌入（embeddings）并存储以供检索。在查询时，智能体通过检索增强生成⁠（在新窗口中打开） (RAG) 仅拉取最相关的嵌入上下文，而不是扫描原始元数据或日志。这使得即使在数万个表上进行表理解也变得快速且可扩展，同时保持运行时延迟的可预测性和低延迟。运行时查询会根据需要实时发送到我们的数据仓库。

这些层共同确保了智能体的推理建立在 OpenAI 的数据、代码和机构知识之上，从而极大地减少了错误并提高了答案质量。

当问题清晰时，一次性答案有效，但大多数问题并非如此。更多时候，得出正确的结果需要来回的完善和一些方向的修正。

该智能体被构建为表现得像一个可以与之推理的队友。它具有对话性、全天候可用，可以处理快速回答和迭代探索。

它在各轮对话中都保留了完整的上下文，因此用户可以提出后续问题、调整他们的意图或改变方向，而无需重申所有内容。如果智能体开始走向错误的路径，用户可以从中途干预并重新引导它，就像与一个会倾听而不是一意孤行的人类协作者一起工作一样。

当指令不清晰或不完整时，智能体会主动提出澄清性问题。如果没有提供响应，它会应用合理的默认值以取得进展。例如，如果用户询问业务增长但未指定时间范围，它可能会假定为过去七天或三十天。这些先验知识使其能够保持响应性和不阻塞，同时仍然朝着正确的最终结果收敛。

结果是，该智能体在您确切知道自己想要什么时（例如，“告诉我关于这个表的信息”）以及在您探索时（例如，“我在这里看到一个下降，我们能按客户类型和时间范围细分一下吗？”）都能很好地工作。

在部署后，我们观察到用户经常对重复性的常规工作运行相同的分析。为了加快这一过程，智能体的工作流程将重复性分析打包成可重用的指令集。示例包括每周业务报告和表验证的工作流程。通过一次性编码上下文和最佳实践，工作流程简化了重复分析，并确保了用户之间结果的一致性。

构建一个全天候、不断发展的智能体意味着质量可能像提高一样容易漂移。如果没有紧密的反馈循环，回归是不可避免且隐形的。在不破坏信任的情况下扩展能力唯一的方法是通过系统化的评估。

在本节中，我们将讨论如何利用OpenAI 的 Evals API⁠（在新窗口中打开）来衡量和保护智能体的响应质量。

其 Evals 构建在经过策划的问题-答案对集合之上。每个问题都针对一个重要的指标或我们非常关心要正确的分析模式，并配有一个手动编写的“黄金”SQL 查询，该查询能产生预期的结果。对于每次评估，我们将自然语言问题发送到其查询生成端点，执行生成的 SQL，并将输出与预期 SQL 的结果进行比较。

评估不依赖于天真的字符串匹配。生成的 SQL 在语法上可能不同，但仍然是正确的，并且结果集可能包含不影响答案的额外列。为了解决这个问题，我们比较 SQL 和生成的数据，并将这些信号输入到 OpenAI 的 Evals 评分器中。评分器会产生一个最终分数以及一个解释，同时捕获正确性和可接受的变化。

这些评估就像在开发过程中持续运行的单元测试，用作生产环境中的预警指标，以识别回归；这使我们能够在捕获问题的早期阶段自信地迭代，同时扩展智能体的能力。

我们的智能体直接插入 OpenAI 现有的安全和访问控制模型。它纯粹作为一个接口层运行，继承并执行控制 OpenAI 数据的相同权限和保护措施。

智能体的所有访问都是严格的直通式（pass-through），这意味着用户只能查询他们已经有权访问的表。当缺少访问权限时，它会标记此问题或回退到用户有权使用的替代数据集。

最后，它是为透明度而构建的。像任何系统一样，它也可能会犯错。它通过在每个答案旁边总结假设和执行步骤来暴露其推理过程。当执行查询时，它会直接链接到底层结果，允许用户检查原始数据并验证分析的每一步。

从头开始构建我们的智能体，浮现出关于智能体行为、它们遇到的困难以及什么能真正使它们在规模上可靠的实际经验教训。

早期，我们将全套工具暴露给智能体，并很快遇到了功能重叠的问题。虽然这种冗余对于特定的自定义案例可能有所帮助，并且在手动调用时对人类来说更明显，但这对智能体来说是令人困惑的。为了减少歧义并提高可靠性，我们限制和整合了某些工具调用。

我们还发现，高度规范化的提示（prompting）会降低结果质量。虽然许多问题具有相似的分析形状，但细节差异很大，以至于僵化的指令通常会将智能体推向错误的路径。通过转向更高级别的指导，并依靠 GPT‑5 的推理能力来选择适当的执行路径，智能体变得更加健壮并产生了更好的结果。

模式和查询历史描述了表的形状和用法，但其真正的意义存在于生成它的代码中。管道逻辑捕获了永远不会在 SQL 或元数据中浮现的假设、新鲜度保证和业务意图。通过使用 Codex 爬取代码库，我们的智能体理解数据集的实际构建方式，并能更好地推理出每个表实际包含的内容。它能比仅依靠数据仓库信号更准确地回答“里面有什么”和“我何时能使用它”。

我们不断努力改进我们的智能体，方法是提高其处理模糊问题的能力，通过更强大的验证来提高其可靠性和准确性，并将其更深入地集成到工作流程中。我们相信它应该自然地融入人们已有的工作方式中，而不是像一个单独的工具那样运作。

虽然我们的工具将继续受益于智能体推理、验证和自我修正方面的底层改进，但我们团队的使命保持不变：在 OpenAI 的数据生态系统中无缝地提供快速、可信赖的数据分析。

---

🚀 想要体验更好更全面的AI调用？

欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。