深入探究OpenAI的内部数据代理

📢 转载信息

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

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

---

2026年1月29日

数据为系统的学习、产品的演进以及公司的决策提供了动力。然而，要快速、准确且带有正确上下文地获取答案，往往比预想的要困难得多。为了在OpenAI不断扩展规模的同时使这一过程更轻松，我们构建了我们自己的定制内部AI数据代理，用于探索和推理我们自己的平台上的数据。

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

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

在本文中，我们将深入探讨为什么我们需要一个定制的AI数据代理，是什么使其富含代码的数据上下文和自学习能力如此有用，以及我们在此过程中吸取了哪些经验教训。

OpenAI的数据平台为跨工程、产品和研究部门的3500多名内部用户提供服务，这些用户涉及跨越600 PB数据的7万个数据集。在如此庞大的规模下，仅仅找到正确的表就可能是分析中最耗时的部分之一。

正如一位内部用户所说：

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

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

让我们来看看我们的代理是什么，它如何策划上下文，以及它如何保持自我改进。

我们的代理由GPT‑5.2提供支持，旨在推理OpenAI的数据平台。它在员工已经工作的任何地方都可用：作为Slack代理、通过Web界面、在IDE内部、通过Codex CLI via MCP⁠(在新窗口中打开)，以及直接在OpenAI的内部ChatGPT应用通过MCP连接器⁠(在新窗口中打开)中。

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

该代理端到端地处理分析，从理解问题到探索数据、运行查询和综合发现。

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

该代理涵盖了完整的分析工作流程：发现数据、运行SQL以及发布笔记本和报告。它了解内部公司知识，可以对外部信息进行网络搜索，并通过学习到的使用情况和记忆力与时俱进。

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

为了避免这些失败模式，该代理是围绕多层上下文构建的，这些上下文将它锚定在OpenAI的数据和机构知识中。

• 元数据基础：代理依赖于模式元数据（列名和数据类型）来指导SQL编写，并使用表沿袭（例如，上游和下游表关系）来提供关于不同表如何关联的上下文。
• 查询推理：摄取历史查询有助于代理了解如何编写自己的查询以及哪些表通常会一起连接。

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

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

• 通过推导出表的代码级定义，代理可以更深入地理解数据实际包含的内容。
  • 关于表中存储的内容以及它是如何从分析事件中派生出来的细微差别提供了额外信息。例如，它可以提供关于值唯一性、表数据更新频率、数据范围（例如，如果表排除了某些字段，它具有此粒度）等的上下文。
• 这通过展示表在Spark、Python和其他数据系统中SQL以外的用途，提供了增强的使用上下文。
• 这意味着代理可以区分看起来相似但在关键方面不同的表。例如，它可以判断一个表是否只包含第一方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数据的相同权限和护栏。

代理的所有访问都是严格的“直通”模式，这意味着用户只能查询他们已经有权访问的表。当缺少访问权限时，它会发出标志或回退到用户有权使用的替代数据集。

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

从头开始构建我们的代理，浮现了关于代理如何表现、它们在哪里遇到困难以及什么才能真正使它们在大规模下可靠的实际经验教训。

一开始，我们将全套工具暴露给代理，并很快遇到了功能重叠的问题。虽然这种冗余对于特定的定制案例可能很有帮助，并且在手动调用时对人类更明显，但它会让代理感到困惑。为了减少模糊性并提高可靠性，我们限制和合并了某些工具调用。

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

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

我们正在不断努力改进我们的代理，方法是增强其处理模糊问题的能力，通过更强的验证提高其可靠性和准确性，并将其更深入地集成到工作流程中。我们认为它应该自然地融入人们的工作方式，而不是充当一个独立的工具。

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

---

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

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