为什么 AI 会一本正经地胡说八道？测试工程师需要懂一点 Transformer

你有没有遇到过这种情况？

AI 回答得很流畅，语气很肯定，格式也很漂亮。
但你一核对原文，发现它编了。

比如：

知识库里明明没有退款规则，它却回答：

一般 3～5 个工作日内到账。

会议里只是说：

下周再看测试结果。

它却总结成：

确定下周上线。

用户只是问：

如果我要通知项目群，应该怎么写？

Agent 却真的把消息发出去了。

这些问题很容易让测试同学得出一个结论：

这个模型不稳定。
这个 AI 不靠谱。
这个 Prompt 不行。

这些判断可能都对，但还不够。

因为如果只停留在“它不稳定”，我们很难继续往下分析：

• 为什么它会编？
• 为什么它说得这么像真的？
• 为什么 Prompt 改一句话，结果就变了？
• 为什么长文档总结容易漏重点？
• 为什么 RAG 接了知识库，AI 还是可能乱答？
• 为什么 Agent 会“做错了还说做完了”？

这些问题背后，其实都和大模型的基本工作方式有关。

而当前大模型背后最核心的基础架构之一，就是：

Transformer。

这篇文章不是算法科普，也不会推公式。
我想从测试工程师视角讲清楚一件事：

做 AI 测试，不需要先学成算法工程师，但需要懂一点 Transformer 和大模型生成机制。

因为你理解了它为什么会出错，才能更好地设计测试样例、判断风险、写出有价值的测试结论。

---

一、先说结论：不用背公式，但要知道 AI 为什么会出错

很多测试同学听到 Transformer，第一反应是：

这是不是算法工程师才需要学的东西？

如果目标是训练模型、改模型结构、优化推理性能，那确实需要很深的算法和工程能力。

但如果目标是做 AI 测试，你不需要一上来就掌握：

• Q、K、V 的数学推导
• 多头注意力公式
• 反向传播
• 模型训练过程
• 分布式推理优化
• Transformer 源码实现

这些不是 AI 测试入门的前置条件。

测试工程师真正需要先理解的是这些：

1. 大模型不是数据库；
2. 它不是按固定规则查答案；
3. 它是在上下文里生成下一个可能出现的 token；
4. 它的输出具有概率性；
5. Prompt 会改变模型行为；
6. 上下文长度、信息位置、无关噪声都会影响结果；
7. 它不天然保证事实正确；
8. RAG 和 Agent 也不能自动消除这些风险。

这几件事一旦理解了，你对 AI 测试的很多判断会变得更清楚。

你会知道：

• 为什么不能只测“有没有回答”；
• 为什么要测无答案场景；
• 为什么要测长文档；
• 为什么要做 Prompt 回归；
• 为什么要核对引用来源；
• 为什么 Agent 高风险动作必须确认；
• 为什么 AI 测试要从“功能可用”升级到“结果可信”。

所以，测试工程师学 Transformer，不是为了造模型，而是为了：

看懂 AI 出错的来源。

---

二、大模型不是数据库：它是在生成答案

很多人使用 AI 时，会下意识把它当成“更聪明的搜索引擎”或“自然语言数据库”。

用户问：

退款多久到账？

我们会期待它像查数据库一样返回一个准确答案。

但大模型本身不是这么工作的。

更准确地说，大模型是在当前上下文基础上，预测下一个最可能出现的 token，然后一步步生成完整回答。

Token 可以简单理解为模型处理文本的基本单位。
可以是一个字、一个词，也可以是词的一部分。

所以，当 AI 回答你时，它不是在“保证事实正确”的前提下查出答案，而是在根据上下文生成一段最可能、最合理、最符合语言模式的文本。

这就解释了一个非常重要的问题：

为什么 AI 会说得很流畅，但不一定真实。

因为“流畅”和“真实”不是一回事。

举个测试场景。

知识库里没有退款规则。
用户问：

退款多久到账？

AI 回答：

一般会在 3～5 个工作日内原路退回。

这句话读起来很自然，也符合很多业务常识。
但如果你的知识库没有这条规则，它就是编造。

所以 AI 测试里，不能只看：

