P6-10.3 按格式、依据、执行不足来拆分 LLM 失败¶

Section ID: P6-10.3 Version: v2026.07.26

读到 P6-10.2，我们已经能分辨 哪种回答看起来更像 assistant，也能分辨 哪种回答更可接受、更安全。但进入真实功能改进阶段后，问题会再变一次。因为我们不能停在知道好回答标准的位置，还必须诊断失败回答里最先缺少的是什么。

当模型的行为和期待不同时，首先是缺少什么才导致失败？

改进生成式 AI 功能时，比起先选择技术名称，更安全的做法是先判断失败原因更接近 格式、依据、执行、还是 持续适应。

先拆分失败原因的诊断地图¶

失败原因诊断从下面的问题开始。

当前失败是回答格式不稳定的问题吗？
当前依据文档或最新信息缺失了吗？
是否需要计算、查询、状态变更这类执行？
是否需要长期匹配重复出现的领域文体或任务反应？

修改提示(prompt revision)、RAG、工具使用(tool use)、微调(fine-tuning)，都是完成这个诊断之后再检查的补强路径。提示调整处理输入指令和输出格式，RAG 把外部文档和出处连接成依据，工具使用把计算、查询、状态变更交给模型外部功能。微调更接近把重复出现的领域模式或文体适应移到模型调整层。

这里要小心的是，四条路径很容易被 提升性能的方法 这个名字混在一起。实际上它们触碰的位置不同。提示修改是在同一个模型上改变输入句子和输出形式。RAG 是在模型回答前先找到可参考文档，并把它贴到输入侧。工具使用让模型不要直接计算或查询，而是调用外部功能后接收结果。微调把反复需要的反应习惯反映到模型调整过程中。所以同样一句 回答错了，实际要修的位置也可能彼此不同。

本节不替代后续章节的细节技术说明。这里要闭合的问题是 先修哪里，修什么。提示本身的设计会在 P6-10 中处理，RAG 和向量搜索会在 P6-11、P6-12 中处理，工具使用和 AI agent 结构会在后续 Module 中继续看。P6-10.4 和 P6-10.5 是当这个诊断指向微调轴时，需要的高效调整补充学习。

为什么在对齐之后马上读诊断地图¶

读完 指令调优 和 对齐 后，可能会觉得模型质量问题已经大致说明完了。但在真实产品里，工作其实才刚开始。只要答案奇怪就笼统地说 模型不行，就很容易反复走偏：把格式问题误认为检索问题，用更长的提示硬撑最新性问题，或者想用微调解决计算问题。

因此，诊断地图是把前面的 回应习惯调整 和 可接受行为标准 翻译成实际改进工作的桥。这里不再停留于重新评价哪种反应更像 assistant、哪种回答更可接受且安全。我们先区分当前失败到底是格式问题、依据问题、执行问题，还是持续适应问题。

换句话说，本节的闭合点不是 知道四个技术名称，而是 看到问题症状时，更不容易把失败原因分错。这里先抓住提示修改、微调、RAG、工具使用分别首先面向哪类失败，以及当前问题更接近格式、依据、执行、持续适应中的哪一个。各补强路径的实际设计与实现、成本比较表、按组织而异的运营流程，会在后面具体展开。

核心不是 用一个方法修所有问题，而是 根据失败原因，把格式、依据、执行、持续适应分开诊断。有了这个标准，后续技术才会被读成 按失败原因选择补强路径，而不是 新技术介绍。

区分格式、依据、执行、适应问题¶

能说明 prompt、fine-tuning、RAG、tool use 的作用差异。
能根据问题类型说明应该先检查哪个轴。
能把 prompt、RAG、工具使用、AI agent 章节放在同一张诊断地图中阅读。
在综合迷你练习中，更容易理解为什么要把多个装置组合起来。

四种不足的最短区分¶

首先缺少的东西	首先怀疑的补强路径
输入指令和输出格式	prompt revision
最新信息、内部文档、依据连接	RAG
计算、查询、执行等外部功能	tool use
重复语气、领域模式、任务反应	fine-tuning

