The Best Way to Test New AI Models

我们现在正处于新模型大量涌现的秋季。

过去几周，我们迎来了一批前沿的闭源新模型——Opus 5.5、Astra 6、Sol 6.1——还有更多在路上。

而且，从同样的实验室，我们还得到了像Sonnet 5.5这样更具性价比、速度更快的模型。

然后，好像这些还不够似的，我们还得到了许多新的开源权重模型，这些模型对各种类型的业务越来越重要。

当然，每次这些模型发布时，都会附带基准测试结果。

但基准测试并不能真正告诉我们这些模型对我们个人来说有什么相关性。

为此，你需要建立自己的个人AI基准测试，一个能判断模型对你个人AI工具栈是否有用以及如何有用的系统。

这正是今天这期聚焦实操的节目的目标。

《AI每日简报》是一档每日播客和视频节目，涵盖AI领域最重要的新闻和讨论。

好了，朋友们，在开始之前快速说几个通知。

在正式开始之前，还有一个快速说明。

这是上周我和Noufar Gaspar主持的网络研讨会的录音。

鉴于本周我们又收到了几款新模型，我认为这里讨论的系统依然非常切中要害。

希望你觉得有用，明天我们会恢复正常节目。

但现在，我们来聊聊如何建立个人AI基准测试吧。

我们为你准备了一些很有趣的材料，最后会全部分享出来。

你会全程看到这些材料是什么，但基本上，你看到的我做的和说的所有内容，你都会得到，以便你自己尝试进行类似的流程。

记得利用问答框，因为人数众多，我们无法开启麦克风，但Dan在这里，Nathaniel也在，每个人都会尽力回答你们的问题。

废话不多说，Nathaniel，说说我们为什么在这里的动力吧。

是的，感谢大家来到这里。

我想，对于各位《AI每日简报》的常客来说，你们知道，在基准测试这个问题上，我一直喜欢唠叨几句。

每次我们得到一个新模型——顺便说一句，现在前沿模型平均每11天就出一个——我的标准警示之一就是，首先，要对公布的基准测试持怀疑态度，倒不是因为我们觉得这些公司在撒谎。

这不是他们做事的本质，而是因为大多数这些基准测试现在都包含在训练数据集中，成为模型训练的一部分规范。

只是基准测试的价值有限，而且它们存在的时间越长，价值就越低。

现在，很多人不断创建新的基准测试来试图改善这一点，目前这确实是一个相当活跃的环境，比六个月前活跃得多。

但即便如此，仍然存在实实在在的局限。

除此之外，即使我们假设所有基准测试都完美准确，我们现在所处的阶段，更多不是关于模型性能的严格优劣判断，而是关于模型给人的感觉以及它如何融入你正在构建的整体模型栈。

而且我可以保证，会有这样的情况：在某些基准测试上技术最先进的东西，在你做的那个版本上反而更差，即使那个版本在排行榜上排名较低，对吧？

这在写作这类事情上尤其如此，因为写作很大程度是非常主观的。

所以所有这些都说明，要弄清楚一个新模型是否适合你的工作流程，除了实际使用它之外，没有捷径可走。

所以我过去在节目里讲过一件事，就是尝试建立你自己的 benchmark，里面包含你最常用的 use cases。

NuPhar 非常好心地主动做了一个更全面、更详实、更周到的版本，这样我就不必总是重复这些话，却没有实际资源来帮助你。

所以我觉得，时机再合适不过了。

这周，我想我们用的是 Model 3。

我们拿到了 Claude 5.5、Sol 6.1。

严格来说，我们还没得到 Gemini 4 Argon。

我们只是看到它发布，但现在这个时间点，我不觉得这会慢下来，尽管我们现在已经是在跟上前沿节奏了。

我们对 Gemini 有一些预测，但在看到实际情况之前，我们不会分享。

然后我们就能说我们是对的，或者非常安静地承认自己错了。

非常好。

好了。

今天要讲的，或者说我为了让它更标准化并帮助你自行操作而设计的流程，基本上由五个步骤组成。

第一步，也可以说是最重要的一步，就是决定哪些任务需要放进一个可重复的 benchmark。

这些任务应该代表你工作中做的各种事情；如果你也用 AI 处理个人事务，那也要加进去。

它们需要是那种，基于你得到的结果，你会愿意据此做出决定的任务。

这是最关键的一步之一，会帮助你更好地执行。

然后你需要决定哪些是候选对象。

所以很明显，如果想测试的只是单个模型发布，你就可以拿它和你现有的模型名单进行对比。

在很多情况下，就像我们最近几周看到的，模型是成批出现的，所以你可能经常有不止一个新候选要评估。而且，如果你已经用同一套方式工作了一段时间，只是想让事情有点新意，这也是一个很好的做法。

所以，确定你评估的是什么。顺便说一句，我们一直在说模型，但有时候你只是要评估一个新的 harness，或者一个新的 agentic 工具与模型的组合。

所以有时候不只是模型。

也可以是某个具体工具、功能，或者你正考虑引入最佳工作方法的东西，然后你再去运行真正的 benchmark 和对比。

为了让大家都能上手，我会介绍三种方法。

一种是高度手动，但仍然有效。

