最近在做大模型推理任务时我经常遇到一个困惑同样一个 Prompt大模型在数学题上表现出色但在涉及常识推理、多步逻辑时却经常一本正经地给出错误答案。更麻烦的是你让它“反思”一下它往往意识不到自己哪里错了反而会为错误答案编出更完整的解释。这种“无法自知”的推理缺陷是当前纯靠大模型自校正方案的一个天花板。最近读到 CritICL 这个思路让我有了一种豁然开朗的感觉。它的核心思想非常反直觉用一个小模型的错误来提升大模型的推理能力。不是让大模型自我反思不是用大规模微调也不是引入外部知识库而是把“犯错的小模型”作为一种校准信号放进大模型的上下文里。这篇文章我想围绕 CritICL 聊几个问题它解决的是什么痛点背后的原理为什么成立如何设计一个最小可复现的实验来验证这个思路以及在工程落地时有哪些需要注意的坑。如果你正在做大模型推理优化、Prompt 工程或者在做端侧小模型与大模型协同的方案选型这篇文章应该能提供一个新视角。1. 这篇文章真正要解决的问题先泼一盆冷水大模型的推理能力远没有很多人想象的那么稳定。你可以做一个简单的实验。拿同一个数学应用题换个数字、换个名字模型的输出正确率可能就会有明显波动。再尝试让模型做“A 比 B 高B 比 C 高谁最高”这类简单的传递推理大模型有时依然会绕进去。更令人头疼的是当你让大模型自我纠错时它经常出现一种情况第一次回答是错的你告诉它“再想想”它重新推理一遍给出了另一个错误答案甚至它会坚持原来的错误并补充更多看似合理但实际无效的论证。这说明一个关键问题推理错误不等于知识缺失大模型在推理链的某个环节产生了系统性偏差。这种偏差不是靠“多问几遍”就能消除的。过去大家的解决路径主要有两条微调用高质量推理数据对大模型做有监督微调。效果好但成本高而且容易让模型过拟合到特定数据模式。复杂 Prompt 设计比如 Chain-of-Thought、Self-Consistency、Self-Refine。这些方法有一定效果但都依赖大模型自己发现错误、纠正错误的能力。CritICL 走的是第三条路引入外部的小模型作为“批评者”让它的错误成为大模型的上下文线索。从方法名称来看CritICL 可以拆解为 Critic ICL。ICL 是 In-Context Learning也就是上下文学习让模型通过示例来学习任务模式而不是更新参数。Critic 则是指扮演批评者角色的模型。合起来理解就是把小模型在推理任务上的“犯错模式”作为一种上下文提示输入给大模型帮助大模型避开同样的坑。这个思路真正降低的是“推理校准”的成本。你不需要重新训练大模型也不需要准备高质量的正例数据只需要用小模型在同样任务上产生一批错误样例就能让大模型在推理时更谨慎、更准确。因此以下三类读者最应该关注这个思路正在做 Prompt 工程但发现大模型自反思效果不稳定的人需要在本地或端侧部署小模型希望用小模型辅助大模型、而不是替代大模型的人对大模型推理错误分析感兴趣想理解“错误信号”如何变成训练或提示价值的人。2. CritICL 的核心概念与适用场景2.1 什么是 ICL大模型最常用的推理方式在进入 CritICL 之前需要先把 ICL 讲清楚。ICL全称 In-Context Learning中文通常叫上下文学习。它的含义是不修改模型参数通过在输入文本中提供若干示例demonstrations让模型理解当前任务并完成推理。举个例子你希望大模型判断一个句子是积极还是消极。传统做法是训练一个分类器但 ICL 的做法是在 Prompt 里写句子这家餐厅的菜很好吃。 情感积极 句子排队等了一个小时太糟糕了。 情感消极 句子电影节奏太慢看得想睡觉。 情感大模型会根据前面几个示例的模式自动补充输出“消极”。ICL 的优点是灵活、不需要训练缺点是它对示例的质量和排列顺序非常敏感。同一个任务换一组示例准确率可能出现 10 个点以上的波动。这也是 CritICL 想介入的地方它试图把示例从“正确答案”扩展到“错误答案”让模型从正反两个方向理解任务边界。2.2 CritICL 不是让你用小模型替代大模型CritICL 字面上是“用小模型提升大模型”但它的本质不是“蒸馏”也不是“模型融合”。蒸馏的思路是大模型产出高质量答案用来训练小模型让模型变强。方向是大到小。CritICL 的方向是小到大小模型在推理任务上犯错把这些错误样本以某种形式组织成上下文提醒大模型注意容易出错的地方。小模型不是老师而是“反面教材”。这里有一个容易被误读的点CritICL 并不是把小模型的输出直接作为正确答案给大模型而是把错误特征告诉大模型。假设小模型在解决“甲乙两地相距 120 公里两车相向而行……”这类行程问题时经常犯“把相对速度算成速度差”的错误。CritICL 的思路不是拿小模型的错误答案去教大模型而是把这种错误类型归纳成提示信息例如“过去的小模型在这个任务上经常混淆相对速度和速度差”让大模型在推理时主动检查这一步。这就解释了为什么小模型的错误反而有价值错误往往比正确包含更丰富的边界信息。正确样例告诉你“怎么做是对的”错误样例告诉你“哪里容易做错错误长什么样”。对大模型来说后者常常是更好的推理校准信号。2.3 适用场景复杂推理与鲁棒性要求高的任务从方法原理推断CritICL 风格的方法最适合以下几类场景场景说明为什么 CritICL 风格有效数学应用题需要多步计算容易在中间步骤出错小模型能覆盖大量典型错误模式帮助大模型绕开多跳推理需要把多个事实连接起来得出结论错误往往出现在跳转过程中小模型的错误可以作为警示逻辑推理涉及条件判断、排除法、蕴含关系大模型的“想当然”被小模型的错误样本打破少样本分类类别边界模糊容易混淆错误样例补充了“不像什么”的信息端侧辅助推理端侧小模型先跑推理云端大模型做校准工程架构自然契合小模型成本低大模型只做二次判断值得注意的是CritICL 不太适合那些任务本身模糊、没有明确对错边界的场景。比如开放式的文本生成、创意写作这类任务没有标准答案“错误”的定义本身就不稳定用小模型的错误去提示大模型的意义就大打折扣。3. 为什么“错误”能被用来提升大模型推理3.1 大模型的推理为何会失败要理解 CritICL 的有效性必须回到一个根本问题大模型在推理时为什么会犯错当前主流的大模型本质上是一个“下一个词预测器”。它在生成答案时并不是像人类一样先列出所有已知条件、再逐步推导而是在每一步生成时根据前面的 token 序列做概率采样。这意味着模型的推理过程是一个“逐步生成”的过程前一步的偏差会累积模型倾向于生成“看起来合理”的文本而不是“逻辑上严格正确”的推理链当问题中存在迷惑性信息时模型可能会被高频共现的模式带偏。举例来说问大模型“一个池塘里有一片睡莲每天面积扩大一倍30 天覆盖整个池塘问覆盖一半需要多少天”很多模型会给出 15 天但正确答案是 29 天。原因就是模型在文本中见过太多“一半 除以 2”的模式而没有真正执行“倒推”的推理步骤。这种错误类型很难通过“再想想”来修复因为模型并不知道自己在哪里跑偏了。3.2 小模型错误的信息量错误的比正确的更具体这里要引入一个信息论视角的观察。正确样本的模式是相对单一的一个正确的推理链通常遵循固定的逻辑规则差异不大。但错误样本的模式是多样化的有的错在条件读取有的错在计算有的错在逻辑跳跃有的错在概念混淆。因此一组高质量的错误样本实际上为模型提供了更丰富的“决策边界”信息。它告诉模型不仅要学会正确的推理路径还要识别哪些路径是常见陷阱。小模型在这方面有一个天然优势它的能力上限决定它会犯更多、更典型的错误而这些错误往往和大模型的错误有重叠。因为小模型和大模型在训练数据、训练方式上有相似之处小模型暴露出的推理盲区很可能也是大模型的潜在弱项。这就像老司机带新手时最有价值的不是教新手怎么正确转弯而是告诉新手“这个路口经常有人压线、那个弯道容易冲出去”。正确操作是标准化的但错误操作却是需要预防的。3.3 CritICL 的工作机制从错误信号到上下文校准从方法设计的角度CritICL 应该包含以下几个关键环节在一个推理任务上使用一个小模型进行批量推理收集小模型的错误输出并整理成结构化的批评信息例如错误类型、错误片段、错误原因在给大模型的 Prompt 中加入这些批评信息作为上下文大模型在接收到“带有错误提醒”的上下文后进行推理输出答案。这里的关键点在于错误信息不是简单堆叠而是需要被组织成对大模型“可读、可用”的提示。比如在回答以下问题之前请注意一个小的辅助模型在这个任务上经常犯以下错误 1. 把“相对速度”直接计算为两个速度之差 2. 忽略题目中“相向而行”的条件而当成“同向而行” 3. 在计算 24 小时制时间差时没有考虑跨天的情况。 请避免重复上述错误。这种提示方式不是告诉大模型“正确答案是什么”而是告诉它“哪些坑不要踩”。从推理效果来看这种负面提示有时比正面示例更能提升模型的警惕性。但要谨慎说明CritICL 的具体提示构造方式和实验设置目前公开材料中细节有限。以上是基于方法名称和 ICL 机制做的合理推导实际复现时需要根据任务类型设计自己的错误提示模板。4. 最小可复现实验环境准备与基础流程如果你看完上面的分析想亲手验证“错误提示”对大模型推理的影响可以按下面这个最小实验方案来跑。这个实验不需要大规模算力也不需要训练模型只需要调用现成的推理接口。4.1 环境准备建议使用以下环境搭配Python 3.9 及以上OpenAI SDK 或兼容的模型 API如 vLLM、Ollama 本地部署的模型接口pandas用于数据整理一个小模型如 7B 级别的开源模型和一个大模型如 70B 级别或商业 API 模型。如果你在本地部署模型推荐使用 vLLM 或 Ollama 作为推理框架。vLLM 适合高吞吐量的服务化部署Ollama 更适合快速做单机实验。参考最近社区的热度Ollama 在本地部署私有大模型时很方便但如果你需要批量跑几千条评测样本vLLM 的吞吐量优势会更明显。如果你不希望自己部署模型也可以使用 API 方式调用不同规模模型的接口。实验重点在于“对比大小模型在同一任务上的错误模式”因此只要能稳定调用两类模型即可。4.2 任务选型从数学应用题开始推荐第一个实验任务选“数学应用题”。原因有三有标准答案正确率容易衡量小模型和大模型在数学推理上的差距明显错误样本量大容易观察效果错误类型相对集中容易归纳出有意义的“警示信息”。你可以从公开数据集中选取一批小学或初中数学应用题也可以自己构造 50 道。如果自己构造建议控制变量题干结构相近、条件数量一致、但数字和场景不同。4.3 实验流程设计整个实验流程可以分成五个步骤下面提供一个参考实现。第一步用小模型跑原始推理# 文件路径run_small_model.py # 目的让小模型在测试集上完成推理收集输出 from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, # vLLM 服务地址 api_keyEMPTY ) def get_model_answer(client, model_name, question): response client.chat.completions.create( modelmodel_name, messages[ {role: system, content: 你是一个数学解题助手请逐步推理并给出最终答案。}, {role: user, content: question} ], temperature0.3, max_tokens512 ) return response.choices[0].message.content questions [ 甲乙两地相距 120 公里一辆汽车从甲地出发每小时行驶 60 公里另一辆汽车从乙地出发每小时行驶 40 公里。两车相向而行几小时后相遇, # 更多题目... ] small_model_name Qwen2.5-7B-Instruct for q in questions: answer get_model_answer(client, small_model_name, q) print(题目, q) print(小模型输出, answer) print(---)这段代码的核心是用小模型批量跑测试题并保存输出结果。记住这一步不需要任何特殊设计只需要让小模型自由发挥。第二步标注错误并归纳错误类型拿到小模型的输出后需要人工或半自动地对错误答案进行标注。{ question: 甲乙两地相距 120 公里一辆汽车从甲地出发每小时行驶 60 公里另一辆汽车从乙地出发每小时行驶 40 公里。两车相向而行几小时后相遇, correct_answer: 1.2 小时, small_model_answer: 2 小时, error_type: 相对速度计算错误, error_description: 小模型直接将两车速度相加得到 100 公里/小时忽略了相遇问题的核心是两车相向而行相对速度为两速之和。本次错误在于计算时使用了速度差。 }建议至少归纳 5 到 10 类高频错误。常见错误类型包括单位换算错误关键条件遗漏公式使用错误中间计算结果错误逻辑跳跃跳过必要步骤问题理解偏差答非所问。第三步构造 CritICL 提示这是整个方法的核心环节把错误类型转换成大模型能理解、能参考的上下文信息。# 文件路径build_prompt.py # 目的基于小模型的错误类型构造 CritICL 提示模板 ERROR_PROFILE 在回答以下数学应用题之前请注意 一个辅助小模型在处理类似问题时经常犯以下错误 1. 相对速度计算错误把相向而行的速度错误地计算为速度差而不是速度和 2. 单位转换遗漏在速度单位为“公里/分钟”或“米/小时”时忘记统一单位 3. 中间步骤跳步在两步计算中省略中间结果导致最终结果错误 4. 条件读取遗漏忽略题干中“同时出发”或“途中停留”等关键条件。 请严格按照题目条件逐步推理避免上述错误。 def build_critic_prompt(question): return f{ERROR_PROFILE}\n\n题目{question}\n\n请给出你的推理过程和最终答案注意这段提示的设计思路不是告诉模型“正确答案是多少”而是告诉它“在哪个环节容易出错”。这是一种预防性提示目的是让模型在推理时保持对特定环节的警惕。第四步对比实验与结果记录分别用三种方式让大模型回答问题并记录准确率直接提问Baseline加入正确的示例标准 ICL加入 CritICL 错误提示。# 文件路径evaluate.py # 目的对比不同提示策略下大模型的推理准确率 import json results [] def evaluate_baseline(client, model_name, question): messages [ {role: system, content: 你是一个数学解题助手请逐步推理并给出最终答案。}, {role: user, content: question} ] response client.chat.completions.create( modelmodel_name, messagesmessages, temperature0, max_tokens512 ) return response.choices[0].message.content def exact_match(prediction, answer): return answer.strip() in prediction # 假设 answers 是标准答案列表 for i, q in enumerate(questions): pred evaluate_baseline(client, large_model_name, q) results.append({ question: q, prediction: pred, correct: exact_match(pred, standard_answers[i]) }) with open(results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)这里的关键是保持其他变量一致只改变 Prompt 中的提示内容。这样得出的准确率差异才能归因于错误提示的引入。第五步批量跑分与可视化建议把三种策略分别跑 3 遍取平均准确率以减少随机性。# 批量运行三种评测策略 python evaluate.py --strategy baseline python evaluate.py --strategy standard_icl python evaluate.py --strategy criticl然后整理成表格观察准确率变化。4.4 实验预期根据我的判断这个实验最可能出现的结果是CritICL 策略下大模型在数学推理任务上的准确率会高于直接提问与标准 ICL 相比CritICL 在错误类型集中的任务上表现更有优势在小模型和大模型能力差距越大时CritICL 的增益通常越明显。如果实验没有出现预期效果优先检查两点一是小模型的错误归纳是否准确二是错误提示是否被大模型真正“读进去”了。有时候大模型会把错误提示当作背景噪声忽略掉这种情况下可以尝试把错误提示的措辞改得更直接比如“你之前的模型经常在此类题目上犯错请特别注意”。5. 在真实项目中如何接入 CritICL 思路上面的实验是一个最小验证。如果在真实项目中要落地这套思路还需要考虑几个工程问题。5.1 小模型选型不是越弱越好很多人会误以为“既然是利用小模型的错误那模型越弱错误越多信息量越大”。这个判断是片面的。如果小模型太弱它的错误会变成“瞎猜”错误类型非常随机无法归纳出有意义的模式。比如一个 1B 模型连题目都读不懂它的错误对 70B 模型没有任何参考价值。从工程经验判断推荐选择比大模型弱 1 到 2 个能力档次的小模型。比如大模型用 70B 级别小模型选 7B 级别大模型用 7B 级别小模型选 1.5B 级别。这样的小模型既能稳定产出可归纳的错误模式又不会弱到毫无信息量。这里也可以结合“端侧大模型”的思路来理解。现在很多人讨论在手机、嵌入式设备上部署小模型一个典型场景就是端侧小模型先做初步推理云端大模型做最终决策。CritICL 正好可以为这种架构提供一个数据流设计端侧小模型的失败样本可以作为云端大模型的输入特征。5.2 错误库的建设与更新CritICL 在工程上需要维护一个“错误库”类似知识库的角色但存储的不是知识而是常见错误模式。建议按以下结构维护{ task_type: math_word_problem, error_clusters: [ { error_id: ERR-001, error_type: relative_speed_miscalculation, description: 相向而行时把相对速度算成速度差, example: 题目...小模型输出..., trigger_conditions: [题目出现相向而行, 题目出现同时出发], suggestion: 先判断运动方向再确定相对速度是速度和还是速度差 } ] }在实际项目中这个错误库需要定期更新。因为小模型如果被微调或替换它的错误模式也会变化。更合理的做法是建立一个自动化流水线周期性用小模型跑一批新样本自动对比标准答案筛选错误样本对错误样本做聚类生成新的错误模式描述更新 Prompt 模板中的错误提示。这个过程可以借鉴异常监控的思路把错误库当作一个“模型推理质量监控”的副产品。每次上新版本的小模型或大模型时都重新跑一遍错误采集避免旧错误库失效。5.3 与已有推理框架的集成如果你已经使用 vLLM、Ollama 等推理框架部署了大模型CritICL 思路并不复杂。你只需要在调用大模型之前动态拼接 Prompt 即可。一个典型的实现是在 API 层加一个中间件拦截推理请求在原始问题前插入错误提示模板。# 文件路径middleware.py # 目的在推理请求中自动注入 CritICL 提示 from fastapi import FastAPI, Request app FastAPI() ERROR_PROMPT_TEMPLATE 下面是辅助模型在类似任务上常犯的错误\n{error_profile}\n\n请避免上述错误并回答问题。\n\n题目{question} app.post(/v1/chat/completions) async def chat_completion(request: Request): payload await request.json() messages payload.get(messages, []) # 在最后一条用户消息前插入 CritICL 提示 if messages and messages[-1][role] user: question messages[-1][content] error_profile get_error_profile(question) # 根据问题类型获取错误库 messages[-1][content] ERROR_PROMPT_TEMPLATE.format( error_profileerror_profile, questionquestion ) return await forward_to_llm(payload)这种中间件方式的好处是对上层业务完全透明。业务方不需要知道 CritICL 的存在仍然以普通 Chat API 的方式调用但实际请求中已经注入了错误提示。不过要注意这个方案的代价是 token 消耗增加。错误提示模板如果太长会挤占输出空间同时增加推理延迟和成本。因此建议错误提示控制在 150 到 300 字之间挑选最典型的错误类型而不是把所有错误都堆进去。6. 换个角度看错误的规模化效应前面讲的都是如何利用小模型的错误但 CritICL 的启发可以延伸到更广的范围。6.1 错误互补性不同小模型的错误模式不同如果只使用一个小模型它的错误模式是相对固定的。但如果同时使用多个不同架构、不同训练数据的小模型它们的错误模式会有互补性。举例来说模型 A 在计算单位换算时容易出错模型 B 在条件读取时容易遗漏模型 C 在逻辑推导时容易跳步。把这些不同模型的错误特征合并起来就能形成一份更完整的“避坑指南”。这比只用单个小模型的错误更有价值。从某种程度上说这和小模型集成ensemble的思路相反。传统集成是让多个模型投票得出正确答案而 CritICL 风格的做法是让多个模型的错误叠加出“完整的陷阱地图”然后交给大模型去规避。6.2 与模型微调的协同CritICL 不需要微调模型但它的产出可以为微调提供数据。具体来说通过对小模型错误模式的归纳可以得到训练大模型的负样本。构造一批“错误推理链 正确推理链”的对比数据微调后的大模型会更容易学会区分正确与错误的推理步骤。这两种方式的适用场景不同方案成本效果持续性适用场景CritICL 提示低只消耗推理 token即时生效但依赖 Prompt 设计质量快速上线、任务频繁更换负样本微调高需要训练资源持久改进模型参数固化核心任务、长期稳定运行在实践中建议先用 CritICL 做一个快速验证如果发现错误库里的模式足够稳定、收益足够明显再考虑把高价值的错误模式转化成训练数据进一步微调。7. CritICL 与常见大模型推理优化方案的对比为了帮你更清楚地定位 CritICL我用一个表格对比它和其他常见方案的区别。对比维度CritICL标准 ICLSelf-Refine微调是否更新模型参数否否否是依赖外部模型是依赖小模型否否否核心信号来源小模型的错误人工标注的正确示例大模型自身的批评人工标注的推理数据主要成本小模型推理 token 消耗示例设计和 token 消耗多次推理的 token 消耗训练资源和数据标注成本对大模型“自知力”的依赖低不要求大模型发现自己错误低高需要模型发现并纠正低可解释性较高错误类型清晰中中低项目落地难度中需要建错误库低低高从这个表可以看出CritICL 最独特的定位是它是唯一一个把“外部模型的错误”作为核心信号、同时不要求大模型具备自我反思能力的方法。这一点在工程上很有意义因为目前很多开源大模型的自我反思能力并不可靠。它和 Self-Consistency多次采样投票也可以做对比。Self-Consistency 的思路是“让大模型多答几次多数胜出”它假设正确答案是稳定的、可重复的。但 CritICL 的思路更接近“在推理前先打预防针”它不依赖重复采样因此推理成本更低。8. 常见问题与排查思路8.1 错误提示没有提升大模型准确率这是最可能遇到的问题。问题现象可能原因排查方式解决方案加了错误提示后准确率没有提升小模型的错误和大模型不相关对比大小模型在同一组题目上的错误分布更换与目标大模型行为更接近的小模型准确率反而下降错误提示干扰了大模型原本正确的推理检查错误提示是否过于泛化缩短提示只保留高频、典型错误大模型忽略了错误提示提示位置太靠后或语气不够强观察 Prompt 长度和大模型注意力分布把错误提示放在问题之前并加粗关键句效果不稳定错误库覆盖的题型与当前测试集不匹配分析测试集题型的分布按题型拆分错误库动态匹配8.2 错误归纳不准确如果人工标注的错误类型有误错误提示就会变成误导信息。建议在标注环节增加一道“校验”步骤让大模型先基于错误提示做一次推理人工检查推理过程是否确实规避了对应错误。如果模型依然犯错说明错误类型的描述还不够精准需要重新归纳。还可以尝试用另一个大模型来辅助归纳错误类型形成“小模型犯错 - 大模型归纳错误 - 目标大模型参考错误提示”的流水线。8.3 Token 消耗过高错误提示模板虽然不长但在批量场景下累积消耗也会很可观。优化方式有三种压缩错误提示每条错误只保留一句关键描述使用缓存同类型题目复用同一个错误提示模板只对高难度题目启用错误提示简单题目直接提问。8.4 小模型迭代后错误库失效这是项目长期运行中最容易踩的坑。团队可能会定期更新小模型版本新模型的能力更强、错误更少但错误模式也变了。如果错误库没有同步更新旧提示可能不再适配甚至成为噪声。建议在小模型的版本发布流程中加入“错误库回归测试”环节新模型上线前用旧错误库跑一批样本评估错误库的覆盖率是否仍然达标。9. 工程落地最佳实践9.1 从离线实验开始不要直接上线任何 Prompt 策略的改动都不建议直接上生产。原因很简单Prompt 的效果具有很强的任务相关性离线实验的结果未必完全代表线上表现但至少能提供一个基准。建议流程构建包含 200 到 500 条样本的评测集分别记录 Baseline 和 CritICL 的准确率、延迟、token 消耗如果准确率提升超过 3 个点才考虑灰度上线线上运行一周后重新采样评测确认效果稳定。9.2 记录每一次推理的错误特征推理监控是 CritICL 落地的重要一环。每次大模型推理后建议把以下信息记录下来问题文本是否使用了错误提示使用了哪几条错误提示大模型输出是否正确如果错误错误类型是否与提示中的某个错误类型匹配。这些数据能帮助你持续优化错误库也能用来评估错误提示的动态效果。9.3 安全与隐私边界如果 CritICL 思路用于包含用户隐私或敏感数据的场景需要注意小模型推理产生的错误样本可能涉及用户数据不适合直接存入外部错误库错误库建议存储在内部环境并由专门的数据治理策略管理在将错误提示拼入 Prompt 时避免引入任何可识别个人身份的信息对生产环境的 Prompt 变更务必做好版本记录便于回滚。9.4 与本地部署方案的结合如果你正在考虑本地部署大模型CritICL 思路可以带来一个额外收益降低对大模型“单次推理质量”的依赖。本地部署时受限于算力通常不能运行超大模型模型的推理能力会打折扣。这时候引入一个小模型错误提示相当于在提示层面做了一次“能力补偿”不需要额外算力却有希望提升推理准确率。具体操作上如果本地使用 Ollama 部署大模型只需在调用前拼接错误提示文本即可。不需要修改模型文件也不需要重新加载模型。10. 总结这是一个值得投入的方向CritICL 的价值不在于它多么复杂而在于它提供了一个反直觉但合理的优化视角错误本身也可以是一种高质量的训练和提示信号。在真实项目中如果你想验证这个思路我的建议是从一个最小实验开始选择一个你手头准确率在 70% 到 85% 之间的推理任务用一个弱一档的小模型跑一批题目人工归纳出 5 到 10 条常见错误把错误提示拼入大模型 Prompt对比准确率变化。如果实验结果正向再考虑把错误库工程化、自动化。如果实验效果不明显也不用急着否定这个方向先检查错误归纳质量和小模型选型是否合理。大模型推理优化还有很多值得探索的路径。CritICL 代表的“小模型辅助大模型”只是一类方法沿着这个思路继续深入你还可以尝试多小模型错误互补、错误库自动更新、错误提示动态选择等进阶方向。希望这篇文章能给你一些启发也欢迎在评论区交流你的实验结果和踩坑经历。