AI大模型测试实战：从断言到评估的思维转变

AI时代下测试的三大体系

开发和测试的边界正在被AI重塑——测试人员开始写项目代码，开发者也得学会测试。这位从测开转型、语言从Python切换到JS的UP主，在B站分享了一套系统的AI测试方法论，核心是他半年前就提出的三种测试体系，如今已逐渐清晰落地。

第一种是用AI测试，即借助AI辅助测试、提高效率。半年前这还是测试领域最热门的话题，但如今已成为过去式。第二种是和AI测试（AI主导测试），人和AI各司其职，需求分析、用例设计、系统探索、代码编写、自动化回归等大部分工作可以交给AI完成。腾讯、阿里、字节以及转向工程化研究的DeepSeek^广告，正在推动的正是这种AI主导测试的模式。

第三种也是本文重点——对AI进行测试（AI应用测试）。随着中国移动、中国电信的AI客服，以及AI占卜、AI视频生成等应用越来越多，越来越多软件内部集成了AI功能。这类软件同样需要测试，但思路、流程和传统软件测试完全不同。

为什么从「测试」变成「评估」

传统软件测试依赖断言：断言状态码、断言返回数据、断言字段内容，结果非对即错、非通过即失败，没有第三种可能。这是因为传统软件的输出是确定性的——ID是几就是几，输出基本一致、稳定可靠。

但AI大模型是概率性的，这决定了断言不再适用。UP主从两个角度解释了概率性的来源：

原理层面，主流生成式大模型的架构大多参考Transformer，而Transformer在输出时本质上是一个概率选择的过程。大模型天生自带概率性——同一个问题可能给出不同回答。

结果层面，即便结果是确定的（比如输出数字2），它的表现形式也是多样的：中文大写「贰」、小写「二」、英文two、阿拉伯数字2、二进制、十六进制、ASCII码……更不用说模型参数、提示词的任何微小改动都会导致结果剧变。

正因如此，简单的相等/不相等断言变得不合适——相等场景可能对，但不相等场景有几千万种可能。所以需要一种新方式：评估。评估不再判断「对或错」，而是通过打分表达「有多好、有多差」。

这套逻辑其实是国际惯例。就像判断一个人不能简单说「好人坏人」，评价智力用试卷分数，诊断癌症、抑郁症等复杂领域也都用评分方式。对模仿人的AI采用打分评估，是古今中外在复杂场景下最合理的方案。

评估与测试并非互相取代

值得澄清的是，AI评估领域并非只用评估、抛弃测试。评估负责打分，测试则相当于为分数划定「及格线」——就像高考有录取分数线，肿瘤、抑郁诊断也有分数阈值。产品能否上线，最终仍需依据评估分数的及格线给出明确结论。

打分通常用0到1的连续值（0.1、0.2……0.999），但也可以离散化：0表示不通过（0分），1表示满分（通过），从而回归到传统断言式的判定。连续评分与传统断言，两种方式在实际项目中都会用到。

Transformer架构对大模型概率性的影响值得进一步说明。Transformer在生成每个词（Token）时，会计算词表中所有候选词的概率分布，再通过「采样」策略从中选取——而非机械地取概率最高的那个。控制这一随机程度的关键参数叫做Temperature（温度）：温度越高，输出越随机多样；温度为0时，模型每次都选概率最高的词，输出趋于确定。此外还有Top-p、Top-k等采样参数同样影响输出多样性。这意味着即便是同一套模型权重、同一条提示词，只要Temperature不为0，每次调用的结果在字面上就可能不同。这也是为什么「版本固定」中需要把模型参数列为被测版本的组成部分——参数的任何变化都会改变输出分布，让前后两次评估结果失去可比性。

版本固定：AI评估的严格前提

传统测试有版本号概念——测哪个版本、哪个版本有bug、版本间做了什么改动。但AI评估更复杂，因为它模糊且可能波动，对版本的要求更严格，需要固定两个版本：

被测版本：被测系统本身的版本，由使用的模型、传入的参数、提示词、上下文共同构成。任何一项变化都意味着被测版本变化。比如测的是DeepSeek，换成GPT就是版本不对，结果需要重新评估解读。

评估版本：谁测的、怎么测的，包括数据集、断言、提示词、门槛。同一个系统用不同AI、不同数据集测，打出的分数就不一样，就像做江苏卷和全国卷结果不同。

只有固定两个版本、每次仅替换一个，才能做有价值的横向对比：同样测试手段换不同模型，可对比模型质量；同样被测系统换不同门槛，可对比门槛效果。若两个版本同时变化，结果就成了完全独立的评估，失去对比价值。

类比性能测试更好理解

