CritICL：用小模型的“错题集”提升大模型推理能力-北京尧图网络

在大模型推理任务里一个很常见的现象是小模型容易犯错大模型也不便宜。换更大的模型、堆更多提示词确实能提升一点效果但成本会快速上升。CritICL 的思路刚好反过来——先用小模型在推理任务上产生一批错误结果再把这些“错误样本”作为负例或批评信号注入到大模型的上下文提示中从而让大模型在推理时少犯同类错误。这篇文章会沿着“为什么有效——怎么搭最小实验——怎么调参——怎么排查——怎么工程化”这条主线把 CritICL 完整拆开。1. 先理解 CritICL 为什么值得做错误也是上下文信号1.1 上下文学习只喂正例忽略了错误模式上下文学习In-Context LearningICL是目前使用大模型最轻量的方式。它不更新模型参数只通过在 prompt 里放若干示例让模型理解当前任务要输出什么格式、走什么推理路径。传统做法通常会放“标准答案型示例”给一道题再给正确推理步骤和最终答案。这种正例能教会模型“应该怎么做”但很难覆盖“可能错在哪里”。一个训练有素的大模型在复杂推理场景中错误往往不是随机出现的。它可能集中在某类计算错误、条件误读、步骤跳跃或格式混乱上。如果提示中的正例数量很少模型只能模仿到表面格式无法避开隐藏的坑。比如在数学应用题中大模型常见错误是“忽略无关条件”或“过早四舍五入”这些错误模式在标准正例里根本看不到。1.2 CritICL 的核心思路用小模型生成“错题集”CritICL 的出发点是既然小模型成本低、采样方便而且它在同样任务上会出现一定比例的错误那我们完全可以把这些错误结果整理成“错题集”作为上下文中的负例。负例并不是说让大模型去模仿错误答案而是让大模型在看题之前先看到“这里容易出错、出错类型是什么”从而在生成过程中更自觉地避开这些路径。把这个思路技术化之后可以这样定义CritICL 是一种基于小模型错误信号增强大模型推理的上下文学习方法。它让一个规模较小、推理能力较弱的模型在目标任务上先推理筛出错误的输出再把这些输出连同错误说明一起加入大模型的 prompt。大模型不是从零开始猜而是在给定“错误模式地图”的条件下生成更可靠的推理路径。这背后有一个朴素但有效的类比一个学生只看标准答案进步速度有限如果同时看错题集知道某个知识点容易在哪里失分考试时会更加警惕。大模型在推理时也是类似负例能起到“路线避障”的作用。1.3 两条落地路线错误示例注入与错误批判生成CritICL 这个名称下其实可以拆成两种比较典型的落地路线。实际项目里可以根据任务类型和成本选择。第一种是“错误示例注入”。小模型在训练集或验证集上推理系统只要发现答案与标准答案不一致就把它保存成一条负样本。构造 prompt 时把这些负样本与少数正例混合明确告诉大模型“下面这些是错误的不要模仿”。这种方式实现最简单适合答案可自动判分的任务。第二种是“错误批判生成”。小模型不仅输出错误答案还生成一段“自我批评”比如“我在这里跳过了变量代入步骤所以计算出错”。大模型看到的是带批评的错误轨迹而不是简单的错误答案。这种方式的提示信号更丰富但需要额外训练或提示小模型输出批评文本实施成本也更高。对比项错误示例注入错误批判生成样本来源小模型推理后按答案正确性过滤小模型生成错误答案后追加批评文本上下文复杂度较低只增加错误问答对较高还要生成并解析批评文本可解释性一般只看到错误结果较强能看到错误链路实现成本低适合批量筛选中依赖小模型的文本生成质量适用任务可自动判分的数学、抽取、分类任务需要展示推理链的问答、生成任务两种路线并不是互斥的。小模型如果足够稳定也可以同时输出错误答案和批评文本再在 prompt 中一起使用。关键是要保证错误样本被明确标注为“反面材料”否则大模型可能把它们当成正确示范。2. 设计最小验证用一个小模型制造“可控错误”2.1 选一个能自动判分的推理任务要验证 CritICL 是否有效第一步是选一个能自动判分的推理任务。数学应用题是很好的候选因为它的标准答案固定模型生成结果后可以写一个解析函数直接比对答案不需要人工判断。常见基准数据集如 GSM8K、AQuA 等都可以用来做实验。如果只是验证思路也可以准备几百道自己收集的题目每道题带唯一标准答案。选择任务时有几个检查点题目是否足够短能在普通显卡上生成答案是否能从文本中稳定提取同一个问题是否允许多种推理路径但最终答案唯一。数学题天然满足这些条件也是大模型推理能力对比中最常用的场景。2.2 选一个小模型并约束输出格式小模型的作用是制造“可控错误”不是追求高正确率。可以选择参数量较小的开源模型例如 0.5B 到 1B 左右的指令模型。关键是它的输出格式要稳定否则后续做答案提取和错误筛选时会非常痛苦。为了做到这一点在让小模型推理时尽量把温度控制在 0.2 到 0.4并明确告诉它“最后用‘答案是数字’结尾”。小模型的错误率并不是越高越好也不是越低越好。如果错误率太低能筛出的错题样本就少如果错误率太高而且错误毫无规律反而会导致负例与正确推理路径之间几乎无区分度。理想状态是小模型在大部分题目上能形成连贯推理只在特定步骤上出错这样“错题集”才具有代表性。2.3 定义错误样本的数据结构在开始写代码前先定义好数据格式。推荐使用 JSONL 格式保存原始题目、标准答案、小模型答案、小模型推理、正确性标记和错误类型。错误类型可以在后续标注也可以先用规则自动分类比如提取答案失败、计算结果错误、涉及单位不一致等。字段名类型含义idstring样本唯一标识questionstring题目文本golden_answerstring标准答案small_rationalestring小模型生成的推理文本predicted_answerstring小模型提取出的答案is_correctboolean小模型答案是否与标准答案一致error_typestring错误类型可人工或规则标注这样的结构既方便后面筛选错误样本也方便与大模型的结果做对比分析。建议在刚开始就保留所有字段不要只保存错误样本否则后续想看基线时没有原始数据。3. 写一个可复现的 CritICL 实现流程3.1 用小模型批量生成并过滤错误假设已经准备好了一批题目train_rows每行包含question和golden_answer。下面代码会用一个小模型批量生成推理再通过答案提取函数判断是否正确。示例模型名和路径需要根据实际环境调整。import json import re from transformers import AutoModelForCausalLM, AutoTokenizer # 示例配置实际项目以可用的模型和显存为准 model_name Qwen/Qwen2-0.5B-Instruct tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name) def generate_small(question: str, max_new_tokens: int 128) - str: prompt ( 请一步一步解下面的数学题。\n f题目{question}\n 最后用“答案是数字”结尾。 ) inputs tokenizer(prompt, return_tensorspt) outputs model.generate( **inputs, max_new_tokensmax_new_tokens, temperature0.2, do_sampleTrue ) return tokenizer.decode(outputs[0], skip_special_tokensTrue) def extract_answer(text: str) - str: m re.search(r答案是([0-9.,\-]), text) return m.group(1) if m else def build_error_set(rows): error_set [] for row in rows: rationale generate_small(row[question]) pred extract_answer(rationale) row[small_rationale] rationale row[predicted_answer] pred row[is_correct] pred row[golden_answer] if not row[is_correct]: error_set.append(row) return error_set # errors 就是后续要用的“错题集” errors build_error_set(train_rows)这里有一个容易被忽略的点extract_answer是实验的“裁判”函数。它一旦解析错了后面所有正确性判断都会被污染。因此建议在跑全量数据前先人工抽 50 条结果检查解析函数。如果小模型经常不按格式输出可以增加 few-shot 示例或者把temperature进一步调低到 0.1。3.2 构造带纠错的提示模板有了错题集之后需要设计 prompt 模板。模板中的正例负责教模型“正确路径长什么样”负例负责告诉模型“哪些路径会翻车”。两者缺一不可且负例必须被显式标记为“错误示例”。def build_critic_prompt(question, positive_examples, negative_examples): prompt 请解决下面的数学题。\n prompt 你将看到正确示例和错误示例。错误示例是用来提醒你避免同类错误不要模仿。\n\n for ex in positive_examples: prompt f正确示例\n题目{ex[question]}\n prompt f推理{ex.get(rationale, )}\n答案{ex[answer]}\n\n for ex in negative_examples: prompt f错误示例\n题目{ex[question]}\n prompt f错误答案{ex[predicted_answer]}\n prompt f出错原因{ex.get(error_type, 未标注)}\n\n prompt f题目{question}\n prompt 请给出推理步骤和最终答案。 return prompt在 prompt 中不要把错误示例和正确示例混在同一个段落更不要让错误示例出现在正例前面且没有标注。推荐顺序是“先正例后负例”或者“先负例再正例”都可以但必须保证模型能区分。实际项目中可以在小批量上测试两种顺序选择合适的版本。错误原因字段需要先补全。如果小模型本身没有输出错误原因可以人工标注一部分或者用规则从错误答案中推断。例如答案类型不匹配、数值少了一位、漏掉单位等都可以归为粗略的错误类型。后续如果发现效果不稳定再对错误原因做更细的标注。3.3 设计基线并调用大模型验证 CritICL 是否有效不能只跑一个 prompt。至少要设计三个对照实验Zero-shot只给题目不给任何示例。Few-shot 正例只给正确示例。CritICL同时给正确示例和错误示例。每次调用大模型时记录原始输出、提取答案、是否答对。大模型既可以部署在本地也可以通过 API 调用。下面是一个简化示例使用 HTTP 接口实际地址和鉴权方式按部署环境调整。import requests def call_llm(prompt, api_urlhttp://localhost:8000/v1/completions, api_keyNone): payload { prompt: prompt, max_tokens: 256, temperature: 0 } headers {Authorization: fBearer {api_key}} if api_key else {} resp requests.post(api_url, jsonpayload, headersheaders, timeout60) resp.raise_for_status() return resp.json()[choices][0][text] def run_evaluation(questions, prompt_builder): correct 0 records [] for row in questions: prompt prompt_builder(row[question]) output call_llm(prompt) pred extract_answer(output) is_ok pred row[golden_answer] correct 1 if is_ok else 0 records.append({ id: row[id], prompt: prompt, prediction: pred, is_correct: is_ok, raw_output: output }) return correct / len(questions), records评估指标建议使用“答案准确率”。如果任务更复杂可以再加一个“推理步骤完整率”但需要额外人工或规则打分。这里要注意大模型输出的解析函数最好与小模型的解析函数保持一致否则两个系统之间没有可比性。实际跑实验时建议固定测试集不要在报告结果时临时换数据。每条 prompt 中负例的选择也要固定避免因随机选择导致误差。可以把整个实验过程写成配置方便复现。4. 影响 CritICL 效果的关键参数4.1 错误示例数量k 值太小和太大都会出问题错误示例的数量是 CritICL 最直接的超参数。试想一个极端情况如果只放一条错误示例模型可能只避开这一条路径帮助有限如果放了 10 条错误示例模型反而会困惑甚至开始模仿其中一部分错误。推荐做法是从 k0 开始以 1、2、3、5 的梯度测试每档跑多次取平均。错误示例数量可能效果风险0等同于普通 few-shot作为基线无法避开错误模式1提供一种避障信号覆盖不足特定错误仍会出现3常见的平衡区间需要保证示例相关5 以上信号增多但上下文也变长注意是否出现模仿负例、注意力分散数量选择不是一个固定值。它取决于模型上下文长度、题目复杂度和错误示例的多样性。在 2B 级别的小模型和 70B 级别的大模型上最优 k 也会不同。实验时多跑几个 k 值不要只看一遍结果。4.2 错误相关性比只顾数量更重要如果从小模型筛出了 1000 条错题每次 prompt 随机挑 3 条效果很可能是波动。更好做法是“挑与当前题目最相关的错误”。相关性可以用文本相似度来近似比如用 TF-IDF 或 embedding 向量计算。下面是一个使用 TF-IDF 做简单检索的示意from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity def select_negative_examples(question, error_set, top_k3): texts [e[question] for e in error_set] texts_with_query texts [question] vectorizer TfidfVectorizer() vectors vectorizer.fit_transform(texts_with_query) sims cosine_similarity(vectors[-1], vectors[:-1]).flatten() top_indices sims.argsort()[-top_k:][::-1] return [error_set[i] for i in top_indices]这种做法背后的逻辑是同一个话题下的错误往往具有相同诱因例如行程问题中漏加时间、利润问题中混淆成本和售价。如果当前题目是行程问题则优先选择小模型在行程问题上的错误而不是无关的几何题错误。相关性越强负例的约束作用越直接。4.3 控制温度、输出长度和提示措辞除了负例数量和相关性模型生成参数也会显著影响效果。大模型在评估阶段建议使用较低温度比如 0这样能够减少随机性保留 CritICL 带来的确定性信号。如果做在线推理希望输出更有多样性也不要直接调高温度而是使用同样的 prompt 多次采样再投票。参数推荐初始值作用temperature0 到 0.3温度越高越容易生成发散路径max_new_tokens256 到 512保证推理步骤能完整输出top_p0.9 到 1.0与温度配合控制候选集范围presence_penalty0过高的惩罚会把关键步骤挤出输出提示措辞也需要反复试。在错误示例上方加一句“下面这些是错误做法请避开”通常比不加更有效。如果任务本身对推理步骤敏感可以在 prompt 末尾要求“先写出推理步骤再给出答案”让模型在生成时保持完整链路。不要默认某一种措辞一定最好要像调参数一样调文案。5. 排查 CritICL 的常见问题5.1 结果没提升优先检查数据和样本筛选CritICL 没有提升时第一个要怀疑的不是 prompt而是小模型产生的错题集质量。如果小模型在 1000 道题里只错了 50 道错题数量少覆盖不足如果小模型输出完全没有格式答案提取失败率高那么“错误”并不是推理错误而是解析错误。这类错误样本对改善大模型推理没有价值。检查方式很简单随机抽取 30 条被标为错误的样本人工看它们的推理过程是否基本通顺、是否包含明显的错误节点。如果大量样本是截断、乱码或重复文本需要优化小模型生成格式而不是继续使用这些负例。5.2 大模型开始模仿错误用提示隔离负例另一个常见问题是加了错误示例后大模型反而输出类似错误。这通常发生在错误示例没有与正确示例明显隔离或者错误示例数量过多时。可以尝试在负例前后加显式分隔符比如“错误示例开始”和“错误示例结束”并在正例开始处也做同样标记。还有一种可能是大模型本来就不擅长区分“反例”。这时可以尝试把错误批判路线中的“出错原因”写得再具体一些。如果小模型不会写原因人工标注 10 到 20 条作为种子样本之后用这些种子样本指导小模型生成效果通常会改善。5.3 线上场景的排查顺序到了生产环境排查顺序要从数据链路开始。先确认请求进来时是否检索到了负例再确认 prompt 中负例顺序和格式没有变化然后确认大模型调用参数与实验一致最后才看日志里的错误输出。问题现象检查点处理建议效果与实验不一致负例检索是否稳定缓存检索结果保证同样输入同样负例prompt 超长负例数量过多或推理文本过长截断错误原因限制负例数量大模型频繁返回空输出解析失败查看 raw_output调整 max_tokens 和提示格式小模型在线推理延迟高在线生成负例逻辑过重预生成错题集检索代替实时推理负例与测试集泄漏错误样本来自同一测试集确保负例来自训练集或验证集生产环境建议把所有 prompt、负例和模型输出都记录到日志中。这样一旦出现效果波动可以回放具体请求而不是凭感觉猜问题。对于大模型服务可以使用 vLLM、TGI 等推理框架部署但 CritICL 的核心收益来自提示设计与具体部署框架关系不大。6. 从实验走向工程化最佳实践与扩展方向6.1 工程化落地清单当你已经在小数据集上验证 CritICL 有效再进入工程化之前最好先过一遍下面的清单。数据隔离小模型产生错误的样本必须来自训练集或验证集不能来自测试集。否则实验结果会在测试集上虚高。错误样本库把错题集落库支持按题目相似度或错误类型检索。每次新增题目时先查是否存在相似负例。版本管理prompt 模板、错误样本库、模型版本都要有版本号。因为这三者任一变化都会影响最终效果。评估脚本保留同样测试集每次改动后跑同一套评估避免“感觉变好了”代替“数据证明变好了”。采样稳定性每个配置至少跑 3 到 5 次取平均值和标准差避免一次随机结果造成误判。监控记录负例命中数、平均输出长度、解析失败率。负例命中数突然下降可能是检索模块出问题。6.2 向错题库、自我批评和蒸馏扩展CritICL 的“错题集”可以积累成长期资产。随着业务数据增加错误样本库会越来越贴近真实错误分布。这比每次重新选 prompt 要稳定得多。扩展方向上第一个是“自我批评”。小模型生成错误答案后让它继续写一句“错在哪一步”让大模型看到更具体的原因。第二个是“多轮对话推理”。在多轮任务中把上一轮小模型犯的错作为下一轮的反例让大模型在持续对话中保持正确路径。第三个是“蒸馏信号”。小模型的错误不仅可以用于 prompt还可以作为训练数据扩充的来源但这些错误需要清洗后使用不能直接当正样本。6.3 什么时候不要用 CritICL虽然这种方法在某些推理任务上有效但它不是万能的。如果小模型在目标任务上错误率过低错题样本已经不能覆盖典型失败模式CritICL 就不会带来明显提升。如果大模型本身非常强错误极少加入负例反而可能引入噪声。另外如果任务无法自动判分错误样本的标注成本会迅速增加。此时可以考虑只做小规模人工标注把人工标注的错题作为固定负例而不是实时生成。如果任务是开放生成类比如写作文案错误判断标准模糊CritICL 的适用性也会变差。回到最初的问题小模型的错误到底能不能提升大模型推理答案是在合适的任务、合适的错误样本和合适的提示设计下能。CritICL 提醒我们弱模型的输出并不是只能丢弃的垃圾它包含着低成本、高密度的失败模式信息。把这些失败模式放进大模型的上下文本质上是在用“错题本”帮大模型划重点。这个思路适合所有已经在用大模型做推理同时又积累了大量弱模型答案的团队。下一步建议从一个小数据集开始先跑通“小模型出错——构造负例——大模型改进”的最小闭环再逐步扩大错误样本库和任务场景。

CritICL：用小模型的“错题集”提升大模型推理能力

相关推荐

靶场：xss-labs 实战分析

CP2102驱动安装与排查：从识别失败到稳定的usb转串口通信

Blade Email：自定义发件人名称的开源邮件客户端解析

更多资讯

超材料AI逆向设计：S参数到几何结构的端到端建模工作流

火电文档逆向工程：从Word.doc解析机组数字孪生要素

AI漫剧日更流水线：从配置到复盘的30天实战

用S型曲线从零理解扩散模型：加噪去噪与PyTorch实现

加密恶意流量检测：基于机器学习的TLS流量分析与平台搭建

MariaDB 预处理语句加 CAST 后查询大幅提速的原因

今日更新

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？