Hex用评估驱动AI功能开发：错误率从21%降至3%

Hex 的生成式应用让你可以通过与 Hex 智能体聊天来构建完全自定义的数据应用。上周我们推出了 快速编辑，它使用一个小模型让你以比完整智能体快 20 倍、成本低 20 倍的速度重新设置图表样式。

我们使用评估在 Hex 构建 AI 功能已有一段时间。当模型输出是非确定性的时，它们是判断一项更改是否真正让功能变得更好的唯一可靠方法。我们在快速编辑上采取了不同的方法：我们从一开始就用评估来驱动其开发，而不仅仅是在最后作为 QA 步骤。

最初，我们编写了几百个评估用例，随着功能的演进，最终创建了总共 1,800 个用例。然后编码智能体针对这些评估测试了数百项更改，只保留得分更高的那些。这个过程称为爬山法，将我们的错误编辑率从 21% 降到了 3%。令人惊讶的是，大部分收益来自模型周围的测试框架，而不是提示词。

如果你有兴趣采取类似的方法，Anthropic 的 评估设计与爬山法指南是一个很好的起点。以下是我们在他们分享内容之外发现对我们有效的方法：

从产品体验出发

该功能如何工作

快速编辑使用一个小模型（GPT-6 Luna/Claude Haiku 4.5）来读取用户的请求——"把 Enterprise 那条线变成绿色"——并一次性提出对图表属性的编辑建议。

如果用户的请求太复杂——"为什么数字没有上升？？？让它们上升！"——它会移交给 Hex 智能体，后者可以对应用进行更复杂的更改。

我们的评估专注于确保小模型正确处理这些编辑和移交。

选择正确的优化指标

我们的功能——因此也是我们的评估——可能以两种方式失败：

• 错误编辑：进行了用户没有要求的编辑。
• 错误移交：将本应由小模型处理的请求移交给了 Hex 智能体。

人们很容易想要同时最小化这两类失败，并最大化整体通过率。但对于这个功能来说，对我们更重要的是最小化错误编辑，而不是错误移交。

错误编辑会以用户没有要求的方式改变他们的图表，这很突兀并会侵蚀信任。错误移交只是导致主智能体更慢地做出正确编辑，这没那么糟糕。

例如，我们采用了 GPT-6 Luna，尽管它的整体通过率比 GPT-5.6 Luna 低约 1 个百分点，因为它的错误编辑少了 20%，而成本只有一半。

当我们开始爬山时，我们的"错误编辑"率是 21%，到最后是 3%。在我们的客户实际使用中，我们预计错误编辑率会远低于此——我们有意让我们的评估尽可能具有挑战性。

从真实使用中编写评估，然后扩展

丰富的评估用例

我们构建了一套超过 1,800 个评估用例，最初从内部用户真实的图表编辑请求中提取了几百个。我们想要人们所要求的那种编辑示例，以及他们使用的具体词语（和语言）。

我们扩展了这些核心用例，以覆盖我们想要处理的所有不同类型的图表编辑（和移交）。

我阅读了最初约 150 个合成用例并给出了反馈，这足以让 LLM 出色地合成其余部分。

我让 GPT-6 Astra 生成新用例，并使用 Claude Fable 5.1 填补任何空白。使用多个模型让我们确信这些示例是多样且全面的。

我们确保许多测试用例是困难和模糊的，这给了我们更多爬山法的空间。我们想测试模型是否能分辨哪些请求应该自己处理，哪些应该移交。几个例子：

• "让它更抢眼" → 移交（没人知道这是什么意思，包括模型）
• "把它改成每周" / "hazlo semanal" → 移交（那是伪装成样式更改的数据更改）
• "隐藏图例并只显示 2025" → 移交，即使其中一半是可以做到的（部分编辑比不编辑更糟）
• "把所有线条都变成灰色，除了 Canada，隐藏图例并把线条加粗" → 应用全部三项（并且不要碰 Canada 的颜色）
• 在水平条形图上"将 Y 轴格式化为美元" → 移交（因为那里的 Y 轴是类别轴）

处理夹具

每个评估用例都包含"用户请求"和"夹具"——关于图表的上下文，我们将其与用户请求一起发送给模型。

对于这个功能，夹具以 JSON 表示图表的起始状态，包括之前的编辑，以处理像"不，我更喜欢旧颜色"这样的提示。

