Presentation: AI Agents to Make Sense of Data at OpenAI

OpenAI 中的 AI Agent 用于理解数据 - InfoQ

InfoQ 首页 演讲 AI Agent 在 OpenAI 中用于理解数据

AI、机器学习与数据工程

AI 分析时代重新思考日志（网络研讨会 7 月 9 日）

OpenAI 中的 AI Agent 用于理解数据

喜欢

新下拉阅读列表

• 阅读列表

查看演讲

• 垂直

• 水平

• 全屏

速度：

• 1x

• 1.25x

• 1.5x

• 2x

44:49

概述

OpenAI 的 Bonnie Xu 讨论了 Kepler，这是一个内部构建的 AI 数据分析代理，用于查询 600 多 PB 的数据。她解释了他们如何使用 MCP、自动代码爬取和 RAG 来克服上下文窗口的限制。Xu 还分享了他们的团队如何利用范围限定的语义记忆进行自我学习，并使用基于 AST 的 LLM 评分来构建一个强大且无回归的评估管道。

个人简介

Bonnie Xu 是一名软件工程师，也是 OpenAI 数据生产力团队的技术负责人。她在 OpenAI 从零开始构建了一个 AI 驱动的数据工具，帮助团队更智能地探索和理解数据。在加入 OpenAI 之前，她在 Stripe 工作了四年，负责数据平台，并曾在 Meta 和 Google 担任过工程职位。

关于会议

QCon AI 是一个由实践者主导的活动，专注于实现这些工作负载安全扩展所需的工程学科。它提供了直接访问同行组织在生产环境中使用的架构蓝图和失败指标。

INFOQ 事件

• 2026 年 6 月 25 日，东部时间下午 1 点 架构自主可靠性：将 AI 嵌入您的可观测性堆栈 演讲者：Justin Griffin - NeuBird AI 产品负责人

• 2026 年 7 月 9 日，东部时间中午 12 点 AI 分析时代重新思考日志 演讲者：Nicolas Jung - Datadog 日志产品经理

• 2026 年 7 月 16 日，东部时间下午 1 点 代理时代工程：如何规范、构建、测试和运营 AI 驱动的系统 演讲者：Juveria Kanodia - Harness 工程高级总监

演讲稿

Bonnie Xu：今天我将谈论 OpenAI 如何部署 AI Agent 来帮助我们的团队回答数据问题。让我先给你描绘一个场景。你的业务负责人来找你，问你一个问题，我们在意大利有多少个 ChatGPT 专业用户？你咨询了一位数据科学家，但这位数据科学家却说，“这很难。我得再想想。”他们不知道该查看哪张表，于是他们又问了另一位工程师，但那位工程师也不知道。在进行了三次代码深入分析、两次简短会议和五次 Slack 聊天后，我们终于得到了答案。简单的问题不应该这么困难和耗时，但它们确实如此。之所以困难，是因为有太多的数据。

我是 Bonnie Xu。我在 OpenAI 的数据生产力团队工作。我今天来这里是为了和你们分享我们是如何解决这个问题的。以下是我希望你们从我的演讲中获得的一些关键要点。首先，正确数据上下文的重要性。然后，我将谈谈记忆对于自我学习的重要性，以及评估对于确保模型不会退化的重要性。

数据平台概述

让我先从数据平台的概述开始，说明为什么我们需要一个AI代理，然后我会深入讲解实现细节、学到的经验以及我们接下来的步骤。在OpenAI，公司80%的员工直接使用我们的数据平台。这意味着公司80%的员工使用我们团队开发的15个工具，每天处理超过600 PB的数据，涉及总共7万个数据集。数据的增长速度还在加快。这意味着我们有越来越多的问题需要回答，但同时也有越来越多的数据需要筛选，才能得到正确的结果。当ChatGPT在2022年推出时，我们问自己，我们有多少用户？随着产品的发展，我们引入了更多的地区、不同的计划和更多的功能。

