大模型(LLM)应用之所以难测,根本原因不在于"测试技术不够",而在于被测对象本身的性质发生了变化。传统软件是确定性的:给定输入,期望输出可枚举、可断言;而 LLM 应用是概率性、组合性、状态依赖的——同一条输入,在不同温度、不同上下文窗口、不同检索结果、不同工具返回下,输出可能完全不同。把传统软件的测试金字塔原样套用到 LLM 应用,几乎必然出现"单元测试全绿、线上事故频发"的尴尬。

本专题从一线工程视角,拆解 LLM 应用系统测试的完整图谱:从测试金字塔的重构,到组件级测试、端到端场景测试、非功能测试、回归测试、在线测试,再到测试数据管理、CI 集成、覆盖率度量、工具选型与反模式。所有方法均给出可执行的评估指标、工具命令与数据集结构,避免停留在"要多测、要全测"的口号层面。

50.1 LLM 应用测试与传统软件测试的本质差异

理解差异是设计策略的前提。LLM 应用的测试难度来自五个相互叠加的维度。

第一,非确定性输出。 同一 prompt 在 temperature=0 时,不同推理后端(vLLM、TGI、各云厂商)仍可能因浮点累加顺序、KV-cache 命中差异产生微小分歧;temperature>0 时分歧显著放大。这意味着"断言相等"这类经典断言几乎不可用,必须改为语义断言、评分断言或分布断言。

第二,概率性失败。 传统软件的 bug 通常是确定可复现的;LLM 应用的失败往往是"100 次里错 3 次"的小概率事件。要可靠捕获 p=3% 的失败,单跑一次毫无意义,需要在同一用例上重复采样 N 次,用置信区间判断是否真正回归。统计上,要让观察失败率 0% 与真实失败率 3% 区分开,N 至少要达到 100 量级,这意味着 LLM 测试的样本成本天然比传统测试高一两个数量级。

第三,组合爆炸。 一个 RAG 应用涉及:检索(召回率、排序、重排)、prompt 模板(变量注入)、上下文窗口(截断策略)、模型(版本、量化)、工具调用(参数生成、错误处理)、护栏(输入过滤、输出过滤)。每一环都是独立变量,笛卡尔积的组合空间远超人工可枚举范围,必须用分层测试 + 抽样 + 自动化生成来覆盖。

第四,高单次成本。 每次推理都要消耗 GPU 时间或 API 配额。一个端到端用例若涉及多轮对话、检索、工具调用,单次执行成本可能从几分钱到几块钱不等。跑一个 1000 条的评估集,单次成本可能上千元,这让"每次 commit 跑全量"变得不现实,必须分层、分频次。

第五,漂移(Drift)。 模型供应商会静默升级版本(如 gpt-4-0613 → gpt-4-turbo → gpt-4o),同一个 API 名字背后可能是完全不同的权重;外部知识库内容会更新;用户的 prompt 习惯会演化。即便代码一行未改,应用行为也会随时间漂移,因此 LLM 应用需要"持续在线测试",而非"发布前测一次"。

一句话原则:LLM 测试的对象不是"函数",而是"行为分布";断言的不是"相等",而是"可接受的边界"。

50.2 测试金字塔在 LLM 中的重构

经典测试金字塔(底层单元测试最多、顶层端到端最少)在 LLM 应用中需要重构为五层,自底向上依次为:单元 → 组件 → 端到端 → 红队 → 在线。

单元测试层(最厚、最快、最便宜)。 测的是与模型无关的纯逻辑:prompt 模板的变量拼接是否正确、JSON 解析是否健壮、token 计数函数、截断算法、护栏规则的正则匹配、配置加载。这一层用 pytest / unittest 即可,毫秒级、零成本。常见反例是把"调用模型生成一句话"塞进单元测试,既慢又贵且不确定——这类应下沉到组件层用 mock 模型或本地小模型替代。

组件测试层(中等厚度、中等成本)。 把 RAG/Agent 拆成检索、prompt、工具、护栏四个子系统,各自独立测试。例如检索组件固定一份 query 集,断言 Top-K 命中率;prompt 组件固定输入,断言输出是否包含必备字段、是否触发格式约束。组件层允许调用真实模型,但应锁定 temperature=0、固定模型版本、固定检索索引快照,以保证可复现。

