type
tags
category
icon
password
Multi-select
优先级
重要度
状态 2
预计结束时间
添加日期
URL
状态
分类（人工）
总结（AI 摘要）
status
随着 LLM 在业务中的应用，评估正在成为产品经理一项非常核心的能力。多团队构建的评估仪表盘看似有用，但最终却被忽略，无法带来更好的产品，因为这些评估报告的指标与实际用户问题脱节
那么如何构建评估系统以真正推动产品改进呢。
当有真实反馈之后，我们要做的对 LLM 的评估并不是从幻觉这种比较常见的指标开始。这个对我们的业务没有任何意义；可能幻觉很低，但用户觉得毫无价值。
想要做一个系统的评估，有三个阶段；
- 进行错误分析，找到主要优化的点
- 构建可靠的评估套件
- 如何投入生产，并持续改进
1. 错误分析
再进行这一步的时候，要找到人类的领域专家进行判断；在中小公司里，这通常由该产品担任，因为他最清楚用户需求，场景主要解决的场景，所以是可以给出判断的。
通过给几百条用户交互的真实内容，这就类似与日记一样。让专家进行判断
判断也是分步骤的，首先是略读一下全部信息，进行判断对错，以及给出评价。
当看过的内容比较多的时候，心里大概就知道可能有哪些错误分类了，这个时候就可以针对错误进行分类：
即使是作为专家，在前期这些步骤也是要走的，因为人并不擅长预先了解 AI 会犯什么错，只有仔细检查并明确哪些方面有问题，才能找到如何优化来提升产品质量。
当然可以用 LLM 来加速这个进程，比如用它进行初筛；不过这个要给足上下文信息，还有要仔细核查他给的结论，尤其是分类，可能会分的过于细或者过粗。这个阶段 LLM 也只是加速我们去判断而已，真正的判断结果还是要掌控在人类专家手中。
确定这些之后，就可以定位产品主要出了什么问题。
2. 构建评估套件
数据集构建
当有了第一步构建的内容，其实我们已经有了一份有明确答案的监督学习数据集。
接下来我们可以训练 一个LLM 评估代理。为什么要训练这个呢，本质上是把我们掌握到的判断经验给自动化，这样在后续 CI 的时候可以用 LLM自动走一遍我们的这个数据集。看每次的改动对之前已经出现过的问题是否有影响。
那么如何构建呢：
- 少部分提示样本集（5-10%）：这个是放在 prompt 里做少样本提示用
- 训练集（50%）：这部分主要是用来调优 prompt 的，prompt 专家从这些样本中，不断找到可以改进的内容，将其补充到 prompt 中，然后在根据这些样本看是否可以输出正确的结果。
- 测试集（40%）：为了检验训练的 LLM 的泛化能力，要给他没见过的测试数据，看是否可以正常运行，这个决定了后续上线的真实效果表现。
然后通过不断的迭代，最终让这个 LLM 接近人类专家。
其实这个跟监督学习的样本划分是比较像的，只是样本比例不同。在监督学习中，因为要从这么多特征中训练到背后的逻辑，所以基本上要用 70% 的样本进行训练；之后的开发集（20%）是为了调整模型超参数，并选取表现最好的模型，而测试集（10%）就是进行泛化性能的测试。
关于评估标准
不能直接用准确率来做 LLM 的评估标准，要根据业务的场景去选择合适的指标。举几个例子：
- 比如邮件垃圾识别，这个场景要求更多的是，我可能漏判了，但是我判断的每一个垃圾邮件都是对的。因为一旦判断错，对用户而言体感就非常差。所以这里更侧重查准率。
- 还有比如 RAG 的场景，查全率就非常重要。因为 RAG的核心是要把所有需要的内容都可以找到，因为对 LLM 来说，他们更擅长从大量的上下文中找到重点内容，而不是让他凭空捏造，这样就很不准了。
这里其实可以看一下混淆矩阵：
准确率：(TP + TN) / (TP + TN + FP + FN)，模型预测正确的样本占总样本的比例。遇到不平衡问题的时候，就很麻烦了，误导性极强。
精确率（查准率）：TP / (TP + FP)：在所有被模型预测为正例的样本中，有多少是真正的正例。
召回率 ：TP / (TP + FN)， 在所有真正为正例的样本中，有多少被模型成功预测出来了。
F1-Score：2*（精确率*召回率）/（精确率+召回率） ，是精确率和召回率的调和平均数
AUC：ROC 的面积，是一个混淆矩阵最全面的表征。
所以请看一下你当前的业务场景，可能在一个业务中，有一个流程，每个阶段侧重的点也不同，这个要结合场景来选择指标。
不同架构下的评估方案
因为 LLM 的使用方式也有很多种，比如多轮对话、RAG、Agent 代理。这些方式也有一些差异
多轮对话中：
- 要先看整个会话是否达成了用户目标，要基于会话层面来看，而不是直接进入到某一次单独的会话。当发现对话不满意之后，就要找出原因
- 要先看下单轮对话是否可以重现问题，因为有可能是多轮对话的复杂性造成的，比如丢失上下文或者误解了之前的信息。通过直接看单轮对话可以帮忙找到原因
RAG中：
- rag 有 2 部分组成，检索与生成，这两部分都可能出问题，要分别排查
- 检索评估，这个本质就是一个搜索问题。所以要准备一个查询数据集，RAG 最关键的指标刚才说了是 召回率。所以看前 k 个结果中召回率如何。这里的 k 其实就是结合自己场景要关注的值，简单场景下 3-5 个就行，复杂的话可能要 20 个。所以这里主要做的就是找到满足这个场景下召回率要求的最小 k 值。
- 生成评估，这个其实是LLM 拿到 k 个结果之后生成的。所以这里有两个关键要看的，第一是忠实度，模型是否严格按照检索上下文提供事实；第二是答案相关性，回复的内容是否是用户想要的
Agent 代理：
代理跟多轮对话不同的地方在与，他有自主意识，可以根据外界环境自己规划。所以要判断他如何出错，其实可以使用 故障矩阵。
将整个代理的模块拆出来，看看到底在哪个步骤是最容易出问题的。
比如上图，发现在生成 sql 的时候问题最多，那么就重点优化就好了。
3. 实时评估，持续改进
有LLM 评估系统并非是最终目标，因为数据漂移的问题，线上的问题可能会不断的冒出新的，我们需要一整套可以持续迭代的方案。
持续集成（CI）中的评估
你的首要目标是当前已发现的旧错误要防止再现，所以我们在之前构建的测试集就派上了用场 。利用我们构建的 LLM 评估专家，在代码更改的时候，都会专门跑一变这个测试集，来测试效果。这正是 LLM 时代的回归测试。
护栏-模型输出的最后一道防线
这是一个实时的同步的过滤器，他的特点就是低延迟和误报率低，所以一般不用 LLM，直接就是基于规则的代码。这在一些高风险、严重的错误场景下，可以保护用户体验。比如很多政治敏感的话题等，虽然可以在 prompt 中约束，但依然会输出，这时候就需要基于规则的判断了。
4. 产品发布之前-冷启动问题
上面说到的都是在发布之后，有真实的反馈，那么在前期没上线之前如何测试呢？
主要有 2 方面：
- 产品经理基于对业务场景的洞察，梳理最重要的用户故事，这里本身就设计到 LLM 最重要的场景是什么，基于这些场景我们可以构建一些测试案例。
- Dogfooding，吃自己的狗粮。公司内部员工就是最好的前期用户，可以让他们产生真实的用户数据。
- 作者:xingyan
- 链接:http://blog.xingyan.me/article/29a64cad-d821-80e8-8fa1-c45a4f685857
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
