大模型测试技术概览
技术地图 + 测试视角 · 这篇不是讲某一个接口怎么调，而是讲现在大模型技术都发展到哪了，以及测试团队分别该关注什么
这篇放在整套资料里的位置
如果接口测试主线解决的是“怎么测”，这一篇解决的是“现在大模型技术有哪些方向，这些方向分别会引出什么测试问题”。它更像测试团队的技术导航图。
第1章：为什么要补这篇
随着大模型能力越来越复杂，测试团队面对的问题已经不再只是 Chat 接口和文本问答。现在常见的系统已经涉及推理模型、RAG、Tool Calling、MCP、Agent、多模态、GUI Agent、安全对齐、部署优化、模型切换和回归评测。如果没有一张技术地图，测试工作会很容易碎片化。
核心目标
这篇不是要把测试同学培养成算法工程师，而是要让测试同学知道： 1. 现在大模型技术的主要版图是什么。 2. 每个方向为什么会影响测试。 3. 每个方向最值得关注的测试风险是什么。
第2章：当前大模型技术地图
结合当前主流实践、MCP 官方规范，以及类似 dive-into-llms 这类教学型资源，可以把现在与测试最相关的大模型技术大致整理为以下几层。
模型层：基础模型、推理模型、数学推理、长上下文、知识编辑、微调、对齐。 应用层：Prompt、RAG、结构化输出、工具调用、MCP、Agent、工作流。 交互层：多轮对话、流式输出、多模态输入输出、GUI Agent、Computer Use。 工程层：部署、推理优化、量化、服务稳定性、评测、回归、质量基线。
| 技术方向 | 它解决什么问题 | 测试为什么必须关心 |
|---|---|---|
| Prompt / CoT | 通过提示词引导模型行为与推理过程 | Prompt 改一个词就可能引发明显回归 |
| RAG | 让模型基于外部知识回答 | 会引入检索层、切分层、召回层的新错误 |
| Tool Calling | 让模型调用外部能力 | 从“说错”升级到“做错” |
| MCP | 标准化能力发现、工具、资源、提示模板 | 需要做协议级接口测试 |
| Agent / GUI Agent | 让模型自主规划和执行多步任务 | 会出现死循环、误操作、越权、成本失控 |
| 多模态 | 让模型理解图像、音频、视频、文档 | 会引入 OCR/ASR/视觉幻觉/保守回答等问题 |
| 微调 / 知识编辑 | 让模型定向增强或改写知识 | 要验证增强生效，也要防止副作用和遗忘 |
| 安全对齐 / 红队 | 约束模型输出和工具行为 | 越狱、提示注入、隐私泄露都属于高风险 |
| 部署与推理优化 | 让模型更快、更省资源、更稳定 | 量化和推理框架切换都可能引发质量退化 |
第3章：模型能力与推理
“模型能力”是很多测试团队容易忽视的一层。因为表面上看，测试面对的是接口；但接口背后调用的其实是不同能力类型的模型。对话模型、推理模型、数学模型、代码模型、多模态模型，它们的风险并不一样。
3.1 推理模型为什么值得单独看
| 类型 | 特点 | 测试关注 |
|---|---|---|
| 普通对话模型 | 响应快、偏通用、解释性强 | 问答质量、格式遵循、拒答 |
| 推理模型 | 更强调复杂任务拆解和中间推理 | 复杂问题正确率、稳定性、耗时、长链路回归 |
| 数学/代码专项模型 | 特定任务更强 | 标准答案正确率、边界问题、逻辑严谨性 |
测试提醒
推理模型的风险往往不是“完全不会答”，而是“看起来推得挺像，但结论错了一点”。所以推理类测试最好准备标准题集和分步评估口径。
3.2 知识编辑和微调为什么也和测试有关
像 dive-into-llms 这类教程里会把“知识编辑”“微调与部署”单独列为主题。这类技术虽然更偏研发，但测试团队也要知道，因为每次知识编辑、模型微调，本质上都在改变模型行为边界。
- 微调后要验证新任务能力是否增强。
- 也要验证旧任务能力是否回归。
- 知识编辑后要验证目标知识是否真的被改掉。
- 还要验证无关知识是否被误伤。
第4章：Prompt / RAG / MCP / Agent
这一层是大模型产品最常见的应用技术层，也是测试最有价值的主战场。
4.1 Prompt 和思维链
Prompt 不只是“提问方式”，而是系统行为的一部分。思维链（Chain-of-Thought）和推理引导属于这层的典型技术点。测试上要关注：
- Prompt 变更是否引发回归。
- 推理引导是否真的提升了复杂题正确率。
- 在复杂约束下模型是否还能稳定遵循格式和安全边界。
4.2 RAG
RAG 已经是企业大模型应用里最常见的技术栈之一。测试必须分层看：
- 检索有没有命中。
- 召回片段够不够。
- 回答有没有超出知识库乱编。
- 引用、溯源、冲突处理是否清晰。
4.3 MCP
根据 MCP 官方规范，MCP 已经不只是一个“工具调用小协议”，而是围绕 Tools、Resources、Prompts 等能力组织的一套标准化协议层。Tools 侧重模型控制的外部动作，Resources 侧重上下文资源暴露，Prompts 侧重服务器暴露提示模板。对测试来说，这意味着必须从“HTTP 接口测试”进阶到“协议接口测试”。
| MCP 原语 | 测试关注点 |
|---|---|
| Tools | schema、参数校验、执行结果、危险动作、安全边界 |
| Resources | 资源 URI、内容格式、更新通知、权限控制 |
| Prompts | 模板参数、注入风险、分页、权限与展示逻辑 |
4.4 Agent / GUI Agent
Agent 是把大模型从“回答问题”推进到“完成任务”的关键一层。GUI Agent、Computer Use、Browser Agent 这类技术都属于这个方向。测试的核心不只是接口通不通，而是：
- 能不能合理规划步骤。
- 能不能识别风险和权限边界。
- 遇到错误会不会死循环。
- 有没有因为视觉识别误差而误操作。
第5章：多模态、GUI Agent 与世界交互
多模态技术是当前很重要的一条主线。相关教程和资源普遍会把多模态模型、视觉语言模型、GUI Agent 作为单独主题，这本身就说明它们的复杂度已经高到不适合被当作“文本接口附属功能”。
5.1 多模态为什么是测试难点
| 输入模态 | 常见技术点 | 测试风险 |
|---|---|---|
| 图片 | OCR、目标识别、图像理解 | 看错图、视觉幻觉、细节漏读 |
| 音频 | ASR、说话人分离、音频理解 | 转写错误、说话人混淆、口音误识别 |
| 视频 | 抽帧、时间线建模、事件理解 | 漏关键帧、时间顺序理解错 |
| 文档/PDF | OCR、表格解析、版面理解 | 页码漏读、表格错列、扫描件误读 |
5.2 GUI Agent 的特殊风险
GUI Agent 不只是“看屏幕”。它还会点击、滚动、输入、切换页面、关闭弹窗。所以它的测试风险是复合型的：
- 视觉识别错误。
- 定位点击错误。
- 多步操作顺序错误。
- 危险动作没有二次确认。
第6章：安全、对齐与红队
现在的大模型测试，安全已经不是“补充项”，而是主项。
6.1 为什么安全要单独成体系
因为大模型一旦进入真实业务，就可能接触到用户数据、工具能力、内部知识库、GUI 操作权限。这意味着安全问题不再只是“说了句不该说的话”，而是可能演变成：
- 系统 Prompt 泄露。
- 知识库越权读取。
- 危险工具误调用。
- 通过提示注入绕过规则。
- Agent 执行危险动作。
6.2 对齐、越狱、隐写、水印为什么值得知道
像 RLHF 安全对齐、越狱攻击、大模型隐写、模型水印，这些在很多技术教程里会被单独拿出来讲。测试团队至少要知道：
- 对齐是为了约束模型行为边界。
- 越狱是在试图绕过这些边界。
- 隐写和水印会影响内容安全、版权、可追踪性和审计。
测试团队的现实建议
不要求每个测试都深入研究 RLHF 算法细节，但至少要理解：安全边界来自哪里、可能被谁绕过、绕过之后会发生什么。
第7章：微调、知识编辑与部署推理
很多测试团队天然更关注产品侧功能，但随着大模型工程越来越成熟，模型切换、量化、推理框架、部署回退也会直接影响测试质量结论。
7.1 推理优化为什么会影响测试
| 技术 | 目标 | 测试风险 |
|---|---|---|
| 量化 | 更快、更省显存 | 复杂推理、数学、代码能力退化 |
| 推理框架切换 | 吞吐和稳定性优化 | 流式输出、token 节奏、边缘格式变化 |
| 模型替换 | 能力升级或成本下降 | Prompt 行为、风格、稳定性整体变化 |
7.2 测试团队要关注哪些部署信号
- 模型版本号是否真的切换。
- 量化后是否对重点场景做了对比评测。
- 推理框架更换后，是否复跑了流式、结构化输出、复杂推理专项。
- 有没有保留稳定基线和回退策略。
第8章：评测、基线与质量工程
大模型测试最终要走向工程化。否则所有技术主题最后都会变成“知道很多，但没有稳定质量体系”。
8.1 当前最重要的三个工程化动作
- 建立分层测试集：Golden Set、扩展集、对抗集、多模态素材集。
- 建立评测基线：模型切换、Prompt 修改、知识库更新都可对比。
- 建立趋势追踪：不是看一次结果，而是看几周、几个月的变化。
8.2 测试团队的技术观察哨
| 技术变化 | 测试团队该做什么 |
|---|---|
| 上新推理模型 | 补复杂推理和一致性专项 |
| 新增 MCP Server | 补协议和工具权限专项 |
| 新增多模态能力 | 补素材集、OCR/ASR/视觉幻觉专项 |
| 引入 GUI Agent | 补风险动作和误操作专项 |
| 模型对齐策略调整 | 补红队集和安全回归 |
第9章：测试团队应该怎么学
对测试团队来说，最有效的学习方式不是追所有论文，而是建立“技术地图 + 测试视角”的对应关系。
建议学习顺序
- 先掌握接口测试主线。 2. 再掌握 AI 专项里的 Chat、Structured Output、RAG、MCP、多模态。 3. 再读这篇技术概览，理解这些能力背后的技术分类。 4. 最后用 Markmap 技术地图去做复盘和授课。
补充练习与参考答案
补充练习
- 用你自己的话解释为什么大模型测试不能只沿用传统软件测试思路。
- 从技术地图里任选 3 个方向，说出它们分别对应的测试重点。
- 如果团队资源有限，你会优先补哪些方向，为什么？
参考答案要点
- 大模型测试涉及概率输出、自然语言理解、知识时效性和安全边界，天然比传统确定性系统更依赖评分和统计。
- 例如 RAG 对应检索与拒答测试，MCP/Tool 对应协议与参数测试，多模态对应 OCR/视觉幻觉与素材集测试。
- 优先级通常应先补主业务链路最相关的方向，而不是把所有前沿专题同时铺开。