这个表的目的不是详细解释四种技术。它要留下的是，同样一个 LLM 回答错了 的症状，如果缺少的层位不同，首先该看的补强路径也不同。

例如，用户说 请把休假规定总结成三行，但回答让人不满意。用一句话说，都可以叫 回答不好，但实际诊断会像下面这样分开。

观察到的失败	首先要看的不足	为什么是不同问题
不是三行总结，而是长段落	格式	加入更多当前规定，输出格式也可能仍然摇摆
三行格式是对的，但依据是上个月的规定	依据	问题不是句子形状，而是当前文档缺失
必须计算剩余休假天数，但数字错了	执行	即使有规定文档，计算结果也需要单独确认
每次都要求同一品牌语气，语气仍然摇摆	持续适应	稳定重复模式比一次性指令更重要

这样看，错误回答 不是单一原因。必须先区分格式是否破了、依据是否缺失、是否需要执行结果、是否需要重复习惯，之后的补强路径才不容易偏离。

各补强路径不容易单独闭合的问题¶

重要的不是只看 什么适合，还要同时看 用它 alone 不容易闭合什么。

手段	首先适合的问题	只靠它不容易闭合的问题
提示修改	格式摇摆、说明顺序、语气调整	最新信息不足、外部执行、计算准确度保证
微调	重复领域风格、持续任务适应	经常变化的最新文档反映、即时查询型问题
RAG	最新性、内部文档依据、出处连接	计算执行、状态变更、外部系统动作
工具使用	计算、查询、真实执行	语气一致性、长期领域风格适应

也就是说，诊断地图的目的不只是 四选一，而是先分离当前失败属于哪个层位的问题。

格式信号不足时¶

下面的问题应该先检查输入指令和输出格式信号是否不足。

回答格式经常走样
指令顺序没有正确遵循
同样的信息需要更摘要或更结构化的输出

这种情况下，模型不一定缺少知识。当前输入设计可能没有充分显露目标。

持续适应信号反复出现时¶

下面的条件反复出现时，可以检查这是不是一次性输入修改问题，而是持续适应问题。

持续需要某个领域风格
必须大量、稳定地处理同一模式的任务
只靠提示，一致性提升不够

也就是说，微调更接近一种选择：把 每次都设计很长输入 的一部分转移到学习层。

依据信号不足时¶

下面的问题应该先检查当前依据和出处连接是否不足，而不是回答方式。

回答的最新性很重要
需要内部文档依据
只让模型依靠内部记忆回答会有风险

这种情况下，核心问题不是 怎样让它说得更好，而是 它应该依据什么来说。

执行信号不足时¶

下面的问题不能只靠文档依据闭合，需要检查是否需要模型外部的执行或查询。

必须直接计算
必须查询当前状态
必须在外部系统中实际触发动作

例如创建日程、查询剩余休假、读取文件、确认订单状态，都不能只靠文档依据结束。这时要检查负责真实执行或查询的工具使用路径。

如果不能一次分清，就拆分失败记录¶

真实问题往往不会干净地分成上面四类之一。所以比起先贴技术名称，更应该把失败记录拆成更小的观察单位。好的诊断不会直接跳到 需要 RAG 这样的结论，而是按下面顺序询问。

诊断顺序	要问的问题	要确认的记录
1. 要求是什么	用户期待的输出格式、事实标准、执行结果是什么	原始请求、系统指令、期待输出
2. 实际回答在哪里偏离	格式、依据、执行、持续适应中出现了什么信号	模型回答、缺失出处、错误数字、重复失败模式
3. 先修哪里效果最大	最大失败更接近输入设计、文档连接、工具执行，还是调整层	失败频率、风险度、可复现性
4. 还会留下什么问题	一阶补强后是否还有二阶信号	重新执行结果、剩余错误类型

例如，请把最新休假规定总结成三行 这个请求，如果回答是四行，而且规定数字也错了，就同时出现格式和依据信号。只修格式，会得到三行的错误回答。只修依据，可能得到正确规定的长段落。因此要先降低风险更大的依据错误，再稳定输出格式，把一阶和二阶优先级分开。

