大模型评测与算法效果追踪：从选型到持续优化

前言

#

选了大模型之后怎么评估效果？上线之后怎么持续追踪？这两个问题一直困扰着我。大模型赛道现在卷得飞起，每个月都有新模型发布，各种榜单排名满天飞。但榜单上的分数和你的实际业务效果之间，往往隔着一道鸿沟。模型上线了，准确率只有 60%，问题出在哪？是模型不行、数据不行、还是标注有问题？

我花了很长时间把评测选型和算法效果追踪这两件事梳理清楚，发现它们其实是一条完整链路上的两个阶段：先通过系统化评测选出最适合业务的模型，再通过持续的效果追踪确保模型在线上真正发挥作用。今天把这套方法论完整记录下来，从评测框架、指标体系到持续优化的闭环，一口气讲透。

评测的起点：不是找最好的，而是找最合适的

#

先明确一个前提：评测的目的不是找"最好的模型"，而是找"最适合业务场景的模型"。这两件事完全不同。

一个模型在通用能力上碾压全场，但在你的垂直领域（比如法律合同审查、医疗问诊）表现拉胯，那它对你来说就不是好模型。反过来，一个小模型在你的场景上微调得很好，推理成本还低，那它就是最佳选择。

所以评测的核心逻辑是：用最低成本，选出最适合业务场景的模型。 这需要一套系统化的评测方案。

SuperCLUE 榜单：便捷但不够透明的标尺

#

AI 领域广泛关注的评测榜单 SuperCLUE¹，用 660 道题目从图像质量、一致性、创造力、复杂适应性等维度对模型打分。对产品经理来说，它的价值在于低成本获取客观评测数据，支撑初步判断。你不需要自己跑评测，看看榜单就能对主流模型的能力有个大致了解。

但它有一个明显的局限性：评测数据不开源。 你只能看到最终排名，看不到模型在每个具体问题上的表现。这意味着你无法拆解某个模型在你关心的维度上到底是强还是弱，写技术报告时缺乏具体案例佐证，也无法做归因分析。

打个比方，SuperCLUE 就像大学排行榜。你知道清华北大排名靠前，但无法判断清华的计算机系和北大的计算机系哪个更适合你。要做精准选型，必须深入到具体维度。

开源评测方案：EvalScope 实战

#

SuperCLUE 看不到细节怎么办？那就上开源评测方案。开源评测的核心价值是可复现、可拆解、可归因。使用业内公认的开源数据集，所有评测流程透明，每个问题模型的回答都能追溯。

但开源评测有一个痛点：操作门槛高。涉及大量数据集、统计脚本和指标计算，光是跑通评测流程就要折腾很久。

EvalScope[^2]（基于 FlagEval 开源框架）就是来解决这个痛点的。它提供三项关键能力：

自动化评测。 整个流程被封装得很简洁：安装依赖包、配置文本编码器、选择数据集、运行脚本。不需要手动写评测代码，也不需要一个个数据集去下载和处理。

可视化报告。 跑完评测大概 20 分钟，就能拿到一份带诊断结论的可视化报告。不再是冷冰冰的数字表格，而是图形化的对比分析，哪个模型在哪个维度强、哪个维度弱，一目了然。

归因分析。 这是最有价值的部分。不只是告诉你模型得了多少分，而是告诉你为什么得了这个分。是在哪类问题上答错了？是推理能力不够还是知识覆盖不全？是中文表现差还是英文表现差？

有了归因分析，才能做出有针对性的决策：是需要换模型，还是针对特定场景做微调，还是调整 Prompt 策略。举个具体例子：假设你在做一款法律问答产品，评测发现模型 A 总得分比模型 B 高，但归因分析显示模型 A 在"法律推理"类问题上错误率高达 40%，而模型 B 在这类问题上错误率只有 15%。如果只看总分，会选模型 A；但结合归因分析，模型 B 才是最优选择。

评测实战：四步走

#

讲完工具，说几条实用的建议。

明确评测维度

#

不要上来就跑全量评测。先想清楚业务场景最看重什么：

• 准确率优先（医疗问诊、法律咨询）：重点看知识准确性、推理能力
• 流畅性优先（内容创作、营销文案）：重点看语言质量、创意能力
• 稳定性优先（客服对话）：重点看输出一致性、格式遵守能力
• 成本优先（高并发场景）：重点看 Token 消耗、推理速度

