AI 工程
RAG 与微调：如何让模型掌握你的业务领域
检索在请求时为模型提供事实；微调改变的是模型的行为方式。把两者当作竞争方案会导向错误的架构，因为它们解决的是不同的问题。
· 阅读约 4 分钟 · Starone 工程团队
这个问题通常被表述为：在两种让模型了解业务的方式之间二选一。这种表述掩盖了真正有用的区别。检索增强生成（RAG）提供的是知识：它在请求时取回相关文本，放入上下文窗口。微调调整的是行为：它改变模型权重，使模型按特定格式输出、遵循特定策略，或更可靠地完成某项狭窄任务。
我们的默认做法是：凡属事实，一律用检索；只有当证据表明提示词和检索无法产生所需行为时，才考虑微调。本文余下部分解释原因，以及这一默认做法在哪些情况下并不适用。
两种技术各自改变了什么
使用检索时，模型本身没有变化。查询被转换为对索引的一次搜索，选出最相关的段落，模型再基于这些段落作答。知识存放在数据存储中，可以更新、过滤和审计。
使用微调时，基础模型在成对的输入输出样例上继续训练，通常借助 LoRA 这类低秩适配器，只学习一小部分新增权重。知识和行为被压缩进参数里。此后，没有任何一条内容可以被单独查阅、引用或删除。
为什么知识类需求默认用检索
业务知识会变化，面向不同的受众，有时还必须被移除。这三个特性，恰好对应检索系统擅长而微调模型不擅长的地方。
- 时效性：新政策一经索引即可使用，无需任何训练。
- 访问控制：可以在查询时按调用方权限过滤结果，因此两个用户问同一个问题，看到的来源并不相同。
- 可溯源：答案可以引用所依据的段落，读者得以核实，工程师得以调试。
- 删除：把文档从索引中移除，它就不会再出现在之后的答案里；而要从训练好的权重中抹去某条事实，在实践中仍是未解难题。
检索会在哪里出问题
检索把难点转移到了搜索上，而这类系统通常正是败在搜索。如果没有取回正确的段落，模型要么凭通用训练知识作答，要么自信地把空缺补上。固定长度的分块会把表格拆散，也会把条款和赋予它含义的标题分开。仅靠稠密向量会漏掉产品编码、条款编号这类精确标识符，因此我们把向量搜索与 BM25 等关键词搜索结合起来，再对合并后的候选结果做重排序（rerank）。
检索还会让每次请求都付出 token 和延迟的代价，而且难以应对需要纵览整个语料库的问题，例如汇总所有包含某一条款的合同。这类问题需要聚合流水线或结构化查询，而不是更大的 top-k。
微调在哪些场景物有所值
当问题在于模型如何回应，而不在于它知道什么时，微调才是合适的工具。典型场景包括：靠提示词在大批量下无法稳定维持的严格输出结构；临床或法律文书这类领域语体；拥有数千条标注样例的分类或抽取任务；以及需要以低成本或在私有基础设施上运行小模型的要求。在最后一种情况下，用大模型的输出来微调小模型，可以把一项狭窄任务纳入大模型无法满足的延迟和成本预算之内。
当提示词已经膨胀到数页的指令和示例，而且每次调用都要为之付费时，微调同样值得考虑。把稳定的行为移入权重，可以缩短提示词。
微调模型的运维成本
微调后的模型是一个有自己生命周期的构建制品。它需要一套精心整理的训练集、一套留出的评估集、一份记录哪些数据产出了哪个版本的台账，还需要一份预案，应对基础模型下线、必须在后继模型上重新微调的那一天。含有个人信息或机密信息的训练数据，此时已经嵌入一个难以检视的制品之中。
质量上也有风险。狭窄的微调可能削弱通用能力，即所谓的灾难性遗忘；而一个用事实微调过的模型，在事实变化之后仍会满怀信心地陈述过时的内容。这是我们不把微调当作知识存储的主要原因。
一个经得起推敲的决策顺序
我们按成本和可逆性的顺序逐一尝试各个选项，并在第一个达到评估目标的选项上停下。
- 写一段清晰的提示词，附上少量示例，并用评估集来衡量它。
- 如果语料规模小且稳定，就直接放进上下文窗口并使用提示词缓存（prompt caching）；检索基础设施可能并无必要。
- 当知识体量大、持续变化或带有权限要求时，再引入检索。
- 当剩下的失败集中在格式、语气或任务技能上，并且有足够多的高质量样例时，再做微调。
- 必要时两者结合：用一个善于利用检索上下文的微调模型，事实仍由索引提供。
什么时候反过来选才对
当任务是封闭的、知识是静态的，先做微调是合理的：把支持工单归入固定的分类体系，从已知类型的文档中抽取字段，或者在没有索引可查的设备上离线运行。检索会引入这类任务并不需要的活动部件。
无论选哪一种，决策都应当基于度量。一套能把检索失败与生成失败区分开的评估集，可以说明哪种技术针对的是实际观察到的错误，也能避免为一个本可以靠改进搜索解决的问题，去做一次昂贵的训练。