语义分析任务做到模型评估与优化这一步往往是最磨人的阶段。前面数据清洗、标注、微调跑通demo 效果看着不错一旦要把这套自然语言处理能力真正推到业务线上问题全冒出来了离线指标涨了两个点线上投诉却没减少人工抽查感觉变好了评审会上又拿不出能服人的证据好不容易把分数刷上去换个测试集又掉回来。这篇内容聊的就是大模型时代语义分析的模型评估与优化怎么落地——指标体系怎么搭、评估集怎么造、错误怎么归因、优化手段按什么顺序上。适合已经跑通过一次微调或 Prompt 调优、正准备把语义分析模块交付出去的同学也适合带团队、需要一套可复用评估流程的负责人。下面全部是我在实际项目里趟出来的做法有具体参数、有代码片段、有踩过的坑。1. 语义分析的评估为什么不能照搬分类任务那一套1.1 一个语义有无数种正确说法指标天然失真做文本分类出身的人第一次做语义分析最容易犯的错是拿 accuracy 当北极星。分类任务的标签空间是封闭的标签对了就是对了语义分析不是这样。用户问这个订单还能不能改地址模型输出订单已发货地址无法修改建议联系配送方协商和包裹已经出库了改不了你打快递电话试试——这两句话字面重合度极低语义上却都是对的。你要是拿 BLEU 去打分第二个答案可能只有十几分直接判定为失败可人工看一眼就知道它更好因为它更像人说话。这就是语义分析评估的第一个根本矛盾输出空间是开放的参考答案却是有限的。任何基于字面匹配的指标本质上都在惩罚表达多样性而表达多样性恰恰是大模型最值钱的地方。我在一个意图归一化的项目里做过统计同一个语义槽位人工写了 5 条参考改写模型生成的 2000 条输出里有 37% 是字面不重合但语义正确的如果只按 ROUGE-L 卡阈值这 37% 全被误判成错误实际错误率被高估了近一倍。所以评估体系必须先解决怎么定义对这个问题再去谈怎么算分。我的做法是把判定拆成两层第一层是语义等价判定只关心意思对不对第二层是质量分层判定在语义正确的基础上再区分表达质量是否简洁、是否口语化、是否带了不该有的承诺。这两层的判定标准、抽样比例、责任人都不一样混在一起算一个总分最后谁都不认这个数。1.2 三层评估结构离线看趋势业务看方向线上看真相单看任何一层都会翻车这个我吃过亏。有一回离线指标从 0.82 涨到 0.87团队很高兴灰度 5% 之后业务侧的二次追问率反而涨了 3 个点——模型答得更标准了但用户觉得答非所问于是又问一遍。这就是典型的离线指标和业务指标脱钩。我现在的标准结构是三层每层的职责划清楚层级数据来源核心指标更新频率决策作用离线评估层固定评估集 对抗集语义等价准确率、ROUGE-L、BERTScore/向量余弦、格式合规率每次迭代判断要不要发版卡门槛业务代理层历史真实日志回放二次追问率、转人工率、采纳率、平均交互轮次每周判断优化方向对不对线上观测层灰度流量分场景成功率、P95 延迟、单次成本、负反馈率实时判断能不能全量、要不要回滚三层里最容易做错的是业务代理层。很多团队直接用线上 AB 实验问题是一次 AB 实验跑两周两周里你可能已经迭代了三个版本实验结论永远滞后。我更喜欢用日志回放把过去一个月的真实请求录下来脱敏后做离线回放对比新旧两版的输出差异和对应的业务代理指标。好处是快一天能跑完坏处是它只能反映当时那批用户的分布所以每个月必须重新采样一次日志不然评估集会逐渐和真实分布漂移。注意日志回放必须做严格的脱敏和去重同一个用户的重复请求只保留首次否则重度用户的行为会主导整个评估集。1.3 我踩过的第一个坑单一指标导致的刷分式优化早期我们只有一个综合分团队每周盯着那个数字。三个月后我复盘发现模型确实在涨分涨的方式却很畸形——它学会了输出更长、更全面的答案因为参考答案普遍偏长长答案的字面召回更高。结果就是延迟翻倍、成本翻倍用户还嫌啰嗦。这就是指标的可优化性问题任何单一指标只要被当成唯一目标模型或人都会找到投机的路径。解决办法不是换一个更好的指标而是让指标之间形成制衡。我现在固定配置一组互相牵制的指标任何一项恶化都要单独说明理由语义等价准确率主指标权重最高但单独上涨不算数平均输出长度防止靠啰嗦刷召回格式合规率结构化输出场景必看JSON 解析失败直接算错P95 首字延迟与总延迟用户体验硬约束单请求平均 token 消耗成本硬约束这套组合拳的价值在于它逼着优化者去找既准又短又快的解法而不是在单一维度上做无效内卷。后面第 4 节讲的上下文压缩、输出约束基本都是被这几个约束指标逼出来的。2. 指标体系怎么搭从字面匹配到模型裁判2.1 BLEU 和 ROUGE 还有没有用有但要用对地方先说结论这两个老指标在语义分析的主评估里不该做主指标但在两个场景里依然很好用——格式化输出的结构校验和回归检测。BLEU 的核心是 n-gram 精确率加简短惩罚。标准 BLEU-4 的权重是四个 gram 各 0.25公式里那个简短惩罚项 BP 在候选长度 c 小于参考长度 r 时取 exp(1 - r/c)否则取 1。这个设计本来是为机器翻译服务的翻译要求不漏译所以短答案要罚。语义分析里经常反过来——短答案往往更好这时候 BP 就在帮倒忙。我在实际使用中会把它改成对称惩罚或者在配置里直接关掉 BP只保留 n-gram 精确率部分。ROUGE-L 基于最长公共子序列对词序不敏感比 BLEU 更贴合中文语义分析尤其是抽取式任务。但它同样惩罚同义替换。下面这段是我现在常用的计算封装加了平滑和中文分词处理from nltk.translate.bleu_score import sentence_bleu, SmoothingFunction from rouge_score import rouge_scorer import jieba def tokenize_zh(text: str) - list: return [t for t in jieba.lcut(text.strip()) if t.strip()] def bleu4(cand: str, refs: list) - float: smoothie SmoothingFunction().method1 c_tok tokenize_zh(cand) r_tok [tokenize_zh(r) for r in refs] if len(c_tok) 2: return 0.0 return sentence_bleu(r_tok, c_tok, weights(0.25, 0.25, 0.25, 0.25), smoothing_functionsmoothie) scorer rouge_scorer.RougeScorer([rougeL], use_stemmerFalse) def rouge_l(cand: str, ref: str) - float: s scorer.score( .join(tokenize_zh(ref)), .join(tokenize_zh(cand))) return s[rougeL].fmeasure实测下来BLEU-4 在我们的语义改写任务上和人工判定的相关系数只有 0.41ROUGE-L 是 0.53都不算高。它们的真正价值是便宜、稳定、可解释——几万条样本几秒钟跑完做版本回归筛查完全够用。我的用法是先用 ROUGE-L 卡一个很低的底线比如 0.35把明显跑偏的样本筛出来剩下的进模型裁判或人工这样能省掉 60% 以上的裁判调用成本。2.2 语义相似度阈值必须自己标定别抄别人的向量余弦相似度是介于字面匹配和模型裁判之间的一个折中方案。它的好处是不需要参考答案的措辞一致只要向量空间里靠得近就行。坏处是阈值的尺度完全取决于你用哪个 embedding 模型抄别人的 0.8 是纯粹的赌博。标定方法不难但一定要做挑 300 条样本人工标成等价 / 部分等价 / 不等价三档然后算每个档位的余弦分布看两个分布的交叠区域在哪取交叠区间的中间值作为阈值。我在一个句向量模型上做过这个标定结果是等价档的余弦均值 0.91、标准差 0.04不等价档均值 0.72、标准差 0.09交叠区间在 0.80 到 0.84 之间最终阈值定在 0.82对应的等价召回是 0.93、误判率 0.07。这里有个容易忽略的细节长文本的余弦天然偏高。同一批模型在短句上区分度好在 200 字以上的段落上随便两段中文的余弦都能到 0.6 以上。所以按长度分段标定阈值是必要的我一般切成 30 字以内、30 到 100 字、100 字以上三档各用各的阈值。2.3 模型裁判LLM-as-Judge好用但坑比想象的多到了大模型时代最自然的想法是让一个强模型来当裁判。确实好用但如果不做偏差控制你得到的分数可能比 BLEU 还不靠谱。先说评分卡怎么设计。我用的是分维度打分 明确锚点而不是一个笼统的 1 到 10 分。原因很简单笼统打分时裁判模型的尺度会漂移同一批样本今天平均 7.2 分明天平均 6.8 分你根本不知道是样本变了还是裁判心情变了。分维度加锚点描述能大幅降低这种漂移。你是严格的语义一致性评审员。请依据给定材料判断【模型回答】是否在语义上与【参考要点】一致。 评分维度每项独立打分不要互相影响 1. 语义一致性0矛盾1部分相关但不完整2完全一致 2. 事实准确性0含明显错误信息1无法验证2与材料一致 3. 表达合规性0含不该出现的承诺/敏感表述2合规 判定规则 - 语义一致性必须为 2 且事实准确性不为 0才可判为「通过」 - 只要出现与参考要点相矛盾的具体数字、时间、主体直接判「不通过」 输出格式严格 JSON不要有任何额外文字 {semantic: 0|1|2, factual: 0|1|2, compliance: 0|2, pass: true|false, reason: 不超过30字}温度设 0这一点没有商量余地。另外三个偏差必须处理位置偏差做 A/B 对比时裁判模型会系统性地偏好排在前面的那个。解决办法很简单——每条样本跑两次第二次把 A、B 顺序对调只有两次结论一致才算有效判定不一致的进人工。这个操作让成本翻倍但把偏差从 8% 压到了 2% 以内值得。长度偏差裁判模型普遍偏好更长的答案。我在评分卡里显式加了冗余扣分维度后长度和通过率的相关性从 0.34 降到了 0.11。自我偏好裁判模型对自己家族生成的答案打分偏高。这个没法完全消除只能靠裁判与被评模型尽量不同源并且拿 200 条人工标注做校准算出裁判与人工的一致率。低于 0.8 的裁判直接不用。2.4 指标加权权重不是拍脑袋是用回归拟合出来的多个指标怎么合成一个总分我见过最多的是拍脑袋比如语义占 60%、格式占 20%、延迟占 20%。这种权重在评审会上永远吵不出结果因为没人能证明 60 比 50 更合理。更靠谱的做法是拿人工判定做因变量用逻辑回归拟合各指标权重。具体做法抽 500 条样本人工给通过/不通过的二元标签然后把语义分、ROUGE-L、格式合规、长度惩罚等作为特征做拟合看系数。系数就是权重而且带统计显著性能直接回答这个指标到底有没有用。我在最近一个项目里拟合出来的结果是语义等价判定系数 2.31、格式合规 1.47、长度惩罚 -0.62、ROUGE-L 只有 0.19 且 p 值 0.21不显著。这个结论直接让我们把 ROUGE-L 从总分里踢了出去只留作回归筛查用。指标不是越多越好不显著的指标只会稀释信号。还有一点总分一定要配置信区间。评估集只有 500 条的时候准确率从 0.842 涨到 0.856这个差异很可能完全在噪声范围内。用 bootstrap 重采样算 95% 置信区间两版的区间大幅重叠就说明没区别别急着开香槟import numpy as np def bootstrap_ci(correct: np.ndarray, n_boot2000, alpha0.05): n len(correct) stats np.array([ correct[np.random.randint(0, n, n)].mean() for _ in range(n_boot) ]) lo, hi np.quantile(stats, [alpha/2, 1-alpha/2]) return correct.mean(), lo, hi500 条样本、准确率 0.85 的情况下95% 置信区间大概是 ±0.031。这意味着任何小于 3 个点的提升你都得靠扩大评估集或者做配对检验才能下结论。配对比较我用 McNemar 检验只看两版判定不一致的那些样本结论比直接比准确率灵敏得多。3. 评估集怎么造这件事的价值被严重低估3.1 分层抽样先画场景矩阵再抽样本我见过不少团队评估集就是从线上日志里随机抽 1000 条抽完就固定下来一直用。这样做的后果是高频场景占了 80%低频但高风险的场景比如退款、投诉、合规敏感表述连 20 条都不到指标完全被高频场景主导一出事就是低频场景翻车。我的做法是先画场景矩阵。横轴是业务意图10 到 15 个纵轴是输入形态短问句、长描述、多轮上下文、含表格或代码、含否定或反问每个格子按业务风险定配额。风险高的格子至少 50 条中风险 30 条低风险 15 条。这样一个评估集约 800 到 1200 条覆盖度完全不一样。配额定好之后抽样策略也要讲究。纯随机抽样会让难例被淹没我一般按7:2:1混合70% 随机抽样保证分布代表性20% 难例历史错误、边界样本10% 对抗样本人为构造的诱导、歧义、超长输入。这个比例不是死的模型上线初期难例比例可以提到 30%因为那个阶段你最需要知道它在哪里崩。3.2 标注一致性Kappa 低于 0.7 就别往下做了语义分析的标注比分类难因为要判断意思一样不一样。我遇到过最尴尬的情况是两个标注同学对同一批 200 条样本一致率只有 76%算出来 Cohens Kappa 只有 0.52。这意味着人工标签本身的噪声就很大拿它当金标准去评估模型等于用一把不准的尺子量东西。Kappa 的计算是 (Po - Pe) / (1 - Pe)Po 是观察一致率Pe 是随机一致率。分类任务里 0.8 以上算好0.6 到 0.8 可接受。语义分析这种主观性强的任务我把门槛定在0.7低于这个数就必须回头改标注规范而不是硬着头皮继续。最容易产生分歧的三类情况规范里必须写死部分正确算不算对我的规则是语义等价必须覆盖全部核心要点漏任何一个关键要素时间、金额、主体、条件都判不通过不给部分分。更详细但没出错算不算对算对但如果超出参考范围引入了新信息进待核实单独一档不计入主指标。语气差异只要语义一致正式或口语都算对。但如果模型加了不该有的承诺肯定能退合规项直接判失败。规范写完还不算完得跑校准轮三个标注同学各标 100 条重叠样本一起过一遍分歧项把分歧原因归类回头改规范。这个流程我一般跑两轮Kappa 能稳定到 0.78 以上再开始大规模标注。3.3 对抗样本不是为了打模型是为了暴露脆弱面对抗样本在语义分析里主要是三类歧义型一句话有多个合理解释比如这个能退吗没有上下文退的是货还是钱还是订单模型必须学会追问而不是瞎猜。这类样本检验的是模型的请求澄清能力我一般要求模型在信息不足时明确追问而不是给一个四平八稳的模糊回答。否定与双重否定我不是不想退是超过时间了——这种句子里的真实意图和字面情绪完全相反。模型如果只做关键词匹配会把退当成正向意图。这类样本我一般从真实日志里捞比人工构造的自然得多。超长与噪声把三条无关的客服记录拼在一起或者塞进错别字、表情符号、重复字符。检验的是鲁棒性和截断策略。实话说大模型对这种输入的容忍度比想象中好真正的问题出在上下文窗口超限时的截断位置——如果截断把关键条件切掉了输出就是错的而且错得很隐蔽。3.4 数据污染检测与版本管理一个必须做的脏活评估集做久了必然面临一个问题它会不会被练进去尤其当你用同一批数据做微调或者做 few-shot 示例时。我现在的硬性规定是评估集与训练数据零交集并且在入库前做三道检查精确去重、n-gram 指纹去重8-gram 重合度超过 0.7 视为重复、向量近邻检测余弦超过 0.95 的样本对人工复核。版本管理上评估集必须带版本号和变更日志每次变更记录加了多少、删了多少、为什么。听起来很官僚但真出事的时候这是唯一能自证清白的材料。我就遇到过评审时被问你这个 0.87 是在哪版评估集上跑的答不上来的尴尬。4. 优化实操先归因再动手4.1 错误归因把效果不好拆成六类可执行的问题模型效果不达标时最没用的动作就是再调调 Prompt 试试。我现在的流程是先把所有错误样本做归因分类每类占比算出来再决定投入哪个方向。这套分类是我反复迭代出来的基本能覆盖 95% 的情况错误类型典型表现占比我的项目实测首选解法知识缺失答案本身没错但缺关键事实32%检索增强、补充上下文语义理解偏差把否定当肯定、主体搞错21%拆解任务、加中间推理步骤格式不合规JSON 少了字段、多了解释文字18%结构化输出约束、后处理兜底信息不足未追问该问的没问直接瞎答12%Prompt 加澄清规则、加置信度判断表达冗余正确但啰嗦、重复10%长度约束、输出模板幻觉编造数字、时间、政策7%强约束、事实校验层这张表最直接的价值是告诉你别一上来就做微调。32% 是知识缺失微调解决不了你喂多少数据它也不会突然知道某个具体商品的退换规则那是检索该干的事。反过来只有 21% 的理解偏差值得考虑微调而且这部分里还有一半能靠拆解任务解决。4.2 Prompt 优化的正确迭代方式一次只改一个变量Prompt 调优最大的陷阱是感觉改完更好了。我见过一个 Prompt 被改了 40 多版最后没人说得清哪一版最好因为每一版都同时改了示例数量、输出格式、系统指令变量全混在一起。我的做法是建一个变量登记表每次只动一个维度跑完评估集记录分数和置信区间确认显著再进下一个。常见的可调维度按收益排序大致是任务拆解方式一步到位 vs 先抽取再判断——收益最大经常能带来 5 到 8 个点示例的选择与数量0/2/5 shot示例是否覆盖边界情况——2 到 4 个点输出结构约束强制 JSON、先给结论再给理由——主要提升格式合规率角色与规则表述把请尽量准确换成具体的判定规则——稳定但边际收益递减温度、top_p 等采样参数——对确定性任务基本没用直接设 0关于 few-shot 示例有个反直觉的经验示例不是越多越好也不是越像越好。我做过一组对比5 个示例里如果全是同类简单样本效果反而不如 2 个示例一个典型、一个边界。原因是示例太多会让模型倾向于模仿示例的表面形式而不是理解判定逻辑。边界示例的价值远高于典型示例。任务拆解这块值得多说一句。很多时候一步到位做理解 判断 生成会让模型顾此失彼拆成两次调用反而更准第一次只做结构化抽取输出意图、关键实体、条件约束的 JSON第二次基于抽取结果生成回答。代价是延迟翻倍、成本上升所以我会在准确率不达标的场景才启用达标场景保持单次调用。4.3 上下文压缩成本优化里性价比最高的一招前面提到 32% 的错误是知识缺失自然的解法是检索增强。但检索一上来上下文长度立刻爆炸成本和延迟一起涨。我见过最夸张的配置一次请求塞进去 8 段检索结果、共 6000 多 token其中真正用上的可能就一两句。上下文压缩有几个层次我按投入产出比排序第一层检索结果重排加截断。用向量召回 20 条再用一个小交叉编码器重排只保留前 3 条。这一步通常就能砍掉 60% 的 token且几乎不损失准确率。第二层按段落做相关性过滤。不是整篇文档塞进去而是先按句子切开逐句算和问题的相关性只保留高相关句子。这招在长文档问答里效果特别好我在一份 40 页的规范文档上做过测试压缩后上下文从 5000 token 降到 900 token答案准确率反而涨了 2 个点——因为干扰信息少了。第三层抽取式摘要。用一个便宜的小模型对长文档做摘要但摘要会引入信息损失涉及精确数字、条款编号的场景慎用。这里有个参数选择需要算清楚。假设你的场景平均上下文是 3000 token输出 300 token日请求 10 万次那么每天的输入 token 消耗是 3 亿。压缩到 1000 token 就变成 1 亿直接省三分之二。这个账一定要在动手前算因为它决定了你愿意为压缩投入多少工程成本——如果一天只省几十块钱写两百行代码做语义压缩就不划算如果是几百上千那怎么投入都值。4.4 微调与蒸馏什么时候该上参数怎么定微调这件事我的判断标准很明确当错误归因里语义理解偏差和格式不合规两项加起来超过 35%且 Prompt 优化已经榨不出收益时才考虑微调。原因是大模型的通用语义能力已经很强你想通过微调让它更懂某领域的表达习惯收益往往不如你把判定规则写清楚。真要微调LoRA 是首选参数量和显存都好控。我常用的配置是 r16、alpha32alpha 一般取 r 的 2 倍、dropout 0.05、学习率 1e-4、3 个 epoch、warmup 比例 0.03。r 的选择上任务越接近原模型的已有能力r 可以越小我试过 r8 和 r32在语义归一化这种任务上差异不到 1 个点但 r32 的训练时间长了近一倍所以没特殊需求就停在 16。显存估算这件事必须提前算不然跑到一半 OOM 很难受。粗略公式是模型权重显存 参数量 × 每参数字节数。7B 模型如果做全参数微调权重 fp16 是 14GB梯度 14GBAdam 优化器的两个状态再加 56GB光这些就 84GB加上激活值和中间张量80GB 的卡都很紧张。LoRA 只训练很小一部分参数优化器状态按可训练参数算7B 模型 r16 大概只有 2000 万到 4000 万可训练参数优化器状态不到 0.3GB整卡占用能压到 20GB 出头单张消费级卡就能跑。训练数据量上我的经验是质量远比数量重要。500 到 2000 条精选样本覆盖所有场景矩阵格子效果远好于 2 万条随机日志。数据构造时要注意标签必须是最终正确答案而不是当时的线上输出——拿线上输出当标签等于把历史错误固化进模型。这一点我在一个项目里吃过教训用线上日志回填标注结果模型学会了系统一贯的错误表述评估集上分数很高新场景上完全不行。蒸馏的用法不太一样。当你想把一个大模型的能力搬到小模型上跑为了成本和延迟做法是用大模型对大量无标注样本生成输出经人工抽检或模型裁判过滤后作为小模型的训练数据。关键在于保留难例只保留大模型答对的简单样本小模型学不到东西要刻意保留 20% 到 30% 大模型也答得勉强的样本小模型在这些样本上的学习收益最大。4.5 输出约束与后处理最后一道防线不管模型多强输出格式永远不能完全信任。结构化输出的校验必须做而且要能优雅降级。我现在的做法是三层第一层用结构化输出能力比如强制 JSON schema约束生成这是最有效的一层能把格式错误率从 15% 压到 2% 以内。第二层解析失败时做一次修复重试把解析错误信息回传给模型让它自己改。这一层能救回大部分剩余的格式问题但要注意设置重试上限我一般设 1 次不然延迟会失控。第三层兜底逻辑。重试还失败就返回一个安全默认值并打点记录。这个兜底看着不起眼但它是防止整个服务因为一个格式错误就抛异常的关键。除格式之外业务规则校验也要做。比如生成的回答里不能出现未授权的承诺、不能出现超出权限的金额、必须包含指定的免责说明。这些用正则或关键词匹配做二次校验就够了不需要再调一次模型。我在一个场景里用 30 行正则拦下了 4% 的高风险输出投入产出比高得离谱。5. 常见问题与排查速查5.1 评估分数虚高的五个来源这是最值得警惕的问题因为虚高的分数会让你在不该发版的时候发版。我总结出来五个来源每一个都真实发生过参考答案过短或过泛。参考只写了无法修改模型输出一大段解释语义判对但实际表达质量很差评分却通过了。解决办法是参考要点必须写全并用质量维度单独扣分。裁判模型被答案长度收买。前面说过加冗余扣分维度能显著缓解。评估集和训练集泄漏。做微调时如果不查重评估集样本被间接学进去分数会虚高 5 到 10 个点且完全无法从分数上看出问题。必须做 n-gram 指纹检测。评估集过于同质。全是简单样本准确率自然 0.95。看分之前先看场景矩阵的覆盖度和各格子的样本量。只报均值不报分布。整体 0.86 很好看拆开看某个高风险场景只有 0.61。分场景报表是必须的均值会掩盖灾难。5.2 线上效果回落的排查路径离线好好的上线就掉——这个流程我走过太多次现在有一套固定顺序能在一小时内定位到大概方向先看是不是输入分布变了。对比上线前后一周的输入长度分布、意图分布、含特殊字符的比例。有一次线上掉点纯粹是因为新上了一批带表情符号的输入分词后语义被切碎了。再看是不是上下文变了。多轮对话场景里轮次变深之后上下文变长超窗截断把关键信息切掉了。然后看是不是调用链路问题。超时重试导致的重复请求、缓存命中率变化、并发升高导致的服务降级这些都会让模型效果看起来变差其实跟模型没关系。最后才是模型本身。如果前三项都排除了才去比对同一批输入的离线输出和线上输出是否一致确认有没有版本错配。确认是模型问题后看错误归因的分布变化。哪一类错误涨得最多就往那个方向查。提示线上回落的排查一定先做输入侧再做模型侧。我的经验是至少六成所谓的模型退化其实是数据或链路问题直接去调模型是纯粹的浪费。5.3 成本、延迟与效果的三方平衡这三个指标天然打架必须显式做取舍而不是等到上线被成本打脸。我的做法是给每个场景定一个服务等级不同等级用不同配置服务等级典型场景模型配置上下文策略允许延迟效果底线高高风险判定、合规审核强模型 二次校验全量上下文 重排3 秒准确率优先中常规问答、意图识别强模型单次调用重排后截断前 3 条1.5 秒准确率与延迟平衡低提示语、分类打标小模型或蒸馏模型短上下文500 毫秒延迟与成本优先这套分级的意义在于它把要不要用大模型从哲学问题变成了配置问题。同一个系统里90% 的流量走中低等级只有 10% 的高风险请求走强模型整体成本能降一个数量级而高风险场景的效果一点不降。最后分享一个我踩过的坑早期我们为了省成本把所有请求都路由到小模型结果高风险场景的错误率涨了 6 个点客诉直接翻了倍最后算下来处理客诉的成本远高于省下的调用费。这个账一定要算全别只算 token 账单。写到这里我个人在实际操作中的体会是模型评估与优化这件事七成的功夫在评估体系和数据上三成才在模型和 Prompt 上。急着调模型的人往往在原地打转先把归因做扎实、把评估集做扎实优化方向会自己浮出来。 
长河君 · 2026/10/27 20:01:00 · 阅读 1.2k 语义分析模型评估与优化：指标体系、评估集与错误归因
语义分析任务做到模型评估与优化这一步往往是最磨人的阶段。前面数据清洗、标注、微调跑通demo 效果看着不错一旦要把这套自然语言处理能力真正推到业务线上问题全冒出来了离线指标涨了两个点线上投诉却没减少人工抽查感觉变好了评审会上又拿不出能服人的证据好不容易把分数刷上去换个测试集又掉回来。这篇内容聊的就是大模型时代语义分析的模型评估与优化怎么落地——指标体系怎么搭、评估集怎么造、错误怎么归因、优化手段按什么顺序上。适合已经跑通过一次微调或 Prompt 调优、正准备把语义分析模块交付出去的同学也适合带团队、需要一套可复用评估流程的负责人。下面全部是我在实际项目里趟出来的做法有具体参数、有代码片段、有踩过的坑。1. 语义分析的评估为什么不能照搬分类任务那一套1.1 一个语义有无数种正确说法指标天然失真做文本分类出身的人第一次做语义分析最容易犯的错是拿 accuracy 当北极星。分类任务的标签空间是封闭的标签对了就是对了语义分析不是这样。用户问这个订单还能不能改地址模型输出订单已发货地址无法修改建议联系配送方协商和包裹已经出库了改不了你打快递电话试试——这两句话字面重合度极低语义上却都是对的。你要是拿 BLEU 去打分第二个答案可能只有十几分直接判定为失败可人工看一眼就知道它更好因为它更像人说话。这就是语义分析评估的第一个根本矛盾输出空间是开放的参考答案却是有限的。任何基于字面匹配的指标本质上都在惩罚表达多样性而表达多样性恰恰是大模型最值钱的地方。我在一个意图归一化的项目里做过统计同一个语义槽位人工写了 5 条参考改写模型生成的 2000 条输出里有 37% 是字面不重合但语义正确的如果只按 ROUGE-L 卡阈值这 37% 全被误判成错误实际错误率被高估了近一倍。所以评估体系必须先解决怎么定义对这个问题再去谈怎么算分。我的做法是把判定拆成两层第一层是语义等价判定只关心意思对不对第二层是质量分层判定在语义正确的基础上再区分表达质量是否简洁、是否口语化、是否带了不该有的承诺。这两层的判定标准、抽样比例、责任人都不一样混在一起算一个总分最后谁都不认这个数。1.2 三层评估结构离线看趋势业务看方向线上看真相单看任何一层都会翻车这个我吃过亏。有一回离线指标从 0.82 涨到 0.87团队很高兴灰度 5% 之后业务侧的二次追问率反而涨了 3 个点——模型答得更标准了但用户觉得答非所问于是又问一遍。这就是典型的离线指标和业务指标脱钩。我现在的标准结构是三层每层的职责划清楚层级数据来源核心指标更新频率决策作用离线评估层固定评估集 对抗集语义等价准确率、ROUGE-L、BERTScore/向量余弦、格式合规率每次迭代判断要不要发版卡门槛业务代理层历史真实日志回放二次追问率、转人工率、采纳率、平均交互轮次每周判断优化方向对不对线上观测层灰度流量分场景成功率、P95 延迟、单次成本、负反馈率实时判断能不能全量、要不要回滚三层里最容易做错的是业务代理层。很多团队直接用线上 AB 实验问题是一次 AB 实验跑两周两周里你可能已经迭代了三个版本实验结论永远滞后。我更喜欢用日志回放把过去一个月的真实请求录下来脱敏后做离线回放对比新旧两版的输出差异和对应的业务代理指标。好处是快一天能跑完坏处是它只能反映当时那批用户的分布所以每个月必须重新采样一次日志不然评估集会逐渐和真实分布漂移。注意日志回放必须做严格的脱敏和去重同一个用户的重复请求只保留首次否则重度用户的行为会主导整个评估集。1.3 我踩过的第一个坑单一指标导致的刷分式优化早期我们只有一个综合分团队每周盯着那个数字。三个月后我复盘发现模型确实在涨分涨的方式却很畸形——它学会了输出更长、更全面的答案因为参考答案普遍偏长长答案的字面召回更高。结果就是延迟翻倍、成本翻倍用户还嫌啰嗦。这就是指标的可优化性问题任何单一指标只要被当成唯一目标模型或人都会找到投机的路径。解决办法不是换一个更好的指标而是让指标之间形成制衡。我现在固定配置一组互相牵制的指标任何一项恶化都要单独说明理由语义等价准确率主指标权重最高但单独上涨不算数平均输出长度防止靠啰嗦刷召回格式合规率结构化输出场景必看JSON 解析失败直接算错P95 首字延迟与总延迟用户体验硬约束单请求平均 token 消耗成本硬约束这套组合拳的价值在于它逼着优化者去找既准又短又快的解法而不是在单一维度上做无效内卷。后面第 4 节讲的上下文压缩、输出约束基本都是被这几个约束指标逼出来的。2. 指标体系怎么搭从字面匹配到模型裁判2.1 BLEU 和 ROUGE 还有没有用有但要用对地方先说结论这两个老指标在语义分析的主评估里不该做主指标但在两个场景里依然很好用——格式化输出的结构校验和回归检测。BLEU 的核心是 n-gram 精确率加简短惩罚。标准 BLEU-4 的权重是四个 gram 各 0.25公式里那个简短惩罚项 BP 在候选长度 c 小于参考长度 r 时取 exp(1 - r/c)否则取 1。这个设计本来是为机器翻译服务的翻译要求不漏译所以短答案要罚。语义分析里经常反过来——短答案往往更好这时候 BP 就在帮倒忙。我在实际使用中会把它改成对称惩罚或者在配置里直接关掉 BP只保留 n-gram 精确率部分。ROUGE-L 基于最长公共子序列对词序不敏感比 BLEU 更贴合中文语义分析尤其是抽取式任务。但它同样惩罚同义替换。下面这段是我现在常用的计算封装加了平滑和中文分词处理from nltk.translate.bleu_score import sentence_bleu, SmoothingFunction from rouge_score import rouge_scorer import jieba def tokenize_zh(text: str) - list: return [t for t in jieba.lcut(text.strip()) if t.strip()] def bleu4(cand: str, refs: list) - float: smoothie SmoothingFunction().method1 c_tok tokenize_zh(cand) r_tok [tokenize_zh(r) for r in refs] if len(c_tok) 2: return 0.0 return sentence_bleu(r_tok, c_tok, weights(0.25, 0.25, 0.25, 0.25), smoothing_functionsmoothie) scorer rouge_scorer.RougeScorer([rougeL], use_stemmerFalse) def rouge_l(cand: str, ref: str) - float: s scorer.score( .join(tokenize_zh(ref)), .join(tokenize_zh(cand))) return s[rougeL].fmeasure实测下来BLEU-4 在我们的语义改写任务上和人工判定的相关系数只有 0.41ROUGE-L 是 0.53都不算高。它们的真正价值是便宜、稳定、可解释——几万条样本几秒钟跑完做版本回归筛查完全够用。我的用法是先用 ROUGE-L 卡一个很低的底线比如 0.35把明显跑偏的样本筛出来剩下的进模型裁判或人工这样能省掉 60% 以上的裁判调用成本。2.2 语义相似度阈值必须自己标定别抄别人的向量余弦相似度是介于字面匹配和模型裁判之间的一个折中方案。它的好处是不需要参考答案的措辞一致只要向量空间里靠得近就行。坏处是阈值的尺度完全取决于你用哪个 embedding 模型抄别人的 0.8 是纯粹的赌博。标定方法不难但一定要做挑 300 条样本人工标成等价 / 部分等价 / 不等价三档然后算每个档位的余弦分布看两个分布的交叠区域在哪取交叠区间的中间值作为阈值。我在一个句向量模型上做过这个标定结果是等价档的余弦均值 0.91、标准差 0.04不等价档均值 0.72、标准差 0.09交叠区间在 0.80 到 0.84 之间最终阈值定在 0.82对应的等价召回是 0.93、误判率 0.07。这里有个容易忽略的细节长文本的余弦天然偏高。同一批模型在短句上区分度好在 200 字以上的段落上随便两段中文的余弦都能到 0.6 以上。所以按长度分段标定阈值是必要的我一般切成 30 字以内、30 到 100 字、100 字以上三档各用各的阈值。2.3 模型裁判LLM-as-Judge好用但坑比想象的多到了大模型时代最自然的想法是让一个强模型来当裁判。确实好用但如果不做偏差控制你得到的分数可能比 BLEU 还不靠谱。先说评分卡怎么设计。我用的是分维度打分 明确锚点而不是一个笼统的 1 到 10 分。原因很简单笼统打分时裁判模型的尺度会漂移同一批样本今天平均 7.2 分明天平均 6.8 分你根本不知道是样本变了还是裁判心情变了。分维度加锚点描述能大幅降低这种漂移。你是严格的语义一致性评审员。请依据给定材料判断【模型回答】是否在语义上与【参考要点】一致。 评分维度每项独立打分不要互相影响 1. 语义一致性0矛盾1部分相关但不完整2完全一致 2. 事实准确性0含明显错误信息1无法验证2与材料一致 3. 表达合规性0含不该出现的承诺/敏感表述2合规 判定规则 - 语义一致性必须为 2 且事实准确性不为 0才可判为「通过」 - 只要出现与参考要点相矛盾的具体数字、时间、主体直接判「不通过」 输出格式严格 JSON不要有任何额外文字 {semantic: 0|1|2, factual: 0|1|2, compliance: 0|2, pass: true|false, reason: 不超过30字}温度设 0这一点没有商量余地。另外三个偏差必须处理位置偏差做 A/B 对比时裁判模型会系统性地偏好排在前面的那个。解决办法很简单——每条样本跑两次第二次把 A、B 顺序对调只有两次结论一致才算有效判定不一致的进人工。这个操作让成本翻倍但把偏差从 8% 压到了 2% 以内值得。长度偏差裁判模型普遍偏好更长的答案。我在评分卡里显式加了冗余扣分维度后长度和通过率的相关性从 0.34 降到了 0.11。自我偏好裁判模型对自己家族生成的答案打分偏高。这个没法完全消除只能靠裁判与被评模型尽量不同源并且拿 200 条人工标注做校准算出裁判与人工的一致率。低于 0.8 的裁判直接不用。2.4 指标加权权重不是拍脑袋是用回归拟合出来的多个指标怎么合成一个总分我见过最多的是拍脑袋比如语义占 60%、格式占 20%、延迟占 20%。这种权重在评审会上永远吵不出结果因为没人能证明 60 比 50 更合理。更靠谱的做法是拿人工判定做因变量用逻辑回归拟合各指标权重。具体做法抽 500 条样本人工给通过/不通过的二元标签然后把语义分、ROUGE-L、格式合规、长度惩罚等作为特征做拟合看系数。系数就是权重而且带统计显著性能直接回答这个指标到底有没有用。我在最近一个项目里拟合出来的结果是语义等价判定系数 2.31、格式合规 1.47、长度惩罚 -0.62、ROUGE-L 只有 0.19 且 p 值 0.21不显著。这个结论直接让我们把 ROUGE-L 从总分里踢了出去只留作回归筛查用。指标不是越多越好不显著的指标只会稀释信号。还有一点总分一定要配置信区间。评估集只有 500 条的时候准确率从 0.842 涨到 0.856这个差异很可能完全在噪声范围内。用 bootstrap 重采样算 95% 置信区间两版的区间大幅重叠就说明没区别别急着开香槟import numpy as np def bootstrap_ci(correct: np.ndarray, n_boot2000, alpha0.05): n len(correct) stats np.array([ correct[np.random.randint(0, n, n)].mean() for _ in range(n_boot) ]) lo, hi np.quantile(stats, [alpha/2, 1-alpha/2]) return correct.mean(), lo, hi500 条样本、准确率 0.85 的情况下95% 置信区间大概是 ±0.031。这意味着任何小于 3 个点的提升你都得靠扩大评估集或者做配对检验才能下结论。配对比较我用 McNemar 检验只看两版判定不一致的那些样本结论比直接比准确率灵敏得多。3. 评估集怎么造这件事的价值被严重低估3.1 分层抽样先画场景矩阵再抽样本我见过不少团队评估集就是从线上日志里随机抽 1000 条抽完就固定下来一直用。这样做的后果是高频场景占了 80%低频但高风险的场景比如退款、投诉、合规敏感表述连 20 条都不到指标完全被高频场景主导一出事就是低频场景翻车。我的做法是先画场景矩阵。横轴是业务意图10 到 15 个纵轴是输入形态短问句、长描述、多轮上下文、含表格或代码、含否定或反问每个格子按业务风险定配额。风险高的格子至少 50 条中风险 30 条低风险 15 条。这样一个评估集约 800 到 1200 条覆盖度完全不一样。配额定好之后抽样策略也要讲究。纯随机抽样会让难例被淹没我一般按7:2:1混合70% 随机抽样保证分布代表性20% 难例历史错误、边界样本10% 对抗样本人为构造的诱导、歧义、超长输入。这个比例不是死的模型上线初期难例比例可以提到 30%因为那个阶段你最需要知道它在哪里崩。3.2 标注一致性Kappa 低于 0.7 就别往下做了语义分析的标注比分类难因为要判断意思一样不一样。我遇到过最尴尬的情况是两个标注同学对同一批 200 条样本一致率只有 76%算出来 Cohens Kappa 只有 0.52。这意味着人工标签本身的噪声就很大拿它当金标准去评估模型等于用一把不准的尺子量东西。Kappa 的计算是 (Po - Pe) / (1 - Pe)Po 是观察一致率Pe 是随机一致率。分类任务里 0.8 以上算好0.6 到 0.8 可接受。语义分析这种主观性强的任务我把门槛定在0.7低于这个数就必须回头改标注规范而不是硬着头皮继续。最容易产生分歧的三类情况规范里必须写死部分正确算不算对我的规则是语义等价必须覆盖全部核心要点漏任何一个关键要素时间、金额、主体、条件都判不通过不给部分分。更详细但没出错算不算对算对但如果超出参考范围引入了新信息进待核实单独一档不计入主指标。语气差异只要语义一致正式或口语都算对。但如果模型加了不该有的承诺肯定能退合规项直接判失败。规范写完还不算完得跑校准轮三个标注同学各标 100 条重叠样本一起过一遍分歧项把分歧原因归类回头改规范。这个流程我一般跑两轮Kappa 能稳定到 0.78 以上再开始大规模标注。3.3 对抗样本不是为了打模型是为了暴露脆弱面对抗样本在语义分析里主要是三类歧义型一句话有多个合理解释比如这个能退吗没有上下文退的是货还是钱还是订单模型必须学会追问而不是瞎猜。这类样本检验的是模型的请求澄清能力我一般要求模型在信息不足时明确追问而不是给一个四平八稳的模糊回答。否定与双重否定我不是不想退是超过时间了——这种句子里的真实意图和字面情绪完全相反。模型如果只做关键词匹配会把退当成正向意图。这类样本我一般从真实日志里捞比人工构造的自然得多。超长与噪声把三条无关的客服记录拼在一起或者塞进错别字、表情符号、重复字符。检验的是鲁棒性和截断策略。实话说大模型对这种输入的容忍度比想象中好真正的问题出在上下文窗口超限时的截断位置——如果截断把关键条件切掉了输出就是错的而且错得很隐蔽。3.4 数据污染检测与版本管理一个必须做的脏活评估集做久了必然面临一个问题它会不会被练进去尤其当你用同一批数据做微调或者做 few-shot 示例时。我现在的硬性规定是评估集与训练数据零交集并且在入库前做三道检查精确去重、n-gram 指纹去重8-gram 重合度超过 0.7 视为重复、向量近邻检测余弦超过 0.95 的样本对人工复核。版本管理上评估集必须带版本号和变更日志每次变更记录加了多少、删了多少、为什么。听起来很官僚但真出事的时候这是唯一能自证清白的材料。我就遇到过评审时被问你这个 0.87 是在哪版评估集上跑的答不上来的尴尬。4. 优化实操先归因再动手4.1 错误归因把效果不好拆成六类可执行的问题模型效果不达标时最没用的动作就是再调调 Prompt 试试。我现在的流程是先把所有错误样本做归因分类每类占比算出来再决定投入哪个方向。这套分类是我反复迭代出来的基本能覆盖 95% 的情况错误类型典型表现占比我的项目实测首选解法知识缺失答案本身没错但缺关键事实32%检索增强、补充上下文语义理解偏差把否定当肯定、主体搞错21%拆解任务、加中间推理步骤格式不合规JSON 少了字段、多了解释文字18%结构化输出约束、后处理兜底信息不足未追问该问的没问直接瞎答12%Prompt 加澄清规则、加置信度判断表达冗余正确但啰嗦、重复10%长度约束、输出模板幻觉编造数字、时间、政策7%强约束、事实校验层这张表最直接的价值是告诉你别一上来就做微调。32% 是知识缺失微调解决不了你喂多少数据它也不会突然知道某个具体商品的退换规则那是检索该干的事。反过来只有 21% 的理解偏差值得考虑微调而且这部分里还有一半能靠拆解任务解决。4.2 Prompt 优化的正确迭代方式一次只改一个变量Prompt 调优最大的陷阱是感觉改完更好了。我见过一个 Prompt 被改了 40 多版最后没人说得清哪一版最好因为每一版都同时改了示例数量、输出格式、系统指令变量全混在一起。我的做法是建一个变量登记表每次只动一个维度跑完评估集记录分数和置信区间确认显著再进下一个。常见的可调维度按收益排序大致是任务拆解方式一步到位 vs 先抽取再判断——收益最大经常能带来 5 到 8 个点示例的选择与数量0/2/5 shot示例是否覆盖边界情况——2 到 4 个点输出结构约束强制 JSON、先给结论再给理由——主要提升格式合规率角色与规则表述把请尽量准确换成具体的判定规则——稳定但边际收益递减温度、top_p 等采样参数——对确定性任务基本没用直接设 0关于 few-shot 示例有个反直觉的经验示例不是越多越好也不是越像越好。我做过一组对比5 个示例里如果全是同类简单样本效果反而不如 2 个示例一个典型、一个边界。原因是示例太多会让模型倾向于模仿示例的表面形式而不是理解判定逻辑。边界示例的价值远高于典型示例。任务拆解这块值得多说一句。很多时候一步到位做理解 判断 生成会让模型顾此失彼拆成两次调用反而更准第一次只做结构化抽取输出意图、关键实体、条件约束的 JSON第二次基于抽取结果生成回答。代价是延迟翻倍、成本上升所以我会在准确率不达标的场景才启用达标场景保持单次调用。4.3 上下文压缩成本优化里性价比最高的一招前面提到 32% 的错误是知识缺失自然的解法是检索增强。但检索一上来上下文长度立刻爆炸成本和延迟一起涨。我见过最夸张的配置一次请求塞进去 8 段检索结果、共 6000 多 token其中真正用上的可能就一两句。上下文压缩有几个层次我按投入产出比排序第一层检索结果重排加截断。用向量召回 20 条再用一个小交叉编码器重排只保留前 3 条。这一步通常就能砍掉 60% 的 token且几乎不损失准确率。第二层按段落做相关性过滤。不是整篇文档塞进去而是先按句子切开逐句算和问题的相关性只保留高相关句子。这招在长文档问答里效果特别好我在一份 40 页的规范文档上做过测试压缩后上下文从 5000 token 降到 900 token答案准确率反而涨了 2 个点——因为干扰信息少了。第三层抽取式摘要。用一个便宜的小模型对长文档做摘要但摘要会引入信息损失涉及精确数字、条款编号的场景慎用。这里有个参数选择需要算清楚。假设你的场景平均上下文是 3000 token输出 300 token日请求 10 万次那么每天的输入 token 消耗是 3 亿。压缩到 1000 token 就变成 1 亿直接省三分之二。这个账一定要在动手前算因为它决定了你愿意为压缩投入多少工程成本——如果一天只省几十块钱写两百行代码做语义压缩就不划算如果是几百上千那怎么投入都值。4.4 微调与蒸馏什么时候该上参数怎么定微调这件事我的判断标准很明确当错误归因里语义理解偏差和格式不合规两项加起来超过 35%且 Prompt 优化已经榨不出收益时才考虑微调。原因是大模型的通用语义能力已经很强你想通过微调让它更懂某领域的表达习惯收益往往不如你把判定规则写清楚。真要微调LoRA 是首选参数量和显存都好控。我常用的配置是 r16、alpha32alpha 一般取 r 的 2 倍、dropout 0.05、学习率 1e-4、3 个 epoch、warmup 比例 0.03。r 的选择上任务越接近原模型的已有能力r 可以越小我试过 r8 和 r32在语义归一化这种任务上差异不到 1 个点但 r32 的训练时间长了近一倍所以没特殊需求就停在 16。显存估算这件事必须提前算不然跑到一半 OOM 很难受。粗略公式是模型权重显存 参数量 × 每参数字节数。7B 模型如果做全参数微调权重 fp16 是 14GB梯度 14GBAdam 优化器的两个状态再加 56GB光这些就 84GB加上激活值和中间张量80GB 的卡都很紧张。LoRA 只训练很小一部分参数优化器状态按可训练参数算7B 模型 r16 大概只有 2000 万到 4000 万可训练参数优化器状态不到 0.3GB整卡占用能压到 20GB 出头单张消费级卡就能跑。训练数据量上我的经验是质量远比数量重要。500 到 2000 条精选样本覆盖所有场景矩阵格子效果远好于 2 万条随机日志。数据构造时要注意标签必须是最终正确答案而不是当时的线上输出——拿线上输出当标签等于把历史错误固化进模型。这一点我在一个项目里吃过教训用线上日志回填标注结果模型学会了系统一贯的错误表述评估集上分数很高新场景上完全不行。蒸馏的用法不太一样。当你想把一个大模型的能力搬到小模型上跑为了成本和延迟做法是用大模型对大量无标注样本生成输出经人工抽检或模型裁判过滤后作为小模型的训练数据。关键在于保留难例只保留大模型答对的简单样本小模型学不到东西要刻意保留 20% 到 30% 大模型也答得勉强的样本小模型在这些样本上的学习收益最大。4.5 输出约束与后处理最后一道防线不管模型多强输出格式永远不能完全信任。结构化输出的校验必须做而且要能优雅降级。我现在的做法是三层第一层用结构化输出能力比如强制 JSON schema约束生成这是最有效的一层能把格式错误率从 15% 压到 2% 以内。第二层解析失败时做一次修复重试把解析错误信息回传给模型让它自己改。这一层能救回大部分剩余的格式问题但要注意设置重试上限我一般设 1 次不然延迟会失控。第三层兜底逻辑。重试还失败就返回一个安全默认值并打点记录。这个兜底看着不起眼但它是防止整个服务因为一个格式错误就抛异常的关键。除格式之外业务规则校验也要做。比如生成的回答里不能出现未授权的承诺、不能出现超出权限的金额、必须包含指定的免责说明。这些用正则或关键词匹配做二次校验就够了不需要再调一次模型。我在一个场景里用 30 行正则拦下了 4% 的高风险输出投入产出比高得离谱。5. 常见问题与排查速查5.1 评估分数虚高的五个来源这是最值得警惕的问题因为虚高的分数会让你在不该发版的时候发版。我总结出来五个来源每一个都真实发生过参考答案过短或过泛。参考只写了无法修改模型输出一大段解释语义判对但实际表达质量很差评分却通过了。解决办法是参考要点必须写全并用质量维度单独扣分。裁判模型被答案长度收买。前面说过加冗余扣分维度能显著缓解。评估集和训练集泄漏。做微调时如果不查重评估集样本被间接学进去分数会虚高 5 到 10 个点且完全无法从分数上看出问题。必须做 n-gram 指纹检测。评估集过于同质。全是简单样本准确率自然 0.95。看分之前先看场景矩阵的覆盖度和各格子的样本量。只报均值不报分布。整体 0.86 很好看拆开看某个高风险场景只有 0.61。分场景报表是必须的均值会掩盖灾难。5.2 线上效果回落的排查路径离线好好的上线就掉——这个流程我走过太多次现在有一套固定顺序能在一小时内定位到大概方向先看是不是输入分布变了。对比上线前后一周的输入长度分布、意图分布、含特殊字符的比例。有一次线上掉点纯粹是因为新上了一批带表情符号的输入分词后语义被切碎了。再看是不是上下文变了。多轮对话场景里轮次变深之后上下文变长超窗截断把关键信息切掉了。然后看是不是调用链路问题。超时重试导致的重复请求、缓存命中率变化、并发升高导致的服务降级这些都会让模型效果看起来变差其实跟模型没关系。最后才是模型本身。如果前三项都排除了才去比对同一批输入的离线输出和线上输出是否一致确认有没有版本错配。确认是模型问题后看错误归因的分布变化。哪一类错误涨得最多就往那个方向查。提示线上回落的排查一定先做输入侧再做模型侧。我的经验是至少六成所谓的模型退化其实是数据或链路问题直接去调模型是纯粹的浪费。5.3 成本、延迟与效果的三方平衡这三个指标天然打架必须显式做取舍而不是等到上线被成本打脸。我的做法是给每个场景定一个服务等级不同等级用不同配置服务等级典型场景模型配置上下文策略允许延迟效果底线高高风险判定、合规审核强模型 二次校验全量上下文 重排3 秒准确率优先中常规问答、意图识别强模型单次调用重排后截断前 3 条1.5 秒准确率与延迟平衡低提示语、分类打标小模型或蒸馏模型短上下文500 毫秒延迟与成本优先这套分级的意义在于它把要不要用大模型从哲学问题变成了配置问题。同一个系统里90% 的流量走中低等级只有 10% 的高风险请求走强模型整体成本能降一个数量级而高风险场景的效果一点不降。最后分享一个我踩过的坑早期我们为了省成本把所有请求都路由到小模型结果高风险场景的错误率涨了 6 个点客诉直接翻了倍最后算下来处理客诉的成本远高于省下的调用费。这个账一定要算全别只算 token 账单。写到这里我个人在实际操作中的体会是模型评估与优化这件事七成的功夫在评估体系和数据上三成才在模型和 Prompt 上。急着调模型的人往往在原地打转先把归因做扎实、把评估集做扎实优化方向会自己浮出来。