1. 那个让我后背发凉的95%去年冬天团队里一个做智能客服的朋友拉着我看他们的评测报告。报告上赫然写着机评一致率95%人工抽检满意度4.8分。数据漂亮得可以直接拿去汇报。我当时多嘴问了一句“那剩下5%的不一致你们看过吗”他愣了一下说“5%嘛噪声而已模型总不可能完美。”我让他把那5%的case捞出来我们一条一条看。结果看到第三十条的时候他脸色就变了。那5%里有将近一半是模型答非所问、答非所问里又有一半是安全边界问题——用户问的是退款流程模型给了一段产品推荐用户表达不满模型回了一句“感谢您的支持”。这些case如果流到线上每一个都是客诉。这就是我想聊的核心问题机评一致率这个指标本身可能就是一个陷阱。95%的一致率听起来很高但如果你的评测集里95%都是简单样本那这个数字什么都说明不了。更可怕的是那5%的不一致里藏着模型真正会犯的错。你把噪声扔掉等于把金子也扔了。这篇内容适合谁看如果你正在做AI产品的评测体系不管是对话系统、内容生成、代码助手还是多模态应用只要你需要回答“我的模型到底行不行”这个问题那这篇就是写给你的。我会从评测集设计、机评与人工的配合、指标陷阱、到具体怎么落地一套能抓错的eval流程全部拆开讲。不堆术语只讲我踩过的坑和验证过的方法。2. 评测集没设计好后面全是白干2.1 为什么你的评测集可能一直在骗你大多数团队做评测集的方式是这样的从线上日志里随机采样一批query找几个标注同学打上标准答案然后拿模型跑一遍算准确率。这个方法不能说错但它有一个致命缺陷——随机采样得到的评测集分布和真实业务分布是脱节的。我见过一个做法律问答的产品评测集里80%的问题是“劳动合同法第X条是什么”这种检索型问题模型准确率92%。上线之后用户投诉不断因为真实用户问的是“公司拖欠工资三个月我能不能直接离职并要求赔偿”这种需要推理和多步判断的问题。评测集里的简单样本把真实问题稀释了92%这个数字毫无意义。正确的做法是分层采样。你需要先对业务场景做分类比如场景类型占比真实业务评测集建议占比难度简单检索40%20%低多步推理30%35%中边界/对抗15%30%高安全合规15%15%高注意看简单检索在真实业务里占40%但在评测集里我只放20%。为什么因为简单样本对模型能力的区分度太低放多了只会拉高一致率让你误以为模型很强。而边界和对抗样本真实业务里可能只占15%但它们是模型最容易翻车的地方评测集里要加倍放。提示评测集的分布不应该等于业务分布而应该等于“你希望模型表现好的关键场景分布”。简单样本是分母难样本才是分子。2.2 标注标准不统一机评就是空中楼阁还有一个更隐蔽的坑标注标准本身就不一致。我参与过一个内容审核模型的评测三个标注同学对同一条内容的判断两两一致率只有78%。这意味着什么意味着你拿这个评测集去算模型准确率模型和标注的一致率上限就是78%左右。你后面再怎么优化模型都突破不了这个天花板。解决这个问题的方法只有一个先做标注一致性校准再做评测。具体步骤选100条代表性样本让所有标注同学独立标注。计算两两一致率Cohens Kappa或Krippendorffs Alpha。对不一致的case逐条讨论形成明确的标注规则文档。用新规则重新标注直到一致率达到85%以上。这个规则文档就是后续所有标注和机评的“宪法”。这个过程很痛苦但省不得。我见过太多团队跳过这一步直接让标注同学上手结果评测集里全是噪声模型优化方向完全跑偏。2.3 评测集要“活”不能一劳永逸很多团队把评测集当成一次性工程建好之后就锁在仓库里每次模型迭代都拿同一套跑。这会导致一个严重问题模型会“过拟合”评测集。你的优化方向会不自觉地朝着评测集里的样本倾斜而真实业务中的新问题、新表达、新边界评测集里根本没有。我的做法是评测集分三份固定集60%长期不变用于跨版本对比保证指标可比性。轮换集30%每季度更新一次从最新线上日志里采样反映业务变化。对抗集10%专门收集模型犯错的case持续追加只增不减。固定集保证你不会自欺欺人轮换集保证你不会脱离业务对抗集保证你不会在同一个坑里摔两次。3. 机评和人工到底谁说了算3.1 机评不是“自动打分”而是“自动筛选”很多人对机评的理解是写一个打分脚本让模型自己给自己打分然后算个平均分。这种做法的问题在于模型给自己打分天然会偏向自己。你用一个模型去评另一个模型如果两个模型能力相近一致率会虚高如果能力差距大一致率又会虚低。我理解的机评核心价值不是“打分”而是“筛选”。具体来说机评应该做三件事粗筛把明显好的和明显差的case分出来减少人工工作量。定位找出模型可能犯错的case交给人工重点看。监控在模型迭代过程中快速发现指标异常波动。机评的输出不应该是一个单一的分数而应该是一个多维度的信号。比如对于对话系统机评可以输出相关性得分回答是否切题完整性得分是否覆盖了关键信息点安全性得分是否触碰红线流畅度得分语言是否自然每个维度单独看比一个综合分有用得多。因为一个综合分95可能意味着相关性98、安全性60——安全性的问题被平均掉了。3.2 人工评测的“锚点”怎么设人工评测最大的问题是主观性。同一个回答A标注员给4分B标注员给2分你听谁的解决方法是设置锚点样本。锚点样本就是一组预先定义好分数的标准回答。比如对于“如何申请退款”这个问题5分锚点完整说明退款条件、流程、时限并主动提示需要准备的材料。3分锚点说明了退款流程但遗漏了时限和材料要求。1分锚点只回复“请联系客服”没有实质信息。标注员在打分前先看锚点样本校准自己的评分尺度。每标注50条重新看一遍锚点防止尺度漂移。这个方法看起来笨但实测下来标注一致性可以从70%提升到88%以上。3.3 机评和人工的“交叉验证”机制机评和人工不是替代关系而是交叉验证关系。我的做法是机评先跑一遍输出每条case的多个维度得分。人工只标注机评“不确定”的case比如得分在中间区间、或者多个维度得分矛盾。人工标注结果反过来校准机评的阈值。具体流程可以这样设计# 伪代码示意机评筛选 人工复核的流程 def eval_pipeline(cases, machine_scorer, human_annotator): results [] for case in cases: scores machine_scorer(case) # 多维度得分 # 如果所有维度都明显好或明显差直接采纳机评 if all(s 0.9 for s in scores.values()) or all(s 0.3 for s in scores.values()): results.append({case: case, label: auto, scores: scores}) else: # 否则交给人工 human_label human_annotator(case) results.append({case: case, label: human, scores: scores, human: human_label}) return results这个流程的关键在于阈值设定。阈值太松人工工作量太大阈值太紧机评漏掉的错误就多。我的经验是先跑一批数据看机评得分分布把阈值设在分布的两个拐点附近。比如如果80%的case得分都在0.85以上那0.85就是一个自然阈值。4. 一致率95%背后的三个统计陷阱4.1 基数效应5%的不一致可能全是关键错误回到开头那个例子。95%一致率5%不一致。如果评测集有1000条不一致就是50条。这50条里可能藏着模型所有的关键错误。因为模型在简单样本上表现好在难样本上表现差而难样本在评测集里往往只占少数。我做过一个实验把一个对话模型的评测集按难度分层分别计算机评一致率。结果如下难度分层样本数机评一致率人工发现的关键错误数简单60098%2中等30093%15困难10082%38看到没有困难样本只占10%但贡献了73%的关键错误。如果你只看总体一致率95%你会觉得模型很好但如果你看困难样本的一致率82%你就知道模型在真正难的地方还有很大提升空间。提示永远不要只看总体一致率。一定要按难度、按场景、按错误类型分层看。分层之后你才能知道模型到底哪里不行。4.2 类别不平衡准确率高不代表召回率高假设你的评测集里90%的case是“模型应该回答A”10%是“模型应该回答B”。模型把所有case都回答成A准确率也有90%。但它在B类上的召回率是0。这就是类别不平衡带来的假象。解决方法是在评测指标里加入召回率和F1而不是只看准确率。对于安全审核、内容过滤这类场景召回率比准确率重要得多。你宁可误杀也不能漏放。具体怎么算举个例子真实为正类应该拦截的case有100条模型拦截了80条召回率80%。真实为负类不应该拦截的case有900条模型误拦了50条准确率 80/(8050) 61.5%。如果你只看准确率61.5%很难看但如果你看召回率80%还可以接受。关键是你的业务能容忍多少误杀。这个权衡必须在评测指标里体现出来。4.3 机评模型的“偏见”它可能和被测模型犯同样的错这是最隐蔽的陷阱。如果你用一个和被测模型同源、同架构、同训练数据的模型去做机评那它们很可能在同样的地方犯错。机评模型觉得“这个回答没问题”被测模型也觉得“这个回答没问题”一致率当然高。但人工一看两个都错了。避免这个陷阱的方法是机评模型和被测模型要异构。如果被测模型是基于A架构的机评模型最好用B架构如果被测模型是生成式的机评模型可以用判别式的。甚至可以用多个不同来源的机评模型做投票减少单一模型的偏见。我自己的做法是机评模型至少用两个一个基于规则小模型一个基于大模型。两者一致时结果可信度高两者不一致时交给人工。这样虽然成本高一点但能有效避免“同谋”问题。5. 一套能抓错的eval流程长什么样5.1 从“算分”到“抓错”的思维转变大多数团队的eval流程是跑模型 - 算指标 - 看报告 - 决定是否上线。这个流程的问题是它只告诉你“模型行不行”不告诉你“模型哪里不行”。我想要的eval流程是跑模型 - 机评筛选 - 人工复核 - 错误归因 - 形成改进清单。核心区别在于eval的终点不是分数而是错误清单。具体来说每次eval之后我应该得到这样一份东西模型在哪些场景下表现好哪些场景下表现差。差的表现具体是什么错误类型事实错误、逻辑错误、安全错误、格式错误。每个错误类型对应的典型case是什么。这些错误里哪些是可以通过prompt优化解决的哪些需要微调哪些需要数据补充。没有这份清单eval就是白做。5.2 错误归因把“不一致”翻译成“可行动项”错误归因是eval流程里最容易被忽略、但价值最高的环节。我通常把错误分成四类错误类型定义改进方向知识错误模型不知道某个事实补充知识库、RAG推理错误模型知道事实但推理错了优化prompt、few-shot对齐错误模型理解错了用户意图意图识别优化、多轮澄清安全错误模型触碰了红线安全层加固、拒答策略分类之后每个错误类型对应不同的改进动作。知识错误补数据推理错误调prompt对齐错误加澄清安全错误加规则。这样你的优化就不是盲目的“再训一版”而是有针对性的。5.3 一个可复用的eval脚本框架下面是我常用的eval脚本框架用Python写的核心逻辑是“机评筛选 人工复核 错误归因”import json from collections import defaultdict class EvalPipeline: def __init__(self, machine_scorer, human_annotator, error_classifier): self.machine_scorer machine_scorer self.human_annotator human_annotator self.error_classifier error_classifier def run(self, cases): results [] for case in cases: # 第一步机评 machine_result self.machine_scorer(case) # 第二步判断是否需要人工复核 if self._need_human_review(machine_result): human_result self.human_annotator(case) final_label human_result source human else: final_label machine_result source machine # 第三步错误归因 if final_label.get(is_error): error_type self.error_classifier(case, final_label) else: error_type None results.append({ case_id: case[id], source: source, label: final_label, error_type: error_type }) return self._summarize(results) def _need_human_review(self, machine_result): # 机评得分在中间区间或者多维度矛盾时需要人工 scores list(machine_result[scores].values()) if max(scores) - min(scores) 0.4: return True if 0.4 sum(scores)/len(scores) 0.8: return True return False def _summarize(self, results): summary defaultdict(int) for r in results: if r[error_type]: summary[r[error_type]] 1 return { total: len(results), human_reviewed: sum(1 for r in results if r[source] human), error_distribution: dict(summary) }这个框架的关键在于_need_human_review函数。它决定了哪些case交给人工哪些直接采纳机评。阈值可以根据你的业务容忍度调整。如果业务对错误很敏感就把阈值放宽多交人工如果业务迭代快、容忍度高就把阈值收紧减少人工。5.4 评测报告怎么写才有用最后说一下评测报告。我见过太多评测报告满篇都是数字但没有一句话能指导行动。好的评测报告应该回答三个问题模型现在能不能上线给出明确的go/no-go建议以及理由。如果不能上线最需要改什么按优先级列出top 3改进项。如果能上线风险是什么列出已知的边界case和监控指标。报告里不要只放总体指标要放分层指标、错误分布、典型case。最好附上错误case的原始输入和模型输出让读报告的人能直接看到问题。提示评测报告是给决策者看的不是给算法同学看的。决策者不关心F1是多少他们关心“上线会不会出事”。所以报告的第一页应该是结论和风险第二页才是数据细节。6. 那些年我踩过的eval坑6.1 坑一用测试集调prompt这是最经典的坑。你有一个测试集你根据测试集的表现调prompt调完之后测试集指标上去了你以为模型变好了。但实际上你只是把模型过拟合到了测试集上。上线之后真实表现可能反而下降。正确做法是测试集只能用来看不能用来调。调prompt要用开发集开发集和测试集要严格分开。如果数据不够至少要做交叉验证不能反复用同一批数据调。6.2 坑二忽略“拒答”和“澄清”的评测很多评测集只评“模型回答得对不对”不评“模型该不该回答”。对于安全敏感的场景模型拒答一个正常问题和模型回答一个危险问题都是错误。但很多评测集里根本没有拒答样本导致模型学会了“什么都答”上线之后安全风险极高。我的做法是评测集里必须包含一定比例的“应该拒答”和“应该澄清”的样本。比如用户问“怎么制作危险物品”模型应该拒答用户问“帮我订机票”但没说时间和目的地模型应该澄清。这些场景的评测和普通问答一样重要。6.3 坑三评测频率太低有些团队一个季度才做一次完整评测模型迭代了十几个版本但评测报告还是三个月前的。这导致优化方向严重滞后。我的建议是轻量评测每次迭代都做完整评测每月一次。轻量评测可以只用固定集里的核心样本快速跑一个指标完整评测用全量评测集做分层分析和错误归因。这样既能快速反馈又能定期深入。6.4 坑四不记录评测历史评测结果不存档每次评测都是“一次性”的。这导致你无法回答“模型是在哪个版本开始变差的”这个问题。我的做法是每次评测结果都存到一个结构化数据库里包含模型版本、评测集版本、评测时间、各项指标、错误分布。这样你可以画趋势图看模型是在哪个版本、哪个指标上出现了退化。这个信息对于定位问题非常关键。7. 写在最后eval不是成本是投资我刚开始做AI产品的时候也觉得eval是“额外工作”——模型都训好了跑个分不就行了后来踩的坑多了才明白eval不是成本是投资。一个好的eval体系能让你在模型上线前就发现80%的问题能让你在优化时知道往哪个方向使劲能让你在汇报时拿出有说服力的数据。那个95%一致率的故事后来怎么样了我朋友回去之后把那5%的不一致case全部捞出来逐条分析发现了一个安全漏洞和两个意图识别问题。他们花了两周修复上线之后客诉率下降了40%。他后来跟我说“那5%才是真正值钱的东西。”所以下次你看到95%一致率的时候别急着高兴。先问问自己那5%是什么你看过了吗 
长河君 · 2026/10/24 8:15:20 · 阅读 1.2k 机评一致率95%的陷阱：AI评测体系设计与错误归因实践
1. 那个让我后背发凉的95%去年冬天团队里一个做智能客服的朋友拉着我看他们的评测报告。报告上赫然写着机评一致率95%人工抽检满意度4.8分。数据漂亮得可以直接拿去汇报。我当时多嘴问了一句“那剩下5%的不一致你们看过吗”他愣了一下说“5%嘛噪声而已模型总不可能完美。”我让他把那5%的case捞出来我们一条一条看。结果看到第三十条的时候他脸色就变了。那5%里有将近一半是模型答非所问、答非所问里又有一半是安全边界问题——用户问的是退款流程模型给了一段产品推荐用户表达不满模型回了一句“感谢您的支持”。这些case如果流到线上每一个都是客诉。这就是我想聊的核心问题机评一致率这个指标本身可能就是一个陷阱。95%的一致率听起来很高但如果你的评测集里95%都是简单样本那这个数字什么都说明不了。更可怕的是那5%的不一致里藏着模型真正会犯的错。你把噪声扔掉等于把金子也扔了。这篇内容适合谁看如果你正在做AI产品的评测体系不管是对话系统、内容生成、代码助手还是多模态应用只要你需要回答“我的模型到底行不行”这个问题那这篇就是写给你的。我会从评测集设计、机评与人工的配合、指标陷阱、到具体怎么落地一套能抓错的eval流程全部拆开讲。不堆术语只讲我踩过的坑和验证过的方法。2. 评测集没设计好后面全是白干2.1 为什么你的评测集可能一直在骗你大多数团队做评测集的方式是这样的从线上日志里随机采样一批query找几个标注同学打上标准答案然后拿模型跑一遍算准确率。这个方法不能说错但它有一个致命缺陷——随机采样得到的评测集分布和真实业务分布是脱节的。我见过一个做法律问答的产品评测集里80%的问题是“劳动合同法第X条是什么”这种检索型问题模型准确率92%。上线之后用户投诉不断因为真实用户问的是“公司拖欠工资三个月我能不能直接离职并要求赔偿”这种需要推理和多步判断的问题。评测集里的简单样本把真实问题稀释了92%这个数字毫无意义。正确的做法是分层采样。你需要先对业务场景做分类比如场景类型占比真实业务评测集建议占比难度简单检索40%20%低多步推理30%35%中边界/对抗15%30%高安全合规15%15%高注意看简单检索在真实业务里占40%但在评测集里我只放20%。为什么因为简单样本对模型能力的区分度太低放多了只会拉高一致率让你误以为模型很强。而边界和对抗样本真实业务里可能只占15%但它们是模型最容易翻车的地方评测集里要加倍放。提示评测集的分布不应该等于业务分布而应该等于“你希望模型表现好的关键场景分布”。简单样本是分母难样本才是分子。2.2 标注标准不统一机评就是空中楼阁还有一个更隐蔽的坑标注标准本身就不一致。我参与过一个内容审核模型的评测三个标注同学对同一条内容的判断两两一致率只有78%。这意味着什么意味着你拿这个评测集去算模型准确率模型和标注的一致率上限就是78%左右。你后面再怎么优化模型都突破不了这个天花板。解决这个问题的方法只有一个先做标注一致性校准再做评测。具体步骤选100条代表性样本让所有标注同学独立标注。计算两两一致率Cohens Kappa或Krippendorffs Alpha。对不一致的case逐条讨论形成明确的标注规则文档。用新规则重新标注直到一致率达到85%以上。这个规则文档就是后续所有标注和机评的“宪法”。这个过程很痛苦但省不得。我见过太多团队跳过这一步直接让标注同学上手结果评测集里全是噪声模型优化方向完全跑偏。2.3 评测集要“活”不能一劳永逸很多团队把评测集当成一次性工程建好之后就锁在仓库里每次模型迭代都拿同一套跑。这会导致一个严重问题模型会“过拟合”评测集。你的优化方向会不自觉地朝着评测集里的样本倾斜而真实业务中的新问题、新表达、新边界评测集里根本没有。我的做法是评测集分三份固定集60%长期不变用于跨版本对比保证指标可比性。轮换集30%每季度更新一次从最新线上日志里采样反映业务变化。对抗集10%专门收集模型犯错的case持续追加只增不减。固定集保证你不会自欺欺人轮换集保证你不会脱离业务对抗集保证你不会在同一个坑里摔两次。3. 机评和人工到底谁说了算3.1 机评不是“自动打分”而是“自动筛选”很多人对机评的理解是写一个打分脚本让模型自己给自己打分然后算个平均分。这种做法的问题在于模型给自己打分天然会偏向自己。你用一个模型去评另一个模型如果两个模型能力相近一致率会虚高如果能力差距大一致率又会虚低。我理解的机评核心价值不是“打分”而是“筛选”。具体来说机评应该做三件事粗筛把明显好的和明显差的case分出来减少人工工作量。定位找出模型可能犯错的case交给人工重点看。监控在模型迭代过程中快速发现指标异常波动。机评的输出不应该是一个单一的分数而应该是一个多维度的信号。比如对于对话系统机评可以输出相关性得分回答是否切题完整性得分是否覆盖了关键信息点安全性得分是否触碰红线流畅度得分语言是否自然每个维度单独看比一个综合分有用得多。因为一个综合分95可能意味着相关性98、安全性60——安全性的问题被平均掉了。3.2 人工评测的“锚点”怎么设人工评测最大的问题是主观性。同一个回答A标注员给4分B标注员给2分你听谁的解决方法是设置锚点样本。锚点样本就是一组预先定义好分数的标准回答。比如对于“如何申请退款”这个问题5分锚点完整说明退款条件、流程、时限并主动提示需要准备的材料。3分锚点说明了退款流程但遗漏了时限和材料要求。1分锚点只回复“请联系客服”没有实质信息。标注员在打分前先看锚点样本校准自己的评分尺度。每标注50条重新看一遍锚点防止尺度漂移。这个方法看起来笨但实测下来标注一致性可以从70%提升到88%以上。3.3 机评和人工的“交叉验证”机制机评和人工不是替代关系而是交叉验证关系。我的做法是机评先跑一遍输出每条case的多个维度得分。人工只标注机评“不确定”的case比如得分在中间区间、或者多个维度得分矛盾。人工标注结果反过来校准机评的阈值。具体流程可以这样设计# 伪代码示意机评筛选 人工复核的流程 def eval_pipeline(cases, machine_scorer, human_annotator): results [] for case in cases: scores machine_scorer(case) # 多维度得分 # 如果所有维度都明显好或明显差直接采纳机评 if all(s 0.9 for s in scores.values()) or all(s 0.3 for s in scores.values()): results.append({case: case, label: auto, scores: scores}) else: # 否则交给人工 human_label human_annotator(case) results.append({case: case, label: human, scores: scores, human: human_label}) return results这个流程的关键在于阈值设定。阈值太松人工工作量太大阈值太紧机评漏掉的错误就多。我的经验是先跑一批数据看机评得分分布把阈值设在分布的两个拐点附近。比如如果80%的case得分都在0.85以上那0.85就是一个自然阈值。4. 一致率95%背后的三个统计陷阱4.1 基数效应5%的不一致可能全是关键错误回到开头那个例子。95%一致率5%不一致。如果评测集有1000条不一致就是50条。这50条里可能藏着模型所有的关键错误。因为模型在简单样本上表现好在难样本上表现差而难样本在评测集里往往只占少数。我做过一个实验把一个对话模型的评测集按难度分层分别计算机评一致率。结果如下难度分层样本数机评一致率人工发现的关键错误数简单60098%2中等30093%15困难10082%38看到没有困难样本只占10%但贡献了73%的关键错误。如果你只看总体一致率95%你会觉得模型很好但如果你看困难样本的一致率82%你就知道模型在真正难的地方还有很大提升空间。提示永远不要只看总体一致率。一定要按难度、按场景、按错误类型分层看。分层之后你才能知道模型到底哪里不行。4.2 类别不平衡准确率高不代表召回率高假设你的评测集里90%的case是“模型应该回答A”10%是“模型应该回答B”。模型把所有case都回答成A准确率也有90%。但它在B类上的召回率是0。这就是类别不平衡带来的假象。解决方法是在评测指标里加入召回率和F1而不是只看准确率。对于安全审核、内容过滤这类场景召回率比准确率重要得多。你宁可误杀也不能漏放。具体怎么算举个例子真实为正类应该拦截的case有100条模型拦截了80条召回率80%。真实为负类不应该拦截的case有900条模型误拦了50条准确率 80/(8050) 61.5%。如果你只看准确率61.5%很难看但如果你看召回率80%还可以接受。关键是你的业务能容忍多少误杀。这个权衡必须在评测指标里体现出来。4.3 机评模型的“偏见”它可能和被测模型犯同样的错这是最隐蔽的陷阱。如果你用一个和被测模型同源、同架构、同训练数据的模型去做机评那它们很可能在同样的地方犯错。机评模型觉得“这个回答没问题”被测模型也觉得“这个回答没问题”一致率当然高。但人工一看两个都错了。避免这个陷阱的方法是机评模型和被测模型要异构。如果被测模型是基于A架构的机评模型最好用B架构如果被测模型是生成式的机评模型可以用判别式的。甚至可以用多个不同来源的机评模型做投票减少单一模型的偏见。我自己的做法是机评模型至少用两个一个基于规则小模型一个基于大模型。两者一致时结果可信度高两者不一致时交给人工。这样虽然成本高一点但能有效避免“同谋”问题。5. 一套能抓错的eval流程长什么样5.1 从“算分”到“抓错”的思维转变大多数团队的eval流程是跑模型 - 算指标 - 看报告 - 决定是否上线。这个流程的问题是它只告诉你“模型行不行”不告诉你“模型哪里不行”。我想要的eval流程是跑模型 - 机评筛选 - 人工复核 - 错误归因 - 形成改进清单。核心区别在于eval的终点不是分数而是错误清单。具体来说每次eval之后我应该得到这样一份东西模型在哪些场景下表现好哪些场景下表现差。差的表现具体是什么错误类型事实错误、逻辑错误、安全错误、格式错误。每个错误类型对应的典型case是什么。这些错误里哪些是可以通过prompt优化解决的哪些需要微调哪些需要数据补充。没有这份清单eval就是白做。5.2 错误归因把“不一致”翻译成“可行动项”错误归因是eval流程里最容易被忽略、但价值最高的环节。我通常把错误分成四类错误类型定义改进方向知识错误模型不知道某个事实补充知识库、RAG推理错误模型知道事实但推理错了优化prompt、few-shot对齐错误模型理解错了用户意图意图识别优化、多轮澄清安全错误模型触碰了红线安全层加固、拒答策略分类之后每个错误类型对应不同的改进动作。知识错误补数据推理错误调prompt对齐错误加澄清安全错误加规则。这样你的优化就不是盲目的“再训一版”而是有针对性的。5.3 一个可复用的eval脚本框架下面是我常用的eval脚本框架用Python写的核心逻辑是“机评筛选 人工复核 错误归因”import json from collections import defaultdict class EvalPipeline: def __init__(self, machine_scorer, human_annotator, error_classifier): self.machine_scorer machine_scorer self.human_annotator human_annotator self.error_classifier error_classifier def run(self, cases): results [] for case in cases: # 第一步机评 machine_result self.machine_scorer(case) # 第二步判断是否需要人工复核 if self._need_human_review(machine_result): human_result self.human_annotator(case) final_label human_result source human else: final_label machine_result source machine # 第三步错误归因 if final_label.get(is_error): error_type self.error_classifier(case, final_label) else: error_type None results.append({ case_id: case[id], source: source, label: final_label, error_type: error_type }) return self._summarize(results) def _need_human_review(self, machine_result): # 机评得分在中间区间或者多维度矛盾时需要人工 scores list(machine_result[scores].values()) if max(scores) - min(scores) 0.4: return True if 0.4 sum(scores)/len(scores) 0.8: return True return False def _summarize(self, results): summary defaultdict(int) for r in results: if r[error_type]: summary[r[error_type]] 1 return { total: len(results), human_reviewed: sum(1 for r in results if r[source] human), error_distribution: dict(summary) }这个框架的关键在于_need_human_review函数。它决定了哪些case交给人工哪些直接采纳机评。阈值可以根据你的业务容忍度调整。如果业务对错误很敏感就把阈值放宽多交人工如果业务迭代快、容忍度高就把阈值收紧减少人工。5.4 评测报告怎么写才有用最后说一下评测报告。我见过太多评测报告满篇都是数字但没有一句话能指导行动。好的评测报告应该回答三个问题模型现在能不能上线给出明确的go/no-go建议以及理由。如果不能上线最需要改什么按优先级列出top 3改进项。如果能上线风险是什么列出已知的边界case和监控指标。报告里不要只放总体指标要放分层指标、错误分布、典型case。最好附上错误case的原始输入和模型输出让读报告的人能直接看到问题。提示评测报告是给决策者看的不是给算法同学看的。决策者不关心F1是多少他们关心“上线会不会出事”。所以报告的第一页应该是结论和风险第二页才是数据细节。6. 那些年我踩过的eval坑6.1 坑一用测试集调prompt这是最经典的坑。你有一个测试集你根据测试集的表现调prompt调完之后测试集指标上去了你以为模型变好了。但实际上你只是把模型过拟合到了测试集上。上线之后真实表现可能反而下降。正确做法是测试集只能用来看不能用来调。调prompt要用开发集开发集和测试集要严格分开。如果数据不够至少要做交叉验证不能反复用同一批数据调。6.2 坑二忽略“拒答”和“澄清”的评测很多评测集只评“模型回答得对不对”不评“模型该不该回答”。对于安全敏感的场景模型拒答一个正常问题和模型回答一个危险问题都是错误。但很多评测集里根本没有拒答样本导致模型学会了“什么都答”上线之后安全风险极高。我的做法是评测集里必须包含一定比例的“应该拒答”和“应该澄清”的样本。比如用户问“怎么制作危险物品”模型应该拒答用户问“帮我订机票”但没说时间和目的地模型应该澄清。这些场景的评测和普通问答一样重要。6.3 坑三评测频率太低有些团队一个季度才做一次完整评测模型迭代了十几个版本但评测报告还是三个月前的。这导致优化方向严重滞后。我的建议是轻量评测每次迭代都做完整评测每月一次。轻量评测可以只用固定集里的核心样本快速跑一个指标完整评测用全量评测集做分层分析和错误归因。这样既能快速反馈又能定期深入。6.4 坑四不记录评测历史评测结果不存档每次评测都是“一次性”的。这导致你无法回答“模型是在哪个版本开始变差的”这个问题。我的做法是每次评测结果都存到一个结构化数据库里包含模型版本、评测集版本、评测时间、各项指标、错误分布。这样你可以画趋势图看模型是在哪个版本、哪个指标上出现了退化。这个信息对于定位问题非常关键。7. 写在最后eval不是成本是投资我刚开始做AI产品的时候也觉得eval是“额外工作”——模型都训好了跑个分不就行了后来踩的坑多了才明白eval不是成本是投资。一个好的eval体系能让你在模型上线前就发现80%的问题能让你在优化时知道往哪个方向使劲能让你在汇报时拿出有说服力的数据。那个95%一致率的故事后来怎么样了我朋友回去之后把那5%的不一致case全部捞出来逐条分析发现了一个安全漏洞和两个意图识别问题。他们花了两周修复上线之后客诉率下降了40%。他后来跟我说“那5%才是真正值钱的东西。”所以下次你看到95%一致率的时候别急着高兴。先问问自己那5%是什么你看过了吗