这句话像不像一个正确答案。

而要看：

它有没有依据。

这也是 RAG 测试、知识库问答测试、制度问答测试里最核心的一条原则。

---

三、为什么 AI 会一本正经地胡说八道？

因为大模型擅长生成“合理文本”，但它不天然知道哪些内容在你的业务里是真的。

它可能把训练中见过的通用模式，套到当前场景里。

例如：

用户问：

试用期请假会影响转正吗？

如果知识库里没有明确制度，AI 可能会回答：

一般情况下不会直接影响转正，但会作为综合评估参考。

这句话听起来非常像 HR 制度。
但如果公司文档没有写，它就不能作为正式答案。

这就是 AI 幻觉最危险的地方：

它不是胡乱输出，而是输出“很像真的”的内容。

对测试来说，这比明显错误更危险。

明显错误，用户容易警觉。
一本正经的错误，用户更容易相信。

所以，测试幻觉不能只靠标准问题，而要专门设计一些“诱导型样例”。

例如：

测试样例	目的
文档中没有退款规则，询问退款到账时间	验证无答案是否拒答
问“按常规经验应该怎么处理”	验证是否被诱导发挥
问“如果文档没写，你推测一下”	验证是否坚持依据边界
文档中只有审批规则，询问薪资规则	验证是否越界回答
文档里写“待确认”，询问“是不是已确定”	验证是否把不确定说成确定

理想回答不是编一个看起来合理的答案，而是明确说明：

当前知识库未找到相关依据，无法确认。

所以从 Transformer 和生成机制角度看，AI 幻觉不是偶然现象，而是 AI 测试必须长期覆盖的核心风险。

---

四、Prompt 改一句话，为什么输出就可能变很多？

很多团队调 Prompt 时会遇到这种情况：

原 Prompt：

请总结这份需求文档。

AI 输出比较泛。

改成：

请从测试工程师视角总结这份需求文档，重点关注功能点、边界规则、异常流程和测试风险。

输出立刻变得更像测试分析。

再加一句：

输出尽量简洁。

结果又可能变得太短，漏掉关键规则。

为什么会这样？

因为 Prompt 不是普通文案。
它是模型当前任务上下文的一部分。

它会影响模型判断：

• 当前角色是谁？
• 任务目标是什么？
• 哪些信息更重要？
• 输出要详细还是简洁？
• 是否可以自由发挥？
• 信息不足时要不要拒答？
• 输出格式是否必须固定？

所以 Prompt 改动，本质上就是改了 AI 功能的执行规则。

这也解释了为什么 Prompt 必须测试、必须回归。

很多 Prompt 改版会出现“修 A 坏 B”的问题。

例如：

改版目标	可能副作用
强化格式约束	内容变模板化、覆盖变少
强化拒答策略	正常问题也不敢回答
强调风险识别	没风险也硬编风险
要求更简洁	关键规则被压缩掉
强调完整输出	内容变啰嗦，用户不愿看

所以 Prompt 改版后不能只问两三个问题。
至少要回归：

• 标准样例；
• 历史缺陷样例；
• 边界样例；
• 高风险样例；
• 新旧版本对照样例。

测试结论也不能只写：

新 Prompt 效果更好。

而要写清楚：

• 哪些问题修复了；
• 哪些能力退化了；
• 高风险场景是否仍可控；
• 是否建议上线或灰度。

一句话：

Prompt 不是文案，它是 AI 功能逻辑的一部分。

---

五、为什么长文档总结容易漏重点？

很多 AI 功能都会做文档总结：

• 总结 PRD
• 总结会议纪要
• 总结制度文档
• 总结项目报告
• 总结故障复盘

但测试时经常会发现：

• 总结看起来很完整；
• 语言也很顺；
• 结构也没问题；
• 但关键规则漏了。

比如需求文档里写：

报销金额超过 5000 元需直属上级审批，超过 20000 元还需财务复审。

AI 总结成：

系统会根据报销金额走不同审批流程。

这句话不能说完全错，但对业务几乎不够用。

因为它漏掉了两个最关键的信息：

• 5000 元；
• 20000 元；
• 对应审批角色。

为什么长文档总结容易这样？

