评测驱动开发（Eval-Driven Development）LLM 应用怎么做？ | AI 面试题

Q: 评测驱动开发（Eval-Driven Development）LLM 应用怎么做？

一、先给出结论和背景 - Eval-Driven Development：先有评测，再谈迭代：LLM 应用是非确定性的，「感觉变好了」不可靠。EDD 把评测当成开发的方向盘，类似测试驱动开发 TDD。 - 先定义评测集与指标：- 收集有代表性的输入 + 期望输出/验收标准，覆盖典型用例、边界与历史 bug。 - 选指标：任务成功率、忠实度/幻觉率、格式合规率、相关性等。 二、拆开关键步骤和判断点 - 三种打分方式组合：- 确定性规则：能精确判定的用断言（JSON 是否合法、是否含必需字段、数值是否在范围）。 - LLM-as-judge：开放生成用强模型按 rubric 打分，需校准并人工抽检。 - 人工标注：关键/争议样本由人复核，作为金标准。 - 迭代闭环：- 改提示词、换模型、调 RAG 后跑同一评测集对比分数，用数据决定是否采纳。 三、补上落地边界和取舍 - 接入 CI 防回归：- 把评测做成可在 CI 运行的任务，PR 触发，分数低于阈值则阻断合并。 - 数据飞轮：- 把线上失败 case 持续回灌评测集，评测集越用越强。详见 LLM 评测：基准测试与对齐评估。

核心要点

先建评测集与指标，再迭代提示词/模型（评测先行，类似 TDD）
离线评测三种打分：确定性规则、LLM-as-judge、人工标注
把评测接入 CI，每次改提示/换模型自动跑，防止悄悄回归
从线上失败样例持续回灌评测集，形成数据飞轮

标准回答

一、先给出结论和背景

Eval-Driven Development：先有评测，再谈迭代：LLM 应用是非确定性的，「感觉变好了」不可靠。EDD 把评测当成开发的方向盘，类似测试驱动开发 TDD。
先定义评测集与指标：- 收集有代表性的输入 + 期望输出/验收标准，覆盖典型用例、边界与历史 bug。
选指标：任务成功率、忠实度/幻觉率、格式合规率、相关性等。

二、拆开关键步骤和判断点

三种打分方式组合：- 确定性规则：能精确判定的用断言（JSON 是否合法、是否含必需字段、数值是否在范围）。
LLM-as-judge：开放生成用强模型按 rubric 打分，需校准并人工抽检。
人工标注：关键/争议样本由人复核，作为金标准。
迭代闭环：- 改提示词、换模型、调 RAG 后跑同一评测集对比分数，用数据决定是否采纳。

三、补上落地边界和取舍

接入 CI 防回归：- 把评测做成可在 CI 运行的任务，PR 触发，分数低于阈值则阻断合并。
数据飞轮：- 把线上失败 case 持续回灌评测集，评测集越用越强。详见 LLM 评测：基准测试与对齐评估。

常见误区

⚠️ 常见踩坑

误区一：容易答偏的地方：凭感觉调提示词、无固定评测集，改 A 修好却让 B 变差却不自知；或只用 LLM-as-judge 不校准、不抽检，把不可靠的分数当真理。

追问

追问 1：EDD 和传统 TDD 有什么异同？

相同点：都先写「验收标准」再开发、用自动化跑、防回归。不同点：LLM 输出非确定，难以精确断言，评测需结合规则、LLM-as-judge 与人工，指标是分布/通过率而非单次 pass/fail，且评测集需持续扩充。

追问 2：评测集应该怎么构建和维护？

初版从真实用例、产品需求、边界条件采样，规模够覆盖关键场景即可；上线后把用户反馈和失败样例持续回灌，定期人工复核标注质量，并对评测集本身做版本管理，使其随业务演进。

🔗 相似问题

同一考点的不同问法，换着练更稳

延伸学习

按主题分类的相关资源，便于系统复习

核心要点

先建评测集与指标，再迭代提示词/模型（评测先行，类似 TDD）
离线评测三种打分：确定性规则、LLM-as-judge、人工标注
把评测接入 CI，每次改提示/换模型自动跑，防止悄悄回归
从线上失败样例持续回灌评测集，形成数据飞轮

标准回答

一、先给出结论和背景

Eval-Driven Development：先有评测，再谈迭代：LLM 应用是非确定性的，「感觉变好了」不可靠。EDD 把评测当成开发的方向盘，类似测试驱动开发 TDD。
先定义评测集与指标：- 收集有代表性的输入 + 期望输出/验收标准，覆盖典型用例、边界与历史 bug。
选指标：任务成功率、忠实度/幻觉率、格式合规率、相关性等。