如何发现 AI“摸鱼”？

随着基座大模型的能力越来越强，越来越多的人开始探索 AI 在应用层的可能性，比如：

• 基于企业知识库进行答疑
• 帮用户完成复杂的软件操作
• 理解应用报错日志，并自动修复
• 。。。

它们在大模型的基础上又增加了向量检索，工具调用等更加复杂的层次。

功能使用虽然方便了，但是确定性却更差了，甚至有的时候 AI 还会摸鱼：

除了被动地等待用户反馈外，作为功能的开发团队：

• 怎么对模型表现做到心中有数呢？
• 对系统做了优化后，能否在上线之前就知道优化效果呢？

本文将从常见的 RAG 评测指标中提取出模型应用效果评测的底层逻辑，并且讨论怎么将这些底层逻辑应用到自己的业务中。

为什么不直接让用户点赞呢?

像 ChatGPT, Kimi 或者 通义 等大模型的交互界面, 在每次问答后都有一个大大的点赞点踩按钮:

这也是最直接的模型评价方式, 毕竟用户就是上帝, 用户说好才是真的好。

这种方法虽然简单, 却不一定适合所有场景。很多功能都没法将点赞，点踩很自然地在产品功能上暴露。

其次, 这种评价方式存在滞后性。系统改进后, 需要上线一段时间让用户感知后, 才知道效果。这对于方案的迭代速度是大打折扣的。而且, 用户也不是用来做测试的, 我们不能将软件交付后, 再由用户发现问题, 体验会很差。在软件开发中, 我们会通过集成测试, 保证软件功能和性能至少比以前更好后, 再给用户做体验。因此, 在大模型应用中, 我们也应该考虑一些开发阶段就能使用的前置指标, 让我们心里对新方案的效果和体验有个底后, 再交由用户做最后的评判。

最后, 个人观点, 我认为用户点赞只是一种方便的用户调研方式, 不代表全部的产品体验。产品本身需要有更加高远的目标指引。

参考工作

大模型在应用层的玩法千千万万，很多场景无法找到直接可用的评测指标。

但是 RAG 作为研究者关注更多的应用领域， 相关的评测非常成熟，我们可以从中总结出评测的底层逻辑，然后应用于自己的业务场景。

ALCE

在大模型输出添加引证的论文 ALCE，作者从下面三个维度评测自己工作的效果：

• Fluency：模型输出是否流畅，和人类相似
  • 指标
    • MAUVE：对比机器书写文本和人类书写文本的相似性
• Correctness: 正确性, 即生成结果的信息量和效用是否足够.
  • 指标
    • claim recall：将真实答案（ground truth）拆成多个子声明，这些子声明被包含在模型输出中的比例

• Citation quality：文本引用的质量
  • 指标
    • citation recall：带引用的陈述中，能够完全支持引用的陈述，占的比例
    • citation precision：相关引证在引证中的占比
      • 无关引证的判断方法：引证单独无法论证陈述, 去除该引证后, 其余引证可以论证陈述

Ragas

Ragas 是一个 RAG 技术的评测框架。RAG 的核心就是检索加生成，因此它也将自己的指标分成两类，一类是衡量检索效果的（retrieval），另一类是衡量模型生成效果的（generation）。

• generation
  • Faithfulness：衡量模型输出是否遵循召回的上下文
  • Answer Relevance：模型生成结果和用户提问的相关性
• retrieval
  • context precision: 召回的前 K 个文档中，正确（和GT相关）的文档的占比
  • context recall：GT 中被上下文包含的比例

具体计算方法都比较简单，就不复述，有兴趣可以去阅读文档。

底层逻辑一：围绕过程中的关键元素

在整个 RAG 流程中，只包含四个元素

• 首先是用户提问
• 通过用户提问，检索出来的 context，即检索结果
• 大模型再根据检索结果，生成回答，即模型输出
• 另外，在评测中，对于每个提问，也会有人工写的 “真实答案”（ground truth）

RAG 中的指标，无论设计得多么精巧，都是围绕这个四个关键元素进行的，当我们用围绕的元素来描述指标时，原本晦涩难懂的名称就变得清晰起来：

以下是 ALCE 和 Ragas 中设计的评测指标，以及涉及的元素间关系图