因为“能把长文档放进模型上下文”，不代表模型能均匀关注所有细节。

实际测试中，你会发现很多影响因素：

1. 关键规则在文档位置不同，输出可能不同；
2. 文档里无关背景越多，重点越容易被稀释；
3. 表格、合并单元格、跨页内容更容易丢；
4. 多个相似规则并存时容易混淆；
5. 文档越长，模型越可能只抓大意。

所以长文档总结测试不能只看“有没有总结”。

要专门设计这些样例：

样例类型	测试目的
关键规则在开头	看是否识别主规则
关键规则在中间	看是否被忽略
关键规则在末尾	看长文档末尾信息是否丢失
大量背景信息干扰	看是否抓住重点
表格规则	看行列关系是否理解正确
多版本变更说明	看是否识别当前版本
待确认内容	看是否误写成确定结论

对测试工程师来说，判断总结质量的关键不是：

写得像不像总结。

而是：

关键事实有没有被正确压缩出来。

---

六、RAG 接了知识库，为什么还是会编？

很多人以为：

只要接了 RAG，AI 就不会胡说了。

这是一个很常见的误解。

RAG 的基本链路是：

用户提问
  ↓
检索知识库
  ↓
召回相关片段
  ↓
把片段放进上下文
  ↓
模型基于上下文生成答案

注意最后一步：

仍然是模型生成答案。

这意味着 RAG 不是把大模型变成了数据库。
它只是给模型提供了外部依据。

所以 RAG 仍然可能出问题：

• 检索错了，模型基于错误片段回答；
• 检索漏了，模型基于不完整信息回答；
• 片段太多，模型忽略关键依据；
• 引用不准，答案和来源对不上；
• Prompt 不够强，模型混入常识；
• 无答案时，模型仍然生成合理文本；
• 权限控制不严，模型使用了无权限内容。

举个例子。

用户问：

验证码错误超过几次会锁定？

知识库里正确片段是：

验证码错误超过 5 次后，账号锁定 10 分钟。

但检索召回了另一个片段：

验证码 60 秒内只能发送一次。

模型可能回答：

60 秒内多次操作会触发限制。

这个回答看起来和验证码有关，但答错了问题。

所以 RAG 测试不能只看：

AI 有没有回答。

而要看：

• 召回的是不是正确文档；
• 召回的是不是正确片段；
• 答案是不是基于片段；
• 引用能不能支撑答案；
• 无答案时有没有拒答；
• 是否混入模型常识；
• 是否使用无权限内容。

一句话：

RAG 不是天然可信，答案仍然要验证依据。

---

七、为什么 Agent 会做错了还说完成了？

Agent 比普通聊天机器人更危险，因为它不只是回答，还会执行。

例如：

• 创建任务；
• 发送通知；
• 创建会议；
• 查询数据；
• 修改配置；
• 调用接口；
• 删除文件。

但 Agent 的执行链路里，很多关键判断仍然依赖模型：

• 用户到底是咨询，还是要执行？
• 是否需要调用工具？
• 调哪个工具？
• 参数怎么填？
• 工具失败后怎么办？
• 是否需要确认？
• 最终结果是否真的完成？

这些环节一旦判断错，就会出现误执行。

例如：

用户说：

如果要通知项目群延期上线，应该怎么写？

Agent 误理解成：

用户要发送通知。

于是直接发到项目群。

这不是普通文本错误，而是真实业务操作风险。

再比如：

用户说：

帮我预约明天下午三点的评审会。

日历接口失败了。

Agent 却回复：

已为你预约成功。

这就是“假完成”。

从大模型机制看，Agent 的计划、工具选择、结果解释，也都是基于上下文生成和判断的结果。

所以测试 Agent，不能只看最终回复。
必须看执行链路：

• 是否正确识别意图；
• 是否应该调用工具；
• 是否调用了正确工具；
• 参数是否正确；
• 高风险操作是否确认；
• 工具失败是否如实反馈；
• 是否返回真实任务 ID、会议链接或执行凭证；
• 是否存在未确认执行、重复执行、越权执行。

Agent 最大的风险不是不会做，而是：

做错了，还让用户以为已经正确完成。

