1. 鲸林向海首页
  2. 大模型评测

LLM应用评测全指南：核心指标、基准测试与实践方法

• 大模型评测 • 阅读 80

LLM应用评测全指南：核心指标、基准测试与实践方法

手动抽查提示词和输出，既慢又容易遗漏，长期来看难以持续。要确保 LLM 应用上线后稳定可靠，必须将评估过程自动化、流水线化。本文旨在全面解析 LLM 评测的各个方面，帮助你构建长期稳定运行的 LLM 应用。

对 LLM 进行评测，是确保其输出符合人类预期的关键环节，涉及伦理安全、准确性、相关性等多个维度。从工程实践角度看，LLM 的输出可被转化为一系列单元测试用例，评测标准则通过特定的量化指标来衡量。

本文将详细介绍：
* LLM 评测与 LLM 应用评测的核心差异
* 离线评测的构成要素：基准测试、评测数据集构建方法、基于 LLM-as-a-judge 技术的指标选择，以及常见误区
* 实时评测及其对离线基准数据集的改进作用

LLM 评测与 LLM 应用评测的本质区别

首先需要明确：LLM 特指经过训练、能够理解和生成人类语言的基础模型（如 GPT-4o），而 LLM 应用 则是包含 LLM 及其他辅助组件的完整解决方案。这些组件可能包括工具调用（用于智能体）、检索系统（用于 RAG）、响应缓存等，它们共同使 LLM 能在实际场景中发挥作用，例如客户支持聊天机器人、销售代理或文本转 SQL 生成器。

值得注意的是，LLM 应用有时也可能仅由 LLM 本身构成，ChatGPT 就是一个典型例子。下图展示了一个基于 RAG 的文本转 SQL 应用示例：

LLM应用评测全指南：核心指标、基准测试与实践方法

该应用的核心目标是：根据用户查询，快速准确地生成可执行的 SQL 语句。用户查询首先进入检索管道，从数据库模式中提取相关的表、字段及外键关系；这些信息随后作为上下文，输入到生成管道以产生正确的 SQL。这一前一后的管道构成了典型的 RAG 式 LLM 应用。

（注：流程不必严格遵循先检索后生成，但对于中等规模的数据库模式，检索步骤能有效减少 LLM 的幻觉问题。）

由于应用被拆分为多个“乐高积木”式的组件，评测就不能再用单一标准衡量整体。相比单一模型，LLM 应用至少需要对每个核心组件进行独立评估，才能准确定位瓶颈。

例如，在上述文本转 SQL 应用中：
* 检索管道 的评估指标是 上下文召回率 —— 衡量其是否找全了解决问题所必需的所有表。

LLM应用评测全指南：核心指标、基准测试与实践方法

* 生成管道 的评估指标是 SQL 正确率 —— 在给定前 K 张表作为上下文的前提下，评估生成的 SQL 语句能否通过编译、执行并返回正确结果。

LLM应用评测全指南：核心指标、基准测试与实践方法

总而言之，组件化设计提升了 LLM 应用的能力，但也使评测工作更加复杂。要精准定位短板，必须将评测指标细化到管道级别，对每个组件进行独立考核。

在下一节中，我们将深入探讨如何在开发阶段对 LLM 应用进行离线评测，包括快速创建大量测试用例的方法，以及如何为不同组件选择合适的评测指标。

离线评测：测试用例、评测数据集、指标与基准测试

1. 离线评测概述

离线评测是指在本地开发环境中对 LLM 应用进行评测。你可以在 Python 脚本、Colab/Jupyter Notebooks 甚至 CI/CD 流水线（如 GitHub Actions）中运行评测，待性能达标后再部署到生产环境。通过量化结果，你可以优化应用架构，或通过迭代为各组件找到最佳超参数配置（如选择哪个 LLM 模型、如何优化提示词、使用哪种向量化模型等）。整个过程依赖数据驱动，而非主观感觉。

LLM应用评测全指南：核心指标、基准测试与实践方法

LLM 应用基准测试 是在标准化的评测数据集上，运用特定指标，按照自定义标准衡量应用性能的过程，这正是离线评测的核心实践。以前文的文本转 SQL 应用为例，我们可以使用上下文召回率和 SQL 正确性这两个指标进行基准测试：将一批用户问题及对应的标准 SQL 答案（测试用例）输入系统，即可计算出其真实性能水平。

厘清几个关键术语：
* 基准测试 = 评测数据集 + 评测指标
* 评测数据集 = 测试用例的集合
* LLM 评测指标 可以有多种，每条测试用例都会被多项指标依次评估

