为什么做一个评估平台比看起来难得多
关联
在 AI 智能体快速普及的今天,怎么确保它们上线后不出岔子?
Hossein 在 Salesforce 和 Databricks 做了 15 年解决方案工作,现在在 Braintrust 负责西区的解决方案工程团队。
这场演讲回答了一个很多团队都会遇到的问题:为什么自己搭一个[[评估|评估]](eval)平台,远比想象中难。
评估到底在评估什么
智能体的质量靠两根支柱。第一根是评估:在上线之前,用测试输入跑智能体,看它的行为是否符合预期。
第二根是可观测性:上线之后持续监控真实用户的交互,验证之前的假设是否成立 。
两者本质上是同一个问题的两面——都是为了让智能体更可靠。
而这件事之所以必要,是因为大模型天生是不确定的、高度可变的。
这种灵活性让它能处理各种任务,但也带来了风险:品牌风险、合规风险,还有系统难以调试带来的成本风险 。
从电子表格开始,没错,但很快会遇到天花板
很多人评估的第一步就是:跑一批测试输入,把结果记进电子表格。Hossein 说这没什么可羞愧的,反而是个好的开始。
最简单的评估系统只需要三样东西:执行智能体的方式、查看输出的方式、一组测试输入 。
但问题很快出现。这个阶段你基本上只是在记录,没法做真正的实验,更没法做长期分析。
人工打分有价值但费时费力,协作很弱,懂业务的领域专家往往被排除在外 。
自己写个界面?只是看起来更漂亮
接下来通常是产品工程师出手,做一个定制界面。
这确实能把产品经理拉进评估流程,但根本问题还在:数据难以留存,长期分析做不了,本质上还是个报告工具 。
再往前一步,是让非技术用户也能在界面上做实验:改提示词、换底层模型、调参数,做并排对比。
可这里仍有个关键缺口——所有测试用例都来自离线环境,一旦上线,你就成了睁眼瞎,不知道智能体在生产环境里到底在哪一步出了错 。
真正的目标:让失败自动回流成测试用例
成熟的团队想要的是一个改进闭环:
从生产环境观察到失败模式,把这些失败转化成测试用例,离线迭代改进,再上线,如此循环 。
而且这个循环不会停,因为用户和智能体的交互方式会随时间漂移,就像经典机器学习里的数据漂移一样。
难就难在:这是个系统问题,不是界面问题
把这套闭环做进平台后,你得自己维护它。
而智能体的追踪数据非常棘手:它们是半结构化的 JSON,有的团队一次交互就记录几百兆数据——相当于一部电影的信息量。
普通的云数据仓库在这种负载下会直接垮掉 。
Braintrust 自己也撞上了这堵墙,最后造了一层叫 BTQL 的查询抽象。
实时摄入、超大载荷、深度嵌套的半结构化文本、既要大规模聚合又要时间点快照——这些都是 ChatGPT 爆火后出现的新问题 。
传统的可观测性数据只有几 KB,完全不是一个量级。
还没完:底层数据库、权限管理、数据脱敏,每一个都是独立的工程难题。
所以说,评估平台不是界面加电子表格,而是实打实的系统问题。
下一步:让智能体评估智能体
现在,智能体本身成了评估平台的一等公民。
你可以用自然语言对编程智能体下达指令,比如「找出过去 24 小时用户体验差的追踪记录,帮我跑一遍评估」。
因为编程智能体能访问代码库和基础设施,它可以直接执行评估并记录结果 。
在 Braintrust 的愿景里,平台还能自动从追踪数据中做推理,告诉你那些未知的未知——比如智能体在哪些场景下悄悄失败了,用户在哪些情况下反复用同样的请求表达不满 。
而人的角色退到最后一步:看结果,决定哪个版本值得上线。
本集带走
- 评估和可观测性是同一问题的两面:一个在上线前,一个在上线后,共同目标是智能体的可靠性。
- 电子表格评估是合理起点,但很快会遇到无法实验、无法分析、无法协作的天花板。
- 成熟团队的核心是改进闭环:把生产环境的失败自动转化为测试用例,离线改进后再上线。
- 智能体追踪数据又大又乱(单次交互可达几百兆),普通数据仓库撑不住,评估平台本质是系统问题。
- 未来趋势:编程智能体自己跑评估,平台自动发现未知的未知,人只负责最后拍板。
评测是一种让你能够持续朝着单一目标攀爬的方式,这个目标就是智能体质量。
Evals are a way for you to continue hill climbing against one target, which is agent quality.
—— Hossein · [06:41]
但一旦我把它发布到生产环境,我就是在盲目的状态下运行。
But once I ship it to production, I’m operating in the blind.
—— Hossein · [10:42]
在某些情况下,我们看到团队在每次交互中记录相当于一部电影大小的数据,几百兆字节。
In some cases, we see teams that are logging a movie’s worth of data in each interaction, hundreds of megabytes.
—— Hossein · [12:12]
我有巨大的 payload,有几十兆、有时几百兆的大小,而传统的心跳可观测性数据只有几 KB 的大小。
I have huge payloads that are tens of megabytes, hundreds of megabytes in size sometimes compared to traditional heartbeat observability, which are just kilobytes in size.
—— Hossein · [13:54]
这些特性中的每一个都证明了,这不仅仅是一个 UI 加一张电子表格,而是一个支撑它的系统问题。
Each one of these features proves that this is not just a UI and a spreadsheet, but rather it is a systems problem that powers it.
—— Hossein · [16:32]
顺着「智能体」挖下去
- 模型不再是护城河,谁在围绕模型建「自己的智能」同概念:可观测性 (observability)、智能体 (agent)、评估 (evals)、追踪数据 (trace)
- 智能体上线后总出问题?先学会「看见」它在干什么同公司:Braintrust · 同概念:可观测性 (observability)、编程智能体 (coding agent)、评估 (evals)
- 模型一换代系统就崩?evals 才是你该押注的持久资产同公司:Braintrust · 同概念:智能体 (agent)、评估 (evals)、可观测性 (observability)
换个口味
- 评测优先:Braintrust 创始人谈 AI 产品开发的真正工程同公司:Braintrust · 同概念:LLM、可观测性 (observability)、智能体 (agent)、评估 (evals)
- DevOps 之父 Patrick Debois:AI 时代组织比技术更难成熟同概念:可观测性 (observability)、智能体 (agent)、评估 (evals)
- 管理者日程突然能写代码了:CTO 的通宵智能体工作流同概念:智能体 (agent)、编程智能体 (coding agent)、评估 (evals)
