评测驱动开发（EDD）：让 AI 应用“说得清好坏“的方法论

评测驱动开发（EDD）：让 AI 应用"说得清好坏"的方法论

很多团队把 AI 功能上线当终点，结果三个月后被业务方一句"好像没上次准了"问住------翻遍日志也拿不出证据。传统软件有单元测试兜底，AI 应用的效果却飘在 prompt 和模型版本之间：改一句提示词、升一次模型，没人知道是变好还是变坏。本文聊一套在 2026 年越来越主流的做法：评测驱动开发（Eval-Driven Development，EDD）。

一、AI 应用最大的坑，是"说不清"

软件工程的信条是"可测试才能可维护"。但 LLM 应用输出是自然语言，没有非黑即白的断言。于是常见三连：靠手工试几条样例、凭感觉说"还行"、出问题再救火。EDD 的核心主张很简单------把"效果"也变成可量化、可回归的工程对象，像对待单元测试一样对待评测。

二、什么是评测驱动开发

EDD 把评测从"上线后复盘"前移到"开发时基线"。三件套：

评测集（Eval Set）：一组覆盖真实边界的输入-期望对，不追求大，追求有代表性。
指标（Metric） ：事实类用精确率/召回率，开放类用 LLM-as-Judge 给分。
回归门禁（Regression Gate）：每次改 prompt 或换模型，自动跑分，低于基线就拦下。

三、四步把 EDD 搭起来

建评测集：从线上真实 query 里挑，而非自己编。覆盖四类------典型 case、边界 case、对抗 case、历史出错 case。
定指标：能自动判的绝不人工判。选择题/抽取类直接字符串比对；生成类用打分模型，给出 1~5 分加理由。
跑分 + 门禁：接进 CI，PR 合并前必须过评测，分数回退直接标红。
迭代闭环：分数低就先定位是数据问题还是 prompt 问题，改完再跑，形成飞轮。

四、怎么搭一个"不水"的评测集

评测集质量决定 EDD 上限。用一张能力-难度矩阵组织：横轴是任务难度（检索/抽取/推理/创造），纵轴是错误代价（低/高），把 case 撒进去确保四象限都有覆盖。

python 复制代码

cases = [
    {"input": "提取合同甲方名称", "expect": "XX科技", "type": "抽取"},
    {"input": "三步解释注意力机制", "expect": None,     "type": "生成"},
]
def run_eval(respond):
    for c in cases:
        out = respond(c["input"])
        score = judge(c, out)        # LLM-as-Judge 返回 1~5
        print(f"{c['type']}: {score}")

judge 用一个强模型当裁判，比对的不是字面值而是"是否达到期望"。评测集要像代码一样版本化、随业务长。

五、落地前提与学习路线

EDD 转起来要三个前提：有持续真实流量沉淀 case、有标准化评测流水线、有"效果回退即事故"的共识。学习路线建议：先吃透提示词工程与结构化输出，再学评测框架（如 promptfoo、ragas），最后把评测接进 CI/CD，从"能跑"进化到"敢改"。

总结

EDD 不神秘，本质是把 AI 应用的效果管理工程化：基线可量化、改动可回归、问题可定位。当你的 AI 系统每一次迭代都带着分数进场，它就从"凭感觉调参"变成了"可经营的工程资产"。