端到端测试层(较薄、较贵)。 用场景化用例集覆盖核心用户旅程(开户问答、订单查询、工单流转)。每个场景断言多维指标:任务完成率、关键事实正确性、语气合规、是否拒答。端到端用例数量通常控制在 50–300 条,每条跑 1–3 次,作为发布前的质量门。

红队测试层(专门一层、人工+自动化)。 针对越狱(jailbreak)、提示注入(prompt injection)、敏感内容诱导、数据泄露做对抗性测试。这一层不能用随机样本,必须用结构化攻击手册(如 AdvBench、PAIR、人工编写的行业特定攻击),并结合 LLM-as-attacker 自动生成变种。红队通过率不进入发布门,但作为独立风险报告。

在线测试层(金字塔之外、持续运行)。 包括影子流量(线上请求复制到新版本不返回用户)、A/B 测试、金丝雀发布、用户隐式反馈(点赞/点踩/重写率/会话放弃率)。在线测试是唯一能捕获"真实分布漂移"的层,也是最终的质量裁决者。

重构后的金字塔不是简单的"底多顶少",而是"快慢分层 + 频次分级":单元层每次 commit 跑、组件层每次 PR 跑、端到端层每日跑、红队每周跑、在线层持续跑。

50.3 组件测试:prompt、检索、工具、护栏各自怎么测

LLM 应用可分解为四个核心组件,每个组件的测试目标和指标都不同。

50.3.1 Prompt 组件测试

Prompt 是 LLM 应用最大的"代码债"。测试维度包括:(1)格式稳定性——用格式校验器(如 Instructor、Outlines、JSON Schema 约束解码)断言输出始终符合 schema;(2)指令遵从度——是否遵守"用中文回答""不超过 200 字""不要提到竞品"等约束,可用规则匹配 + LLM-as-judge 双重判定;(3)鲁棒性——注入空变量、超长变量、含特殊字符的变量,检查是否优雅降级而非崩溃。

实操方法:为每个 prompt 维护一份"黄金输入集"(20–50 条人工精选),锁定 temperature=0,用 DeepEval 或 Promptfoo 跑批,断言用 assert "格式字段" in output 或语义相似度阈值(如 BERTScore ≥ 0.85)。

50.3.2 检索组件测试(RAG 评测)

检索质量直接决定 RAG 应用上限。指标分两层:检索层指标——召回率(Recall@K,关键:是否召回了能回答问题的文档)、精确率(Precision@K)、MRR、nDCG;生成层指标——答案的正确性、是否忠实于检索内容(忠实度 Faithfulness)、是否完整回答了问题(答案相关性 Answer Relevance)、是否引入了幻觉。

工具链上,RAGAS 是事实标准:ragas.evaluate(dataset, metrics=[faithfulness, answer_relevancy, context_precision, context_recall])。数据集需要人工标注"问题—标准答案—相关文档块"三元组,通常 100–500 条覆盖核心场景。一个常见误区是只评检索层、不评生成层——召回率 95% 但模型仍然答错,问题往往出在 prompt 拼接或上下文截断。

50.3.3 工具调用(Tool/Function Calling)测试

Agent 类应用的核心风险是工具调用参数错误。测试要点:(1)参数生成正确率——给定自然语言意图,模型生成的工具调用 JSON 是否字段齐全、类型正确、枚举值合法,可用 JSON Schema 校验;(2)错误处理——工具返回超时、4xx、5xx、脏数据时,模型是否能识别并重试或转人工;(3)调用顺序——多步任务中工具是否按依赖图正确排序;(4)参数边界——金额为负、日期为未来、ID 不存在等边界值。

建议构造一份"工具调用回归集",每条用例包含:用户输入、期望调用的工具名、期望参数的断言(必填字段+关键值域)、期望的下一步动作。用 LangSmith 或自研 trace 校验器回放断言。

50.3.4 护栏(Guardrails)测试

护栏分输入侧(敏感词、PII、越狱检测)和输出侧(涉政、暴力、隐私、版权)。测试方法:(1)正负样本集——每类护栏维护 200+ 正样本(应通过)和 200+ 负样本(应拦截),标注拦截与否;(2)指标——精确率、召回率、F1,以及关键的"误拦截率"(把正常请求判为违规),因为误拦截直接伤害用户体验;(3)绕过测试——用谐音、拆字、多语言、emoji 替换等绕过手段验证护栏韧性;(4)延迟——护栏通常在主链路上,延迟需控制在 100ms 以内,否则拖垮整体响应。

