LLM 评测体系：从“感觉不错”到“指标说话”，科学评估大模型应用

2026 年，大模型应用的评测已经从“人工看几条效果”走向“系统化评测体系”。但很多团队依然靠感觉上线：改了个提示词，觉得“看起来更好”就发布，结果上线后准确率不升反降。这篇文章讲清楚 LLM 评测的完整体系：评测维度、评测集建设、自动化评测方法、评测平台搭建，以及如何用评测驱动持续迭代。

评测基准

一、为什么评测是大模型应用的“地基”

没有评测就没有迭代

• 提示词改好改坏，没有指标说不清；
• 模型换版本，效果是升是降，没有基线对比不了；
• 上线后用户反馈差，没有日志与评测，排查无据。

一句话：评测是“大模型应用工程化”的分水岭——没有评测，你的系统永远停留在“演示”阶段。

评测解决三个核心问题

1. 能不能用：任务完成质量是否达标；
2. 能不能上线：稳定性、边界、成本是否可控；
3. 能不能持续：每次变更是否被客观验证、是否可回退。

二、评测什么：五个关键维度

1. 正确性（Accuracy）

• 事实正确：答案内容与事实/标准答案一致；
• 推理正确：逻辑链条是否正确；
• 输出格式正确：结构化输出是否符合 schema。

2. 忠实性（Faithfulness）

• 是否基于提供的上下文回答（防幻觉）；
• 是否编造了不存在的引用、数据、来源；
• 检索不到时是否诚实拒答。

3. 相关性（Relevance）

• 回答是否紧扣问题；
• 是否答非所问、是否过度扩展；
• 关键信息是否遗漏。

4. 风格与合规（Style & Compliance）

• 语气、结构是否符合业务规范；
• 是否触碰敏感词、越权承诺；
• 是否遵循内容安全规则。

5. 效率与成本（Efficiency & Cost）

• 响应延迟；
• token 消耗；
• 平均单次成本。

维度的取舍：不是所有业务都要五个全上

• 知识库问答：正确性、忠实性、相关性为主；
• 客服对话：风格合规、忠实性为主；
• 代码助手：正确性、可执行性为主；
• 营销文案：风格、合规、相关性为主。

先选 2-3 个核心维度，跑熟后再加，不要一开始就堆全套指标。

每条评测用例的“可判标准”

好的评测用例不是“问一句看答案”，而是带上判断标准：

• 标准答案：可以直接比对；
• 判分要点：必须包含/禁止出现的要素；
• 容错说明：哪些偏差可以接受；
• 评测维度：本条主要测什么（正确性/忠实性/风格）。

标准写不清，评测就做不准。

三、评测集：评测体系的“标尺”

评测集的质量决定评测质量

评测集是评测体系的根基，要满足四个条件：

• 代表性：覆盖真实业务的典型问题；
• 全面性：覆盖简单/复杂/边界/异常四类；
• 明确性：每条有明确的“预期结果”或“判断标准”；
• 独立性：与训练/调试数据分离，防止“背题”。

评测集的组成

• 典型问题集：日常高频问题（60%）；
• 边界问题集：容易出错的边界场景（25%）；
• 对抗问题集：刻意刁难的异常场景（15%）。

一条评测用例的完整写法

以“政策问答”为例：

text
问题：员工报销交通费需要哪些凭证？ 标准答案：发票、行程单、审批单，缺一不可。 判分要点：必须包含“发票”和“审批单”；提及“行程单”加分。 容错：可以补充“电子发票同样有效”。 类别：政策类 / 正确性 + 忠实性

这样一条用例，自动化（关键词/LLM 裁判）和人工都能评，且可复现。

评测集的“防污染”原则

评测集最怕两件事：混入训练数据和泄露给被测模型。

• 评测用例不能出现在训练/微调数据里（否则分数虚高）；
• 评测集要访问控制，不给外部模型或 API 提供提示；
• 公开模型评测时会“背题”，自建评测集要定期更新新增用例。

防污染 = 评测可信的前提，被污染的评测集还不如没有。

评测集的维护

• 线上新增高频问题 → 定期补充进评测集；
• 业务规则变化 → 同步更新评测标准；
• 每季度评审一次：剔除过时、补充新增。

评测集怎么来的：三个来源

1. 线上真实日志：从线上问答/调用日志里筛高频问题，这是最贴近业务的；
2. 业务专家出题：让业务骨干按典型场景出题，覆盖“大家都会问的”；
3. 故障复盘沉淀：把历史上答错的案例纳入评测集，防止“重蹈覆辙”。

评测集是资产：每一次线上翻车、每一次用户投诉，都值得沉淀成一条评测用例。

评测集的分层结构

推荐“三层结构”：

• 核心集（20 条）：最关键业务场景，任何变更必测；
• 标准集（100 条）：覆盖主要场景，变更时全量测；
• 扩展集（500 条+）：边界与对抗用例，月度回归测。

