基准测试不了解你的工作

原文：https://every.to/context-window/benchmarks-don-t-know-your-job

人工智能面临一个测量问题。企业知道自己为模型花了多少钱，也知道这些模型在公共基准测试上的得分。但它们往往不知道的是：模型是否真的帮员工节省了时间，是否产出了人们无需复核就能信任的工作成果。本期 Context Window 探讨的是企业如何自行回答这些问题：我们解释为什么组织需要围绕真实工作来构建测试，展示克隆我们主编这件事让 Every 在评估（evals）上学到了什么，并介绍帮助 Every 工程师判断家里能否开烘干机的六代理团队。

信号

氛围感无法规模化

假设你的公司每年在人工智能上花费 1 亿美元。你知道自己付了多少钱，也知道你所付费的模型在公共排行榜上的位置。但你仍然可能完全不知道，它们是否在完成你花钱让它们做的工作，或者一个更便宜的模型是否能同样胜任。这种花钱方式很奇怪。

Mercor 联合创始人兼 CEO Brendan Foody 表示，他遇到的企业高管正处在这种境地：他们每年花费高达 1 亿美元运行模型，却没有任何“离线评估”——即在模型接触真实工作之前，用一套固定的真实任务来测试和比较它们。Box 的 CEO Aaron Levie 引用转发了 Foody 的帖子，写道：“企业不能只靠感觉行事。”

公共基准测试可以告诉你，一个模型在总体上比另一个模型更强。但它们无法告诉你，这个模型是否抓到了你的律师关心的条款，是否保持了你的行文风格，或者是否让员工免去了又一轮检查。一个有用的评估应该从你公司已经在做的工作出发：代表性案例、员工知道要留意的失败模式，以及人类仍需手动修正的工作量统计。

与此同时，可供选择的方案数量正在成倍增长。投资人 Gavin Baker 引用了 Vercel CEO Guillermo Rauch 的一张图表，显示在短短两个月内，前端云平台上开源模型的 Token 份额从 28% 增长到了 62%。Andreessen Horowitz 的本周图表报告称，法律行业从业者对 Codex 的采用率自 2 月以来增长了 108 倍。越来越多的模型在越来越多的工作上已经足够好用。挑选分数最高的那个，已经不再算是一种购买策略。

一个可复用的评估，能给你一套判断模型能否按你想要的方式完成公司工作的工具。对每个候选模型运行同一组任务，衡量留给人类的工作量，然后比较节省下来的成本。你可以测试一个新模型，而不必从零开始，也无需轻信供应商最喜欢的那项得分。

在 Every，我们使用 Vibe Checks 针对团队每天所做的编码、写作和知识型工作任务来测试每个新模型。现在我们要更进一步：构建内部评估体系，让我们能够随时间比较模型的表现，并衡量模型实际做的事与我们期望它做的事之间有多大的差距。KateBench 是一个 AI 文字编辑，基于主编 Kate Lee 过去约 3 万次编辑修改训练而成。它会在 Google 文档中提出修改建议，然后追踪编辑接受了哪些、拒绝了哪些，以及编辑之后又自己改写了哪些内容。评估帮助我们判断模型的判断与 Kate 可能做出的判断有多接近。

本周可以做什么： 选择一项反复出现的工作，比如编制每周报告或制作演示文稿。写下当前模型在五个方面会出错的表现，每个方面配一个示例（一份达到黄金标准的报告或演示文稿），然后拿你正在考虑的模型去运行这些案例。这就是一个评估的开端。比起再花一个下午比较排行榜，这样做能让你更清楚该买什么。

走进 Every

86% 这个数字没有告诉你的事

要使用 KateBench，编辑需要标记 @every 来召唤 Every 代理，要求它进行一轮 Kate 式的文字编辑。代理会直接在 Google 文档中留下修改建议，由编辑决定接受或拒绝。

在最近的几次运行中，编辑接受了大约 85% 到 90% 的建议。Jannik Jung 是负责 KateBench 的工程师，他向我们展示了两个让人怀疑这个数字的理由。这个工具在提交 40 条建议后就会停止工作，所以在长文章中，它可能先找出一条不错的修改，但在编辑看到之前就把它丢掉了。现在这个上限已改为 80。