一种是用我创建的小脚本，我也会分享给你，这样你就能完全复刻我运行 benchmark 时采取的相同步骤。

还有一些专门的工具和平台可以帮助公司做这件事，我们会顺带提到。

它们不是今天的重点。

为了让 benchmark 有效运作，建议你把每个结果是由哪个模型或工具生成的隐藏起来，因为我们都对自己心爱的工具带有很强的偏爱。

剧透警告：我对自己的结果相当惊讶，一会儿你们会看到。

最后，就是做决定了。因为在某一次 benchmark 运行中，某个工具或模型表现得比你当前这套更好，并不一定意味着你需要自动做出改变。

首先，因为变化本身就是件难事，其次，有时候是否要做这个改变还涉及其他考量。

可能是公司限制，可能是成本问题，也可能是延迟问题，甚至可能因为改进幅度不够大，让你觉得不值得换。

所以我们会在这次网络研讨会中涵盖这全部五个步骤。

那么，关于如何应对这些层出不穷的新模型发布，我想分享几点想法——因为每次发布都遵循同样的套路：一个公告、一张测试成绩表（你们都见过Gemini那张表），然后是一周的热议，每个人都说“我有早期访问权限，这是我的看法”，或者有影响力的博主提前分享他们的实验结果。

通常，早期的实验往往严重偏向于制作一个小游戏或小应用，比如搞个3D玩意之类的，这些可重复的用例在社交媒体上看起来特别漂亮。

而且，有些人会声称，某些模型的设计就是为了在社交媒体和网红测试中表现好看，这样它们在短视频里就会显得很厉害。

然后大约七天后——有时长一点，取决于热度和粘性——我们开始看到更真实的解读，因为这时候报告来自实际工作场景。

举个例子，某个模型悄悄在我的合同审查中漏掉了一个条件，这对律师来说非常关键；而另一个模型却能生成一个令人惊叹的3D游戏，完美复刻了我90年代最爱的某某。

所以我们对早期的发布持保留态度。

我们会认真听，因为也许真有颠覆性的东西，但最终还是要看一段时间后的效果。

更重要的是，我们自己得亲自测试。

具体到今天，我们会看看一些新来者，比如Claude Opus 5.5、Grok和GPT-6.1 Sol。

Gemini什么时候来还不确定，如果你们愿意等，可以到时候再跑基准测试，或者用Gemini重新跑一遍。

我当然很好奇，一旦我们获得Gemini的访问权限，我会把它加进去，跟其他模型以及我将展示的其他结果进行比较。

这就是今天的重点，也是我要具体比较的内容。

你们听我讲的时候，可能心里在想：我对个人基准测试这个整体概念有一些担忧或反对意见。

通常，这些意见有两种类型。

第一种是：现在什么都那么好了。

前沿模型已经遥遥领先。

就像，我们干嘛还要在意？

是不是只是工具FOMO或模型FOMO在作祟，感觉如果我们不追逐前沿，就落伍了？

这就是一种反对意见。

我对这种反对意见的回应是：首先，你说得对。

前沿模型确实很好，而且就算你不一定要更换工具或模型，你能挖掘的价值也远远大得多。

但是，有时候，一个新模型的发布——就像NLW在播客里反复说的——可能会解锁一个以前只存在于愿望清单上的用例。

而且我认为，即便只是为了这个理由——解锁新用例，推动AI使用方式的边界——这也是一个很好的理由，至少偶尔考虑升级到新模型或新工具，确保你能够最大限度地利用这项技术。

并不需要每周都做，因为那样本身就会造成很大的混乱。

所以你可以根据自己的精力定期进行。

第二种反对意见或考量是，有时候人们会说：这挺好玩的，像你们这样能随便用任何工具和模型的人，可以尽情换来换去、追赶前沿。

但在我这里，我的公司限制我只能用某个特定的工具或模型。

这是很多员工都会遇到的现实情况。

首先，我表示同情，我理解你的感受。

这真的不容易。

不过，即使模型和工具的选择有限，也总还是有选择的余地，哪怕只是在不同配置之间选，比如快速思考、快捷模式之类的。

所以，即使你把评测范围限制在工具内部那一点点可选项上，这些选择也同样重要。

有时候，不管是出于个人使用场景，还是为了说服公司里做决策的人，跑一次基准测试，哪怕是用模拟数据，也值得做——这样你就能向公司的人证明，也许你们应该考虑再买一个许可证。

这就是所谓的反模式。

说完这些，我想回到一开始提到的——整个流程中最重要的决策。

也就是你用来做基准测试的具体使用场景。

在我看来，理想情况下，你需要覆盖你实际在做的事情，不管是工作还是个人使用。

当然，这个比例要跟你实际用 AI 的情况保持一致。

如果你主要用 AI 来工作，那就侧重工作场景。

如果你主要用 AI 处理家里的事情，那就多关注那些方面。

然后，我建议你尽量构建一套多样化且均衡的使用场景。

当然，你不可能把工作中的每个任务都跑一遍，所以你要精心挑选一套好的场景——如果你发现某个模型在这个场景下有明显提升，或者表现好得多，你就会认真考虑切换——也就是说，这套场景的产出你要足够信任，能用来为工作做实际决策。

