前言
我们说了这么多期大模型应用的事情，都是讲怎样提供开放能力，支持各种各样的应用，我们可以用这些能力制作一个nb的应用，那它应该如何上线，如何迭代优化？
这就是评测要做的事情。
评测是什么？重要性？
我这里说的评测并不是指基座模型的评测，而是更宽泛的概念，是从产品和业务的维度讲评测。
评测就像产品上线前的测试，bug越多，越严重，说明产品越垃圾。
但和产品测试不同，评测主要针对大模型相关的feature。
重要性：
- 评测产生的结果，是衡量模型应用好坏的标准。换句话说，评测能告诉你大模型在你的业务下，能达到一个什么效果。
- 评测是应用优化的基础。产品是不断变更迭代的，新的变动，比如你改了prompt，这个变动应该如何上线那，由评测来决定。
- 评测保证了模型在实际应用中的效果。
个人观点：没有评测，就没有应用
怎么做评测
评测最主要有两块，一是上线评测，一个是在线评测。
上线评测
目标：保证变更是可预期的
流程很简单：
- 根据你的业务场景准备测试集
- 变更agent后，根据测试集，得到测试结果
- 根据测试结果，得到评测报告
在线评测
目标：保证实际业务是符合预期的
流程：
- 根据线上数据抓取结果集（相当于测试集+结果）
- 根据结果进行监控，或报警
- 定期生成评测报告
评测指标
指标是为目标服务的，要根据你的业务制定指标，但就通用指标来讲，主要有这么几种：
- 回复效果评分：表示agent对用户的回复效果，就是看回复是否越符合人设，文档关联性，拟人程度等等。
- tool召回率：主要是看模型调用工具是否正常，参数拼接是否正确。
- 回复耗时：从用户发问开始，到agent开始回复消息的耗时，换句话说，就是用户等了多久。
除了这三种最重要的，还有一些异常指标：
- 打断率：用户主动打断，大概率生成的回答用户不满意，或者太拖沓。
- 风险值：问答敏感，或者内容涉及到暴力，恐吓等敏感信息
- bad response：用户主动标记这个回答是垃圾回答，参看gpt，这种是要重点处理的。
根据模态不同有许许多多的指标。
- 模态效果：图片生成的效果，语音转换的效果等等
- 耗时情况：文生图的耗时，asr或者tts的耗时
agent自身也需要关注一些指标：
- knowledge召回率
- memory准确率
- 多agent的效果
- taskflow效果，耗时
除此之外，还要根据业务特点，确定一些指标，这里就不写了，根据业务去确定吧。
自动化评测
在项目上线的前期，测试集内容还比较少，这时候手动测试即可，并且项目前期也不要过分关注评测，还是以功能为主。
随着项目的更新迭代，测试集会越来越大，最终使用自动化评测是必然的。关于自动化如何评测，继续看。
规则验证
在得到用户的问答信息后，需要给出一个评分。这时候可以用规则对结果进行验证。
这通常适用于解决封闭域问题。
规则引擎是一套比较成熟的方案，这里推荐rush，规则引擎
rush的好处是不仅支持表达式规则，也同时支持脚本，或者外挂wasm。
模型验证
因为大模型具有随机性，所以规则校验在解决一些开放问题时比较费劲。
我之前有做一个开放性的应用，因为模型的Temperature很大，最终把规则写的极为复杂，以至于最后我自己也维护不下去了。
所以推荐的做法是用一个专门评分的agent来打分，但这有几个需要注意的地方，
- 高模型评低模型通常是准的，比如用gpt4给自研的模型打分，准确率在0.98以上
- 对等模型也可以打分，准确率不高，这时候需要好好调prompt，准确率也能达到九成以上
- 低模型评高模型也是可以的，但误判非常严重，一般场景能有个0.5~0.8，多轮对话和拐弯抹角的场景只有0.3左右的准确率，0.3=瞎蒙。
重点：当用例多起来的时候，外挂knowledge能够很好的解决模型验证不准的问题。
神经网络验证
是的，你没看错，也可以用神经网络进行效果打分。
打分本质上是个分类问题，利用神经网络进行分类当然也是可以的。
当然缺点显而易见，准确率没有保障。
但是，这种方式对处理特定场景十分有效，比如多模态场景，安全场景。
在实践中，上文提到的安全风险预估中，就是利用神经网络来评估。
评测最佳实践
测试集的收集
在产品刚上线的时候，可以根据业务场景，构建一批测试用例。也可以在开发的时候，就有意识收集一批用例。
如果产品已经在线上，后续的agent变更，都需要尽量保证前面的用例是正确的。
每次变更时，针对业务场景，也需要补充，或变更一些用例。
端到端的评测是否必要？
我的实践是，多模态通常需要端到端的测试。
其他情况通常是不需要的。
在线评测的测试集如何抽取？
在线的情况下，通常有大量的问答数据，我们不可能把所有的数据都评测一遍，所以这涉及到数据抽取的问题。
- 按会话维度随机：比如，可以用最简单的方式，给在线评测服务做个限流就可以了。
- 按用户维度抽取：比如,用户活跃度通常成对数分布，我们将它分成不同区间，每个区间分别抽样验证
- 任何业务维度都是可以的
关于模型ab的问题
我的建议是不要做在线的模型abtest。通常上线评测，就应该能够分辨出各个基座模型在业务场景中的效果。而不是到线上去测试。
并且现在的发展方向，偏向于多模型融合，这种情况做模型ab是没意义的。
关于指标获取
为了最终得出评测指标，我们需要拿到整个agent的执行过程信息。
无侵入的方式： 可以根据日志，监控，链路追踪，打点等方式。
【推荐】侵入的方式：需要agent给出执行报告
这里解释一下为啥要推荐侵入的方式，正常来说不是无侵入的更好吗？
除了评测，在debug，调优，问题排查等等场景下，都需要这个功能，并且在设计之初，执行报告就应该作为一个agent的基本功能来提供。
线上评测为啥要抽样，为啥要低模型
本质就是成本问题，如果你特别富有，那请全量验证，高模型验证，岂不美哉。
参考gpt看一下模型的成本，差了几十倍。
多模态如何评测？
像图频音ui 这些场景，建议还是手工评测。
关于评分
0:不可用 1:基本合格 2:回答非常完美
建议用01评分，如果想提效，再用012
不建议十分制，或者百分制：
- 分制越细，评测准确率越低，
- 分制越大，效果表现越不明显，尤其是0分的用例。
关于评测结果
长期来看，随着我们的不断优化，评测指标是逐步变好的。
但是，事实是，随着功能不断累积，评测效果开始会变高，然后会保持在某个水平期间，最后随着功能堆砌会慢慢劣化。
出现这种情况，说明是达到了当前agent的上限，需要优化agent架构，或者使用多agent模式。
尾语
其实，大模型应用的工作就是这样一个循环：评测->优化->评测->优化->评测->优化->...。
没入行的切记：不要把有限的时间，浪费在无限的评测和优化中