Linkedin 最近出了一篇技术博客,聊了内部为期半年的生成式AI产品实践，Musings on building a Generative AI product。文章聊了RAG、路由、Agent和内部API调用的一些思路和反思，其中有一部分不小的篇幅在聊Evaluation。
RAG作为当前LLM实践落地最重要的方式之一，评估的逻辑是什么？最常见的RAGAS评估框架具体怎么展开？这些问题正好和LInkedin介绍的实践，相互呼应，就以此篇小结RAG Evaluation相关的内容。
Linkedin 是如何做评估的？
如果按照前文 探索LLM的透明度：从解释到评估，在不确定性中寻找确定性 中聊的评估分类，这样的实践明显属于是Application Evalutaion的范畴。下图也清楚的展示了三段评估过程，不同的主体和不同的方法。
-
第一阶段，工程师，自动化评估。 工程师执行快速、粗略的评估以获得方向指标，文中也指出Linkedin正在构建基于模型的评估器。自动化评估是圣杯,但是能实现符合场景和需求的自动化评估还是很不易的。
-
第二阶段，标注员评估，人工评估 。在自动化评估的基础上,标注员要进行人工的评估.当应用的诉求是"既真实又富有同理心"时,人工评估的体系就必不可少.而且还透过语言学家团队进行了工具和指标的构建。
-
第三阶段，用户，A/B Test 。让用户去评估最终的效果。
用什么指标评估?
在 Linkedin这的这篇文章里, 只是介绍了指标的方向, 指标的指向包括整体质量得分、幻觉率、负责任的 AI 违规、连贯性、风格等,并未进行详细的展开,不如来看看 RAGAS 的框架和指标明细。
RAGAS 是 RAG 领域的常见的评估框架,在这个框架的指标指引中, 分了两个大类, 基于生成 和 检索 两个大的维度构建指标,背后对应着 RAG 两个核心过程.在此框架下,RAGAS 给出了 12 个可以参考的指标.
Ragas 允许用户根据具体需求选择和组合这些指标，甚至可以自定义权重来计算整体评分。这种灵活性使得 Ragas 能够适应不同类型的 RAG 系统和应用场景。虽然 RAGAS 的框架很常用,但是相比面向过程的抽像,我觉得下图面向对象的抽象, 则能更好的理解和解释怎么更好的评估 RAG 应用.
-
第一个主体,"Query"（查询），这是用户输入的问题或请求。
-
第二个主体,"Context"（上下文），这是系统检索到的相关信息。
-
第三个主体,"Response"（响应），这是系统根据查询和上下文生成的答案。
这三个主体之间构成的 RAG 三角,每一条边代表着三种不同的链接关系，也构成了评估RAG系统的的不同维度.其实 RAGAS的很多评估指标也能按照这个框架的这三条边理解, 只是两者配合会更容易理解, 都覆盖了 RAG 的核心过程.
-
Context Relevance（上下文相关性） ：检索到的上下文是否与查询相关？这评估了系统的检索能力。
-
Answer Relevance（答案相关性） ：生成的响应是否与查询相关？这评估了系统理解问题并提供相关答案的能力。
-
Groundedness（基于事实） ：响应是否由上下文支持？这评估了系统是否基于检索到的信息生成答案，而不是"幻觉"或编造信息。
**为什么评估如此重要?
**
随着模型越来越精进,LLM 更像是一种能力,能够大幅降低研发的难度和复杂度.但是就像 LInkedin 的这段研发过程一样,前一个月可能能完成了 80% 的体验,但是后续从 80%➡️95% 的过程是一个缓慢又爬坡的过程.
这也从侧面说明了,为什么评估是一个如此重要的方向. 因为需要明确应用面向体验的过程牵引 ,明确过程中的迭代方向.尤其是在面向LLM模型的幻觉和不稳定的情况下，能够提供稳定和一致的应用变得异常珍贵。
在这个过程中，面向应用的评估就如同一枚精准的指南针，指引着我们前行。因此，Evaluation评估不仅仅是一个方向，更是一个为应用提供稳定性和可持续性支持的关键环节。🧭