这些场景要多样化，涵盖你不同类型的工作以及使用频率，最好是那些你经常做的任务，因为你从中获得的提升最大。

你还要问问自己，这里面有什么风险？如果你知道哪些错误代价很高，或者有办法快速判断结果完全不对，那也是一个好的使用场景——因为如果你能识别出糟糕的结果，有时候这比那些需要区分细微差别的正面场景更有用。

另外，对于你正在使用的具体任务，它是从零开始，还是只能基于现有文档来启动？比如润色一封邮件、美化一份演示文稿，这些都需要先有内容才能开始做。

最后，就像我说的，这也是为什么即使你对现有配置很满意，仍然值得跑这些基准测试的原因之一——至少要包含一个你特别想实现但还没做好的任务。

这是什么意思呢？

就是那些你用 AI 试过，但对结果不满意，所以平时不会用 AI 去做的任务。

我强烈建议你放一两个这样的任务进去，这样当新的前沿模型出现时，这些任务就是最让你兴奋、促使你切换到新模型的因素之一。

这就是我们需要做的核心决策。

当然，你可以根据你的实际情况来决定数量。

我建议大概 4 到 6 个这样的使用场景，当然你也可以多选或少选。

我会展示我是怎么梳理出来的，但为了具体一点，这是我的 6 个使用场景列表。

一个是发 LinkedIn 内容，另一个是跟利益相关者进行关键甚至有时不太愉快的对话，比如在价格谈判中据理力争。

还有做一些关于工具特性的调研，要具体一些；一个网站，包含我上的一门课的内容；以及为我管理的课程设计练习。

这个在愿望清单里——一个像样的每周计划，就像一个靠谱的总参谋长那样，让我不会感到沮丧或忽略它。

到目前为止，我还没找到一个模型能一次性搞定复杂的每周规划，而不需要我来回提示它。

所以这就是我的系统，我马上给你展示我是怎么得出这个结论的。

一旦你有了用例列表和用例的具体细节，接下来你要做的就是进行一次品测，当然最好是盲测。

我们要选出哪些模型、工具或者模型与工具的组合作为候选来评估。

快速说明一下，在这个实验中，我跑了7个模型选项，我可以告诉你，7个实在太多了。

对6个不同的任务，给7个模型选项打分和审阅，过程极其繁琐。

所以我其实不是……其实是5个，但也不推荐。

我建议只跑现有模型对比一个新模型，或者最多比较4个候选。

其中一个候选应该是你当前做这项工作的基线。

这样你才能知道是否要切换到新模型。

然后我们每次请求都要在全新的对话中运行，这样上下文窗口就不会让我们跑偏。

接下来，这一步非常重要，我们要隐藏模型的名字。

一会儿我会简单说说怎么做到这一点。

做完盲测之后，我们可以口头反思一下是否喜欢这个输出。

我们可以给一个数字评分，或者两者都做。

你即将获得的这个程序化工具包鼓励你两者都做。

按1到5分打分，并写一行观察记录，说明你喜欢什么、不喜欢什么。

盲测完成后，你就可以揭晓各个模型的身份了。

这是个很有意思的环节，可以看看你预测的哪个模型产生了哪个输出是否准确。

我保证其中一些结果会让你惊讶，因为我们对某些模型有很多固有看法，但并非全都符合现实。

最后，我们需要做决定。

所谓做决定，即使某个模型明显更优，但可能优势还不够大，或者有别的考虑，我们可能不会因此改变习惯。

以上就是我们进行品测的方法。

具体到如何让不同模型的结果匿名化，有4种方式可以做到。

第一，你可以找一个朋友帮你做匿名处理。

要么让他们帮你运行所有结果，然后只给你一套匿名化的结果供你评估。

这适用于你手动做基准测试的情况，手动做当然没问题。

只是会多费一点工夫。

你可以用电子表格生成随机数，然后这样匿名化。

你可以利用AI工具来打乱和重新标记，这样你就不知道结果来自哪个模型了，或者你也可以用我写的脚本帮你做这件事。

当你使用这个脚本时，有一件事需要做：你需要使用API key来实际执行任务。

一种方法是用 OpenRouter，它允许你用单个 API 密钥运行多个模型；或者你也可以为每个供应商单独准备 API 密钥；如果你只跟某个特定供应商合作，只想评估它不同层级的模型，那用单个 API 密钥就行。但无论哪种，编程或脚本方式都需要 API 密钥。

我可以向你保证，即使你不懂技术，现在也很容易做到。

这就是匿名化处理的方法。

还有一点要特别注意，我强烈建议，有些任务会更偏视觉，比如网页设计、应用设计或图像生成。

因为大多数情况下，视觉内容更容易让我们快速打分。

当然，如果你根本不用 AI 做任何视觉相关的事，就别为了测试而硬选视觉任务。

但如果你偶尔也用 AI 做点视觉方面的事，就确保测评中包含这类内容。

要评估视觉内容，你可能需要把它们存到专门的文件夹里，这样就能在固定位置打开每个视觉素材，比如网页之类的。

很快你就会看到我是怎么处理网页设计的。

接下来我们需要做个选择。