护栏测试必须独立于模型版本演进,因为护栏规则与模型能力是两条独立的迭代线。

50.4 端到端测试:场景化用例集的设计

端到端测试不是"随便找几个问题跑一下",而是要构建有结构的场景化用例集,覆盖业务的"用户旅程全集"。

用例集结构。 推荐四维标注:场景类型(信息查询/事务办理/故障排查/闲聊/拒答)× 复杂度(单轮/多轮/多工具)× 用户画像(新手/老用户/恶意用户)× 预期行为(成功/转人工/合规拒答)。以客服机器人为例,典型用例集规模 150–300 条,各维度比例按线上真实流量分布加权,避免"测试集全是简单查询、线上全是复杂工单"的错配。

断言策略。 单一断言不够,采用多维评分卡:(1)任务完成(是/否,人工或规则判定);(2)事实正确性(关键实体是否准确,可用 LLM-as-judge 对比标准答案);(3)格式合规(是否符合接口 schema);(4)语气与品牌一致性;(5)安全性(是否触发护栏)。每维 0–2 分,总分作为该用例的质量分,设定阈值(如 ≥7/10)为通过。

采样策略。 由于概率性失败,每条端到端用例至少跑 3 次取众数或最差值,关键用例(高价值场景)跑 5–10 次。统计上,3 次采样观察到 0 次失败时,真实失败率 95% 置信上限约 63%(粗糙上界),因此端到端用例的"通过"只能说明"无明显回归",不能作为质量保证的唯一依据。

人工评审闭环。 端到端失败用例必须进入人工评审,分类为"真 bug / 评测器误判 / 边缘 case 容忍",前两类进入修复队列,第三类记录到已知限制清单。没有这个闭环,自动评测分会被噪声淹没。

50.5 非功能测试:性能、安全、合规、可访问性、多语言

功能性测试之外,非功能属性往往是上线与否的真正裁决因素。

性能测试。 指标:首 token 延迟(TTFT)、token 生成速率(TPS)、端到端延迟 P50/P95/P99、并发吞吐、长上下文下的延迟退化。工具:Locus、k6、自研压测脚本,结合 vLLM 的 --max-num-seqs 调优。注意:LLM 的延迟分布是长尾,P99 可能是 P50 的 5–10 倍,SLA 必须按 P99 而非均值承诺。

安全测试。 重点三项:(1)越狱与提示注入,用 AdvBench、JailbreakBench、PAIR 等数据集红队;(2)数据泄露,测试模型是否会泄露 system prompt、检索到的其他用户数据、训练数据中的 PII;(3)供应链,检查模型权重来源、HuggingFace 仓库的可信度(签名、下载量、社区报告)、依赖库漏洞(CVE 扫描)。

合规测试。 国内场景需对接《生成式人工智能服务管理暂行办法》的备案与安全评估要求,测试用例需覆盖:社会主义核心价值观、民族宗教、暴恐、隐私、商业合规。建议建立"合规评估集"(通常 1000+ 条),由法务与安全团队共同维护,任何模型升级或 prompt 大改后必须全量回归。

可访问性测试。 语音输入识别对方言、口音、语速的覆盖度;屏幕阅读器对模型输出的可读性;低视力用户的字号与对比度。这部分常被忽视,但对公共服务类应用是硬要求。

多语言测试。 同一意图用中、英、日、粤、文言等变体输入,断言输出语义一致与语言正确。LLM 在低资源语言上幻觉率显著升高,需独立评估集。

50.6 回归测试:bad case 回归集是核心资产

LLM 应用迭代中,最值钱的资产不是代码,而是bad case 回归集——历史上踩过的坑,固化成永不删除的测试用例。

回归集构成。 三类来源:(1)线上用户投诉/点踩的真实 case(脱敏后入库);(2)红队发现的攻击成功 case;(3)评测中发现的模型固有缺陷(如某类数学题总错、某类实体总幻觉)。每条 case 标注:输入、期望输出(或期望行为)、严重程度(P0/P1/P2)、来源、修复版本。