核心集 + 标准集 + 扩展集，让评测快而准，不因集太大而拖慢迭代。

人工评测

四、自动化评测：让指标说话

自动化评测的两条路线

路线一：规则评测（低成本、可解释）

• 关键词/正则匹配：检查是否包含必含要素；
• 格式校验：JSON 结构、字段名、数据类型；
• 引用校验：检查引用编号是否存在；
• 长度限制：超长/过短判定。

路线二：模型评测（灵活、贴近真实）

• 用强模型当“评委”（LLM-as-a-Judge），对输出打分；
• 支持复杂标准（语气、结构、推理质量）；
• 需要防“评委偏见”（如对长答案偏好）。

模型裁判的工程实践

• 评分要“结构化”：输出 JSON（分数 + 理由）；
• 分项评分：正确性、忠实性、相关性分开打；
• 多人对照：同一条数据多个模型评，取稳定结论；
• 定期校准：抽评“评委判分 vs 人工判分”的一致性。

LLM 裁判的提示词要点

评委提示词直接影响评分质量，关键点：

• 给评分标准：明确每一档的判定条件（如 90 分 = 完整正确且简洁）；
• 给判断依据：要求给出“为什么打这个分”的具体理由；
• 约束评分格式：结构化输出，方便程序解析；
• 防止位置偏差：随机打乱候选顺序，防止“总是选第一个”；
• 防止重复：同一个评委不要连续评同一类问题，避免风格漂移。

提示词写不好，评委就是“带偏见的裁判”。

自动化评测的三条红线

1. 评测集与训练/调试数据隔离：防止“背题”造成的虚高；
2. 评委模型与待测模型分离：别让“自己评自己”；
3. 评测过程可复现：固定版本、参数、随机种子，保证同一代码两次跑结果一致。

常见自动化指标

• 准确率：正确数 / 总数；
• 忠实度：基于上下文的比例；
• 拒答率：应拒答的识别率；
• 幻觉率：编造内容的比例；
• 平均延迟、平均 token。

评测指标

评测分数的解读：不要只盯着平均分

• 看分布不看均值：平均分 85 分，可能是 70% 的 95 分 + 30% 的 60 分，后者正是要修的部分；
• 按类看：政策类 95 分、流程类 70 分 → 优先补流程类；
• 按历史看：对比上一次评测，找出“这版改坏了什么”。

评测工具怎么选

• 自建脚本：适合 50 条以内小评测集，快速验证；
• 开源评测框架（LangSmith、DeepEval、Promptfoo 等）：内置指标、报告、对比，适合中等规模；
• 自建评测平台：多团队、大规模时，把评测集、任务、报告、权限统一管理。

选型建议：先跑起来再说，有 500 条以上用例、2 个以上团队在协作时，再考虑自建平台。

评测结果可视化

评测报告最好能“一眼看懂”：

• 雷达图：五个维度得分一览；
• 趋势图：历次评测变化曲线，变更影响一目了然；
• 分类热力图：哪类问题失分最多，先修哪类。

没有可视化，评测报告就是一串没人看的数字。

五、人工评测：机器评不了的交给人工

什么场景必须人工

• 风格、情感、态度类主观指标；
• 合规敏感内容（政策、法务、医疗）；
• 评测集之外的开放问题；
• 自动化评测发现异常后的复核。

人工评测的流程设计

• 抽样本（随机 + 分层）：
• 每批次随机抽 50-100 条；
• 覆盖各类别、各难度；
• 双人标注：两人独立打标，不一致的讨论；
• 标注指南：定义每一档标准，防止“每个人理解不一样”。

人工评测的成本控制

• 全量自动化 + 抽样人工；
• 人工重点看“自动化存疑”的样本；
• 标注员要培训、要一致性测试。

评测日志

人机协作的评测分工

• 自动化负责“量”：全量跑，找出异常、给出评分；
• 人工负责“质”：抽查自动化评分低/存疑的样本，判断是“真差”还是“评错”；
• 规则负责“硬约束”：格式、长度、敏感词这类能用规则判定的，别浪费人和模型。

分工原则：能规则的用规则，能自动化的用模型，剩下的才给人工。

评分标尺：让人工评测“有据可依”

人工评测最大的风险是“标准不一”，建议用 5 分制 + 判分细则：

• 5 分：完全正确，无瑕疵；
• 4 分：基本正确，个别措辞不当；
• 3 分：方向对但有遗漏或小错误；
• 2 分：部分正确，关键信息缺失；
• 1 分：错误或答非所问。

每档都要写“典型表现描述”，标注人员对照打分，避免“凭感觉给分”。

五、评测流程：从开发到上线

持续评测的三个阶段

1. 开发期：提示词改动 → 跑评测集 → 对比基线；
2. 上线前：全量评测 + 人工抽检 + 灰度验证；
3. 上线后：线上日志每天抽检 + 定期回归，及时发现退化。

变更管理