第一个也是最重要的方法，就是你自己给结果打分，因为这是个人基准，没人比你更清楚自己的偏好。

就像你之前指出的，有时候会有一个 X 因素，让你喜欢或讨厌某个结果，哪怕你说不出原因，你只是更喜欢其中一个。

有时候我们确实词穷，说不清为什么喜欢这个而不是那个，但理想情况下，你应该是自己喜好的主要评判者。

根据我的经验，单独评判一个东西往往很难，也就是说，你从某个工具或模型得到结果后，想给它打一个 1 到 5 的绝对分数，非常困难。

更简单的方法往往是，把同一任务的几个备选结果放在一起对比，然后说，这个我最喜欢，那个我最不喜欢，然后据此打分。

通常就该这么做。

这是一种方法，而且很可能最重要，因为涉及你的个人品味和那个 X 因素——你常常说不清为什么就是更喜欢某个结果。

另一种方法，而且你可以两种方法都试试再对比，就是借助 AI 工具来做评判。

这样就不是你一个人在打分，而是也有一个 AI 工具，根据你设定的评判标准来评估结果，比如什么是好的 LinkedIn 帖子、什么是好的供应商谈判、什么是好的网页设计。

你随时可以对比，看看综合评分是否一致，以及是否形成了一种清晰的模式，告诉你需要调整哪些地方。

但我要提醒你，用 AI 做评判也有其缺点，关于用 AI 做评估，已经有一套完整的理论体系了。

不过我要说的是，你应该先评估评判者本身。

因为，如果这个评判者完全不符合你的品味，那它就是个糟糕的评判者，直接扔掉。

关于评判还有几点要补充。

因为品味非常主观，所以我们才需要并排对比和口头描述。

而且我们才尝试用 AI 根据我们的标准来做主观测试，但正如我说的，这并不完美。

理想情况下，你用来做评判的模型，应该跟执行任务的那些模型不一样。

因为存在某种 AI 裙带关系。

某个模型很可能会偏袒同系列的模型，而不是其他系列的。

虽然不是绝对，但这种现象很常见。

所以如果你有另一个模型系列不在你评估的范围之内，那就让它来做评判。

在我的用例中，因为我还没有用Gemini评估过任何东西，所以评判模型用的是Gemini。

就像我说的，隐藏模型的名字非常重要，因为我们非常偏见，而且没人能证明我错了。

我相信我们可以证明情况确实如此。

我们希望尽可能保持一切不变，也就是说，对每个模型都提出完全相同的请求，然后以公平且对等的方式进行比较。

而且因为答案可能不同，如果你在某个非常重要的事情上运行这个个人基准测试，并且这可能涉及到金钱或者其他方面的影响，从而促使你改变工作方式。

理想情况下，你应该对每个模型多次运行相同的请求，然后比较这几次执行的结果，因为我们知道模型的反应非常多样。

即使我们使用完全相同的模型、完全相同的配置和完全相同的提示，你也会得到不同的结果。

我今天刚刚看到这一点，当时我让一个模型生成一个网站。

我真的很喜欢第一次的结果，但中间卡住了，然后第二次执行时，我觉得远不如第一次好。

所以这是真实的情况。

如果你担心基准测试的有效性，多次运行就能确定结果。

KPMG和University of Texas at Austin的一项新研究发现，当人们使用AI工作时，相似的技能并不能保证相似的结果。

研究人员研究了500多名职业生涯早期专业人士，发现表现最佳的人通过引导、评估和优化AI的输出来持续放大AI的价值。

这些表现最佳者被称为AI Amplifiers，他们并非仅由所掌握的知识定义，而是取决于他们如何与AI合作。

在这一点上，问题不再是公司是否在积极使用AI。

而如何用好AI，则完全是另一回事了。

但Robots and Pencils是一家我可以指出的、真正为这个时代而生的公司。

他们是一家应用AI工程公司，直接与客户合作解决对企业重要的问题，而不是停留在幻灯片里的实验。

每一次合作都是从客户真正需要的结果逆向推导开始的。

如果你想在这个领域区分真正的AI工程和噪音，这就是关键所在。

每一集我们都会报道OpenAI、Anthropic、SpaceX AI、Google和Meta之间的竞争。

很可能你已经对谁处于领先地位有了自己的看法。

但每个AI实验室都采取不同的方法，构建不同的技术，建立不同的合作伙伴关系，并发展独特的生态系统。

好的。

就像我们说的，最后一步是决定。

理想情况下，你应该做出三种类型的决定。

Switch（切换），意思是我确信这个模型或工具明显更好，综合考虑所有其他因素，我想切换到这种新配置。

Split（分割），意思是我可能会在不同的选项之间进行更细致的权衡。

或者Stay（保持），就像，我并不认为我刚才评估的新事物的表现足以让我改变工作方式。

所以这就是核心决策。

但是，要做出决策，并不是那么直接了当，比如“这是最终的最佳结果，因此我就要切换”。

还有其他一些考虑因素，有时会让你保持现状。

例如，也许你的公司不允许你切换，所以这并不相关，或者也许你担心某些条款和条件。

也许你自己的计划根本没有提供，或者没有给足够的使用额度，来支持你所考虑的新工具或新模型。

