专访 Braintrust CEO Ankur Goyal：为什么 AI 评测是产品 prototype 走向生产的唯一桥梁？

今天看了 Founder Mode 频道跟 Braintrust CEO Ankur Goyal 的播客视频 《From AI Prototype to Production》，讨论了 AI prototype 投入生产的挑战，以及讨论了 AI 评测在这个过程中的重要性。

保留原视频观点，全是干货，文长，但值得深思。

可以带着这个问题阅读：“如果我使用你的应用并抱怨，你需要多少努力才能将这个抱怨转化为一个 eval？”

Ankur 的数据库思维

在 Ankur Goyal 看来，无论他涉足什么领域——搜索、数据库、AI 还是 AI 可靠性——有一条贯穿始终的主线：“一切都是数据库问题”。

这个理念的核心在于：如果你能帮助某人创建一个真正优秀的系统，让他们能够捕获数据、处理数据并持续迭代，那么他们就能构建出真正优秀的产品。在他早期为 MemSQL（现 SingleStore）工作时，这个理念已经成型——帮助金融公司将交易决策时间从 30 小时缩短到 30 秒，帮助工业公司通过传感器数据预测设备故障。到了 AI 时代，这个逻辑依然成立：越快速、越有效地使用数据来提升产品质量，就能构建出越好的产品。

第一次遭遇：Impira 的文档提取困境

Braintrust 的故事始于一个反复出现的问题。在 Impira，他们构建基于 AI 的文档提取系统——在 ChatGPT 出现之前，这是一个极其困难的技术问题，他们需要处理多种文档类型。

BERT 发布后，团队意识到可以训练一个统一的 Transformer 模型来处理所有文档类型，而不需要为每种类型训练单独的模型。但他们很快发现了一个致命问题：每次改进一种文档类型的性能，就会破坏另一种文档类型的表现。比如改进了发票处理，银行对账单就会出问题。这让金融客户非常不满。

被逼无奈之下，团队开始认真对待评估（evals）。这个转变带来了戏剧性的效果：他们从为一个模型决策争论 3-4 个月，转变为能够快速发布。Ankur 亲眼见证了 evals 如何彻底改变了他们构建产品的方式。

但随之而来的是新的挑战：获取用于评估的数据变得非常困难。团队开始探索一个在当时看起来很奇怪的问题：如何将可观测性堆栈（observability stack）中的数据连接起来，转化为可以离线使用的评估数据？这需要编写大量脚本和构建工具，但当时 Ankur 并没有想太多。

第二次遭遇：Figma 的相同困境

Figma 收购了 Impira，Ankur 开始领导 Figma 的 AI 团队——正值 ChatGPT 刚刚发布的时刻。团队放下手中所有工作，开始思考如何用 LLM 改进 Figma 的产品。

不过在改进的过程中，他们遇到了完全相同的问题：团队不断构建新功能，然后另一个团队开始使用它并把它搞坏。最终，他们基本上又构建了一遍相同的工具。

经历两次后，Ankur 对这个问题感到彻底厌倦。

从个人困境到行业痛点

转折点来自一个敏锐的观察，有人对 Ankur 说："你在两家公司都构建了相同的工具，但现在不只是你一个人在角落里做 AI 了。像 Instacart 这样的公司也在构建 AI 产品，也许其他人也有这个问题。所以他还是开始与一些公司交流，包括 Instacart、Notion、Zapier、Airtable、Stripe——这些后来成为 Braintrust 早期客户的公司。他们的反馈都是：“是的，我们正在摸索这个问题。”

这就是 Braintrust 诞生的时刻。

团队最容易低估的问题：从"我妈妈很喜欢"到打地鼠游戏

当 AI 产品从 prototype 走向 production 时，大多数团队会遭遇一个意想不到的困境。Ankur 用一个生动的例子来说明：

假设你在为 Instacart 构建一个帮助用户规划每周购物车的 AI 工具。用户发现了一个问题并向你反馈。你意识到：“哦，用户是对的，我需要修改提示词或更换模型。” 你进行了调整，改进了这个用户的场景，然后发布了新版本。

第二天，另一个用户抱怨说：“嘿，昨天我还能创建购物车，但现在它不会添加香蕉了。” 你会想：“天哪，我做了什么？”

