假设我们在做一个内部 SDK 升级助手。开发者把依赖清单和失败的 CI 日志交给它，它要判断用了哪个版本、给出带出处的迁移建议，并在沙箱里验证修改。比如日志提示某个配置项不认识，原因可能是旧选项已经移除，也可能是 CI 实际加载了另一个版本。用户看到的都是「升级建议不靠谱」，后台要分开查知识、行为和决策。
文档没进上下文，先查 RAG
如果正确的迁移指南刚发布，先看它是否已入库。如果已入库却没进模型上下文，再检查召回和重排。关键词完全一致的旧版 FAQ 可能排在前面，这时应该给文档保留版本、发布时间和适用范围，并根据项目依赖过滤候选。推理时检索并补充上下文，更新索引即可让助手读到新指南，基座权重保持原样。RAG 原论文
一个便宜的诊断办法是把标注过的正确段落直接交给模型，保持其余输入一致。如果答案随之变好，优先修证据链路。如果仍然混用新旧版本，就看模型能否遵守「按锁文件确认版本」「结论要能在引用段落中找到依据」等规则。RAG 能提供证据，回答仍需要正确使用它。
证据拿到了，判断是否值得做 SFT
强基座通常已经会读文档、解释报错和按示例写回复。可以先给一份短提示词、几条覆盖典型边界的示例，再用 schema 约束输出字段。比如要求结果包含 version、evidence 和 next_step，由代码验证版本字段和引用 ID。规则经常变，或者这套方案已经达到验收标准时，继续维护提示词和校验器就够了。字段合法只说明结构合规，引用是否支持结论还要另外测。
值得收集 SFT 数据的情况是，同一类约定在大量请求中反复失守，示例和校验后的重试仍解决不了，且团队对期望行为已有一致标准。比如面对锁文件与 CI 日志冲突，助手应先标出冲突、向用户索要能区分两个原因的信息，拿到证据后再给改动。可以用覆盖不同仓库、版本和失败类型的示范，提高模型遵守这套流程的概率。基座越强，越容易靠少样本达到门槛。SFT 的收益要看留出集上的约定遵守率、重试次数和提示成本，知识更新仍走文档库。InstructGPT 原论文
行为规范了，再看多步决策是否需要 RL
这个助手还得决定先复现失败、检查依赖树，还是直接试一处最小改动。不同仓库的最佳顺序可能不同。如果固定工作流和 SFT 基线已能解决大多数任务，先看剩余失败是否集中在这种路径选择上。具备可重置沙箱、足够的交互样本和可信评估时，可以让模型探索多条路径，用原故障是否修复、回归测试是否通过、执行步数等信号优化策略。先确保成功率，再比较步骤成本。测试由外部环境运行，并保留独立用例，避免模型靠改测试或提前结束拿分。DeepSeek-R1 技术报告
用同一批任务拆开量收益
固定测试集、初始基座、可用工具和执行预算。测试样本按仓库和时间留出，避免同一故障的近重复案例混进训练集。每轮对照只改一个环节。
| 对照 | 看什么 |
|---|---|
| 相同提示词，有无检索，再加一组直接给正确段落 | 正确版本证据的 Recall@k、引用是否支撑结论，区分召回和证据使用问题 |
| 相同检索和 schema，少样本基线对比加入 SFT | 证据冲突时的澄清率、无依据建议率、重试次数，验证行为是否更稳定 |
| 同一 SFT 检查点，加入 RL 前后对照 | 沙箱修复成功率、回归通过率、成功任务的工具步数，验证路径是否更有效 |
例如正确段落进入上下文后引用仍经常用错版本，就先改行为约束并量化结果。如果回答已引用正确版本，但验证过程中不断重复无效操作，再把预算投到决策层。这样每次改动都能对应到一种可观察的失败。