在其他情况下，胜者并不明确；它不足以证明改变是合理的。如果你需要打破僵局，一些可以帮助你决定的因素包括成本、执行速度，也许还有一些你很喜欢而不想改变的具体功能，以及习惯。

养成习惯的成本很高，所以如果没有显著的提升，仅仅保持原来的工作方式也有其优点。

但如果所有这些测试都证明改变是合理的，那么就做出改变。

所以这就是整个过程。

接下来你们将看到的是我创建的一个自动化过程，就像开头提到的，你们可以获得它，以便自己实施。它的工作方式如下：

它从你保存的任务开始。

我会展示如何保存它们。

然后，我使用OpenRouter API密钥来为不同类型模型生成结果。

然后我们得到每个选项的答案。

代码本身会对结果进行匿名化处理，这样我就不知道这些结果是由哪些原始模型产生的。

你在不知道哪个模型产生什么结果的情况下对它们进行盲评。

你给出评分以及文字描述，然后有一个有趣的大揭晓环节，向你展示你的偏好与评判者以及模型名称的对比，这是有趣的部分，常常会让你感到惊讶。

我用了OpenRouter，但正如我所说的，还有其他模型集散地。

使用任何你觉得相关的平台，但你需要相关模型的API密钥。

所以这就是你们即将看到的方法论。

正如我说过的，我正在评估多个模型。

所谓的“基线”，虽然我一段时间没用了，是Opus 5。

同时我也在尝试Opus 5.5、Grok 4.7、GPT-6.1 SOL。

我还想将它们与非常昂贵的前沿模型Fable 5.1和GPT-6 Astra进行对比测试。

为了确保给开源模型留出空间，我也将它们与Kimi K3进行对比测试。

这就是为什么我得到了7个不同的选项，并且评估起来非常困难。

最后，就像我说的，由不同的模型来运行评判。

在这个例子中，我使用了Gemini Pro。

所以这就是你们即将看到的。

现在让我带你们了解这个过程。

你首先会被鼓励做的，就是运行一个提示词。

这个提示词是材料的一部分，它帮你发现哪些用例应该纳入你的基准测试。

所以这个提示词会像采访你一样，利用最了解你的那个AI工具所能给出的全部建议。

所以一定要在一个拥有大量记忆和大量上下文的工具里运行它，尽可能多地利用这些。

它会帮你搞清楚这些问题。

它会经历大约8个问题的流程，帮你找出最佳用例。

如你所见，Claude知道得挺多的。

它知道我的角色，也知道我一周通常都做些什么。

所以它会有一些猜测，对用例也有一些初步建议，还有一些来回互动的内容。

然后它就开始问我问题了。

所以我回答了它提出的所有问题。

在8个问题之后，虽然有点烦人，但也没太烦，它就给我生成了一组6个推荐用例。

对每个用例，它还会创建一个提示词，用来做实际的基准测试。

所以它不只是发掘出用例，还会发掘出真正发送去运行基准测试的那个提示词。

所以那个就是“根据原始笔记写LinkedIn帖子”，还有“提示词定价异议加敏感邮件”。

“按套餐层级整理当前AI工具功能”，这个需要联网搜索和查资料。

“课程参与者中心网站”、“面向新受众的一次性练习”，还有“周计划：课程参与愿望清单”。

所以这些就是前6个，最后它还会显示你的覆盖情况。

比如我决定不包含任何个人相关的内容，因为我在个人方面使用AI没有工作方面那么多，所以那些对我来说不太相关。

它确实也指出了一些可能缺失、值得注意的东西。所以这就是最终结果。

最后，如果它是一个agentic工具，它会把它保存到一个专用文件夹里，其中每个文件都是独立的文件。

比如，这就是“LinkedIn帖子生成器”文件的样子。

里面有任务名称、快速动机、请求。

这就是会发送给模型的实际提示词。

这很重要，因为如果你想用AI工具来评判基准测试，而不仅仅基于自己的偏好，那会有一个给评判者的评分指南。

所以它也被附加为任务本身的一部分。

我想让你做的一件事是，看看通过这个过程生成的提示词或任务。

如果它看起来太泛泛，或者无法帮你在某个具体用法上做决定，或者你觉得它需要更深入、或者完全不一样，那么这一步就非常重要：你要去细化请求和评分指南，这样才能做出决策。

如果你不觉得这些任务能很好地代表你的工作方式，那这就不是一个足够好的基准测试。

所以我这里有6个这样的任务，从1到6，是Claude根据那次采访过程，以及你也能获得的全部指令生成的。

所以一旦我们都有了它们，我们就可以开始运行自动化过程了。

这个自动化过程是我创建的一个脚本，就像我说过的，我正在分享给你。

为了让过程有趣且愉快，这个脚本还创建了一个简单的用户界面，就托管在你自己的机器上。

它不需要去任何地方。

所以，它不是——没有你未打算的数据共享。

而且总的来说，顺便提一下，如果你的公司数据敏感，就不要用像OpenRouter这样的服务来处理公司数据。

使用模拟数据或模拟用例，这样就不会有任何机密信息泄露到任何地方。

这种用户界面创建的方式，你会看到这里。