这就是 “打地鼠游戏”的本质：在 prototype 阶段，你会对少数几个示例保持极度专注。这是快速迭代的好方法。但当你真正发布产品并拥有大量用户时，你突然需要考虑随时间积累的集体智慧。改进了一个用户的场景，另一个用户的功能可能就坏了。

这就是为什么 Braintrust 早期有个规则：如果一个团队的产品发布还不到 3 个月，就不值得和他们谈。那些团队会说：“我们不需要 evals，我们的产品很棒，我妈妈在用，她很喜欢。” 但三个月后，他们会带着点宿醉的样子回来：“嘿，你们还在吗？”

提升速度而不失去信任：两个必须做好的事情

面对这个困境，Ankur 提出了两个关键要素，它们构成了从 prototype 到 production 的桥梁：

第一要素：建立良好的迭代环境 — Playground 的诞生

Ankur 强调的第一点是：你需要一个真正良好的迭代环境。它的设计理念非常简单：让你能够用一堆数据点并排测试多个模型、提示词。

重要的是，你不需要从计算复杂的数字和分数开始。仅仅是在一批示例上运行你的提示词，然后用眼睛查看输出，就已经是一个很好的开始了。

为什么需要 Playground？因为当你在 terminal 前，你一次只能处理一个示例。这是prototype阶段的典型工作方式——专注、快速，但视野有限。而当你的数据从 10 个示例突然变成 10,000 个时，你就需要工具来帮助你筛选这一切。这时，那些数字和分数才变得真正有用。

Playground 本质上是对开发者工作流的升维：从一次处理一个示例，到一次处理一批示例；从只看当前输出，到对比多个方案；从单纯的快速迭代，到在迭代中保持对全局的把控。

第二要素：连接生产与测试

Ankur 强调的第二点是：在生产环境发生的事情和你能够测试的内容之间，必须有非常强的连接。

这就是为什么 Braintrust 从一开始就建立了从日志记录（logging）和追踪（tracing）一直到评估（evals）的端到端体验。

解决一个根本性问题：如何让生产中发生的真实问题，能够无缝地成为你测试和改进的基础。

这个反馈循环极其重要——它确保了你不是在真空中改进模型，而是在持续应对真实用户遇到的真实问题。

LLM 更像数据库

当谈到模型选择时，Ankur 提出了一个类比：LLM 更像数据库，而不是 CPU。

如果 LLM 像 CPU，那么同样的指令输入应该得到完全相同的结果，不同的只是性能表现。但现实是：同样的英文字符串发送给不同的 LLM，可能会产生截然不同的结果。

这更像数据库的世界。所有数据库都"说" SQL，但它们各自说着略有不同的 SQL 方言。某些数据库在特定用例上表现出色，而在其他用例上则平平无奇。

这个类比带来的启示是：你需要像选择数据库一样选择 LLM— 做基准测试，做尽职调查，然后为特定用例选择最适合的模型，并在一段时间内专注于让这个模型表现得更好。

最佳实践：每 1-2 个月的重新评估节奏

如果在 10 年前构建 SaaS 产品，你可能每 3 年才重新评估一次关系型数据库的选择，如果你很激进，可能是每年一次。但在 AI 领域，一切都被压缩了。模型的进化速度太快，以至于每个月都可能出现新的可能性。

重新评估的过程很简单：

1. 准备好你的评测集— 基于你要解决的具体场景构建 2. 定期重新运行基准测试— 每 1-2 个月执行一次 3. 发现新的产品体验机会— “哦，现在 GPT-5 Nano 突然变得很快，所以我可以解锁之前认为做不到的用户体验了”

这种定期重新评估不仅是技术优化，也充当产品创新的触发器。也许两个月前你想要一个快速响应的体验，但模型不支持。现在重新测试发现新模型准确率提升了，速度也快了，你就可以重新设计产品体验。

两个极端，都会失败

Ankur 观察到两种极端情况，它们都不可取：

极端一：从不重新评估模型

这类团队选定一个模型后就再也不看其他选项。结果往往是逐渐失去产品市场契合度。当竞争对手利用更好的模型提供更优体验时，你还在用过时的技术栈。

极端二：一直在比较模型，从不发布