每当对 LLM 应用进行修改（如更换检索架构或 LLM 服务商）时，都应在本地重新运行这些基准测试，以监测性能变化。你甚至可以将基准测试集成到 CI/CD 流水线中，实现自动化的回归测试。

2. 评测数据集与测试用例

评测数据集是测试用例的集合。一个 LLM 测试用例 是用于对系统进行单元测试的数据单元，通常包含以下参数：
* 输入 —— LLM 应用的输入（如用户查询）
* 实际输出 —— LLM 应用生成的文本响应
* 预期输出 —— 给定输入下，LLM 应用的理想响应
* 检索上下文 —— RAG 管道/检索系统实际检索到的文本块/文档列表
* 上下文 —— 预期输出所应基于的理想文本块/文档列表

关键提醒：不同指标需要不同的参数，无需为每条用例填写所有字段，但也不能遗漏必要字段。例如：
* 无参考相关性指标只需要 输入 和 实际输出。
* 基于参考的相关性指标则需要 输入、实际输出 和 预期输出。
* 文本转 SQL 场景中的“上下文召回率”指标，关心检索是否全面，因此只需要 输入 和 检索上下文。

构建评测数据集时需注意以下几点：
* 起步规模：建议先积累 50–100 条 高质量的测试用例。这个数量既能揭示潜在问题，又不会因规模过大而难以启动。数据可来自人工编写或生产环境日志（如果应用已上线）。
* 样本选择：优先纳入 最可能出错的场景，如边界情况、长尾查询、对抗性输入等，这样评测效率最高。
* 实际输出：无需提前计算，尤其是在进行回归测试时，可以实时运行应用生成。
* 标准答案：务必为每条测试用例提供 预期输出，这是基于参考的指标能够准确计算的前提。

（1）如何构建评测数据集

虽然强调准备带预期输出的测试用例很重要，但实际操作（尤其是需要一次性准备 50-100 条时）颇具挑战。目前主流方法有两条路径：
* 人工标注：最直接但成本较高。可以聘请标注员逐条编写，或从已上线应用的真实日志中筛选高质量样本，再进行人工精修。
* 合成数据：不依赖人力，利用 LLM 自动生成测试用例。这种方法看似省事，但技巧性更强，下文将重点展开。

（2）用 LLM 批量生成合成数据

核心思路：将“上下文”输入给 LLM，让其同时生成 输入（如用户查询）和对应的 预期输出（如标准答案）。

以前文的文本转 SQL 场景为例，一个有效的合成数据生成流程如下：
1. 从数据库模式中随机抽取若干张表作为“上下文”，确保数据多样性。
2. 让 LLM 根据这些表，编写一条符合用户习惯的自然语言查询，作为 输入。
3. 让 LLM 为这条查询生成对应的标准 SQL 语句，作为 预期输出。
4. 重复步骤 1-3，直至达到所需的数据规模。

（3）提升合成数据的真实性

直接生成的合成用例往往过于规整，带有明显的 AI 痕迹。为了使其更贴近真实数据，可以采用 演化指令 技术。

该技术最初由微软的 Evol-Instruct 论文提出：对已有的合成查询进行改写、添加噪声或追加约束条件，将简单的问法升级为更复杂、更接近人类真实表达方式的查询。

简而言之，先合成，再演化，是逼近人工标注质量的有效策略。

3. LLM 评测指标

LLM 评测指标的意义在于将评估过程自动化。依赖人工逐条打分虽然可行，但会重回低效、主观的老路。因此，核心问题有两个：
* 如何自定义一套评测指标？
* 如果直接选用现有指标，哪些是最佳实践？

传统指标如 BERTScore、ROUGE 和 n-gram 难以有效评估大语言模型的开放式生成内容。一种行之有效的解决方案是采用“LLM-as-a-Judge”方法，即让大语言模型自身担任评估裁判。

多篇研究已证实，让大模型评估大模型的输出，其结果与人类评估者的相关性最高。通过以下策略，可以进一步提升这种相关性：
* 链式思考：要求评估模型进行逐步推理后再给出评分。
* 信息压缩：通过提示词将长文本摘要为关键信息，减少评估噪声。
* 问题-答案生成：将主观性问题转化为客观的问答形式，使评分更具数学依据。

以下是大语言模型应用常用的评估指标，每个指标侧重于评估不同维度：
* 正确性
* 答案相关性
* 忠实性
* 相似性
* 连贯性
* 上下文召回
* 上下文相关性
* 上下文精确度
* 偏见
* 毒性