像这样的夹具可能出奇地复杂和详细，并且更难制作。我们使用了约 50 个基础图表，带有许多变体和编辑历史，再次受到真实使用的启发并由 Astra/Fable 扩展。

测试框架比提示词更重要

验证器 > 提示词

验证器是检查并清理模型输出、然后我们才用它来编辑图表的代码。

例如，模型可能返回正确的十六进制颜色，但遗漏了我们代码期望的引号。我们之前会拒绝这些响应，即使模型已经理解了请求。我们更改了验证器以接受它们。

令人惊讶的是，我们超过 50% 的爬山改进来自扩展验证器以处理更多几乎正确的输出，例如：

• 修复小的格式错误，比如缺少引号，或返回值类型错误
• 将数字舍入到最接近的允许值

验证器还执行模型可能弄错的规则：最小值低于最大值、ISO 日期、某个属性是否真的能在该图表上生效……

验证器改进将 Luna 上的通过率提高了 7 个百分点，Haiku 上提高了 10 个百分点。它们将 Haiku 的硬错误（我们的代码无法接受的输出）减少了 99%！

我们学到的一个反直觉的教训是，提示词的更改远没有我们预期的那么有影响。绝大多数纯提示词微调都未能通过我们的评估。事实上，我们最终把一些东西去掉了提示词中的内容，并将它们放入验证器，或放入模型读取的图表属性描述和标签中。

例如，模型经常混淆水平图表的坐标轴。在相关属性标签中加入“(x 轴)”并改进其描述，帮助它选择了正确的设置。我们此前无法通过修改提示词来解决这个问题。

处理不同模型

我们同时评估了 Luna 和 Haiku，以确保任何调整都能在多个提供商的多个模型上良好运行，保证该功能在我们的客户群中无论他们使用何种模型配置都能正常工作。

例如，我们最初有一个“无更改”选项，让模型可以表示图表已经符合请求。Luna 处理得很好，但 Haiku 过度使用它，错误的“无更改”响应比正确的多出 30 倍。这是另一个我们无法通过提示词修复的行为的例子；我们移除了该选项，并将这一逻辑推入验证器中。

确保改进是真实的

用“留出”案例避免过拟合

根据我们的经验，至关重要的是要对执行爬山优化的智能体隐藏相当数量的评估案例，以免它过拟合（针对你的评估过度优化）。没有这些留出案例，就像学生死记硬背练习测试的答案。他们可能在这项测试中拿满分，但当题目变化时就会吃力。

我们的留出案例几乎占评估套件的 40%。我们只在留出结果改善时才接受提议的更改。

调整噪声与尝试次数

你还需要考虑确保高质量评估数据需要付出什么。在我们的案例中，我们发现每个案例只运行 3 次尝试噪声太大。重新运行同一套件的差异约为 8 个错误编辑。每个案例 10 次尝试对我们来说是恰到好处的平衡点，将留出噪声降低到 0.2 个百分点。

值得让智能体重新运行相同的评估集几次，看看在更改任何内容之前结果有多大差异。

快速评估意味着更快的产品迭代

即使每次完整运行有 18,000 次尝试（1,800 × 10），在 Luna 上运行一次成本不到 10 美元，在高并发下只需几分钟。

这意味着评估不仅仅是最后一步。我们对功能每个部分的每一次更改后都会运行它们：提示词、验证器、图表属性、交接规则、用户体验。

在爬山优化运行期间，我们在十天内三次更改了图表的底层属性。每次我们都重新运行套件，能够立即看到是否有任何东西被破坏或需要改进。

反过来也成立。当模型一直把某件事弄错时，修复往往不在提示词中。我们重命名一个属性、添加一个描述，或更改一条交接规则，然后重新运行以检查它是否有帮助。

我们同时针对相同的评估，对 AI 和功能的其余部分进行迭代。

产品体验应该驱动你的评估

我们将评估案例、测试数据、用于爬山优化的指标以及其他一切都植根于我们今天看到人们使用 Hex 的方式，以及我们想要为他们实现的产品体验。

所以，如果你正在构建评估，我的总体建议是仔细思考那种产品体验，并以此为基础设计你的评估。

（另外，欢迎复制这篇文章并将其粘贴到你的智能体中，这样它也能利用我们学到的东西。）