这类研究最值得关注的不是模型本身有多强而是它提供了一种新思路不修改小模型内部参数而是在推理阶段通过大模型“搭脚手架”的方式让小模型也能完成超出其原有能力的复杂任务。这相当于给一个普通工人配了一位经验丰富的老师傅老师傅不直接上手而是在旁边指导工人如何一步步操作最终工人也能独立完成高难度工作。如果你手头只有计算资源有限的小模型但又希望它能处理一些需要多步推理、逻辑判断或知识整合的任务那么这种“推理阶段能力迁移”的方法就非常值得一试。它绕开了微调、蒸馏等需要大量数据和算力的传统路径直接在“用”的层面做文章。下面我会围绕这个核心思路拆解清楚它到底怎么用、需要什么条件、具体怎么操作以及落地时最容易踩哪些坑。1. 先搞懂“搭脚手架”到底是什么意思别和微调、蒸馏弄混了很多人一听到“提升小模型能力”第一反应就是微调Fine-tuning或者知识蒸馏Knowledge Distillation。但这篇论文提出的方法和这两者有着本质区别。1.1 传统方法改变模型“本身”微调需要准备大量领域数据在小模型的原始权重上继续训练。这相当于让工人脱产去上培训班学成之后他自己就变成了一个掌握新技能的工人。代价是培训训练成本高且工人模型的“原始技能”通用能力可能会被削弱灾难性遗忘。知识蒸馏用一个大模型教师的输出作为“软标签”去训练一个小模型学生。这相当于让工人反复观摩老师傅的操作录像直到自己能模仿出来。这同样需要训练过程并且对“录像”训练数据的质量和匹配度要求很高。1.2 “搭脚手架”方法改变模型“使用方式”核心完全不修改小模型的任何权重参数。小模型还是原来那个小模型它的“知识”和“能力”上限并没有改变。过程在推理使用时引入一个大模型作为“规划师”或“分解器”。当遇到一个复杂任务时先让大模型把这个任务拆解成一系列小模型肯定能执行的简单子任务并安排好执行顺序。然后小模型就像按照一份详细的“操作手册”一步步完成这些子任务最终组合成复杂任务的结果。类比老师傅大模型拿到一张复杂的家具图纸复杂任务。他不会自己动手做而是根据工人小模型只会锯木头、钉钉子的现状把图纸分解成“先锯一块30厘米木板”、“再钉两个直角”、“最后刷一遍漆”等简单指令序列。工人严格执行这些指令最终也能组装出家具。这种方法最大的优势在于轻量化和灵活性。你不需要为每个新任务都去训练一个小模型只需要有一个能调用的大模型可以是云端API也可以是本地部署的来负责“任务分解”即可。小模型保持不变部署成本极低。2. 落地前先确认你的“大模型”和“小模型”分别是什么理论很美好但落地需要具体的工具。这里的关键是明确你手中的“大”和“小”具体指什么以及它们如何协作。2.1 “大模型”的选择不一定要巨无霸“大模型”在这里的角色是任务分解与规划。它需要具备较强的逻辑理解、指令遵循和步骤拆解能力。云端API模型例如 GPT-4、Claude-3、DeepSeek等。这是最方便的选择你只需要一个API Key。优势是能力强、稳定劣势是有使用成本、网络依赖和潜在的延迟。本地部署的中等模型例如 Qwen1.5-32B、Llama-3-70B 等经过量化后能在消费级显卡如RTX 4090上运行的模型。优势是数据隐私性好、无网络延迟劣势是对硬件有要求且规划能力可能略逊于顶级闭源模型。关键点这个大模型不需要针对你的下游任务进行训练。它只需要具备通用的任务分解和指令生成能力。你的主要成本金钱或算力是消耗在它身上的。2.2 “小模型”的选择明确它的能力边界“小模型”是最终任务的执行者。它的能力边界决定了“脚手架”要搭多细。典型代表参数量在7B或以下的模型如 Llama-3-8B、Qwen1.5-7B、Gemma-7B 等甚至是更小的模型。经过量化后它们可以在CPU或低端GPU上快速运行。能力审计在搭建系统前你必须彻底测试你的小模型单独能做好什么。例如它能做简单的文本分类吗情感正/负它能做实体识别吗从句子中提取人名、地点它能做简单的文本改写或摘要吗总结一段话的核心意思它能回答基于给定段落的事实性问题吗闭卷问答原则你交给小模型的每一个子任务都必须是它独立就能较高成功率完成的。如果子任务对它来说还是太难那这个方案就会失败。2.3 协作接口如何让两者对话大模型和小模型不会自动协作。你需要编写一个“协调器”程序通常是Python脚本来管理整个流程接收用户复杂任务。调用大模型API/本地接口将复杂任务和“小模型能力描述”一起作为提示词Prompt输入要求大模型输出一个步骤列表。解析大模型输出的步骤将其转化为一个个具体的、可执行的请求。对于每个步骤调用本地小模型执行并收集结果。可能需要将中间结果作为下一步的输入继续执行后续步骤。整合所有步骤的结果形成最终输出。这个“协调器”是整个系统的核心它的稳定性和错误处理能力决定了系统的可用性。3. 从零开始搭建你的第一个“脚手架”系统我们以一个具体的例子来贯穿整个流程让一个仅擅长提取实体和总结段落的小模型完成一份“行业竞品分析报告”的生成。假设条件大模型使用 GPT-4 Turbo API你也可以替换为任何支持Chat Completion的API或本地模型。小模型本地部署的 Qwen1.5-7B-Chat4位量化版它能在16GB内存的机器上流畅运行。任务输入三篇关于“智能音箱”的新闻文章输出一份包含“主要玩家”、“技术亮点”、“市场趋势”和“潜在风险”的分析报告。3.1 环境准备与模型部署小模型本地部署以Ollama为例# 安装Ollama (Linux/macOS) curl -fsSL https://ollama.com/install.sh | sh # 拉取并运行量化后的小模型 ollama pull qwen2.5:7b ollama run qwen2.5:7b运行后Ollama会在本地11434端口提供一个类OpenAI的API接口。Python环境pip install openai requests如果你用其他大模型API如DeepSeek安装对应的SDK。3.2 编写“协调器”与提示词工程这是最关键的一步。我们需要设计两个核心提示词Prompt。1. 给大模型规划师的提示词这个提示词必须清晰定义小模型的能力并明确输出格式。planning_prompt 你是一个任务规划师。你需要将一个复杂任务分解为一系列简单的子任务以便一个能力有限的小模型执行。 ## 小模型的能力描述 1. **实体识别**能从一段文本中提取出公司名、产品名、技术术语、人名、地点等实体。 2. **文本摘要**能对一段文本少于500字进行概括总结其核心内容。 3. **基于文本的问答**能根据提供的文本内容回答一个具体的事实性问题。 ## 复杂任务 请根据用户提供的三篇关于“智能音箱”的新闻文章生成一份竞品分析报告需包含“主要玩家”、“技术亮点”、“市场趋势”和“潜在风险”四个部分。 ## 你的工作 请设计一个详细的步骤列表。每个步骤必须 - 只调用上述小模型的一种能力。 - 输入明确例如指定对哪篇文章或哪个段落进行操作。 - 输出描述清晰例如“输出提取出的所有公司名列表”。 请以严格的JSON格式输出格式如下 { steps: [ { step_id: 1, instruction: 执行的具体指令如对文章A进行摘要限100字内。, ability_required: 实体识别, input_spec: 文章A的全文, output_desc: 文章A的摘要文本 }, // ... 更多步骤 ] } 请确保步骤之间有逻辑依赖关系后一步骤可以使用前一步骤的输出。 2. 给小模型执行者的提示词模板对于每种能力我们需要一个固定的提示词模板确保小模型能稳定执行。实体识别模板“请从以下文本中提取所有的实体并按‘公司’、‘产品’、‘技术’、‘人物’、‘地点’分类列出{text}”文本摘要模板“请用不超过100字总结以下文本的核心内容{text}”基于文本的问答模板“请根据以下文本回答问题。文本{context} 问题{question}”3.3 协调器核心逻辑代码简化版import openai import requests import json # 配置 BIG_MODEL_API_KEY your-openai-api-key SMALL_MODEL_URL http://localhost:11434/api/generate # Ollama 接口 SMALL_MODEL_NAME qwen2.5:7b # 1. 定义小模型调用函数 def call_small_model(prompt, ability): 根据能力选择模板调用本地小模型 if ability 实体识别: formatted_prompt f请从以下文本中提取所有的实体并按‘公司’、‘产品’、‘技术’、‘人物’、‘地点’分类列出{prompt} elif ability 文本摘要: formatted_prompt f请用不超过100字总结以下文本的核心内容{prompt} elif ability 基于文本的问答: # 这里prompt应该是一个包含context和question的字典或字符串 formatted_prompt f请根据以下文本回答问题。文本{prompt[context]} 问题{prompt[question]} else: return None payload { model: SMALL_MODEL_NAME, prompt: formatted_prompt, stream: False } try: response requests.post(SMALL_MODEL_URL, jsonpayload) result response.json() return result.get(response, ).strip() except Exception as e: print(f调用小模型失败: {e}) return None # 2. 调用大模型进行任务规划 def plan_with_big_model(user_task, articles): client openai.OpenAI(api_keyBIG_MODEL_API_KEY) # 将文章内容整合到提示词中 full_prompt planning_prompt f\n\n## 提供的文章内容\n{json.dumps(articles, ensure_asciiFalse)} response client.chat.completions.create( modelgpt-4-turbo-preview, messages[{role: user, content: full_prompt}], temperature0.1, # 低温度保证规划稳定性 response_format{type: json_object} ) plan json.loads(response.choices[0].message.content) return plan[steps] # 3. 主执行循环 def execute_plan(steps, articles): results {} for step in steps: step_id step[step_id] ability step[ability_required] # 根据input_spec解析输入这里简化处理实际需要解析对哪篇文章的操作 input_text resolve_input(step[input_spec], articles, results) print(f执行步骤 {step_id}: {step[instruction]}) output call_small_model(input_text, ability) if output: results[step_id] output print(f步骤 {step_id} 结果: {output[:100]}...) # 打印前100字符 else: print(f步骤 {step_id} 执行失败) # 简单的错误处理终止或跳过 break return results def resolve_input(input_spec, articles, previous_results): # 这是一个简化的解析函数。实际应用中需要解析input_spec字符串。 # 例如input_spec可能是“文章A的第二段”或者“步骤3的输出”。 # 这里我们假设input_spec直接就是文章内容或上一步的结果。 if input_spec in articles: return articles[input_spec] # 更复杂的解析逻辑需要根据你的步骤设计来实现 return input_spec # 4. 整合最终报告 def generate_final_report(execution_results, steps): # 这里可以根据steps中定义的输出描述从execution_results中提取数据 # 然后组织成“主要玩家”、“技术亮点”等部分。 # 可以再次调用大模型进行润色整合也可以直接用规则拼接。 report 竞品分析报告由大模型规划小模型执行生成\n report *50 \n # ... 具体的整合逻辑 return report # 主函数 if __name__ __main__: # 假设有三篇文章 articles { 文章A: 这里是第一篇关于智能音箱市场格局的新闻内容..., 文章B: 这里是第二篇关于语音AI技术突破的新闻内容..., 文章C: 这里是第三篇关于数据隐私风险的新闻内容... } user_task 生成智能音箱竞品分析报告 print(开始任务规划...) steps plan_with_big_model(user_task, articles) print(f规划完成共{len(steps)}个步骤。) print(\n开始执行步骤...) step_results execute_plan(steps, articles) print(\n生成最终报告...) final_report generate_final_report(step_results, steps) print(final_report)3.4 运行与验证确保小模型服务Ollama已启动。配置好大模型的API Key。运行上述Python脚本。验证重点规划合理性观察大模型生成的步骤列表。是否每一步都落在了小模型的能力范围内步骤间的依赖是否清晰执行成功率观察每个小模型步骤的执行结果。实体识别是否准确摘要是否抓住了核心问答是否基于给定文本最终输出质量最终的报告是否结构清晰、内容相关虽然文笔可能不如纯大模型生成但信息点是否都覆盖了通过这个流程你就完成了一个最基本的“大模型搭脚手架小模型执行”的系统。小模型没有经过任何微调但通过精心的任务分解它协作完成了一个原本无法独立完成的任务。4. 从Demo到实用必须处理的稳定性与边界问题跑通Demo只是第一步。要让这个模式真正可用你必须系统性地解决以下几个问题这些都是从Demo到产品化过程中必然会遇到的坑。4.1 大模型规划的不可控性这是最大的挑战。大模型生成的步骤计划Plan可能超出小模型能力规划出一个需要“对比分析”或“预测未来”的步骤小模型根本无法执行。逻辑错误步骤顺序混乱后一步需要前一步的结果但前一步并没有产生这个结果。格式错误不按你要求的JSON格式输出导致程序无法解析。应对策略强化提示词约束在给大模型的提示词中极其严格地定义小模型的能力列表并使用“少样本示例”Few-shot展示正确的步骤格式。引入计划验证环节在正式执行前增加一个“计划验证”步骤。可以用另一轮大模型调用或规则来检查每个步骤的“ability_required”是否在允许列表中检查输入输出描述是否清晰。设置重试与降级如果大模型连续几次都无法生成合格计划系统应降级为执行一个预设的、简单的备用计划或直接向用户返回错误。4.2 小模型执行的错误累积即使每一步的成功率有90%10个步骤连续执行下来的总体成功率也只有0.9^10 ≈ 35%。任何一步失败整个任务都可能失败。应对策略步骤原子化与容错将步骤设计得尽可能原子化一步只做一件事。并为每一步设计明确的成功/失败判断标准例如实体识别结果是否为空列表摘要长度是否在合理范围内。实现步骤重试对于失败的步骤不是整个任务失败而是可以重试例如换一种提问方式重新调用小模型或者跳过如果该步骤非关键。中间结果校验与清洗对小模型的输出进行后处理。例如实体识别结果用正则表达式过滤掉明显非实体的词摘要结果如果包含“抱歉我无法回答”则视为失败。4.3 系统延迟与成本这个架构需要多次模型调用一次大模型规划 N次小模型执行总延迟是各步骤之和。大模型API调用也产生费用。优化方向缓存与复用对于常见的任务类型如“分析报告”、“数据提取”可以将大模型生成的优质计划模板缓存起来下次类似任务直接复用或稍作修改省去每次规划的耗时和费用。并行执行分析步骤间的依赖关系。对于没有依赖关系的步骤可以并行调用小模型执行缩短总时间。小模型批量处理如果多个步骤都是同一种能力如都是“文本摘要”可以考虑将输入批量发送给小模型提高吞吐量如果小模型支持。4.4 适用任务边界的界定不是所有任务都适合用这种方法。它的优势在于逻辑分解明确、子任务定义清晰的任务。非常适合的任务类型信息提取与整合从多篇文档中提取特定信息并填入固定格式的表格或报告。分步决策例如先让模型判断用户意图分类再根据意图查询知识库检索最后组织回答生成。代码生成辅助大模型规划程序模块和函数接口小模型代码专用模型填充函数内的具体实现代码。不太适合的任务类型高度创意性任务如写一首意境深远的诗、生成一个完全虚构的精彩故事。这类任务难以被分解为确定性的子步骤。强推理链任务如复杂的数学证明、逻辑谜题。虽然可以分解但每一步的推理深度可能仍然超出小模型能力且错误传递效应极强。实时性要求极高的任务由于多次调用带来的延迟不适合对话等实时交互场景。5. 进阶思考从“脚手架”到“AI代理”的演进“搭脚手架”模式可以看作是构建复杂AI代理AI Agent的一种特例或初级阶段。当你把这个模式玩熟之后自然会产生更进阶的需求。5.1 引入工具调用小模型的能力不仅是文本生成还可以是调用外部工具或API。例如步骤1大模型规划“需要查询北京明天的天气”。步骤2协调器不调用小模型而是调用一个天气查询API获取结果。步骤3大模型规划“将天气信息整合到出行建议中”。步骤4调用小模型根据API返回的天气数据生成出行建议文本。 这样系统的能力边界就从“文本处理”扩展到了“连接现实世界”。5.2 动态规划与反思更高级的Agent具备“反思”能力。在上述基础架构上可以增加观察步骤执行结果在执行完每个步骤后将结果反馈给大模型。动态调整计划大模型根据当前结果判断原计划是否可行是否需要调整后续步骤。例如小模型实体识别结果为空大模型可以决定换一种方式提问或者跳过该步骤。最终结果验证任务完成后大模型可以对最终输出进行质量评估如果不合格可以触发新一轮的规划-执行循环。5.3 多专家小模型协作不一定只用一个“小模型”。你可以准备多个各有所长的小模型模型A擅长代码生成。模型B擅长SQL编写。模型C擅长文本润色。 大模型作为“调度中心”根据任务步骤的不同将子任务分派给最专业的那个小模型执行。这样就在保持低成本的前提下实现了“专家会诊”的效果。6. 总结什么时候该用这个方案经过上面的拆解你可以清晰地看到这种方法的全貌和复杂性。它不是一个“一键提升”的魔术而是一套需要精心设计的系统工程。我建议在以下场景优先考虑此方案核心模型无法微调你使用的闭源小模型或硬件受限无法进行权重更新。任务复杂但可分解你的任务有清晰的结构可以被拆解为一系列标准化的子任务。追求部署轻量化你希望最终服务只依赖一个轻量级的小模型将主要的成本和复杂度放在服务端的“协调器”和大模型调用上。需要快速原型验证你想测试一个复杂AI工作流的可行性又不想在训练模型上投入大量时间。反之在以下场景传统微调或直接使用更强模型可能更简单有效任务单一且固定你就想做好一件事如客服分类且有足够的标注数据微调一个专用小模型效果更好、延迟更低、成本更可控。对延迟极其敏感多次模型调用的延迟叠加无法满足业务要求。追求极致效果任务效果的天花板由模型本身能力决定“脚手架”模式无法突破小模型的知识和推理上限。最终技术选型没有银弹。这种“推理阶段能力迁移”的思路为我们提供了一种灵活、低成本扩展小模型应用边界的新武器。它的价值不在于替代大模型或微调而在于增加了一种架构上的选择。当你手里只有一把锤子小模型时别忘了可以请一位设计师大模型来告诉你怎么用这把锤子更高效地完成复杂工作。