这类团队把所有时间都花在并排比较模型上，陷入"选择困难症"，结果什么都没发布出去。

rm -rf，不要害怕删除东西。

这个答案看似玩笑，它暴露了一个核心问题：大多数团队面对评估数据时的第一反应是"积累"，而不是"筛选"。他们担心删掉重要的数据，结果就是数据越来越多，却越来越不知道该看什么。

Evals 不是 Benchmarks，而是 Time-Savers

Ankur 对 evals 的核心框架是：不要把它们当作基准测试，而要把它们当作省时工具。

这是一个视角的根本转变。这意味着：

作为人类，当我们做评估时，我们的工作是影响 LLM 的行为，使其更好地匹配用户的期望。

假设你每天有 15 分钟来做这件事：

• 场景一：你有 1 个用户，每天使用产品 5 次，产生 5 个数据点。你的评估可能就是花 15 分钟看这个用户做了什么，回忆他昨天做了什么，然后调整一些东西，希望明天的 5 次使用体验更好。 • 场景二：你有 500 个用户，每人每天使用产品 100 次，产生 50,000 个数据点。你根本不可能看完所有 50,000 次交互。Evals 作为优先级排序功能

这时候，正确的思考方式是：“我有这 50,000 个示例，哪 5-10 个真正值得我花时间深入研究？”

如果你把 evals 看作一个优先级排序功能，那么答案就变得显而易见了：

• 如果你有太多 evals，这意味着你生成了太多看起来像是优先级的东西

• 解决方案：更激进地设置优先级，或者删除一些

这不是数据多少的问题，而是优先级设置的问题。

最大的错误：只看 Bar Chart，不看数据

Ankur 指出了一个致命的陷阱：人们开始收集 50,000 个 evals，然后生成一个条形图，而不是真正查看数据。他们会说：“好吧，我现在没时间看示例了，所以我就看条形图吧。”

这是错误的做法。

这就像任何数据使用的反面教材一样 —— 当你只看聚合指标而不看具体数据时，你就失去了对真实情况的感知。Bar chart 会告诉你"准确率从 85% 提升到 87%"，但它不会告诉你：

• 为什么提升了？

• 是哪类问题得到了改善？

• 是否有新的问题类型出现了？

• 用户实际体验到的质量变化是什么？

从 1 个用户到 500 个用户的演变

Ankur 的框架本质上是在说：你的时间是恒定的（比如每天 15 分钟），但数据量会爆炸性增长。Evals 的作用是帮你从海量数据中找到最值得关注的部分。

五、LLM 的第一性原理 — “All Agents Converge on While Loops with Tools”

剥离所有抽象后的最简架构

Ankur 发布过一个引发广泛讨论的观点：“所有 Agent 都会收敛到带工具的 while 循环”。

这个观点背后的逻辑是什么？Ankur 解释说：这本质上就是 LLM 所做的事情。

想象一下，如果你剥离所有软件抽象，设想一个最简单的架构——如果它能工作，就会极其简单；如果它不工作，那只是因为 LLM 还不够聪明——那就是一个带工具的 while 循环。

这个架构之所以重要，是因为：

• LLM 正在快速改进

• 改进 LLM 的人也在采用这种思维方式

• 看看 Claude 的构建方式，看看 OpenAI Agents SDK，看看 ChatGPT 实际运行时的工作方式—— 都是同样的"while 循环 + 工具"的理念

这是唯一一种真正能够承受模型迭代的架构。

从第一性原理出发，允许复杂但不执着于复杂

当然，现实总是更复杂一些。有时你需要考虑状态管理，有时你需要让一个 LLM 将任务委托给另一个更简单的 LLM。

但 Ankur 强调的关键点是：带着目的、从第一性原理出发去构建复杂设计，这才合理。

什么叫"从第一性原理出发"？举个例子：

• 你先尝试了"while 循环 + 工具"

• 你发现因为成本原因卡住了，需要将某个任务委托给更便宜的 LLM

• 因为你实际经历了这个问题，所以你知道为什么需要更复杂的设计

这种方式的好处是：如果模型变得更好或更便宜，你不会有自我或执着，可以直接回退到更简单的设计。