需要评估的任务列表。

对于每一个任务，它会生成所有候选模型。

在我们的案例中，它将模型匿名化为从A到G，并且在每个用例的顶部，它会根据你的评分标准告诉你什么是好的答案，以帮助你正确评分。

然后你可以并排看到我们从OpenRouter得到的所有结果。

所以这是在脚本后台运行并使用提供的API密钥后完成的，它为我之前看到的五个任务中的每一个都生成了候选回答，并将它们并排展示。

所以你可以看到，例如，这是LinkedIn帖子生成器。

所以模型D提供了这个开头选项：三只手举手，等等等等。

完整的帖子结尾选项。

所以第一个看起来就是这样。

然后它要求我做的是提供一个1到5的评分，以及一个口头评价。

所以在这种情况下，我打了五分中的两分，并且说。

虽然它可读且清晰，但也太轻泛了，而且包含了那种“是A而不是B”的模式，我个人非常讨厌AI写作中的这种模式。

所以我得到了7个这样的。

而且就像我跟你说过的，在至少阅读一批之前很难评分，因为至少在LinkedIn帖子那个任务中，不同模型的回答有些重叠。

但是正如你可以看到的，我确实给出了不同的评分。

所以有些得到了3分、4分。

实际上，没有一个被我打5分，因为没有一个写出足够好的LinkedIn文章。

所以没有一个可以直接发布。

所以那是任务1，当我完成时，界面显示所有任务已评分。

我还有定价反驳、一次性练习和周计划这些任务。

这些都是文字量很大的用例，所以它们不那么令人兴奋。

我在想，最令人兴奋的事情是看到不同的候选模型如何创建一个课程参与者中心网站。

所以这里呢，如果你有HTML或者其他视觉素材的话，这个小应用挺有意思的，你也可以自己做一个，而且还能拿到它。

它只是展示了不同的网站。

我把它们都全屏打开给你看，而且当你跟我一起浏览这些由不同模型创建的网站时，有个好玩的练习就是猜猜哪个是哪个。

你也可以在聊天里开始猜，哪个看起来像是KIMI，哪个像Claude，哪个像GPT。

哪个看起来像Grok？

我特别好奇你们有多少人能猜对。

所以这是其中之一，不是最好的，但话说回来，它们都创建了相当完整的网站。

所以很高兴看到它们生成了文案，还有导航这些。

所以这是其中一个候选。

这是另一个候选，给这家虚构公司做的培训门户。

我不太喜欢，但也不是最差的。

又一个。

这个稍微更有主见一些，你能看出来。

我觉得这是我最喜欢的一个，也是因为我审阅了部分文案，不光是文案功能和导航。

这又是另一个做出来的。

这又是一个。

这差不多是最后一个了。

最后是这个。

所以我们有7个候选。

如果在座有人能全部猜对这7个模型，那我真要给你点赞。

我猜得差远了，但你看，对于任何视觉化的东西，往往更容易有明确的偏好，比如觉得‘哦，我喜欢这个’之类的。

所以一旦我完成了，你也会完成每个任务的评分，接下来你能做的就是要么只公开我的评分，要么跟AI裁判一起公开。

所以当你点击‘跟AI裁判一起公开’，所有结果就会发给裁判审核，裁判也会参与评分。

然后它会逐步揭示结果。

所以你看，每个任务都有我的首选，还有几句理由。

现在，敲鼓吧，我们来揭晓名字。

对于LinkedIn帖子生成器，我最喜欢的是Kimi、Fable和Opus。

我挺惊讶的。

我本来以为GPT肯定在里面。

对于价格异议处理，你可以看到GPT模型在谈判方面是最好的，至少在我看来是这样。

在这个练习中，我们用了GPT和Grok，做周计划，结果Grok赢了，挺有意思的。

对于课程参与者中心，是Opus 5.5。

可能有些人对此并不惊讶。

接下来我得到的是针对每个模型的建议，针对具体任务该怎么处理，是把它添加到模型清单里，还是考虑切换。

换成用这个模型。

当然了，我们说过，要考虑，对吧？

我们需要做额外的判断。

现在来看看最终结果，因为我觉得这也很有意思。

我们列出了不同模型以及它们的平均分、它们被选中的任务数量，还有裁判的平均分。

比如，Fable排第一，因为裁判给了它第一。

但是注意这里。

Fable的总成本比其他所有模型都高得多。

这可能会成为不选Fable的一个考虑因素，尽管理论上它表现更好。

注意看我的平均分。

在我的平均分里，Fable和GPT Sol是差不多的，但看看成本差异。

这个成本低了一个数量级。

平均用时很接近。

注意，这也很有意思。

Groq的平均用时非常长，尽管成本很可控。

KIMI也在竞争中，有意思。

这些模型整体得分较低。

记住，我们想要更差异化的使用，所以我们可能不只是寻找一个赢家，而是针对每个任务做出更差异化的选择，这样我们可能会有不同的视角。

然后你还有更多数据，比如每个模型在每个任务上花了多长时间，你可以看到KIMI在成本和耗时两方面都胜出。

你还可以看到——5.1在哪里？

5.1很可能是这一组中整体最贵的。