反过来，如果总额计算错了，却因为句子啰嗦而先改提示，可能只会得到更短、更好看的错误答案。诊断的目的不是先做出漂亮答案，而是找出先减少哪种不足，失败才会真的减少。

把缺失信号移到补强路径的流程¶

flowchart TD
  A["观察到问题"]
  B["拆分缺失信号"]
  C["格式 / 指令匹配"]
  D["依据 / 最新性"]
  E["计算 / 查询 / 执行"]
  F["重复风格 / 任务适应"]
  G["一阶补强路径"]
  H["记录二阶补强候选"]

  A --> B
  B --> C
  B --> D
  B --> E
  B --> F
  C --> G
  D --> G
  E --> G
  F --> G
  G --> H

这个图不是为了机械地自动化所有选择，而是给后续章节一个阅读判断顺序。真实问题中可能同时出现两个信号，所以应该读成先抓住最大的不足，再把第二个信号作为辅助应对留下。

案例和示例¶

案例 1. 回答格式经常走样¶

假设用户要求 始终用三行摘要回答，但有的回答很长，有的回答很短。人们看到回答摇摆时，容易先觉得模型不够聪明。但这里既不是因为没有最新文档而出错，也不是因为没有计算工具而失败。核心问题是 应该用什么格式回答 在摇摆，所以在转向依据不足或执行不足之前，先检查提示结构和示例更自然。

例如内容是对的，但项目符号增加到四行，即使解决最新性或计算问题，仍然不符合使用目的。这里变化的是，从模糊地看 模型聪不聪明，转向看 输出格式要求是否真的稳定。因此这个案例要确认的结果，是在检查依据连接或工具执行之前，修改提示结构后回答格式摇摆是否真的减少。

当前看到的症状	实际上首先缺少的东西	一开始看起来过重的应对
项目符号数量每次不同	格式指令和示例结构	RAG、计算工具连接
标题/摘要顺序经常变化	输出顺序约束	检查微调
内容正确但形式不稳定	提示设计	添加最新文档

案例 2. 经常答错内部规定¶

假设公司休假规定经常变化，但模型按上一季度标准回答。人们看到句子自然时，容易先当成正确答案。但这种情况下，无论怎样修整回答形式，只靠模型内部记忆都很难反映最新规定。核心问题是 没有当前文档依据，所以应该先看最新规定文档是否被检索出来并连接为回答依据，而不是把提示写得更长。

例如把句子写得更礼貌或调整回答长度，也不会修正最新标准数字错误的问题。这里变化的是，从看 回答是否自然，转向看 最新依据文档是否真的连接了。因此这个案例要确认的结果，是只靠提示修改不能修正的最新性错误，在连接最新文档依据后是否真的减少。

当前看到的症状	实际上首先缺少的东西	为什么只靠提示不闭合
数字和规定日期经常错误	最新依据文档	输入写得更长，也不会更新内部记忆
句子自然但标准陈旧	当前版本参照	语气修改不能修正事实错误
询问出处时回答摇摆	文档连接和引用依据	核心是依据缺失，不是说明方式

案例 3. 经常算错数字¶

假设模型经常算错折扣率或总额合计。人们容易觉得写上 慢慢想 这样的长提示就能解决，但这并不能保证计算本身准确。若核心是执行准确度，连接计算工具可能比更长的提示更直接。

例如说明变得更长、更像真的，最后一个数字错了，业务上的失败仍然存在。这里变化的是，从看 说明是否像样，转向看 实际计算结果是否准确。因此这个案例要确认的结果，是比起增加说明长度，用计算工具确认值时最终数字准确度是否真的更稳定。

案例 4. 想长期稳定同一领域文体¶

可以想象法律指引草稿、医疗咨询草稿、品牌公告等需要长期保持同一领域文体的场景。人们容易觉得在提示里放很长的语气规则就足够，但请求一多，表达可能一点点摇摆。这不是一次性修改问题，而是持续风格调整问题，所以可以考虑微调或更结构化的调整层。

