[控场AI]
· 9 分钟阅读· 4,675 字

Prompting、RAG与微调怎么选？先诊断故障再定方案

Prompting、RAG与微调怎么选？先诊断故障再定方案

大模型出错先诊断根因，再在提示词、RAG、微调、工具和代码之间选择组合干预。

文章指出，大模型应用出错时不应直接把症状当病因，而应先检查输入、来源证据、检索结果、工具响应和预期输出，再决定干预手段。提示词、RAG 和微调解决的是不同问题：提示词适合表达风格和任务边界，RAG 适合私有或变化中的文档，微调适合基线优化后仍偏弱的稳定任务模式。三者可以组合，且检索不保证正确或合规，强制规则应落在确定性代码中，实时数值应通过工具或 API 获取。所有改动都必须用任务级评估验证，并测量实际时延与成本。

大模型应用出错时，很多团队的第一反应是「换个更大的模型」或「上微调」。但一个错误答案只是一次观测结果，不是根因。在动手改提示词、接入检索或启动训练之前，先弄清失败到底来自哪里——是上下文缺失、标签歧义、基础模型能力不足，还是根本不在模型本身。

别把症状当病因

同一类错误可能对应完全不同的成因。指令不清晰和检索没覆盖到关键文档，表现都是「答非所问」；缺少实时数值和缺少私有知识，表现都是「编造内容」；基座模型能力不够，和训练数据标签有噪声，也可能给出看似相似的错误。

原始素材给出一张诊断对照表，思路很清晰：先看证据，再选干预手段。

观察到的问题应先检查的证据候选干预
指令不清或风格不对提示词措辞、示例、指令冲突、任务测试改进提示词并评估改动
答案需要私有或变化中的文档来源版本、访问过滤、检索覆盖率、引用支撑通过 RAG 检索相关文档并作为上下文
答案需要实时的数值权威服务、时间戳、单位、响应结构请求时调用工具或 API
某条规则必须严格强制执行已批准的规则说明、输入、边界情况、授权用确定性代码实现并测试
基线优化后，稳定任务模式仍偏弱标签质量、代表性样本、模型能力、留出集结果对比基线评估微调

一个常见误区是：某个错误频繁出现，就断定它来自预训练。素材明确提醒，先查标签、缺失上下文、预处理和任务定义，再考虑换基座模型或加训练。

rss source: Prompting vs RAG vs fine-tuning

三者各自解决什么

Prompting 在推理时提供指令和示例，成本最低、迭代最快，适合解决表达风格、格式约束、任务边界说明这类问题。它不改变模型权重，因此无法引入模型不知道的私有知识，也无法保证实时性。

RAG 检索相关内容并注入模型输入，适合需要私有文档或频繁变化的资料。它的评估重点不在模型本身，而在来源版本、访问过滤、检索覆盖率、排序质量，以及引用是否真正支撑了每一条事实主张。素材特别强调：检索不等于正确答案，更不等于合规，来源覆盖和人工复核仍然必要。

Fine-tuning 用训练样本改变模型的学习行为，适合「稳定任务模式在基线优化后依然偏弱」的情况。它不适合用来刷新变化中的事实，也不适合强制执行精确规则。素材提到 LoRA：它冻结基座权重、学习低秩更新——但冻结基座不等于行为不变，更新一旦应用，目标任务的收益和其他任务的回退都要实测。

三者是可组合的：一个微调过的模型照样可以使用提示词、检索和工具调用。

RAG（Retrieval-Augmented Generation，检索增强生成） 的核心思路是在模型生成答案之前，先从外部知识库中检索出与问题相关的文档片段，再把这些片段拼接进模型的输入上下文，让模型“看着材料回答”。它把知识存储与语言生成解耦：模型权重不变，知识更新只需更新索引。因此 RAG 特别适合私有文档、频繁变更的政策条款、内部手册等场景。但检索质量决定了答案上限——如果检索阶段没召回关键文档，或者召回了过时版本，模型再强也只能基于错误材料作答，甚至会用流畅语言把错误信息包装得很可信。