现在，我们问自己，纽约有多少每日活跃的即时结账用户？现在这个问题要难得多，但本质上，我们寻找的答案类型是一样的。其中一个原因是，随着规模扩大，表的发现变得越来越困难。Helene是OpenAI的一名数据科学家，几个月前她在Slack上问了这个问题。她很难找到合适的表来使用，因为有很多听起来相似的表，而且不清楚这些表中包含哪些数据。这是Eric，OpenAI的另一名数据科学家，正在努力理解每个表的细微差别。这是一个困难的问题，因为一些表包含加密的ID，一些表包含未加密的ID，但我们可能仍然希望将它们连接起来。一些表包含调整欺诈率的列，而另一些表则没有。一些表经过了反馈的预筛选，另一些则没有。错过一个细微差别可能导致答案出现数量级的错误，而这在做出重要商业决策时可能带来灾难性的后果。更不用说编写SQL本身就很困难。这个SQL语句有160行代码，我完全不知道它是否正确。毕竟，谁能记住所有不同的日期格式方式、编写高性能查询的方法，或者令人恼火的事实：Trino数组是1索引的。

Kepler - AI数据分析师（内部工具）

有没有更好的方法来解决这个问题？在OpenAI，我们开发了Kepler，一个AI数据分析师，它利用数据平台的完整上下文来回答这些问题。Kepler服务的核心是利用模型在你需要时生成AI驱动的结果。这可能是在Slack上。例如，这里左侧是我们可以通知的Slack代理。这可能是在你的IDE中，比如Cursor，你将其连接到我们的MCP服务器。也许你在询问我们的网络代理以获取表信息，或者你可以将Kepler连接到MCP平台以处理工作负载。让我们通过一个例子来说明。让我们看看Kepler是如何运作的。假设我想找出纽约出租车行程中哪些上下车ZIP码对是最不可靠的，即典型行程和最坏情况下的持续时间差异最大，以及这种情况发生的时间。

你现在可以看到，Kepler 首先会进行内部知识搜索。它正在获取一些初始信息，并查看目前有哪些信息。你现在看到的是这一系列推理过程的实时流。这里我们有表结构，因此 Kepler 知道如何编写查询，并且它正在运行这个查询。基本上，它正在编写各种不同的查询，以尝试获取正确的数据。在这里，分桶（bucketing）非常重要。我们正在查看百分位数以确定最差的持续时间。你可以从 SQL 看出，我们已经得到了一些结果。我们需要调整阈值，因为这些结果并不是我们想要的。运行更多的查询，进行一些排序。你可以想象，如果手动完成这些操作，会耗费大量时间。

代理只是代表你执行这些查询和结果集的步骤。再次运行另一个查询。我们需要进行调整，依此类推。这里正在进行一些排序。分析过程中有很多步骤。我们的代理会尽力做到全面。如果你阅读 SQL，你会发现有一些数据的提取。我认为比率在这里被用于持续时间。这是涉及的 CTE（公共表表达式）。现在是分析部分。我们对目前得到的结果感到满意，并且需要生成实际要展示给用户的内容。这就是你在屏幕上看到的摘要。进行了一些简单的格式化，因为我们希望确保它看起来美观。这在分析中总是很重要的。你可以看到，我们正在查看时间戳。最后，我们得到了正确的答案。

我们通过 p50 来衡量典型情况，通过 p95 和 p50 的比率来衡量可靠性。我们得到了正确的数据集和具体的数值。这是一个我们数据目录中可用的 2016 年的示例数据集。结果以纽约时间显示。这里展示了所有结果，所以是 ZIP 码，然后是这些持续时间。这是实际使用的 SQL。如你所见，它相当庞大。然后我们有一个链接到原始结果。这里是最终答案：本周早高峰时段、工作日和深夜时段的通勤是最不可靠的，对于任何乘坐纽约出租车的人来说都是如此。假设我也想做一点稍微不同的事情。假设我想绘制一个图表来表示这些结果。我想通过可视化来更好地理解。Kepler 也可以做到这一点。

你在这里可以看到它正在推理。它成功地找到了一个方法。这是它用来生成图表结果的正确查询。如果我在这里向下滚动，你实际上可以看到左侧的分析。右侧是 ZIP 码，以及不可靠性。

这是一个使用数据集的玩具示例。让我再举一个可能你们中一些人会更熟悉的例子，调试一个异常。在这个例子中，我们正在查看是什么导致了 ChatGPT 周活跃用户在三月下旬出现大幅增长的异常。我将在这里分享一些推理过程的截图。第一步是查看正确的表以检查这个异常。如果确实存在异常，我们应该看到异常前后的数值有所增加。推理过程的另一部分实际上是深入数据。我们如何知道这个表是正确的？在这里你可以看到 Kepler 正在引用一个仪表板和一个 Notion 文档来确认这一点。此外，Kepler 会与数据进行交互式探索。它通过实际运行不同的查询来实现这一点。

