实测对比：Self-Consistency 多路采样投票的准确率与成本权衡

问题背景：单次 CoT 为什么还会错

链式思考（CoT）能显著提升大模型在数学、逻辑、代码排障等任务上的表现，但它本质上仍是一次采样。温度稍高时，模型可能在某一步误读条件；温度为 0 时，也可能因为提示词歧义、训练数据偏差或问题本身存在多个近似路径，稳定地走到错误答案。

Self-Consistency（自一致性）的思路很直接：不要只相信一条推理链，而是让模型从同一个问题出发，独立生成多条推理路径，再对最终答案进行多数投票。它的核心假设是：错误路径往往分散，正确答案更容易在不同思路中收敛。

但工程上真正的问题不是“有没有效果”，而是：采样多少路才划算？温度如何设置？答案怎样归一化？什么情况下多路投票反而增加成本却不提升准确率？本文用一个可运行的 Python 示例拆解这套推理增强方案。

方案对比：贪心解码、单路 CoT 与多路投票

常见方案可以按准确率、延迟和成本分成三类：

• 贪心解码：温度接近 0，每次选择概率最高的 token。成本最低、结果稳定，但容易被单一路径锁死。
• 单路 CoT：要求模型先分析再作答。适合简单推理，延迟和成本只增加几百个输出 Token。
• Self-Consistency 多路采样投票：使用较高温度生成多条推理链，再提取答案投票。通常准确率更高，但 Token 成本、延迟和解析复杂度近似随采样路数线性增加。

下面这张图展示了多路采样投票的基本流程：

关键取舍：准确率不是随路数线性增长

多路采样的收益通常呈现“先快后慢”的趋势。从 1 路提升到 5 路，往往能覆盖大部分随机性收益；从 9 路提升到 21 路，准确率可能只提升几个百分点，但成本增加数倍。对于在线接口，还要考虑并发限流、首 Token 延迟和总超时时间。

工程上建议先用评测集确定曲线，而不是凭感觉设置路数。一个实用决策框架是：

1. 简单事实型问题：不要使用 Self-Consistency，检索或单次结构化输出更合适。
2. 中短链数学、逻辑题：从 5 路开始，温度设置在 0.5~0.8。
3. 高风险决策题：使用 7~9 路，并设置最低投票阈值；票数分散时交给更强模型或人工复核。
4. 长链路复杂推理：先做问题分解或工具调用，否则多路采样会放大冗长推理的成本。

可运行示例：实现多路采样与答案投票

下面示例使用 OpenAI Python SDK 的异步接口，适合直接接入评测脚本。代码包含结构化提示词、答案提取、归一化、多数投票和成本估算。若使用其他兼容 OpenAI 接口的模型，只需修改 base_url 与模型名。

# 安装依赖：pip install openai
import asyncio
import re
from collections import Counter
from typing import List, Dict, Any
from openai import AsyncOpenAI

client = AsyncOpenAI()

PROMPT_TEMPLATE = """
你是一个严谨的推理助手。请按以下要求回答：
1. 先给出简短、清晰的推理步骤；
2. 每一步只处理一个明确事实；
3. 最后必须另起一行，使用严格格式输出最终答案。

问题：{question}

输出格式：
推理过程：
1. ...
2. ...
最终答案：{{答案}}
"""

async def sample_once(question: str, model: str = "gpt-4o-mini") -> Dict[str, Any]:
    """生成一条独立推理链。较高 temperature 用于获得多样化路径。"""
    resp = await client.chat.completions.create(
        model=model,
        temperature=0.7,
        messages=[{"role": "user", "content": PROMPT_TEMPLATE.format(question=question)}],
    )
    text = resp.choices[0].message.content.strip()
    usage = resp.usage
    return {
        "text": text,
        "answer": extract_answer(text),
        "prompt_tokens": usage.prompt_tokens,
        "completion_tokens": usage.completion_tokens,
    }

def extract_answer(text: str) -> str:
    """从固定格式中提取最终答案，避免把整段推理拿去投票。"""
    match = re.search(r"最终答案[:：]\s*(.+)", text)
    if not match:
        return "__PARSE_ERROR__"
    return normalize_answer(match.group(1).strip())

def normalize_answer(answer: str) -> str:
    """归一化答案：去空白、单位、千分位和结尾标点。"""
    answer = answer.strip().replace("，", ",")
    answer = re.sub(r"\s+", "", answer)
    answer = answer.rstrip("。.;；")
    # 统一金额格式，例如 1,000 元 -> 1000元
    answer = re.sub(r"(?<=\d),(?=\d{3}(?:\D|$))", "", answer)
    return answer.lower()