UP主给出了一个很实用的类比：AI评估与性能测试高度相似。性能测试同样不特别关心对错，而是在特定条件下通过一组数据发现问题，且发现问题后不能只测一轮，要做两轮对比、拿对比结果去提交。学过性能测试的同学可以把相关概念、思路直接往AI评估上迁移。

评估什么：LLM、知识库、Agent三层递进

很多人误以为AI评估就是堆一堆指标（忠诚度、召回率等），但UP主强调：要先确定评估对象，因为不同对象的目的和指标完全不同。常见评估对象分三种，且呈递进关系：

大语言模型（LLM）：评估生成内容的正确性、完整性、安全性和稳定性。对DeepSeek这类公司是必测项；对普通公司，则用于模型选型（哪个更好、更快、更聪明）、提示词优化（基于结果评估而非拍脑门），以及模型微调后的效果验证——现在千问等发布了不少可本地微调的小模型，微调后同样需要评估。

知识库（RAG）：原理是先检索正确资料，再结合资料回答问题。评估要覆盖各个环节——检索对不对、准确度、忠诚度、最终结果对不对。召回率、忠诚度等指标主要用在这里，忠诚度即生成结果是否有对应参考资料支撑。

智能体（Agent）：客服Agent、数据Agent、知识库Agent已很常见，未来还会有旅游、法律、医疗Agent。Agent原理包含任务规划、工具使用、任务推进，评估内容和指标又不一样。

这三者是递进而非三选一的关系：智能体内部往往挂着知识库，知识库和智能体又都要用大模型。学习路线因此清晰——先掌握大模型评估，再到知识库，最后到最复杂的智能体（涵盖工具选择、任务编排、知识库使用）。

用什么测：promptfoo工具选型

有了方法论，还需要配套工具。UP主推荐了promptfoo，理由充分：

它是命令行和YAML驱动的工具，支持CLI意味着可以被AI自己使用。这个用来评估AI的工具本身又能被AI调用，未来「AI评估AI」的场景很有潜力。同时它也支持人工评估——在当前行业通识里，AI还不如人聪明，人工评估是金标准，而通过YAML编写用例断言，与零代码框架封装的思路一致。

此外它支持批量调用、支持Python自定义扩展，扩展性强、前景好，且已被OpenAI收购，优秀程度得到认可。它能覆盖LLM、知识库、Agent三层评估对象。

针对不同场景，工具选型可以更灵活：做学术性的指标研究（如DeepSeek评估模型指标数据）、做面向用户的线上智能体（通过生产监控评估实际效果）各有更合适的选择。但对大部分测试同学来说，评估是为了测试、测试是为了判定产品能否上线（带验收性质），promptfoo是较合适的入门选择。

promptfoo的核心工作流基于YAML配置文件驱动：用户在配置文件中声明被测的模型提供商（如OpenAI、Anthropic、本地Ollama等）、输入的提示词模板、测试数据集，以及断言规则（支持包含关键词、正则匹配、语义相似度、调用另一个LLM作为裁判等多种断言类型）。运行promptfoo eval命令后，工具会自动批量调用模型、执行断言并生成可视化报告，支持在浏览器中对比不同模型或提示词版本的得分差异。其中「LLM-as-a-Judge（用LLM作为评估裁判）」模式尤为常用——让一个能力较强的模型（如GPT-4）对被测模型的输出进行打分，从而实现对开放式问答的自动化评估。这一模式正好呼应了前文提到的「AI评估AI」趋势，也是promptfoo能覆盖LLM、RAG、Agent三层对象的技术基础。

写在最后

这套内容看似枯燥，却是整个AI测试体系中最有价值的部分——它解决的是「方向层面」而非「执行层面」的问题。理解了从断言到评估的思维转变、版本固定的严格要求、三层评估对象的递进关系，即便没有动手实操，面试时也能聊上两句，接到实际任务时也有清晰方向。工具和具体语法反而是次要的，因为一切实操都建立在这套方法论之上。

背景补充

RAG（Retrieval-Augmented Generation，检索增强生成）是目前企业落地大模型最主流的方式之一。其核心流程分为两步：先将外部知识（文档、数据库等）切片后转换为向量存入向量数据库；用户提问时，系统先用同样的向量化方式检索最相关的若干片段，再将这些片段连同问题一起送入大模型，由模型据此生成回答。这套机制让模型能够回答其训练数据之外的领域知识，同时降低「幻觉」风险。RAG评估因此天然分为两个阶段：检索阶段（召回的文档是否相关、是否覆盖了答案所需信息，对应召回率/Recall指标）和生成阶段（模型的回答是否忠实于检索到的参考内容，而非凭空捏造，对应忠诚度/Faithfulness指标）。两个阶段都可能出问题，且原因和修复方向完全不同，这正是RAG评估需要分环节覆盖的原因。