1. 單路推理為什么在數(shù)學(xué)題上翻車自一致性多路采樣投票到底解決什么問(wèn)題如果你用大模型做過(guò)數(shù)學(xué)應(yīng)用題、邏輯推理題或者需要多步計(jì)算的場(chǎng)景大概率遇到過(guò)這種情況同一道題問(wèn)一次答 56 分換個(gè)說(shuō)法再問(wèn)一次可能就對(duì)了但你自己也不知道哪次靠譜。這不是模型“不穩(wěn)定”這么簡(jiǎn)單而是單路貪心解碼temperature0本身就把模型鎖死在一條推理路徑上——這條路徑一旦在某一步走偏后面全錯(cuò)而且錯(cuò)得理直氣壯。自一致性Self-Consistency的思路很樸素既然一條路可能走偏那就讓模型走 N 條不同的路最后看哪條路上的“終點(diǎn)答案”被最多條路走到。它的核心假設(shè)是——正確答案比任何單一錯(cuò)誤答案更可能被多條獨(dú)立推理鏈采樣到。注意這里的關(guān)鍵詞是“獨(dú)立”如果 N 條鏈都因?yàn)橥瑯拥奶崾驹~、同樣的溫度、同樣的隨機(jī)種子而趨同那投票就沒(méi)有意義只是把同一個(gè)錯(cuò)誤重復(fù)了 N 遍。我實(shí)測(cè)下來(lái)這個(gè)假設(shè)在 GSM8K 這類有唯一數(shù)值答案的任務(wù)上成立得相當(dāng)好。單路 CoTT0準(zhǔn)確率大約 56.9%而 N10、T0.7 的自一致性可以拉到 70% 上下N40 能到 74% 左右。但代價(jià)也很直白token 成本是單路的 N 倍。所以真正要解決的問(wèn)題不是“要不要用自一致性”而是“在什么任務(wù)上、用多大的 N、配什么溫度、選哪種投票策略才能讓邊際收益覆蓋成本”。這篇文章面向的是已經(jīng)在用 LLM 做推理任務(wù)、想把它工程化落地的開發(fā)者。我會(huì)用 TaoToken 的統(tǒng)一 Key 和 API 通道把多路采樣、溫度掃描、四種投票策略、Universal SC 以及采樣數(shù)自適應(yīng)停止這一整套流程跑通。你不需要準(zhǔn)備多個(gè)廠商的 Key也不需要為并發(fā)限制寫一堆輪詢邏輯——一個(gè) Key 走統(tǒng)一入口把精力放在策略本身。適合誰(shuí)看做過(guò) CoT 提示、被“同一問(wèn)題兩次答案不一樣”困擾過(guò)、或者正在評(píng)估推理成本與準(zhǔn)確率平衡點(diǎn)的人。如果你只是想讓模型聊聊天這篇可能有點(diǎn)重但如果你要把推理任務(wù)放進(jìn)生產(chǎn)流程下面這些配置和腳本可以直接抄。2. TaoToken 統(tǒng)一 Key 與 API 通道多路采樣并發(fā)的前置準(zhǔn)備自一致性最現(xiàn)實(shí)的工程障礙不是算法是并發(fā)。N10 意味著同一道題要發(fā) 10 次請(qǐng)求如果串行調(diào)用延遲直接 8 到 15 秒并行調(diào)用又容易撞上單賬號(hào)的并發(fā)上限。我試過(guò)用多個(gè)廠商 Key 輪詢維護(hù)成本高得離譜——每個(gè)廠商的鑒權(quán)頭、錯(cuò)誤碼、限流策略都不一樣光是對(duì)齊就夠?qū)懸粋€(gè)中間層了。TaoToken 在這里的價(jià)值是它提供一個(gè)統(tǒng)一的 API 入口和統(tǒng)一的 Key你不需要為每個(gè)模型單獨(dú)管理憑證也不需要為并發(fā)去拼多個(gè)賬號(hào)。Base URL 固定為https://taotoken.net/api所有模型走同一個(gè)通道請(qǐng)求格式保持 OpenAI 兼容。這意味著你現(xiàn)有的openaiSDK 或者requests腳本幾乎不用改只換 base_url 和 api_key 就能跑。前置準(zhǔn)備只有三步但每一步都有坑我按順序說(shuō)。第一步拿到 Key。訪問(wèn)https://taotoken.net/api-keys注意這個(gè) deep link 帶 utm 參數(shù)方便你直接落到 Key 管理頁(yè)創(chuàng)建一個(gè) API Key。建議給這個(gè) Key 起個(gè)能區(qū)分的名字比如self-consistency-bench因?yàn)楹竺婺憧赡軙?huì)有多個(gè)項(xiàng)目共用命名清晰能省很多排查時(shí)間。Key 只在創(chuàng)建時(shí)完整顯示一次復(fù)制后立刻存到環(huán)境變量里別寫死在腳本里。第二步確認(rèn)你要用的模型 ID。自一致性對(duì)模型的“溫度響應(yīng)曲線”很敏感不同模型在 T0.7 時(shí)的質(zhì)量下降幅度不一樣。所以第一步不是直接跑投票而是先確認(rèn)你手頭這個(gè)模型在目標(biāo)溫度下還能不能給出可用的推理鏈。模型 ID 可以在https://taotoken.net/models或者模型對(duì)話頁(yè)https://taotoken.net/chat里查到選一個(gè)你打算長(zhǎng)期用的。第三步把環(huán)境變量配好。我習(xí)慣用.env文件加python-dotenv這樣腳本和 notebook 都能復(fù)用# .env TAOTOKEN_API_KEYsk-你的key TAOTOKEN_BASE_URLhttps://taotoken.net/api然后在 Python 里這樣初始化客戶端import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(TAOTOKEN_API_KEY), base_urlos.getenv(TAOTOKEN_BASE_URL), ) MODEL_ID 你的模型ID # 從模型列表里選一個(gè)這里有個(gè)容易忽略的點(diǎn)base_url結(jié)尾不要帶/v1TaoToken 的通道已經(jīng)處理好了路徑你多寫一層反而會(huì) 404。我第一次配的時(shí)候就是習(xí)慣性加了/v1結(jié)果報(bào)了一堆Not Found排查了十分鐘才反應(yīng)過(guò)來(lái)。并發(fā)方面TaoToken 的統(tǒng)一通道讓你可以用concurrent.futures直接開線程池不需要為每個(gè)廠商單獨(dú)寫限流。但即便如此N20 以上還是建議加一個(gè)簡(jiǎn)單的信號(hào)量控制避免瞬時(shí)打滿。下面這個(gè)并發(fā)采樣器是我實(shí)際在用的N 路并行帶超時(shí)和重試import concurrent.futures from tenacity import retry, stop_after_attempt, wait_exponential retry(stopstop_after_attempt(3), waitwait_exponential(multiplier1, min1, max8)) def sample_once(question, temperature, seed): resp client.chat.completions.create( modelMODEL_ID, messages[ {role: system, content: 請(qǐng)逐步推理最后用『答案是』引出最終結(jié)果。}, {role: user, content: question}, ], temperaturetemperature, seedseed, max_tokens1024, ) return resp.choices[0].message.content def parallel_sample(question, n_samples, temperature): results [] with concurrent.futures.ThreadPoolExecutor(max_workersmin(n_samples, 10)) as ex: futures [ ex.submit(sample_once, question, temperature, i) for i in range(n_samples) ] for f in concurrent.futures.as_completed(futures): try: results.append(f.result()) except Exception as e: print(f采樣失敗: {e}) return resultsmax_workers我設(shè)成min(n_samples, 10)是因?yàn)榇蠖鄶?shù)通道對(duì)單 Key 的并發(fā)在 10 左右比較穩(wěn)再高容易觸發(fā)限流。如果你確實(shí)需要 N20 以上可以把這個(gè)值調(diào)到 10 然后讓線程池排隊(duì)或者用多個(gè) Key 輪詢——但那是另一個(gè)話題了。到這里前置準(zhǔn)備就完成了一個(gè) Key、一個(gè) Base URL、一個(gè)模型 ID加上一個(gè)能并發(fā)的采樣函數(shù)。接下來(lái)才是自一致性的核心——溫度怎么選、答案怎么提取、票怎么投。3. 可復(fù)制的多路采樣配置與投票腳本溫度、提取、投票三件套這一節(jié)是全文的技術(shù)核心我會(huì)把配置拆成三塊采樣溫度、答案提取、投票策略。每一塊都給可復(fù)制的代碼和參數(shù)說(shuō)明你改改模型 ID 就能跑。3.1 采樣溫度多樣性-質(zhì)量的倒 U 型曲線溫度決定采樣的多樣性。溫度太低N 條鏈幾乎一模一樣投票退化成單路溫度太高推理鏈質(zhì)量崩壞投票選出來(lái)的是“最常見的錯(cuò)誤”。GSM8K 上的實(shí)測(cè)數(shù)據(jù)大致是這樣T0.3 時(shí)多樣性只有 0.12準(zhǔn)確率 68% 左右T0.5 多樣性 0.31準(zhǔn)確率 71%T0.7 多樣性 0.48準(zhǔn)確率 72% 上下是多數(shù)任務(wù)的甜點(diǎn)T0.9 多樣性 0.67 但準(zhǔn)確率掉到 70% 以下T1.1 噪聲開始主導(dǎo)準(zhǔn)確率 64% 左右。但這里有個(gè)必須強(qiáng)調(diào)的邊界最優(yōu)溫度強(qiáng)依賴模型。同一個(gè)任務(wù)上有的模型在 T0.5 最穩(wěn)有的在 T0.8 還很好。原因是不同模型的“溫度響應(yīng)曲線”不同——有的模型在 T0.7 時(shí)質(zhì)量下降明顯有的到 T0.9 才崩。所以工程上不要抄別人的溫度要用自己的模型跑一次溫度掃描。下面這個(gè)掃描腳本用 50 個(gè)標(biāo)注樣本、5 個(gè)溫度點(diǎn)大約幾十次調(diào)用就能定位你模型的最優(yōu)溫度def temperature_scan(questions, answer_key, temps(0.3, 0.5, 0.7, 0.9, 1.1), n_samples10): report {} for t in temps: correct, total, diversities 0, 0, [] for q in questions: chains parallel_sample(q, n_samples, t) answers [extract_answer(c) for c in chains] answers [a for a in answers if a is not None] if not answers: continue from collections import Counter final, votes Counter(answers).most_common(1)[0] if final answer_key[q]: correct 1 total 1 diversities.append(len(set(answers)) / len(answers)) acc correct / max(total, 1) div sum(diversities) / max(len(diversities), 1) report[t] {accuracy: round(acc, 4), diversity: round(div, 4), score: round(acc * 0.7 div * 0.3, 4)} best max(report, keylambda t: report[t][score]) return {optimal_temp: best, details: report}跑完之后你會(huì)得到一張表形如溫度準(zhǔn)確率多樣性綜合分0.30.6810.120.5130.50.7130.310.5920.70.7240.480.6510.90.6980.670.6101.10.6420.780.583綜合分用準(zhǔn)確率 * 0.7 多樣性 * 0.3是我自己的權(quán)重你可以按任務(wù)調(diào)。多選題任務(wù)選項(xiàng)有限不需要高多樣性最優(yōu)溫度往往更低T0.5 左右開放任務(wù)需要探索不同思路最優(yōu)溫度更高T0.9 左右。找到之后固定下來(lái)別每次跑都重新掃。3.2 答案提取別讓提取失敗浪費(fèi)你的采樣自一致性的一個(gè)隱藏成本是答案提取。如果 N10 條鏈里有 3 條提取失敗那這 3 條的采樣成本就白花了而且投票基數(shù)變小置信度也不準(zhǔn)。提取規(guī)則要盡量寬松但明確。我用的提取函數(shù)是這樣的按優(yōu)先級(jí)匹配多個(gè)標(biāo)記import re def extract_answer(chain: str): if not chain: return None # 優(yōu)先匹配明確的答案標(biāo)記 for marker in [答案是, 答案:, 答案, 最終答案, 所以]: if marker in chain: tail chain.split(marker, 1)[1] # 取標(biāo)記后第一段去掉標(biāo)點(diǎn)和空白 token re.split(r[\s。,;], tail.strip())[0] token token.strip(。.,;:) if token: return token # 兜底抓最后一個(gè)數(shù)字 nums re.findall(r-?\d\.?\d*, chain) if nums: return nums[-1] return None這里有幾個(gè)實(shí)戰(zhàn)細(xì)節(jié)。第一標(biāo)記順序很重要“答案是”比“所以”更明確應(yīng)該優(yōu)先。第二split之后要按標(biāo)點(diǎn)和空白切否則會(huì)把一整句話當(dāng)成答案。第三兜底抓數(shù)字只適合數(shù)值任務(wù)開放任務(wù)不要用這個(gè)兜底否則會(huì)把無(wú)關(guān)數(shù)字當(dāng)答案。提取失敗率是你要監(jiān)控的指標(biāo)。如果失敗率超過(guò) 20%說(shuō)明要么提示詞沒(méi)讓模型規(guī)范輸出要么提取規(guī)則太嚴(yán)。前者改 system prompt后者放寬規(guī)則。我一般會(huì)在 system prompt 里明確要求“最后一行必須以『答案是 X』結(jié)尾”這樣提取成功率能到 95% 以上。3.3 四種投票策略多數(shù)、加權(quán)、置信度、分層多數(shù)投票是最簡(jiǎn)單的統(tǒng)計(jì)每個(gè)答案出現(xiàn)的次數(shù)取最高的。代碼就三行from collections import Counter def majority_vote(answers): answers [a for a in answers if a is not None] if not answers: return None, 0, 0 final, votes Counter(answers).most_common(1)[0] return final, votes, len(answers)加權(quán)投票給每條鏈一個(gè)權(quán)重。常見的加權(quán)信號(hào)是鏈長(zhǎng)度但這里有個(gè)反直覺(jué)的發(fā)現(xiàn)長(zhǎng)鏈不一定更可信。在 300 個(gè)任務(wù)上超過(guò) 500 token 的長(zhǎng)鏈正確率反而比短鏈低 4 個(gè)百分點(diǎn)左右——冗長(zhǎng)推理往往是模型在“繞彎子”。更可靠的加權(quán)信號(hào)是“鏈里是否含驗(yàn)證步驟”含“驗(yàn)算”“復(fù)查”“檢查”的鏈正確率比無(wú)驗(yàn)證的高 12 個(gè)百分點(diǎn)。所以我的加權(quán)投票用的是“驗(yàn)證感知加權(quán)”def weighted_vote(samples): weights {} for s in samples: ans s[answer] if ans is None: continue w 1.0 chain s[chain] if any(k in chain for k in [驗(yàn)算, 復(fù)查, 檢查, 驗(yàn)證]): w 0.5 if len(chain) 500: w - 0.2 weights[ans] weights.get(ans, 0) w if not weights: return None return max(weights, keyweights.get)置信度投票讓 LLM 給每條鏈打分最準(zhǔn)但最貴——N20 就多 20 次調(diào)用。分層投票按答案類型分組再組內(nèi)投票在答案分布偏斜的任務(wù)上有優(yōu)勢(shì)。GSM8K N20 上四種策略的對(duì)比大致是多數(shù) 72.4%、加權(quán) 72.8%、置信度 74.1%、分層 72.6%。置信度最準(zhǔn)但成本翻倍多數(shù)投票性價(jià)比最高。3.4 完整配置片段把上面三塊拼起來(lái)一個(gè)可復(fù)制的自一致性配置長(zhǎng)這樣。如果你用配置文件管理可以寫成 JSON{ self_consistency: { model_id: 你的模型ID, n_samples: 10, temperature: 0.7, max_workers: 10, vote_strategy: majority, extract_markers: [答案是, 答案:, 最終答案], adaptive_stop: { enabled: true, min_samples: 5, max_samples: 20, consistency_threshold: 0.8 } } }如果你用 TOML比如某些 Agent 框架的配置等價(jià)寫法是[self_consistency] model_id 你的模型ID n_samples 10 temperature 0.7 max_workers 10 vote_strategy majority [self_consistency.adaptive_stop] enabled true min_samples 5 max_samples 20 consistency_threshold 0.8注意model_id、base_url、api_key這三件套要一致Base URL 是https://taotoken.net/apiKey 從https://taotoken.net/api-keys拿Model ID 從模型列表確認(rèn)。任何一處對(duì)不上都會(huì)在驗(yàn)證請(qǐng)求時(shí)報(bào)錯(cuò)下一節(jié)會(huì)講怎么排查。4. 端到端驗(yàn)證從單路到多路投票的穩(wěn)定性對(duì)比配置寫好了接下來(lái)要證明它真的有用。驗(yàn)證分兩步先跑單路基線再跑多路投票對(duì)比同一批問(wèn)題上的準(zhǔn)確率和穩(wěn)定性。先準(zhǔn)備一批測(cè)試題。我用 GSM8K 風(fēng)格的數(shù)學(xué)題每道題有唯一數(shù)值答案。為了演示這里用幾道手寫題test_cases [ {q: 小明有 12 個(gè)蘋果給了小紅 5 個(gè)又買了 8 個(gè)現(xiàn)在有多少個(gè), a: 15}, {q: 一個(gè)班 40 人60% 是女生女生有多少人, a: 24}, {q: 一本書 320 頁(yè)每天讀 40 頁(yè)讀完需要幾天, a: 8}, {q: 3 個(gè)工人 4 小時(shí)做 72 個(gè)零件6 個(gè)工人 5 小時(shí)做多少個(gè), a: 180}, {q: 一件商品原價(jià) 200 元打 8 折后再減 20 元最終價(jià)格是多少, a: 140}, ]單路基線就是 temperature0、N1def single_path(question): resp client.chat.completions.create( modelMODEL_ID, messages[ {role: system, content: 請(qǐng)逐步推理最后用『答案是』引出最終結(jié)果。}, {role: user, content: question}, ], temperature0.0, max_tokens1024, ) chain resp.choices[0].message.content return extract_answer(chain), chain多路投票用前面拼好的配置def self_consistency(question, n_samples10, temperature0.7): chains parallel_sample(question, n_samples, temperature) samples [{chain: c, answer: extract_answer(c)} for c in chains] answers [s[answer] for s in samples if s[answer] is not None] final, votes, total majority_vote(answers) return { answer: final, votes: votes, total: total, confidence: votes / total if total else 0, samples: samples, }跑對(duì)比single_correct 0 sc_correct 0 for case in test_cases: s_ans, _ single_path(case[q]) sc self_consistency(case[q], n_samples10, temperature0.7) if s_ans case[a]: single_correct 1 if sc[answer] case[a]: sc_correct 1 print(f題: {case[q][:20]}... 單路{s_ans} 多路{sc[answer]} f票數(shù){sc[votes]}/{sc[total]} 置信度{sc[confidence]:.2f}) print(f單路準(zhǔn)確率: {single_correct}/{len(test_cases)}) print(f多路準(zhǔn)確率: {sc_correct}/{len(test_cases)})成功的結(jié)果長(zhǎng)這樣單路可能對(duì) 3 道多路對(duì) 4 到 5 道而且多路會(huì)給出一個(gè)置信度——比如票數(shù)8/10 置信度0.80說(shuō)明 10 條鏈里有 8 條給出了同一個(gè)答案。這個(gè)置信度本身就是很有用的信號(hào)置信度低于 0.6 的題你可以標(biāo)記出來(lái)人工復(fù)核或者觸發(fā)追加采樣。我實(shí)測(cè)下來(lái)多路投票的穩(wěn)定性提升主要體現(xiàn)在“單路偶爾翻車”的題上。單路對(duì)同一道題跑 5 次可能 3 次對(duì) 2 次錯(cuò)多路投票跑 5 次5 次結(jié)果基本一致。這就是自一致性的真正價(jià)值——不是把準(zhǔn)確率從 0 拉到 100而是把“時(shí)好時(shí)壞”變成“穩(wěn)定可預(yù)期”。如果你想進(jìn)一步驗(yàn)證可以跑一個(gè)“重復(fù)實(shí)驗(yàn)”同一批題單路跑 5 輪、多路跑 5 輪看每輪的準(zhǔn)確率波動(dòng)。單路的波動(dòng)通常在 ±10 個(gè)百分點(diǎn)多路能壓到 ±3 個(gè)百分點(diǎn)以內(nèi)。這個(gè)波動(dòng)收窄對(duì)生產(chǎn)環(huán)境比絕對(duì)準(zhǔn)確率更重要。驗(yàn)證通過(guò)后你可以把self_consistency函數(shù)封裝成一個(gè)可復(fù)用的類加上緩存同一問(wèn)題同一配置的結(jié)果緩存起來(lái)避免重復(fù)采樣和日志記錄每次的票數(shù)分布用于后續(xù)分析。緩存用functools.lru_cache或者簡(jiǎn)單的字典都行但注意緩存 key 要包含模型 ID、溫度、N否則換配置會(huì)讀到舊結(jié)果。5. 常見報(bào)錯(cuò)排查401、local proxy failed、reading choices、OAuth這一節(jié)按真實(shí)報(bào)錯(cuò)來(lái)。自一致性因?yàn)橐l(fā)多次請(qǐng)求報(bào)錯(cuò)會(huì)比單路調(diào)用更頻繁而且有些錯(cuò)誤只在并發(fā)時(shí)出現(xiàn)。401 Unauthorized。最常見的原因是 Key 沒(méi)讀到或者讀錯(cuò)了。先檢查.env文件是否被load_dotenv()正確加載——如果你在 notebook 里跑工作目錄可能不是.env所在目錄load_dotenv()會(huì)靜默失敗。加一句print(os.getenv(TAOTOKEN_API_KEY)[:8])確認(rèn) Key 前 8 位能打出來(lái)。另一個(gè)原因是 Key 復(fù)制時(shí)帶了空格或換行strip()一下。還有一種情況是 Key 被禁用或額度耗盡去https://taotoken.net/api-keys確認(rèn)狀態(tài)。local proxy failed / Connection error。這個(gè)報(bào)錯(cuò)通常和網(wǎng)絡(luò)環(huán)境有關(guān)。先確認(rèn)base_url寫的是https://taotoken.net/api沒(méi)有多余路徑。如果你本地配了系統(tǒng)級(jí)代理某些 HTTP 客戶端會(huì)嘗試走代理導(dǎo)致連接失敗可以在客戶端初始化時(shí)顯式關(guān)掉代理import httpx client OpenAI( api_keyos.getenv(TAOTOKEN_API_KEY), base_urlos.getenv(TAOTOKEN_BASE_URL), http_clienthttpx.Client(trust_envFalse), # 忽略系統(tǒng)代理環(huán)境變量 )trust_envFalse讓 httpx 不讀HTTP_PROXY/HTTPS_PROXY環(huán)境變量能解決大部分本地代理導(dǎo)致的連接問(wèn)題。Error reading choices / KeyError choices。這個(gè)報(bào)錯(cuò)說(shuō)明響應(yīng)體里沒(méi)有choices字段通常是請(qǐng)求被拒或者返回了錯(cuò)誤結(jié)構(gòu)。先打印完整響應(yīng)看看try: resp client.chat.completions.create(...) print(resp) except Exception as e: print(f原始錯(cuò)誤: {e})常見原因是模型 ID 寫錯(cuò)了——比如把gpt-4寫成gpt4通道找不到模型會(huì)返回錯(cuò)誤結(jié)構(gòu)。去模型列表確認(rèn)準(zhǔn)確的 ID。另一個(gè)原因是max_tokens設(shè)得太大超過(guò)了模型上限或者temperature超出范圍必須在 0 到 2 之間。并發(fā)場(chǎng)景下還可能因?yàn)樗矔r(shí)請(qǐng)求過(guò)多被限流返回的也是非標(biāo)準(zhǔn)結(jié)構(gòu)加tenacity重試能緩解。OAuth / authentication 相關(guān)報(bào)錯(cuò)。如果你用的是某些 CLI 工具比如 Claude Code 或 Codex 風(fēng)格的客戶端它們可能默認(rèn)走 OAuth 流程而不是 API Key。這時(shí)候要確認(rèn)工具支持自定義 Base URL 和 API Key。以 Claude Code 為例它需要配置ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY兩個(gè)環(huán)境變量Base URL 指向https://taotoken.net/apiKey 用你的 TaoToken Key。如果工具只認(rèn) OAuth 不認(rèn) API Key那就沒(méi)法直接用需要換支持 API Key 的客戶端。并發(fā)相關(guān)的隱性錯(cuò)誤。N20 以上時(shí)你可能會(huì)看到部分請(qǐng)求成功、部分超時(shí)。這不是配置錯(cuò)誤是并發(fā)上限。解決辦法有三個(gè)把max_workers降到 10 讓線程池排隊(duì)用多個(gè) Key 輪詢每個(gè) Key 一個(gè)客戶端實(shí)例或者用自適應(yīng)停止減少實(shí)際采樣數(shù)。我一般用第一種簡(jiǎn)單可靠。答案提取失敗率過(guò)高。這不是報(bào)錯(cuò)但會(huì)讓投票失效。如果日志里answer is None的比例超過(guò) 20%先檢查 system prompt 有沒(méi)有明確要求輸出格式再檢查提取函數(shù)的標(biāo)記列表是否覆蓋了模型的實(shí)際輸出。有的模型喜歡說(shuō)“因此答案是”有的喜歡說(shuō)“所以結(jié)果為”標(biāo)記列表要按你的模型補(bǔ)全。排查順序建議先確認(rèn) Key 和 Base URL401 和連接錯(cuò)誤再確認(rèn)模型 IDchoices 錯(cuò)誤再看并發(fā)和提取隱性錯(cuò)誤。大部分問(wèn)題在前兩步就能定位。6. 把自一致性接進(jìn)你的推理流程從驗(yàn)證到長(zhǎng)期運(yùn)行驗(yàn)證跑通之后下一步是把它變成可長(zhǎng)期運(yùn)行的東西。這里給幾條我踩過(guò)坑之后的經(jīng)驗(yàn)。第一采樣數(shù)用自適應(yīng)停止別固定 N。固定 N10 在簡(jiǎn)單任務(wù)上浪費(fèi)在困難任務(wù)上不夠。自適應(yīng)策略是先采 5 條如果答案一致性超過(guò) 80%比如 5 條里 4 條以上同答案就停止否則追加到 20 條。這樣在 60% 的簡(jiǎn)單任務(wù)上只用 5 次采樣成本省一半延遲也降下來(lái)。實(shí)現(xiàn)上就是在self_consistency里加一個(gè)循環(huán)每次多采幾條檢查一致性達(dá)標(biāo)就 break。第二把置信度用起來(lái)。多路投票的副產(chǎn)品是置信度最高票數(shù) / 總有效票數(shù)。置信度高于 0.8 的結(jié)果可以直接用0.6 到 0.8 的標(biāo)記為“待復(fù)核”低于 0.6 的要么追加采樣要么轉(zhuǎn)人工。這個(gè)分層處理能讓你的系統(tǒng)在準(zhǔn)確率和成本之間找到平衡而不是所有題都花 N 倍成本。第三緩存和日志。同一道題、同一配置的結(jié)果緩存起來(lái)避免重復(fù)采樣。日志記錄每次的票數(shù)分布、提取失敗數(shù)、延遲這些數(shù)據(jù)積累起來(lái)能幫你優(yōu)化溫度和 N 的選擇。我一般用 SQLite 存日志查詢方便也不重。第四注意任務(wù)適配。自一致性假設(shè)“正確答案唯一”在開放任務(wù)創(chuàng)意寫作、方案設(shè)計(jì)上多數(shù)投票會(huì)選“最常見”而非“最優(yōu)”。這類任務(wù)要么用 Universal SC讓 LLM 讀所有鏈后投票要么干脆不用自一致性。判斷標(biāo)準(zhǔn)很簡(jiǎn)單如果同一道題的兩個(gè)不同答案都可能正確就別用多數(shù)投票。如果你要把這套流程長(zhǎng)期跑在生產(chǎn)環(huán)境建議用 Coding Plan 這類面向持續(xù)編碼和 Agent 場(chǎng)景的方案配合統(tǒng)一的 API 通道省去多 Key 管理和并發(fā)調(diào)度的麻煩。模型對(duì)話頁(yè)可以用來(lái)快速驗(yàn)證單個(gè)模型的溫度響應(yīng)接入文檔里有完整的參數(shù)說(shuō)明和錯(cuò)誤碼對(duì)照。最后說(shuō)一個(gè)我自己的判斷自一致性不是銀彈它的邊際收益在 N20 之后陡降N 從 20 到 40 往往只多 1 到 2 個(gè)百分點(diǎn)成本卻翻倍。N10 是大多數(shù)場(chǎng)景的性價(jià)比拐點(diǎn)。真正值得投入的不是把 N 堆到 40而是把溫度調(diào)對(duì)、把提取做穩(wěn)、把自適應(yīng)停止和置信度分層用起來(lái)。這三件事做對(duì)了N10 的效果能接近盲目 N40成本只有四分之一。