第 10 章 能力专题：RAG、Agentic retrieval、记忆、微调与多模态的适用判断
当一个 AI 工作流稳定运行一段时间后，你可能会遇到“单个 Prompt + 检查清单”开始触及天花板的情况：
- 知识量太大，塞不进提示词
- 希望模型输出固定的语气和风格，但每次效果不稳定
- 任务需要处理图片、语音或视频，不只是文字
- 任务需要依据运行时状态逐步检索资料、调用受控工具或在多轮任务中保留已确认的进度
在进入 RAG、Agentic retrieval、记忆、微调和多模态之前，先确认是否已经把任务封装为第 4 章定义的 Skill。Skill 不是另一种模型技术，而是把 Prompt、上下文、知识、工具、验证、回退、责任和版本组织为可运营能力单元。许多所谓的“提示词能力不足”，实际是输入输出、上下文来源、知识维护、验证或责任边界没有被封装清楚；这时应先完善 Skill 和第 5 章的上下文包，而不是直接引入更重的技术架构。
本章不是技术实现手册，而是决策指南：帮你在正确的时机，选择正确的技术路线，避免过度工程化或选型错误。重点不是“哪种技术更先进”，而是“哪种机制能在既定业务、数据、权限和运营边界内提供最小必要上下文”。
一、什么时候不需要这些方案
在讨论 RAG、微调和多模态之前，先确认你是否真的需要它们。以下情况通常不需要复杂技术方案：
- 你的知识量仍可被压缩为少量稳定、可核验的任务规则与参考材料，无需引入运行时检索
- 你的任务只需要固定的格式，而不是固定的“风格”或“专业知识”
- 你处理的全是文字，没有图片/语音/视频
- 你还没有跑通第一个最小闭环（先跑通再考虑进阶）
- 你还没有把 Prompt、知识、验证、回退和责任人封装为可复用的 Skill
常见误判：很多团队在跑通第一个场景之前，就急着上 RAG 或微调，结果把本该用“知识材料 + Prompt + 验证”解决的问题，变成了一个复杂的工程项目，反而降低了稳定性。另一种常见误判是把 Skill 当作“更长的提示词”；真正需要补齐的是输入输出契约、知识责任、验证标准、版本和回退。
二、RAG（检索增强生成）：适用判断与选型要点
RAG 是什么
RAG 的核心思路：不把全部知识塞进提示词，而是在生成回答前，先从外部知识库中检索最相关的片段，再把这些片段连同用户问题一起送给模型。
适合 RAG 的信号：
- 知识量大，无法以稳定、可审核的方式在单次调用中提供（例如全量产品规格或合同条款库）
- 知识需要频繁更新（政策每月变、产品每周上新），用微调成本太高
- 不同任务需要的知识片段不同，预先全量输入会带来噪音
- 需要精确的来源可追溯性（可以告诉用户“这个答案来自第 3 号文档第 5 页”）
不适合 RAG 的信号：
- 知识量少且稳定（几百字的规则直接放提示词更简单）
- 你的问题不是“缺知识”，而是“任务定义不清晰”（RAG 解决不了这个问题）
- 检索质量难以保证（如知识库文档质量参差不齐，检索出来的片段反而带来噪音）
RAG 的关键决策点
如果你判断需要 RAG，以下是三个关键选型决策：
决策 1：知识库的分块策略（Chunking）
文档如何切分、保留元数据、建立父子结构或在运行时展开，都会影响检索质量。错误的切分会让关键条件、例外或上下文被拆散，继而影响回答或后续行动。不存在可跨模型、语种、文档类型和检索方式复用的固定字数；应从能够保留业务语义、权限和来源定位的最小结构起步，再用代表性问题验证。
| 知识类型 | 初始组织方式 | 必测问题 |
|---|---|---|
| 长篇文档（合同、报告） | 按标题、章节和语义段落保留层级；必要时保留相邻或父级内容 | 关键定义、例外和限定条件是否仍与结论同时出现？ |
| 结构化条款（政策、规章） | 按条款编号、生效日期、适用对象和版本组织 | 回答能否定位到正确条款、版本和适用范围？ |
| 产品信息（SKU 详情） | 每个产品或配置项保持完整属性与状态 | 是否混淆相似产品、地区、版本或停售状态？ |
| FAQ | 保留问题、答案、来源、生效范围和升级条件 | 是否把某一问答错误外推到不适用情形？ |
决策 2：检索质量的验证
RAG 的关键失败模式之一在检索与来源治理：若没有检出关键片段、版本或限定条件，后续模型再强也缺少可靠依据。生成、引用、权限过滤、上下文组装和人工验证同样需要单独评测。
验证方法：准备覆盖正常、边界、历史失败、冲突和过期情形的代表性真实问题，对每个问题检查：
- 在当前模型、检索策略和返回量下，返回的来源是否包含回答这个问题所需的关键信息、版本与限定条件？
- 如果包含：检索没问题，生成可能有问题
- 如果不包含：说明检索层有问题（分块策略、索引方式、查询处理需要调整）
决策 3：知识库的维护机制
RAG 系统的长期可靠性，不取决于技术，取决于知识库是否保持更新。在上线前，必须明确：
- 由谁负责维护知识库？（不能是“大家都负责”）
- 知识更新的触发机制是什么？（业务规则变更时，多久之内必须更新知识库？）
- 有没有与知识变更频率、风险和用例健康信号相称的健康检查？（至少在规则变更、来源失效、异常发现或发布前触发复核）
三、Agentic retrieval、工具生成上下文与持久记忆
RAG 通常在生成前检索一次或少量次数；而当任务需要根据中间结果继续定位资料、查询受控系统或在长任务中维持进度时，团队可能考虑 Agentic retrieval、工具生成上下文或持久记忆。这些机制并不是“更高级的 RAG”，而是在运行中增加了状态、权限、成本和恢复要求。
1. 何时考虑 Agentic retrieval 或工具生成上下文
适合的信号包括：任务的下一步确实依赖上一轮发现；需要根据对象、时间、地区或权限逐步缩小检索范围；必须查询实时但受控的系统状态；或固定工作流会产生大量无效检索。开始前应先确认 Agent 具备第9章所述的上下文白名单、工具白名单、状态机、预算、审批和人工接管条件。
不适合的信号包括：任务顺序可以预先定义；查询条件稳定且一次 RAG 即可满足；来源、权限、工具参数或失败处理尚无法说明；或团队不能观察其检索路径和工具行为。此时应保留固定工作流或受控 RAG，而不是让 Agent 自由探索。
| 机制 | 解决的问题 | 最低控制 | 常见误用 |
|---|---|---|---|
| 固定 RAG | 从大规模权威资料中取得与当前问题相关的片段 | 索引、来源、权限过滤、版本、检索评测 | 把检索命中误当作最终结论正确 |
| Agentic retrieval | 根据中间发现逐步检索或缩小范围 | 上下文包、来源路径、状态、步骤/成本限制、停止条件 | 让 Agent 从全库或外网无边界搜索 |
| 工具生成上下文 | 查询实时记录、计算或业务系统状态 | 工具控制卡、最小权限、参数/返回量、超时与审批 | 把工具返回默认当作权威事实，或返回整库内容 |
| 持久记忆/压缩 | 跨轮次保留已确认决定、进度和必要工作笔记 | 记忆合约、来源、事实/假设区分、隔离、失效与删除 | 将全量会话或未经确认推断写成长期记忆 |
公开工程实践建议将上下文视为有限资源：对长任务可采用少量预置规则、按需检索、结构化笔记或压缩摘要等组合，但每次加载仍应有来源、范围与失效控制。1
2. 选择和验证方法
先从最简单可验证的机制开始。若固定 RAG 能取得正确、有效且可定位的片段，就不要为“看起来更智能”而增加 Agent 循环。若必须增加工具或记忆，则分别使用附录A的上下文包、工具/MCP 控制卡、记忆合约和上下文评测记录，测试正常、空结果、冲突、过期、越权、超时、异常返回和人工接管情形。检索、工具或记忆变更都应按第5章的影响分析和回归要求处理。
四、微调（Fine-tuning）：适用判断与注意事项
微调是什么
微调是在预训练模型的基础上，用经筛选的数据调整模型在特定任务上的行为模式、格式、风格或分类/调用倾向。它可以提升特定分布下的表现，但不应被当作可精确、可追溯、自动更新的业务知识库。
适合微调的信号：
- 你需要非常固定的输出风格，而提示词无法稳定实现（例如特定的客服话术风格、特定的文案语气）
- 你有足够覆盖正常、边界和高风险样本的高质量“输入—输出”示例，且已证明其代表真实任务
- 你已用基线测试证明：相较于提示词、结构化输出、检索或工作流改造，微调能以可接受的质量、延迟和全成本带来增益
- 你希望将反复验证过的行为模式固化为可版本化、可回归的候选能力，而不是把未核验规则交给模型猜测
不适合微调的信号：
- 你的主要问题是“知识不够”或需要可追溯的当前事实（微调不应承担实时、精确的知识更新；应比较受控 RAG、长上下文、工具查询或其他可定位的上下文机制）
- 你的数据覆盖、标注一致性、许可或评测证据不足，无法判断候选版本是在改进还是过拟合
- 你的业务规则、事实或产品状态变化频繁，且无法通过数据更新、重新训练、回归和发布流程持续维护
- 你还没有验证清楚输出的质量标准（如果你还不清楚“什么样的输出是好的”，微调会把坏的模式也固化进去）
微调的两个常见误区
误区 1：用微调代替知识库
团队把所有的业务文档和 FAQ 做成训练数据来微调模型，希望模型“记住”这些知识。问题是：微调学的是模式和分布，不是精确的知识记忆。业务规则一旦变更，模型不会自动更新——你需要重新准备数据、重新训练。而用 RAG + 知识库，只需要更新文档。
误区 2：用少量低质量数据微调
50 条由实习生随手写的示例，微调出来的模型会把不好的习惯也固化进去，反而比基础模型表现更差。微调的数据质量要求极高，每一条示例都应该是“你最希望模型输出的样子”。
五、多模态：何时纳入、能力边界在哪
多模态能力是指模型处理文字以外的内容：图像、语音、视频。
当前（2026 年）的能力校准
当前主流产品已可在一定条件下处理图文、语音、视频、生成/编辑图像，并让 Agent 依据视觉界面、文件或业务工具完成多步骤任务。2 3 4 这并不意味着任何模型、输入质量、部署方式或任务都达到相同可靠性。以下表格不列“绝对不能做什么”，而是把可探索能力与必须在本组织样本上验证的边界分开。
| 模态或能力 | 可在受控试点中评估的能力 | 仍需按任务验证、不可直接外推的边界 |
|---|---|---|
| 图像理解与文档视觉 | 识别图中文字、表格/图表字段、对象、界面状态和常见视觉关系；支持图文联合问答 | 小字、密集版面、遮挡、精确测量/计数、空间定位、专业图纸和高影响事实不应只靠单次输出确认 |
| 图像生成与编辑 | 从文字或参考图生成、修改和多轮迭代视觉草稿；可作为设计、沟通和原型辅助 | 品牌规范、文字细节、身份/肖像、版权授权、工程尺寸和对外材料必须走专门审核，不能把“看起来像”当作已符合要求 |
| 语音与音频 | 多语种语音转写、摘要、分类、部分说话人或事件线索提取 | 噪声、重叠说话、方言、专有名词、关键数字、身份归属和合规录音边界应以实际音频与审核流程验证 |
| 视频理解 | 摘要、关键片段定位、字幕、按任务抽取事件或界面线索 | 长视频覆盖、细粒度时序、复杂动作、身份/地点判断、实时性与证据完整性需单独评测，不宜直接作为唯一事实依据 |
| 计算机使用与跨系统操作 | 在隔离环境中读取界面、填写字段、运行已批准步骤、验证部分结果 | 生产写入、外发、支付、权限变更、不可逆操作和异常恢复必须受最小权限、独立批准、日志与回退约束 |
纳入多模态的决策标准
| 判断维度 | 是/否 | 建议 |
|---|---|---|
| 任务是否真的需要处理图像/语音/视频，不能用文字替代？ | 是 | 考虑纳入多模态 |
| 模型在该模态上的能力是否足以支撑任务精度要求？ | 是 | 进行小批量测试验证 |
| 你是否已经为文字输出建立了稳定的验证机制？ | 是 | 先建立，再扩展到多模态 |
| 团队是否有能力为多模态输出设计验证标准？ | 是 | 多模态验证通常更复杂，需要专门设计 |
多模态的验证要点
多模态任务的验证通常比纯文字任务更复杂：
- 图像理解与视频理解：使用覆盖正常、低清、密集、小字、遮挡、冲突和高风险情形的标注样本；除准确率外，还检查来源、定位、遗漏、误报和人工接管。
- 语音转文字与音频分析：计算词错率（WER）或与任务相关的字段正确率，并对行业专词、关键数字、多人重叠、噪声和授权范围做专项测试。
- 图像生成与编辑：依据视觉规范、品牌/法律授权、文字可读性、事实一致性和版本差异评审；对外使用前由适当角色批准。
- 计算机使用：在隔离环境中测试任务完成、越权拒绝、异常界面、网络/工具失败、写入前确认、回退和审计日志，而不是只演示一次成功路径。
六、技术路线的选型决策树
你遇到了什么问题？
│
├── 任务尚未有清晰的输入输出、验证、回退和责任人
│ └── → 回到第 4 章，先完善并验证 Skill
│
├── 知识量太大，无法稳定提供给已定义的 Skill
│ └── → 先考虑固定 RAG，并验证来源、权限和检索质量
│
├── 下一步是否必须依据中间结果动态检索或调用受控实时系统？
│ ├── 否 → 保持固定 RAG 或固定工作流
│ └── 是 → 仅在上下文包、工具权限、状态、预算、审批与接管齐备后，评估 Agentic retrieval 或工具调用
│
├── 是否需要跨轮次保留已确认进度或决定？
│ ├── 否 → 使用任务内状态或短期摘要
│ └── 是 → 先建立记忆合约、来源定位、隔离、失效和删除机制
│
├── 输出风格/语气不稳定，已优化 Skill 中的 Prompt 和示例后仍无法解决
│ ├── 有覆盖真实任务、边界与风险样本的高质量数据，并已证明微调优于基线方案？
│ │ ├── 是 → 考虑微调试验与回归评测
│ │ └── 否 → 先补齐样本、评测和基线；短期可用少样本提示或其他可验证方案
│ └── 知识需要频繁更新？
│ ├── 是 → 选择可定位、可更新的上下文机制，再叠加风格提示词或候选微调
│ └── 否 → 以内部评测比较微调、提示词、结构化输出和工作流方案
│
├── 任务涉及图片/语音/视频
│ └── → 评估多模态方案
│
└── 以上都不是
└── → 回到第 4 章和第 6 章，深化基础工作流与 Skill 设计七、本章行动清单
评估是否需要进阶方案：
- [ ] 用本章决策树，判断你当前遇到的问题是否真的需要 RAG/微调/多模态
- [ ] 如果答案是“不需要”，记录下来，避免未来重复讨论这个问题
如果决定上 RAG：
- [ ] 整理知识库，确认数据质量和维护责任人
- [ ] 设计分块策略，用代表性任务验证检索质量、来源、权限、冲突和过期处理
- [ ] 建立知识库更新机制，明确触发条件、响应时限和受影响用例回归要求
如果决定采用 Agentic retrieval、工具生成上下文或持久记忆：
- [ ] 先确认固定工作流或固定 RAG 无法以可接受成本和质量完成任务
- [ ] 分别建立上下文包、工具/MCP 控制卡、记忆合约和上下文评测记录
- [ ] 在沙箱或受限范围测试来源选择、空结果、冲突、越权、超时、异常返回、回退和人工接管
如果决定上微调：
- [ ] 确认训练数据的来源、许可、质量、覆盖与标注一致性，并用基线比较判断样本量是否足以支持试验
- [ ] 明确微调的评估标准（什么样的输出算“好”）
- [ ] 评估知识更新频率，判断微调的长期维护成本是否可承受
本章小结
进阶技术方案不是越复杂越好。
固定 RAG 解决的是“知识量超出可稳定提供范围”的问题；Agentic retrieval 与工具生成上下文解决的是“任务需要在受控状态下按需获得信息”的问题；持久记忆解决的是“已确认的进度或决定需要跨轮次延续”的问题；微调解决的是“风格模式固化”的问题；多模态解决的是“需要处理非文字内容”的问题。它们解决的是不同维度的问题，可以组合，但不能相互替代，也不应在问题还没有明确时就急着引入。
大多数企业 AI 稳定产出的问题，都可以在“Skill（Prompt + 最小上下文 + 知识 + 验证 + 回退 + 责任）”的框架内解决。只有当这个框架在知识规模、运行时信息、长任务状态、模式固化或内容模态上触碰到明确天花板时，才是引入进阶方案的正确时机。