通过维度，你看到的就是这些内容。Kepler 正在根据计划类型和区域运行查询。这就是它能够发现峰值背后原因的方式。例如，是否是某个特定区域的增加导致了这一现象？这正是人类在进行数据分析时可能会做的事情。现在，Kepler 也尝试根据它所拥有的所有数据提出一些原因。一个例子假设是，我们记录了太多数据，存在重复问题。Kepler 正在查看公司内部的上下文，以验证这一假设是否成立。幸运的是，就我们的使用场景而言，事实并非如此。Kepler 能够确定，这与我们推出的 ImageGen 有关。现在 Kepler 提出了这个假设，它实际上会进行网络搜索，以核对时间线并进行交叉参考。

在这个思考链中，你可以看到 Kepler 引用了那个时间段的发布说明，还有一篇 TechCrunch 的文章，因为这就是它真正检查趋势的方式。最后，我们得出了结果。Kepler 能够确定，这是由于 ImageGen 的趋势造成的。它有效了。每当 Kepler 显示出答案时，我总是会感到紧张。我会想，这是否正确？幸运的是，大多数时候它是正确的。我也会谈到这一点。

让我们谈谈 Kepler 还能做的一些其他事情。不要觉得向 Kepler 提问有什么不好。Kepler 可以全天候地进行快速对话。你也可以进行后续提问。这就是你如何得到像 Dominique 正在进行的那样有 56 条回复的对话链。非常棒的一点是，所有后续提问，Kepler 都会保存整个上下文，因此你不需要重复自己。如果你看到 Kepler 偏离了主题，因为我们正在流式传输思考链，你可以看到 Kepler 正在走向哪里，你可以打断 Kepler，而 Kepler 会接受这个反馈并产生不同的结果。这里有一个视频示例，说明我所说的后续提问是什么意思。这里的情况类似。我正在询问纽约出租车场景，因为我对这个特别感兴趣。我正在询问有关接客情况的结果。我们有这张图表。

现在假设我想深入探讨一些更具体的内容。我想特别查看 2 月 14 日的接客趋势，这是一个非常随意的日子。我在这里询问 Kepler。你可以看到 Kepler 正在进行推理。你在这里看到的是我们的 Slack 代理界面。有一些查询正在运行。你可以看出这一点，或者希望你已经注意到了。Kepler 不需要再次进行所有初始的知识搜索，因为我们从之前的回答中获得了上下文，知道了使用正确的表。Kepler 能够立即运行查询并得出结果，即在这个数据集中总共有 375 次接客。此外，Kepler 还可以处理后续提问。如果我提出一个非常不完整的问题，Kepler 会自动选择最佳的默认选项，而无需我进行后续提问。

另一个对我们来说非常有用的特点是，人们经常重复执行一些常见的流程。例如，对功能产品进行分析，或者在开发表和生产表上进行数据验证。基本上，我们有这些工作流程，它们就像可以随时在 UI 中重新运行的自定义可共享指令。

刚才我向大家展示了如果在公司中使用Kepler，可能会是什么样子。现在让我来谈谈所有这些实际是如何在幕后发生的。这是一张整体的示意图，说明了事情是如何进行的。在这里左侧，我们有入口点。你们已经见过其中的一些，比如用户界面，还有Slack代理。此外，你还可以连接本地或远程的MCP。上方的部分是预处理的离线信息，稍后我会详细讲解，这部分是知识库。下方的部分用于同步调用，所以我可以直接调用我们的数据仓库或其他数据平台源，比如Spark或Airflow。这实际上是整个系统的核心。Kepler与模型进行交流，并配备了这个工具箱。

让我在这里后退一步，解释一下为什么使用MCP对我们来说如此有帮助。原因在于，有了这些工具，Kepler就可以利用它们作为起点。然后，当发现某些问题时，比如Kepler只是选择了两个表进行连接，但使用了错误的键，结果就会是空的。Kepler可以返回并重复这些步骤。我们进行内部知识搜索，检查模式，运行查询，然后再次执行。你可以从我之前的例子中看出，Kepler一直在不断运行查询并查看结果。基本上，这就是代理自身进行推理的过程。而不是你提供反馈，Kepler会运行工具，提供反馈，然后根据所获得的反馈使用合适的工具采取下一步行动。

Kepler可以与数据进行交互式探索，而且在整个过程中上下文都会被保留。我们有完整的步骤，这些步骤最终会带来更准确的答案。