例如某一天敬语感很强，另一天说明顺序又变了，即使内容正确，品牌或领域语气也很容易摇摆。这里变化的是，从看 是否写过一次很长的规则，转向看 重复请求中是否仍保持同一文体。因此这个案例要确认的结果，是同一风格问题反复留下时，模型调整层补强是否比输入句子修改带来更一致的文体。

把四个案例再按不足信号诊断视角归纳，如下所示。

症状	首先怀疑的缺失信号	首先确认的补强路径
回答格式摇摆	格式要求反映不足	prompt revision
最新规定错误	依据文档缺失	RAG
计算错误	执行准确度不足	tool use
文体一致性不足	持续风格适应不足	fine-tuning

同样的内容如果按 缺少什么 再读一次，可以这样看。

flowchart TD
  A["观察到失败"]
  J{"首先缺少什么？"}

  A --> J

  J --> B["格式 / 指令匹配"]
  J --> C["当前 grounding"]
  J --> D["计算 / 执行"]
  J --> E["持续风格"]

  B --> F["修改提示"]
  C --> G["连接 RAG"]
  D --> H["使用工具"]
  E --> I["微调"]

核心不是先选择技术名称，而是先分辨当前失败由哪种不足解释。

需要缺失信号诊断的场景¶

读完本节后，即使还不知道各章的具体实现，也可以先练习分辨当前卡住的是 格式问题、最新依据问题、执行问题，还是 持续风格问题。如果回答格式经常摇摆，在想到大规模调整之前，要先看是不是输入结构和格式诱导的问题。规定数字和日期总是来自旧标准时，核心可能不是语气，而是最新文档依据缺失。计算结果或当前状态查询经常错误时，比起文本改进，更需要确认执行和查询信号。同一领域文体在重复请求中无法保持一致时，可能需要的不是最新依据，而是持续风格适应。

这里重要的不是选择 哪种技术看起来更好，而是先把 缺少什么 读成 格式、依据、执行、持续适应。

这里常见的混淆如下。

容易把最新信息不足和格式摇摆看成同一个问题。
容易把执行准确度问题误解成语气或说明长度问题。
容易觉得重复文体问题可以靠最新文档连接解决。

因此，技术名称之前先分类失败原因 这个标准必须成为实际选择习惯。

如果先像下面这样用手简短标记，就能更清楚 Python 示例想计算什么。

失败场景	格式	依据	执行	持续适应	首先阅读方向
摘要格式每次不同	大	小	小	有一点	先看输入指令和输出示例
最新规定编号错误	小	大	有一点	小	先看文档搜索和出处连接
总额计算错误	小	有一点	大	小	先看计算工具或查询结果连接
同一领域文体反复摇摆	有一点	小	小	大	看是否需要重复风格调整

这个表不是答案纸，而是观察练习。同一场景中，公司的风险、用户要求、数据访问权限不同，标记也可能不同。但如果标记改变，后面要看的补强路径优先级也应该改变。

下面三个场景是故意让它们不只显示一个信号。先自己标出 一阶不足 和 二阶不足，再与解说对照。

场景	一阶不足	二阶不足
客服回答把公司政策的最新退款期限答错，回答语气也和品牌语气不同
销售摘要回答的表格格式正确，但合计数字错误，也不清楚以哪个文件为基准计算
合同摘要很好引用了最新条款，但每次摘要顺序都不同，审阅者必须重新整理

解说：

场景	首先要看的不足	接着要看的不足	理由
退款期限错误和品牌语气摇摆	依据	持续适应	最新政策错误是事实失败，所以要先减少；品牌语气是稳定重复回应质量的下一问题
表格正确，但合计和基准文件不清楚	执行	依据	合计是计算执行问题，使用哪个文件则是依据连接问题
最新条款正确，但摘要顺序摇摆	格式	持续适应	当前失败首先是输出结构不稳定，如果在许多合同中反复出现，持续适应就是下一问题

这个练习的核心不是 一个场景只贴一个技术。把失败拆开，区分一阶和二阶优先级后，就更容易理解后面的 Python 示例为什么同时看 first_action 和 second_action。

练习和示例¶

