针对小型语言模型的代码引导推理：评估可执行的 MCQA 脚手架

TL;DR Code-Guided Reasoning (CGR) 以生成可执行的 Python 代码支架辅助小模型回答多选题，在保留测试集上观察到辅助准确率达 66.21%，远超直接作答的 38.11%，并提供完整评估协议与生成程序资源。

问题

问题背景

当前，小语言模型（SLM） 在多个选择题（MCQA）基准上被频繁评测，但评测方式通常假设模型直接输出答案。现实中，越来越多的 AI 系统依赖外部推理脚手架（如工具调用、代码执行、多轮自检）来提升最终回答质量。

现有方法局限

• 直接解答范式：将 MCQA 视为单轮分类任务，忽略真实部署中模型可通过生成并执行代码来分解问题、验证中间结论的能力。
• 评测协议不统一：缺乏对脚手架组件的标准化定义，不同研究使用的提示模板、答案抽取方式、计算预算差异巨大，导致结果无法直接对比。
• 辅助推理的收益与风险不透明：现有工作往往只报告最终准确率，未系统区分直接回答、辅助回答、生成器侧回答的不同信号，也未量化代码生成中的硬编码泄露、答案抽取脆断等失效模式。

为什么这个问题难且重要

• 技术挑战：有效利用代码执行环境需要模型同时具备指令遵循、程序合成、错误处理等多维能力；答案抽取还需应对生成结果中可能的格式漂移和逻辑错误。
• 工程价值：在算力成本敏感的场景下，理解“何时用脚手架、用多少调用预算”能直接指导推理时资源调度。业界正逐渐从单纯追求模型尺寸转向推理策略优化，例如 OpenAI o1 系列通过隐式链式思考提升性能，CGR 则提供了一种更透明、可审计的外部化推理方案。
• 评估科学性：CGR 提出的 三通道结果记录（直接、辅助、生成器侧）和 分区定义 为严谨的消融分析和误差归因奠定基础，推动 MCQA 评测从“单一指标”走向“多维诊断”。

行业类比

类似检索增强生成（RAG） 通过外部知识库弥补模型参数记忆的不足，CGR 通过可执行代码环境扩展了 SLM 的逻辑推导与数值计算边界，二者都是以结构化外部资源增强语言模型的典型范式。

核心洞察

• Code-Guided Reasoning (CGR) 将可执行推理脚手架与直接回答解耦，通过标准化组件和多通道记录（direct/assisted/generator-side）度量 SLM 在 MCQA 上的性能变化：在非零基线分区中，辅助准确率比直接准确率高 28.10 个百分点（宏观平均），且配对 bootstrap 区间为 [20.32, 36.43]。这不同于常规 benchmark 仅把 SLM 当作直接回答器，CGR 明确将代码生成、执行与答案提取纳入评估，暴露了大型 solver-call 预算和答案提取脆弱性对整体增益的依赖，为工程选型提供了更贴近真实部署的参考。
• 辅助推理虽然提升了整体准确率，但 Time-MQA 数据集上出现回归，且部分生成程序违反“不硬编码”指令，答案提取链条本身也易出错（brittle extraction）。这提示：在追求外部工具增益的同时，必须关注代码生成的指令遵循度、解析鲁棒性以及特定领域（如时间推理）的退化风险；CGR 提供的完整 trace package（包含生成程序、响应元数据和分区定义）让工程师能针对性审计失败案例，而不是仅看单一准确率数字。

方法

CGR 方法围绕 标准化六组件评估协议 展开，将 SLM 从直接答案生成器转变为可借助代码支架的推理器。

输入与标准化接口

每个 MCQA 项目（问题、选项、正确答案）首先通过 归一化项目接口 (normalized item interface) 转换为统一格式，屏蔽不同数据集的结构差异，保证后续流程一致。

关键模块

1. 直接求解器提示 (direct solver prompt)：输入标准化项目，要求 SLM 直接输出答案，用于获取无辅助的准确率基线。
2. 生成器提示 (generator prompt)：由能力更强的模型（生成器）根据项目生成一个 Python 程序，该程序负责实现逐步推理逻辑，并允许在推理中多次调用目标 SLM 作为求解器。
3. Python 支架 (Python scaffold)：执行生成器产生的代码，管理程序与求解器之间的交互循环。程序可通过预定义的 求解器调用助手 (solver-call helper) 向 SLM 发送子问题，并利用 答案提取助手 (extraction helper) 从 SLM 的响应中抽取结构化答案。
4. 三通道结果记录 (three-channel result record)：每次评估同时记录 直接答案、辅助答案 和 生成器侧答案，并附带程序源码、求解器调用元数据、分区标识（如零基线分区）等，构成可审计的追踪包。

输出与分析

基于记录的数据，计算 宏观辅助准确率 相对于直接准确率的提升，并通过 配对的 bootstrap 置信区间 估计效应大小。为排除基线噪声，定义了 非零基线分区（直接准确率 > 0）和更严格的 A_b > 30% 直接信号门，分别观测辅助带来的增益。同时，审计追踪可暴露 答案提取的脆弱性、生成程序违反“禁止硬编码”指令 等问题，为结果解读提供依据。

与单纯将 SLM 作为最终答案生成器不同，CGR 通过 生成式代码 + 多次求解器调用 构建显式的推理支架，不仅量化了此种支架对性能的改善幅度，还系统揭示了其失败模式（如 Time-MQA 上的退化），为构建更稳健的 SLM 应用提供了评估框架。

实验

实验设计

