自洽性推理解决的核心问题并不是模型参数不够多，而是单次生成路径中的随机错误很难在局部被纠正。模型每输出一个 token 都会基于当前概率分布做出选择，如果某一小步偏离了正确方向，后续推理就可能沿着错误路径继续。多次采样利用同一个问题生成多条思维链，再把最终答案汇总投票，将个别路径中的偶然错误稀释掉。这种方式不需要重新训练，也不用引入外部知识库，只在推理阶段增加采样次数。它的工作机制可以从统计基础、采样实现、投票规范化以及工程成本几个角度展开。
自洽性推理的统计基础
自洽性推理之所以有效，可以从边际化的角度理解。给定输入问题 x 和候选答案 y，模型生成答案的概率可以看作所有潜在推理路径 r 上的积分或求和。单次采样只取了一条路径，相当于用一条路径上的条件概率近似整体概率。如果采样路径分布与真实推理路径分布存在偏差，答案就会不稳定。多次采样后按答案聚合并投票，相当于对多条路径做了均匀加权，更接近边际化后的答案分布。
一个更直观的类比是重复测量。假设模型单次推理得到正确答案的概率是 0.7，随机采样 10 次后通过多数投票得到正确结果的概率会明显高于 0.7。因为错误路径并不总是指向同一个错误答案，而正确推理通常指向同一个最终结果。错误答案越分散，投票机制对准确率的提升越明显。相反，如果模型存在系统性偏差，即很多次采样都稳定地得出同一个错误结论，多数投票也无能为力。
自洽性推理的工作流程可以拆成四步。第一步构造一个鼓励逐步推理的提示，让模型在给出最终答案前先输出推理过程。第二步设置合适的温度参数并重复调用模型，得到多条候选回答。第三步从每条回答中抽取最终答案，而不是比较整个回答文本。第四步对答案做规范化处理后统计频次，选出现次数最多的答案作为输出。每一步的实现质量都会影响最终效果。
多次采样的实现细节
采样次数是第一个需要调的关键参数。次数过少时投票的统计优势不明显，比如只采样 3 次，2 比 1 的投票结果仍然可能是偶然。次数过多会线性增加推理成本，但在多数公开测试中，采样 5 到 10 次已经能获得大部分收益。从工程角度看，10 次是比较稳妥的默认值；如果响应时间不敏感，可以提升到 20 次甚至 40 次，但在算术推理、常识推理等任务上超过 20 次后的准确率提升通常非常有限。
温度参数直接决定采样多样性。温度接近 0 时模型几乎退化为贪心解码，每次生成的文本高度相似，投票失去意义。温度设置到 1.0 以上会增加非常规路径的出现概率，但这些路径往往包含更多语法错误或偏离题目要求。实践中 0.5 到 0.8 是常用区间。可以这样理解：温度每升高一点，模型更愿意尝试低概率 token，这有助于跳出局部推理模式，但也会引入噪声。最合适的温度需要通过小规模验证集测试，不同模型和任务差异较大。
提示词设计也值得单独处理。思维链提示通常要求模型先给出推理，再以固定格式给出最终答案，例如在答案前加上“最终答案：”。这种格式可以降低后端提取难度。如果只需要答案而不需要展示推理过程，可以在多次采样阶段只要求输出简短推理和结论。示例代码如下，它展示了一个多次采样的基础调用流程。
import random
from collections import Counter
import re
def call_model(prompt, temperature=0.7, max_tokens=256):
# 实际项目中替换为模型推理接口
# 返回一段包含推理过程和最终答案的文本
return model.generate(prompt, temperature=temperature, max_tokens=max_tokens)
def generate_candidates(prompt, n=10, temperature=0.7):
candidates = []
for _ in range(n):
answer_text = call_model(prompt, temperature=temperature)
candidates.append(answer_text.strip())
return candidates
def extract_final_answer(text):
# 假设提示词中要求模型以 最终答案：xxx 结尾
if "最终答案：" in text:
return text.split("最终答案：")[-1].strip()
return text.strip()
def normalize_answer(answer):
# 去掉空白、标点和大小写差异，中文保留
answer = answer.lower()
answer = re.sub(r"[^a-z0-9\u4e00-\u9fff]", "", answer)
return answer
def majority_vote(candidates):
if not candidates:
return ""
norm_map = {}
for raw in candidates:
norm_map.setdefault(normalize_answer(extract_final_answer(raw)), []).append(raw)
best_key = max(norm_map, key=lambda k: len(norm_map[k]))
return norm_map[best_key][0]
上面这段代码只给出了流程框架，实际接入时需要处理接口异常、超时重试以及并发调用。尤其是并发，如果串行生成 10 次答案，总耗时会变成单次的 10 倍。多数场景下应当并行请求，把总延迟控制在一个可接受范围内。对于支持批量推理的服务，还可以把同一条提示复制成若干份一次请求，减少网络开销。
投票决策机制与答案规范化
投票决策的第一个难点是答案表达不规范。同一个正确结果可能以不同形式出现，例如“42”、“答案是42”、“42.0”、“四十二”。如果不做规范化，这些答案会被统计成不同类别，导致正确结果无法获得多数票。因此多数投票之前需要做答案提取和标准化。答案提取通常依赖提示词中的固定格式，标准化则包括转小写、去除标点、合并全半角字符、统一数字格式等。对于数学题，还可以把不同单位的相等结果做进一步归并，不过这会增加实现复杂度。
简单多数投票有一个隐含假设：每条采样路径同样可信。实际上模型对某些答案的置信度更高，例如生成时整条路径的平均对数概率更大。此时可以把概率作为投票权重，而不是每票相等。加权投票在答案分布较为接近时能够提供更细的信号。以下代码展示了按每个候选答案的置信度进行加权投票的做法。
def weighted_vote(candidates, scores):
# scores 与 candidates 一一对应，表示每个候选答案的置信度
if not candidates:
return ""
weighted = {}
raw_map = {}
for raw, score in zip(candidates, scores):
key = normalize_answer(extract_final_answer(raw))
weighted[key] = weighted.get(key, 0.0) + score
raw_map.setdefault(key, raw)
if not weighted:
return ""
best_key = max(weighted, key=weighted.get)
return raw_map[best_key]
平局处理也需要提前设计。文本答案的投票结果经常出现 3 比 3 比 4 这类接近的分布，如果最高票与第二高票差距只有 1，直接采用最高票不一定可靠。可以在差距过小时回退到概率加权结果，或者再追加若干次采样后重新统计。另一种策略是设定最小相对多数阈值，例如最高票必须占总采样次数的 40% 以上才接受，否则标记为低置信度结果并要求人工确认。这种机制在需要高可靠性的生产系统中很实用。
工程实践中的成本与适用边界
自洽性推理的成本不能只看单次调用。采样 10 次意味着问题处理成本增加约 10 倍，如果系统原本已经接近并发上限，直接把自洽性推理嵌入在线请求会造成明显压力。更合适的方式是分层处理：先使用普通贪心解码快速返回，只有当用户对答案不满意、模型自身置信度低或问题进入高风险类别时，才触发多次采样投票。这样既能保持平均响应速度，又能在关键场景中获得更高准确率。
与 best-of-n 采样相比，自洽性推理更强调答案层面的聚合。Best-of-n 通常根据整条回答的生成概率或奖励模型打分选择最优一条，而自洽性投票只关注最终答案是否一致。两者可以组合使用，例如先用 best-of-n 筛选出高质量候选，再对候选答案进行多数投票。另一个容易混淆的概念是集成学习，但自洽性推理并不训练多个模型，它只是利用同一模型在随机解码下的输出多样性，因此实现成本低很多。
从适用任务来看，自洽性推理在答案空间有限、逻辑路径相对固定的任务上提升最明显，例如小学到高中难度的数学题、代码片段生成、事实判断题和多步骤规划。开放创作、诗歌写作这类没有标准答案的任务则不适合，因为投票会把多样化的合理回答压缩成单一结果，反而削弱表现力。调试时建议先在验证集上绘出采样次数与准确率的关系曲线，确认投票收益后再决定是否上线。
最终是否采用自洽性推理，核心取决于对延迟与可靠性的权衡。如果产品允许几百毫秒的额外等待，且用户对错误答案容忍度低，那它是一项性价比很高的推理层优化。如果系统追求极低延迟，则可以在本地缓存或小模型预筛后再选择性地使用多次采样。