同一个提示词、同一个模型、同一套参数连着跑三次给你三个互相打架的答案——我第一次碰到这种情况时第一反应是接口缓存串了数据翻了半天请求日志才发现是自己把 temperature 设成了 0.7。那会儿我正在做一批数学应用题的批量评测单次跑出来的准确率忽高忽低同一道题今天对明天错根本没法判断是模型能力问题还是我的提示词有问题。后来在 Prompt 工程这条路上摸爬滚打久了才明白**自我一致性Self-Consistency**这套思路解决的正是这个痛点它不指望模型一次就想对而是让它用不同的思路想很多次最后投票选那个被最多条推理路径支持的答案。对于做评测、做数据标注、做需要稳定输出的业务场景的人来说这套方法几乎是把玄学变成工程的第一步。下面我把自己从踩坑到跑通、从跑通到调优的完整过程拆开讲包含提示词骨架、采样参数、抽取归一的代码、路径数的边际收益曲线以及几种典型的失效排查链路适合刚接触 Prompt 工程、想把手里的模型输出稳定下来的读者。1. 单次推理靠不住自我一致性到底补的是哪个洞1.1 温度系数把确定性这件事悄悄偷走了很多人对模型输出的第一印象是它是确定的因为在大众认知里计算机程序就是输入决定输出。实际不是。当前主流对话模型的解码过程本质上是按概率抽签模型每生成一个 token都会先算出一整张词表上的概率分布然后按这张分布去采样。temperature 参数干的事情就是把这个分布压平或者削尖。temperature 趋近 0 时分布被削得只剩最高概率那一根尖刺相当于每次都选概率最大的 token业内叫贪心解码temperature 拉到 1 附近分布保持原样抽签范围变宽输出就开始有随机性了。我在实践中发现一个很多人忽略的细节即使把 temperature 设成 0同一个请求多次调用也未必 100% 一致。原因在于批处理调度、并行计算的浮点累加顺序、推理框架的算子实现等因素都可能在极低概率上引入微小差异而模型是一个每步都基于前文重新决策的系统前面一个 token 的细微差别后面可能滚成完全不同的句子。所以严格意义上只要不是每次都走完全相同的计算路径输出就有方差。这个问题在短回答里不明显在多步推理的长回答里会被放大得很夸张。温度带来的方差不是均匀分布的。简单的事实问答比如某个国家的首都是哪即使 temperature 给到 1模型翻来覆去也就那么一两个答案但一旦题目需要多步计算、多点信息综合、或者存在歧义方差就陡然上升。这提示我们方差的大小和任务的推理深度强相关而自我一致性恰恰是针对推理深度大的任务设计的。1.2 思维链把单步误差滚成了雪球思维链Chain-of-Thought提示是过去几年 Prompt 工程里最能提准确率的一招让模型把中间步骤写出来再给答案。但它的副作用很多人没意识到它把一次判断拆成了十次判断只要其中一步走偏后面全歪。举个我实际踩过的例子。一道典型的多步应用题涉及先算总量、再算单价、最后算总价中间还要做一次单位换算。假设模型每一步的正确率是 95%看起来很高但四步连乘下来整道题的正确率就只有 0.95⁴ ≈ 81%。如果题目有八步正确率掉到 66%。而如果某一步出现歧义、模型在两种理解之间摇摆那一步的正确率可能只有 70%整体就会崩得更厉害。更麻烦的是模型走错路的时候语气一点都不心虚。它会把错误的前提当成既定事实继续往下推最后给你一个看起来推导严密、实际上根基就歪了的答案。我在早期做评测时经常被这种自信的错误骗过去直到手工核对才发现问题出在第二步。自我一致性的洞察就发生在这里对于同一个问题正确的推理路径往往不止一条但错误的推理路径通常各自跑偏、互不相同。如果你让模型用不同的随机种子、不同的措辞、不同的切入点去想很多遍正确答案会因为有多条路径通向他们而形成共识而错误答案则因为路径分散而票数稀薄。这不是让模型变聪明了而是让运气这个东西在统计上被摊平了。1.3 为什么这套思路在 Prompt 层面就能落地对比一下模型训练侧的方案要让模型输出更稳定通常需要做对齐训练、RLHF、拒绝采样之类的工作门槛高、周期长、还得有算力。自我一致性最大的好处是它完全发生在推理侧和提示词侧不改模型、不训练、不微调只要你会调接口、会写几十行聚合代码今天下午就能跑起来。我在几个不同规模的项目里都验证过这个特点只要任务本身有唯一正确答案这个属性套上自我一致性之后输出的稳定性肉眼可见地提升尤其是那些单次跑准确率在 60% 到 80% 之间晃荡的任务往往能提到 85% 以上。而那些单次准确率本来就有 95% 的简单任务加了反而浪费钱。2. 机制拆解从一条推理链到一片路径森林2.1 多次采样、独立推理、答案聚合这三条腿自我一致性的执行结构其实很朴素可以拆成三个必须同时成立的动作。第一步是多次采样对同一个问题让模型生成 N 条完整的推理过程每条都从零开始独立作答。第二步是独立推理这 N 条路径之间不能互相看见不能共享上下文最好连系统提示都一模一样保证它们是在同一条件下各自摸索。第三步是答案聚合从每条路径里把最终答案抠出来统计哪个答案出现次数最多票数最高的那个就是输出。这三步缺一不可。少了第一步就退化成普通思维链少了第二步就变成让模型自己检查一遍少了第三步就变成生成多个候选让用户挑。我在早期做过一个错误版本为了省 token把 N 条路径塞进同一次对话里让模型给出三种不同的解法然后自己判断哪个对。结果准确率几乎没提升因为模型在同一段上下文里生成的三条路径高度同质化它只是换了个说法重复同一套思路投票等于自己给自己投。对比另外两种常见的思路会更清楚。Best-of-N采样也是生成多个候选但它需要一个外部的验证器或者打分模型来判断哪个候选最好多了一个组件。模型集成Ensemble是换不同的模型各答一遍再投票成本和运维复杂度都高一个量级。自我一致性只用同一个模型、不同随机性聚合规则简单到用计数器就能实现工程上极轻。2.2 多数投票成立需要四个隐含前提这套方法看起来像人多力量大的朴素逻辑但它在什么条件下有效很多人没想清楚。我在不同任务上试下来总结出四个隐含前提只要有一条不成立投票就会失效。前提具体含义不成立时的表现答案空间可枚举最终答案能被归一化成有限个离散值投票全是平票聚合毫无意义正确路径概率质量集中正确的那条路是模型最容易想到的模型根本没这个知识投一万次也是错的路径之间相互独立采样过程没有共享上下文或缓存所有路径雷同投票退化答案抽取确定从文本里抠答案的规则是固定的明明说的是同一个数被抽成两种写法第一条最容易理解。数学题答案是数字选择题答案是选项字母分类任务答案是类别名这些都能归一化。但如果你让模型写一段营销文案、做一次开放式总结答案是无限维的文本空间哪段文案最一致这个问题本身就没有定义投票无从谈起。我在一个文案生成项目里试过自我一致性结果聚合出来的高频答案往往是最平庸、最没信息量的那一版——因为平庸的表达路径最多这反而把好的创意给投没了。第二条讲的是模型能力的边界。自我一致性只能在模型偶尔会做对的任务上起作用它摊平的是运气带来的方差不是知识空白。如果模型压根没见过相关知识任你采样一百次错误答案会以压倒性优势形成共识这时你反而会得到一个错误但极其自信的结论。我见过有人拿这套方法去测冷门知识结果跑出来一堆错误答案还以为自己发现了什么规律。第三条是本篇最需要强调的工程细节。独立性包含三个层面调用独立、上下文独立、提示词一致。调用独立是指每次都是一次新的请求不复用对话历史上下文独立是指不要把前一次的答案顺手塞进后一次提示词一致是指 N 条路径的输入除了随机性以外完全同一如果你给每条路径配了不同的角色设定或者不同的示例那实际上是在做 Ensemble结果解释起来就复杂了。第四条最容易被低估也最容易在工程上翻车。模型的最终答案常见写法有答案是 42最终结果42因此总价为 42 元42如果抽取正则只认其中一种另外三种就被丢掉了票数自然稀薄。我在这一条上至少翻过两次车后面会专门讲。3. 手搭流水线提示词、采样、抽取、投票四步3.1 提示词骨架让答案可抽取比让模型多想更重要很多教程在讲自我一致性时把注意力全放在怎么让模型多想几遍上其实提示词设计的核心是让答案可被稳定抽取。我摸索出来的模板结构大概长这样你是一个严谨的推理助手。请一步步分析下面的问题并给出最终答案。 要求 1. 先写出完整的推理过程每步都要有依据。 2. 推理结束后另起一行用 最终答案 开头后面只跟答案本身。 3. 不要在最终答案那一行写任何解释、单位说明或多余的字。 问题{question}这个模板里第 1 条是思维链的触发第 2 条是抽取锚点第 3 条是防止模型在答案后面加尾巴。实践中我发现第 3 条特别重要模型很爱在答案后面补一句假设没有其他费用或者保留两位小数这种尾巴一旦掺进答案字符串归一化就会变得极其痛苦。一个血的教训模板里千万不要写请用多种方法思考这个问题然后给出你认为最可靠的答案。这句话听起来像自我一致性实际上是把投票工作交给了模型自己完成等于放弃了你对过程的控制。模型自己投票的能力远比不上统计计数。另外冻结提示词是个容易被忽略但极其重要的工程习惯。一旦确定了模板所有路径都用同一个版本。我早期做过一个实验中途为了优化模板改了几个字结果前后两批数据没法直接对比白白浪费了一晚上的采样预算。3.2 采样参数与并发控制参数这块我踩过的坑比提示词多。最初我以为 temperature 越高越好因为多样性更足结果拉到 1.2 之后模型开始大量胡说八道正确路径的比例低到投票救不回来。后来又试过 0.2路径全一样等于多花 N 倍钱跑了一遍。我现在的常用区间是temperature 0.5 到 0.8top_p 0.9 到 0.95。这个区间的效果是最稳定的既能保证路径之间有足够的措辞和思路差异又能保证单条路径的质量不塌。对于数学类任务我偏 0.6对于逻辑推理、多跳问答我偏 0.7对于选择题我偏 0.5因为这些任务的答案空间小路径太野反而容易跑偏。采样代码我用最简单的同步版本起步跑通再上并发import re from concurrent.futures import ThreadPoolExecutor def sample_one(client, prompt, temperature0.7, max_tokens1200): resp client.complete( promptprompt, temperaturetemperature, top_p0.95, max_tokensmax_tokens, stop[\n\n\n], ) return resp.text def sample_many(client, prompt, n8, temperature0.7, workers4): results [] with ThreadPoolExecutor(max_workersworkers) as pool: futures [ pool.submit(sample_one, client, prompt, temperature) for _ in range(n) ] for f in futures: try: results.append(f.result()) except Exception as e: print(f单次采样失败已跳过: {e}) return results并发数要跟你的接口限流匹配。我一般的经验是并发数不超过你配额上限的 70%留一点余量应对突发的重试。另外一定要收集异常而不是让它直接抛出去N 条路径里丢个一两条不影响投票但如果一条失败整批崩掉评测跑一晚上全废。提示如果接口支持一次返回多个候选很多 SDK 支持传 n 参数优先用它。一次请求内返回的结果共享同一次前缀计算token 成本比 N 次独立请求低不少我在一个长 prompt 的场景里实测能省下将近四成的开销。3.3 答案归一化这里翻车的概率比你想的高这一步是整个流水线里最枯燥、最容易出事、也最考验细节的地方。我把它拆成三层处理。第一层是抽取。用正则从完整输出里抠出最终答案后面那一段。如果抠不到降级处理找输出里最后一个数字、或者最后一个匹配选项字母的字符。降级策略一定要有因为总有一两条路径不听话。第二层是清洗。去掉首尾空白、去掉中文标点、去掉货币符号、去掉元个米这类单位后缀。如果答案是数字尝试转成浮点如果模型写了一百二十还得考虑要不要做中文数字转换。第三层是等价映射。这是最容易忽略的一层。比如你问哪个选项正确模型可能输出A、a、选项 A、A这四种其实就是同一个答案。你问总价多少模型可能输出120、120.0、120元、$120这四种也应该归为一类。做一层映射字典或者规则把它们统一。我见过有人在这一层偷懒结果投票统计里 8 条路径分成了 6 个不同的答案最高票只有 2 票聚合出来的结论几乎是随机的。回头一看其实有 5 条路径说得是同一个答案只是写法不同。def normalize(raw): if not raw: return None s raw.strip() s re.sub(r^[\s\-\*\], , s) s re.sub(r[。,\.!;:]$, , s) m re.search(r-?\d(?:\.\d)?, s.replace(,, )) if m: v float(m.group()) if v.is_integer(): return str(int(v)) return f{v:.6f}.rstrip(0).rstrip(.) m re.search(r[A-Da-d], s) if m: return m.group().upper() return s.lower()这段代码不长但它是我在实践里反复调整出来的覆盖了数字、小数、选项字母、其他文本四类情况。你可以拿去当起点然后针对自己任务的特点往里加规则。3.4 投票聚合与平票处理聚合这一步代码最短但平票的处理策略要想清楚。最简单的是用collections.Counter取最高票。问题是最高票并列怎么办。我试过三种策略各有适用场景补采样平票时再追加采样几条直到出现唯一最高票或者达到上限。准确率提升最明显成本最不可控。取最先出现的把平票的候选中按第一次出现的顺序选。实现最简单但结果带有采样顺序的偏好不够公平。降级重跑平票直接判定为无法确定降级到更严格的提示词或者人工审核。这种做法在评测场景里最诚实因为它不会给你一个假象。from collections import Counter def vote(answers): answers [a for a in answers if a is not None] if not answers: return None, 0.0 c Counter(answers) top c.most_common() best_count top[0][1] winners [k for k, v in top if v best_count] conf best_count / len(answers) return winners[0] if len(winners) 1 else None, conf我现在的默认策略是置信度低于 0.4 的样本打上标记进入二次复核队列不直接把最高票当正确答案。这套做法在一个数据标注项目里帮我拦下了大约 12% 的可疑样本人工复核后发现其中超过一半确实是模型判断出了问题。这个数字比任何参数调优都更有价值。4. 路径数与温度调参的边际收益曲线4.1 路径数的边际收益并不是线性的路径数 N 是这个方法里最直观的可调项也是最容易浪费预算的地方。我在一批数学应用题上做过一条完整的曲线样本量大概几百题用同一个模型、同样的提示词只改 N。几个关键点大致是这样的N1就是单次思维链准确率在 65% 左右N3 提到 76%N5 到 81%N8 到 85%N12 到 86%N20 到 87%N40 到 87.5%。看这条曲线你会发现一个很明显的拐点从 1 到 5 的收益占了全部收益的绝大部分从 5 到 20 加了三倍成本只换来不到 6 个点从 20 到 40 基本是一条横线。所以我的默认值是 N5 到 8。这个区间性价比最高投一条也不会太心痛。不同任务的拐点位置不一样。逻辑推理、多跳问答这类任务的拐点偏右一点N10 左右才收敛简单分类、选择题的拐点偏左N3 到 5 就够了。我的建议是先在任务的一个小样本上50 到 100 条跑一条 1、3、5、8、12、20 的曲线找到你自己的拐点再上全量。这半小时的投入能帮你省掉后面大量的预算。还有一个反直觉的观察N 越大方差越小但系统性错误也越稳定。也就是说如果模型在这个任务上存在某种系统性偏差比如总是把某个类型的单位搞错N40 之后你会得到一个极其稳定的错误答案。这时候你会误以为方法失效了其实是任务本身需要先修正提示词或者补样例。4.2 temperature 的两难低了没信息高了没质量temperature 和路径数是一对相互作用的参数不能分开调。我用一个二维的粗略实验总结了一张对照表temperature \ NN3N8N200.2路径几乎相同准确率≈单次微弱提升浪费预算0.5提升明显接近最优接近最优0.7提升明显最优附近最优附近1.0提升不稳定有可能反降大幅波动1.2大概率反降明显反降明显反降从这张表能看出两件事。第一温度太低时增加路径数没有意义因为路径本身是同质的投 20 次等于投 1 次。第二温度太高时增加路径数反而有害因为高温度的路径里有相当比例是胡言乱语这些乱语虽然不会形成共识但它们抢占了采样预算稀释了有效路径的比例。我个人的固定组合是temperature0.7 配 N8作为大多数任务的起点。这个组合我在数学、逻辑、多跳问答、代码调试几个不同任务上验证过跑出来的结果都在各自任务的最优附近误差可以接受。如果你的任务是选择题这种答案空间很小的可以降到 0.5 配 N5如果你的任务是开放式的结构化输出温度反而要更低一点。4.3 任务类型对方法的适配度差异不是所有任务都值得上自我一致性。我把它分成三档这张表是我在不同项目里摸出来的经验总结任务类型适配度原因数学计算、多步算术高答案唯一可验证正确路径天然多条逻辑推理、多跳问答高推理链长单次方差大正确路径集中选择题、分类任务中高答案空间小但通常单次准确率已经很高收益有限代码生成中可以按测试通过率投票但一致不等于正确信息抽取、结构化输出中需要极强的归一化字段对齐麻烦开放式写作、创意生成低答案空间无限聚合退化到最平庸版本长文档总结低同上且单次成本已经很高对于最后一类的对比我印象很深。有一次我在一个文案改写任务上试自我一致性本来想的是多个版本投票取共识结果跑出来的共识版本比任何一条单次输出都要平淡因为最保守、最没风险的表达方式路径最多。这提示了一个根本性的道理自我一致性假设多数即正确这个假设只在答案有客观对错的任务上成立。创意类任务里多数恰恰意味着最不出彩。5. 投票结果和直觉打架四条排查链路5.1 第一条链路投票异常先查答案抽取这一步这条链路是我遇到频次最高的问题。现象是明明人工看一眼就知道答案是对的但投票结果给了一个看起来毫不相干的答案或者置信度极低。排查顺序我固定成这样先把所有 N 条路径的原始输出、抽取结果、归一化结果并排打出来人眼看一遍。这一步能解决 70% 的问题。常见的情况有几种有两条路径的答案是120 元被抽成了120有两条是约 120没被抽出来因为正则只认数字开头还有一条模型在答案行写了最终答案120单位元括号把后面全吃进去了。我遇到过一个特别典型的案例题目问的是需要多少分钟模型给出的答案有的是45 分钟有的是0.75 小时有的是45。三种写法归一化后变成三个不同的字符串8 条路径最高票只有 3 票。修好归一化之后7 条路径统一到了45置信度从 0.375 跳到 0.875。有个土办法很有效打印前先对 N 条答案做一次set()看看有多少个不同的值。如果不同值的个数接近 N那几乎肯定是归一化出了问题不是模型的问题。修好归一化之后如果还不对再看是不是提示词里对答案格式的要求不够死。有时候模型体贴地补充了一句说明把格式搞乱了这时候就要在提示词里把只输出答案本身不要任何附加说明这句话加粗强调或者干脆用分隔符做硬性限制。5.2 第二条链路所有路径错得一模一样现象是置信度极高比如 8 条全票同一个但人工验证是错的。这种结果最坑人因为它看起来特别可信。我的第一条判断标准是如果 N 条路径不仅答案一样连推理过程都高度雷同那大概率是模型的知识或者理解出了问题与采样无关加大 N 完全没用。这时候要往回查的是提示词里有没有引入误导。我踩过两个具体的坑一个是题目里的术语有歧义模型统一按错误的理解做了另一个是我在提示词里给了一个相似示例示例的表达方式和本题略有差异模型照搬了示例里的思路。还有一种情况是任务本身超出了模型能力。我早期用它跑一批很偏门的专业题目模型在零样本下几乎没有相关知识采样出来的答案全是同一种编。这种问题靠 Prompt 工程解决不了得补上下文RAG或者换更强的模型。诊断方法很简单拿一道你确定模型有能力做对的题目跟这道出错的题目放在一起对比跑如果前者表现正常、后者全票错误基本可以定位在任务难度或者提示词歧义上。如果两者一起错那可能是提示词模板本身有系统性缺陷。5.3 第三条链路看似在投票其实路径并不独立这条链路最隐蔽因为它不出现在单条输出里而是出现在整批数据的一致性上。现象是跑出来的置信度普遍偏高都在 0.8 以上但准确率不涨甚至比单次还略降。我排查到这个问题的过程有点曲折。当时我为了省事把 N 条路径的调用放在一个带缓存的客户端后面以为缓存只在相同请求时生效、不会有影响。结果那个客户端按前缀做缓存N 条路径只有最后一句随机措辞不同前缀全同命中了同一次计算结果返回的其实是同一份文本的低配版本。相当于花了 N 倍的钱跑的都是同一条路径。排查这一类问题我总结出三个检查点检查请求的完整参数除了提示词以外随机种子、temperature、top_p 是不是真的每次都传了有没有被默认值覆盖检查客户端缓存如果用了 CDN 或者代理层缓存确认缓存键包含所有可变参数检查提示词模板N 条路径是不是真的只差随机性如果你给每条路径塞了不同的小标题或者不同的引导语那就不是在跑自我一致性了自检的办法也很直接对 N 条输出做一次相似度计算比如简单的 n-gram 重叠如果平均重叠度高到 0.9 以上路径显然不够独立要么调高温度要么检查上面三个点。5.4 第四条链路正确路径存在但概率质量太分散这条链路是最讲究的一条因为它不是 bug是这套方法的固有局限。现象是N 条路径里确实有 2 到 3 条走对了但也确实有更好的几条走了不同的弯路导致正确路径的票数不够集中输掉了投票。举个例子一道有多种解法的几何题正确的两条路径一个用三角恒等式、一个用坐标法错误的两条路径一个算错符号、一个漏了一个条件还有三条路径走的是看起来像那么回事的近似估算。三条路径各投了不同的错答案两条正确路径也只能拿到 2 票最后输给了一个 3 票的错误答案。应对这种情况我能想到的招有两个。第一个是在提示词里做思路引导让模型优先走某一条确定可靠的路比如加上请优先使用代数方法这种约束把路径收窄到一条质量最高的主干上。这样做的代价是牺牲了一部分多样性但准确率通常更稳。第二个是N 拉大从 8 拉到 15 到 20正确路径的票数有更大概率浮出水面。我一般先试思路引导因为它成本低思路引导搞不定再拉大 N。6. 成本账与替代方案什么时候不值得用6.1 算一笔成本与延迟的真实账自我一致性的成本是一个 1 乘以 N 的放大。你跑 8 条路径token 成本就是单次的 8 倍这是账面上能看到的。真正容易被忽略的是延迟如果串行跑8 条路径的响应时间就是单次的 8 倍一个原本 3 秒返回的请求变成 24 秒这在实时场景里是灾难。并发能把这个时间压下来。8 条并发、每条约 3 秒总体响应时间大概在 4 到 5 秒之间首尾加中间的一点调度开销。但如果你的接口配额有限并发上不去那延迟就会爆炸。方案相对成本相对延迟并发准确率相对单次单次思维链1x1x基准N3 自一致性3x1.1x8 个点经验值N5 自一致性5x1.2x14 个点N8 自一致性8x1.3x18 个点N20 自一致性20x2x20 个点表里的百分比是基于我跑过的几个数学和逻辑类任务的均值不同任务差异很大只能看相对趋势。看这张表你会发现N 从 5 到 8 增加了 60% 的成本换来的准确率提升不到 4 个点N 从 8 到 20 增加了一倍多的成本几乎没提升。所以除非任务对准确率极度敏感N5 是大多数人最优的选择。我现在的默认配置就是 N5 打底碰到个别困难样本再触发补采样到 N12。6.2 这些场景下用了纯属浪费我有几类任务是明确不上自我一致性的摆在明面上说清楚第一类是单次准确率已经稳定在 95% 以上的任务比如给一句短文本做情感极性判断、判断两个句子是否语义等价。这类任务的方差本来就小投票等于用 N 倍成本换千分之几的提升纯纯浪费。第二类是低延迟场景比如在线对话、实时搜索。用户等不了 5 秒你只能走单次。第三类是开放式生成前面已经分析过投票会让结果趋平庸。第四类是长文档处理单次成本已经很高N 倍之后账单会失控且长文档里的信息互相干扰路径之间的差异往往来自关注到了不同的段落而不是推理过程不同投票在这里失去了意义。第五类是探索性任务比如让模型列举十种可能的解题方向、十种可能的产品定位。这类任务你要的是多样性投票恰恰会把多样性抹平。6.3 和思维链、自反思、best-of-n 的组合关系最后梳理一下这套方法在 Prompt 工程工具箱里的位置很多人容易把它们搞混。思维链是自我一致性的地基没有思维链自我一致性就失去了可投票的中间过程不知道路径长什么样也就没有多条路径这回事。实践上通常是把两者叠起来用也就是常说的带思维链的自一致性。自反思Self-Refine / Reflexion是另一个方向它的做法是让模型先给一个答案再自己检查发现问题就改。这套方法省成本通常是两三轮但它的假设是模型能看出自己的错误而这个假设在实践中经常不成立——模型对自己犯的错误往往格外宽容。我在几个任务上对比过自反思的提升不如自一致性稳定尤其是在推理类任务上。best-of-n 加验证器是另一个思路多生成几个候选然后用一个独立的验证手段可能是另一个模型、可能是执行测试用例、可能是规则检查挑出最好的那个。这套方法在代码生成上特别有效因为你可以真的跑一遍测试。但它需要额外构建验证器工程投入比自我一致性大得多。帮我选一条路线的简单经验任务有可执行验证代码、SQL、可跑的计算就走 best-of-n 加验证器任务只有文本答案、且模型有基本能力做对就走自一致性任务需要探索不同可能性就什么投票都别用直接跑多次采样让用户挑。我在几个不同规模的项目上跑下来最深的一个体会是自我一致性不是让模型变聪明而是让模型的输出变得可度量。它把这个模型靠不靠谱从一个主观判断变成了一个置信度数字。一旦你有了这个数字就可以做很多工程上的事置信度高的自动通过、置信度低的进人工队列、整体置信度分布可以当质量监控看板、置信度的变化可以当回归测试的告警。这套东西真正的价值不在于那十几个点的准确率提升而在于它把不确定的东西变成了一个可以在流水线里被处理的对象。至于什么时候该停手不用它我的判断很简单当你发现加了自我一致性之后置信度一直在 0.9 以上而准确率没什么变化那就是该把注意力从采样挪到提示词和上下文的时候了。