这个示例的目标是确认：即使表面上都像 LLM 做不好，只要分类失败原因，首先要确认的不足和需要暂缓的应对也会改变。我们拿五种代表失败，分别读取每个问题中的 格式、最新依据、执行、持续风格 信号，然后用分数比较应该先看哪条补强路径，以及什么应对应该往后放。

输入：

下面代码使用 5 个代表性失败类型，以及每个失败类型中的格式、最新依据、执行、持续风格信号观察值。结果中会同时看到按问题类型计算的手段得分表、首先确认的补强路径和二阶补强路径、应该推后而不是最先看的应对、失败原因分类摘要。

这里的分数不是真实运营系统自动给出的答案。它是为了让读者把 观察到的失败信号 和 补强路径所瞄准的问题 分开看的诊断练习权重。所以重要的不是数字本身，而是当某个信号变大或变小时，一阶和二阶补强路径如何改变。

要确认的核心是，提示、微调、RAG、工具使用不是先作为技术名称被选择。补强优先级会随着失败原因处在格式、依据、执行、持续适应中的哪一类而改变。

# 通过合计失败信号分数，比较应该优先确认哪条补强路径。
cases = [
    {
        "issue": "format drift",
        "symptom": "回答格式经常摇摆",
        "signals": {
            "format": 3,
            "evidence": 0,
            "execution": 0,
            "persistent_style": 1,
        },
    },
    {
        "issue": "missing latest policy",
        "symptom": "经常答错最新规定",
        "signals": {
            "format": 0,
            "evidence": 3,
            "execution": 0,
            "persistent_style": 1,
        },
    },
    {
        "issue": "needs calculator",
        "symptom": "计算结果经常错误",
        "signals": {
            "format": 0,
            "evidence": 1,
            "execution": 3,
            "persistent_style": 0,
        },
    },
    {
        "issue": "persistent domain style",
        "symptom": "重复请求中文体不一致",
        "signals": {
            "format": 1,
            "evidence": 0,
            "execution": 0,
            "persistent_style": 3,
        },
    },
    {
        "issue": "mixed format and policy evidence",
        "symptom": "摘要格式摇摆，最新规定依据也缺失",
        "signals": {
            "format": 2,
            "evidence": 3,
            "execution": 0,
            "persistent_style": 1,
        },
    },
]

weights = {
    "prompt revision": {
        "format": 3,
        "evidence": 0,
        "execution": 0,
        "persistent_style": 1,
    },
    "RAG": {
        "format": 0,
        "evidence": 3,
        "execution": 0,
        "persistent_style": 0,
    },
    "tool use": {
        "format": 0,
        "evidence": 1,
        "execution": 3,
        "persistent_style": 0,
    },
    "fine-tuning": {
        "format": 1,
        "evidence": 0,
        "execution": 0,
        "persistent_style": 3,
    },
}

def score_action(signals, action_name):
    action_weights = weights[action_name]
    return sum(signals[key] * action_weights[key] for key in signals)

action_counter = {}

for case in cases:
    scores = {
        action_name: score_action(case["signals"], action_name)
        for action_name in weights
    }
    ranked = sorted(scores.items(), key=lambda item: item[1], reverse=True)
    best_action, best_score = ranked[0]
    second_action, second_score = ranked[1]
    last_action, last_score = ranked[-1]
    action_counter[best_action] = action_counter.get(best_action, 0) + 1

    print("=" * 70)
    print("issue =", case["issue"])
    print("symptom =", case["symptom"])
    print("signals =", case["signals"])
    print("scores =", scores)
    print("first_action =", best_action, best_score)
    print("second_action =", second_action, second_score)
    print("not_first =", last_action, last_score)

print("[action summary]", action_counter)

这个示例已用本地 .venv 的 Python 执行，并确认与正文输出一致。

执行结果示例可以这样阅读。