开发者可以根据应用的具体需求，选择合适的指标组合，对模型进行全面的评估。

4. 基准测试

一套完整的基准测试包含评测数据集和评估指标。与 MMLU、DROP 等通用基准不同，LLM 应用的基准测试通常是“私人订制”的，原因如下：
* 指标无标准：即使是文本转 SQL 这样的特定场景，也没有统一的评估指标，选择何种指标取决于应用的具体架构。
* 数据集需定制：不同的数据库 schema 需要配套的 query-SQL 数据对，不存在通用的现成数据集。

离线评测的最大陷阱：静态数据集
许多人在构建完基准数据集后便不再更新，这会导致随着系统迭代，评估逐渐偏离实际。数据漏洞的分布是动态变化的，数据集必须持续演进，始终反映应用中最新的问题模式，否则高分可能只是脱离实际的自满。

下一节将探讨如何利用生产数据来持续进化数据集。

实时评测

（若您的 LLM 应用尚未部署，本节内容可暂作参考）离线评估受限于预设的测试用例，无法覆盖真实用户千变万化的使用方式。只有通过生产数据（即应用在真实环境中接收的输入和生成的响应），才能发现未知的边界情况。

然而，生产数据量巨大。例如，每月产生 5 万条响应，全部进行人工审核是不现实的。即使随机抽样 10%，对标注人员仍是繁重的负担。实时评测的价值在于提供一套筛选机制。

其实质是：首先使用无参考指标（无需标准答案，仅基于输入和实际输出进行评估）为每条响应打分，然后只筛选出得分较低、可能存在问题的响应进行人工复核。复核确认的高价值案例可直接并入基准数据集。

通过这种方式，人工只需处理其中 1-2% 的可疑样本，效率得以极大提升。

生产环境使用什么指标？
在开发阶段，我们强调使用基于参考的指标（需要标准答案进行对比），因其评估更为严格。然而，上线后缺乏标准答案，必须切换到无参考指标来量化风险。示例如下：

LLM应用评测全指南：核心指标、基准测试与实践方法

其核心思路是：选择一个或多个无参考指标，对每条生产响应进行评分，并依据这些分数决定哪些响应应被用于扩充基准数据集。将此类无参考指标集成为实时流水线，就能持续从生产环境中捕获“值得回炉”的案例，反向滋养基准数据集，形成闭环。

小结：评测是持续进化的飞轮

总而言之，LLM 应用的评测并非一劳永逸。
* 离线评测在开发阶段“把好第一道关”——构建测试用例，选择指标，运行基准测试，优化架构。
* 真正的考验在于生产环境，用户行为难以预测，边界案例层出不穷。

因此，正确的做法是离线与实时评测双管齐下。离线评测确保基础质量，实时评测则像一位全天候的“质检员”，用无参考指标自动筛查，让人工专注于处理极少数可疑案例，并将高价值数据反馈至基准数据集。如此，数据集得以生长，评估体系持续进化，系统才能越跑越稳。

记住三个关键点：
* 组件化评估：不要用单一尺度衡量整个系统。例如，对 RAG 系统应分别评估检索和生成组件。
* 利用合成数据与演化：人工标注耗时，可让 LLM 生成数据并通过改写进行增强，快速积累测试弹药。
* 挖掘生产数据金矿：通过实时评测筛选问题，反哺离线基准，不让数据价值白白流失。

只有将评测构建为闭环，LLM 应用才能健康、长久地运行。否则，系统可能在上线后很快出现不可预知的问题。

关于大模型评测诊断NoneLinear
https://nonelinear.com

  1. 评测榜单——已囊括300+大模型、300+评测维度，每周更新大模型评测结果
  2. 模型选型降本——一键选出最合适模型，效果更优，成本降低50%以上
  3. 智能模型超市——统一API，一键调用全球所有大模型，GPT5 / Gemini2.5 / Claude4.5免费体验，高并发，自动故障切换，实时监控模型调用效果

LLM应用评测全指南：核心指标、基准测试与实践方法

关注“鲸栖”小程序，掌握最新AI资讯

本文来自网络搜集，不代表鲸林向海立场，如有侵权，联系删除。转载请注明出处：http://www.itsolotime.com/archives/14700

赞 (0)
0 0
上一篇 2025年10月22日 上午5:03
下一篇 2025年10月22日 下午3:19

相关推荐