检索增强生成的技术叙事，长期被一个默认假设主导：生成环节必须交给尽可能大的模型。大模型拥有更强的语言组织能力、更广的世界知识和更好的指令遵循水平，似乎只有它才能把检索到的证据转化为流畅可信的回答。在这个假设下，RAG的优化方向几乎全部集中在检索侧：更好的分块、更准的向量、更强的重排序、更聪明的查询改写。生成侧则被视为一个黑箱，只要模型够大，输入足够的上下文，输出自然就好。
但这个假设正在被工程现实修正。当RAG系统从演示走向生产，当每天的查询量从几百次增长到几十万次，当部署环境从云端数据中心延伸到边缘设备和私有化内网，大模型在生成环节的三个代价开始变得不可忽视：推理延迟、调用成本和对硬件资源的刚性依赖。一个每次回答都调用千亿参数模型的RAG系统，在演示时令人惊艳，在生产中却可能因为成本结构而难以为继。
小语言模型的价值正是在这个背景下浮现的。参数量在十亿以下、经过蒸馏或领域微调的小模型，在RAG系统的多个环节中展现出大模型无法替代的工程优势。它们不是在替代大模型，而是在RAG的内部劳动分工中找到了属于自己的位置。理解这种分工的逻辑，比争论小模型能否达到大模型的效果更有意义。
本文从小模型的能力边界出发，系统分析它在RAG系统中的多重角色：查询理解与改写、检索路由与过滤、上下文压缩与重排、答案草稿生成、幻觉初筛以及边缘侧独立推理。文章还会讨论小模型与大模型在RAG架构中的协同模式，以及在实际落地中需要跨越的工程门槛。
第一章 重新理解小语言模型的能力边界
1.1 小模型不是什么
讨论小模型在RAG中的作用，首先需要澄清一个常见的误解：小模型不是缩小版的大模型。两者的差异不只是参数量，更在于能力结构的不同。
大模型的核心优势在于通用知识覆盖和复杂语义推理。它读过海量文本，能够在没有外部信息的情况下回答大量常识性问题，能够处理多步逻辑推理、抽象概念对比和跨领域的知识迁移。这些能力来自参数规模带来的知识容量和表达能力。
小模型在这些维度上存在明显短板。它的知识覆盖面窄，面对开放域的复杂问题时容易暴露知识盲区。它的多步推理能力有限，在需要连续推导的任务上容易中途偏离。它对隐含意图的理解不够细腻，在提示词模糊时更容易给出泛泛的回答。
承认这些短板，是合理使用小模型的前提。小模型的价值不在于在所有场景下追赶大模型，而在于在特定环节中以更低的代价完成足够好的工作。
1.2 小模型擅长什么
与短板对称，小模型在另一组能力上具有天然优势。
第一是任务聚焦下的稳定性。当一个任务被明确定义、输入格式固定、输出要求清晰时，小模型的表现远好于开放域问答。比如判断一段文本是否与查询相关，比如把用户的口语化问题改写为结构化的检索查询，比如从检索结果中抽取与问题直接相关的句子。这些任务的边界清晰，不需要广博的世界知识，小模型经过少量微调就能达到可用水平。
第二是推理效率。参数量小意味着单次推理的延迟低、吞吐高。在同样的硬件上，小模型的每秒请求处理能力可能是大模型的数十倍。对于RAG系统中那些高频、低复杂度的子任务，这种效率优势直接转化为成本节约和体验改善。
第三是部署灵活性。小模型可以运行在消费级GPU、边缘设备甚至高性能CPU上，不需要依赖云端的大规模推理集群。这使得RAG系统可以在私有化环境、离线环境和资源受限的环境中部署，拓展了RAG的应用边界。
第四是可控性。小模型的行为更容易预测和约束。它的输出空间相对窄，在格式遵循和边界控制上更容易通过微调达到稳定。对于需要严格遵循输出规范的子任务，这种可控性比大模型的灵活性更有价值。
1.3 小模型在RAG中的定位原则
基于上述能力分析，小模型在RAG系统中的定位可以归纳为三条原则。
原则一是任务拆解优先于能力替代。不要把整个回答生成交给小模型，而是把RAG流程拆解为多个子任务，把其中边界清晰、知识依赖低的子任务交给小模型，把需要深度推理和广博知识的子任务留給大模型。
原则二是效率敏感环节优先。在RAG流程中，有些环节被高频调用但对单次结果的精度要求不那么苛刻，比如初步的相关性过滤。这些环节是số小模型的最佳切入点。
原则三是与边缘场景绑定。当RAG需要部署到没有云端连接的场景时，小模型不是可选项，而是唯一可行选项。这时它的定位不是效率优化，而是能力可用性的保障。
第二章 RAG系统的内部劳动分工
2.1 传统RAG流程的隐性成本
要理解小模型的作用，需要先看清传统RAG流程中的隐性成本。
一个典型的RAG请求会经过以下环节：用户问题输入，查询改写或扩展，向量化和检索，候选文档重排序，上下文组装，大模型生成回答，输出后处理。在这些环节中，大模型通常只在生成环节被调用，但其他环节的成本并不低。
查询改写如果也交给大模型，每个请求就多了一次大模型调用。重排序如果使用大模型做交叉编码，每个候选文档都要经过一次大模型推理，成本随候选数量线性增长。上下文组装如果包含无关片段，会浪费大模型的输入Token，增加生成延迟。输出后处理如果依赖大模型做校验，又是一次额外调用。
这些隐性成本在演示阶段不明显，在生产规模下会成为主要开销。小模型的介入，本质上是在这些环节中替代大模型的高成本调用，把大模型的计算预算集中在真正需要它的生成环节。
2.2 小模型可以承担的子任务
具体来看，小模型在RAG流程中可以承担以下子任务。
查询理解与改写。用户的问题往往口语化、指代不清或缺少上下文。小模型可以把这些问题改写为更适合检索的查询，包括补全指代、扩展同义词、拆解复合问题。这个任务的知识依赖低，主要考察语言转换能力，小模型经过微调完全可以胜任。
检索结果的相关性初筛。向量检索返回的Top-K结果中，通常有相当比例是弱相关或无关的。用一个小的交叉编码器或小语言模型做初步的相关性判断，可以快速过滤掉明显不相关的结果，减少后续重排序和生成的负担。
上下文压缩与片段抽取。检索到的文档片段可能很长，包含大量与问题无关的内容。小模型可以从每个片段中抽取与问题直接相关的句子，压缩上下文长度，提高大模型输入的信噪比。
答案草稿的初步生成。对于一些简单的事实性问题，小模型基于检索到的证据直接生成答案，可能已经足够。只有当小模型判断自己无法确定答案时，才升级到大模型。这种分层生成策略可以显著降低平均成本。
幻觉的初步筛查。小模型可以检查生成的答案是否能在检索证据中找到支撑，如果发现答案中的关键声明在证据中不存在，标记为可疑，触发重新生成或人工审核。
2.3 分工的边界在哪里
小模型和大模型的分工边界不是固定的，它取决于三个变量。
任务的复杂度。越简单的任务越适合小模型，越复杂的任务越需要大模型。但复杂度不是单一维度，它包含知识广度、推理深度和输出自由度。一个知识依赖低但输出自由度高的任务，比如创意写作，可能仍然需要大模型。一个知识依赖高但输出格式固定的任务，比如从文档中抽取结构化字段，小模型微调后可能表现更好。
错误的代价。如果一个子任务的错误可以被下游环节纠正，那么用低成本的小模型试错是合理的。如果一个子任务的错误会传播到最终输出且无法挽回，那么应该使用更可靠的模型。
调用频率。高频调用的环节对单次成本更敏感，适合小模型。低频调用的环节对单次质量更敏感，适合大模型。
这三个变量共同决定了分工的边界。在实际系统中，边界会随着业务变化和模型迭代而移动。
第三章 小模型在查询理解环节的作用
3.1 查询改写的必要性
用户输入的问题很少是完美的检索查询。它可能包含代词而没有明确的指代对象，可能使用口语化的表达而缺少专业术语，可能是一个复合问题需要拆解为多个子查询，可能包含拼写错误或语法错误。
这些问题如果不处理，检索的召回率会显著下降。查询改写是解决这些问题的标准手段。传统方法使用规则和同义词表，效果有限。大模型改写效果好但成本高。小模型在这个环节提供了一个成本和效果的平衡点。
3.2 小模型改写查询的实现方式
小模型改写查询通常采用序列到序列的方式。输入是原始问题和对话历史，输出是改写后的检索查询。训练数据可以通过大模型生成，再用人工筛选高质量样本进行微调。
训练数据的构造是关键。需要覆盖多种改写场景：指代消解、同义词扩展、问题拆解、拼写纠正和查询简化。每个场景提供数百到数千个样本，小模型就能学到对应的改写模式。
推理时，小模型的输出可以是一个或多个改写后的查询。多个查询分别检索后合并结果，可以进一步提高召回率。小模型的推理速度快，生成三到五个查询变体的延迟仍然远低于一次大模型调用。
3.3 效果评估与边界
小模型改写的效果评估需要看两个指标：改写后的查询是否提高了检索的召回率，以及改写是否引入了语义偏差。
在多数公开数据集上，经过微调的小模型在查询改写任务上可以达到大模型百分之八十五到九十五的效果，而推理成本只有大模型的几十分之一。这个性价比在大多数场景下是可以接受的。
边界在于复杂的多轮对话场景。当对话历史很长、指代关系复杂、需要理解隐含意图时，小模型的改写质量会明显下降。这时可以将这类请求路由给大模型处理，或者在小模型改写结果的基础上增加一层校验。
第四章 小模型在检索过滤与重排序中的作用
4.1 检索结果的噪声问题
向量检索基于语义相似度返回Top-K结果，但语义相似不等于与问题相关。一个文档片段可能在语义上接近问题，但并没有回答问题的关键信息。在Top-50的结果中，真正有用的片段可能只有五到十个。
这些噪声如果不处理，会带来两个问题。一是浪费上下文窗口，挤占有用信息的空间。二是干扰大模型的判断，无关片段可能引导模型产生错误的联想。
重排序是解决噪声的标准手段。传统方法使用交叉编码器对每个候选片段与问题的相关性打分，按分数重新排序。交叉编码器的效果好，但对每个候选片段都需要一次前向推理，当候选数量大时延迟和成本都不可忽视。
4.2 小模型做初筛的策略
小模型在重排序环节的定位是做初筛，而不是做精确排序。
初筛的目标是用极低的成本过滤掉明显不相关的片段，把候选数量从五十降到十到十五个，然后交给更精确的重排序器或直接交给大模型。初筛的精度要求可以放宽，只要保证不把真正相关的片段过滤掉。
实现方式上，可以用小模型对每个片段做一个二分类判断：相关或不相关。也可以让小模型给每个片段打一个粗略的相关性分数，然后按分数截断。二分类的推理成本更低，适合候选数量大的场景。
关键设计是初筛的召回率。初筛可以接受一定的误判，把一些弱相关的片段保留下来，但不能把真正相关的片段过滤掉。因此在阈值设置上应该偏保守，宁可多保留一些候选，也不要过早截断。
4.3 小模型作为交叉编码器的可行性
除了初筛，小模型也可以直接作为交叉编码器使用。交叉编码器将问题和片段拼接后输入模型，模型输出相关性分数。这种方式比双编码器的精度高，但推理成本也高。
小模型作为交叉编码器的可行性取决于候选数量。当候选数量在十到二十个时，小模型的交叉编码推理可以在几百毫秒内完成，成本远低于大模型。当候选数量超过五十个时，初筛加精排的两阶段方案更经济。
在实际系统中，常见的组合是：向量检索召回五十个，小模型初筛到十五个，小模型交叉编码精排到五个，大模型基于这五个片段生成答案。这个流水线在成本和质量之间取得了较好的平衡。
第五章 小模型在上下文压缩中的作用
5.1 上下文窗口的稀缺性
即使大模型的上下文窗口在不断扩大，上下文仍然是稀缺资源。每一个放入窗口的Token都占用生成模型的处理时间，都增加推理成本，也都可能分散模型对关键信息的注意力。
检索到的文档片段通常包含大量冗余信息。一段五百字的文档，可能只有一两句话与问题直接相关。如果直接把整段放进去，浪费是明显的。
上下文压缩的目标是在保留关键信息的前提下，缩短输入长度。压缩可以在检索后进行，也可以在检索前通过更精细的检索实现。小模型在后一种方式中发挥的作用更大。
5.2 小模型做抽取式压缩
抽取式压缩是从原文中选出与问题最相关的句子或短语，组成压缩后的上下文。这种方式不改变原文的表述，避免了生成式压缩可能引入的事实偏差。
小模型做抽取式压缩的实现方式是：将问题和文档片段拼接输入，让模型输出每个句子的相关性标签，或者直接输出被选中句子的索引。经过微调的小模型可以学会判断哪些句子包含回答问题的关键信息。
抽取式压缩的优势是可追溯。压缩后的每一句话都能在原文中找到出处，便于验证和引用。对于需要严格溯源的场景，比如法律和医疗领域的RAG系统，这个特性比生成式压缩更有价值。
5.3 小模型做生成式压缩
生成式压缩是用模型将原文改写为更短的表述，保留核心信息。这种方式可以更大幅度地缩短长度，但可能引入改写带来的语义偏差。
小模型做生成式压缩需要经过专门的微调，训练数据是原文和压缩版本的配对。压缩版本可以通过大模型生成，再用人工筛选保证质量。
生成式压缩的风险在于信息丢失和事实变形。小模型在压缩时可能遗漏关键限定条件，或者把模糊的表述压缩成过于确定的陈述。为了控制风险，可以在压缩后增加一个校验步骤，用小模型检查压缩版本中的关键声明是否能在原文中找到支撑。
第六章 小模型在生成环节的分层策略
6.1 不是所有问题都需要大模型
RAG系统面对的查询，复杂度分布是长尾的。大量查询是简单的事实性问题，答案可以直接从检索到的证据中提取或简单组合。只有少数查询需要跨文档的综合推理、多步逻辑推导或对复杂矛盾信息的权衡。
如果所有查询都交给大模型生成，简单查询的计算资源被浪费了。分层生成策略是根据问题的复杂度，把简单问题交给小模型，复杂问题交给大模型。
6.2 小模型直接生成的条件
小模型适合直接生成的情况包括：问题类型是事实查询，答案在检索证据中有明确表述；问题的答案可以在一到两个句子内完成；输出格式要求固定，比如填表或抽取字段；对回答的创造性没有要求。
在这些条件下，小模型基于检索证据生成答案的质量可以接近大模型，而延迟和成本大幅降低。判断是否满足这些条件，可以由一个小型分类器完成，也可以让小模型在生成时同时输出一个置信度分数，低于阈值时升级到大模型。
6.3 小模型作为草稿生成器
在更复杂的场景中，小模型可以作为草稿生成器。小模型先基于检索证据生成一个初步答案，然后由大模型对草稿进行审核、修正和润色。
这种模式的优势是降低大模型的生成负担。大模型不需要从零开始组织答案，只需要判断草稿中的信息是否准确、逻辑是否连贯、表达是否恰当，然后做针对性的修改。修改比从头生成的计算量小，延迟也更低。
草稿生成加审核修正的模式还有一个额外好处：小模型的草稿可以作为大模型推理的脚手架，帮助大模型更快地定位关键信息和组织答案结构。
6.4 升级策略的设计
分层生成的核心是升级策略。什么时候小模型的输出可以接受，什么时候需要升级到大模型，需要一个明确的判断机制。
判断机制可以基于小模型输出的置信度分数，也可以基于一个独立的验证器。验证器可以是另一个小模型，专门训练来判断答案是否充分。验证器检查答案是否覆盖了问题的所有部分，是否有证据支撑，是否存在明显的逻辑矛盾。
升级策略还需要考虑用户体验。如果需要升级到大模型，用户会感知到额外的延迟。因此在交互设计上，可以先返回小模型的答案并标注正在优化，大模型的修正版本随后更新。这种渐进式的响应方式可以改善感知体验。
第七章 小模型在幻觉筛查中的作用
7.1 RAG系统中的幻觉来源
RAG的设计初衷是减少幻觉，但RAG系统本身仍然会产生幻觉。幻觉的来源包括：检索证据本身包含错误信息；模型对证据的理解出现偏差；模型在证据不足时用内部知识填补空白；模型在组织答案时把不同来源的信息错误地拼接。
这些幻觉如果不筛查，会损害用户对系统的信任。传统的筛查方法依赖人工审核或规则检查，成本高且覆盖面有限。小模型为幻觉筛查提供了一个自动化的低成本方案。
7.2 小模型做声明级验证
声明级验证是将答案拆解为多个独立的事实声明，逐个检查每个声明是否能在检索证据中找到支撑。
小模型在这个任务中的角色是：给定一个声明和一组证据片段，判断该声明是否被证据支持、被证据反驳，还是证据不足。这个任务的边界清晰，小模型经过微调可以达到较高的准确率。
实现方式可以是逐声明验证，也可以是一次性验证整个答案。逐声明验证的精度更高，但推理次数多。一次性验证的效率更高，但对小模型的综合判断能力要求更高。
7.3 筛查结果的处置策略
筛查发现可疑声明后，需要有一个处置策略。
对于被证据反驳的声明，应该从答案中删除或修正。对于证据不足的声明，可以标注为待确认，或者触发额外的检索来补充证据。对于整体答案的可信度低于阈值的情况，可以触发大模型的重新生成或转人工审核。
处置策略的设计需要平衡自动化和人工介入。全自动化处置的效率高，但可能误删正确信息。全人工审核的质量高，但成本不可接受。合理的做法是根据可疑声明的严重程度分级处置，轻微问题自动修正，严重问题触发人工审核。
第八章 边缘场景下的小模型独立推理
8.1 离线环境的RAG需求
RAG不只存在于云端。在工业现场、医疗设备、车载系统和军事场景中，RAG需要在没有稳定网络连接的环境中运行。
在这些场景中，大模型无法部署，云端API无法调用。小模型成为唯一可行的选择。它可以在边缘设备上本地运行，结合本地的知识库完成检索和生成。
边缘RAG的典型应用包括：工业设备的故障排查助手，基于本地的维修手册和故障记录回答维修人员的问题；医疗设备的操作指引，基于设备说明书和操作规程回答医护人员的疑问；车载系统的知识问答，基于车辆手册和交通规则回答驾驶员的问题。
8.2 边缘RAG的架构设计
边缘RAG的架构与云端RAG有显著差异。
模型侧，使用参数量在一到三十亿之间的小模型，经过量化和蒸馏优化，适配边缘设备的算力。检索侧，使用轻量级的向量索引和本地部署的嵌入模型，索引规模控制在设备存储可容纳的范围内。知识侧，知识库需要预先处理并打包到设备上，更新通过定期的离线同步完成。
生成侧，小模型独立完成答案生成。由于没有大模型作为后备，小模型需要经过充分的领域微调，确保在目标领域的回答质量。同时需要设计明确的拒答机制，当检索证据不足或问题超出知识范围时，明确告知用户无法回答，而不是编造答案。
8.3 边缘与云端的协同
边缘RAG不必完全孤立。在网络可用时，边缘设备可以将复杂的查询转发到云端的大模型，获取更高质量的回答。网络不可用时，小模型独立工作，保证基本可用。
这种协同模式需要设计查询路由机制。简单的、本地的查询由小模型处理；复杂的、需要广博知识的查询在条件允许时升级到云端。路由决策可以基于查询的复杂度、本地检索的置信度和网络状态。
第九章 小模型与大模型的协同架构
9.1 级联模式
级联模式是最常见的协同架构。请求首先经过小模型处理，小模型判断自己能否胜任。如果能，直接返回结果；如果不能，升级到大模型。
级联模式的关键是升级判断的准确性。过于保守的升级判断会失去小模型带来的成本优势；过于激进的升级判断会导致质量问题。升级判断可以基于小模型的置信度、任务的复杂度分类，或者一个独立的路由模型。
9.2 并行模式
并行模式是小模型和大模型同时处理同一个请求，然后由一个小模型或规则来选择和融合两个结果。
并行模式的优势是延迟可控，因为不需要等待小模型的判断再决定是否调用大模型。劣势是成本较高，因为大模型总是被调用。并行模式适合对延迟敏感且成本可接受的场景。
9.3 流水线模式
流水线模式是将RAG流程拆分为多个阶段，不同阶段使用不同的模型。比如查询改写用小模型，检索过滤用小模型，答案生成用大模型，幻觉筛查用小模型。
流水线模式的核心是阶段划分和接口设计。每个阶段的输入输出需要明确定义，小模型和大模型之间的切换需要平滑。流水线模式的灵活性最高，但也最需要精心的工程设计。
9.4 协同架构的选择依据
选择哪种协同架构取决于三个因素。
成本预算。如果成本是主要约束，级联模式最经济。如果成本宽松但对延迟敏感，并行模式更合适。
质量要求。如果对答案质量有极高要求，流水线模式可以在每个环节都使用最合适的模型。如果质量要求中等，级联模式可能已经足够。
工程能力。流水线模式的工程复杂度最高，需要团队具备较强的系统设计能力。级联和并行模式的工程复杂度相对较低。
第十章 落地中的工程挑战
10.1 小模型的微调数据从哪来
小模型在RAG子任务上的表现高度依赖微调质量，而微调质量取决于训练数据的数量和质量。
训练数据的来源通常有三条路径。第一条是用大模型生成标注数据，再由人工筛选。这种方式效率高，但需要设计好提示词和筛选标准，确保生成的数据覆盖各种场景。第二条是从历史日志中挖掘数据，比如从用户的查询和点击行为中推断查询改写的效果。这种方式的数据真实，但覆盖面和标注质量可能不足。第三条是人工标注，质量最高但成本也最高，通常用于关键任务的精标。
实际操作中，通常采用组合策略：用大模型生成基础数据集，用历史日志补充真实场景，用人工标注修正关键样本。
10.2 小模型的版本管理
小模型在RAG系统中承担多个子任务，每个子任务可能对应一个独立微调的模型。随着业务变化和模型迭代，这些模型需要版本管理。
版本管理需要记录每个模型的训练数据版本、微调参数、评估指标和部署时间。当某个子任务的效果下降时，需要能够快速定位到是哪个模型版本的问题，并回滚到上一个版本。
模型版本与RAG流程的配置需要联动管理。当检索策略变化时，可能需要重新训练查询改写模型。当知识库更新时，可能需要重新评估幻觉筛查模型的效果。
10.3 评估体系的建立
小模型的引入使RAG系统的评估变得更复杂。需要评估每个子任务的独立效果，也需要评估整个系统的端到端效果。
子任务评估相对直接。查询改写看检索召回率的提升，初筛看重筛后的精度提升，压缩看上下文长度的减少和关键信息的保留率。每个子任务都有对应的指标。
端到端评估需要考虑子任务之间的相互作用。一个小模型在查询改写上的错误可能被后续环节弥补，也可能被放大。端到端评估需要在真实的用户请求上测试，收集用户反馈和业务指标。
10.4 延迟与吞吐的权衡
小模型虽然单次推理快，但在RAG流程中增加了多个处理环节，总的延迟可能并不比单次大模型调用低。
优化延迟的方法包括：合并可以并行处理的环节，比如查询改写和向量化可以同时进行；使用流式输出，在生成过程中逐步返回结果；预加载常用查询的结果，避免重复计算。
吞吐方面，小模型的优势在于可以批量处理。多个请求的初筛、压缩和验证可以合并为一个批次，充分利用GPU的并行能力。
第十一章 真实场景中的实践模式
11.1 客服知识库场景
某企业的客服RAG系统每天处理数十万次查询。原始方案中，每次查询都调用大模型生成答案，成本高昂且高峰期延迟明显。
改造后的方案引入了小模型分层处理。小模型先对查询做改写和意图分类，判断问题是否属于常见问题。对于常见问题，小模型直接从缓存的答案库中匹配答案，不调用大模型。对于非常见问题，小模型做检索初筛和上下文压缩，把精简后的证据交给大模型生成。
改造后，大模型的调用量下降了约百分之七十，平均响应时间从三秒降低到一点二秒，答案质量的关键指标保持稳定。
11.2 工业设备维护场景
某制造企业的设备维护RAG系统部署在车间边缘服务器上，网络连接不稳定，无法依赖云端大模型。
系统使用一个三十亿参数的小模型，经过设备手册和故障记录的微调。检索使用本地的向量索引，知识库每月通过离线同步更新。小模型独立完成查询理解和答案生成，当检索置信度低于阈值时，明确提示用户联系技术专家。
系统上线后，维修人员的问题解决时间平均缩短了百分之四十，对于网络中断的时段，系统仍然可以正常工作。
11.3 法律文档问答场景
某律所的法规检索RAG系统对可追溯性有极高要求。每个答案都需要标注引用来源，不能出现没有依据的陈述。
系统采用流水线架构。小模型负责查询改写、检索初筛和声明级验证。大模型负责最终的答案生成和表达润色。小模型在声明级验证环节的作用尤为关键，它检查大模型生成的每一个事实声明是否能在检索证据中找到支撑，发现无支撑的声明时触发重新生成。
这个架构使答案的可追溯性显著提升，人工复核的工作量下降了约百分之五十。
第十二章 未来演进
12.1 小模型能力的持续提升
小模型的能力边界不是固定不变的。随着蒸馏技术、量化技术和训练方法的进步，同样参数量的小模型在特定任务上的表现持续提升。
未来可能出现针对RAG子任务专门优化的小模型系列，每个模型专注于一个环节，在精度和效率上都达到极致。这种专用化趋势已经在查询改写和重排序领域显现。
12.2 模型路由的智能化
小模型和大模型之间的路由决策，目前多依赖规则或简单的分类器。未来可能出现专门的路由模型，根据查询特征、历史效果和实时负载动态决定使用哪个模型。
智能路由的价值在于它能够适应业务的变化。当小模型在某个领域的效果下降时，路由模型可以自动增加该领域请求升级到大模型的比例。当大模型的价格下降时，路由模型可以调整成本收益的计算，增加大模型的使用比例。
12.3 RAG架构的模块化
RAG系统正在从固定的管线向模块化的架构演进。每个模块可以独立替换和升级，小模型和大模型只是模块的实现选项之一。
模块化的好处是灵活性。团队可以根据业务需求和成本预算，自由组合不同的模型和策略。小模型在这个架构中是一个可插拔的组件，而不是一个固定角色的参与者。
结语
小语言模型在RAG系统中的作用，本质上是一个劳动分工的问题。RAG是一个多环节的流水线，每个环节对模型能力的需求不同。大模型适合承担需要广博知识和深度推理的核心生成任务，小模型适合承担边界清晰、高频调用的辅助任务。
这种分工不是对小模型的降级使用，而是对它的精准定位。小模型在查询改写、检索过滤、上下文压缩、初步生成和幻觉筛查等环节中，以更低的成本和更快的速度完成足够好的工作，让大模型的计算预算集中在真正需要它的地方。
RAG系统的未来不是单一模型的独角戏，而是多种模型协同的交响乐。理解每个模型的能力边界，设计合理的分工和协同机制，比单纯追求更大的模型或更复杂的检索更重要。当小模型和大模型在RAG流程中各司其职时，系统的效率、成本和质量的平衡才真正成为可能。