======================================================================
issue = format drift
symptom = 回答格式经常摇摆
signals = {'format': 3, 'evidence': 0, 'execution': 0, 'persistent_style': 1}
scores = {'prompt revision': 10, 'RAG': 0, 'tool use': 0, 'fine-tuning': 6}
first_action = prompt revision 10
second_action = fine-tuning 6
not_first = tool use 0
======================================================================
issue = missing latest policy
symptom = 经常答错最新规定
signals = {'format': 0, 'evidence': 3, 'execution': 0, 'persistent_style': 1}
scores = {'prompt revision': 1, 'RAG': 9, 'tool use': 3, 'fine-tuning': 3}
first_action = RAG 9
second_action = tool use 3
not_first = prompt revision 1
======================================================================
issue = needs calculator
symptom = 计算结果经常错误
signals = {'format': 0, 'evidence': 1, 'execution': 3, 'persistent_style': 0}
scores = {'prompt revision': 0, 'RAG': 3, 'tool use': 10, 'fine-tuning': 0}
first_action = tool use 10
second_action = RAG 3
not_first = fine-tuning 0
======================================================================
issue = persistent domain style
symptom = 重复请求中文体不一致
signals = {'format': 1, 'evidence': 0, 'execution': 0, 'persistent_style': 3}
scores = {'prompt revision': 6, 'RAG': 0, 'tool use': 0, 'fine-tuning': 10}
first_action = fine-tuning 10
second_action = prompt revision 6
not_first = tool use 0
======================================================================
issue = mixed format and policy evidence
symptom = 摘要格式摇摆，最新规定依据也缺失
signals = {'format': 2, 'evidence': 3, 'execution': 0, 'persistent_style': 1}
scores = {'prompt revision': 7, 'RAG': 9, 'tool use': 3, 'fine-tuning': 5}
first_action = RAG 9
second_action = prompt revision 7
not_first = tool use 3
[action summary] {'prompt revision': 1, 'RAG': 2, 'tool use': 1, 'fine-tuning': 1}

所以，这个示例中要确认的结果是：看起来相似的 LLM 问题，只要先分离 缺少什么，优先确认的补强路径和现在马上看也不容易闭合的路径就会实际变得不同。尤其是格式摇摆和文体一致性不足看起来相似，但一个在输入设计侧分数更高，另一个在持续适应侧分数更高。最新规定错误和计算错误也都像是 错误回答，但一个是依据连接不足，另一个是执行不足。复合失败中会同时出现一阶和二阶。最新规定依据缺失更大时，先看 RAG，再用 prompt revision 整理格式摇摆。

读者可以在这个示例中直接尝试下面的调整。

改变 signals 值，确认什么条件下推荐手段会翻转
把 weights 调得更保守，实验组织更重视哪类失败
把 issue 换成客户支持、财务报告、内部批准自动化等新场景
不只看 first_action，也一起读第二名分数，确认为什么有些问题需要复合应对

把分数表画成图后，失败类型为什么会分到不同补强路径会更清楚。颜色最深的格子是首先确认的路径，下一深的格子是一起保留的二阶补强候选。即使失败看起来相似，只要格式、依据、执行、持续文体中的某个信号更大，优先级就会改变。

按缺失信号计算补强路径得分

诊断地图中分开的补强路径¶

这个示例说明，比起背下四条路径再选择，把失败重新读成 格式、依据、执行、持续适应 更重要。真实系统中也不要一看到问题就直接按技术名称分类，而应该先收集它缺少了什么的观察信号。这样才不会把需要更长提示的问题、需要文档依据的问题、需要计算工具的问题、需要长期调整层的问题混在一起。

按失败类型选择补强路径¶

提示、微调、RAG、工具使用不是互相竞争的万能解法，而是根据 因为哪种不足而失败，首先应该拿出来的不同手段。

检查清单¶

能把失败重新拆成 格式、依据、执行、持续适应 吗？
能说明提示、微调、RAG、工具使用不是竞争解法，而是分别瞄准不同不足吗？
准备好把后续章节读成诊断地图中的细节章节，而不是技术列表了吗？

出处和参考资料¶

OpenAI Academy, Prompting fundamentals, 确认日期: 2026-07-19. https://openai.com/academy/prompting/
Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS, 2020, 确认日期: 2026-07-19. https://arxiv.org/abs/2005.11401
Jason Wei et al., Finetuned Language Models Are Zero-Shot Learners, arXiv, 2021, 确认日期: 2026-07-19. https://arxiv.org/abs/2109.01652