大家好，我是Filipe，亚马逊AGI实验室的技术团队成员。我的职责是协助构建下一代产品项目。今天我将分享如何设计能赢得客户信任的迭代评估体系（Evals）。去年三月，我们推出了Nova研究预览版。Nova是一款帮助构建浏览器代理的工具，可自动化网页操作任务。我们的主要目标是通过产品发布获取大量客户反馈。七月时，我们优化了开发者体验；十二月则在AWS上正式推出服务，使其成为构建生产级代理的一流平台。在此期间，我主要负责客户赋能工作，即与客户紧密合作以理解并解决他们的问题。

大家可能习惯于基于基准测试（Benchmarks）构建AI产品，无论是公开基准还是自创的合成数据。虽然目标是优化这些指标，但一旦上线生产环境，客户往往会尝试模型未预期的操作并导致产品崩溃。这是因为我们大多使用静态评估（Static Evals）。传统流程中，我们在开发阶段运行测试并优化指标后便直接发布。然而，静态评估无法反映客户在真实场景中的行为差异，导致产品在实际使用中失败。这揭示了基准测试的局限性：它无法捕捉生产环境中客户实际使用方式的动态变化，从而产生预期与现实的差距。

解决这一问题的关键不在于追求更完美的基准测试，而在于建立“客户闭环”。我们提出了一个评估飞轮模型。第一步是定义成功标准，但这并非由工程师决定，而是基于客户认为的成功是什么。第二步是捕捉信号，除了收集遥测数据和指标外，必须与客户面对面交流以深入理解其真实需求。第三步是诊断差距，将收集到的信号分类为模型缺陷、工程Bug或产品定位问题。最后将这些发现反馈给科学、工程和产品设计团队进行优先级排序和修复，并不断重复这一循环。

在实验室中反复执行此飞轮后，我发现客户在使用产品时会经历不同的阶段。首先是“用例发现”，即初次接触时理解客户的痛点。随着客户深入使用产品，他们会经历四个学习阶段：首先是发现用例；其次是理解产品的能力边界与限制；第三是掌握如何高效利用产品功能以最大化价值；最后是探索创新用法，将产品融入更复杂的业务流程中。识别这些阶段有助于我们针对性地提供支持和优化评估体系，从而持续增强客户信任并提升产品价值。

解决客户的问题，并确保你所构建的产品能真正解决这个问题。随后，你会拥有一批早期采用者。从这些早期采用者那里，你获得的主要信号是“什么是可能的”。这是客户会尝试各种疯狂用法的阶段。你会发现一些你完全无法帮助他们的情况，但也会发现客户利用你的产品解决了许多问题，而且往往令你惊讶，因为那是你从未想象过的场景。

第三点在于开始规模化扩张时。在拥有早期采用者后，你开始扩大规模，获得更多客户，并能够识别出一些模式。这些模式基本上就是你的“核心用例”，即每个人都在使用你的产品来解决的问题和场景。最后一点更具前瞻性，涉及“产品缺口”。在与早期采用者合作及规模化过程中，你会发现产品的不足之处。你的产品团队可以帮助优先处理这些问题，这些缺口决定了你未来的开发方向，即接下来应该构建什么功能。

正如我所述，在此过程中我与多位客户合作，有一些心得想要分享，有些可能显而易见，但其他则极具洞察力。首先是“信任悬崖”，我喜欢这样称呼它。想象你构建了一个产品，准备发布并衡量其可靠性为80%。这看起来不错，你认为可以交给客户使用。但当你告诉客户产品有80%的可靠性时，客户的想法是“我无法信任这个产品”。

为什么？因为当显示80%的可靠性时，客户会想：“既然只有80%，我仍然需要监控这个智能体。如果它失败了，我需要做一些手动工作。”事实上，这反而增加了他们的工作量：他们需要构建智能体、监控它，并在出错后手动干预。然而，当可靠性达到90%左右时，传递给客户的信息就变了：“好吧，90%，我可以信任它来处理我的任务。”

此时，你可以完全将工作流交给客户。因此，可靠性本质上是“零和一”的关系：要么信任，要么不信任，中间没有过渡地带。第二个心得是“评估透明度”。每次与客户合作时，你必须对产品做的三件事保持透明。第一件很简单：展示“什么有效”。你向客户证明你在某些方面做得很好，达到了一定的可靠性水平。

你可以信任我的产品，使用我的智能体就能获得所需的可靠性。第二点是“我正在改进什么”。告知客户你知道存在某些差距，但目前正投入时间进行优化。第三点是最难的：“什么不在范围内”。没人喜欢这样做，但必须透明地告诉客户产品无法处理的情况。不要让客户去尝试那些无效的功能，否则他们会转向竞争对手。

这里的主要心得是：对产品局限性的透明比更高的基准测试分数更能增加信任。这是一个非常有趣的发现，了解产品能做什么以及更重要的是不能做什么，是赢得客户信任的关键。第三个心得是：如果你与客户紧密合作，可能会发现许多意想不到的用例。例如亚马逊的Leo卫星互联网项目。

在与他们合作时，我们学到了关于缓存轨迹以创建功能的输入信息。与其一直进行推理运算，他们选择使用我们的产品的同时缓存轨迹；如果失败，再回退到模型。这为他们优化了成本。第二个心得来自汽车租赁公司赫兹（Hertz）。他们使用我们的产品质量保证自动化，我们发现他们的QA工程师中有些技术很强，能编写Python脚本；但另一些则不具备同等技术水平。

这一洞察促使我们为产品构建了一套完整的非技术用户体验，以便让更多客户能够使用它。最后一个例子是一家名为Sol的初创公司，这是一家RPA（机器人流程自动化）公司。他们为其他公司提供自动化工具来执行重复性任务，因此用例种类繁多。我们从中学到的是，可以为产品增加额外的灵活性，特别是执行堆栈的可定制性，以满足他们的需求。

这些心得的重要性在于提醒我们：通过与客户的互动，你会深入了解他们试图做的事情以及接下来应该构建的功能。通过多次运行这个飞轮模型，我们总结出了四个原则：第一，从生产环境而非想象中衍生评估场景。虽然创建合成数据在初期很重要，但一旦获得客户信号，务必将其反馈到评估中。

第二，分类为可操作的领域。区分产品问题、工程问题和研究问题，并确保团队优先处理这些问题。第三，诚实地共享能力。透明建立信任，务必向客户分享产品的不足之处。第四，尽可能快地运行飞轮。你跑得越快，产品改进就越快。这一点看似显而易见，但务必牢记：加速飞轮运行能让评估每周变得更智能。

如果没看到评估能力每周提升，说明你的评估已经过时了。最后分享两个想法。

最后，我想让大家记住两点核心观点。第一，评估体系必须反映客户真正关心的事情，而不是你认为他们关心的内容。关键在于获取客户的反馈，并确保你的评估标准能够准确反映他们的实际痛点和问题所在。

第二，评估体系不是一次性构建完成的静态产物，而是一个随着客户发展而不断演进的飞轮。需要特别注意的是，客户的旅程是动态变化的：当客户在使用产品的过程中不断深入时，他们试图通过产品完成的任务也会随之改变。例如，随着使用场景的复杂化，需求会变得更加多样和深入。

因此，你的评估体系必须保持实时更新，精准反映客户当前正在尝试完成的具体任务和行为。基于此，你需要做的是构建一个持续迭代的闭环机制：确保评估体系能够随着产品演进而不断进化，从而赢得客户的信任。以上就是我今天分享的全部内容。非常感谢大家的参与。会后我会在展位停留一段时间，欢迎大家继续交流讨论。再次祝愿大家在会议中收获满满。