先还原一个经常遇到的场景你已经把大模型接进了项目用它做数学题、做逻辑判断、做代码片段生成但在某类需要多步推理的任务上它总是会在某个不起眼的环节悄悄出错。你试着换更长的提示词试着加更多示例甚至换更强的模型版本结果可能只是“这次对了下次又错”。这个时候有人提了一句“要不要先用一个小模型故意犯几个错再把错误结果喂给大模型看”我第一反应是这像绕路但深入研究后我发现这其实是一条被低估的优化路径。CritICL 的核心思路就是利用小模型的错误来提升大模型的推理能力。这里的重点不是“小模型很弱”而是把错误变成一种可观察、可利用的信号。CritICL 这个名字可以拆成“Critic”和“ICL”一个是批判、审视一个是 In-Context Learning上下文学习。合在一起就是借助批判性信息来增强大模型在上下文中的推理表现。而这个“批判性信息”往往可以从小模型的失败中获取。小模型的推理能力不如大模型但它出错的方式往往更集中、更可预测。把这种错误直接放进提示词相当于主动告诉大模型“你看这种推理路径有问题请绕开”。真正值得思考的不是“小模型为什么错”而是“大模型为什么能从错误中得启发”。这是这篇博客想讲清楚的主线。1. 为什么“用小模型错误提升大模型推理”听起来反直觉却很有道理很多人第一次听到这个方向时都会有一个疑虑小模型能力不如大模型它犯的错大模型难道不会犯吗如果大模型自己都能正确推理为什么还需要看小模型的错误这个疑问表面合理但忽略了一个关键区别大模型经常不是没有能力而是缺少对“危险路径”的感知。1.1 推理错误并不总是能力不足有时候是路径惯性想象一个人走迷宫。大模型像是一个跑得很快的人它记忆力好规则也懂但在一处岔路口它会按照最习惯的方向走。如果这个习惯方向在多数题目里是正确的那么它不会每次停下来检查。只有当它提前看到“这条路前面有个坑”的警告时它才更容易换一条路。小模型的错误就扮演了这个警告。小模型因为参数量少、模式记忆有限往往会在更基础的位置暴露问题。比如在数学推理中小模型更容易在步骤间跳跃更容易错误套用公式更容易把题目里的一个数字提前挪到不相关的步骤里。这些错误很“幼稚”但大模型在长上下文里也会犯同样的幼稚错误只是出现频率更低更隐蔽。所以 CritICL 能起到的作用不是教大模型“什么是正确答案”而是帮大模型建立“什么样的情况不能按惯性走”的敏感性。1.2 错误本身带有结构信息如果你只给大模型一个正确答案的推理链它能学会“正确答案长什么样”。但如果你给它的是一组“错误推理 错误点定位 修正方向”它就能学到“哪一步是关键岔路为什么这里容易偏”。这就像学写作。只看范文能学会规范表达但进步往往是有限的如果同时看到一篇问题作文旁边有人标注“这里偷换了概念”“这里论据撑不住结论”你对写作结构的理解会深很多。CritICL 的思路正是如此用小模型的错误制造一批“反面示范”让大模型在上下文里同时看到正反两面。它不是靠更多示例堆出准确率而是靠错误信息构造出更清晰的决策边界。1.3 真正有价值的不是错误本身而是错误的显著性不过这里有一个容易被误解的点不是所有小模型错误都有价值。如果一个错误毫无理由或者只是单纯胡编乱造大模型看了也不会有收获。有价值的错误是有显著性的错误最好具备这几种特征错误发生在推理链的关键转换点而不是随机乱写。错误能够被定位能说清楚是计算错、逻辑错还是前提误用。错误不是完全离谱而是看起来像一条“可能被采用的推理路径”。所以“用小模型错误提升大模型推理”这个思路本质上不是在用错误本身而是在利用错误暴露出来的决策风险。大模型从这些风险点上得到提醒从而在真正面对类似题目时更谨慎。2. CritICL 的方法逻辑小模型产生错误大模型完成批判与修正把思路落到工程实现上可以拆成三个阶段。第一阶段是用小模型生成错误样本第二阶段是构造批判性上下文示例第三阶段是让大模型在推理时参考这些示例。这三个阶段不是固定的代码流程更像是一套可迁移的处理框架。2.1 第一阶段用小模型制造“错误样本库”首先准备一批代表性的推理任务。这些任务可以先从小样本开始比如 20 到 50 条。每一条任务都不要只让小模型生成一次答案最好生成多次因为小模型在不同采样温度下会产生不同类型的错误。实际落地时我会这样处理使用同一个任务让模型在不同 temperature 下生成结果。从结果中筛选出“推理链完整但与正确答案不一致”的样本。过滤掉那些非常离谱、完全没有逻辑的样本。把剩下的错误按类型归档计算错误、逻辑跳跃、前提误用、上下文遗忘等。这里不需要追求错误样本数量巨大。在常见实践里每个任务类型如果有 3 到 5 个高质量的错误示例已经能对大模型形成比较稳定的提示效果。关键是错误样本的质量而不是数量。2.2 第二阶段把错误样本加工成“批判性上下文”拿到小模型的错误输出后不能直接把它塞进大模型的提示词里。直接给一个错误答案大模型不一定知道该怎么利用。你需要加工成三层结构原始任务让大模型知道要解决什么问题。小模型的错误解答展示一条不完整或有问题的推理路径。批判和修正标注明确指出错误发生在哪一步以及正确方向是什么。这种结构的本质是让上下文从“看例子的答案”变成“看你自己的可能错误路径”。大模型在生成时会不自觉地调用这个批判性信息对自己的推理过程做一次内部检查。一个比较常见的提示结构长这样任务题目内容…… 一个可能但不完整的推理过程 [这里放入小模型的输出包含错误步骤] 请指出上述推理中的问题并进行正确推理。如果是更精细的做法可以在错误步骤后用括号或注释标出“这一步将题目前提中的数值错误扩展到了最终计算”。2.3 第三阶段用批判性上下文驱动大模型推理把加工后的上下文放到大模型的实际推理提示词里。这里的核心不是“让大模型重新做一遍题目”而是让大模型在进入正式的生成步骤前先理解“错误路径长什么样、为什么错、该往哪里改”。用我自己的体验来说大模型在这种结构下更容易给出带自我怀疑的推理过程。它不会直接跳到结论而是会先检查一下是否有类似小模型犯过的路径。这个检查过程不一定会出现在输出里但它会影响到最终结果。如果你已经具备本地部署大模型的经验这个过程可以很直观地验证。部署一个中等规模的大模型不加入批判性示例让它做 50 道推理题再在同样的模型、同样的配置下加入批判性上下文继续让它做相同的 50 道题。你会发现有些题目结果没有变化但那些模型原本容易犯错的题目结果会更稳定。3. 实操路线从最小验证到批量使用中间隔着很多细节概念讲清楚之后最实际的问题是我自己该怎么跑通这个方案需要注意哪些地方这里我给出一个可复用的三步路线它适用于大多数人第一次接触 CritICL 这类思路时的情况。3.1 第一步用一个最小实验验证思路是否适合你的任务不要一上来就搭完整的批量系统。先选 10 到 20 条有代表性的推理题最好是你已经在项目中观察到大模型犯错的那一类。然后用小模型生成错误输出。人工检查这些错误输出挑出 5 条结构清晰的错误。把 5 条错误做成批判性上下文。让大模型在有批判性上下文的情况下重新生成这 10 到 20 条题目。这一步的目标不是立刻提升多少准确率而是确认一件事当前的错误样本是否能让大模型产生行为变化。如果大模型看了错误示例后输出几乎没有任何变化后面就不用继续了问题可能不在示例而在任务本身不适合这类方法。3.2 第二步把“单一提示词”升级成可对比的实验结构当最小验证有效后你需要把实验做得更规范。建议进行三组对比基线组只给任务不给示例。标准示例组给正确答案示例。批判性示例组给小模型的错误和修正说明。每组都使用相同的随机种子、相同的生成参数至少跑 3 次。记录三个指标正确率、推理链完整性、生成时间。这一步最容易被忽视但它恰恰决定了 CritICL 在你的场景里有没有真实收益。没有对比就无法判断提升是来自示例本身还是来自批判性信息的额外作用。3.3 第三步逐步扩展到批量任务但必须增加输出校验如果对比结果表明批判性上下文有稳定收益再考虑批量使用。批量使用不是简单地把单条提示扩展到几百条而是需要补上三个工程能力错误样本的缓存管理小模型生成的错误样本没必要每次重新生成可以落盘按任务类型和错误类型建索引。输出格式校验大模型生成推理过程时可能不按预期结构输出需要增加一层解析校验确认它真的完成了“指出错误 修正推理”两个动作。失败重试策略如果某次生成结果为空、超时或格式错误要能自动重试并记录失败原因。有人会觉得这些步骤只是在堆工程复杂度但事实是任何一个模型优化方案如果没有落到稳定的执行路径上就只能在演示环境里发光。4. 最容易踩的坑不是模型不够强而是提示设计走偏了真正做 CritICL 这类方案时你会发现最大的障碍不是本地算力不够而是上下文设计和错误样本选择出现偏差。下面这四类问题是我觉得最容易遇到的。4.1 错误样本太随机大模型无法形成模式认知小模型在低温度下会生成比较平淡但错误不明显的输出在高温度下又很容易生成胡说八道的内容。如果你直接把高温度下的随机输出当错误样本大模型很可能学不到任何结构信息只会认为整个任务很混乱。更合适的做法是用中等温度比如 0.7 到 0.9生成多次挑选那些“推理过程局部可读但最终结论错误”的样本。只有这种样本才有批判价值。4.2 批判说明过于简单大模型只能照猫画虎如果在错误输出后面只标一句“这是错的”那和大模型自己随机猜测没什么区别。批判信息需要具体到步骤。最好的标注方式是指出错误的类型。标明错误在推理链中的位置。提供正确的替换步骤。如果可能说明为什么容易在这里出错。比如“在第 3 步中把题干里的比例关系理解成了绝对数量导致后续所有计算基于错误前提。正确做法是先将比例转换为同一单位。”4.3 上下文长度被大量消耗导致核心推理空间不足批判性上下文会显著增加提示词长度。以前一个任务可能只需要 200 到 400 个 token加入错误示例和修正说明后可能直接涨到 1500 到 3000 个 token。这时候你要面对的就不再是语义问题而是资源问题。如果大模型的上下文窗口有限或者推理速度要求较高就需要限制错误示例数量或者对示例做摘要压缩。我在实际操作中一般会保留两条原则每个任务类型只放 1 到 2 条错误示例而不是越多越好。示例中只保留最核心的推理链删除无关的题面背景。4.4 忽略大模型自身的“越改越错”风险有了批判信息后大模型并不一定每次都往正确方向修正。它可能把原本正确的推理路径反而改成了错误路径。这就是为什么批量使用前必须做对比实验。如果发现某些题目在加入批判性示例后错误率反而上升那就说明这些题目不适合这种方法。适当情况下可以把“是否需要 CritICL 提示”做成一个分类器只对容易出错的题目应用批判性示例。5. 排查链路效果不佳时按顺序检查这四层如果你已经写了提示词也跑了小模型生成错误样本但大模型推理效果并没有提升别急着换模型。按下面这个顺序排查基本能找到问题所在。5.1 先看错误样本本身这一步看的是“错误样本是否有可学习的信息”。打开你的错误样本库逐条看错误是否可以被明确归因。错误是否出现在关键推理步骤上。修正说明是否和错误步骤严格对应。如果错误样本都是“看起来就毫无逻辑”的随机文本大模型是无法从中做上下文学习的。这个阶段的问题属于输入质量问题。5.2 再看批判性提示的结构是否清晰接着检查大模型实际收到的提示词结构。一个常见问题是错误样本和修正说明之间缺少明确的分隔符。比如你直接把小模型输出贴在任务后面然后又写一句“请重新推理”大模型可能分不清哪些是错误内容哪些是待办指令。建议用清晰的标签结构【错误推理过程】 …… 【问题定位与修正方向】 …… 【最终回答要求】 ……如果提示词结构含糊哪怕错误样本质量很高大模型也难以有效利用。5.3 再看生成参数和模型行为如果输入和提示结构都没有问题就要看生成参数。temperature 过高大模型可能不会老老实实参考上下文中的修正方向温度过低又可能过度模仿错误示例中的局部表达。另外不同模型对长上下文的关注程度不同。有些模型对中段信息较容易忽略你需要在测试时将错误示例放在离输入位置更近的地方或者通过换行、序号、重复强调等方式提高关键信息的显著性。5.4 最后看任务类型和测试集有些任务天然不适合通过错误示例来实现优化。比如任务本身需要大量外部知识而你提供的错误示例只是逻辑方向上的偏差大模型可能会因为缺少知识而继续犯错。更稳妥的做法是把你的测试集按错误类型分组计算错误类。逻辑跳跃类。前提误解类。上下文遗忘类。观察 CritICL 对哪类错误最有效然后把它应用在那些场景上。不要指望一个统一方案解决所有推理问题。6. 适用边界这种方法不是“万能推理增强器”任何技术方案都有边界CritICL 也不例外。把它讲清楚反而能避免你用错场景后得出错误结论。6.1 适合什么场景大模型在特定任务上已经能完成大部分题目但存在稳定、可复现的错误模式。你能够为错误样本编写高质量批判说明而不只是简单标注“错”。任务有比较明确的推理链条比如数学题、逻辑题、代码调试、复杂指令拆解。在这种场景下CritICL 相当于给大模型戴了一副“风险提示眼镜”让它更快识别自己容易走偏的地方。6.2 不适合什么场景任务本身没有可定位的推理链比如开放式创意写作。大模型在当前任务上错误率很高且错误模式五花八门小模型错误样本无法形成统一的上下文信号。上下文窗口非常有限加入批判性示例后核心题目反而被挤占。你需要的是实时推理每条请求对时延极度敏感而批判性示例增大了提示长度推理耗时明显上升。6.3 长期使用要注意什么如果要把 CritICL 思路持续用在生产环境而不是只在实验里跑一次那么你需要考虑错误样本库的维护问题。小模型版本升级后错误分布会变化。大模型版本升级后已有的批判性提示可能不再有效。任务分布发生变化后旧的错误样本也会失去代表性。所以更合理的做法不是把这套方法固化成一个静态提示词模板而是把它当成一个持续迭代的机制。每隔一段时间重新用小模型生成当前任务下的错误样本再用新的测试集评估批判性上下文是否仍然有效。7. 一个可复用的评估框架从“直觉上好像有效”到“数据上确实有效”很多人在尝试新的提示策略时容易止步于“某几次输出看起来更顺眼了”。如果你想让 CritICL 成为真正可靠的工程手段就必须有一套可量化的评估方式。我建议用一个五步评估框架它不高深但能帮助判断方案是否真的有效。明确目标题目集选出 30 到 50 道与生产场景一致的题目。记录基线表现用原始提示跑若干次记录准确率和错误类型分布。应用批判性示例在相同题目上加入 CritICL 提示保持其它参数不变。对比结果计算提升率、新引入错误数量、推理耗时变化。做小范围试用选择 5 到 10 道生产题目人工检查大模型输出的完整性和可靠性。这个框架适用于 CritICL也适用于其它上下文学习方案。它能帮你快速判断这是偶然的波动还是真正可复用的能力增强。在实际使用中我还会额外记录一条信息模型在生成结果时是否出现了“先复述错误路径再修正”的行为。如果模型经常这样说明批判性上下文确实在影响它的推理过程。如果模型从不提错误路径只是直接输出结果那也许方法有效但你也需要关注提示结构是否被模型忽视了。8. 回到本质这项技术真正改变的是人怎么和模型协作CritICL 让我觉得有价值的地方不只是它可能提升几个百分点的准确率而是它提供了一个新的协作思路我们不再要求模型“一次做到位”而是允许一个更弱的模型先暴露问题再由更强的模型基于问题修正自己。这种思路有点像项目评审。直接让新人写一份完整方案不如先让他写一版初稿再由资深同事指出关键问题、集中修改。初稿不是用来展示正确性而是用来暴露风险。大模型的推理过程也一样有时候错误信号反而比正确答案更有引导价值。如果你正在做模型推理优化我的建议是不要一上来就想着换更大参数量的模型。先整理一版当前模型最容易犯的错误再尝试用小模型生成一批可比较的错误样本把它们组织成批判性上下文最后观察大模型是否能从中获得新的判断依据。这个过程成本不高却能帮你理解一种更通用的能力怎样把模型暴露出来的问题转化成下一次推理时的约束条件。这不是说 CritICL 是唯一正确的路线也不是说它能替代微调、RAG 或更系统的后处理策略。但它确实打开了一个切入点在数据、参数之外提示本身还有更多信息可以向模型传递而我们过去往往只把提示当作“让答案更漂亮的面具”忘记了它也可能成为模型审视自己的镜子。