• 构建 Code-Guided Reasoning (CGR) 协议，标准化六个组件：归一化题目接口、直接求解 prompt、生成器 prompt、Python 脚手架、求解器调用与提取辅助、三通道结果记录。
• 使用本地准备的 MCQA bundle（含 Time-MQA 等），在 6 个已注册元数据的 SLM 上运行。
• 对比直接回答与由生成器产生 Python 程序辅助推理的模式，收集直接、辅助和生成器侧答案及完整 trace。

关键发现

• 非零基线分区：辅助宏观准确率 66.21% vs. 直接 38.11%，提升 +28.10 pp（配对自助法区间 [20.32, 36.43]）。
• 在 A_b > 30% 直接信号门控下，宏观差异收窄至 +14.11 pp。
• 辅助推理消耗更多求解器调用；答案提取环节脆弱；生成程序可能违反“不得硬编码”规则；Time-MQA 上出现性能衰退。

与基线对比解读

• 增益均为描述性估计，但揭示可执行脚手架能显著提升 SLM 的 MCQA 表现，前提是题目具有非零基线信号。
• “免费午餐”不存在：严格门控后增益大幅缩水，且辅助推理的额外计算与脆弱性需在实际部署中权衡。
• 相比隐式思维链，CGR 提供的可执行程序轨迹增强了可解释性，但生成质量（如硬编码）直接影响效果，对工程落地提出新的质量监控需求。

行业影响

落地场景

Code-Guided Reasoning (CGR) 为小语言模型 (SLM) 注入可执行推理能力，适用于需要高可靠性、低延迟且成本敏感的 MCQA 场景：

• 客户支持自动化：在电商、金融等领域的聊天机器人中，将 FAQ 转化为选择题式问答，SLM 通过生成并执行 Python 代码完成复杂逻辑判断、日期计算或规则匹配，替代昂贵的大模型 API。
• 教育与测评：自动化批改系统中的客观题判定，可结合元数据（如知识点、难度）动态生成推理步骤，提升解释性。
• 内容审核与合规：对用户生成内容进行多标签分类时，用 CGR 将规则引擎与 SLM 结合，代码负责硬约束，模型处理模糊语义，降低误判。

商业价值

CGR 的核心价值在于以极低成本解锁 SLM 的高级推理能力：

• 大幅降低推理算力开销：使用 1-7B 参数模型替代 70B+ 模型处理 MCQA，成本可降低 10-100 倍，同时保持可接受的准确率（实验中 +28.10 个百分点提升）。
• 提升自动化率：在非零基线数据上，辅助精度达 66.21%，可在无需人工审核的阈值以上自动处理更多工单，直接减少运营成本。
• 增强可解释性与审计性：生成程序提供完整推理轨迹，满足金融、医疗等强监管行业的合规要求。

与现有 stack 的集成

CGR 设计为六项标准化组件，易于插入现有 ML 流水线：

1. 标准化接口：统一的数据格式 (normalized item interface) 可适配主流评估集和自定义题库。
2. 轻量级引擎：Python scaffold 和 solver-call helpers 可作为微服务部署，通过 REST/gRPC 接入现有的模型推理服务。
3. 多通道记录：three-channel result record 输出直接答案、辅助答案和生成器答案，便于集成到 MLflow/Kubeflow 等实验管理平台。
4. 与 RAG 或工具调用框架协同：CGR 可视为一种特殊工具——它生成代码调用自身（或另一个 SLM），因此 LangChain、AutoGen 等框架均可无缝集成。

典型应用：金融合规审查

• 场景：银行需对交易描述进行多标签合规分类（如是否涉及制裁实体、高风险地区等）。规则复杂且频繁变动，纯规则硬编码维护成本高，纯大模型则推理成本高。
• CGR 落地：将合规规则表作为外部知识，SLM 生成 Python 函数查询规则、执行逻辑判断，并调用规则引擎 API。仅当规则匹配模棱两可时，才调用大模型进行语义裁决。保证可解释性，满足监管审计要求，单次调用成本可降至 $0.001 以下。

电商智能客服中的订单修改

• 场景：用户要求修改订单地址或取消订单，客服机器人需判断订单状态、物流阶段、用户权限等，属于典型的条件组合推理。
• CGR 落地：将订单状态机编码为 Python 逻辑，模型根据用户输入生成调用这些函数的代码，自动校验可行性。错误分支可返回预期外的状态给人工坐席。在百万级订单量下，能过滤 60-80% 的简单工单，且 SLM 推理成本仅为大模型的数十分之一。

局限

• **答案提取的脆弱性**。辅助推理管道中，从 Python 程序输出或求解器调用中提取最终选项字母的步骤容易出错，部分程序的答案提取失败或产生歧义，导致准确性记录需要人工审核。论文公开指出答案提取是一种脆弱的启发式方法，在开放式中文或复杂格式下可能失效，这限制了该方法在标准化选择题以外的通用性。
• **辅助推理的高推理成本**。Code-Guided Reasoning 为每个问题生成并执行一个 Python 程序，并多次调用小型求解模型（solver-call），使得辅助模式下的推理预算远高于直接解答模式。论文承认这种额外开销，但未深入量化成本占比或讨论在实际部署中如何权衡精度与算力，这对资源受限的场景构成明显障碍。
• **生成程序的不合规与领域敏感性**。部分由生成器模型产生的程序违反了'不得硬编码答案'的指令，即程序直接包含正确选项而不经过推理，这削弱了 scaffolds 的有效性验证。此外，Time-MQA 数据集上观察到辅助模式下的性能倒退，说明该方法对特定领域（如时间推理）可能不适用，通用性有限，且未探索如何自动检测或缓解此类不合规行为。