所以成本可能不让你意外，但是一些关于成本和速度的数据，以及我和裁判之间的并列比较。

如你所见，我们意见很不一致。

因此我说，把任何AI当作裁判都要持保留态度。

我们唯一达成一致的是价格方面的反馈。

嗯。

剩下的，你可以看到，我们有不同的选择。

这里要指出一点，评委只能看到代码和文字。

所以对于Hub网站的选择是基于代码，而不是基于视觉上的东西。

因此，如果你想让AI去判断视觉上的东西，仅仅使用API通常不是最好的选择，因为它没有把那个当成图片来利用。

它会直接进入代码。

从今以后，我会根据评委来做选择吗？

可能不会。

我也可以去修改一些评委的指令，但我更愿意依赖自己。

然后你有一些原始分数，你那里什么都有。

那就是应用，那就是过程。

只是为了展示最终结果，有趣的名单，其中一些完全出乎我的意料。

我在考虑改变我的一些工作方式吗？

老实说，是的。

我日常工作中非常偏向于Claude和用Groq的Cursor。

虽然我偶尔也会用GPT，但它不在我的前两名之列，我绝对在考虑更多地使用GPT，让它成为我的前两名之一。

如果我必须选择一种工具，基于这些结果，我可能会愿意考虑主要转向GPT，至少在当前时代。

这就是完整的流程，而且正如提到的，你们可以完全自己运行。

在我回答问题并从Nathaniel那里听取一些观察之前，还有几点补充。

正如我所说，我创建了一个流程，可以手动运行，也可以利用脚本来运行和我自己做的相同流程。

如果我说没有平台能直接做类似的事情，那我就是疏忽了。

这些通常是面向已经在规模化或公司级别做这些事情的团队的平台。

一些例子包括LangSmith、Braintrust和Langflow。

使用，而且它们不是唯一的。

我们还有其他的选择。

所以，如果你处于需要以更标准化和常规的方式进行这类评估的情况，这些都是值得研究的好选择，这样你的实验、监控和评估将以更系统的方式进行，而不是你必须自己创建这些即用的小脚本。

但如果你主要是个人使用，那么我刚才展示的方法就足够了。

正如我所说，你会得到讲义和会议讲义，还有一些其他东西。

我一会儿给你看看它长什么样。

这是一个不错的地方，你会得到所有材料以及实验本身，非常一步一步来。

你还可以下载实际的脚本和基准测试运行器以及其他很多东西。

而且我们还有资源。

所以对你刚才看到的所有东西，都有非常全面的视角。

我们一会儿就会分享出来。

所以把所有这些归到一处，这就是五个步骤。

最重要的是任务选择。

选模型，挑有趣的候选，用其中一种方法跑，做盲测。

这是非常有趣的体验。

做一次，哪怕只是为了享受让自己惊讶的感觉，并思考改变一些东西。

如果你做得好，创建了一个好的 benchmark，那么从这之后，每次你要考虑投入一个重大变化时，都可以跑同一个 benchmark。

所以这是一次性的努力，如果做得好，我保证它会让你受益匪浅。

所以如果你觉得有用的话，强烈推荐。

谢谢你，Noufar。

这对你来说是怎么演变的？

比如说，这一套测试在三个月或六个月前和现在相比，会有什么不同？

我特别想到 OpenAI 推出了那种超快模式，Sam Altman 基本上说，直到用上它之前，他都没真正意识到速度对他有多重要。

当然，那个模式目前只在一个每月五百美元的计划里才有，诸如此类。

但你大概会多久更新一次这类标准？还有你觉得随着时间的推移，哪些方面会变得越来越重要？

我猜，首先这取决于你有多疯狂和有多注意力不集中，因为如果你又疯狂又注意力不集中，可能每个月都得更新。

但具体到你的问题，当我看到 Ultrafast 的演示时，而今天我要坐下来等有时二十分钟才能让这个破网站生成好，说实话我非常不耐烦。

我意识到我现在对速度的关注度比以前看到 Ultrafast 演示之前高多了。

有些考量是实时更新的。

有些使用场景——这正是为什么我想要一个愿望清单——有些使用场景我现在会去追求或者视为前沿用例，以前我做梦都想不到能以那种质量一次就搞定。

所以门槛越来越高了。

我不知道主题本身会不会变，但我觉得那些让你改变主意或者定义什么算好的考量因素，会随着我们对技术进展的了解而频繁变化。

太棒了。

我就不继续占用时间了，让其他人也问问题。

没问题。

我这里给你准备了一些问题，Noufar。

你说话的时候我一直在记，免得漏掉。

谢谢你这么做。

好，没问题。

所以有一个提到的问题是关于“努力程度设置”的。

当你在做这个测试、使用 OpenRouter 的时候，你会不会把所有模型都设成类似的努力程度设置？

正确的回答是理想情况下会，不过有些模型之间的努力程度设置不一定完全对等。

所以如果你想更严谨一点，就尽量拿同级别的东西对比，或者直接用 OpenRouter 的默认设置。

这也是一种偷懒但可能效果不错的办法，不过我也承认努力程度设置可能会造成差异。

