概述
背景
首先介绍下为什么要写这篇文章。虽然网上有非常多的大模型评测相关的文章，但是就像看成功人士传记一样，看到别人的成功案例并不意味着自己也知道应该如何一步步地实现目标。市面上有非常多的评测平台，但是每个平台都不会告诉我们“上传评测集”、“新增评测维度”所涉及的评测集和评测维度是怎么生成的。所以我想通过这篇文档，让大家可以通过按“使用说明书”的方法执行就可以实现自己业务场景下的大模型评测。
本文内容力求严谨，但也可能存在主观判断、不完整甚至错误的问题。
定义
我们也约定下大模型评测的范围。大模型评测的目标是通过设计合理的测试任务和数据集来对大模型的能力进行全面、量化的评估。本文主要聚焦对大模型业务效果方面的评测，不包含大模型的性能测试。性能测试通过压测实现。
区别于基础模型的Benchmark(基准测试)，本文更加聚焦在针对具体业务场景下大模型的效果。在基础模型发布时，模型厂商提供的测试报告无法覆盖用户实际业务场景。用户需要通过针对自己业务场景设计的评测来评估大模型的实际表现。同时大模型评测除了针对模型本身，也可以面向整个模型应用进行评测，覆盖RAG、MCP、工作流等构成的统一整体进行端到端的测试。
场景
大模型评测在模型应用中的作用，类似于功能测试在业务应用中的作用——两者均是确保系统或大模型在实际部署前达到预期性能与可靠性的关键验证环节。以下是几种典型的评测场景：
大模型上线：在大模型应用上线前，通过评测了解大模型的能力，判断大模型应用是否具备上线条件。
大模型升级切换：因为需要切换模型厂商、更换模型尺寸、模型微调或模型版本升级等原因，用户需要通过评测对新旧模型的效果进行比对，从而决策是否进行切换。
大模型优化：通过评测发现的bad case，持续提升大模型效果。通过分析bad case的原因，可以进行诸如优化知识库、优化提示词、优化工作流、引入或优化MCP以及对模型进行微调等方式优化效果。
挑战
大模型评测相关工具平台随着各大模型平台厂商的持续投入以及开源社区的火爆，相关功能也在持续完善，目前已经不是主要的困难点。目前的主要困难更多聚焦在如何结合自己的业务场景开展大模型评测。
评测维度：评测维度如何设计才能更好的衡量大模型效果，并推动大模型优化？
评测集：如何设计评测集才能更好地仿真实际的线上场景。如何平衡不同场景的比例失衡的问题，确保不同场景的覆盖？
标注：标注人员质量参差不齐，不同人对标准的理解不一致。同一个人不同时间标注，也会导致结果不同，最终导致标注准确性稳定性差。除了标注效果外，人工标注非常耗时且需要投入额外的人工成本，导致无法开展大规模评测。
业务变化：随着技术方案和业务场景的变化，大模型本身也在持续迭代演进。不同大模型特点不同，评测标准和评测集的构成也各不相同。
大模型评测方法
评测流程
大模型评测流程，整体可以分为4个阶段共9个动作。前7个为模型评测本身的动作，以输出评测报告为目标。后续2个动作为通过持续优化模型与模型评测本身，以达到最后的模型上线切换等目标。
需求分析
通过需求分析了解关键信息，作为后续设计的依据。以下是一些典型的问题。
业务场景
大模型被使用在什么业务里？
这个业务都有哪些业务流程，大模型在其中哪个流程中，起到什么样的作用？
在这个业务场景里，大模型的使用者是谁。是否包含C端用户。
用户使用大模型需要解决什么问题。用户会提供什么信息，并期望大模型输出什么？
目前大模型是否已经投产了？还是处于测试阶段？
评测对象
我们要评测的对象是模型（基础模型/微调模型），还是大模型应用。
对象=基础模型：具体的模型名称，是否是经过微调。
对象=模型应用：请提供大模型的技术架构。
如果是基于百炼调用，请提供测试账号方便了解技术细节。
是需要对单一大模型对象进行评测，还是需要和其他的大模型进行比较评测结果。如果是需要比较的话，对比对象是什么？
评测集
用户最常见的使用大模型都会分哪几种场景，这些场景的调用量分布是怎么样的？
每个场景里大模型的输入输出是怎么样的，请分别提供一些示例。
本次评测的目标是什么？是希望评估模型对实际场景的业务效果，还是需要评测特定子场景的效果，或是希望能对历史bad case做回归？
评价维度
如何判断大模型效果好不好？业务人员会关注哪些维度？
针对其中的每个维度，是如何评估的，是定性的对错，还是有打分的机制。如果是打分，分别打几分。每个档次之间的评分标准是什么。
对于多维度的评价，是否可以通过一个公式（比如通过加权）将结果量化成一个数字，还是必须每个维度分别分析？
模型效果
当前大模型的实际效果表现如何？这些效果评估是来自哪里？是感性的反馈还是有数字支撑。
当前系统如何收集用户的bad case，是否有日志可以分析？
当前都有哪些原因可能导致bad case，都是什么样的原因？
是否分析过bad case，都是哪些原因导致结果不满意，分布如何。
技术实现
企业内部是否有评测平台，还是计划使用百炼进行评测？
是否有人工评测团队，还是希望通过“AI评测器”（指通过大模型进行评测）或“自动化指标”自动完成评分（自动化指标仅适用于文本分类等客观性任务）？
自动评测：自动对于推理完成的时效性是否有要求，是否可以接受离线的推理方式？使用这种方式的模型不执行在线推理，因此可以显著降低推理成本。
评测集设计与生成
基于评测目标确认数据来源
大模型的评测集根据评测目的最常见的有以下三种：
端到端评测集：
实际场景效果：为了实现实际场景效果评估的目标，需要选择评测集尽量接近选择实际线上数据。这里典型的有两种方法。一种是选择历史某天的历史记录。另外一种是选择接入线上流量进行“双跑”，仅仅是结果只做记录分析但是不输出给线上环境。区别在于接入历史数据更方便做分析统计，“双跑”方案方便后续做灰度以及切换。
特定子场景效果：为了实现特定子场景的评估目标，需要定义特定场景并设计对应的评测集。比如让大模型做小学生数学题，五年级的题目、奥数题、压轴题就是其中的一个子场景。从具体的需求出发，选择整体的评测集中的子集。
分层评测集：
bad case回归：使用线上问题中的用户的负面反馈，或者在测试、质检等环节形成的案例，经过标注形成Bad Case作为评测集。目的是为了验证优化工作对bad case的优化效果。
功能模块评测：比如评测模型应用中的意图识别模块的准确率、知识库部分的召回准确率等。通过评测识别各功能的效果方便后续进一步优化。这种情况下可以针对评测对象的各种功能针对性设计评测集。
安全评测集：专注于科技伦理、数据安全和内容安全的各项指标，确保模型满足安全合规要求。建议由安全或风控团队提供。
确认评测集场景范围
确认评测集场景范围的原因主要是为了保证测试内容的完整性，避免测试内容遗漏。评测集场景的梳理方式主要有以下方式结合分析：
结合业务场景分析：从业务场景出发来设计评测场景是最基本的做法。大模型在不同场景下可能有不同的表现，模型评测需要覆盖不同业务以获得完整的评测结果。假设阿里云售后支持大模型可以在提供云产品异常问题诊断的能力的同时，也提供协助售后支持小二回答服务流程规范、服务排班的问题。实际评测的时候就不能遗漏对应的功能。而且应用服务异常诊断也需要针对不同云产品的故障诊断能力准备评测集。
结合技术架构分析：不同的业务场景下可能在技术实现上会有不同。比如通过意图识别针对不同的情况走不同的技术链路的，可能是不同的场景。或者使用了不同的组件、MCP或知识库，或者有不同的工作流的，很可能是不同的场景。
确认评测集数量
对于来自线上请求“双跑”的在线数据集和离线数据集，采用不同的数量规划方式：
在线评测集：需要考虑“双跑”持续的时间。双跑的时间取决于业务人员觉得多久足够证明业务效果。一方面考虑评测集样本数量；另外一方面考虑是否覆盖业务周期（比如是否覆盖常态和大促态、覆盖工作日和周末等）。一般建议可以评测3-7天。为了更准确评估，可以提前统计单日的调用量。
离线评测集：离线数据集的数量主要考虑场景覆盖度、样本数量足够以及与成本性能的均衡。场景覆盖度需要不存在某个场景没有评测集样本的情况。样本数量足够包括总体样本数量足够，也包括各评测场景的样本也需要有足够的样本数量。成本性能的均衡主要考虑样本数量不能太大，以免评测需要消耗过多的时间、人力和算力成本。为了更准确评估，可以提前统计单日的总调用量及分场景的数量。
这里有个难点：如何解决各场景样本数量分布不均衡的问题？比如假设某质检场景里差评投诉的案例只占全部案例的1%，那如果完全按照实际请求生成评测集，可能导致差评占比偏少。而如果提升差评样本数量又会导致整体样本失真。
一般的解决方法有：
增加样本数量。通过提升样本数量（即增加时间范围）来获得更多负样本。
适用场景：评测目标是为了实现“以XX日到XX日实际案例评测结果”，评测集需要尽可能接近真实数据。
注意事项：无法实际规避样本分布不均衡的问题，只是通过提升总体样本数量来确保小场景有最低数量的样本。而且过度的增加样本会导致大场景的样本过多浪费资源。此外需要关注某段时间范围是否已覆盖所有场景（比如要考虑业务场景下工作日和周末是否存在不同），而不是单纯只考虑数量。这不是一个特别好的方法，只是在特定场景下约束下的选择。
调整权重比例。比如每个场景按需要生成足够数量的样本进行评测，分场景计算平均分，分析各个场景的模型表现。
适用场景：需要用数字量化总体效果，但是又存在样本分布不均匀的情况。
调整损失函数。引入诸如召回率、F1分数等指标，选择更加符合业务需求的指标。
适用场景：在样本分布不均衡时关注小场景的效果。另外小样本数量过小时数据也可能失真。
评测集初稿生成
在线评测集只需要接入线上数据接入，生成方式主要指离线数据集。生成方式主要有
历史请求：通过解析一段时间内的历史访问日志等方式，获得历史访问请求。
优点：接近真实数据，样本数量充足。
缺点：数据可能同质化严重。特定日期/业务场景等无法控制。不支持冷启动。
bad case日志：需要模型输出给用户使用时，收集用户的反馈。比较典型的做法是在模型输出时让用户反馈。如果用户点踩，可以进行分析后纳入bad case案例库。
优点：在有埋点时获取难度接近历史请求。
缺点：主要适用于问题回归场景，需要对用户反馈做埋点。不支持冷启动。
人工生成：人工生成评测集在有专家经验输入的情况下可能可以获得比较好的效果，但是缺点在于成本过高，一般无法获得特别多的评测集样本。
优点：数据质量高，可以考虑到多种异常场景。支持无用户使用下的冷启动。
缺点：耗费人力，对人员的要求高。无法进行高频率更新。
历史请求+人工调整：通过对特定问题进行调整，比如减少简单问题的比例甚至直接过滤，针对bad case做重点补充等。
优点：重点问题突出。
缺点：破坏了线上的比例，无法通过评测集的测试效果验证推出线上效果。
大模型自动生成：在冷启动场景里，可能无法足够的线上真实案例作为评测集，除了人工去造之外，通过大模型自动生成评测集也是比较好的做法。
优点：样本数量充足。在没有线上实际使用时冷启动方便。
缺点：效果最差，需要人工筛选，并且需要基于效果不好的部分优化生成提示词。
人工生成+大模型自动生成：在实际的冷启动场景里，为了能同时保障评测集的质量和数量，一般的做法是由人工生成一部分评测集后，以few-shot的方式作为prompt的一部分，进行大模型自动生成。
评测集优化
当完成评测集后，可以根据需要进行一些优化。这里列出主几个常见的方面：
数据安全脱敏：针对评测集里有涉及数据安全信息时，根据需要进行脱敏。如用户的个人身份敏感信息，公司内部诸如密钥信息等内部数据，都需要根据公司的要求进行处理。
数据集分布不合理：比如生成的评测集正负样本比例、各场景样本分布等不符合评测集的预定设计，则需要通过删除过多的样本或补充缺少场景的样本的方式进行调整。
持续迭代优化：评测集需要结合实际的业务场景持续优化迭代的。基于过程中的bad case持续优化评测集，通过删除过程中发现的低质量的评测集样本，补充优质样本，或对业务的新增场景以及评测集数量比较少的小场景补充样本等方式，持续完善评测集。需要注意的是，如果是通过大模型自动生成的评测集，则不只是优化评测集，也需要根据不合理的部分优化提示词，以生成更高质量的评测集。
案例参考
蚂蚁集团：蚂蚁金服 FinEva金融评测集
蚂蚁集团、上海财经大学联合推出金融评测集Fin-Eva Version 1.0。根据对金融业务大模型的使用场景的拆分，分金融认知、金融知识、金融逻辑、内容生成以及安全合规五大类场景33个子场景共设计了上万个评测用例。
详细可以参考Github：https://github.com/alipay/financial_evaluation_dataset/tree/main
评测集生成：集团某业务使用人工造数结合大模型生成高质量评测集
该业务通过使用大模型去托管电销BD做自动回复和流程流转，实现让商家报名活动流程的自动化，提升活动的覆盖度。在该场景中，大模型先进行意图识别，驱动北极星任务的流转。针对回答不相关、要求转人工、同意开通、有意向/不明确等不同的情况，使用不同的策略进行推进。
由于商家和BD的聊天内容多种多样，场景无法穷举，意图识别的准确率和回复商家的话术，又直接影响到销售的效果。从质量的角度，如何全面地评测“AI销售模型”的能力水位，如何评测AI销售的准确率和话术体验，如何通过评测去挖掘异常场景和能力缺失点，从而反哺算法提升，都有一定的挑战。因此需要一个能“看得见”、“看得清”、“可持续”的评测方式，对AI销售进行持续全面的评估。
采用人工造数+大模型生成的方式，不仅实现了评测集的冷启动，同时又保障了评测集数量和质量的双重要求：
1. 人工造数。通过产运技提供了若干条数据，覆盖所有意图；
2. 大模型生成，使用LLM+Few-shot做补充，每个意图写单独的prompt，准确率更高。
评测维度设计
设计方法
评测维度用于评价模型输出的效果，涉及三个设计点：
模型是否有统一的评价维度，还是需要从多个维度去判断模型的能力。
对于具体的某个维度，分几档（量级）。
每个量级的定义，以及区分不同量级的标准。
具体的评测维度是根据业务人员对模型期望达到的效果来设计的。
对于选择题或判断题，业务人员的期望就是“选得准”。那一般可以设计维度数量=1，评测量级=2，分别为正确和错误。
对于生成类场景，由于没有标准答案，需要业务人员根据场景设计评测维度。比如翻译场景，“信、达、雅”是最经典的三个标准。
最后要提到的是，业务人员可能也无法一次性给出最准确的评测维度，可能需要结合实际的bad case去优化。对于某些业务人员或用户觉得生成效果不好的案例，如果根据现有的评测维度给出的评价是正向的，那就需要寻找原因调整评价维度。举个例子，比如在“AI试衣”场景里，我们预先定义了“清晰度与分辨率”、“色彩准确性”、“人体与服饰的自然融合”、“姿势与角度匹配”、“光影与背景一致性”共5个评测维度。但是实际消费者使用时反馈部分场景的bad case在评测时给出好的评价。了解分析后发现消费者表示“我的体型穿这种衣服根本不是这个效果”。那基于消费者的这个反馈，我们就需要增加评测维度“人体比例与体型适配”。
模型效果量化
在完成分维度的设计后有一个最终的问题是，如何将各个维度的效果汇总成模型的整体效果的度量，从而评估模型是变好还是变坏，是否达到了上线等后续动作的标准。不同维度的优先级是不同的，安全类、客户投诉类一般都高于其他的业务指标。
通过权重调整各个维度的重要性，最终通过加权后的得分来量化模型的最终效果，是一种相对比较简单的实现方案。对于总分，通过加权
评测任务设计与执行
评测配置设计
对于模型评测，在开始具体的评测动作前，还有一些评测设置需要确定：
评测方式
人工评测：通过人员手工评测的方式进行评测。一般用于评测集数量较少或评测准确性要求较高或者不具备自动评测条件的场景。
自动评测：自动评测分AI评测和自动化评测，可以极大提升评测效率。其中AI评测为使用大模型进行评测的方式。自动化评测适用于文本分类等客观性任务，通过自动计算BLEU、Rouge、F1等自动化指标评估模型效果。
基线评测：针对基础模型的评测，使用基线评测集进行测试。
评测类型：单个评测VS对比评测。评测对象只有1个模型还是多个模型。
AI评测
针对模型评测，可以使用大模型进行评测以提升效率。这里以百炼为例介绍如何进行AI评测。其他产品原理也是一致。AI评测的关键点在于评测Prompt的编写。
为了获得比较好的评测效果，百炼固定了Prompt框架，让用户按框架补充场景定义、评测维度（评分标准、评分档位、最大得分）。
完整的百炼的Pormpt如下
你的任务是对AI智能助手回复进行质量评分。你非常清晰地认识到当用户提出一个关于【${scene}】场景的指令时（该场景的定义为：${scene_desc}），一个AI智能助手的回复应当符合以下标准（按标准重要性程度从高到低依次给出）：[标准开始]${metric}[标准结束]评分采取${max_score}档制（1-${max_score}），各分数档位含义如下：[档位含义开始]${score_desc}[档位含义结束]针对用户指令，我们搜集到一个AI智能助手的如下回复。请根据你所知的当前场景下智能助手的回复标准，综合评估该回复并提供评价。以下是用户指令和助手回复数据：[数据开始]***[用户指令]: ${question}***[回复]: ${answer}***[参考答案]: ${ref_answer}***[数据结束]你需要按照以下流程评估以上回复：${steps}仔细思考一会，然后给出你的结论。你返回的模版如下，注意输出需保留模版中的'[['和']]'：***我认为该回复的综合评分为[[一个1-${max_score}之间的评分]]，理由如下。当前回复的优点：1.（请依次列举你认为当前回复做得好的点，每个点同时给出[[一个1-${max_score}之间的评分]]...）当前回复的不足：1.（请依次列举你认为当前回复欠缺的点，每个点同时给出[[一个1-${max_score}之间的评分]]...）***
案例参考
集团某业务自动化评测该业务在每个月/每次重要实验后需要从搜索曝光日志中抽取数万条记录进行评测，日志包含曝光的品、店以及对应的query，评测规则较为简单，众包对query和品店评分0、1、2，代表相关程度，2分（完全相关）、1分（部分相关、可以接受）、0分（不相关），通过对比实验桶和测试桶评测结果统计相关性效果。
阶段一：使用通用模型，使用few-shot的方式让prompt理解
你现在的角色是XX领域的相关性打分模型,主要功能是判断用户搜索的关键词和商户名称或商品名称之间是否具有相关性,我会给你任务和要求,请按要求返回结果。任务: 第一步:XXX第二步:XXX要求:1.按照以下格式输出回答,不要回答其他内容,输出格式: XXX2.一共只有三个得分选项即2分、1分、0分,不要给出其他的得分。3.我会给出具体的打分规则并给出对应的例子,给出的规则顺序不代表最终得分的权重,请参考完所有例子并仔细理解后给出答案,打分规则和示例如下:(1)对于商品名或商户名和关键词完全一致且意图也完全一致的,得2分例如:XXXX(2)对于商品名或商户名包含部分关键词,但意图完全一致的,得2分例如:XXXX
阶段二：基于微调后的模型进行自动评测
基于Qwen大模型模型，通过使用历史人工评测数据不断的微调后，新模型在搜索相关性评测领域的理解能力已经超过通用模型。
你现在的角色是XX领域的query-shop相关性打分模型。query:XXshop_name:XX店打分规则:0分：query与shop_name不相关。1分：query与shop_name弱相关。2分：query与shop_name强相关。……query和shop之间的相关性分数是少？
评测报告
评测数据分析
百炼等评测平台会提供基础的评测结果展示的功能。为了提供通用能力，评测平台一般无法满足业务人员对于评测报告的要求，通过柱状图、表格等方式提供评测结果的展示和分析。
评测报告编写
评测报告是评测人员输出，便于后续决策（如判断是否具备上线切换条件等）使用的报告，所以需要根据阅读人员的习惯按格式输出。以下是一些案例：
集团某业务qwen-max评测评测环境
1. 目前Qwen-max在xx环境中进行灰度测试，灰度比例15%。
2. xx环境目前主要是xx和xx业务使用。
评测结果
具体评测维度和分数如下表所示：
结论
1. Qwen-max整体评分超过XX模型，但在NL2SQL、代码编写、上下文理解和数学计算方面还是有差距。
2. 对比老版本Qwen-max，整体评分有较大提升。
增强项：NL2Frame、NL2SQL、上下文理解、摘要总结、CoT、谜题解惑、数学和工具
减弱项：代码编写
后续动作
输出评测报告后，评测的部分已经完成了。基于评测报告的结果以及评测过程中发现的问题，后续的动作有：
评测方案优化
持续优化评测集
优化评测维度
优化AI评测Prompt
bad case优化
决策模型上线或者切换
