近年来，大语言模型（LLM）快速渗透进各类产品——智能客服、代码助手、内容生成、Agent 自动执行……企业对这些 AI 功能的质量要求水涨船高。央视财经数据显示，2026 年上半年 AI 智能体开发人才需求同比增长 244%，而 AI 质量保障方向的岗位供给几乎处于真空状态。很多传统测试工程师想切入这个方向，却不知道从哪里着手。
本文从实际工作出发，梳理传统 QA 转型 LLM 评测需要补齐的 7 块核心知识。
一、理解评测范式转变：从"验证功能"到"验证能力"
传统测试的核心是确定性验证——输入 A 预期输出 B，用 assertEquals 完成断言。大模型评测面对的是非确定性系统：同一个 Prompt 问十次，可能得到三种不同但都对的说法。
这意味着必须建立新的评测思维：
语义断言代替字符串比对：不再比原文是否相等，而比意思是否一致。通过 embedding 算余弦相似度，或者在关键时刻用更强的大模型做裁判（LLM-as-a-Judge）。
从"缺陷密度"到"能力画像"：传统测试报告用 Bug 数说话，LLM 评测则需要给出模型在多维度（知识、推理、代码、安全、多模态）上的能力分布图。
统计学思维：结果存在概率波动，需要报告置信区间，控制温度参数，多轮采样取平均。
二、掌握主流评测基准与指标体系
大模型评测不是想测什么就测什么，业内有成熟的 Benchmark 生态。以下几个是入门必须了解的：
评测维度 | 代表基准 | 评测内容 |
|---|
综合知识 | MMLU / C-Eval | 57 学科多选，考察知识广度 |
数学推理 | GSM8K / MATH / AIME | 小学到竞赛级数学题 |
代码生成 | HumanEval / LiveCodeBench / SWE-bench | 函数生成、Issue 修复 |
常识推理 | HellaSwag / ARC | 日常情境推理 |
指令遵循 | IFEval | 模型能否正确理解指令约束 |
安全性 | TruthfulQA / WMDP / HarmBench | 幻觉、偏见、越狱攻防 |
多模态 | MMMU / MMBench / Video-MME | 图文理解、视频分析 |
Agent 能力 | AgentBench / WebArena / OSWorld | 工具调用、多步任务执行 |
2025 年实施的国标 GB/T 45288.2 给出了"2-4-6"评测框架（2 类视角、4 类要素、6 大维度），中国信通院的"方升"体系也已积累超 600 万条测试数据——这些标准化成果是测试工程师切入时可以直接借用的底层框架。
三、打通评测工具链与自动化脚本
在大模型评测中，Python 脚本能力从"加分项"变成了"入场券"。典型的日常工作包括：
用 requests 批量调用模型 API，收集生成结果
用 pytest 组织评测用例、embedding 做语义评判
将评测流水线接入 CI/CD，实现每次模型迭代自动回归
用 Jupyter 做数据分析，可视化模型在不同维度上的表现变化
核心工具链建议：Python 3.9+、pytest、LangChain/Langfuse（可观测性）、OpenCompass/lm-evaluation-harness/EvalScope（评测框架）、DeepEval（单元级评测库）。
四、理解 RAG 与 Agent 的评测特殊性
企业落地大模型的主力模式是 RAG（检索增强生成）和 Agent。这两类系统的评测远比纯对话复杂：
RAG 评测需要分层：
Agent 评测需要验证链路：
传统接口测试的参数校验思路仍然有用，但评测范围和判断标准都大幅扩展了。
五、掌握数据构建与质量分析
大模型评测非常依赖高质量数据集。数据构建、清洗、标注质量控制，正是测试工程师可以发挥优势的地方。
评测集设计：围绕业务场景设计测试用例——高价值场景、边界场景、对抗场景、长尾场景
Badcase 回收与归因：上线后的用户反馈、模型失败案例需要系统化回收，并判断问题出在模型、检索、提示词还是系统流程
合成数据生成：利用大模型批量构造多样化的评测样本，用脚本做二次校验
行业里有一个广为人知的说法——“大模型的效果三分靠模型，七分靠数据”。测试工程师在数据质量管控方面有天然优势。
六、建立安全与对齐评测意识
大模型上线前必须通过安全评测。这块内容传统测试基本不涉及，但在 AI 测试中是硬性门槛：
2025 年 ITU 发布的国际标准 ITU-T F.748.44 已对大模型基准测试的指标体系和测试方法给出通用规范，安全评测是其中的关键组成部分。
七、拥抱"质量策略师"的角色进化
最后也是最重要的一点：心态和角色的转变。
传统测试找 Bug，大模型评测定标准。产品经理可能只给一句"让模型回答得更准确一些"，你需要自己去定义什么是"准确"，设计评测方案，给出可量化的质量结论。
你的价值不再体现在"发现了多少 Bug"，而是体现在：
总结：传统测试工程师切入大模型评测，不是从零开始，而是一次技能栈的平顺升级。自动化脚本经验、CI/CD 集成能力、业务理解深度、数据质量敏感度，这些都是可以直接迁移的核心资产。需要补齐的主要是新评测框架（Benchmark 体系）、新评测方法（语义/统计/LLM-as-Judge）、新技术概念（RAG/Agent/多模态），以及安全与对齐层面的新维度。
窗口期还在，但不会永远敞开。