比如提到 “忠诚度”（Faithulness） 这个指标时，没接触过模型评测的人肯定一脸懵逼；但是当你提到它衡量的是 “大模型输出” 和 “检索结果” 两个元素的一致性时，就豁然开朗了。

底层逻辑二：多维度衡量效果

大模型的输出一般都是要直接对客的，除了要准确之外，客户的体验也很重要。

比如在 ALCE 论文中，作者在衡量各种准确性的同时，还使用 MAUVE 衡量模型的生成文本的流畅性，确保优质的客户体验。

因此我自作主张地将指标分成两类，分别是 精度指标 和 体验指标：

• 诸如召回率，忠诚度等衡量模型性能和准确性，都是 精度指标
• 而流畅度这种，就属于 体验指标

我们在设计自己业务场景的指标时，最好也要包含这两种。

底层逻辑三：主张拆分

大模型因为对数字不敏感，如果让它们直接对结果从 0 到 1 打分的话，它们很难发现其中的细微差别，而且操作也比较黑盒。

所以指标设计中，一般会先把完整的输出拆分成原子的主张（claim），然后衡量每个主张的一致性，将打分问题转换成分类问题，之后我们手动写程序算一个比例，会比让大模型直接打分效果更好。

主张拆分也有个缺陷，如果输入很长的话，非常消耗模型的输出 token，速度也很慢，可以考虑使用小模型加速，我目前使用 GLM_8B，效果也还可以，速度却大大提升。

一个主张拆分用的 Prompt 如下（改变自 Ragas 的 Faithfulness 指标中的 Prompt）：

给定一段描述，分析其中每个句子的复杂性，并将每个句子分解成一个或多个完全可理解的陈述，同时确保每个陈述中没有使用代词。以JSON格式格式化输出。

描述：
爱因斯坦是一位德国出生的理论物理学家，被公认为有史以来最伟大、最有影响力的物理学家之一。他最著名的成果是提出了相对论，他也为量子力学的发展做出了重要贡献。

输出：[
    "爱因斯坦是德国出生的理论物理学家。",
    "爱因斯坦被公认为有史以来最伟大、最有影响力的物理学家之一。",
    "爱因斯坦以提出相对论而闻名。",
    "爱因斯坦也对量子力学理论的发展做出了重要贡献。"
]
                
描述：
${需要拆分的描述}
                
输出：

大模型应用和问答的不同之处

大多数的大模型指标都是针对问答设计的，我们还必须深刻理解应用和问答的不同之处，才能设计出更加适合自己应用的指标。

问答是一个更加开放性的场景，注重给启发性，模型给出的可能性越多，越能激发用户的创意。比如下面的回答一般在问答中认为是一个很好的回答：

它给了用户 5 种修复方案，用户可能从中受到启发，选择更加适合自己的方案。

在微软 GraphRAG 中，就采用 完整性（Comprehensiveness） 和 多样性（Diversity） 作为最重要的评测指标，希望模型尽可能输出所有可能的结果。而 直接性（Directness） 作为相对次要的指标。（参考论文 GraphRAG）

但是如何作为一个软件功能，用户对它的期待是完全相反的。用户期望它开箱即用，而不是去做选择题。

因此在大模型应用中，对 “直接性” 的衡量要摆在更加重要的地位。

元评测

设计好指标后，又要怎么论证指标本身的有效性呢？

可以参考 ALCE 论文的做法，单独人工打标几十或者上百条数据，然后使用 “科恩卡帕系数”（Cohen’s kappa coefficient） 证明其和人工标记存在相关性。

科恩卡帕系数可以简单理解成模型和人类打标一致的概率，但是做了点优化，减去了随机情况下一致概率的干扰，取值为 -1~1 之间，大于0就可以认为有一定相关性。ALCE 论文使用的两个指标的科恩卡帕系数分别时 0.5 和 0.6。

End

在有了可信的指标之后，我们就可以用每天的线上数据执行一遍评测，观察模型效果的变化。

还可以从中切分出一部分评测集，做完功能优化后，首先在评测集上验证，效果和体验是否有提升，有提升再发布到线上。

这样就能大大提升大模型应用的迭代效率。