回归集治理。 反模式是"只增不减",最终堆积成几千条跑不动的死库。正确做法:按严重程度分级调度——P0 每次发布必跑、P1 每周跑、P2 每月采样跑;对连续 10 次发布都通过的用例降级;对新引入的同类 case 做聚类去重。回归集应纳入版本控制(git 仓库或专门的数据版本工具如 DVC),每次变更可 diff。

漂移监控。 回归集本身要定期"复审":半年前的 bad case 在当前模型上是否仍然成立?如果模型已天然修复,该用例可移出核心集。这避免回归集逐渐失去区分度。

50.7 在线测试:AB、影子流量、金丝雀

离线评测再全,也无法完全模拟真实流量分布。上线阶段的在线测试是质量闭环的最后一公里。

影子流量(Shadow / Mirror)。 把线上真实请求复制一份到新版本,不返回给用户,只记录输出与线上版本的差异。优点:零用户风险、真实分布;缺点:成本翻倍。适合重大版本升级前的预热验证。

A/B 测试。 按用户 ID 哈希分流(如 95% 老版本、5% 新版本),监控核心业务指标(解决率、转人工率、会话时长、用户满意度)与技术指标(延迟、错误率)。统计显著性需达到 p<0.05 且样本量充足(每臂数千次会话),否则容易因随机波动误判。注意 SRM(样本比例失调)检验——如果分桶后实际流量比与设计不符,说明存在分流 bug,所有结论作废。

金丝雀发布(Canary)。 先放量 1%→5%→25%→100%,每级观察 24–48 小时的告警面板与人工抽检,任一指标恶化立即回滚。金丝雀的关键不是"放多少",而是"观察多久、回滚阈值多严"——建议预设量化回滚条件(如转人工率上升 >10% 或延迟 P95 上升 >30%),由告警自动触发,而非靠人盯。

在线指标的反作弊。 用户点踩率受 UI 位置影响、会话时长被"卡死循环"污染、解决率可能被模型过度自信虚高。每个在线指标都要配套"健康度校验",避免单一指标优化导致系统退化(Goodhart 定律)。

50.8 测试数据管理:评估集隔离、脱敏、版本

LLM 测试的数据治理比代码治理更关键,因为模型质量直接由评估集定义。

评估集隔离。 严格区分三层:(1)开发集——日常调试用,可被工程师反复查看、模型可能间接"见过";(2)验证集——调参选模型用,工程师不直接看 case 内容,避免主观过拟合;(3)留出测试集(Hold-out)——仅在发布前运行一次,用于无偏估计真实质量。三层必须物理隔离,禁止交叉使用。常见事故是开发集污染了测试集,导致离线指标虚高、上线翻车。

脱敏。 任何来自真实用户的 case 必须脱敏:手机号、身份证、银行卡、姓名、地址、病历等 PII 用规则替换为占位符(如 [PHONE_1]),并保留映射表在受控环境内。脱敏要双向——既脱输入,也脱输出与检索上下文。脱敏流程需通过隐私团队评审,避免"看似脱了实际可还原"(如罕见病+罕见地名组合仍可定位个体)。

版本化。 评估集用 DVC 或 git-LFS 管理,每次评测记录:数据集版本、模型版本、prompt 版本、评测脚本版本、评测结果哈希。这样任何"指标变化"都可追溯到具体变量,而不是"不知道是数据变了还是模型变了"。结果数据本身也建议存为 parquet/jsonl 进版本库,便于历史趋势可视化。

数据版权与合规。 评估集若含第三方内容(如公开 benchmark 子集),需确认许可证允许内部评测使用;涉及个人信息的需符合《个人信息保护法》最小必要原则。

50.9 测试自动化与 CI 集成

没有 CI 的 LLM 测试会迅速退化为"想起来跑一下、想不起来就算了"。自动化是质量纪律的载体。

分层 CI 流水线。 推荐四阶段:(1)pre-commit(本地 hook,秒级):跑单元测试 + prompt 格式 lint + 评估集 schema 校验;(2)PR 流水线(分钟级):跑组件测试 + 50 条核心端到端用例,作为合并门;(3)夜间流水线(小时级):跑全量端到端用例 + 红队子集 + 性能基准;(4)发布流水线:跑合规评估集全量 + 留出测试集 + 在线影子流量对比。

