devgo.cn你精心设计了一个基于大语言模型（LLM）的客服助手，Prompt写了十几版，模型选了最强的那款，上线后用户却反馈"回答不准确""语气不对"。你检查自动化测试，发现"帮助性"指标得分很高——问题出在哪？因为你的评估指标没有捕捉到真正的失败模式。Airbnb在将生成式AI（GenAI）集成到评论摘要、智能客服、房东沟通工具等产品时，也遇到了同样的困境。他们发现，如果不把评估当作第一等工程实践，就会陷入三种陷阱：虚假自信（通用指标得分高但没抓住实际失败模式）、遗漏回归（Prompt改动悄悄降低了某个未测量的维度）、浪费精力（构建的评估管道与真实结果不相关）。为此，他们总结了一套名为"评估驱动开发"（Eval-Driven Development, EDD）的方法论，核心是把评估从事后补丁变成驱动开发的引擎。
EDD的灵感来自测试驱动开发（TDD），但针对GenAI的非确定性做了调整。它包含五个原则，这些原则不是凭空产生的，而是从实际数据探索中涌现的。提前定义目标和门禁——在项目启动时就明确优化什么、上线前必须满足什么条件，这些答案可能随着数据探索而演变，但必须有一个起点。让真实错误指导指标——不要凭空发明评估指标，而是从实际观察到的失败中提炼，与跨职能伙伴共同开发。保持评估器集小而精——3-5个精心校准的LLM-as-Judge（用更强的大模型评估另一个大模型的输出）评估器胜过20-30个噪声大的，每个评估器只针对一个具体的正确性维度，比如语气、连贯性、忠实度等。指定决策者——团队讨论什么是"正确"，但最终需要一个人拍板，避免无休止的争论。持续协作——让产品伙伴定期回答"A比B好还是差？"和"这个输出到底哪里不对？"，将评估融入日常开发流程。Airbnb特别强调一条黄金法则：拿不准时，去看你的数据。手动检查100个输出，阅读追踪信息，找到模型的错误，分类它们，然后建立评估器。这个习惯比任何框架都重要。
Airbnb将评估方法分为三层，形成一个金字塔，每层有不同的成本和精度。底层是程序化检查（Programmatic Checks），用确定性代码快速过滤明显错误，比如通过JSON Schema（一种定义JSON数据结构的规范）强制结构化输出，而不是依赖Prompt指令——后者容易破坏下游数据管道。这一层成本最低，应该作为第一道防线。中间层是LLM-as-Judge（虚拟法官），用一个更强的LLM按照精心设计的评分标准评估另一个LLM的输出，用于衡量语气、连贯性、忠实度、相关性等细微质量。顶层是人工评估（Human Evaluation），作为黄金标准，用于高风险场景和解决自动评估器之间的分歧。
LLM-as-Judge听起来简单，但评分标准的设计至关重要。模糊的标准（如"可读性是否达标"）会让LLM无所适从。Airbnb给出了一个具体例子：评估房源解释的可读性，标准包括语气像友好的旅行顾问（温暖但专业）、不使用内部术语、格式正确（无引号、无感叹号）、语法自然、用词简单。评分只有1或0，并附带原因。这样的标准才能让LLM一致地打分。他们强调，如果人类都无法一致应用的标准，LLM更不可能。虚拟法官的输出格式也必须严格，比如只返回一个包含原因和分数的JSON对象，以便下游解析。
但虚拟法官如果不校准，比没有更糟——它会给你虚假自信。校准步骤包括：创建50-100条黄金数据集（必须包含坏例子，不能只有好例子），让虚拟法官对黄金集打分，测量与人工标注的一致性（目标80%-90%以上，可用Cohen's kappa或Krippendorff's alpha——衡量分类一致性的统计指标），分析分歧并优化Prompt和few-shot示例，然后重复循环直到达标。随着失败模式的演变，需要定期重新校准。Airbnb指出，完美一致不可能达到，因为人类之间也存在分歧，但高80%-90%的一致性是一个务实目标。
人工评估虽然资源密集，但仍是确定地面真相的最终手段。Airbnb建议从20-100条由领域专家标注的样本开始，只有当评分标准非常稳固且数据量很大时，才扩展到规模化标注团队。他们的一条经验法则是：先用少量专家标注建立直觉，再考虑扩大。在评估场景的选择上，他们推荐根据任务类型混合使用三种方法，比如程序化检查用于格式验证，LLM-as-Judge用于质量评估，人工评估用于边界情况。
这套方法的核心启示是：评估不是项目的附属品，而是产品开发的主线。对于任何构建LLM应用的团队，都可以从一个小循环开始——构建原型、跑100个例子（合成数据也可以）、阅读输出、阅读追踪（trace）找到模型的错误、分类错误、建立评估器。不要一开始就追求完美的评估体系，而是让评估随着你对失败模式的理解而进化。记住那条黄金法则：拿不准时，去看你的数据。这种"评估驱动开发"的思维，能帮你避免在错误的方向上浪费资源，真正构建出用户信赖的GenAI产品。它适用于任何LLM应用场景，从客服到内容生成，从代码助手到数据分析。但也要注意，没有放之四海皆准的方案，每个团队需要根据自己的领域和失败模式调整评估策略。
内容与图片版权归原作者所有 · 原文: https://medium.com/airbnb-engineering/eval-driven-development-lessons-from-evaluating-genai-at-scale-e817e5ae5788?source=rss----53c7c27702d5---4