async def self_consistency(
    question: str,
    samples: int = 5,
    model: str = "gpt-4o-mini",
    min_vote_ratio: float = 0.6,
) -> Dict[str, Any]:
    """并发生成多条推理链，并对最终答案投票。"""
    results = await asyncio.gather(*[sample_once(question, model) for _ in range(samples)])

    valid_answers = [r["answer"] for r in results if r["answer"] != "__PARSE_ERROR__"]
    votes = Counter(valid_answers)
    top_answer, top_count = votes.most_common(1)[0] if votes else ("__NO_ANSWER__", 0)
    vote_ratio = top_count / samples

    total_prompt_tokens = sum(r["prompt_tokens"] for r in results)
    total_completion_tokens = sum(r["completion_tokens"] for r in results)

    return {
        "answer": top_answer,
        "confident": vote_ratio >= min_vote_ratio,
        "vote_ratio": round(vote_ratio, 3),
        "votes": dict(votes),
        "results": results,
        "total_prompt_tokens": total_prompt_tokens,
        "total_completion_tokens": total_completion_tokens,
    }

async def main():
    question = "一个商品先涨价 20%，再打八折出售。若原价是 100 元，最终售价是多少元？"
    output = await self_consistency(question, samples=5)
    print("答案：", output["answer"])
    print("投票：", output["votes"])
    print("是否达到可信阈值：", output["confident"])
    print("输入 Token：", output["total_prompt_tokens"])
    print("输出 Token：", output["total_completion_tokens"])

if __name__ == "__main__":
    asyncio.run(main())

这段代码最重要的不是“多请求几次”，而是把推理链生成和答案投票解耦。投票对象必须是规范化后的最终答案，而不是模型生成的自然语言段落；否则“96 元”“96元”“最终售价为 96 元”会被误判为三个不同答案。

成本控制：并发、缓存与提前停止

如果固定采样 9 路，理论输出 Token 约为单路 CoT 的 9 倍。实际项目中可以通过三种方式降低成本。

第一，并发请求但设置预算。在线服务可使用 asyncio.wait_for 控制总超时，并限制最大并发数，避免触发模型提供方的限流。

第二，复用系统提示词缓存。将通用角色、输出格式和少量示例放入 system message，把变化的问题放入 user message。支持 Prompt Cache 的服务商可以降低重复输入 Token 成本。

第三，按置信度提前停止。例如先发 5 路，如果某个答案拿到 4 票以上就直接返回；若票数分散，再补采 4 路。需要注意，提前停止会让简单问题更快、更便宜，但不能在离线评测中只统计成功命中阈值的样本，否则准确率评估会产生偏差。

避坑总结：来自线上评测的 5 个注意事项

1. 温度设成 0，导致多路采样退化成重复请求

常见错误现象：开了 7 路投票，但返回文本几乎完全相同，成本增加 7 倍，准确率没有变化。原因是 temperature=0 或 Top-p 过窄，模型没有探索不同推理路径。

修正方法：Self-Consistency 一般使用 0.5~0.8 的温度；如果业务要求稳定输出，可保持响应格式固定，但不要把采样空间完全锁死。

2. 直接对整段推理文本投票

常见错误现象：多个回答结论相同，却因为措辞、标点、步骤顺序不同而投不出多数答案。

修正方法：提示词中强制输出“最终答案：...”，再用正则或 JSON Schema 提取字段。投票只针对归一化后的短答案，推理过程仅用于审计和错误分析。

3. 答案归一化不足，正确票被拆散

常见错误现象：96元、96 元、人民币96块 被统计成三个答案，模型本来答对了，系统却判定为低置信度。

修正方法：按题型设计归一化规则。数值题统一单位和小数位；选择题统一大写选项；布尔题统一为 yes/no；实体题可增加别名字典。不要用一个 strip() 处理所有题型。

4. 忽略解析失败票，使置信度虚高

常见错误现象：9 路请求中有 4 路格式错误，剩余 5 路里 3 路选择 A，系统报告置信度 60%，但按总样本计算只有 33%。

修正方法：置信度分母应包含全部采样路数；解析失败可以作为 __PARSE_ERROR__ 单独计票。若失败率过高，应优先修复提示词或启用结构化输出，而不是盲目增加采样数。

5. 把 Self-Consistency 当成所有任务的通用增强器

常见错误现象：摘要、信息抽取、开放写作也启用多路投票，结果答案难以定义，延迟明显上升，用户感知不到收益。

修正方法：Self-Consistency 更适合答案空间有限、可验证、需要多步推理的任务。对于 RAG 问答，应先提升检索召回；对于长文本生成，应使用评审、引用校验或分步规划；对于事实查询，单次回答加工具验证通常更经济。

结语：先评测曲线，再决定采样预算

Self-Consistency 的价值在于用可控冗余换取推理鲁棒性，但它不是免费的准确率提升。推荐的落地顺序是：先用固定评测集比较 1、3、5、7、9 路的准确率和 Token 成本，再根据题型选择温度、投票阈值和补采策略；最后把低置信度样本接入强模型、工具或人工复核。这样，多路采样投票才不会沦为“多花几倍钱买一点心理安慰”，而会成为可度量、可回滚、可优化的推理增强组件。

免责声明

本工具与文章内容仅用于学习测试场景，优化建议仅供参考，请勿直接用于生产环境，由此产生的风险自行承担。