成本控制。 LLM 测试贵,必须分层调度:PR 阶段只跑高价值子集(如 50 条黄金用例),用本地小模型或 mock 模型替代大模型跑组件测试;夜间用真实模型跑全量。建议维护"快速评估集"(50 条,2 分钟,5 元)和"全量评估集"(500 条,40 分钟,200 元)两套,按场景选择。

结果可视化。 CI 必须输出可读报告:每条用例的通过/失败、各维度评分趋势曲线、与上次基线的 diff、失败用例的输入输出全文。推荐集成 LangSmith、Phoenix(Arize)、或自建 Grafana 面板。光有数字没有趋势,工程师无法判断"是噪声还是真回归"。

质量门(Quality Gate)。 定义硬性合并条件:(1)核心用例通过率 ≥ 95%;(2)无 P0 级失败;(3)关键指标(如答案正确率)相对基线下降不超过 2%;(4)延迟 P95 不超过基线 110%;(5)护栏误拦截率不超过基线。任一不满足,流水线红,PR 不可合并。

50.10 测试覆盖率与质量度量

传统代码覆盖率(行/分支)对 LLM 应用几乎无意义——LLM 应用的"代码"常常只有几百行胶水逻辑,真正决定质量的是 prompt、检索、模型行为。需要一套新的覆盖率度量。

行为覆盖率。 评估集是否覆盖了业务场景全集。可用场景矩阵(场景类型 × 复杂度 × 用户画像)的填充率衡量,目标 ≥ 90% 单元有至少 3 条用例。低覆盖单元即为高风险盲区。

意图覆盖率。 从线上日志聚类出真实用户意图 Top-N(如用 sentence-BERT 聚类),检查评估集是否覆盖了流量占比累计 95% 以上的意图簇。未覆盖的意图簇即为"线上有、测试无"的缺口,应优先补齐。

风险覆盖率。 红队攻击手册的覆盖度,如越狱、注入、PII 泄露、不当内容各类是否都有 ≥ 100 条用例。

指标健康度。 评测器本身是否可信。可用"人工抽检一致性"衡量——随机抽 100 条评测结果,人工复核,计算与评测器判断的一致率,目标 ≥ 85%;低于此值说明 LLM-as-judge 不可靠,需更换评测模型或加规则约束。

反直觉结论:LLM 应用的"覆盖率"不是代码行数,而是"线上真实分布被测试集代表了多少"。

50.11 工具选型:DeepEval、Promptfoo、RAGAS 与自研边界

工具不是越多越好,选型要服从于"是否能集成进 CI、是否能版本化、是否可解释"。

DeepEval。 Python 原生,pytest 风格,内置 faithfulness、answer_relevancy、toxicity 等指标,支持 LLM-as-judge 与规则断言混合。适合需要把评测纳入 pytest 体系、与单元测试统一调度的团队。优点:上手快、与 CI 集成顺畅;缺点:对复杂 Agent 链路的支持较弱,自定义指标需写较多胶水。

Promptfoo。 强项在 prompt 对比与回归:同一输入集,并排跑多个 prompt/模型版本,生成可视化对比矩阵。支持 YAML 配置用例、本地缓存结果、CLI 一键重跑。适合 prompt 工程阶段的大规模版本对比(如 10 个 prompt 候选 × 200 条用例)。优点:对比体验极佳、成本低(缓存);缺点:指标偏轻量,深度评测仍需配合 RAGAS/DeepEval。

RAGAS。 RAG 评测的事实标准,核心指标 faithfulness、context_precision、context_recall、answer_relevancy 均针对检索增强场景设计。优点:指标定义严谨、学术认可度高;缺点:对非 RAG 场景(纯生成、Agent)不适用,且 LLM-as-judge 部分对评测模型依赖大,需选强模型(如 GPT-4 级)做 judge 否则噪声大。

LangSmith / Langfuse / Phoenix。 这一类是观测+评测平台,核心价值是 trace 级调试与在线评测,能直接把线上 trace 转为评测用例。适合需要"从生产流量反哺评估集"的团队。

自研边界。 何时该自研:(1)行业特定指标(如医疗答案的临床正确性、法律答案的法条引用准确率),通用工具无法覆盖;(2)评测器需要对接内部知识库或业务系统;(3)需要特殊的采样与统计策略(如分层抽样、贝叶斯置信区间)。自研应基于开源框架扩展,而非从零造轮子。