LoRA（Low-Rank Adaptation，低秩适配） 是一种参数高效微调方法。它不更新基座模型的全部权重，而是在若干层旁边插入小的低秩矩阵，只训练这些小矩阵。这样做大幅降低了显存和存储成本，也让同一基座可以挂载多个任务适配器。需要强调的是，LoRA 冻结的是基座权重，但适配器一旦生效，模型在目标任务上的输出分布就会改变，因此可能同时影响其他任务的表現，回归测试不可省略。

决策流程：从证据出发

素材给出的决策流程可以概括为：先检查失败证据，再分别评估提示词优化、检索相关文档、调用权威实时值、用代码强制规则、评估微调稳定模式，最后统一比较结果与运行成本。

关键在于，一个症状可能指向多个候选干预，而每个改动都要用任务级评估来验证，不能凭直觉认定某一种方案一定有效。

架构中各组件各司其职

把系统拆开看，每个组件有自己的职责和评估重点：

  • 提示词模板：负责指令、示例和上下文组装的版本管理，评估任务成功率和措辞敏感性
  • 文档摄入与检索：维护来源版本、访问过滤、索引和摘录，评估覆盖率、新鲜度、排序和引用支撑
  • 工具执行：获取权威数值、执行授权操作，评估结构、单位、时间戳、错误和授权
  • 确定性应用逻辑：强制执行显式业务规则和输出约束，评估边界情况与可复现性
  • 训练与模型注册：追踪数据集、基座版本、微调产物和评估证据，评估目标任务提升及其他任务回退
  • 编排与监控：组装上下文、路由请求、记录诊断信息，评估端到端质量、成本、时延和故障恢复

素材举了一个假想的政策助手例子：用检索提供适用文档版本和引用，用 API 获取实时费率，用代码做精确阈值计算。模型可以解释结果，但需要强制执行的规则必须落在应用逻辑里。

架构决策记录（ADR，Architecture Decision Record） 是一种轻量级的工程文档实践，用于记录一项重要技术决策的背景、选项、最终选择和后果。它的价值不在于“记录正确”，而在于让团队日后能追溯：当时为什么这么选，约束是什么，如果条件变化应该重新评估什么。ADR 通常短小、按编号递增、随代码库一起版本管理。文章后文给出的两份 ADR 正是这种格式的示例：一份关于检索变化中的政策文档，一份关于评估微调以稳定分类行为。它们都明确写出了决策的背景、选择以及需要承担的运营成本，而不是只宣称方案有效。

诊断辅助代码（教学用途）

素材附带一段 Python 教学代码，把已诊断出的类别映射到候选干预，本身不做诊断、不授权操作、不判定合规：

from enum import Enum

class Finding(Enum):
    UNCLEAR_INSTRUCTIONS = "unclear_instructions"
    DOCUMENT_GAP = "document_gap"
    LIVE_VALUE = "live_value"
    EXACT_RULE = "exact_rule"
    STABLE_TASK_GAP = "stable_task_gap_after_baselines"

INTERVENTIONS = {
    Finding.UNCLEAR_INSTRUCTIONS: "evaluate_prompting",
    Finding.DOCUMENT_GAP: "evaluate_rag",
    Finding.LIVE_VALUE: "query_authoritative_tool",
    Finding.EXACT_RULE: "implement_tested_code",
    Finding.STABLE_TASK_GAP: "evaluate_fine_tuning",
}

def candidate_interventions(findings: list[Finding]) -> list[str]:
    """Return unique candidates in the order the findings were supplied."""
    if not isinstance(findings, list):
        raise TypeError("findings must be a list of Finding members")
    candidates = []
    for finding in findings:
        if not isinstance(finding, Finding):
            raise TypeError("each finding must be a Finding member")
        candidate = INTERVENTIONS[finding]
        if candidate not in candidates:
            candidates.append(candidate)
    return candidates