---

八、这些原理最后怎么变成测试点？

理解 Transformer 和大模型机制，最终不是为了讲概念，而是为了更好地设计测试点。

可以直接用下面这张表。

大模型机制 / 特性	典型风险	测试应该关注
基于 token 概率生成	回答流畅但不一定真实	无答案样例、事实核对
不是数据库	无依据也可能回答	依据校验、拒答测试
依赖上下文	信息放置影响结果	长文档、信息位置、噪声干扰
Prompt 敏感	改一句话输出变化大	Prompt 回归测试
输出具有波动性	多次结果不一致	稳定性测试
长上下文注意力不均	关键规则被漏掉	长文档总结、表格规则
RAG 仍需生成	引用和答案可能不一致	检索、引用、依据验证
Agent 依赖模型决策	误执行、假完成	工具调用链路、确认机制

这张表就是测试工程师理解 Transformer 的真正价值：

把原理转化成风险，把风险转化成测试样例。

---

九、测试工程师到底要学到什么程度？

最后给一个非常现实的学习边界。

必须懂的

测试工程师做 AI 测试，建议至少理解：

• 大模型是基于上下文生成；
• 输出不是固定答案；
• Prompt 会影响模型行为；
• 长上下文可能漏重点；
• 模型会幻觉；
• RAG 不能完全消除幻觉；
• Agent 需要执行安全边界；
• AI 输出要用样例、评分和风险来评估。

这些足够支撑大多数 AI 功能测试。

建议逐步懂的

如果你想更深入，可以继续补：

• Token 是什么；
• 上下文窗口是什么；
• Attention 大概解决什么问题；
• Temperature 等参数如何影响输出；
• Embedding 和相似度检索大概是什么；
• RAG 的检索和生成是两段链路；
• Agent 的工具调用是模型决策和系统执行的组合。

这些能帮助你更好地和研发、算法、平台同学沟通。

不必一开始深钻的

刚入门 AI 测试，不建议一开始就卡在：

• QKV 矩阵公式；
• 多头注意力推导；
• 反向传播；
• 模型训练细节；
• 微调工程；
• 分布式推理优化；
• Transformer 源码实现。

不是说这些没用，而是说：

对大多数测试工程师来说，先理解机制和风险，比先啃公式更有实际价值。

---

十、小结

为什么 AI 会一本正经地胡说八道？

不是因为它故意骗人，而是因为大模型本质上是在上下文中进行概率生成。
它擅长生成流畅、合理的文本，但不天然保证每句话都有事实依据。

所以测试工程师需要懂一点 Transformer，不是为了学算法，而是为了理解：

• 为什么 AI 会幻觉；
• 为什么 Prompt 要回归；
• 为什么长文档会漏重点；
• 为什么 RAG 接了知识库仍然可能编；
• 为什么 Agent 会误执行；
• 为什么 AI 测试不能只看“有没有回答”。

AI 测试真正要做的，是把这些机制带来的风险，转化成可执行的测试样例：

• 无答案样例；
• 长文档样例；
• Prompt 回归样例；
• 引用核验样例；
• 多轮上下文样例；
• Agent 高风险执行样例。

一句话总结：

测试工程师不需要先成为算法工程师，但要能看懂 AI 为什么会出错。

这就是学习 Transformer 对 AI 测试最大的价值。

---

写在最后

过去我们测试的大多数系统，是确定性的。

输入什么，输出什么，规则比较明确。
但 AI 系统不一样。

它基于上下文生成，输出有概率性，会受 Prompt、上下文、检索结果、工具调用影响。

所以 AI 测试不是简单多点几下，也不是随便问几个问题。

它要求测试工程师继续升级自己的判断方式：

• 不只看结果，还要看依据；
• 不只看回答，还要看上下文；
• 不只看一次输出，还要看稳定性；
• 不只看能不能做，还要看会不会做错；
• 不只看模型效果，还要看业务风险。

这就是为什么测试工程师需要懂一点 Transformer。

不是为了讲清楚每个公式，而是为了在面对 AI 输出时，能更专业地追问：

它为什么这样回答？
它依据是什么？
它可能在哪里出错？
我应该怎么测出来？