KateBench 还有一个问题：它每次读取同一份文档时，产生的修改并不完全一致。这意味着即使 Jannik 没有改动任何东西，它的接受率也可能上升或下降。一个新的提示词（prompt）可能某一次得分更高，但并不代表它持续更优，所以 Jannik 必须把每个版本运行多次，才能判断它是否真的算一种改进。

值得点击的链接

软件工程师 Steve Yegge加入了关于“沙盒”的讨论——沙盒是用于开发和测试 AI 模型的受控环境。他提出，智能体需要的是“围栏”——即关于每个智能体被允许做什么的明确规则——而不是从外部强加限制的技术壁垒。Cursor 解释了它为什么重建了 Git 托管服务：编码智能体会创建大量短命的仓库。它的新系统把每次代码变更都存储在云端，然后根据智能体的需要创建或丢弃工作副本。Andreessen Horowitz 普通合伙人 Martin Casado认为，Fable 的低市场份额是一个隐私问题：该模型会保留公司发送给它的数据，而且不提供零数据保留选项，这使得它对有严格数据政策的公司来说根本无法采用。CentaurBench 发现，最擅长独立完成任务的模型，并不一定就是最好的助手。在七项任务中的五项里，另一个不同的模型在改进较弱模型的初稿方面表现更好。而 Thinkingbox 发现，最强的编码模型单次尝试通过率为 65%，但当研究人员要求它在连续 20 次尝试中稳定表现时，成功率下降到了 25%。

对立观点

收益递减，怎么衡量？

Olivia Moore，Andreessen Horowitz 的另一位合伙人，周六在 X 上发帖说：“感觉我们在许多任务上的智能提升已经遇到了收益递减。我们可能不会再看到每个产品一发布就自动切换到下一代前沿模型了。”她认为，对于在模型之上构建产品的公司来说，更慢的进步速度反而创造了削减成本的机会。

我们同意的地方： Moore 对许多任务的判断是对的。Mike 表示，Opus 4.8 是 Every 在价格和质量上都没有犹豫就采用的最后一个前沿模型。

我们不同意的地方： “智能的收益递减”这种说法，有可能把当前的任务清单误当成模型未来能力的完整清单。公共基准测试测量的是一组狭窄的能力；它们无法告诉一家公司，某个模型是否在自己所从事的工作上取得了进步。KateBench 就展示了得出错误结论有多容易。它那高企的接受率让这个工具看起来几乎已经完工，但这个数字在一次次完全相同的运行中会发生变化，而且忽略了 Kate 之后仍然需要做的修改。本质上，除非企业构建出能够捕捉那部分残余工作——即智能体完成任务之后人类仍需做的工作——的评估体系，否则它们根本无法判断是进步放缓了，还是它们的测量方式根本没测到进步。

缺失的部分： 构建者仍然缺少一个针对特定任务的工具。他们应该削减成本——同时保持评估持续运行，这样当更便宜的模型在任务上失败时，他们能够及时发现。

最后一件事

烘干机也有了一个代理团队

Every 的设计师 Tyler Nishida 想让他家的离网太阳能系统回答一个问题：有足够的电力来运行烘干机吗？

他家位于夏威夷大岛的一处雨林中，所以天气预报不能套用典型夏威夷阳光的刻板印象。Tyler 用 Grok Bot 将一个 Raspberry Pi——一种信用卡大小的廉价计算机——连接到系统中。现在，他可以通过手机查看电池组电压，监控控制太阳能板向电池输送电量的设备，根据天气预测系统将产生多少能量，并在该启动发电机时收到提醒。

Grok Bot 创建了一个由六个智能体组成的频道来协作完成这套设置。Tyler 看着它们互相发消息。一个智能体告诉另一个智能体他需要买什么；后来，一个智能体通过私信把亚马逊链接发给了 Tyler。

这个团队并没有独自完成所有工作。Tyler 在最后几个步骤中使用了 Grok Build。现在，他家的烘干机有了一支六智能体运营团队。

核心启示：企业无法靠公共基准测试判断模型是否真正胜任自己的工作；只有围绕公司真实工作构建可复用的评估体系，衡量的又是“人类仍需手动修正的残余工作量”这一指标，才能在日益增多的模型选项中做出有依据的采购决策。而 KateBench 的案例表明，高接受率这类表面数字可能具有欺骗性，因为模型输出的非确定性和评估设计的局限性都会扭曲结论。