AI 模型评估规划指南：怎么系统测一个 LLM 或 prompt

很多团队上线 AI 功能时，质量判断停留在"这个回答感觉还行"。感觉不能复现，也无法回归。上一版好的 prompt 改了几个字之后是变好还是变坏，没人说得清。要把 AI 产品做稳，第一步不是写 eval harness 代码，而是先把评估方案规划清楚：测什么、用什么用例、按什么维度打分、跟谁比。

下面按我自己跑过的流程，讲一套可落地的 AI 模型评估方法论。

评估规划的四个产物

一份能用的评估方案，至少要产出四样东西，缺一个后面都会扯皮：

测试集：一组带输入和期望行为的用例，覆盖正常路径、风险路径和边界输入。
评分维度：每条用例按哪些维度判定通过，标准要具体到两个审核者能得出同样结论。
对比基线：新模型或新 prompt 跟谁比，是上一版、是竞品，还是人工答案。
回归记录：失败输入、实际输出、期望输出和风险标签，留着下次改动后重跑。

我习惯在写任何脚本之前先用 AI Eval 计划生成器把这四样摊开。输入功能描述、已知风险和用户路径，它会生成核心成功路径用例、风险覆盖用例、路径步骤用例和通过标准，导出 Markdown 进文档、导出 JSON 接测试工程。它本身不调模型也不打分，只负责把零散担忧整理成可审查的计划，剩下的执行还是要自己拿用例去跑模型。

设计测试集：别只测理想 prompt

测试集最容易犯的错，是只准备一条最顺的输入，跑通就觉得没问题。真实失败大多发生在交接点，而不是理想 prompt 里。一个合格的测试集应该分三层：

第一层是核心成功路径，确认基本能力没退化。第二层是风险覆盖，把每条已知失败模式变成一个具体场景，比如编造政策、不安全建议、隐私泄露、工具误用、语言错误、输出 schema 漂移，一行一个风险，生成的用例才清楚。第三层是用户路径用例，针对缺上下文、中途改目标、部分完成、人工审核这些节点单独造例子。

评分维度：把"好"拆成能判定的项

"回答质量要好"不是评分标准，是争论的起点。要把它拆成可判定的维度。以一个客服 AI 为例，我会拆成：事实正确（有没有编造政策）、安全合规（有没有给出违规建议）、完成度（有没有解决用户问题）、语气（是否符合品牌口径）、格式（输出 JSON 是否合 schema）。每个维度写明通过条件，二值或三档都行，关键是不能依赖审核者的主观感受。

写 prompt 本身这一步如果想规范化，可以配合系统提示词构建器，把角色、边界、输出格式固定下来，评分维度才有稳定的对照对象。

对比基线：没有基线的分数没有意义

单看一个 78 分没意义，要知道跟谁比。常见基线有三种：上一版 prompt（回答"这次改动是涨还是跌"）、人工标注答案（回答"离人能做到的上限有多远"）、另一个候选模型（回答"换模型值不值"）。

换模型时除了质量分，还要把成本一起算进基线对比，否则容易为了一点点准确率付出几倍的调用开销。我一般会用 LLM 价格计算器把候选模型在测试集规模下的预估成本拉出来，跟质量分放一张表里一起看。

一个真实的评估场景

举个我做过的例子：一个简历筛选助手，要判断它给出的录用建议靠不靠谱。

测试集：30 条用例。10 条正常简历（核心路径），10 条带风险（学历造假、敏感信息、跨行业转岗这类容易误判的），10 条边界（信息严重残缺、纯英文简历、格式乱码）。

评分维度：四项。建议是否有据（必须引用简历里的具体事实）、是否触发歧视性判断、信息缺失时是否如实说"无法判断"而不是硬编、输出是否符合约定字段。

对比基线：上一版 prompt 跑同一套 30 条。结果新版核心路径从 8/10 升到 10/10，但风险层从 7/10 掉到 5/10，原因是新 prompt 太自信，遇到信息残缺也强行给结论。这个跌幅如果没有基线，根本发现不了，光看新版自己的 30 条还会觉得挺好。

把评估方案沉淀成可复用资产

跑完一轮不是结束。把通过标准、失败样本和风险标签存下来，下次改 prompt 直接重跑同一套测试集，就有了真正的回归能力。团队里如果有多个 prompt 在维护，可以用提示词模板库把稳定下来的版本归档，每个版本都对应一份评估记录。

第一人称说一句：我以前最大的教训，是评分维度写得太松，两个同事对同一条输出打出完全不同的结论，整轮评估白做。后来我强制要求每个维度都写到"换个人看也会得出一样判断"才算合格，评估才开始真正帮我做上线决策，而不是给一个看着安心的数字。

AI 产品质量评估的核心不复杂：先规划，再执行。把测试集、评分维度、对比基线和回归记录这四样在写代码前定清楚，后面所有改动都有据可依。

Made by Toolora · Updated 2026-06-13