23 篇博文 含有标签「evals」

构建 LLM 应用的团队总会犯同一个错误：他们等待积累足够的标注数据之后，才肯投入评估基础设施建设。他们告诉自己需要 5000 个样本，或者 10000 个。评估系统始终停留在待办事项清单上，而"感觉不错"的主观判断代替了真正的指标度量。ZenML 对 1200 个生产部署的分析发现，即便是成熟的部署，非正式的直觉判断依然普遍存在——许多团队从未真正建立起系统性的评估机制。

数据量直觉是从经典机器学习时代借来的——在那个时代，更多的标注样本确实能稳定提升模型性能。但对于 LLM 评估，这个直觉基本上是错的。对稀疏基准测试的研究表明，20–40 个精心挑选的样本就能可靠地估算完整基准的排名，而 100 个样本产生的平均绝对误差低于 1%，与使用数千个样本相比相差无几。问题不在于数据量，而在于大多数团队跳过了使小规模评估集值得信赖的结构化流程。

本文介绍这个流程的实际操作方式：如何通过主动学习选取合适的样本，如何用弱监督大规模生成噪声标签，如何借助 LLM 评判者进行冷启动，以及如何判断你的小型评估集何时可以正式使用。

你的评测套件得分 91%，但用户反映系统感觉不可靠。事后复盘发现了问题所在：你同时用 GPT-4o 来生成响应和评分。这个模型在评判自己的镜像，而它喜欢自己所看到的。

这就是裁判模型独立性问题。它比大多数团队意识到的更为普遍，产生的评分虚高幅度足以影响决策，而且修复方法既不复杂也不昂贵。但你必须知道从哪里找起。

大多数团队只有在账单出现时才会发现重试问题。智能体（Agent）“运行正常”；延迟仪表盘保持绿色；错误率看起来也没问题。然后财务部门询问为什么本月的推理支出翻了一番，这时才有人终于去翻看日志。结果发现，一个 3 步操作的智能体中，20% 的工具调用在静默重试，每次重试都重放了完整的提示词（prompt）历史记录，而账单已经连续几周在攀升。

这背后的数学逻辑并不神秘，但极其反直觉。20% 的单步重试率听起来还可以接受 —— 大多数工程师看一眼就会忽略它。但一旦考虑到现代智能体框架的重试方式，实际的 Token 成本会更接近 2 倍而非 1.2 倍。而且，这种失败模式对于团队通常关注的每一项指标都是不可见的。

重试预算（Retry budgets）—— 这是一个源自 Google SRE 工作的旧概念 —— 是最简洁的解决方案。但该模式的 LLM 版本需要调整，因为 Token 的行为方式与 RPC 不同。

你的团队花了三周时间构建了一个严谨的评估套件。它涵盖了各种边缘情况，包括对抗性示例。LLM 作为评测员（LLM-as-judge）在所有维度上的得分都达到了 92%。你发布了产品。

接着，客服工单接踵而至。用户反馈 AI “听不懂他们在问什么”。会话放弃率上升了 30%。满意度得分仅为 41%。

这种差距 —— 即评估表现与现实世界结果之间的鸿沟 —— 是当今生产级 AI 系统最常见的失败模式。这不是模型问题，而是衡量标准的问题。

一个团队使用 Claude 构建了一个 AI 研究助手。他们对 Prompt 进行了三周的迭代，向利益相关者演示了该助手，并满怀信心肠发布了它。两个月后，他们发现该助手在大约 30% 的输出中悄悄地产生虚假引用（幻觉）—— 这种失败模式之前没有人测试过，因为评估套件是在 Prompt 在演示中“感觉对了”之后才建立的。

这种模式是常态，而非例外。LLM 开发行业在很大程度上采用了测试驱动开发（TDD）的词汇 —— 评估（Evals）、回归套件、黄金数据集、LLM-as-judge —— 却忽略了 TDD 建立的最重要规则：在实现之前编写测试，而不是在实现之后。

以下是如何正确执行此操作的方法，以及 TDD 类比在哪些地方失效得非常严重，以至于字面上照搬它会让你的系统变得更糟。

Wait, I should double-check the truncate tag and headers.

