为什么 LLM 应用必须先评测

大模型应用上线最容易踩的坑是「demo 挺好，上线就翻车」。demo 阶段你测的是你自己想到的那几个 case，上线后用户问的千奇百怪。没有系统化的评测集，你根本不知道模型在哪些场景会出错，更不知道改一版是变好还是变坏。

评测不是「跑个分看看」，而是给你的应用建一把尺子。每次改提示词、换模型、调参数，都用同一把尺子量一遍，才能确认改动是正向的。这在软件工程里叫回归测试，LLM 应用也一样需要。

没有评测集的 LLM 应用就像没有测试用例的代码——你不知道它什么时候会崩，改完也不知道有没有修好。
本文核心知识点
  • 评测集覆盖典型场景和边界 case 的测试集，是回归测试的基础。
  • 评测指标不只是准确率，还有幻觉率、拒答率、格式合规率等。
  • 幻觉缓解通过 RAG、提示工程、输出校验等手段降低模型胡说八道的概率。
  • 在线评测上线后持续监控真实用户反馈，发现新问题补充评测集。
LLM 评测配图：左侧文档堆上有放大镜，右侧仪表盘带柱状图和勾选标记，蓝色渐变扁平风格
评测流程的直观示意：左边是待测文档和样例，右边是打分仪表盘。

评测集怎么搭

评测集不是随便找几条问题。好的评测集要覆盖三类：典型场景（用户最常问的）、边界 case（容易出错的）、以及你专门踩过坑的（线上出过问题的）。每类都要有标准答案，模型答完自动或人工打分。

# 评测集的基本结构
# 每条样本包含：
# - question: 用户问题
# - expected: 期望回答（或参考答案要点）
# - category: 属于哪个场景类别
# - difficulty: 难度等级（简单/中等/困难）

# 示例：客服场景的评测样本
{
  "question": "我买的东西能退吗",
  "expected_points": ["说明退货政策", "告知退货流程", "提及时效"],
  "category": "售后",
  "difficulty": "简单"
}

# 评测集规模：
# - 起步阶段：100 条核心场景就够
# - 稳定阶段：500-1000 条覆盖主要场景
# - 成熟阶段：持续补充线上错误案例，不追求总量

评测指标：准确率之外看什么

准确率是最基本的指标，但对 LLM 应用来说远远不够。一个客服机器人答错了产品规格，和它在不知道答案时瞎编一个答案，是完全不同性质的错误。前者是知识不全，后者是幻觉——后者更危险。

指标含义为什么重要
准确率回答和参考答案的匹配度最基础的能力指标
幻觉率编造不存在的事实的比例直接影响用户信任
拒答率不确定时说不知道的比例太低容易幻觉，太高显得没用
格式合规率输出格式符合下游要求的比例对接系统时常出问题

幻觉是什么、怎么量

幻觉就是模型一本正经地胡说八道——说的话语法通顺、逻辑自洽，但事实是错的或者完全是编的。这是大模型最核心的问题：它的训练目标是「生成合理的下一个词」，不是「说真话」。

量幻觉率最简单的方法：从评测集里挑那些需要外部知识才能回答的问题，看模型会不会在不知道的时候瞎编。另一种方法是让模型输出引用来源，检查它引用的内容是否真的支持它的结论。

幻觉的两种类型
  • 事实性幻觉编造不存在的事实：编造一个不存在的法规条款。
  • 忠实性幻觉曲解已有资料：RAG 检索到的材料被模型改写得偏离原意。

幻觉缓解的常用手段

幻觉不能完全消除，但可以显著降低。常用手段有四个方向：RAG 让模型基于检索到的资料回答而不是凭记忆；提示词里明确说「不知道就说不知道」；输出后加一层校验，检查关键事实是否有来源支撑；以及对高风险场景加人工审核兜底。

# 缓解幻觉的提示词策略
# 系统提示词里加这些约束：
# 1. 只基于提供的参考资料回答
# 2. 如果参考资料不足以回答，明确说"资料不足"
# 3. 不要编造引用、数据或条款编号
# 4. 不确定的时候宁可少说，不要多说

# 输出校验的简单做法：
# - 提取回答中的数字、日期、专有名词
# - 对照参考资料逐一检查是否存在
# - 找不到依据的标记为"待人工确认"