选型决策矩阵。 团队 < 5 人且场景标准:DeepEval + RAGAS;重视 prompt 迭代速度:Promptfoo + DeepEval;Agent 复杂链路:LangSmith + 自研 trace 断言;强行业属性:RAGAS + 自研领域指标。组合优于单一。

50.12 反模式:不测就上、只测 happy path

最后列出一线上反复出现的反模式,作为团队自查清单。

反模式一:不测就上。 "模型很强、demo 看着没问题、先上线再说"——这是最常见的翻车起点。LLM 的能力边界只有在评测中才会暴露,demo 的 5 个问题永远不能代表线上 5000 种问法。对策:任何上线必须跑核心评估集,无评估集不允许上线。

反模式二:只测 happy path。 评估集全是清晰、礼貌、信息完整的提问;线上却是模糊、口语化、带错别字、信息缺失的真实输入。对策:评估集必须按线上日志分布采样,刻意保留噪声与边缘 case。

反模式三:评测器不可信却不校验。 用一个弱模型做 LLM-as-judge,评分随机波动,团队逐渐不信任评测,退回到"靠感觉"。对策:定期人工抽检评测器一致率,不一致的用例进入评测器优化队列。

反模式四:评估集污染。 工程师把测试 case 拿来调试 prompt,无意中让 prompt"记住"了测试集,离线指标飞涨、上线拉胯。对策:三层评估集物理隔离,hold-out 测试集仅在发布流水线中运行,日常不可见。

反模式五:只评离线、不看在线。 离线指标全绿,上线后用户投诉激增——因为离线分布与线上分布错配。对策:建立影子流量对比,把线上真实请求每月采样进评估集,持续校准分布。

反模式六:护栏一刀切。 为了安全把护栏阈值调到极严,正常请求被大面积拦截,用户流失。对策:护栏指标同时看召回与误拦截,误拦截率纳入质量门。

反模式七:回归集只增不减。 几千条死用例,跑不动、没人维护、逐渐失效。对策:定期复审、分级调度、聚类去重。

反模式八:把在线指标当唯一真理。 点踩率上升就紧急回滚,实际是 UI 改版导致点踩按钮位置变化。对策:每个在线指标配套健康度校验与多维交叉验证。

本专题小结

大模型应用的系统测试,本质是把"测试对象从函数变为行为分布"的方法论迁移。核心要点:(1)接受非确定性,改相等断言为评分断言与分布断言;(2)重构测试金字塔为单元/组件/端到端/红队/在线五层,按频次而非数量分层调度;(3)组件测试按 prompt/检索/工具/护栏四个子系统分别建立指标体系,RAGAS、DeepEval、Promptfoo 各有适用边界;(4)端到端用多维评分卡 + 多次采样,单次结果不可信;(5)非功能测试(性能 P99、安全越狱、合规备案、可访问性、多语言)往往是真正上线门;(6)bad case 回归集与三层评估集隔离是 LLM 应用最值钱的两项资产;(7)CI 集成必须分层、设硬质量门、输出可视化趋势;(8)覆盖率度量从"代码行"转向"行为分布与意图覆盖";(9)反模式的共同根源是把 LLM 当传统软件测——只测 happy path、不校验评测器、不做在线对照,任何一条都会让"全绿"变成幻觉。一句话:LLM 应用的测试不是验证"它能跑",而是持续证明"它在真实分布下依然在可接受的边界内"。

本专题来源

• 一线 LLM 应用工程实践与事故复盘(客服机器人、企业知识库、Agent 类应用的测试经验)
• RAGAS、DeepEval、Promptfoo、LangSmith、Langfuse、Phoenix(Arize)等工具官方文档与基准评测
• AdvBench、JailbreakBench、PAIR、TruthfulQA、MT-Bench、HELM 等学术评测基准
• 《生成式人工智能服务管理暂行办法》《个人信息保护法》《数据安全法》相关合规评估要求
• LangChain、LlamaIndex、Instructor、Outlines、vLLM 等框架的工程测试实践
• Google Testing Pyramid、Microsoft AI Red Team、OpenAI Evals 方法论的公开资料