大多数构建 LLM 应用的团队都会陷入两种失败模式之一。第一种是完全不建立评估（Evals），凭感觉发布功能。第二种是在还没搞清楚到底要衡量什么之前，就构建了复杂的评估基础设施。这两种都是代价高昂的错误。

表现优秀的团队有一个共同点：他们从观察数据开始，而不是从构建系统开始。错误分析优先于自动化评估。在信任任何自动评判器之前，先用人工判断为指标奠定基础。他们不把评估看作是一个需要跨越的里程碑，而是一个随着产品共同演进的持续准则。

这就是 Evals 在实践中的真实样貌——那些至关重要的决策、浪费精力的模式，以及在你被“坑”过之前都不明显的权衡。

大多数团队构建 LLM 评估器（evaluators）的顺序都是错误的。他们先写标准，然后再看数据。这种倒置是评估失准的根本原因，而且在交付首个 AI 产品的团队中几乎普遍存在。这些标准在纸面上听起来很合理 —— “回复应当准确、有帮助且简洁” —— 但当你将它们应用于真实模型输出时，你会发现评分标准（rubric）与你真正关心的内容并不匹配。你最终得到的评估器评分的是你并未衡量的内容，却漏掉了真正重要的失败情况。

解决方法不是制定更好的评分标准。而是一个不同的工作流：先看数据，再定义标准，然后在信任其进行无人值守运行之前，根据人类判断验证你的评估器。

大多数构建 LLM 系统的团队都从错误的问题开始。他们在了解系统到底哪里会出错之前，就先问“我该如何评测这个系统？”。然后，他们花几周时间构建评测基础设施，却测量了错误的东西，迅速达到了 90% 以上的通过率，最后发布了用户讨厌的产品。评测本身并没有错——它们只是没有在测量失败。

有效的评测工程（Eval Engineering）主要并不在于基础设施，而在于对你的特定系统而言，“好”究竟意味着什么，并建立精确且共识的理解。基础设施几乎是次要的。在成熟的 LLM 团队中，60–80% 的开发时间都花在错误分析和评测上，而不是功能开发。这个比例会让大多数工程师感到惊讶，直到他们将一个有缺陷的模型推向生产环境，并花了一周时间去调试到底是哪里出了问题。

每次 AI 产品演示看起来都很棒。模型生成了一些貌似合理的内容，利益相关者频频点头，每个人都带着乐观的情绪离开会议。然后产品发布了，真实用户出现了，事情开始以没人预料到的方式走向下坡路。团队手忙脚乱地修复一个故障模式，却无意中制造了另一个，经过数周的“打地鼠”后，提示词已经变成了一个 2000 个 token 的庞然大物，没人再能完全理解它了。

根本原因几乎总是相同的：没有评估系统。那些发布可靠 AI 产品的团队很早就构建了评估系统，并将其视为基础设施，而不是事后才考虑的事情。那些停滞不前的团队则将评估视为“等产品更成熟了”才需要担心的事情。到那时，他们已经陷入困境。

如今大多数使用 LLM 构建产品的团队都在重复别人一年前犯过的错误。最代价昂贵的错误就是将模型误认为是产品。

在 LLM 驱动的系统（代码生成工具、文档处理器、面向客户的助手、内部知识系统）上线生产环境一年后，从业者积累了一系列辛苦换来的知识，这些知识与炒作周期所暗示的大相径庭。这些教训不在于选择哪个基础模型，或者 RAG 是否优于微调，而在于构建可靠系统的那些枯燥工作：如何评估输出、如何构建工作流、何时投资于基础设施、何时继续迭代提示词，以及如何思考差异化。

这是对这些实战经验的总结。

大多数构建 AI 智能体的团队犯了同一个错误：他们在理解失败是什么样子之前，就开始着手评估基础设施。他们构建仪表盘、选择指标、连接评估器——然后发现他们的评估完全测量错了东西。六周后，他们得到了一份绿色的记分卡，但智能体却是坏的。

解决方法不是更多的工具。它是一系列特定的步骤，在你自动化任何事情之前，将你的评估建立在现实基础之上。以下就是这些步骤。