所以如果你想更严谨，可以随时用不同的努力程度设置跑几个模型，看看结果会不会变，因为努力程度设置的偏好，也是我希望你能在建立个人模型清单或模型配置清单时逐步摸索的一部分。

很好。

然后关于任务，我通常会把它们分成三大类：比如内容运营。

还有策略。

你在处理这三类任务时，有没有发现什么不同？还是说它们大体上都走同样的流程？

有些任务需要更复杂的配置，比如要嵌入你自己的 harness、带上你自己的上下文，还有连接器等等。

所以有几个选择：如果你确实要把一个和整体配置高度相关的任务放进 benchmark，那它就必须直接从 harness、从实际的配置环境里运行，而不是用一个只能看到简化视角的第三方 API key。

如果必须这样，那也是一种办法，就是直接通过实际工具来跑，同时确保你做了足够的匿名化处理，别自己骗自己。

或者说，如果你能为这个任务创建一个代理，不需要在实际配置里跑那些花哨的东西，那你可以尝试用这个方法去跑。

但对于运营类任务，我猜它受整体配置的影响最大，这类任务要特别小心，不能脱离实际配置去判断，因为它高度依赖你整个系统。

太棒了。

然后有人问到开源模型，问我们在测试的时候有没有天然注意到什么，显然你那边有 KIMI。

你注意到什么了吗？

还有一些关于 Mistral 的问题。

你有没有发现很大的差异？还是说你通常很乐意把开源模型和前沿模型都测一遍，然后直接做比较？

这又回到了最终标准的问题，因为如果你出于安全或公司政策原因，特别偏向开源，或者反过来特别偏向闭源，那你本身就带了偏见。

也就是说你可能会完全不纳入开源，或者主要纳入开源。

如果成本是个关键因素，那你可能会更倾向于那些便宜、同时结果也够好的模型。

而且任务本身也影响很大，因为有些任务只是门槛级别的要求，对吧？

比如写邮件草稿，或者基础研究，这些都属于门槛级任务。

对这些任务，你可能会发现任何像样的模型——比如 KIMI 及以上，或者 Mistral、GLM 及以上——你都看不出明显差别，这时候开源模型就已经足够好了。

但对于更进阶或更复杂的任务，有时候你仍然会看到商业模型和开源模型之间的差距，不过这又回到了我一开始提出的那个观点。

如果你大部分用例都追求“够用就好”，那么到目前为止，开源模型在大多数知识型工作任务上已经够用了，尤其是当它运行在一个很好的 harness 里。

很好。

另一个问题是关于如何给出指令和提示词。

这让我想起上次我们做的关于循环的线上研讨会，当时谈到什么算是好的内容，比如“如果不符合就拒绝”，因为有一些评论提到，在构建时人们注意到你有一些非常具体的指令。

在怎么做这方面，你有什么建议吗？

或者我们有没有什么资源可以帮助大家做到这一点？

所以提示词本身能帮你理清任务，而且好的提示词能起到很大的作用，尤其是在一个智能模型、一个了解你的工具里。

一般来说，它需要是可衡量的。

我们主要讨论的是智能体工具。

智能体工具的目标。

“写一篇好的博客文章”是不可衡量的。

“写一篇能让高管和普通员工都感兴趣的博客文章”就好一些；而“写一篇不包含以下内容、字数限制在多少、并包含以下部分的博客文章”就更好了，因为它高度可衡量且高度可实现。

太好了。

另外，有一个关于成本的问题，我觉得 OpenWriter 能做出这些改变很好。

在考虑切换时，关于成本方面你还有什么其他想法吗？

即使有了 OpenRadar，你能看到每个任务的成本，这很好，但关于切换的成本你还有其他想法吗？

是的。

要记住，如果你有一个慷慨的订阅方案，比如 Pro 版或 Teams 版，有些方案实际上是在隐藏或补贴更高的实际 token 成本。

所以仅仅评估成本本身并不一定是全貌。

因为，比如你每月花200美元用 Claude 或 OpenAI，你可能从 Astra 或 Fable 那里得到了超出你应得份额的所需资源，那么成本对你来说可能就不像那些按实际消耗付费的人那么重要。

所以这有点取决于你的订阅方案，而且我认为一个不错的预测是，未来可能不会一直这么慷慨，到那时我们都会关心具体成本，而不仅仅是大致范围。

但如果你即便用了慷慨的订阅方案，也经常遇到速率限制，那么成本对你就很重要，你就应该更侧重于优化成本。

所以是视情况而定的。

太棒了。

NLW，这就是我能够大致整理的所有问题了。

我不知道你还有没有其他问题。

没有了，我觉得这非常有帮助。

我认为这是那种比我们常见的操作指南类主题更需要个人深思的领域，对吧？

比如，如果其中有你觉得没用的部分，全部的意义就在于让它变得有用。

所以拒绝它，试试别的。

然后再分享回来，这样其他人也能了解情况。

我超级凭感觉，因为我什么都用，而且我经常用多个不同的模型跑同一个东西。

所以我的做法会和别人不太一样。

不过Nufar，还是要谢谢你一如既往地把这个搞出来，希望大家玩得开心。

嗯。

等我们定下来下一期内容后，记得来参加哦。

干杯。

拜拜。