• 每次改提示词/模型/检索逻辑 → 必须跑评测；
• 评测结果记录在案（版本 + 指标 + 结论）；
• 指标下降 → 回滚或优化，不带病上线。

一个标准迭代闭环

提示词变更 → 跑评测 → 看指标 → 对比基线 → 决定上线/回滚/再改

评测与 CI/CD 的结合

成熟的团队会把评测嵌进发布流程：

1. 提示词或代码变更后自动触发评测；
2. 评测集全量跑一遍，生成报告；
3. 关键指标低于基线 → 阻断发布；
4. 指标达标 → 允许进入灰度。

把评测变成“发布的一道门禁”，才能真正防止“带病上线”。

评测责任的归属

• 评测集谁维护：业务方（定义标准）+ 技术方（实现自动化）共同维护；
• 评测结果谁负责：产品/算法负责人，对指标变化负责；
• 异常谁处理：谁改的谁解释，评测不过不给过。

没有责任人的评测是走流程，有责任人的评测才是管理。

评测体系建设的三个里程碑

• 第 1 个月：建起 100 条评测集 + 规则评测，先让“能测”；
• 第 3 个月：引入 LLM 裁判 + 人工抽检，让“测得准”；
• 第 6 个月：嵌入发布流程 + 可视化报表，让“测得上线”。

别想一步到位：先让评测跑起来，再慢慢变准、变全。

评测报告与运营节奏

• 日维度：自动化评测自动跑，异常自动告警；
• 周维度：变更后的评测报告 + 人工抽检结论，项目例会同步；
• 月维度：评测集更新、评委校准、趋势回顾。

报告要能“向上汇报”：一张趋势图 + 三类问题分析 + 下一步优化项，管理层看得懂，团队执行得了。

六、真实案例：客服助手的评测体系

背景：某客服助手频繁改动，出现“改了一次政策解读，准确率掉 15%”的情况。

做法：

1. 建评测集：300 条真实客服问题（覆盖政策/流程/边界）；
2. 自动化：规则（引用完整性）+ LLM 裁判（语气、相关性）；
3. 人工：每周抽 50 条复核；
4. 基线：上线前跑全量，记录准确率、忠实度、延迟。

效果：

• 每次变更先跑评测，准确率从 78% 稳定到 90%+；
• 变更导致的回退率下降 60%；
• 上线后监控“忠实度/幻觉率”防止持续恶化。

案例二：金融风控文本的评测

背景：某金融机构用大模型生成风控分析报告，人工审核成本高。

做法：

1. 建 200 条报告评测集，标准含事实正确、引用合规、风险提示完整；
2. 自动化：规则校验格式 + LLM 裁判检查风险点覆盖；
3. 人工：重点复核“高风险判定”的报告。

效果：模型输出的一次通过率从 62% 提到 85%，人工复核量下降四成。

评测集的反哺：评测数据也是训练数据

评测过程中积累的“优质问题+标准答案”，可以沉淀为微调数据、示例库、Agent 工具说明。评测不只是“检查”，更是“知识沉淀”。

• 误区一：评测集越大越好。大而杂不如小而准；
• 误区二：只测准确率。忠实性、相关性、合规同样重要；
• 误区三：人工评测等于标准。人工有主观偏差，要多人+协议；
• 误区四：上线后不评测。线上效果会退化，必须持续回归；
• 误区五：评测集一成不变。业务变了评测集不变，指标再好看也没意义。

评测的组织保障：谁来做

• 评测负责人：算法/产品团队指派一人专职，维护评测集、跑流程、出报告；
• 业务参与：业务专家审评测标准、评审异常样本；
• 管理介入：把评测指标纳入迭代流程门禁，形成制度，而不是靠自觉。

评测要“有人认领、有人负责、有人追责”，否则落地三周就流于形式。

八、总结与行动清单

1. 建评测集：覆盖四类、带标准、定期维护；
2. 自动化优先：规则 + LLM 裁判双通道；
3. 人工复核：主观与合规场景人工兜底；
4. 变更必测：改提示词/模型必须跑评测；
5. 持续回归：上线后定期评测，防止退化。

给团队的落地顺序：先花一天把评测集雏形搭起来（30 条核心问题），再用自动化跑通报告，最后嵌入发布流程。先跑起来，再跑准，再跑快——评测体系建设最忌讳“完美主义等不到上线”。

给读者：评测不是“上线前的仪式”，而是“持续运营的仪表盘”。一套靠谱的评测集 + 评测流程，能让你的 AI 应用从“感觉不错”变成“有数据、有底气”。别等出了问题再建评测，那是亡羊补牢。

最后提醒：评测的投入要“配得上业务的重要性”——核心业务用全流程评测，边缘功能做轻量抽检，别让评测成本超过业务价值。评测体系的终点不是“分数好看”，而是“上线放心、迭代有据”——它应该是团队决策的依据，而不是应付检查的摆设。

我是狗蛋，关注我，持续拆解 AI 行业的关键变化。