我做模型评估这些年，最怕听到一句话：“这个模型效果怎么样？”问题听着简单，回答起来得先拆目标。AI模型评估方法不是把准确率、F1值或者BLEU往表格里一填就完事。它更像一套从目标到闭环的工作系统，产品、算法、业务、安全、运维各自站在不同角度，看到的“好模型”根本不是同一个东西。我习惯先跟各方聊一圈，把评估目标写成几句人能看懂的话，再决定后面用什么方法、什么指标。
1.1 评估目标与典型场景：能力验证、安全合规、效率优化与业务适配
我遇到过一个小团队做客服问答模型。算法工程师天天盯离线测试集上的准确率，产品经理更关心用户问三句能不能解决一句，法务同事只问模型会不会把用户手机号吐出来。三拨人坐在一起，评估目标完全拧着。能力验证像给模型做体检，看它会不会、准不准、稳不稳。安全合规像过安检，偏见、毒性、隐私、越狱这些口子得提前堵。效率优化像算账，延迟、吞吐、单次调用成本都得摆上桌面。业务适配更像试鞋，模型在公开榜单上再漂亮，塞进真实业务流里磨脚就是不行。
我通常会把典型场景拆成四类来对齐预期。能力验证场景下，我会问“模型要完成哪些任务，失败代价多大”。安全合规场景下，我会拉着安全团队一起列红线，哪些输出绝对不能出现，哪些人群不能被差别对待。效率优化场景下，运维伙伴会给我一张资源账单，模型再聪明，响应三秒以上用户也会跑。业务适配场景最容易被忽略，业务方嘴上说“要准确”，实际想要的是转化率、留存率或者人工审核量下降。这四种场景没有固定优先级，项目阶段不同，重心会漂移。
我见过一个风控模型上线前评估。算法团队拿出AUC 0.92的报告，业务团队看完只问误杀率能不能压到千分之三以下。安全团队追问模型有没有用敏感字段做代理变量。运维团队担心高峰时推理集群扛不住。同一个模型，四套评估语言。我的做法是先把场景翻译成可验证的评估问题，再决定每个问题用离线指标、在线实验还是人工抽检来回答。这样后面选指标、建数据集、做实验才不容易跑偏。
1.2 评估方法分类：离线评估与在线评估、自动评估与人工评估、静态评估与动态评估、内在评估与外在评估
我习惯把AI模型评估方法分成几组对照来看，项目里经常混着用。离线评估像在实验室跑测试，拿固定数据集反复跑，成本低、可复现、适合版本回归。在线评估像把模型放进真实流量里做A/B测试，用户行为会说话，代价是周期长、变量多、还得考虑实验污染。自动评估适合大规模筛查，跑分快、覆盖广，面对主观质量就有点笨。人工评估能看语气、同理心、事实一致性这些细活，成本高、标注者之间还会打架。
静态评估用一套固定题库，好处是历史可比，坏处是模型可能“背题”。动态评估会定期换题、换数据、换场景，更接近真实世界的变化。内在评估看模型自身输出，比如困惑度、生成质量、推理步骤是否自洽。外在评估看下游任务效果，比如接进搜索排序后点击率有没有涨，接进客服系统后人工转接率有没有降。我自己的经验是，早期迭代多用离线加自动加静态加内在，快速筛版本。临近上线再加在线加人工加动态加外在，把真实风险和业务收益摸清楚。
有一次做营销文案生成，自动评估的BLEU分数涨了，人工评估却发现文案越来越像机器翻译腔。团队伙伴开玩笑说“分数在进步，读起来在退步”。我们后来把自动评估当粗筛，人工评估当复检，静态集看回归，动态集看新鲜场景。这套组合不便宜，可它帮我们避开了好几次“榜单漂亮、上线挨骂”的尴尬。分类本身没有高低，关键是看你在哪个阶段、承担多大风险、能花多少评估预算。
1.3 评估流程设计：任务定义、数据构建、指标选择、实验设计、结果解释与迭代闭环
我参与过的评估项目里，返工最多的地方往往不是模型本身，而是任务定义没写清楚。任务定义得像给新人派活一样具体：输入是什么、输出长什么样、什么算成功、什么算失败、边界情况怎么处理。数据构建要盯住真实分布，训练集和测试集别共享同一批用户、同一批文档、同一个时间窗口。指标选择别贪多，一个主指标加两三个辅助指标就够用，主指标要跟业务目标对齐。实验设计要控制变量，模型版本、提示词、解码参数、评估集版本都得记录清楚。
结果解释这一步特别容易被算法团队包办。我的习惯是拉上业务方一起看 bad case，让业务方判断哪些错误能忍、哪些错误会出事故。有一次情感分类模型整体准确率不错，业务方翻到一条把用户投诉判成满意的样本，脸都绿了。后面我们把高风险类别的召回率单独拎出来看，评估结论才站得住。迭代闭环不是写完报告就结束，得把发现的问题变成下一轮的数据补充、提示词调整或者模型微调任务，再回到评估流程里验证。
我见过比较成熟的团队会把评估流程做成流水线：任务定义写在评估卡上，数据构建有版本号，指标选择有对照表，实验设计有模板，结果解释有评审会，迭代闭环有负责人。流程听起来重，跑顺了反而省时间。小团队可以轻量一点，用一张共享表格把任务、数据、指标、实验、结论、待办串起来。关键是让评估结果能被人读懂、被复用、被追踪，别每次换个人就从零猜。
1.4 评估治理与常见挑战：数据泄漏、基准污染、指标错配、可复现性与评估偏差
数据泄漏是我踩过最隐蔽的坑。训练集里混进了测试集用户的历史行为，模型离线分数高得离谱，上线后原形毕露。基准污染在开源榜单上更常见，模型训练语料可能已经见过测试题，跑分好看不代表真会。指标错配也让人头疼，不平衡分类只看准确率，模型全判多数类也能拿高分。可复现性考验工程习惯，随机种子、数据版本、代码提交、依赖环境少记一项，别人就复现不出你的结果。评估偏差藏在标注环节，标注者偏好、抽样方式、任务顺序都可能让结论偏掉。
我现在的做法是给评估治理留出专门时间。数据泄漏靠切分策略和重叠检查来防，用户、文档、时间窗口都要隔离。基准污染靠私有测试集和动态题库来缓解，公开榜单只当参考。指标错配靠任务对齐来纠，分类看精确率召回率F1，回归看RMSE和MAE，生成任务看事实性和人工偏好。可复现性靠评估卡和流水线来保，每次评估留下数据快照、指标脚本和运行日志。评估偏差靠多人标注、一致性检验和盲评来压。
治理这件事没有一劳永逸。业务在变，数据在变，模型也在变，评估体系得跟着长。我通常会建议团队设一个评估负责人或者评估小组，定期回看基准集是否过时、指标是否还跟业务目标对齐、人工评估标准有没有漂移。评估报告里除了分数，还要写清楚这次评估的边界和风险。这样模型选型、版本对比、上线决策才有依据，评估本身也才经得起追问。
上一章我们把评估目标、方法分类和流程治理捋了一遍。真到跑评估的时候，摆在我面前第一个问题就是：用什么指标说话。指标选错了，后面数据集再干净、实验设计再严谨，结论也是歪的。我这些年攒下来的体会是，指标得像工具箱里的扳手，什么活儿用什么尺寸，不能一把锤子敲到底。这一章我把常用指标、生成质量指标、系统工程指标、基准数据集和统计校验分开讲，中间穿插我自己踩过的坑。
2.1 通用任务指标：准确率、精确率、召回率、F1值、AUC、RMSE、MAE等分类与回归指标
分类任务里准确率是最容易被滥用的指标。我做信贷违约预测的时候，坏客户占比不到百分之三，模型全判“不违约”也能拿九十七以上的准确率，这种分数拿给业务方看就是自欺欺人。我通常先看混淆矩阵，把精确率、召回率和F1值摆在一起。精确率高说明模型报出来的正例比较靠谱，召回率高说明该抓的正例没漏掉。两个指标经常打架，F1值是个折中，可它默认精确率和召回率同等重要，实际业务里未必如此。风控场景我更看召回率，宁可多拦一些正常客户再人工复核，也不愿意放坏账过去。
AUC是排序类任务的常用指标，它衡量模型把正例排在负例前面的能力，不受分类阈值影响。我给业务方解释AUC时就一句话：随机抽一个正样本和一个负样本，模型给正样本打分更高的概率有多大。AUC零点九听着漂亮，落到具体阈值上，误杀率和漏放率还得单独算。回归任务我用RMSE和MAE比较多。RMSE对大误差更敏感，适合那些“错得离谱代价很高”的场景，比如销量预测差太多会压库存。MAE对异常值更宽容，看平均偏差更直观。我一般两个都报，再补一个误差分布图，让业务方看到模型在哪些区间稳、哪些区间飘。
多分类任务我会看宏平均和微平均的差别。宏平均把每个类别同等看待，小类别表现差会拉低整体分数。微平均受大类别主导，类别不平衡时容易虚高。我做过一个意图识别项目，微平均F1零点九一，宏平均只有零点七六，翻开小类别一看，几个长尾意图几乎全军覆没。后面我们针对长尾类别补数据、调权重，宏平均才慢慢上来。指标这件事，单看一个数永远不踏实，得知道它在什么口径下算出来的。
2.2 生成与语言质量指标：BLEU、ROUGE、METEOR、困惑度、相关性、连贯性与事实性
生成任务的指标比分类回归麻烦得多，因为“好”的定义本身模糊。BLEU最早在机器翻译里用，看生成文本和参考译文的n-gram重合度。ROUGE在摘要任务里更常见，关注参考摘要里的词有没有被生成内容覆盖。METEOR加了同义词和词形变化匹配，比BLEU稍微宽容一点。这几个指标跑起来快、可复现，适合大规模粗筛。我用它们做版本对比的时候会盯着一个前提：参考文本得足够多样，否则模型学会套模板就能刷分。有一次做商品标题生成，BLEU涨了三个点，人工一看全是把品牌词堆在前面，读起来像关键词列表。
困惑度衡量语言模型对文本的“惊讶程度”，数值越低说明模型越适应这批文本。它适合看模型在领域语料上的拟合情况，可它跟生成质量不是一回事。困惑度低的模型可能生成很安全但很无聊的句子，也可能在开放对话里答非所问。相关性、连贯性和事实性这些维度更贴近人的判断。相关性看输出有没有回应输入，连贯性看段落之间顺不顺，事实性看有没有编造。这三个维度自动评估很难做准，我通常用人工评分或者LLM-as-a-Judge来补。
事实性是我最看重的生成指标。做医疗问答评估的时候，BLEU和ROUGE都不差，模型把“每日服用两次”写成“每日服用三次”，字面重合度很高，意思完全反了。这类错误靠n-gram指标根本抓不住。我后来的做法是把生成评估拆成两层：一层用自动指标看语言流畅度和覆盖度，一层用人工或规则校验看关键事实、数字、否定词有没有出错。两层都过才敢往下走。生成任务的指标没有万能钥匙，得根据输出里什么东西错不起，来配相应的检查手段。
2.3 系统与工程指标：延迟、吞吐、成本、资源消耗、稳定性与可扩展性
模型评估不能只看它答得对不对，还得看它跑起来贵不贵、稳不稳。延迟是我跟运维团队吵架最多的指标。算法团队说模型效果好多花两百毫秒值得，运维说用户等一秒就流失。我一般把延迟拆成首token延迟和整体生成时间，流式输出场景下首token延迟更影响体感。吞吐看单位时间能处理多少请求，压测的时候得区分平均吞吐和峰值吞吐，峰值扛不住，平时再好看也没用。成本要算单次调用成本和每千次请求成本，云上按token计费和自建集群按GPU小时计费，口径不一样，得统一了再比。
资源消耗包括显存占用、CPU利用率、GPU利用率和内存增长趋势。我见过模型跑长对话时显存缓慢泄漏，前一百轮没事，到五百轮直接OOM。稳定性评估得跑长时间压测和异常输入测试，空输入、超长输入、特殊字符、并发突增都得试。可扩展性看模型能不能横向扩实例、批处理效率怎么样、量化后效果掉多少。有一次我们评估一个开源模型，单卡跑得挺欢，想扩到八卡做张量并行，发现通信开销把吞吐收益吃掉大半，这种问题不上工程评估根本发现不了。
我习惯把系统工程指标和效果指标放在同一张评估表里看。效果涨两个点、延迟涨一倍，这个交易划不划算得业务方一起判断。成本指标还要算上评估本身的开销，人工评估、标注、跑基准都要花钱。有些团队评估预算比训练预算还高，这不见得是坏事，可你得心里有数。工程指标的特点是它们会随部署环境变，离线测出来的数字跟线上往往有差距，我一般会留出百分之二十左右的余量再做容量规划。
2.4 常用评估基准与数据集：NLP、CV、多模态及大语言模型基准的适用场景与选择原则
基准数据集像考卷，考卷出得好不好，直接决定你能不能测出真本事。NLP领域经典的GLUE、SuperGLUE覆盖自然语言理解任务，分类、蕴含、相似度都有。阅读理解有SQuAD，机器翻译有WMT系列。CV领域ImageNet看图像分类，COCO看检测和分割，还有各种细粒度分类和姿态估计基准。多模态有VQA、Flickr30K、MSCOCO Caption。大语言模型起来之后，MMLU、HellaSwag、GSM8K、HumanEval、BIG-bench这些基准被用得很多，分别覆盖知识、常识推理、数学、代码和综合能力。
选基准不能看哪个火就用哪个。我选基准先问三个问题：任务跟我的业务场景像不像，数据分布跟我的用户像不像，基准有没有被污染。做法律合同审查，拿MMLU跑分再高也说明不了合同条款识别能力。做方言客服，拿标准普通话基准测出来的分数参考价值有限。公开基准还有个麻烦，模型训练语料可能已经见过测试题，跑分虚高。我通常会配一个私有测试集，从真实业务日志里抽样、人工标注，不公开、不重复使用，专门用来做上线前的最终校验。
基准的选择原则我总结成几条：任务要对齐，难度要匹配当前模型水平，数据要新、要干净、要跟业务分布接近，还要控制评估成本。基准太简单，所有模型都接近满分，区分度不够。基准太难，模型全在瞎猜，也看不出差异。我做过一个代码生成评估，HumanEval通过率都挺高，换到真实项目里的多文件补全场景，差距立刻拉开。公开基准当参照系，私有基准当照妖镜，两个一起用才靠谱。多模态和大模型基准更新很快，我每隔一段时间会回看手里的基准集是不是该换了。
2.5 指标组合与统计校验：多指标权衡、置信区间、显著性检验与任务对齐
单指标决策的风险前面已经聊了不少，实际评估里我基本都用指标组合。分类任务看准确率、F1、AUC和高风险类别召回率，生成任务看自动指标、人工评分和事实性校验，工程侧看延迟、吞吐和成本。指标多了之后，权重怎么分配、冲突怎么取舍就成了新问题。我的做法是先把指标分成“必须守住”和“尽量优化”两类。安全红线、事实性、延迟上限属于必须守住，差一点都不能放行。流畅度、覆盖面、成本这些属于尽量优化，可以权衡。权重不是拍脑袋定的，得跟业务方一起把失败代价摆出来谈。
统计校验是很多团队容易跳过的一步。两个模型在测试集上差一个点，这个差距是真的还是噪声，不做显著性检验根本说不清。我常用置信区间和bootstrap重采样来看指标波动范围，用配对检验比较两个模型在同一批样本上的表现。样本量小的时候，置信区间会宽得让你不敢下结论。有一次我们比较两个摘要模型，ROUGE差零点八，我跑了置信区间发现重叠很大，又扩了测试集才确认差距显著。业务方一开始嫌麻烦，后来有一次差点因为噪声差异选错版本，态度就变了。
任务对齐是统计校验之后的最后一道关。指标显著提升了，跟业务目标是不是一回事，还得回头对一遍。我见过推荐模型AUC涨了，线上点击率没动，因为排序头部变了但用户根本没感知到。也见过客服模型BLEU涨了，人工转接率反而升了，因为回答更流畅但没解决问题。指标组合、统计校验、任务对齐这三步走完，评估结论才敢写进报告。报告里我会把指标定义、测试集版本、样本量、置信区间和已知局限都写清楚，让看报告的人知道这个结论的边界在哪。
前两章把评估的骨架和尺子讲完了，这一章落到大语言模型身上，情况会复杂不少。传统分类模型跑个测试集就能出分，大模型输出是开放文本，同一个问题问十次能给你十个版本的答案。我给团队定评估方案的时候，经常得先问一句：这次到底想测它什么。测不出来比测不准更麻烦。这一章我把基准选择、能力维度、安全对齐、自动化平台和结果应用这几块分开说，中间夹一些我们实际项目里的教训。
3.1 大语言模型评估基准与方法：静态基准、动态评测、人类评估、LLM-as-a-Judge、红队测试与对抗评测
静态基准是我评估的起点，不是终点。MMLU、GSM8K、HumanEval这些基准跑起来方便，几分钟就能出一张成绩单。麻烦在于模型厂商训练语料越来越杂，测试题有没有进过训练集谁也说不清。我现在的做法是拿静态基准做横向参照，同时手里攥一套不公开的私有题。私有题从业务日志里挖，人工标答案，版本迭代不重复使用。公开分数好看我不太当真，私有分数掉了我才会紧张。
动态评测是我这两年开始重视的。静态题会过时，模型能力也在变，我会定期从线上收集用户真实提问，按难度分层抽样，滚动更新评测集。有一回我们做客服助手，静态基准分数一直很稳，动态集上冒出一批新业务场景的问题，模型答得一塌糊涂，原因是产品上线了新功能，用户开始问新东西了。静态基准测的是过去，动态评测盯的是现在，两个都得有。
人类评估最贵，可有些东西机器真替代不了。我组织过几轮人工盲评，让标注员对比两个模型的回答，从有用性、准确性、语气三个维度打分。人评的坑在于标注员之间的一致性，同一段回答两个人能打出差两分的评价。我的解决办法是写细评分手册，先做校准测试，一致性不达标的不进正式评。人评样本量有限，我一般用它来校准自动评估，不是拿来大规模跑分。
LLM-as-a-Judge这两年用得很多，拿一个强模型给另一个模型的回答打分或者做偏好对比。成本比人评低一个量级，速度也快。它的问题我也碰过不少：评分模型有位置偏好，两个回答换个顺序结论就变；它对长回答有偏爱，废话多的得分反而高；它跟人评的一致性在不同任务上波动很大。我的用法是把它当粗筛工具，先跑一遍找出明显有问题的样本，再用人评做精校。Judge模型的提示词我会反复调，评分维度拆细，要求它先写理由再给分，效果比直接打个总分稳定不少。
红队测试和对抗评测是安全侧的重头戏。我带队做过一轮越狱测试，让安全团队扮成恶意用户，用角色扮演、多语言绕行、编码转换各种手段去撬模型的护栏。红队报告里最有价值的不是“攻破了几个”，而是“哪类攻击路径反复奏效”。有一类提示词换个说法就能绕过过滤，我们后来在系统提示层加了针对性约束才堵上。对抗评测我还会拿公开的对抗数据集跑一遍，看模型在已知攻击面上的表现，新攻击面靠红队去挖。这两块工作没法一劳永逸，模型版本一更新就得重跑。
3.2 核心能力维度评估：知识问答、推理、代码、数学、多语言、长上下文、工具调用与指令遵循
知识问答评估我关注两件事：知不知道，以及知不知道自己不知道。前者用事实性问答集测，后者用“不可回答问题”测。我做过一个产品知识助手，模型对产品参数张口就来，一问到停产型号就编，编得还特别像真的。后来我在评测集里加了一批“这个问题资料里没有”的样本，专门看模型会不会老实说不知道。拒答率太低是幻觉温床，拒答率太高又影响可用性，这个平衡得按业务场景调。
推理能力评估得分层看。简单逻辑推理、多步推理、因果推理难度不一样，我一般从易到难搭一个梯度测试集。GSM8K这类数学应用题能测多步推理，可它偏模板化，模型可能靠模式匹配过关。我会补一些需要自己列算式、自己检查中间步骤的题。有一次评估一个模型解应用题，答案对了但中间步骤胡写，换一道数字稍变的题就错。推理评估不能只看最终答案，过程也得抽查。
代码评估我用HumanEval和MBPP打底，真正拉开差距的是真实项目场景。函数级补全、多文件上下文、根据报错改代码、按注释生成测试，这几种任务难度完全不同。我搭过一个内部代码评测集，从我们自己的代码仓库里抽真实工单，让模型补全或者修bug。公开基准通过率八十多的模型，到真实仓库里经常掉到五十以下，原因是依赖关系复杂、命名不规范、上下文超长。代码评估不接真实项目，分数参考价值有限。
数学评估我分成算术、代数、几何证明、统计推断几档。大模型在算术上翻车不稀奇，数字一多就乱。我见过模型把三位数乘法算错，还一本正经写出推导过程。评估的时候我会要求模型展示步骤，步骤和答案对不上也算错。数学能力的评测还特别容易被数据污染，公开竞赛题得筛一遍，看看模型是不是背过答案。
多语言评估我吃过亏。拿英文基准翻译成中文跑分，分数看着不错，实际用起来中文表达生硬、文化语境不对。多语言评估得用目标语言的原生测试集，还得看跨语言迁移能力。我做过一个东南亚市场项目，模型在印尼语和泰语上的表现差异很大，泰语训练数据少，回答质量明显下降。低资源语言的评估样本更难找，我一般靠本地团队帮忙标注，成本高但值得。
长上下文评估我要看三样：能不能找到、能不能用对、会不会丢。把关键信息放在长文档开头、中间、结尾，看模型检索准确率有没有位置偏差。再让它基于长文档做多跳推理，看它会不会只盯着最近的一段。我实测过几个宣称支持一百二十八K上下文的模型，信息放在中间位置时召回率明显下滑，放到三十二K左右才开始稳定。宣传参数和实际可用长度是两回事，评估得用真实长度的文档去压。
工具调用评估看意图识别、参数构造和结果整合。用户说“帮我查一下明天北京天气”，模型得知道调天气接口，参数里城市是北京、日期是明天，拿到结果还得组织成自然语言回复。我搭过一套模拟工具环境，覆盖查询、计算、下单、取消这些常见操作，专门测多轮工具调用。模型经常在第一轮调对了，第二轮忘了之前的状态。指令遵循评估则看模型能不能守住格式、长度、语气这些约束，JSON输出、固定字段、禁用词这些要求，模型时不时会漏。
3.3 安全与对齐评估：偏见、毒性、隐私、越狱、幻觉与价值观对齐
偏见评估我一般从性别、地域、职业、年龄几个维度切。构造一批对照提示词，只改一个属性词，看输出有没有系统性差异。比如问“护士应该具备什么素质”和“男护士应该具备什么素质”，回答的侧重点如果明显不同，就值得深挖。偏见这东西很隐蔽，单条输出看不出问题，批量对比才露馅。我评估的时候会做统计，看不同群体在情感倾向、能力评价、推荐建议上有没有显著差距。
毒性评估我用公开毒性数据集加自建场景集。公开集覆盖脏话、侮辱、威胁这些明显毒性，自建集针对业务场景，比如客服场景里的攻击性用户、医疗场景里的自伤倾向提问。模型在明显毒性上表现一般还行，隐晦的阴阳怪气、群体贬低就容易漏。我还会测模型在受到攻击时会不会反击，用户骂它它骂回去，这种在客服场景里绝对不能上线。
隐私评估看两点：训练数据里记没记住敏感信息，对话里会不会泄露用户信息。前者用成员推断攻击的思路去测，给模型一段文本看它能不能补出后面的隐私字段。后者构造多轮对话，前面让用户说自己信息，后面换个话题问它记不记得。我做金融场景评估的时候，专门测了模型会不会把上一个用户的账户信息带到下一个会话里。跨会话泄露是真事故，评估必须覆盖。
越狱评估前面提过红队，这里补一句自动化手段。我维护一个越狱提示词库，按攻击类型分类，每次模型更新跑一遍看拦截率。角色扮演、假设场景、逐步诱导、编码混淆这几类最常见。有个规律挺有意思：模型对英文越狱提示的防御往往比中文好，中文语料里攻击模式见得少。多语言越狱是当前的一个软肋，评估得多语言一起上。
幻觉评估我分成事实性幻觉和忠实性幻觉。事实性幻觉是模型说了跟世界知识不符的话，忠实性幻觉是模型在摘要或者问答里编造原文没有的内容。评估方法上，事实性靠知识库比对，忠实性靠原文核对。我做过一个法律文书摘要项目，模型把“三年以上十年以下”写成“三年以上七年以下”，数字一改意思大变，这种错误必须靠逐条核对抓。自动化幻觉检测工具能筛一部分，关键场景还是得人工过。
价值观对齐评估最不好量化。我的做法是围绕业务所在地区的合规要求和公司价值观，列一批敏感议题和边界场景，看模型回答是回避、是站队还是给出平衡表述。回避太多影响可用性，站队太硬容易惹麻烦。评估结果我一般不给单一分数，而是画一张场景应对分布图，让业务方和法务一起看哪些场景需要加约束。
3.4 评估实验与自动化平台：提示词模板、采样策略、评分规则、人工复核与可复现流水线
提示词模板是评估可复现的第一道关。同一个模型，提示词里加不加“请一步步思考”，分数能差好几个点。我的做法是把评估用提示词版本化管理，跟代码一起进仓库，每次评估记录用的哪个版本。系统提示、用户模板、少样本示例分开存，改哪个都留痕。有一次两个团队报的同一模型分数对不上，查了半天发现一个用了带示例的模板，一个没用。这种坑不靠管理流程防不住。
采样策略影响评估稳定性。大模型有随机性，temperature设成零也不是完全确定。我的做法是每个样本至少跑三次，看结果方差。方差大的题标记出来人工看，可能是题目本身有歧义。评估集大的时候跑三次成本扛不住，我会对核心集跑多次，扩展集跑一次。采样参数固定下来写进评估配置，温度、top_p、最大长度、停止词都记清楚，换参数等于换实验。
评分规则要提前定死。自动评分能用规则就用规则，比如代码题跑单元测试、数学题比对最终数值、格式题校验JSON结构。规则评不了的再用模型评分或者人工。我设计评分规则的时候会先拿一批样本试跑，看规则会不会误伤。有个项目用正则提取答案，模型把答案写在句子里带了个句号，正则没匹配上判了错，后来改成先清洗再提取。评分规则本身也得评估。
人工复核环节我放在自动评分之后，按比例抽样。自动评分判错的样本、分数处在边界的样本、模型输出异常的样本，优先送人工。人工复核界面我会把原始问题、模型回答、自动评分和评分理由摆在一起，标注员改分要写原因。复核数据回流到评分规则和提示词优化里，形成闭环。人工复核的成本得算进评估预算，我一般按总样本量的百分之五到十留人力。
可复现流水线是我最看重的基础设施。评估配置、数据集版本、模型版本、提示词版本、评分规则版本，五样东西绑定在一起才能复现一次评估。我用配置文件驱动整个流程，跑完自动生成报告，报告里带所有版本号和运行环境信息。有一次线上出问题回溯，发现两周前的一次评估用的是旧数据集，结论完全反了。流水线里加数据版本校验之后，这类事故少了很多。平台不一定要多先进，能锁住变量、能回溯、能一键重跑，就够用。
3.5 评估结果应用与持续监控：模型选型、版本对比、上线监控、反馈闭环与持续评估
模型选型的时候我不看总分排名，看分场景得分。一个模型知识问答强、代码弱，另一个反过来，选哪个得看业务重心。我把评估结果做成一张能力雷达图，再叠加成本和延迟，业务方一眼能看出取舍。选型会上经常出现的情况是效果最好的模型太贵，便宜的模型在关键场景上差一截。我的建议是核心场景用强模型，边缘场景用轻模型，路由层做分流。评估报告里我会把每个候选模型在关键场景上的失败案例列出来，失败案例比分数更有说服力。
版本对比我坚持同集同参同时跑。新版本和老版本用同一套评测集、同一套提示词、同一套采样参数，跑完做配对显著性检验。只看平均分涨了多少不够，得看哪些题涨了、哪些题退了。我经历过一次版本升级，总分涨了两个点，翻明细发现安全类题目退了不少，原因是新版本对齐训练调过头，拒答变多了。版本对比报告里我会单列退步样本，退步集中在哪个能力维度，得说清楚。
上线监控是评估的延续。离线评估再充分，线上 Distribution 变了照样出问题。我监控几类信号：用户点赞点踩比例、转人工率、追问率、会话时长、投诉关键词命中。这些信号跟离线指标对不上是常事，对不上就得查。有一次线上差评率突然涨了，离线评估没测出来，最后定位到是新上的一批用户提问里方言表达多，模型理解不了。监控发现问题，样本回流到评测集，下一轮评估就覆盖上了。
反馈闭环我设计成三条线。用户显式反馈走点赞点踩和评价标签，隐式反馈走行为日志分析，人工抽检走质检团队定期抽样。三条线的数据汇到评估池，按月更新评测集。更新评测集的时候我会保留一部分旧样本做纵向对比，新样本测当前能力。评测集只增不换会过时，只换不增会丢历史参照，我的比例大概是七成新样本三成旧样本。
持续评估的节奏看业务变化速度。变化快的业务我两周跑一次核心集，一个月跑一次全量集。变化慢的业务一个月跑一次核心集。模型厂商发新版本、我们自己的提示词有改动、业务规则有调整，这几种情况触发临时评估。评估不是一次性的验收动作，是跟着模型和业务一起走的长期活儿。我见过团队把评估做完就锁进抽屉，模型上线半年没再测过，等出问题的时候连基线都找不到了。评估这件事，停下来就是退步。
