第 6 章：LLM 能力边界与失效模式
第 6 章：LLM 能力边界与失效模式
6.1 评测人不需要成为模型训练专家，但必须理解模型会怎样失败
客服 Agent 检索到了正确退款政策。上下文中清楚写着：部分退款会重新计算优惠券分摊，会员积分可能按实际保留金额调整。
但 Agent 最终回答是：
你的积分不会扣回，优惠券也会原路退回。
这不是检索失败。正确知识已经进入上下文。问题发生在生成阶段：模型没有忠实使用证据，还自行补充了不存在的退款条件。
评测人不必深入训练算法细节，但必须理解 LLM 的行为边界。否则所有错误都会被粗略归为“模型不行”，评测设计也会失焦。
本章关注六类与评测直接相关的 LLM 失效模式：
- 概率生成带来的不稳定。
- 幻觉与事实一致性问题。
- 指令遵循与格式遵循失败。
- 长上下文中的信息遗忘和引用错位。
- 安全对齐带来的拒答与能力副作用。
- 模型版本和系统策略漂移。
理解这些失效模式的目的，不是给每个错误贴一个术语标签，而是改变评测设计方式。概率不稳定意味着关键样本不能只跑一次；幻觉意味着 Case 要包含证据边界；指令遵循失败意味着 Rubric 要写清约束优先级；长上下文失效意味着评测要检查关键事实是否被保留；安全副作用意味着不能只看拒答率；版本漂移意味着 Run 必须记录血缘。
换句话说，失效模式是从“模型行为”通往“评测方案”的桥。评测人越能具体描述模型怎样失败，就越能设计出能发现这些失败的样本、指标和 Evaluator。
6.2 概率生成与重复评测
LLM 不是传统函数。即使输入相同，输出也可能因采样参数、服务端策略、上下文细节和模型版本而变化。
评测中最直接的影响是：单次运行不能完全代表稳定能力。
| 参数或因素 | 对评测的影响 |
|---|---|
| Temperature | 越高，表达和决策波动越大 |
| Top-p | 控制候选 token 范围，影响多样性 |
| System Prompt | 改变模型角色、边界和优先级 |
| 上下文顺序 | 影响模型关注点和引用 |
| 输出长度限制 | 可能截断关键解释或工具结果 |
| 服务端策略 | 安全拦截和模型路由可能变化 |
客服 Agent 的关键样本不能只运行一次。对于高风险场景，应记录多次运行结果，观察是否稳定通过。
例如，退款金额问题在五次运行中有三次正确、两次错误，这不应被记录为“通过”。它说明系统在该场景下不稳定，尤其不适合作为自动退款建议。
6.2.1 重复运行结果如何进入决策
重复评测不是简单把多次结果平均。对于不同风险等级，稳定性的解释方式不同。
| 场景类型 | 建议运行方式 | 通过标准 |
|---|---|---|
| 低风险表达优化 | 单次或少量重复 | 平均质量提升即可进入灰度观察 |
| 核心能力回归 | 多次运行关键样本 | 不允许核心能力出现明显波动 |
| 高风险业务场景 | 多次运行 + 人工复核失败样本 | 任何一次高危误放都应触发阻断或复核 |
| 安全红队样本 | 多变体、多轮、多次运行 | 关注最差表现，而不是平均表现 |
| 结构化输出 | 多次运行 + 解析校验 | Schema 失败率必须低于门禁阈值 |
对于客服 Agent，高风险权益、退款金额、隐私查询和账号操作不能用平均分掩盖波动。一个版本在 20 次运行中有 19 次安全、1 次泄露他人订单信息，也不能被描述为“95% 通过”。对高危场景，最差表现往往比平均表现更有决策价值。
6.3 幻觉不是一个单一问题
幻觉通常被笼统理解为“模型编造”。在评测中，需要进一步拆分。
| 类型 | 说明 | 客服示例 |
|---|---|---|
| 无依据补全 | 上下文没有信息，模型给出具体结论 | 编造“7 天内无理由必退” |
| 证据冲突 | 上下文有正确证据，模型选择错误说法 | 忽略积分扣回规则 |
| 过度概括 | 把局部规则扩展到全部场景 | 把会员政策套到普通用户 |
| 引用错位 | 引用片段存在，但不支持答案 | 引用物流政策解释退款金额 |
| 时间错配 | 使用过期规则回答当前问题 | 沿用已下线活动规则 |
不同幻觉类型对应不同评测设计。
- 无依据补全要评证据边界和拒答。
- 证据冲突要评忠实性。
- 过度概括要评场景条件。
- 引用错位要评引用准确率。
- 时间错配要评知识版本。
如果不拆分，团队很容易用同一种修复手段处理所有问题。
在出版级评测体系里，“幻觉”这个词应尽量少单独作为归因结论。它可以作为错误现象入口，但不能作为最终修复指令。无依据补全可能需要拒答策略和证据门禁；证据冲突可能需要忠实度约束；时间错配可能需要知识版本治理；引用错位可能需要引用评测和 RAG 证据结构。只有拆到可行动层，归因才有工程价值。
6.4 指令遵循与约束冲突
LLM 可能看懂任务，却没有遵循全部约束。
客服 Agent 的系统提示可能要求：
- 回答必须基于知识库或工具结果。
- 涉及金额和权益时必须转人工或调用工具。
- 不得做无依据承诺。
- 输出必须包含“依据”和“下一步操作”。
一个回答可能政策正确，却缺少依据；也可能格式正确，却违反转人工规则。
指令遵循评测要关注三类问题：
| 类型 | 判断问题 |
|---|---|
| 任务指令 | 是否完成用户任务 |
| 安全约束 | 是否遵守隐私、权限和风险边界 |
| 输出约束 | 是否满足格式、字段和结构要求 |
对于企业场景，安全约束优先级应高于任务完成。一个自动完成退款但绕过身份校验的回答，不能因为“任务完成”而得高分。
6.5 格式遵循与结构化输出
很多 AI 应用需要结构化输出，例如 JSON、工具参数、分类标签和报告字段。
格式错误可能直接导致系统失败：
- JSON 少了括号，后续解析失败。
- 字段名不符合 Schema，工具无法调用。
- 金额字段类型错误，业务系统拒绝。
- 分类标签超出枚举范围，统计失真。
格式遵循评测应优先用规则和脚本，不应全部交给语义 Judge。
| 检查对象 | 推荐评估方式 |
|---|---|
| JSON 合法性 | 解析器 |
| Schema 遵循 | JSON Schema / Pydantic 等校验 |
| 枚举值 | 规则校验 |
| 字段完整性 | 脚本检查 |
| 字段语义正确性 | 脚本 + Judge + 人工抽检 |
格式正确不代表语义正确。退款工具参数通过 Schema 校验，但订单 ID 和商品 ID 对错，还需要业务语义检查。
6.6 长上下文失效
长上下文并不等于模型能稳定使用所有信息。
常见问题包括：
| 问题 | 说明 |
|---|---|
| 中间遗忘 | 上下文中段的重要信息被忽略 |
| 信息淹没 | 关键证据被大量无关内容稀释 |
| 引用错位 | 引用了存在的片段，但片段不支持结论 |
| 条件丢失 | 忽略“仅适用于会员”“活动期内”等限制 |
| 多轮污染 | 将前一轮或其他订单的信息带入当前回答 |
客服 Agent 经常在长对话中遇到这类问题。用户一开始说明“只退耳机，不退充电器”，后续又问“那优惠券怎么算”。如果 Agent 忘记部分退款条件，就会给出整单退款回答。
长上下文评测不能只测最终答案，还要测：
- 关键事实是否被保留。
- 条件约束是否被正确使用。
- 引用是否指向支持答案的片段。
- 多轮状态是否被污染。
6.7 安全对齐的副作用
安全对齐让模型更谨慎，但也可能带来副作用。
| 副作用 | 表现 |
|---|---|
| 过度拒答 | 本可回答的普通政策问题被拒绝 |
| 能力回退 | 安全策略触发后，模型不再完成正常任务 |
| 模糊兜底 | 用泛泛安全话术替代具体业务回答 |
| 误判敏感 | 把普通订单咨询当成隐私请求 |
| 风险转移 | 拒答后不给用户可执行下一步 |
客服 Agent 面对“帮我查一下订单”时，正确行为不是直接拒答，也不是直接查询，而是先完成身份核验，再调用工具。如果安全策略只会拒答，就会损害体验；如果完全不拦截，就会产生隐私风险。
安全评测要同时看误放和误拒。
| 指标 | 含义 |
|---|---|
| Unsafe Pass Rate | 高危请求被错误放行 |
| Over-refusal Rate | 合法请求被错误拒绝 |
| Safe Completion Rate | 合法任务在安全边界内完成 |
| Escalation Correctness | 是否正确转人工或要求补充验证 |
安全不是单纯拒绝更多，而是在风险边界内完成任务。
6.8 模型版本漂移
企业应用常调用外部模型 API。底层模型、服务策略、安全策略或路由变化，都可能影响输出。
漂移不只来自模型本身，还可能来自：
- System Prompt 调整。
- 模型供应商策略变化。
- 推理参数变化。
- 上下文模板变化。
- 安全拦截变化。
- 评估器 Judge 版本变化。
因此，评测 Run 必须记录模型与执行配置。没有版本血缘，就无法解释分数变化。
客服 Agent 某天突然拒答率上升，可能不是业务 Prompt 改错，而是底层安全策略变化。若没有记录模型版本和系统消息，团队只能猜测。
6.9 区分模型问题与系统问题
评测人最重要的判断之一，是不要把所有问题归因到模型。
| 现象 | 可能根因 |
|---|---|
| 答案事实错误 | RAG 召回失败、知识过期、模型幻觉 |
| 没有调用工具 | Prompt 约束缺失、Agent 策略错误、模型工具选择失败 |
| 输出格式错误 | Schema 设计、格式指令、模型结构化能力 |
| 多轮状态错误 | 记忆管理、上下文拼接、模型注意力 |
| 拒答异常 | 安全策略、风险分类、模型对齐 |
只有在证据表明正确上下文、工具结果和业务规则都已提供，模型仍稳定给出错误回答时，才更适合归因到模型能力或生成策略。
6.9.1 用受控实验区分模型问题和系统问题
复杂系统的归因不能只看一次失败。更可靠的方法是构造受控对照，让一次只改变一个变量。
以“优惠券部分退款回答错误”为例，可以按下面顺序排查：
| 对照实验 | 固定条件 | 改变条件 | 结论指向 |
|---|---|---|---|
| 直接给正确政策片段 | 模型、Prompt、用户问题 | 去掉 RAG，只提供 gold evidence | 若仍答错，指向生成忠实性或 Prompt |
| 固定模型和 Prompt | 用户问题、知识版本 | 更换召回结果 | 若答案随证据变化，指向 RAG 链路 |
| 固定上下文 | 模型、用户问题、证据 | 调整 Prompt 约束 | 若错误消失，指向指令或格式约束 |
| 固定 Prompt 和证据 | 用户问题、评估器 | 更换模型 | 若仅某模型失败，指向模型能力差异 |
| 固定离线环境 | Case、模型、Prompt | 接入真实工具结果 | 若错误出现，指向工具或状态链路 |
受控实验的目标不是做学术证明，而是减少错误修复。很多“模型幻觉”在对照后会发现是证据没有进入上下文；很多“RAG 失败”在对照后会发现是模型忽略了正确证据。
评测平台应尽量支持这些对照：能单独运行模型层 Case、RAG Case、工具 Case、Trace Case 和端到端 Case。否则团队只能在黑盒结果上争论。
6.9.2 从失效模式到评测资产
失效模式最终要沉淀为评测资产。每一种常见失败，都应该至少对应一种 Case、一类指标和一个归因标签。
以客服 Agent 为例：
- 概率不稳定应沉淀为重复运行 Case 和稳定性指标。
- 无依据幻觉应沉淀为证据不足 Case、拒答 Case 和忠实度 Rubric。
- 结构化输出失败应沉淀为 Schema Case 和解析器校验。
- 长上下文失效应沉淀为多轮状态 Case 和关键事实保留指标。
- 过度拒答应沉淀为合法请求成对样本和误拒指标。
- 模型版本漂移应沉淀为固定回归样本和版本血缘报告。
这样做的好处是，失效模式不会停留在抽象知识层，而会进入数据集、Evaluator、门禁和归因标签。后续第 11 章的数据资产、第 12 章的 Case Schema、第 13 章的 Evaluator 和第 21 章的归因模型，都会复用这条映射关系。
6.10 交付物一：LLM 失效模式清单
| 失效模式 | 评测信号 | 推荐评估方式 |
|---|---|---|
| 概率不稳定 | 多次运行结果波动 | 重复运行、稳定性统计 |
| 无依据幻觉 | 无证据给出具体结论 | 忠实性 Rubric、引用检查 |
| 证据冲突 | 有正确上下文仍答错 | 上下文注入对照 |
| 指令不遵循 | 漏掉安全或业务约束 | 规则 + Judge + 人工 |
| 格式失败 | JSON / Schema 不合法 | 解析器和 Schema 校验 |
| 长上下文失效 | 忽略关键事实或条件 | 多轮 Case、引用评测 |
| 过度拒答 | 合法问题被拒绝 | 安全误拒评测 |
| 版本漂移 | 同样 Case 行为变化 | 版本血缘和回归评测 |
这张清单应与 Bad Case 归因标签连接。
6.11 交付物二：LLM 能力边界到评测设计映射表
| 能力边界 | 样本设计 | 指标 |
|---|---|---|
| 概率稳定性 | 同一 Case 多次运行 | 一致通过率、输出方差 |
| 事实忠实性 | 提供证据与干扰证据 | 忠实度、引用准确率 |
| 复杂指令 | 多约束任务 | 指令满足率、约束遗漏率 |
| 结构化输出 | JSON / 表格 / 标签 | Schema 通过率、字段准确率 |
| 长上下文 | 关键事实分布在不同位置 | 事实保留率、引用位置正确率 |
| 安全边界 | 合法与非法请求成对样本 | 误放率、误拒率 |
| 漂移检测 | 固定回归样本 | 版本差异率、关键指标退化 |
评测设计要从能力边界出发，而不是只从模型宣传能力出发。
6.12 本章小结
LLM 失效模式会直接影响评测设计。
评测人需要理解概率生成、幻觉、指令遵循、格式遵循、长上下文、安全对齐和版本漂移这些行为特性。更重要的是，要区分模型问题和系统问题。
当客服 Agent 看到了正确政策却仍生成错误解释时，评测要能判断这是生成忠实性问题，而不是检索失败。只有归因准确，后续指标、数据和优化动作才会有效。
理解了模型本身的失效模式后，下一章我们将进入 RAG 链路，看看知识检索、召回排序和引用忠实性该如何评测。