没有上下文的代理可能会给出非常错误的答案。例如，某个代理错误地认为有500万ChatGPT用户，而实际上正确的数字是8亿。这只是一个细微的四舍五入问题。或者在另一个例子中，代理误以为Sora是《王国之心》游戏中的角色。也许在我的日常ChatGPT历史中，这会更准确。是的，我真的很想问一下我们刚刚发布的视频生成产品Sora。作为起点，我们需要表元数据的上下文。正如我们之前看到的，将所有7万个表及其模式和查询历史全部放入模型的上下文窗口中，数据量太大了。因此，我们必须提前进行一些预处理。表模式信息尤其重要，因为这样模型才知道如何实际查询表。这就是SQL生成部分的来源。

它需要知道列及其类型。仅凭模式本身不足以理解数据的语义和它们之间的关系。这就是为什么在这里你可以看到查询历史和血缘关系，这些是提供额外上下文的重要信息。所有这些信息基本上都会被输入到一个嵌入中，我们使用OpenAI API进行处理，然后存储起来，以便代理在实际回答问题时，可以通过特定的表搜索和语义搜索实时检索到这些信息。表元数据的另一个常见问题是描述很容易过时，而且经常成为维护的负担。这会导致代理得到糟糕的结果。手动更新它们是非常繁琐的，尤其是当你有7万个表时。我们通过尽可能自动地生成这些信息来解决这个问题。我们还包含了一些超出我们数据目录范围的信息。

这正是生成效果如此出色的原因。仅仅查看表格本身是不够的。你需要了解表格是如何创建的，以及它的来源。这是代理真正理解表格之间差异的关键，知道某个表格之所以被过滤，是因为它来自日志的一个子集。我们通过运行一个离线任务来实现这一点，该任务为表格生成 Codex 任务。这些 Codex 任务每天都会并行执行。它们会爬取代码库，以了解表格的用途、下游使用模式、精确粒度和主键、数据的新鲜度、何时使用其他表格等信息。你不再只是知道某个表格仅涉及 ChatGPT 分析，而是知道该表格包含的是第一方 ChatGPT 流量，而不是第三方流量，并且它通过安全信号进行了增强。

或者你知道某些字段可能实际上是空的，因为它们的上游信号缺失或超出了每小时窗口。这是一个关于 Spark 可观测性表格的 Codex 生成示例。如你所见，Codex 能够轻松地遍历代理文件来爬取代码库。它查看 Airflow 文件夹，查看项目。这就是我们生成某些表格的方式。获取这些信息，可能是作业信息、表格信息、阶段使用情况等。再次强调，由于所有内容都是由离线任务定期刷新的，因此上下文始终保持最新，无需任何人工干预。这个方法非常棒的一点是，你还可以获取血缘信息，这对于了解表格之间的关系非常有用。这是从我们其中一个样本数据集中提取的一个示例。

如你在这里所看到的，它比如果一个人在午夜编写时可能得到的内容更加丰富。所有这些信息都会被输入到代理和我们的用户界面中，因此人类也可以利用这些信息。

我们是如何获取公司上下文的？实际上，我们在 OpenAI 内部有一个知识服务，用于摄入诸如 Slack 线程、Notion 文档或 Google Drive 文档之类的内容。所有这些内容都会被存储到带有元数据的 blob 存储中，以便我们能够获取内容及其来源。由于这些文档通常很大，有时是完整的文档，它们会被拆分成块，并再次使用 OpenAI 的嵌入 API 进行嵌入。然后有一个检索服务，它执行类似的 RAG 搜索，进行权限检查并缓存，以便我们能够高效地提取这些信息。这就是为什么当我们提出一个问题时，我们不仅能得到“是什么”，还能得到“为什么”以及相关的上下文。

如果你看到每周活跃用户数量下降，你可能会找到一个指向事件或停机的 Slack 线程，这将为你提供更丰富的分析和对问题的理解。记忆对于纠正和学习非常有用。这里有一个例子。之前，我们只有一条 Slack 陈述，我们正在查看用户 ID，因为我们正在查看每日活跃用户。假设在这个特定的用例中，我们真正想要查看的是至少发送过一条消息的用户，并且我们希望排除外部用户，并且我们关心的是太平洋时区。在记忆之后，我们的系统将始终生成这种类型的查询，而不是之前的那个，因为我们保存了这个更正。这样，代理基本上每次都能生成正确的结果。记忆的摄入方式与表格知识类似。

