为所有人辩护 AI 评估
每隔几个月，AI 工程社区就会兴起一股新的“不必费心评估”的浪潮。论点通常是：评估成本太高、过于脆弱、难以定义，对于快速迭代的产品团队来说，最终不值得投入这些额外的负担。不如发布、迭代，并相信你的直觉。
这是一个糟糕的建议，会导致劣质软件。2026 年 LangChain 的一项调查发现，只有 52% 的组织进行离线评估，而只有 37% 的组织针对实时流量运行在线评估——然而，32% 的组织将质量列为他们生产部署的第一大障碍。这并非巧合。
那些声称跳过评估的团队实际上仍在进行评估——他们只是非正式地、不一致地进行，并且无法检测到退化。内部测试、错误分类、输出审查会议：这些都是评估活动。问题不在于你是否评估，而在于你是否足够深思熟虑地进行，以便从中学习。
反对评估的论点实则是反对糟糕的评估
最常见的批评并非真正针对评估本身。它是关于团队如何实施评估：选择听起来严谨却一无所获的指标，构建评估套件通过但生产环境却问题百出，并将工程周期投入到从未能揭示可操作信号的基础设施上。
这些都是真实存在的问题。通用指标——“帮助性分数”、“相关性”、“连贯性”——产生的数字几乎没有任何用处。团队优化分数，发布，结果用户仍然抱怨全新的故障模式。评估通过了，因为它们测试的是系统说了什么，而不是它实际做了什么。
答案是更好的评估，而不是没有评估。因为一些实现很糟糕就放弃系统性的质量测量，这就像因为你见过不稳定的单元测试而放弃它们一样。
你已经在进行评估
对你团队的质量保证流程进行任何诚实的盘点。你可能：
- 在发布提示词更改前审查模型输出
- 发布后监控错误率和投诉工单
- 定期阅读对话或完成文本样本
- 有内部高级用户对边缘案例进行压力测试
所有这些都是评估。这与“运行评估”的区别在于结构：你是否提前定义故障模式，你是否持续抽样，你是否跟踪故障率随时间的变化。
拥有深厚领域专业知识和严格内部测试的团队可以采用更轻量级的正式评估基础设施——但前提是他们对抽样和分析真正做到严谨。这是例外，而非规则。对于大多数产品团队来说，隐性评估过程存在足够大的盲区，以至于严重的退化未被发现。
何时可以负担更轻量级的评估
在以下两种情况下，不那么严格的评估是站得住脚的：
基础模型后训练充分覆盖的任务。 代码生成、基本摘要、在成熟领域遵循指令——基础模型在训练期间会遇到大量的这类任务，公共基准测试提供了关于模型是否能处理这些任务的合理信号。如果你的应用程序恰好处于这个领域，你可以更多地依赖模型级基准测试，减少在定制评估基础设施上的投入。
反馈循环紧密且具备真正领域专业知识的小团队。 一个只有两人的团队，两位创始人都是深耕领域的专家，亲自审查每一个输出，并向已知用户增量发布——他们将通过紧密接触发现大部分问题。随着团队壮大或用户群多样化，这种方式会迅速失效。
在这些情况之外，跳过评估是一种会不断累积的债务。每一次模型更新、每一次提示词更改、每一次检索配置调整都会在没有基线可供比较的情况下投入生产。
评估不可协商的场景
复杂的文档处理和分析是最明确的案例。当你的系统从法律文件中提取实体、分类政策违规或汇总医疗记录时，故障模式众多，错误后果严重，再多的非正式审查也无法捕捉到长尾问题。
多步骤智能体管道也类似。一个单一的管道可能涉及检索、上下文推理、工具调用 和输出格式化——每个都是潜在的故障点。一个通过了你的输出质量检查，但在进行细微错误工具调用时却成为一个定时炸弹的智能体，你需要对每个步骤进行评估，而不仅仅是最终输出。
经验法则：问问你的瓶颈是规范（你没有清楚地定义什么是好的）还是模型能力（模型无法可靠地执行你需要的任务）。当答案是能力时，评估最为关键——因为那时你需要衡量改变是否真的带来了进展。
投资回报率最高的评估实践：错误分析
在构建评估基础设施之前，请进行错误分析。它是 AI 产品开发中回报率最高的活动，但大多数团队过快地为了自动化而跳过了它。
流程如下：
- 收集 100 个多样化、真实的轨迹。 不是手工制作的例子——而是实际的用户交互或输入分布中的代表性样本。
- 阅读它们。全部阅读。 手动识别系统在哪里失败以及原因。
- 构建故障分类法。 一组小而连贯、不重叠的二元故障模式：系统是否幻觉出引用了？它是否误解了用户的意图？它是否产生了结构正确但事实错误的答案？
- 量化每种故障模式。 现在你知道该投资哪里了。
这个过程需要一两天。它将比你在一周内设计的任何自动化指标更能揭示系统真正的弱点。最重要的是，它为你提供了编写真正衡量重要事物的评估所需的定义。
LLM 作为评判者：扩展你的评估预算
一旦你定义了故障模式，LLM 作为评判者就能让你廉价地扩展评估。模式很简单：向评判模型提供输入、输出，以及从你的故障分类法中得出的评分标准，并要求它进行评估。
如果做得不谨慎，这会引入其自身的可靠性问题。评判模型存在偏见——它们倾向于偏爱较长的输出、听起来权威的输出以及与评判模型同系列的输出。以下是减少这些偏见的技术：
- 思维链评分：要求评判者在评分前进行推理，而不仅仅是输出一个数字
- 基于参考的评估：提供正确输出的示例进行比较，而不是让评判者孤立地评估
- 位置交换：对于成对比较，以两种顺序运行评估并取平均值
- 针对故障模式的评分标准：每种故障模式一个评分标准，而不是一个用于“质量”的通用标准
实际回报是显著的。团队报告称，与大规模人工审查相比，成本降低高达 98%。更重要的是，它让你能够对每一次提示词更改都运行评估套件，而不是将评估批量化到发布周期中。
经久不衰的产品有何不同
经受住模型更新、竞争压力和用户群增长考验的 AI 应用有一个共同特点：构建它们的团队能够衡量发生了什么变化以及原因。他们能够告诉你哪个提示词修订改进了关键故障模式的提取准确性。他们能够捕捉到模型更新何时导致之前可靠的行为退化。
这不是拥有研究预算的复杂机器学习团队的专利。它源于纪律：定义何为“好”、抽样真实数据、阅读输出，并建立反馈循环，让你能够基于证据而非直觉进行迭代。
评估不是发布速度的负担。它们是使发布可持续进行的机制。
