1. 为什么我要用 Claude 来设计 eval而不是自己硬写做模型应用的人迟早会撞上一堵墙你觉得自己把 prompt 调得挺好了上线之后用户随便换个问法输出就开始飘。更麻烦的是你根本不知道它飘了多少、飘在哪里、下次改完 prompt 到底是变好了还是变差了。没有 eval调 prompt 就像闭着眼睛开车——方向盘打得再猛也不知道自己是在往哪偏。我最早做 eval 的方式特别原始手写几十条测试用例跑一遍人眼看输出觉得差不多就过了。这套方法在项目早期还能凑合一旦用例上到两三百条人眼根本看不过来而且判断标准会随着疲劳程度漂移。上午觉得这个回答可以下午再看同一段输出又觉得不行。这种主观性极强的评估本质上没有复现性团队里两个人对同一个结果能吵起来。后来我把 eval 的设计工作交给了 Claude。注意不是让 Claude 去当裁判打分而是让它帮我设计评估体系本身——包括拆解评估维度、生成测试用例、写打分脚本、分析失败模式。这个分工很关键Claude 擅长的是把模糊的需求结构化而不是替你做最终判断。评估的尺子得你自己定但让 Claude 帮你把尺子刻出来效率能翻好几倍。这套方法适合谁如果你正在做基于大模型的问答、摘要、代码生成、客服机器人这类应用手里有一批真实用户 query但不知道怎么系统性地衡量效果那这套流程可以直接抄。哪怕你只有几十条用例用这套思路也能把评估做得比现在扎实得多。核心关键词就三个eval 设计、Claude 辅助、分数爬坡。下面我一步步拆。2. 整体思路把 eval 拆成四层让 Claude 逐层帮你搭2.1 先想清楚 eval 到底在评什么很多人一上来就让模型“给这个回答打个分”这是最粗糙的做法。一个回答好不好至少涉及四个层面事实准确性有没有胡说、指令遵循度有没有按格式和要求来、完整性该说的点有没有漏、表达质量读起来顺不顺、有没有废话。这四个维度混在一起打分最后你只知道“总分 7 分”但不知道是哪里扣的分改 prompt 的时候完全没有方向。我的做法是先把维度拆开每个维度单独定义评分标准。比如事实准确性可以分三档完全正确、部分正确但有遗漏、存在明显错误。指令遵循度可以分完全符合格式、格式有小瑕疵、格式完全不对。拆到这个粒度Claude 才能帮你写出可执行的打分逻辑而不是笼统地“感觉一下”。这里有个经验维度不要超过五个。我试过拆到七八个维度结果打分脚本复杂到没人愿意维护而且很多维度之间高度相关拆了等于没拆。四到五个维度是甜点区既能定位问题又不至于让评估本身变成负担。2.2 让 Claude 生成测试用例而不是自己憋测试用例的质量直接决定 eval 的可信度。自己憋用例最大的问题是覆盖不全——你会不自觉地围绕自己熟悉的场景出题忽略掉那些边缘但真实存在的输入。Claude 在这件事上的价值在于它能基于你给的业务描述快速铺开一个用例矩阵。具体操作是把你产品的功能描述、目标用户、典型使用场景喂给 Claude让它按“正常场景 / 边缘场景 / 对抗场景”三类分别生成用例。正常场景就是标准问法边缘场景是那种模棱两可、信息不全的输入对抗场景则是故意诱导模型出错的输入比如让它编造不存在的事实。这三类用例的比例我一般控制在 5:3:2正常场景占大头保证基础盘对抗场景少而精专门用来暴露弱点。生成完之后一定要人工过一遍。Claude 生成的用例里会有重复的、不切实际的、或者答案本身就有争议的。我通常会删掉 20% 到 30%再手动补几条 Claude 没想到的。这一步不能省用例是 eval 的地基地基歪了后面全白搭。2.3 打分逻辑规则优先模型兜底打分这件事能用规则就别用模型。比如格式检查、关键词是否出现、长度是否超标这些用代码几行就能搞定又快又准。真正需要模型判断的是那些主观维度比如“这个解释是否清晰”“这个摘要是否抓住了重点”。我的打分架构是这样的先跑一遍规则检查把格式类、硬性要求类的分数算出来剩下的主观维度再交给 Claude 按预设的评分标准逐条打分。这样既保证了硬性指标的确定性又保留了主观评估的灵活性。而且规则部分的分数是 100% 可复现的模型打分部分即使有波动也不会影响整体评估的稳定性。注意让模型打分时一定要把评分标准写死在 prompt 里并且要求它输出打分理由。没有理由的分数没法复盘出了问题你都不知道它为什么给这个分。2.4 分数爬坡一轮只改一个变量eval 搭好之后就进入爬坡阶段。这里最大的坑是一次改太多东西。你同时改了 prompt、换了模型、调了温度参数分数上去了但你不知道是哪个改动起了作用。正确的做法是每轮只动一个变量跑完 eval 看分数变化确认有效再动下一个。我一般把爬坡分成三个阶段第一阶段修硬伤把格式错误、事实错误这类明显问题先解决掉这阶段分数涨得最快第二阶段抠细节优化表达、补全遗漏点分数涨幅会放缓第三阶段对抗优化针对对抗场景做专项提升这阶段最费劲但能把 eval 分数推到比较高的水平。每个阶段跑完都要存档记录改了什么、分数从多少到多少方便回溯。3. 核心细节Claude 设计 eval 时我踩过的那些坑3.1 评分标准要可操作不能是形容词堆砌我第一版评分标准写的是“回答要准确、完整、清晰”。Claude 拿到这个标准之后打分打得特别随意同一个回答两次打分能差两分。问题出在“准确”“完整”“清晰”这些词太虚了模型没法稳定地映射到具体判断上。后来我改成可操作的描述。比如“准确”改成回答中的每个事实性陈述都能在给定资料中找到依据若出现资料中没有的信息标记为事实错误。“完整”改成回答覆盖了问题涉及的所有子问题每遗漏一个子问题扣一分。“清晰”改成回答使用了分点或分段结构没有超过三行的连续长句。改完之后打分的稳定性明显提升同一个回答多次打分基本能稳定在同一档。这个经验很通用任何交给模型执行的判断标准都要能翻译成“看到什么就扣分”的具体规则。形容词是给人看的规则才是给模型看的。3.2 用例要带参考答案但参考答案不是唯一解设计用例时我一开始只写问题不写答案结果模型打分时没有参照只能凭感觉。后来我给每条用例都补了参考答案但很快发现另一个问题模型会把参考答案当成唯一正确答案稍微不一样的表述就判错。解决办法是在参考答案里注明“核心要点”和“可接受的变体”。比如问“如何重置密码”核心要点是“进入设置-账户-安全-重置密码”可接受变体包括“通过登录页的忘记密码链接”等。打分时只要命中核心要点就算对变体不扣分。这样既保证了评估有锚点又不会把合理的多样性误判为错误。3.3 对抗用例要真对抗不能只是换个说法我见过很多人的对抗用例其实就是把正常问题换个问法比如“请告诉我 X”改成“你能说一下 X 吗”。这不叫对抗这叫同义改写。真正的对抗用例是那些故意触发模型弱点的输入比如前提错误的输入“既然 X 已经被证明是错的那 Y 是不是也错了”X 其实没被证明是错的信息不全的输入“帮我处理一下那个东西。”没有上下文诱导编造的输入“请给出 X 在 2023 年的具体数据。”X 可能根本没有公开数据超长输入的边界测试把问题塞在几千字的无关文本中间这类用例才能真正暴露模型的短板。我一般会让 Claude 专门生成一批对抗用例然后人工筛选保留那些确实能难住当前模型的。如果一条对抗用例模型轻松答对说明它不够对抗可以删掉或者加难度。3.4 打分脚本要能定位到具体失败点eval 跑完只给一个总分价值有限。我要求打分脚本对每条用例输出总分、各维度得分、扣分理由、原始输出。这样跑完一轮我能直接筛出“事实准确性扣分最多”的用例集中看这些用例的输出很快就能发现模型在哪个类型的问题上容易出错。这个定位能力是爬坡的关键。没有它你只知道分数低不知道低在哪改 prompt 只能瞎猜。有了它你能精准地知道“模型在处理否定句时容易理解反”然后针对性地在 prompt 里加一条“注意否定词”的说明。4. 实操全流程从零搭一套能爬坡的 eval4.1 第一步定义评估维度和评分档位先拿一张纸或者文档把你的评估维度列出来。我以问答场景为例列四个维度维度权重评分档位事实准确性40%3完全正确2部分正确有遗漏1存在事实错误指令遵循度25%3完全符合格式2格式有小瑕疵1格式错误完整性20%3覆盖所有子问题2遗漏一个1遗漏两个以上表达质量15%3结构清晰无废话2基本可读1混乱或冗长权重根据业务重要性来定。事实准确性通常权重最高因为错了就全错了。表达质量权重最低因为它是锦上添花不影响核心信息传递。这个权重表不是拍脑袋定的你可以让 Claude 基于你的业务场景给个建议然后自己微调。4.2 第二步用 Claude 批量生成测试用例把下面这段 prompt 喂给 Claude你是一个测试用例生成专家。我的产品是一个[产品描述]目标用户是[用户描述]。 请生成 50 条测试用例按以下比例分布 - 正常场景 25 条标准问法信息完整 - 边缘场景 15 条信息不全、模棱两可、多轮对话中的追问 - 对抗场景 10 条前提错误、诱导编造、超长输入、否定句陷阱 每条用例输出格式 问题[具体问题] 类型[正常/边缘/对抗] 核心要点[回答必须包含的要点] 可接受变体[其他合理的表述方式]生成完之后人工过一遍删掉重复和不合理的补上你从真实用户日志里摘出来的典型问题。最终保留 40 到 60 条这个量级既能覆盖主要场景跑一轮的时间又不会太长。4.3 第三步写打分脚本规则和模型混合打分脚本分两部分。规则部分用 Python 写检查格式、关键词、长度这些硬性指标def rule_score(answer, case): score 0 # 检查是否包含核心要点 for point in case[core_points]: if point in answer: score 1 # 检查长度是否超标 if len(answer) case.get(max_length, 500): score - 1 return score模型打分部分把评分标准和用例一起塞给 Claude请根据以下标准给回答打分 [评分标准] 问题[问题] 参考答案要点[核心要点] 模型回答[回答] 请输出 - 事实准确性得分1-3及理由 - 指令遵循度得分1-3及理由 - 完整性得分1-3及理由 - 表达质量得分1-3及理由两部分分数按权重加权得到最终分。规则部分和模型部分分开记录方便排查是规则误判还是模型误判。4.4 第四步跑第一轮建立基线第一轮跑完你会得到一个基线分数。这个分数大概率不好看没关系它的作用是给你一个起点。把每条用例的得分、扣分理由、原始输出都存下来按扣分从多到少排序。排在最前面的那几条就是当前最严重的问题。我第一轮跑完发现事实准确性平均只有 1.8 分主要问题是模型在回答“对比类”问题时容易把两个对象的属性搞混。这就是一个非常具体的失败模式比“模型不够准”这种模糊判断有用得多。4.5 第五步一轮改一个变量记录分数变化针对第一轮暴露的问题改 prompt。比如针对属性搞混的问题在 prompt 里加一条“当对比两个对象时先分别列出各自的属性再逐项对比不要交叉描述。”改完重跑 eval看事实准确性分数有没有提升。每轮改动都记录在一个表格里轮次改动内容事实准确性指令遵循完整性表达质量总分0基线1.82.52.22.62.151加对比类指令2.32.52.22.62.382加格式示例2.32.92.22.62.48这样你能清楚地看到每个改动的收益。如果某轮改动分数没涨甚至跌了就回滚换下一个方向。爬坡的过程就是不断试错但因为有 eval 在每次试错都有数据支撑不是瞎试。4.6 第六步对抗场景专项优化当正常场景和边缘场景的分数都上到 2.5 以上之后重点转向对抗场景。对抗场景的失败往往不是靠加一条 prompt 能解决的可能需要调整整个处理流程。比如对于“前提错误”的输入模型容易顺着错误前提往下答这时候需要在流程里加一个“前提检查”步骤先判断问题本身是否成立再决定怎么回答。这一步的改动幅度会比较大建议单独开一个分支做不要和前面的优化混在一起。对抗场景的分数提升通常比较慢但每提升一点模型的鲁棒性就实打实地强一分。5. 常见问题与排查技巧实录5.1 模型打分不稳定同一个回答两次打分不一样这是最常见的问题原因通常是评分标准太模糊。排查步骤先看两次打分的理由如果理由本身就不一致说明标准有歧义如果理由一致但分数不同说明模型对档位的边界理解不清。解决办法是把每个档位的边界写死比如“3 分要求所有事实都有依据2 分允许一个事实无依据1 分有两个以上无依据”。边界越清晰打分越稳定。5.2 用例跑完分数很高但线上效果还是差这说明你的用例和真实场景有偏差。排查方法从线上日志里随机抽 50 条真实 query人工标注期望输出然后拿这 50 条跑一遍 eval。如果分数明显低于你的测试集分数说明测试集覆盖的场景和真实场景不一致。解决办法是把真实 query 补充进测试集并且定期用线上数据刷新测试集。5.3 分数涨到一定程度就上不去了这是正常的说明当前方案的天花板到了。这时候有两个方向一是换更强的模型二是改流程架构。换模型是最直接的但成本会上去。改流程架构比如加检索、加多轮验证效果可能更好但工作量更大。我的建议是先分析剩余扣分集中在哪个维度如果是事实准确性上不去优先考虑加检索如果是指令遵循上不去优先考虑换模型或加 few-shot 示例。5.4 对抗用例模型总是答错是不是没救了不一定。先看模型答错的方式如果是“顺着错误前提答”可以在 prompt 里加前提检查如果是“编造数据”可以加“不确定时明确说不知道”的指令如果是“超长输入丢失信息”可以考虑分段处理。每种失败模式都有对应的解法关键是先定位清楚。5.5 打分脚本跑得太慢如果用例多、模型打分调用频繁跑一轮可能要十几分钟。优化方向规则部分能并行的并行模型打分部分可以批量提交把多条用例打包成一个请求主观维度如果相关性高可以合并成一个维度减少调用次数。我实测下来把 50 条用例打包成 5 个批次提交时间能压缩到原来的三分之一。5.6 团队里每个人对分数的理解不一样这是协作问题不是技术问题。解决办法是写一份评估手册把每个维度的定义、每个档位的边界、典型示例都写清楚。新成员上手前先跑一遍标注练习和手册对齐之后再正式参与评估。手册不用写得多漂亮但一定要具体到“看到什么扣几分”的程度。6. 几个让我少走弯路的实操心得第一eval 的用例要版本管理。每次改动用例都要记录改了什么、为什么改。我吃过亏改了一轮用例之后分数掉了结果忘了改了什么排查了半天。后来用 Git 管理用例文件每次改动都有 commit message回溯起来很方便。第二打分理由比分数本身更重要。分数只告诉你“好不好”理由告诉你“为什么不好”。我每次看 eval 结果先看扣分最多的用例的理由往往一眼就能看出问题所在。理由写得越具体排查效率越高。第三不要追求满分。eval 分数到 2.8 以上之后每提升 0.1 的边际成本急剧上升但业务收益可能微乎其微。这时候应该把精力转向覆盖更多场景而不是死磕现有用例的分数。我一般把 2.8 作为“可以上线”的阈值之后根据线上反馈再决定要不要继续优化。第四定期用新数据刷新测试集。用户的行为会变产品的功能会变半年前的测试集可能已经不能反映当前的真实场景。我一般每个月从线上抽一批新 query 补充进测试集同时淘汰一批已经不再出现的旧用例。保持测试集的“新鲜度”eval 的结果才有参考价值。第五让 Claude 帮你分析失败模式。把扣分最多的 20 条用例的输出喂给 Claude让它总结这些失败有什么共同点。它经常能发现我忽略的模式比如“所有失败用例都涉及时间相关的表述”。这种模式总结比人眼逐条看快得多而且不容易漏。这套流程我跑了大概三个月eval 分数从最初的 2.1 爬到了 2.9线上用户反馈的 bad case 明显减少。最关键的收获不是分数本身而是有了一个可以持续迭代的评估体系——每次改 prompt 都知道自己在往哪个方向走而不是凭感觉。如果你也在做类似的事情建议先从 20 条用例、两个维度开始跑通整个流程之后再逐步扩展。一开始就追求大而全很容易卡在搭建阶段就放弃了。