我们所做的所有这些修正。用户可以手动提交修正，代理也可以这么做。我们将内容嵌入到向量空间中，然后在运行时进行检索。对我们来说，记忆是帮助代理持续学习和改进的关键机制。上下文可能能带你走到80%、90%的地方。有时你还需要那些最终的细微修正，这些修正很难仅通过推理得出。假设你推出了一项功能，你有一个特定的字符串用于你的统计和门控，这就是一个需要找到正确结果的记忆示例，但如果不这样做，很难知道这一点。这里有一个例子。我们现在有三个作用域。有用户级别的，因为用户可能想要自己的自定义设置。我们还想保护潜在的私人信息。

还有频道级别的，用于团队范围的记忆，以及全局记忆，用于对所有人有益的一般性修复。我们目前正在推出记忆建议功能，因此Kepler可以提示生成一个记忆，然后用户可以确认。然后它可以被插入到正确的范围中。我们还在研究如何创建仅传递正确记忆的评估，以确保所有这些都能正常工作。我们的计划是，如果用户生成了大量相同记忆，记忆也会被压缩。此外，有时可能会生成一些意外的记忆，或者它们可能并不那么可重用。在这种情况下，我们希望在离线作业中进行修剪。另一个让记忆更丰富、信号更强大的方法是允许对记忆进行编辑。

在当前的用户界面中，你实际上可以触发一个编辑，然后如果需要更新，可以触发重新同步。我们的用户在这里也确实实时帮助贡献。如果所有上下文都不够，我们的代理可以实时调用我们的数据仓库来获取所需信息。这只是一个简短的API调用。例如，你可能需要这个功能的一个原因是，如果有一个新的表，比如你生成了测试表，它在我们的任何服务中都还不存在，或者在离线作业中还不存在，你可以直接查询数据仓库，Kepler将获取这些信息。希望这张图片能清楚地说明上下文有多重要。

我们如何衡量响应质量？

下一个需要考虑的重要因素是，我们如何确保不会造成回归。现在让我谈谈我们如何衡量响应质量。用智慧的Greg Brockman的话来说，评估（evals）出人意料地经常是你唯一需要的东西。在我们的情况下，这句话有其道理。我们的评估由一组问答对组成。问题通常是某个我们希望正确获取的重要指标。然后我们有一个手动整理的预期SQL语句，我们希望它成为正确的答案。我们调用代理查询生成端点，将自然语言问题转换为生成SQL，然后运行查询。我们对预期查询结果也执行相同的操作。我们有生成的查询、生成的查询结果、预期的SQL、预期的SQL结果，然后我们将所有这些内容输入到OpenAI评估评分器中。

这个评估评分器实际上是在进行模型评分。这一点尤为重要，因为很多时候生成的 SQL 可能略有不同，但并不会显著改变结果。所有这些最终都会给我们一个评分和原因，这样我们就能了解我们的评估表现如何。以下是我们在评估过程中的一些关键经验。首先，我想强调的是，SQL 文本的完全相等性并不是判断 SQL 评估是否通过的一个好标准。例如，你可以用多种不同的方式编写日期筛选器，但其含义仍然相同。我们对这些内容进行了标准化处理，将所有内容转换为其 AST（抽象语法树）表示形式。这有助于我们绕过这些细微的 SQL 语法差异。此外，当我们比较结果集时，我们实际上会为那些对答案没有实质性影响的内容提供一定的灵活性。

在某些情况下，浮点数或整数的差异并不重要；在某些情况下则可能很重要。但总体而言，LLM（大型语言模型）的推理能力非常出色，因为它在处理细微差别时表现得更好。例如，在浮点数的情况下，有时为了精度确实需要考虑，但有时则不需要。另一个优点是，由于模型的推理能力较强，它能够从所看到的结果中提供更加有信息量的响应。第三点是，我们还公开了评估过程中的推理过程。这对于调试失败的情况非常有帮助。在一种情况下，我们发现评估失败是因为它更倾向于使用一个经过精心整理的表，而不是原始表。

通过深入研究推理过程，我们意识到这是因为模型认为问题更偏向于仪表板方面，因此选择了那个表。这一点在一开始并不明显。

我们是如何安全地进行这些操作的？