构建业务评测集

#

通用榜单只能做参考。真正有说服力的评测，必须用你自己的业务数据。 从真实用户问题中抽取一批代表性样本，人工标注标准答案，做成专属评测集。这比任何通用榜单都有说服力。

多维度对比

#

一个模型在 BLEU[^3]（翻译指标）上得分高，不代表它在实际业务中表现就好。综合多个指标，结合人工测评，做 A/B 测试上线对比。效果才是真理。

持续评测

#

模型在迭代，业务在变化，用户需求也在演进。评测不是一次性的事情，而是需要持续进行。建立一个评测流水线，每次模型更新或业务调整后自动跑一轮评测。

评测的终点不是报告，而是决策。好的评测应该能直接回答：这个模型在核心场景上表现如何？相比现有方案提升多少？推理成本是否在可接受范围内？有没有特定的短板需要通过 Prompt 优化或微调来弥补？

从选型到追踪：算法效果跟进的通用流程

#

模型选好了，效果追踪怎么做？这里有一个三步通用流程：提出需求、效果跟踪、持续优化。

提出算法需求

#

• 明确输入和输出：算法工程师需要知道你给什么、他返回什么
• 明确业务指标和上线阈值：「准确率达到 90% 才能上线」，这个数字不能模糊
• 把需求文档交给研发工程师：白纸黑字，避免口头理解偏差

如果公司有算法中台，先看中台现有能力能不能满足，别上来就造轮子；如果是复杂场景，可能需要算法工程师提前介入评估可行性。

效果跟踪

#

需求提出去只是开始：

• 持续和算法工程师沟通，了解他们打算用什么方式实现
• 提供标注数据（这一点太重要了，后面单独讲）
• 持续跟踪实验结果，每次模型迭代的指标变化都要记录
• 多元数据验证，验证通过后才能上线

持续优化

#

模型上线了不代表工作结束。上线后持续收集 Bad Case，配合算法工程师用 Bad Case 训练模型，一轮一轮提升业务指标。

下面用一个具体的案例来展开。

案例详解：情感识别算法

#

在客服机器人场景中，我们发现一个很影响体验的问题：用户已经明显带着情绪了，机器人还在就事论事地回复。

看这个例子：

用户：“要命了，我贷款申请提交七天了，还没审批结果吗？我要投诉了！” 机器人回复：“您的贷款申请已收到，正在审批中。”

用户看完什么感受？火上浇油。明明已经急得不行了，机器人冷冰冰甩一句「正在审批中」，感觉像在对着一堵墙说话。

我们期望的效果是：先安抚再给答案。 同样是处理贷款审批，先安抚用户的情绪，再告知审批进度，体验完全不同。要实现这个效果，需要一个情感识别算法：输入用户的问题，输出情绪值（正面/负面/中性），预期指标是情绪识别准确率达到 90% 以上。

分类算法与数据标注

#

情感识别用的核心技术是分类算法。二分类就像判断一只羊是黑羊还是白羊，结果只有两种可能。多分类就像把用户的问题分成三堆：正面的放一堆，负面的放一堆，中性的放一堆。情感识别就是一个典型的多分类任务。

训练过程可以一句话概括：人工标注数据，算法学习标注数据，训练出模型，模型判断新句子的类别。 就像教小朋友认动物：先给他看一堆猫的照片并告诉他「这是猫」，看多了之后小朋友就能认出没见过的猫了。

AI 产品经理为什么要懂分类算法

#

看这个例子：

句子 A：“我抓不空了，我要投诉” 句子 B：“到底行不行啊，我很着急”

作为人，一眼就能看出来 A 比 B 更负面。A 都说了「投诉」。但在分类算法眼里，这两个句子打出的负面分数可能差不多。为什么？因为分类算法本质上是看词频和统计特征，它不太能理解「投诉」比「着急」有更强的负面信号。

如果不了解这个技术限制，就会觉得算法工程师「能力不行」。但如果了解，就知道可以加一条关键词规则来补充。这就是「技术不够，产品来补」的思路。

数据标注：模型效果的天花板

#