候选名称刻意描述「下一步工程动作」，而不是承诺「一定能修好」。一次真实调查可能同时产出多个类别，所以函数接受多个 finding。

rss source: Prompting vs RAG vs fine-tuning

两条架构决策记录

素材给出两份假想的架构决策记录（ADR），展示了不同场景下的取舍。

ADR 001：检索变化中的政策文档。 上下文是助手需要解释独立于模型发布而变化的政策文档。决策是维护带版本和生效日期的可搜索来源集合，按新鲜度要求刷新，施加访问过滤，检索相关段落并保留引用元数据。后果是文档更新无需重训模型即可生效，但摄入和检索带来额外运营工作与延迟，单靠新索引不能证明答案正确、完整或合规。

ADR 002：评估微调以稳定分类行为。 上下文是分类器在检查完任务定义、标签、提示词和上下文后仍有反复错误。决策是用代表性、不相交的评估数据比较微调候选与改进后的基线，追踪基座模型、训练数据和微调配置，纳入目标类别之外的回归用例并保留回滚路径。后果是微调可能改善稳定任务行为，但改善必须被证明；训练数据、评估和模型生命周期管理都会增加成本。

评估与维护清单

素材最后给出一份可操作的检查清单，适合直接纳入团队工程规范：

  • 对提示词、模型配置、数据源和预期输出做版本管理，保证比较可复现
  • 用代表性样例测量端到端任务成功率，既看平均值也看单个失败案例
  • RAG 要评估来源覆盖、检索相关性、文档版本、访问控制，以及引用是否支撑每条事实主张
  • 工具调用要验证结构、单位、时间戳和错误状态，明确缓存结果何时可用，需要实时值时不要静默使用过期数据
  • 确定性规则要针对边界值和非法输入测试
  • 微调要保持训练与评估数据分离，与最强实用基线对比，上线前检查回退和漂移
  • 按实际应用测量每个成功任务的时延和成本，阈值来自自身需求，而非杜撰的通用基准
  • 诊断记录只保留调查所需信息，并做好保留策略和数据处理

从证据出发，选择候选改动，测量结果。让检索、工具执行、规则强制和学习行为各自对自己的测试负责——这才是把「不确定」变成「可运维」的路径。

参考来源

  • Microsoft: Retrieval augmented generation and indexes
  • Hu et al.: LoRA: Low-Rank Adaptation of Large Language Models (arXiv:2106.09685)
#Prompting#RAG#Fine-tuning#微调#检索增强生成#提示词工程#LoRA#大模型应用架构
分享：

相关推荐

恒星究竟能有多大？最大恒星的物理极限
·5 分钟

恒星究竟能有多大？最大恒星的物理极限

红超巨星是宇宙中体积最大的恒星，半径可达太阳的2000倍，吞没内太阳系。但恒星尺寸没有精确上限，模型预测可达15000倍太阳半径。质量最大的蓝色恒星体积远小于红超巨星——最大和最重是两回事。

阅读全文 →
苹果HomeView智能屏全功能解析：墙挂桌面两用，299美元
·5 分钟

苹果HomeView智能屏全功能解析：墙挂桌面两用，299美元

苹果发布299美元智能显示屏HomeView，支持壁挂和桌面两种安装方式，配备1200万像素摄像头实现面部识别，可控制智能家居、播放音乐、发送食谱到屏幕逐步跟做。本文全面解析HomeView的表盘、应用扩展、隐私保护和烹饪集成等核心功能。

阅读全文 →
承诺的新工作室去哪了？Craft Computing用五年时间给出答案
·6 分钟

承诺的新工作室去哪了？Craft Computing用五年时间给出答案

Craft Computing主理人回应观众质疑：承诺五年的新工作室因建设成本从3万暴涨至7.5万美元而搁浅，最终改为168平方英尺车库改造空间。频道收入因算法变化下滑，内容方向也将转向更务实的项目制作。

阅读全文 →