拥有强大的数据访问权限意味着也承担了相应的责任。Kepler 并不会提供任何额外的授权。实际上，它只是传递了认证信息。这意味着 Kepler 不会授予你访问你没有权限的表的额外权限。当你没有权限时，Kepler 会非常有帮助地告诉你应该加入哪个访问组。或者，它可能会使用一个你有权限访问的类似表。在 OpenAI，我们非常重视数据安全。用户应仅访问他们有正当理由访问的数据。当我们引入内部知识时，实际上会引入已经过预处理的查询，以防止重要 ID 等信息被意外泄露。特别是在 Slack 上，对于 Slack 代理，当受众更广泛时，我们还会对敏感输出进行脱敏处理。这是通过拦截结果并将其传递给我们的内部匿名化服务来实现的，该服务能够检测 PII（个人身份信息）。

有时候，用户确实有合理的理由查看原始结果。我们实际上允许通过链接到一个外部 UI 来实现这一点，该 UI 允许那些有权限访问这些表的用户查看数据，因为他们本来就可以自行运行这些查询。我们会在那里进行权限检查，以确保他们确实应该看到这些数据。这对于代理生成的所有结果都是适用的。就像人类一样，Kepler 也可能犯错。这就是为什么我们在 Kepler 回答问题时，会实时流式传输其推理过程，正如你之前在截图中所看到的那样。这在审计时非常有帮助，而且在许多情况下，理解答案背后的假设也非常重要。

如果 Kepler 运行了任何产生数据的查询，Kepler 会将这些查询链接起来，并提供参考 ID，以便你可以点击查看原始结果。

用户反馈（Kepler）

现在让我们看看内部用户对 Kepler 的评价。例如，有位用户提到，Kepler 是他们公司最有用的机器人。另一位用户提到，Kepler 在编写 SQL 查询方面非常出色，以至于手动编写这些查询可能是浪费时间。在底部，你可以看到 Kepler 在数据的合理性检查方面表现不错，可以确保你对数据的假设是正确的。实际上，这是我最喜欢的引用之一。有人提到，Kepler 对他们来说感觉像是他们使用过的最接近通用人工智能（AGI）的东西。我们有很多非常棒的人。

关键学习点

看到用户如此喜爱 Kepler 真是令人高兴。我们是如何走到这一步的？让我谈谈我们在过程中学到的一些关键经验。我们最初的许多成功归功于与用户的快速反馈循环。我们与一个关键团队合作，他们会给我们反馈，我们立即进行验证，如此循环往复。让我举个例子说明我的意思。最初，我们认为所有问题都是指标相关的问题，比如你生成一个 SQL 查询，得到一个结果，Kepler 代理会告诉你。实际上，很多问题可以通过公司上下文、文档或表信息来回答，比如访问组。

由于这些用户反馈，我们重新设计了后端，以适应这些情况，这样模型就不会浪费资源运行无意义的查询（如 SELECT 1）或在不相关的情况下进行表搜索。我们可以回答像 Jimmy 现在提出的这类重要问题。另一个对我们帮助很大的事情是，我们以用户当前的水平为出发点。很多代理接口实际上都是基于网页的，例如 ChatGPT。我们实际上从 Slack 接口开始，因为 OpenAI 是一个非常依赖 Slack 的公司。人们经常在 Slack 上发布分析更新，也经常在 Slack 上提出数据问题。我们意识到成功的关键实际上是让人们用他们的分析问题来“ping”Kepler。现在我要谈谈一些学到的经验教训。

事实证明，如果你给模型太多信息，尤其是在信息重叠的情况下，它会变得非常困惑。我们最初意识到这一点是因为我们有很多工具调用，它们之间有些相似，因为一个可能使用服务认证，另一个可能使用用户认证，但模型却因为无法理解这些细微差别而变得非常困惑。实际上，我们减少了代理可以使用的工具调用，以使工具发现更容易。另一个发现是，当有非常具体的指令时，结果反而更差。这是因为人们提出的问题类型实在太多了。虽然可能有一个相似的总体路径，但逻辑上有很多小分支。

过于具体的要求实际上对我们造成了伤害，因为模型会试图遵循一套对问题可能并不适用的精确指令。我们实际上改变了我们的提示方式，使其更加通用，这样 Kepler 虽然可以达到一个大致的点，但最终让 GPT-5 的推理能力来决定它应该采取的确切路径。毕竟，它确实拥有所有这些上下文信息。

未来展望？