假设之前让你采用复杂架构的原因是"模型太贵了，不能用 while 循环"，现在这个假设消失了——那就果断回退到简单架构。没有 ego，没有包袱，只有对问题本质的清晰认知。

LLM 与确定性方案的切换

主持人提到了一个有趣的现象：他们几周前一起吃饭时，聊到正在解决的一个问题，团队选择了回归更确定性的解决方案。Ankur 当时说：“我觉得你们会在这个决策上来回翻转好多次。”

这引发了一个深刻的问题：在 LLM 快速进化的时代，如何在"LLM 驱动"和"规则驱动"之间做决策？

团队经常会遇到这样的时刻：“哦，这次 LLM 还不够聪明，我需要引导它或者做一个更基于规则的代码。” 然后过段时间又发现：“哦，现在它们变聪明了。”

建议一：捕获失败案例作为 Eval

面对这个问题，Ankur 给出的第一个建议是：你应该捕获那些不工作的案例作为 eval。

为什么这很重要？因为任何时候新模型出来，你都希望能够尽可能高效地重新评估你的假设。

举个例子：假设你在构建医疗领域的应用，你发现如果患者笔记超过 3 页，模型就会完全卡住。你该怎么做？

捕获几个模型卡住的示例，这样当 GPT-6 明天发布时，你可以点击一个按钮，就能发现它是否还会卡住。收集失败案例，为未来的大模型更加智能做好准备。你的评测集中应该包含那些"当前做不到，但希望未来能做到"的案例。

建议二：重塑用户体验以适应模型能力

实际解决问题时，有两个方法：

方法一：Hack，而且 hacking 是有效的。

有时候你就是需要临时的解决方案，没什么不好意思的。

方法二（更强大）：围绕模型今天能做的事情重塑用户体验，同时着眼于随着模型改进而启用更多功能。

Ankur 用 Cursor 作为例子。你可能会想：“天哪，Cursor 太幸运了，因为模型在编码方面真的很好。”

但真相是：直到 Cursor 真正流行起来，没有人知道模型在编码方面有多好。

Cursor 团队非常聪明。他们疯狂地迭代，然后发现：“哦，这些东西实际上工作得很好。让我们打造一个突出这些能力的用户体验。”

这种心态极其强大：不是等待模型变得完美，而是发现它现在擅长什么，然后围绕这个构建产品。同时，始终保持对未来能力的想象。

第一性原理的精髓：简单 → 复杂 → 简单

Ankur 的第一性原理思维可以总结为一个循环：

1. 从最简单的架构开始（while 循环 + 工具）

2. 只有在遇到实际问题时才增加复杂度（从经验出发，不是从想象出发）

3. 当假设改变时，毫不犹豫地回退到简单架构（没有 ego，只有实效）

这个循环的关键是：你始终知道为什么需要复杂度，所以你也始终知道什么时候不再需要它。

六、可观测性的范式转变与 Evals 的未来 — 从 Uptime 到 Quality，从 Manual 到 Vibe

AI 时代的可观测性：不是 Uptime，而是 Quality

当被问到 AI 应用的可观测性时，Ankur 首先指出：Observability 是一个被过度使用的术语。更重要的是思考：你投资可观测性是为了驱动什么业务结果？

这个问题很关键，因为可观测性很昂贵。你需要明确：我到底想解决什么问题？

在传统软件世界，优秀的可观测性产品是 Datadog，它解决的问题是正常运行时间（uptime）和性能（performance）。当 Braintrust 的 UI 变慢时，他们依赖 Datadog 来定位问题。Uptime 对他们很重要，所以他们投资可观测性，付给 Datadog 一大笔钱。

但在 AI 中，可观测性的目的根本不同：它是质量（quality）。

对可观测性的投资就是对应用程序质量本身的投资。这是一个根本性的转变：

• 传统软件：可观测性 → 确保系统运行

• AI 应用：可观测性 → 提升应用质量

反向推导出核心问题

如果我们从这个目的反向推导：可观测性如何对质量做出贡献？

最重要的是：它让你在用户体验和开发人员/产品经理定期查看的内容之间建立反馈循环。

这就引出了视频中我最喜欢的一个问题：

“如果我使用你的应用并抱怨，你需要多少努力才能将这个抱怨转化为一个 eval？”

