OpenAI内部数据代理探秘

# OpenAI 内部数据代理揭秘 来源：https://openai.com/index/inside-our-in-house-data-agent/ 数据驱动着系统的学习方式、产品的演变方向以及企业的决策方式。但快速、准确且带有正确上下文地获取答案，往往比预想的要困难得多。为了在 OpenAI 规模化发展的过程中解决这一问题，我们构建了**自有的定制内部 AI 数据代理**，用于在我们自己的平台上进行探索和推理**。** 我们的代理是一款纯内部工具（非对外产品），专门围绕 OpenAI 的数据、权限和工作流构建。本文将介绍我们如何构建和使用它，以呈现 AI 如何以真实、有影响力的方式支持各个团队的日常工作。我们用于构建和运行它的 OpenAI 工具（Codex (https://openai.com/index/introducing-codex/)、我们的 GPT-5 旗舰模型 (https://openai.com/index/introducing-gpt-5-2/)、Evals API（在新窗口中打开） (https://platform.openai.com/docs/guides/evals) 以及 Embeddings API（在新窗口中打开） (https://platform.openai.com/docs/guides/embeddings)）同样向所有开发者开放。 我们的数据代理让员工能够**在几分钟内（而非几天）从问题获得洞察**。这降低了跨所有职能拉取数据和进行细致分析的门槛，而不仅仅局限于数据团队。如今，OpenAI 的工程、数据科学、市场进入、财务和研究等团队都依赖该代理来回答**高影响力的数据问题**。例如，它可以帮助回答如何评估发布活动、理解业务健康状况，这一切都通过直观的自然语言形式完成。该代理结合了由 Codex 驱动的表级知识与产品和组织上下文。其持续学习的记忆系统意味着它会随着每次交互不断改进。 在这篇文章中，我们将分析为何我们需要一个定制的 AI 数据代理，其代码增强的数据上下文和自学习能力为何如此有用，以及我们一路走来学到的经验教训。 OpenAI 的数据平台服务于超过 **3.5k 内部用户**，他们来自工程、产品和研究团队，涵盖超过 **600 PB** 的数据，分布在 **70k 个数据集**中。在这样的规模下，仅仅找到正确的表就可能成为分析中最耗时的环节之一。 正如一位内部用户所说： *“我们有很多非常相似的表，我花大量时间试图弄清楚它们之间的区别以及该用哪个。有些包含已注销用户，有些没有。有些字段重叠，很难分辨是什么。”* 即使选择了正确的表，生成正确的结果也颇具挑战。分析师必须推理表数据和表关系，以确保转换和过滤条件应用正确。常见的失败模式——多对多连接、过滤条件下推错误以及未处理的空值——可能会悄无声息地使结果无效。在 OpenAI 的规模下，分析师不应该把时间浪费在调试 SQL 语义或查询性能上：他们的重点应该是定义指标、验证假设以及做出数据驱动的决策。 这个 SQL 语句有 180 多行长。很难判断我们是否连接了正确的表并查询了正确的列。 让我们来看看我们的代理是什么，它如何整理上下文，以及如何持续自我改进。 用户可以提出复杂、开放的问题，这些问题通常需要多轮手动探索。以这个使用测试数据集的示例提示为例：*“对于纽约市出租车行程，哪些上车到下车邮编配对是最不可靠的，即典型旅行时间与最差旅行时间之间的差距最大？这种变化何时发生？”* **该代理端到端地处理整个分析过程**，从理解问题到探索数据、运行查询以及综合发现。 该代理的一大超能力在于其推理问题的方式。它不是遵循固定脚本，而是评估自身的进展。如果中间结果看起来有误（例如，由于连接或过滤错误导致零行），代理会调查哪里出了问题，调整方法，然后重试。在此过程中，它保留完整的上下文，并在步骤之间传递所学到的知识。这种**闭环、自学习的过程**将迭代工作从用户转移到代理本身，从而实现更快的结果和始终比手动工作流更高质量的分析。 该代理识别最不可靠的纽约市出租车上下车配对时的推理过程。 该代理覆盖了完整的分析工作流：发现数据、运行 SQL、发布笔记本和报告。它理解内部公司知识，可以网络搜索外部信息，并通过学到的用法和记忆随时间改进。 高质量的答案依赖于**丰富、准确的上下文**。如果没有上下文，即使是强大的模型也可能产生错误结果，例如严重错误估计用户数量或误解内部术语。 没有记忆的代理，无法有效查询。 代理的记忆通过定位正确的表来加快查询速度。 为了避免这些失败模式，该代理围绕**多层次的上下文构建，这些上下文将其扎根于 OpenAI 的数据和机构知识中。** - **元数据锚定：** 代理依赖模式元数据（列名和数据类型）来指导 SQL 编写，并使用表血缘关系（例如，上游和下游表关系）来提供不同表之间如何关联的上下文。 - **查询推断：** 摄取历史查询有助于代理理解如何编写自己的查询，以及哪些表通常被连接在一起。 - **领域专家提供的表和列精选描述**，捕捉意图、语义、业务含义以及已知注意事项，这些内容不易从模式或历史查询中推断出来。 仅凭元数据是不够的。要真正区分不同的表，你需要了解它们是如何创建的以及它们的来源。 - 通过推导表的代码级定义，代理可以更深入地理解数据实际包含的内容。 - 关于表中存储了什么以及它如何从分析事件推导而来的细微差别，提供了额外信息。例如，它可以提供关于值的唯一性、表数据更新的频率、数据的范围（例如，如果表排除了某些字段，则有此粒度级别）等上下文。 - 这通过展示表在 SQL 之外如何在 Spark、Python 及其他数据系统中使用，提供了增强的使用上下文。 - 这意味着代理可以区分看起来相似但在关键方面不同的表。例如，它可以判断某个表是否只包含第一方 ChatGPT 流量。此上下文也会自动刷新，因此无需手动维护即可保持最新。 - 代理可以访问 Slack、Google Docs 和 Notion，这些渠道捕获了关键的公司上下文，例如发布活动、可靠性事件、内部代号和工具，以及关键指标的规范定义和计算逻辑。 - 这些文档被摄取、嵌入，并随元数据和权限一起存储。一个检索服务在运行时处理访问控制和缓存，使代理能够高效且安全地拉取这些信息。 -**当代理收到纠正或发现某些数据问题的细微差别时，它能够将这些学到的东西保存下来供下次使用，从而使其能够与用户一起不断改进。** - 因此，未来的答案从一个更准确的基线开始，而不是反复遇到相同的问题。 - 记忆的目标是保留和重用那些对于数据正确性至关重要但难以从其他层次推断出来的非显而易见纠正、过滤条件和约束。 - 例如，在某次案例中，代理不知道如何过滤特定的分析实验（它依赖于匹配实验门控中定义的特定字符串）。记忆在这里至关重要，以确保它能够正确过滤，而不是模糊地尝试字符串匹配。 - **当你向代理提供纠正，或者当它从你的对话中找到学习点时，它会提示你保存该记忆以供下次使用。** - 用户也可以手动创建和编辑记忆。 - 记忆的范围分为全局和个人级别，代理的工具使其易于编辑。 -**当表中没有先前的上下文，或者现有信息过时时，代理可以向数据仓库发出实时查询，直接检查并查询该表。** 这使其能够验证模式、实时理解数据并做出相应响应。 - 代理还能够根据需要与其他数据平台系统（元数据服务、Airflow、Spark）通信，以获取仓库之外更广泛的数据上下文。 我们运行一条每日离线管道，将表使用情况、人工标注和 Codex 生成的增强信息聚合到一个统一的标准化表示中。然后，使用 OpenAI 嵌入 API（在新窗口中打开） (https://platform.openai.com/docs/api-reference/embeddings) 将此增强的上下文转换为嵌入向量并存储以供检索。在查询时，代理通过**检索增强生成**（在新窗口中打开） (https://en.wikipedia.org/wiki/Retrieval-augmented-generation)（RAG）仅拉取最相关的嵌入上下文，而不是扫描原始元数据或日志。这使得表理解即使在数万个表中也能快速且可扩展，同时保持运行时延迟可预测且较低。运行时的查询会根据需要实时发送到我们的数据仓库。 这些层次共同确保代理的推理基于 OpenAI 的数据、代码和机构知识，从而显著减少错误并提高答案质量。 当问题明确时，一次性回答是有效的，但大多数问题并非如此。更多情况下，要获得正确的结果需要来回改进和一些方向修正。 该代理的设计使其行为就像一个你可以与之推理的队友。它是一个对话式、始终在线的工具，处理快速回答和迭代探索。 它在不同轮次之间携带完整的上下文，因此用户可以提出后续问题、调整意图或改变方向，而无需重述所有内容。如果代理开始走错路，用户可以中断分析并重新引导它，就像与一个会倾听而不是一意孤行的人类协作者一起工作一样。 当指示不明确或不完整时，代理会主动提出澄清问题。如果没有得到响应，它会应用合理的默认值来继续推进。例如，如果用户询问业务增长但没有指定日期范围，它可能会假设最近七天或三十天。这些先验知识使其能够保持响应性和非阻塞性，同时仍然收敛于正确的结果。 结果就是一个代理，在你**确切知道自己想要什么**（例如，“告诉我关于这个表的信息”）时工作得很好，并且**在探索时也同样强大**（例如，“我看到这里有个下跌，我们能否按客户类型和时间段进行细分？”）。 推出后，我们观察到用户经常对例行重复工作运行相同的分析。为了加速这一点，代理的工作流将重复分析打包成可重用的指令集。示例包括用于每周业务报告和表验证的工作流。通过一次编码上下文和最佳实践，工作流程简化了重复分析，并确保不同用户之间结果一致。 构建一个始终在线、不断演进的代理意味着质量既可以提高，也同样容易下降。如果没有紧密的反馈循环，回归是不可避免且不可见的。在不破坏信任的情况下扩展能力的唯一方法是通过系统性的评估。 其评估基于精选的问答对。每个问题都针对一个我们非常关心的关键指标或分析模式，并配有一个手动编写的“黄金”SQL 查询，该查询会生成预期结果。对于每次评估，我们将自然语言问题发送到其查询生成端点，执行生成的 SQL，并将输出与预期 SQL 的结果进行比较。 评估不依赖于简单的字符串匹配。生成的 SQL 可能在语法上不同，但仍然是正确的，结果集可能包含不会实质影响答案的额外列。为了考虑这一点，我们比较 SQL 和结果数据，并将这些信号输入 OpenAI 的 Evals 评分器。评分器生成最终分数以及解释，同时捕捉正确性和可接受的差异。 这些评估就像单元测试，在开发过程中持续运行，以识别回归，就像生产环境中的金丝雀；这使我们能够及早发现问题，并在代理能力扩展时充满信心地进行迭代。 我们的代理直接接入 OpenAI 现有的安全和访问控制模型。它纯粹作为一个接口层运行，继承并强制执行管理 OpenAI 数据的相同权限和防护措施。 **代理的所有访问都严格是****透传**的，这意味着用户只能查询他们已经拥有权限的表。当缺少访问权限时，它会标记这一点，或回退到用户有权使用的替代数据集。 最后，它被构建为透明。像任何系统一样，它也会犯错。它**暴露其推理过程**，在每个答案旁边总结假设和执行步骤。当查询执行时，它会直接链接到底层结果，允许用户检查原始数据并验证分析的每一步。 从头开始构建我们的代理，让我们学到了关于代理行为、它们在哪里挣扎，以及什么才能真正让它们在规模化下可靠的实用经验。 早期，我们向代理暴露了完整的工具集，但很快遇到了功能重叠的问题。虽然这种冗余对于特定的自定义案例可能有帮助，并且人类在手动调用时更容易注意到，但它会让代理感到困惑。为了减少歧义并提高可靠性，我们限制并合并了某些工具调用。 我们还发现，高度规定性的提示会降低结果质量。虽然许多问题共享一个普遍的分析框架，但细节变化足够大，以至于僵硬的指令往往将代理推向错误的路径。通过转向更高级别的指导，并依赖 GPT-5 的推理来选择适当的执行路径，代理变得更鲁棒，并产生了更好的结果。 模式和查询历史描述了一个表的形状和用法，但其真正意义在于生成它的代码。管道逻辑捕捉了假设、新鲜度保证和业务意图，这些在 SQL 或元数据中永远不会显现。通过使用 Codex 爬取代码库，我们的代理理解数据集是如何实际构建的，并能够更好地推理每个表实际包含的内容。与仅从仓库信号中获取信息相比，它能更准确地回答“这里面有什么”和“我什么时候可以用它”。 我们不断努力改进我们的代理，增强其处理模糊问题的能力，通过更强的验证提高其可靠性和准确性，并将其更深入地集成到工作流中。我们相信它应该自然地融入人们已有的工作方式，而不是像一个独立的工具那样运作。 虽然我们的工具将继续受益于代理推理、验证和自我修正方面的底层改进，但我们团队的使命保持不变：在 OpenAI 的数据生态系统中无缝地提供快速、可信的数据分析。