接下来 Kepler 的发展方向之一是，我们希望对一个专门用于 Kepler 的模型进行微调。在许多小的领域，Kepler 还不能完全准确。例如，一些 SQL 的细节问题。我们掌握了很多用户提问的数据以及可以生成的正确 SQL。我们的计划是利用这些数据来训练一个模型，使 Kepler 在内部使用场景中表现得更好。我们非常重视用户对 Kepler 的信任。我们希望回答是经过验证且正确的。这对我们的成功至关重要，因为如果人们不信任 Kepler，他们又怎么会使用它呢？因此，我们计划增加额外的验证步骤，使 Kepler 能像人类一样自我检查。一个例子是，你可能在运行查询后，在某个仪表板上查看某个数字。Kepler 可以获取这个结果并进行比较，以确保数字匹配，从而提高我们对答案正确性的信心。

关键要点

如果你从这次谈话中带走任何东西，我希望这三点能给你留下深刻印象。首先，除了表元数据之外，拥有更广泛的上下文非常重要。我之前提到的代码和丰富的上下文，以及公司背景，都对模型的性能有显著帮助。其次，引入记忆非常有价值，这样你的代理可以持续改进。最后，评估特别重要，以确保模型始终保持良好的性能。

问答环节

参与者 1： 我很好奇使用 Kepler 的用户画像。他们是之前做分析的数据分析师吗？还是现在的终端用户，他们不再需要数据分析师，而是直接向 Kepler 提问？或者介于两者之间？

Bonnie Xu： 我们最初主要面向数据科学家，因为他们拥有最多的上下文，也最清楚什么是正确的答案。特别是最初的时候，模型的回答并不理想。现在 Kepler 的表现已经大幅提升，我们扩展到了更广泛的用户群体。目前，我们有来自 GTM 的用户，也有来自金融和经济领域的用户，还有 API 相关的用户。甚至一些在 ChatGPT 上开发 Sora 的人员也会向 Kepler 提问。截至目前，我们已经覆盖了整个公司。

参与者 2： 你们在管理代理的上下文窗口时有哪些策略？

Bonnie Xu： 我认为将所有内容嵌入到向量中，然后在运行时返回这些向量非常有用。正确的搜索实际上效果很好。另一个优点是，它可以只提取小片段的信息。这就是我们高效处理问题的方式。此外，我们还会在查找信息时进行一些标签处理，以便找到正确的信息，同时我们也会在一定程度上限制搜索范围。我们还在研究如何减少工具调用次数，或者更快地找到正确答案。这也是我们减少上下文窗口大小的一种方式，以确保最终的回答仍然有效。

参与者 3： 你们是否会利用用户向机器人提出的问题来驱动数据建模？这是否也属于代理行为？如果有很多用户持续询问关于某些未连接表的问题，你们是否会将这些背景信息纳入考虑？在微调过程中，你们使用了哪些信号？是否有用户在 Slack 中进行某些操作，以提供反馈，帮助判断模型的回答是否良好？

Bonnie Xu：你的第一个问题是，我们是否使用最常见的问题来进行评估？实际上，我们确实如此。目前，我们的评估问题是手动生成的，只是为了确保我们得到正确的数据集，但它们基本上是基于用户可能回答的最常见的问题，以及一些重要的问题，例如ChatGPT的周活跃用户数，或者Sora的收入等。是的，我们确实使用这些信息作为评估问题对的依据。

关于你的第二个问题，关于微调以及我们如何获取正确的输入，我们实际上有反馈机制。人们可以使用手动反馈机制来点赞或点踩。也许你在ChatGPT中见过这种功能，你可以通过点赞或点踩来提供反馈，这对我们也非常重要。此外，我们还会从Slack线程中获取反馈，例如在线程中直接进行反馈，这些也是输入的一部分，甚至只是对话内容本身。我们希望在未来扩展这一功能，但实际上，我们也可以分析所有对话内容，进行语义分析，这是另一种方法。目前我们还没有这样做，但我们希望向这个方向发展。

参与者4：我假设你们的评估是在没有记忆的情况下进行的。那么，当上下文中包含记忆时，你们如何确保记忆的加入不会导致工具性能的下降？

Bonnie Xu：记忆检查实际上非常轻量，因为它只是进行RAG搜索。是的，这确实如此。有时候，记忆可能很糟糕，确实会呈现出不应该出现的失败情况。在这种情况下，这就是为什么思维链是有用的。我们可以检查发生了什么。然后，通过记忆修剪来确保这些记忆是有意义的。基本上，我们只需在我们这边进行一点审计，以确保这种情况发生。当然，也存在糟糕的记忆。

