1. 为什么我要用 Claude 来设计 eval第一次认真做 eval 是两年前当时手头有个分类任务模型离线指标看着挺漂亮上线之后用户投诉却一堆。回头一查发现我那个测试集是从训练数据里随手切出来的分布跟真实流量差了十万八千里。那次教训让我彻底明白一件事模型能力是一回事你能不能量出来它是另一回事。eval 做不好后面所有的调优、迭代、上线决策全是拍脑袋。后来我把 eval 当成一个独立项目来做而不是训练脚本里的一个附属函数。这个转变带来的收益远超预期。而真正让效率起飞的关键是我开始用 Claude 来帮我设计 eval、生成测试用例、分析失败样本然后一轮一轮把分数往上爬。这套方法的核心逻辑其实很朴素eval 本身也是一个需要迭代的系统。你不可能一次写出完美的测试集和评分标准就像你不可能一次训出完美的模型。既然要迭代那就需要一个能快速产出、快速反馈、快速修正的循环。Claude 在这个循环里扮演的角色是一个不知疲倦的、有一定判断力的协作者——它能帮你把脑子里模糊的“好”和“坏”变成可执行的评分规则能批量生成边界用例能帮你分析为什么这一轮分数掉了。这篇文章适合谁看如果你正在做 LLM 应用、Agent 系统、或者任何需要量化评估模型输出质量的场景并且你已经厌倦了“感觉还行”这种评价方式那这篇内容应该能帮到你。我会从 eval 的整体设计思路讲起然后拆解用 Claude 设计 eval 的具体操作再讲怎么通过一轮轮迭代把分数提上去最后分享一些我踩过的坑和排查技巧。需要说明的是下面提到的所有操作步骤和参数配置都是基于我自己的实践经验总结的不同场景下你需要根据实际情况调整。Claude 的 API 调用方式、模型版本这些细节请以官方文档为准。2. eval 整体设计与思路拆解2.1 先想清楚你要量什么很多人做 eval 的第一步是打开编辑器开始写测试用例这是错的。第一步应该是坐下来想清楚你到底要量什么。我见过太多 eval 项目失败在起点上——测试集里塞了一堆“看起来相关”的问题但这些问题跟实际业务目标没有直接关系。比如你做一个客服问答系统测试集里全是通用知识问答那这个 eval 分数再高也没意义。我的做法是先定义清楚三个东西任务边界模型在这个场景下要做什么、不做什么。比如客服问答模型只需要回答产品相关问题对于竞品对比、价格谈判这类问题应该拒答或转人工。成功标准什么样的输出算“好”。这个标准要具体到可以写成评分规则的程度。比如“回答准确”太模糊“回答中提到的产品参数与知识库一致”才可操作。失败模式你最怕模型犯什么错。是胡编乱造是答非所问是语气不当把这些失败模式列出来它们就是你 eval 的重点关注对象。这三个东西想清楚之后你才知道 eval 应该覆盖哪些维度、每个维度的权重怎么分配。2.2 为什么选择用 Claude 来辅助设计市面上能用的模型不少我选 Claude 做 eval 辅助有几个实际原因。第一是长上下文能力。设计 eval 的时候经常需要把大量参考资料、历史对话、评分标准一起塞进 prompt 里Claude 在这方面的表现比较稳定不容易因为上下文长了就丢信息。第二是指令遵循的细腻度。eval 的评分规则往往有很多边界条件比如“如果回答中包含了正确信息但语气过于生硬扣 0.5 分而不是 1 分”。这种细粒度的规则Claude 执行起来比很多模型要靠谱。第三是生成多样性。让 Claude 批量生成测试用例的时候它给出的边界案例质量明显更高不会翻来覆去就是那几种套路。当然这不是说其他模型不能用。核心思路是一样的找一个指令遵循好、上下文窗口大、生成质量稳定的模型来当你的 eval 协作者。Claude 只是我目前用下来最顺手的。2.3 eval 系统的三层结构我把 eval 系统分成三层这个结构在后面迭代的时候会反复用到第一层是测试用例集。这是 eval 的原材料包含输入和期望输出或者期望的输出特征。测试用例的质量直接决定了 eval 的上限。第二层是评分器。评分器负责把模型输出和期望输出做对比给出分数。评分器可以是基于规则的比如关键词匹配、正则表达式也可以是基于模型的让另一个模型来打分还可以是混合的。第三层是聚合与报告。把单个用例的分数聚合成整体指标并且能按维度拆解让你知道模型在哪个方面强、哪个方面弱。这三层里第一层和第二层是 Claude 能帮上大忙的地方。第三层更多是工程实现Claude 的参与度相对低一些。2.4 迭代循环的设计整个迭代循环长这样用 Claude 生成初始测试用例集和评分规则跑一遍 eval拿到基线分数分析失败样本找出分数低的原因判断是测试用例的问题、评分规则的问题、还是模型本身的问题针对性地修正然后回到第 2 步这个循环听起来简单但实际操作中有很多细节。比如第 4 步的判断就很容易出错——很多人一看到分数低就想着去调模型但实际上很多时候是评分规则太严或者测试用例本身有问题。我的一般原则是先怀疑 eval再怀疑模型。因为 eval 是你自己设计的出错的概率远高于一个已经训练好的模型。3. 用 Claude 设计 eval 的核心细节与实操要点3.1 怎么让 Claude 理解你的评估需求跟 Claude 协作设计 eval最关键的一步是把你脑子里的评估需求准确地传达给它。我试过很多种方式最后总结出一个比较有效的 prompt 结构你是一个 eval 设计专家。我需要你帮我设计一套评估方案。 ## 任务背景 [描述你的任务是什么模型需要做什么] ## 成功标准 [描述什么样的输出算好越具体越好] ## 失败模式 [列出你最怕模型犯的错误] ## 输出要求 请帮我生成 1. 评估维度列表每个维度附上权重建议 2. 每个维度的具体评分规则 3. 每个维度的示例测试用例至少 5 个这个结构的关键在于成功标准和失败模式要写得足够具体。我一开始写得很笼统Claude 生成的评分规则也很笼统。后来我把成功标准细化到“回答中必须包含知识库中对应的产品参数且参数值完全一致”Claude 生成的评分规则就变得非常可操作了。还有一个技巧是给 Claude 提供反面例子。比如你告诉它“下面这些是我不希望看到的输出”然后给几个具体的 bad case。Claude 对反面例子的理解往往比正面描述更准确生成的评分规则也更能抓住你真正在意的点。3.2 生成测试用例的批量操作初始测试用例集不需要很多20 到 50 条就够了。重要的是覆盖面而不是数量。我一般会让 Claude 按下面的维度来生成典型场景最常见的用户输入占 40% 左右边界场景输入很短、很长、有歧义、包含多个意图的情况占 30% 左右对抗场景故意诱导模型犯错的输入占 20% 左右拒答场景模型应该拒绝回答的情况占 10% 左右让 Claude 生成的时候我会给它一个具体的格式要求请按以下 JSON 格式输出测试用例 { id: case_001, category: typical, input: 用户输入内容, expected_output: 期望的输出内容或输出特征, scoring_notes: 这个用例的评分要点 }用 JSON 格式的好处是后面可以直接程序化处理不用手动整理。Claude 生成 JSON 的稳定性还不错偶尔会有格式问题加一句“请确保输出是合法的 JSON不要包含注释”就能解决大部分情况。生成完之后一定要人工过一遍。Claude 生成的用例大部分是合理的但总有一些跟你的实际场景不符。我一般会删掉 10% 到 20% 的用例然后手动补充一些 Claude 没想到的场景。3.3 评分规则的设计要点评分规则是 eval 系统里最容易出问题的地方。我踩过的坑包括规则太模糊导致评分不稳定、规则太严格导致所有输出都低分、规则之间有冲突导致无法同时满足。用 Claude 设计评分规则的时候我会要求它遵循几个原则可操作性每条规则都能对应到一个具体的判断动作。比如“回答准确”不可操作“回答中的产品价格与知识库一致”可操作。独立性不同维度的规则之间尽量不重叠。如果两个维度都在衡量“准确性”那它们应该合并。可区分性规则要能区分出“好”和“一般”和“差”。如果一条规则只有 0 分和 1 分两个档位那它很难反映输出的细微质量差异。我一般会用 0 到 5 分的五档评分或者 0、0.5、1 的三档评分。权重合理不同维度的权重应该反映它们在实际场景中的重要程度。比如客服场景里“准确性”的权重应该远高于“语气友好度”。下面是一个评分规则的示例展示一下我实际用的格式维度权重评分标准信息准确性40%5分所有信息与知识库一致3分主要信息正确但有细节偏差1分关键信息错误0分完全错误完整性25%5分覆盖用户问题的所有方面3分覆盖主要方面但遗漏次要信息1分只覆盖部分0分答非所问语气适当性20%5分专业且友好3分专业但生硬1分语气不当0分冒犯性内容格式规范性15%5分格式完全符合要求3分基本符合但有 minor 问题1分格式混乱0分完全不符合这个表格是 Claude 生成的初版我调整了权重和部分评分描述。权重调整是最需要人工介入的地方因为只有你知道在实际业务里哪个维度更重要。3.4 用 Claude 做评分器的注意事项除了设计 evalClaude 本身也可以当评分器用。让 Claude 根据评分规则给模型输出打分这在很多场景下比基于规则的评分器更灵活。但用 Claude 做评分器有几个坑要注意评分一致性同一个输出Claude 两次打分可能不一样。我实测下来温度设为 0 的时候一致性最好但也不是 100% 稳定。对于关键评估我会让 Claude 对同一个输出打三次分取平均值。评分偏差Claude 倾向于给“看起来合理”的输出打高分即使这个输出实际上有事实错误。解决办法是在 prompt 里明确要求它“先检查事实准确性再评估其他维度”并且给它提供事实核查的参考资料。成本控制如果测试集很大用 Claude 逐条打分成本不低。我的做法是先用基于规则的评分器做初筛只对规则评分器不确定的样本调用 Claude 评分。prompt 设计评分 prompt 里一定要包含评分规则、评分示例few-shot、以及输出格式要求。我一般会给每个分数档位配一个示例输出这样 Claude 打分更稳定。4. 一轮轮把分数提上去的实操过程4.1 建立基线第一轮 eval 怎么跑第一轮 eval 的目标不是拿高分而是建立一个可比较的基线。所以第一轮不要做任何调优就用最原始的模型和 prompt 跑一遍看看分数是多少。我第一轮跑的时候整体分数只有 2.8 分满分 5 分。这个分数本身不重要重要的是分维度的分数。我当时的分布是这样的信息准确性3.2 分完整性2.1 分语气适当性3.8 分格式规范性2.5 分一眼就能看出来完整性和格式规范性是短板。这就给后面的迭代指明了方向。第一轮跑完之后我会做一件事把每个维度的最低分样本挑出来人工看一遍。这一步非常关键因为分数只告诉你“哪里差”不告诉你“为什么差”。人工看样本才能发现真正的问题。4.2 分析失败样本找到分数低的真正原因我挑出完整性维度最低的 10 个样本逐个分析。发现的问题主要有三类第一类是模型确实漏掉了信息。比如用户问了三个问题模型只回答了前两个。这是模型能力问题。第二类是评分规则太严。比如用户问“这个产品支持哪些支付方式”模型回答了“支持微信和支付宝”但评分规则要求“必须列出所有支付方式包括银行卡”而知识库里其实只写了微信和支付宝。这是评分规则的问题。第三类是测试用例本身有问题。比如有个用例的期望输出写错了导致模型回答正确却被判低分。这三类问题的处理方式完全不同。第一类需要调模型或改 prompt第二类需要改评分规则第三类需要修测试用例。如果不做这个分析直接去调模型那第二类和第三类问题永远解决不了分数也永远提不上去。4.3 修正 eval 本身先让尺子准起来分析完失败样本之后我的第一轮修正全部集中在 eval 本身而不是模型。具体做了这几件事修正测试用例把期望输出写错的用例改对把跟实际场景不符的用例删掉补充了一些遗漏的场景。这一轮改了大概 15% 的用例。调整评分规则把过于严格的规则放宽把模糊的规则改具体。比如完整性维度原来要求“覆盖所有方面”改成了“覆盖主要方面即可得 4 分覆盖所有方面得 5 分”。这一轮改了大概 30% 的评分规则。统一评分尺度让 Claude 对一批样本重新打分然后人工核对确保评分尺度一致。这一步花了不少时间但非常值得因为评分尺度不一致的话后面的分数变化就没有意义了。修正完 eval 之后重新跑一遍。分数从 2.8 变成了 3.1。这个提升完全来自 eval 本身的修正模型没有任何变化。这里有一个很重要的心态不要害怕花时间修 eval。很多人觉得修 eval 不是“正经工作”不如去调模型来得有成就感。但实际上eval 不准的话你调模型就是盲调今天分数涨了明天可能又跌了你根本不知道发生了什么。4.4 优化模型输出prompt 调整与迭代eval 修正到比较可靠之后才开始动模型。我优化模型输出的手段主要有三个改 prompt、加 few-shot 示例、调生成参数。改 prompt是最直接的。针对完整性维度低的问题我在 prompt 里加了一句“请确保回答覆盖用户问题的所有方面如果有多个问题请逐一回答”。这一句话让完整性分数从 2.1 提到了 3.0。加 few-shot 示例对格式规范性特别有效。我在 prompt 里加了两个格式完美的回答示例格式规范性分数从 2.5 提到了 4.2。调生成参数主要是调温度和最大长度。温度从 0.7 降到 0.3 之后输出的稳定性明显提升信息准确性分数从 3.2 提到了 3.6。最大长度从 500 提到 800 之后完整性分数又涨了一点因为模型不再因为长度限制而截断回答了。这一轮下来整体分数从 3.1 提到了 3.9。每一轮改动之后我都会重新跑 eval记录分数变化。下面是我记录的迭代日志轮次改动内容整体分数准确性完整性语气格式基线无2.83.22.13.82.5第1轮修正 eval3.13.32.53.82.8第2轮改 prompt3.53.43.03.93.5第3轮加 few-shot3.83.53.24.04.2第4轮调参数3.93.63.44.04.2这个日志看起来简单但每一轮背后都有大量的分析和尝试。而且不是每一轮都涨分我有好几次改完之后分数反而掉了然后回滚重新想。4.5 用 Claude 做 hillclimb自动化迭代手动迭代到 3.9 之后提升速度明显变慢了。这时候我开始尝试用 Claude 做半自动化的 hillclimb。具体做法是让 Claude 分析失败样本提出 prompt 修改建议然后我批量测试这些建议保留有效的丢弃无效的。流程大概是这样把当前分数最低的 20 个样本和对应的模型输出、评分结果整理成一份报告让 Claude 分析这些失败样本找出共同模式提出 3 到 5 个 prompt 修改建议对每个建议生成一个修改后的 prompt 版本用每个版本跑一遍 eval记录分数保留分数最高的版本如果都不如当前版本就保留当前版本这个流程跑一轮大概需要 30 分钟到 1 小时取决于测试集大小和 API 响应速度。我跑了大概 10 轮分数从 3.9 提到了 4.3。Claude 提出的建议里有些是我自己想不到的。比如它发现模型在回答包含数字的问题时容易出错建议在 prompt 里加一句“涉及数字时请仔细核对必要时在回答中标注数据来源”。这个建议让准确性分数又涨了 0.2。但也有很多建议是无效的甚至有害的。比如它建议“在回答末尾添加总结段落”这导致格式规范性分数下降因为总结段落经常跟正文重复。所以人工筛选是必须的不能完全放手让 Claude 自动改。4.6 分数卡住了怎么办进阶排查思路分数提到 4.3 之后又卡住了。这时候常规的 prompt 调整已经没什么效果了。我用了几个进阶的排查思路分维度交叉分析把准确性和完整性做交叉看看是不是存在“准确但不完整”或者“完整但不准确”的样本群。果然发现有一批样本模型为了追求完整性而牺牲了准确性回答里塞了很多不相关的信息。错误类型聚类把失败样本按错误类型聚类发现有一类错误是“模型正确理解了问题但选择了错误的回答策略”。比如用户问“这个功能怎么用”模型给了一个很长的功能说明但用户其实想要的是操作步骤。这类问题不是 prompt 能解决的需要在系统层面做意图识别和路由。测试集难度分层把测试集按难度分成简单、中等、困难三层分别看分数。发现简单和中等样本的分数已经很高了但困难样本的分数一直上不去。这说明模型的瓶颈在复杂场景的处理能力上需要更根本的改进。对比不同模型用同样的 eval 跑了一下其他模型发现有些模型在特定维度上表现更好。这不一定意味着要换模型但可以借鉴那些模型的处理方式比如它们的输出格式、回答结构等。这些排查思路帮我找到了新的优化方向分数又从 4.3 提到了 4.5。但越往上提越难从 4.5 到 4.6 花的时间比从 2.8 到 4.3 还多。5. 常见问题与排查技巧实录5.1 评分不一致怎么办这是最常见的问题。同一个输出两次评分结果不一样或者不同评分器给出的分数差异很大。排查思路先检查评分规则是否足够具体。模糊的规则必然导致不一致。检查评分 prompt 里是否有足够的示例。few-shot 示例能显著提升一致性。把温度设为 0减少随机性。如果还是不一致考虑用多个评分器取平均或者用规则评分器做初筛。我实测下来规则评分器的一致性最好但灵活性最差。模型评分器灵活性好但一致性差。混合方案是比较好的折中规则评分器处理明确的对错判断模型评分器处理需要理解语义的判断。5.2 测试集过拟合了怎么办当你发现模型在测试集上分数很高但实际使用中效果不好很可能就是测试集过拟合了。原因通常是测试集太小、太单一或者你在迭代过程中不自觉地针对测试集做了优化。解决办法定期用新数据替换一部分测试集。我一般每个月会替换 20% 的测试用例。保留一个“从未用于迭代”的 hold-out 测试集只在最终评估时使用。让 Claude 生成一些跟现有测试集风格差异较大的用例专门用来检测过拟合。5.3 分数上不去但不知道问题在哪这是最让人头疼的情况。我的排查清单是这样的排查项检查方法常见问题测试用例质量人工抽查 20 个用例期望输出写错、场景不匹配评分规则合理性看分数分布是否过于集中规则太严或太松评分器一致性同一输出多次评分分数波动大模型输出质量人工看失败样本确实存在能力不足prompt 有效性A/B 测试不同 promptprompt 有歧义或冲突参数配置对比不同参数下的分数温度、长度等不合适按这个清单逐项排查基本能定位到问题所在。最怕的是跳过排查直接调模型那样很可能白忙一场。5.4 用 Claude 做 eval 的成本控制用 Claude 做 eval 确实有成本尤其是测试集大的时候。我的控制策略是分层评估先用便宜的规则评分器跑全量只对规则评分器不确定的样本调用 Claude。采样评估如果测试集超过 500 条每次迭代只随机采样 200 条跑 eval全量评估只在关键节点做。缓存结果相同的输入和评分规则评分结果可以缓存不用重复调用。批量处理把多个评分请求合并成一个请求减少 API 调用次数。这些策略综合下来我的 eval 成本控制在了可接受的范围内。具体数字因场景而异但核心思路是不要对所有样本都用最贵的评分方式。5.5 几个我踩过的坑坑一评分规则太多。我一开始设计了 10 个评分维度结果每个维度的分数都很低因为模型不可能同时满足所有维度。后来精简到 4 个核心维度分数反而更合理了。坑二测试用例太“干净”。我最初的测试用例都是精心构造的输入很规范。但实际用户的输入往往有错别字、语法混乱、意图模糊。后来我让 Claude 专门生成了一批“脏”输入eval 结果跟实际表现的差距小了很多。坑三忽略评分成本。有一次我设计了一个需要调用 Claude 三次才能完成评分的规则测试集有 1000 条跑一次 eval 的成本高得吓人。后来改成了规则评分器初筛加 Claude 复核的方案成本降了 80%。坑四迭代太快。有一段时间我每天改好几版 prompt分数确实在涨但后来发现涨的全是测试集分数实际效果没变。原因是改得太快没有足够的时间做人工验证。后来我把迭代节奏放慢到每周一到两轮每轮都做人工抽查效果反而更好。坑五忘了记录。我有一段时间没有记录每轮改动的细节结果后来想回滚到某个版本的时候发现已经记不清当时改了什么。从那以后我养成了写迭代日志的习惯每轮改动、分数变化、人工观察都记下来。这个日志后来成了我最宝贵的参考资料。5.6 一个实用的排查技巧分数分解当整体分数卡住的时候我会做一个分数分解把整体分数按维度、按难度、按场景类型分别拆开看。比如整体分数是 4.3但拆开之后发现简单场景4.8 分中等场景4.4 分困难场景3.2 分这说明瓶颈在困难场景上。然后再看困难场景里哪个维度分数最低假设是完整性只有 2.5 分那就集中精力解决困难场景下的完整性问题。这个技巧看起来简单但非常有效。它能把“分数上不去”这个模糊的问题变成“困难场景下完整性不足”这个具体的问题然后你就能针对性地去解决了。6. 一些个人体会这套方法我用了大半年最大的感受是eval 不是一次性的工作而是一个持续迭代的系统。你不可能一次写出完美的 eval就像你不可能一次写出完美的代码。重要的是建立起“设计-评估-分析-修正”的循环然后一轮一轮地跑下去。Claude 在这个循环里帮了我很多但它不是万能的。它生成的测试用例需要人工筛选它提出的修改建议需要人工验证它打的分数需要人工抽查。把 Claude 当成一个高效的协作者而不是一个自动化的解决方案这个定位很重要。另外分数不是越高越好。4.5 分和 4.6 分的差距在实际业务中可能根本感知不到。与其花大量时间把分数从 4.5 提到 4.6不如把精力放在扩大测试集覆盖面上或者优化那些分数虽然高但实际体验不好的场景。最后分享一个我最近在用的技巧让 Claude 扮演“挑剔的用户”来评估输出。具体做法是在评分 prompt 里加一句“你是一个对产品质量要求极高的用户请找出这个回答中所有可能让用户不满的地方”。这样 Claude 会更容易发现那些“看起来没问题但实际上有隐患”的输出评分也更有区分度。这个技巧让我的 eval 在高质量样本上的区分能力提升了不少。