讲到算法效果，数据标注是绕不开的话题。核心结论是：标注数据的准确率是模型效果的上限值。 如果你标注了 20000 条语句，其中 95% 标注正确，5% 标注不正确或模棱两可，那模型不管怎么调优，最高准确率也就 95% 左右。因为模型学到的「标准答案」本身就有 5% 是错的，它怎么可能超越自己的教材？

AI 的三大基石是数据、算力和算法，但数据在其中的权重占到 70%[^4]。一个很能说明问题的例子：让一个刚毕业的新人和一个资深算法工程师用同样的数据训练分类模型，准确率差别也就 1%-2%。这意味着数据的质量远比算法工程师的经验重要。

建议的做法是：同一批语料至少由两个人标注，取两人一致的交集；不一致的部分再由第三个人或两人一起核对校验。

混淆矩阵：读懂算法的「成绩单」

#

模型训练完了，算法工程师会给一份「成绩单」。要读懂它，需要理解混淆矩阵[^5]。

数据集怎么分

#

数据不是全部拿来训练的。标准的分法是：训练集 80% 的数据（比如 20000 条中的 16000 条），用来让模型学习；验证/测试集 20% 的数据（4000 条），用来考模型学得怎么样。就像学生做题：16000 道是练习题，4000 道是考试题。考试题模型没见过，才能真实反映效果。

混淆矩阵长什么样

#

以「正向情绪预测」为例：

翻译一下：

• TP（真正例）：本来就是正向，模型也判正向，判对了
• FN（假负例）：本来是正向，模型判成负向，漏掉了
• FP（假正例）：本来是负向，模型判成正向，误判了
• TN（真负例）：本来是负向，模型也判负向，判对了

三个核心指标

#

基于混淆矩阵，可以算出三个核心指标：

精确率（Precision）：模型说「这是正向」的样本中，有多少确实是对的。通俗说就是：模型声称找出来的正向情绪，有多少是真的正向。

召回率（Recall）：所有真实为正向的样本中，模型找回了多少。通俗说就是：实际的正向情绪，模型有没有漏掉。

F1 值：精确率和召回率的调和平均数，是一个综合指标。

精确率和召回率往往此消彼长。要求精确率高，模型就会更谨慎，可能漏掉一些正向的（召回率下降）；要求召回率高，模型就会更激进，可能误判一些负向为正向（精确率下降）。F1 值就是帮你在两者之间找平衡的。 这三个指标越高越好，但不要追求完美，根据业务场景找到合适的平衡点更重要。

多元数据验证：上线前的最后一道关卡

#

模型在测试集上效果不错，就可以上线了吗？还不够。需要做多元数据验证，验证模型在不同场景下的表现是否一致：

• 不同业务线：从售前和售后各抽测试样本，看效果是否稳定
• 不同渠道用户：APP 端和网页端用户的表达方式可能不同
• 不同表达方式：同一件事，有人说「提前还款」有人说「不想贷了」，模型都能识别吗

为什么要这么做？因为模型可能在某类数据上表现特别好，但在另一类上表现很差。如果只看整体指标，这个短板会被平均值掩盖。如果验证发现不同场景下效果差异明显，可能需要按场景或行业分别训练模型，而不是用一个通用模型打天下。

持续优化：一个永不停止的闭环

#

模型上线后，持续优化是一个永不停止的过程。主要关注两件事。

收集线上 Bad Case

#

Bad Case 就是模型判断错误的案例。比如明明是负面情绪被识别成了正面。这些案例是金矿，把它们收集回来，重新标注，重新训练，模型的准确率就会一步步提升。

定期更新训练数据

#

业务是持续变化的。三个月前用户的常用话术和三个月后可能完全不同。如果模型一直用老数据，效果会逐渐衰减。所以需要定期收集线上新语料进行标注，更新模型。

这两个动作形成一个持续运转的飞轮：发现问题，收集案例，标注数据，训练模型，上线验证，发现新问题。这个飞轮转得越快，产品就越好。

评测和效果追踪不是技术团队的专属工作，而是必须参与的决策环节。不管是选模型还是优化模型，始终记住一条原则：评测的终点不是报告，而是决策。 报告写得再漂亮，如果它不能帮你做出更好的产品决策，那就是无效评测。

参考文献

#

• SuperCLUE
• EvalScope