参与者5：关于记忆的问题。你提到有不同级别的记忆，包括用户、团队和全局范围。我假设你们是在某种离线过程中生成这些记忆的。你们还允许用户对这些记忆进行编辑，以便用户可以进行一些小的修改。如果是这样的话，在这个记忆处理流程中，如果重新运行这个流程，你们如何确保用户编辑的记忆不会被覆盖？例如，现在，如果记忆是幂等的，也就是说，如果我有一个对话，并且生成一个记忆，即使我重新运行，我也应该得到相同的记忆UUID或其他类似的东西。这是我的假设。如果情况不是这样，你们是如何处理冲突的？如果重新运行相同的流程，你可能会生成不同的记忆，这样就会导致冲突。第一个问题是，你们如何避免覆盖？如果没有，你们是如何避免冲突的？

Bonnie Xu：你的问题基本上是关于冲突的记忆。我认为在这种情况下，我们实际上会做几件事。首先，我们计划引入一种方式，让用户能够看到他们的记忆。引入作用域的整个原因是你不应该污染全局内存。如果我是用户，我可能有非常具体的分析案例。而另一个用户可能说，实际上应该以完全不同的方式处理。这些更适用于个人记忆。即使在作用域内，记忆之间也可能发生冲突。让我先退一步。对于记忆，我们实际上是在运行时插入它们，然后在离线时进行修剪，因为可能会有很多记忆。正是这种离线修剪过程帮助处理了一些冲突。

显然，离线任务运行和实时运行之间仍然存在一些差距。另一个好消息是，当模型检索到错误的记忆，或者在问题上下文中没有意义时，我们有模型可以作为回退。即使在它自己的知识搜索中，这种情况有时也会发生。它能够将这些作为信号来处理，要么忽略它们，要么不给予它们太高的权重。我们在推理链中已经看到了这一点。在大多数情况下，它仍然有效。在这些边缘情况下，就像你提到的，它只是另一个信号。这就是为什么我们提供这么多信号，因为如果至少80%的信号是好的，通常就足以推动正确的方向。

参与者6：是否考虑过将其作为框架开源，或者作为企业服务？你们发现用户是否因为使用Kepler比直接使用源系统更简单，而选择使用Kepler？

Bonnie Xu：当然，第一个问题是开源。我确实喜欢开源。不幸的是，我不确定自己是否有足够的权威来做出这个决定。

至于你第二个问题，使用Kepler与直接查询源系统。至少从我们听到的用户反馈来看，直接使用Kepler要快得多。它更高效，因为当你查看不同的来源时，你必须逐一查看。所有这些不同的来源，你可能需要自己进行一些整理。例如，你正在使用Kepler DAC。你查看Databricks作为你的数据目录，然后查看Codex作为一些代码文件或其他内容。然后你可能查看Airflow作为你的Airflow任务。你必须做很多工作，然后你必须将这些点连接起来。而Kepler就是在这之上的一层，它为你完成这些抽象工作。这就是为什么它要快得多。我们实际上也看到很多人，因为Kepler可以独立运行，他们只需启动几个Kepler问题，然后回来查看结果。通过这种方式，你变得非常高效。

查看更多带有文字稿的演讲

录制时间：

2026年6月19日

由

• Bonnie Xu

#### 相关赞助商

#### 相关赞助商

• 2026年6月25日，下午1点EDT 构建自主可靠性架构：将AI嵌入你的可观测性堆栈 演讲者：Justin Griffin - NeuBird AI产品负责人

#### 本内容属于AI、机器学习与数据工程主题

##### 相关主题：

• AI、机器学习与数据工程

• QCon AI 2025

• 人工智能

• QCon软件开发会议

• 代理

• 相关编辑

• 在 InfoQ 上广受欢迎 ArrowJS 达到 1.0 版本，Recast 成为首个面向代理时代（Agentic Era）的 UI 框架 Anthropic 发布并暂时暂停 Claude Fable 5 Anthropic 解释 Claude 如何构建自己的执行框架 Spring Boot 4.1 新增 gRPC 自动配置、SSRF 防御以及 Kotlin 2.3 支持 提升用户的数据自主权：从 BlueSky 的 AT 协议到本地优先软件运动 Coinbase 事后分析揭示了本地化 AWS 故障如何引发数小时的交易中断