• 最好的团队：一两次点击，甚至更少 • NGMI（注定失败）的团队：他们甚至没想过这个问题的答案

这就是真正的目标：能否做到从某人抱怨到某个案例进入你的 evals，只需要两次点击？

这个"两次点击"的标准，本质上是在衡量你的反馈循环有多紧密。如果需要三天、五个人、十个步骤，那你的迭代速度就会慢到无法跟上用户的期望变化。

过去两年的奇怪现象：构建 AI 产品的工具里没有 AI

Ankur 分享了一个有趣的观察：过去几年构建 Braintrust 时，他们与世界上构建最酷 AI 产品的团队合作，但他们自己的产品几乎没有 AI。

这听起来很奇怪，但原因很简单：直到最近，模型都不擅长评估其他模型的工作。

Ankur 用了一个生动的比喻：这就像狗照镜子。如果你给一个 LLM 看另一个 LLM 的工作，它会感到困惑，很难理解什么是它自己，什么是其他 LLM。

但现在情况变了。

模型有了"身份认同"：从狗照镜子到自我认知

最新一代的模型——Claude 4、GPT-5，还有 Gemini 2.5——它们有了足够的"身份认同"（identity），能够分解这个问题。加上推理能力的进步，它们现在能够真正有意义地改进另一个 LLM 的工作。

这个突破带来了什么？Braintrust 开始在产品中释放这种能力。他们刚刚发布了一个叫 Loop的 agent，它内置在 Braintrust 中。

Loop 擅长的事情包括：

• 自动改进 prompts • 查看数据集并找出应该添加什么来使其更好 • 查看日志并找出应该提取什么来改进测试

这些都是之前需要人工完成的工作。

从 Manual Evals 到 Auto Evals

让我们回到 evals 的本质：作为人类，我们帮助引导 LLM 做一些符合用户期望的事情。

直到现在，这个过程的实现都是手动的：

• 你盯着仪表板

• 你点来点去

• 你输入 65 个字符，比如"我会失业如果你不…"，看看能不能改变模型的行为

Ankur 认为，这部分在明年会发生巨大变化：

从日志到 evals 的反馈循环实现将变得非常 LLM 驱动。但我们仍然会引导其中的品味和判断。

可观测性与 Evals 的未来：人机协作的新范式

这一切指向一个新的范式：

传统方式：

• 可观测性 = 监控仪表板 + 人工分析

• Evals = 人工编写测试用例 + 人工查看结果

未来方式：

• 可观测性 = 自动质量洞察 + 一键转化为 evals

• Evals = LLM 驱动的自动评估 + 人类提供品味判断

关键的转变不是"AI 取代人类"，而是"AI 处理规模，人类提供智慧"。

当你有 50,000 个数据点时：

• LLM 帮你找出最值得关注的 10 个

• LLM 帮你自动生成初步的 eval 案例

• LLM 帮你识别模式和异常

• 但你仍然决定什么重要、什么不重要、产品应该往哪个方向发展

这就是 auto evals 的精髓：你不需要成为数据分析专家或评估工程师，你只需要对产品质量有清晰的判断和品味。

从两次点击到零次点击？

现在最好的团队能做到"两次点击从抱怨到 eval"。但随着 Loop 这样的 agent 的出现，未来可能是：

用户抱怨 → AI 自动捕获并提议加入 evals → 你一键批准或调整

1. 第一性原理：一切都是数据库问题 — 捕获、处理、迭代数据是构建优秀产品的核心 2. 核心困境：从专注少数示例到管理集体智慧的跨越 3. 两个关键要素：良好的迭代环境（Playground）+ 生产与测试的紧密连接 4. 模型选择：准备评测集，每 1-2 个月重新评估 5. 评估疲劳：把 evals 当作优先级排序工具，不是数据收集工具 6. 架构哲学：从最简单开始，只在必要时增加复杂度，随时准备回退 7. 可观测性转变：从 uptime 到 quality，从监控到质量改进 8. 未来方向：LLM 驱动的评估实现 + 人类提供的品味判断 = Vibe Evals

最终，从 AI prototype 到生产不是一个技术问题，而是一个系统问题— 如何构建正确的反馈循环，如何在快速迭代和稳定质量之间取得平衡，如何让数据驱动决策而不是被数据淹没。