試時(shí)計(jì)算：用并行采樣與驗(yàn)證器提升大模型推理能力)
之前在做 AI 智能體項(xiàng)目時(shí)我一直被一個(gè)問(wèn)題困擾模型一旦訓(xùn)練完成能力邊界似乎就固定了。遇到模型答不出來(lái)的題要不重新訓(xùn)練要不微調(diào)成本高周期長(zhǎng)。后來(lái)接觸到一個(gè)思路——不訓(xùn)練模型而是在推理階段投入更多計(jì)算讓模型自己“多想幾步”“多試幾次”效果竟然出奇地好。這個(gè)思路就是測(cè)試時(shí)計(jì)算Test-Time Compute也是斯坦福 CS329A《自我改進(jìn) AI 智能體》第二講的核心內(nèi)容。這篇文章就基于這門課第二講的知識(shí)脈絡(luò)結(jié)合并行采樣與驗(yàn)證機(jī)制完整梳理測(cè)試時(shí)計(jì)算的核心原理、實(shí)現(xiàn)方式和工程落地注意事項(xiàng)。無(wú)論你在做 AI 智能體開(kāi)發(fā)還是想提升大模型在推理任務(wù)上的表現(xiàn)這篇文章都值得收藏。1. 背景與核心概念1.1 為什么“不訓(xùn)練也能讓 AI 變強(qiáng)”我們先想一個(gè)場(chǎng)景。你用大模型解一道競(jìng)賽數(shù)學(xué)題模型直接給出一個(gè)答案。這個(gè)答案可能是對(duì)的也可能是錯(cuò)的但模型通常表現(xiàn)得非常自信。更麻煩的是你讓它重新算一遍它可能給出完全不同的答案而且依然自信。這說(shuō)明什么說(shuō)明單次推理只是一個(gè)“采樣”過(guò)程。大模型本質(zhì)上是根據(jù)輸入概率分布來(lái)生成文本的同樣的 prompt不同的隨機(jī)種子、不同的采樣參數(shù)得到的結(jié)果可能不一樣。既然單次采樣不靠譜我們能不能讓模型多采樣幾次然后從多個(gè)結(jié)果中選出最可靠的那個(gè)這正是測(cè)試時(shí)計(jì)算要做的事。它的核心思想是在模型推理階段通過(guò)增加計(jì)算量來(lái)提升輸出質(zhì)量而不是修改模型權(quán)重。換句話說(shuō)模型還是那個(gè)模型但我們?cè)谑褂梅绞缴献鑫恼?。在很多測(cè)試集上這種“推理時(shí)多想幾步”的方式往往能讓模型在數(shù)學(xué)推理、代碼生成、復(fù)雜規(guī)劃等任務(wù)上的表現(xiàn)明顯提升。相比訓(xùn)練一個(gè)新模型這種方式成本低、見(jiàn)效快且不需要額外準(zhǔn)備訓(xùn)練數(shù)據(jù)。1.2 測(cè)試時(shí)計(jì)算是什么定義與常見(jiàn)形式測(cè)試時(shí)計(jì)算Test-Time Compute通常指在模型推理inference階段投入額外的計(jì)算資源通過(guò)多次采樣、搜索、驗(yàn)證、反思、修正等策略獲得比單次推理更高質(zhì)量的輸出。它的常見(jiàn)形式包括并行采樣Parallel Sampling讓模型對(duì)同一個(gè)問(wèn)題生成多個(gè)候選答案。多數(shù)投票/自一致性Self-Consistency對(duì)多個(gè)答案進(jìn)行投票選出現(xiàn)次數(shù)最多的結(jié)果。驗(yàn)證器Verifier訓(xùn)練或利用一個(gè)評(píng)分模型對(duì)候選答案打分選出分?jǐn)?shù)最高的結(jié)果。思維搜索Search over Thoughts在思維鏈的每一步做多種可能性的搜索類似樹(shù)搜索。自我反思與修正Self-Refinement讓模型自己檢查錯(cuò)誤并根據(jù)反饋重新生成答案。這篇文章重點(diǎn)展開(kāi)并行采樣與驗(yàn)證這是最容易落地、也最容易被忽視的兩塊內(nèi)容。1.3 適用場(chǎng)景與局限測(cè)試時(shí)計(jì)算并非萬(wàn)能。它最適用的場(chǎng)景是那些存在“標(biāo)準(zhǔn)答案”或者“結(jié)果可驗(yàn)證”的任務(wù)比如數(shù)學(xué)題、邏輯推理、代碼單元測(cè)試、SQL 查詢等。這類任務(wù)的共同特點(diǎn)是候選答案很多但我們可以通過(guò)某種方式判斷哪個(gè)答案更好。相反如果任務(wù)本身是開(kāi)放式的比如“寫一首詩(shī)”“總結(jié)一下這篇文章的風(fēng)格”多個(gè)答案沒(méi)有絕對(duì)的對(duì)錯(cuò)測(cè)試時(shí)計(jì)算的價(jià)值就相對(duì)有限因?yàn)轵?yàn)證環(huán)節(jié)很難設(shè)計(jì)。另外還要注意測(cè)試時(shí)計(jì)算是以更多算力開(kāi)銷換質(zhì)量提升。在實(shí)際工程中需要評(píng)估延遲和成本是否能接受。2. 訓(xùn)練階段計(jì)算與測(cè)試時(shí)計(jì)算的對(duì)比2.1 訓(xùn)練階段計(jì)算離線、批量、權(quán)重更新先看傳統(tǒng)方式。訓(xùn)練階段計(jì)算發(fā)生在模型上線之前通過(guò)大量樣本計(jì)算梯度并更新模型權(quán)重。這個(gè)過(guò)程的特點(diǎn)是離線進(jìn)行時(shí)間跨度長(zhǎng)。一次性投入大量 GPU 算力。結(jié)果是一組固定的權(quán)重。模型能力在訓(xùn)練結(jié)束后基本定型。訓(xùn)練階段計(jì)算解決的是“模型學(xué)會(huì)多少知識(shí)”的問(wèn)題。模型不會(huì)做某類題通常是因?yàn)橛?xùn)練數(shù)據(jù)里沒(méi)見(jiàn)過(guò)或者模型容量不夠。這種情況下只能通過(guò)重新訓(xùn)練或微調(diào)來(lái)改變。2.2 測(cè)試時(shí)計(jì)算在線、采樣、選擇測(cè)試時(shí)計(jì)算則完全不同。模型權(quán)重保持不動(dòng)我們?cè)谕评黼A段做額外的計(jì)算讓模型生成多個(gè)候選結(jié)果。對(duì)候選結(jié)果進(jìn)行驗(yàn)證或篩選。選出一個(gè)最終答案或者綜合多個(gè)答案。這個(gè)過(guò)程是“在線”的每次請(qǐng)求都可能產(chǎn)生不同的計(jì)算路徑。它解決的是“模型其實(shí)會(huì)但單次沒(méi)發(fā)揮好”的問(wèn)題。這兩類計(jì)算方式并不互斥而是可以疊加。訓(xùn)練階段決定了模型能力的上限測(cè)試時(shí)計(jì)算則盡量逼近這個(gè)上限。2.3 兩者如何配合使用在實(shí)際項(xiàng)目中合理的做法是先用訓(xùn)練階段的計(jì)算把模型能力提到足夠高。對(duì)于仍然不穩(wěn)定的任務(wù)在推理階段引入測(cè)試時(shí)計(jì)算。當(dāng)一個(gè)任務(wù)經(jīng)過(guò)測(cè)試時(shí)計(jì)算仍然無(wú)法解決時(shí)才考慮重新訓(xùn)練或微調(diào)。這樣做的好處非常明顯訓(xùn)練一次模型成本很高而測(cè)試時(shí)計(jì)算按量付費(fèi)。對(duì)于低頻但高價(jià)值的任務(wù)測(cè)試時(shí)計(jì)算幾乎是性價(jià)比最高的優(yōu)化手段。3. 核心機(jī)制一并行采樣3.1 并行的含義多個(gè)獨(dú)立推理并行采樣的思路很直接同一個(gè) prompt同時(shí)讓模型生成 N 個(gè)答案而不是只生成一個(gè)。這里的“并行”既可以是真正的多路同時(shí)推理也可以是同一模型多次順序采樣只要每次采樣保持隨機(jī)性效果類似。打個(gè)比方你問(wèn)一個(gè)聰明但偶爾粗心的人一道題他答一次可能失誤你讓他答 10 次然后統(tǒng)計(jì)出現(xiàn)次數(shù)最多的答案正確率通常會(huì)高很多。在代碼實(shí)現(xiàn)上并行采樣通常有兩種方式顯式循環(huán)在代碼中調(diào)用 N 次模型接口。批量輸入構(gòu)造 N 條相同的 prompt 一起請(qǐng)求。3.2 溫度參數(shù)與多樣性并行采樣要發(fā)揮作用關(guān)鍵在于“樣本之間的多樣性”。如果采樣出來(lái)的 N 個(gè)答案一模一樣那投票和驗(yàn)證都沒(méi)有意義?？刂贫鄻有缘暮诵膮?shù)是溫度temperature。溫度越高模型生成時(shí)的隨機(jī)性越大候選答案越多樣但同時(shí)單條答案的質(zhì)量可能下降溫度越低輸出越確定但多樣性不足。實(shí)際使用中常見(jiàn)做法是把采樣溫度設(shè)置在 0.7 到 1.0 之間具體需要根據(jù)任務(wù)調(diào)節(jié)。數(shù)學(xué)推理類任務(wù)建議溫度略低比如 0.7 左右創(chuàng)意生成類任務(wù)可以高一點(diǎn)比如 0.9 以上。另一個(gè)注意點(diǎn)是 top-p核采樣它控制候選 token 的累積概率。一般情況下并行采樣時(shí)適當(dāng)調(diào)低 top-p 可以減少低質(zhì)量候選但不要在并行采樣場(chǎng)景把 top-p 設(shè)得過(guò)低否則多樣性會(huì)受影響。3.3 并行采樣的參數(shù)組合一個(gè)典型的并行采樣配置看起來(lái)像這樣參數(shù)說(shuō)明建議值n采樣次數(shù)4 到 16temperature隨機(jī)性0.7 到 1.0top_p核采樣概率0.9 到 1.0max_tokens最大生成長(zhǎng)度根據(jù)任務(wù)調(diào)整stop停止符按需配置下面是一個(gè)調(diào)用 OpenAI 兼容接口進(jìn)行并行采樣的 Python 示例。示例思路可用于任意兼容接口實(shí)際運(yùn)行需要你配置自己的 API Key 和服務(wù)地址。# 文件路徑parallel_sample.py import openai client openai.OpenAI( api_keyyour-api-key, base_urlyour-base-url ) prompt 一個(gè)三角形的三個(gè)內(nèi)角分別是 2x、3x 和 4x求 x 的值。 def parallel_sample(prompt: str, n: int 5) - list[str]: responses [] for i in range(n): try: resp client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: 你是一個(gè)嚴(yán)謹(jǐn)?shù)臄?shù)學(xué)解題助手。}, {role: user, content: prompt} ], temperature0.7, top_p0.9, max_tokens500 ) responses.append(resp.choices[0].message.content) except Exception as e: print(f第 {i1} 次采樣失敗: {e}) return responses if __name__ __main__: answers parallel_sample(prompt, n5) for idx, ans in enumerate(answers, 1): print(f候選 {idx}:\n{ans}\n)這里有幾個(gè)值得注意的地方每次采樣都是獨(dú)立請(qǐng)求互不影響。采樣過(guò)程中的異常需要單獨(dú)捕獲避免單次失敗導(dǎo)致整個(gè)流程中斷。在實(shí)際工程中可以把循環(huán)改成線程池或異步任務(wù)提高吞吐。4. 核心機(jī)制二驗(yàn)證器與選擇策略并行采樣生成了很多候選答案但哪個(gè)更好這時(shí)候就需要驗(yàn)證器。4.1 為什么要驗(yàn)證采樣只是產(chǎn)生候選采樣只解決“有沒(méi)有更多備選”的問(wèn)題并沒(méi)有解決“哪個(gè)備選更好”的問(wèn)題。直接隨機(jī)選一個(gè)候選正確率并不會(huì)提升多少。所以必須有一個(gè)選擇策略。選擇策略大致分兩類無(wú)需額外訓(xùn)練的比如多數(shù)投票、啟發(fā)式規(guī)則。需要訓(xùn)練的比如訓(xùn)練一個(gè)驗(yàn)證器模型對(duì)候選結(jié)果進(jìn)行打分。兩者各有優(yōu)劣。無(wú)需訓(xùn)練的方案上手快適用面廣訓(xùn)練驗(yàn)證器則需要額外數(shù)據(jù)標(biāo)注和訓(xùn)練成本但通常效果更好。4.2 不需要訓(xùn)練的驗(yàn)證方案多數(shù)投票與自一致性先看多數(shù)投票Majority Voting也叫自一致性Self-Consistency。核心邏輯是如果多個(gè)獨(dú)立采樣得到同一個(gè)答案那么這個(gè)答案正確的概率更大。舉個(gè)例子。5 次采樣結(jié)果中有 3 次答案是 20 度1 次是 25 度1 次是 30 度。按照多數(shù)投票規(guī)則最終答案是 20 度。但這里有一個(gè)關(guān)鍵細(xì)節(jié)不能對(duì)完整文本做簡(jiǎn)單去重因?yàn)槟Ｐ偷拇朕o可能不同。更合理的做法是提取“最終答案”部分參與投票。下面是一個(gè)簡(jiǎn)單的多數(shù)投票實(shí)現(xiàn)# 文件路徑majority_vote.py import re from collections import Counter def extract_answer(text: str) - str: # 簡(jiǎn)化版抽取規(guī)則實(shí)際項(xiàng)目需要根據(jù)任務(wù)定制 patterns [ r答案是[:]\s*([^\n。]), r最終答案[:]\s*([^\n。]), r\bx\s*\s*([^\n。]) ] for pattern in patterns: match re.search(pattern, text) if match: return match.group(1).strip() return text.strip() def majority_vote(answers: list[str]) - tuple[str, int]: extracted [extract_answer(ans) for ans in answers] counter Counter(extracted) best_answer, count counter.most_common(1)[0] return best_answer, count if __name__ __main__: sample_answers [ 設(shè)三個(gè)角分別為 2x、3x、4x三角形內(nèi)角和為 180 度。9x 180所以 x 20。答案是 20。, 2x 3x 4x 1809x 180x 20。最終答案20。, x 25。, 內(nèi)角和為 180 度。2x3x4x9x180最終 x 20。, 這道題中 x 20 度。 ] result, cnt majority_vote(sample_answers) print(f多數(shù)投票結(jié)果: {result}出現(xiàn)次數(shù): {cnt})多數(shù)投票的適用前提是任務(wù)有明確的答案形式且模型大部分情況下能給出正確答案。如果模型本身能力較弱正確率低于隨機(jī)水平投票也救不回來(lái)。4.3 需要訓(xùn)練的驗(yàn)證器結(jié)果驗(yàn)證器與過(guò)程驗(yàn)證器當(dāng)任務(wù)答案形式復(fù)雜或者候選答案難以自動(dòng)抽取時(shí)可以考慮訓(xùn)練一個(gè)驗(yàn)證器。驗(yàn)證器本質(zhì)上是一個(gè)二分類模型或打分模型輸入是“問(wèn)題 候選答案”輸出是一個(gè)分?jǐn)?shù)表示這個(gè)答案的可信度。常見(jiàn)做法有兩種結(jié)果驗(yàn)證器Outcome Reward Model, ORM只看最終答案是否正確給最終結(jié)果打分。過(guò)程驗(yàn)證器Process Reward Model, PRM在一步步推理中逐步打分能定位到錯(cuò)誤步驟但訓(xùn)練成本更高。結(jié)果驗(yàn)證器適合大多數(shù)工程場(chǎng)景過(guò)程驗(yàn)證器更適合推理鏈路長(zhǎng)、需要定位錯(cuò)誤位置的任務(wù)。驗(yàn)證器的訓(xùn)練數(shù)據(jù)怎么來(lái)常見(jiàn)思路是用大模型為同一個(gè)問(wèn)題生成多個(gè)候選答案然后通過(guò)人工標(biāo)注或者用權(quán)威答案自動(dòng)比對(duì)給每個(gè)候選打上正確/錯(cuò)誤標(biāo)簽再用排序損失訓(xùn)練一個(gè)打分模型。4.4 用大模型自身做驗(yàn)證如果不方便訓(xùn)練驗(yàn)證器還有一種折中方案讓大模型充當(dāng)驗(yàn)證器。做法是把問(wèn)題、候選答案一起給模型要求它判斷這個(gè)答案是否正確或者對(duì)多個(gè)答案進(jìn)行排序。這種方式無(wú)需訓(xùn)練效果取決于大模型自身的判斷能力。示例 prompt請(qǐng)判斷以下解題過(guò)程是否正確。如果正確請(qǐng)回答“正確”如果不正確請(qǐng)指出錯(cuò)誤原因。 題目一個(gè)三角形的三個(gè)內(nèi)角分別是 2x、3x 和 4x求 x 的值。 候選解答 2x 3x 4x 180 9x 180 x 20 請(qǐng)給出你的判斷。這種方式的好處是靈活缺點(diǎn)是會(huì)額外消耗 token而且大模型可能“看不出”錯(cuò)誤。在工程中可以先做字符串規(guī)則抽答案再用 LLM 驗(yàn)證沒(méi)有抽到答案的候選這樣成本更可控。5. 完整實(shí)戰(zhàn)案例為數(shù)學(xué)推理任務(wù)加入采樣與驗(yàn)證流程現(xiàn)在把前面講的內(nèi)容串起來(lái)實(shí)現(xiàn)一個(gè)“采樣 → 投票/驗(yàn)證 → 最終輸出”的完整流程。示例任務(wù)仍然是數(shù)學(xué)題但這套流程可以擴(kuò)展到代碼生成、SQL 生成、日志分析等任務(wù)。5.1 流程設(shè)計(jì)整體流程分四步接收用戶問(wèn)題。并行采樣生成 N 個(gè)候選答案。對(duì)候選答案做歸一化和抽取。用多數(shù)投票篩選最終答案若投票無(wú)法收斂則用 LLM 驗(yàn)證。5.2 完整代碼# 文件路徑test_time_pipeline.py import re from collections import Counter import openai client openai.OpenAI( api_keyyour-api-key, base_urlyour-base-url ) SYSTEM_PROMPT 你是一個(gè)嚴(yán)謹(jǐn)?shù)臄?shù)學(xué)解題助手。請(qǐng)分步推理并在最后單獨(dú)一行輸出最終答案。 def generate_answer(question: str, temperature: float 0.7) - str: resp client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: question} ], temperaturetemperature, max_tokens500 ) return resp.choices[0].message.content def extract_answer(text: str) - str: # 優(yōu)先抽取“最終答案”后面的內(nèi)容 patterns [ r最終答案[:]\s*([^\n。]), r答案是[:]\s*([^\n。]), rx\s*\s*([^\n。]), r([-]?\d(?:\.\d)?) ] for pattern in patterns: match re.search(pattern, text) if match: return match.group(1).strip() return text.strip() def majority_vote(answers: list[str]) - tuple[str | None, int]: extracted [extract_answer(ans) for ans in answers] counter Counter(extracted) answer, count counter.most_common(1)[0] if count 1: return None, count return answer, count def llm_verify(question: str, answer: str) - bool: verify_prompt f 請(qǐng)判斷下面的最終答案是否正確。如果正確請(qǐng)回答“正確”否則回答“不正確”。 題目{question} 最終答案{answer} 你的判斷 resp client.chat.completions.create( modelyour-model-name, messages[ {role: user, content: verify_prompt} ], temperature0, max_tokens100 ) content resp.choices[0].message.content return 正確 in content def solve_with_test_time_compute(question: str, n: int 5) - str: # Step 1: 并行采樣 candidates [generate_answer(question) for _ in range(n)] # Step 2: 多數(shù)投票 best_answer, count majority_vote(candidates) if best_answer is not None: return f多數(shù)投票結(jié)果: {best_answer}獲得 {count}/{n} 票 # Step 3: 投票不收斂時(shí)用 LLM 驗(yàn)證 for idx, cand in enumerate(candidates): extracted extract_answer(cand) if extracted and llm_verify(question, extracted): return fLLM 驗(yàn)證通過(guò): {extracted}來(lái)自第 {idx1} 個(gè)候選 # Step 4: 兜底返回第一個(gè)候選 return f驗(yàn)證未通過(guò)返回第一個(gè)候選: {extract_answer(candidates[0])} if __name__ __main__: q 一個(gè)三角形的三個(gè)內(nèi)角分別是 2x、3x 和 4x求 x 的值。 result solve_with_test_time_compute(q, n5) print(result)5.3 運(yùn)行結(jié)果說(shuō)明假設(shè)模型本身具備基礎(chǔ)數(shù)學(xué)能力那么 5 次采樣中通常會(huì)出現(xiàn) 3 到 4 次答案一致的情況程序會(huì)直接走“多數(shù)投票”分支并輸出結(jié)果。如果模型能力偏弱5 次采樣各自給出不同答案程序會(huì)進(jìn)入 LLM 驗(yàn)證分支逐一驗(yàn)證候選答案直到找到模型自身認(rèn)可的答案。如果所有候選都無(wú)法通過(guò)驗(yàn)證程序返回第一個(gè)候選作為兜底避免接口無(wú)輸出。這種設(shè)計(jì)保證了整個(gè)流程在工程上是健壯的不會(huì)因?yàn)槟骋淮尾蓸赢惓；蝌?yàn)證異常導(dǎo)致整體失敗。5.4 工程改造建議上面的代碼是一個(gè)串行演示版本。在實(shí)際服務(wù)中建議做以下改造用 asyncio 或線程池并發(fā)發(fā)起采樣請(qǐng)求把 5 次采樣時(shí)間從“5 倍單次延遲”壓縮到“接近 1 倍單次延遲”。對(duì)候選答案做緩存相同 prompt 在短時(shí)間內(nèi)的采樣結(jié)果可以復(fù)用。把投票和驗(yàn)證邏輯封裝成獨(dú)立服務(wù)方便不同模塊復(fù)用。增加超時(shí)和重試機(jī)制防止某個(gè)采樣請(qǐng)求一直阻塞。6. 常見(jiàn)問(wèn)題與排查思路測(cè)試時(shí)計(jì)算在實(shí)踐中會(huì)遇到不少問(wèn)題下面整理幾個(gè)高頻場(chǎng)景。問(wèn)題現(xiàn)象常見(jiàn)原因解決思路采樣結(jié)果千篇一律投票沒(méi)有意義溫度參數(shù)過(guò)低模型輸出趨于確定調(diào)高 temperature適當(dāng)降低 top_p多數(shù)投票選出的答案是錯(cuò)的模型本身能力不足大多數(shù)采樣都錯(cuò)考慮換更強(qiáng)的模型或訓(xùn)練任務(wù)專用驗(yàn)證器答案抽取不準(zhǔn)確投票失效正則規(guī)則沒(méi)覆蓋到模型的表述習(xí)慣先觀察 20 條真實(shí)輸出再完善抽取規(guī)則并行采樣導(dǎo)致接口延遲過(guò)高所有請(qǐng)求串行執(zhí)行用異步或線程池并發(fā)調(diào)用驗(yàn)證結(jié)果不穩(wěn)定同樣的輸入有時(shí)通過(guò)有時(shí)不通過(guò)LLM 驗(yàn)證時(shí)溫度過(guò)高隨機(jī)性大驗(yàn)證請(qǐng)求設(shè)置 temperature0多次驗(yàn)證取多數(shù)算力成本暴增采樣數(shù)量 N 設(shè)置過(guò)大先測(cè) N4 的效果再逐步增加到 8 或 16采樣結(jié)果長(zhǎng)度過(guò)長(zhǎng)token 消耗大沒(méi)有限制 max_tokens模型輸出冗長(zhǎng)設(shè)置合理的 max_tokens并要求“只輸出最終答案”這里重點(diǎn)說(shuō)一下答案抽取。很多人做多數(shù)投票時(shí)直接對(duì)完整文本去重結(jié)果發(fā)現(xiàn)同樣的答案因?yàn)楸磉_(dá)方式不同被當(dāng)成不同結(jié)果。比較好的辦法是先讓模型在 prompt 中按固定格式輸出比如“最終答案xxx”。代碼里先按固定標(biāo)記抽取。抽不到再走正則兜底。最后才考慮用 LLM 抽取。這樣做的核心原則是能用規(guī)則解決的事情不要用模型能一次抽準(zhǔn)的事情不要二次加戲。7. 最佳實(shí)踐與工程建議7.1 采樣數(shù)量 N 不是越大越好N 越大效果通常會(huì)更好但收益遞減非常明顯。從實(shí)際項(xiàng)目經(jīng)驗(yàn)看N4 到 N8 時(shí)性價(jià)比最高N 超過(guò) 16 后正確率提升趨于平緩成本和延遲卻線性增長(zhǎng)。建議上線前先做小規(guī)模實(shí)驗(yàn)畫出“N 值-正確率”曲線再?zèng)Q定線上參數(shù)。7.2 溫度參數(shù)要與任務(wù)匹配數(shù)學(xué)推理、代碼生成建議 temperature0.7top_p0.9。開(kāi)放對(duì)話、創(chuàng)意寫作建議 temperature0.9 以上。驗(yàn)證環(huán)節(jié)建議 temperature0。同一套并行采樣邏輯用在不同任務(wù)上需要單獨(dú)調(diào)參不要追一個(gè)參數(shù)走天下。7.3 驗(yàn)證器要關(guān)注“錯(cuò)誤接受率”用 LLM 做驗(yàn)證時(shí)最容易出問(wèn)題的不是把好答案拒掉而是把錯(cuò)誤答案放進(jìn)來(lái)。比如模型對(duì)錯(cuò)誤答案也說(shuō)“正確”這時(shí)候驗(yàn)證就失去了意義。在工程上可以引入“多次驗(yàn)證取多數(shù)”或者“驗(yàn)證規(guī)則雙重校驗(yàn)”來(lái)降低錯(cuò)誤接受率。在安全敏感的領(lǐng)域比如代碼生成、數(shù)據(jù)庫(kù) SQL 生成建議加上沙箱測(cè)試而不是只靠 LLM 判斷。7.4 并行采樣的資源控制并行采樣會(huì)放大對(duì)底層模型的調(diào)用壓力。建議在代碼中加入并發(fā)數(shù)限制例如用信號(hào)量控制最大并發(fā)請(qǐng)求數(shù)避免短時(shí)間大量請(qǐng)求打爆服務(wù)。下面是一個(gè)簡(jiǎn)單的并發(fā)控制示例# 文件路徑concurrency_control.py import asyncio import openai client openai.OpenAI( api_keyyour-api-key, base_urlyour-base-url ) semaphore asyncio.Semaphore(3) async def guarded_generate(prompt: str) - str: async with semaphore: loop asyncio.get_event_loop() def sync_call(): resp client.chat.completions.create( modelyour-model-name, messages[{role: user, content: prompt}], temperature0.7, max_tokens300 ) return resp.choices[0].message.content return await loop.run_in_executor(None, sync_call) async def parallel_generate(prompt: str, n: int 5) - list[str]: tasks [guarded_generate(prompt) for _ in range(n)] return await asyncio.gather(*tasks, return_exceptionsTrue) if __name__ __main__: results asyncio.run(parallel_generate(解釋一下什么是測(cè)試時(shí)計(jì)算。, n5)) for idx, res in enumerate(results, 1): if isinstance(res, Exception): print(f候選 {idx} 異常: {res}) else: print(f候選 {idx}: {res})7.5 日志與可復(fù)現(xiàn)性測(cè)試時(shí)計(jì)算引入了隨機(jī)性會(huì)導(dǎo)致同一個(gè)請(qǐng)求在不同時(shí)間得到不同的結(jié)果。這在調(diào)試時(shí)非常痛苦。建議在日志中記錄每個(gè)請(qǐng)求的prompt 版本溫度和 top_p 參數(shù)采樣次數(shù)每個(gè)候選答案及其抽取結(jié)果最終采用的候選編號(hào)同時(shí)在采樣時(shí)為每次請(qǐng)求生成一個(gè)隨機(jī)種子方便復(fù)現(xiàn)問(wèn)題。7.6 安全與權(quán)限邊界在真實(shí)項(xiàng)目中如果測(cè)試時(shí)計(jì)算用于生產(chǎn)環(huán)境涉及 SQL 生成、命令執(zhí)行、代碼生成等場(chǎng)景必須嚴(yán)格限制最終結(jié)果的執(zhí)行權(quán)限。建議所有生成結(jié)果默認(rèn)不自動(dòng)執(zhí)行先經(jīng)過(guò)人工確認(rèn)。代碼生成結(jié)果必須在沙箱環(huán)境中進(jìn)行測(cè)試。數(shù)據(jù)庫(kù) SQL 生成結(jié)果必須經(jīng)過(guò)只讀賬號(hào)驗(yàn)證并在測(cè)試庫(kù)執(zhí)行。在安全敏感操作中加入審批流程。測(cè)試時(shí)計(jì)算只是提升模型輸出質(zhì)量的手段不應(yīng)該繞過(guò)任何已有的安全邊界。7.7 評(píng)估線上效果時(shí)要注意評(píng)估測(cè)試時(shí)計(jì)算的效果不能只看正確率。需要同時(shí)觀察延遲P95 延遲是否可接受。成本單次請(qǐng)求的 token 消耗和 API 費(fèi)用。錯(cuò)誤模式是多數(shù)投票能解決還是必須上驗(yàn)證器?；赝藱C(jī)制驗(yàn)證不通過(guò)時(shí)是否有兜底策略。建議先在離線數(shù)據(jù)集上跑通全流程再小流量上線對(duì)比。8. 總結(jié)與后續(xù)學(xué)習(xí)方向測(cè)試時(shí)計(jì)算的核心邏輯并不復(fù)雜既然單次采樣不可靠那就多做幾次再引入驗(yàn)證機(jī)制來(lái)篩選。它把“訓(xùn)練時(shí)多花算力”變成了“推理時(shí)多花算力”在沒(méi)有改變模型權(quán)重的前提下提升了模型在推理任務(wù)上的可靠性。本文講清楚了幾件事什么是測(cè)試時(shí)計(jì)算以及它與訓(xùn)練階段計(jì)算的本質(zhì)區(qū)別。并行采樣如何通過(guò)溫度等參數(shù)控制多樣性。驗(yàn)證器的兩種路線無(wú)需訓(xùn)練的多數(shù)投票以及需要訓(xùn)練的驗(yàn)證器模型。一個(gè)完整的采樣投票LLM 驗(yàn)證流程及其代碼實(shí)現(xiàn)。工程落地時(shí)關(guān)于延遲、成本、護(hù)欄和評(píng)估的注意事項(xiàng)。下一步建議你在自己的任務(wù)上先跑一遍并行采樣基線記錄 N1、N4、N8 時(shí)的正確率和成本曲線。確認(rèn)收益后再考慮是否引入訓(xùn)練驗(yàn)證器。如果對(duì)思維搜索和過(guò)程驗(yàn)證器感興趣還可以進(jìn)一步看樹(shù)搜索在推理任務(wù)中的應(yīng)用。如果你在做 AI 智能體開(kāi)發(fā)或者正在搭建模型評(píng)估流程建議把文中的 pipeline 代碼改成你自己的任務(wù)格式跑一遍。測(cè)試時(shí)計(jì)算是一個(gè)“投入小、見(jiàn)效快”的優(yōu)化方向值得花一個(gè)下午做實(shí)驗(yàn)看看在你的任務(wù)上能提升多少。 測(cè)試時(shí)計(jì)算：用并行采樣與驗(yàn)證器提升大模型推理能力
之前在做 AI 智能體項(xiàng)目時(shí)我一直被一個(gè)問(wèn)題困擾模型一旦訓(xùn)練完成能力邊界似乎就固定了。遇到模型答不出來(lái)的題要不重新訓(xùn)練要不微調(diào)成本高周期長(zhǎng)。后來(lái)接觸到一個(gè)思路——不訓(xùn)練模型而是在推理階段投入更多計(jì)算讓模型自己“多想幾步”“多試幾次”效果竟然出奇地好。這個(gè)思路就是測(cè)試時(shí)計(jì)算Test-Time Compute也是斯坦福 CS329A《自我改進(jìn) AI 智能體》第二講的核心內(nèi)容。這篇文章就基于這門課第二講的知識(shí)脈絡(luò)結(jié)合并行采樣與驗(yàn)證機(jī)制完整梳理測(cè)試時(shí)計(jì)算的核心原理、實(shí)現(xiàn)方式和工程落地注意事項(xiàng)。無(wú)論你在做 AI 智能體開(kāi)發(fā)還是想提升大模型在推理任務(wù)上的表現(xiàn)這篇文章都值得收藏。1. 背景與核心概念1.1 為什么“不訓(xùn)練也能讓 AI 變強(qiáng)”我們先想一個(gè)場(chǎng)景。你用大模型解一道競(jìng)賽數(shù)學(xué)題模型直接給出一個(gè)答案。這個(gè)答案可能是對(duì)的也可能是錯(cuò)的但模型通常表現(xiàn)得非常自信。更麻煩的是你讓它重新算一遍它可能給出完全不同的答案而且依然自信。這說(shuō)明什么說(shuō)明單次推理只是一個(gè)“采樣”過(guò)程。大模型本質(zhì)上是根據(jù)輸入概率分布來(lái)生成文本的同樣的 prompt不同的隨機(jī)種子、不同的采樣參數(shù)得到的結(jié)果可能不一樣。既然單次采樣不靠譜我們能不能讓模型多采樣幾次然后從多個(gè)結(jié)果中選出最可靠的那個(gè)這正是測(cè)試時(shí)計(jì)算要做的事。它的核心思想是在模型推理階段通過(guò)增加計(jì)算量來(lái)提升輸出質(zhì)量而不是修改模型權(quán)重。換句話說(shuō)模型還是那個(gè)模型但我們?cè)谑褂梅绞缴献鑫恼?。在很多測(cè)試集上這種“推理時(shí)多想幾步”的方式往往能讓模型在數(shù)學(xué)推理、代碼生成、復(fù)雜規(guī)劃等任務(wù)上的表現(xiàn)明顯提升。相比訓(xùn)練一個(gè)新模型這種方式成本低、見(jiàn)效快且不需要額外準(zhǔn)備訓(xùn)練數(shù)據(jù)。1.2 測(cè)試時(shí)計(jì)算是什么定義與常見(jiàn)形式測(cè)試時(shí)計(jì)算Test-Time Compute通常指在模型推理inference階段投入額外的計(jì)算資源通過(guò)多次采樣、搜索、驗(yàn)證、反思、修正等策略獲得比單次推理更高質(zhì)量的輸出。它的常見(jiàn)形式包括并行采樣Parallel Sampling讓模型對(duì)同一個(gè)問(wèn)題生成多個(gè)候選答案。多數(shù)投票/自一致性Self-Consistency對(duì)多個(gè)答案進(jìn)行投票選出現(xiàn)次數(shù)最多的結(jié)果。驗(yàn)證器Verifier訓(xùn)練或利用一個(gè)評(píng)分模型對(duì)候選答案打分選出分?jǐn)?shù)最高的結(jié)果。思維搜索Search over Thoughts在思維鏈的每一步做多種可能性的搜索類似樹(shù)搜索。自我反思與修正Self-Refinement讓模型自己檢查錯(cuò)誤并根據(jù)反饋重新生成答案。這篇文章重點(diǎn)展開(kāi)并行采樣與驗(yàn)證這是最容易落地、也最容易被忽視的兩塊內(nèi)容。1.3 適用場(chǎng)景與局限測(cè)試時(shí)計(jì)算并非萬(wàn)能。它最適用的場(chǎng)景是那些存在“標(biāo)準(zhǔn)答案”或者“結(jié)果可驗(yàn)證”的任務(wù)比如數(shù)學(xué)題、邏輯推理、代碼單元測(cè)試、SQL 查詢等。這類任務(wù)的共同特點(diǎn)是候選答案很多但我們可以通過(guò)某種方式判斷哪個(gè)答案更好。相反如果任務(wù)本身是開(kāi)放式的比如“寫一首詩(shī)”“總結(jié)一下這篇文章的風(fēng)格”多個(gè)答案沒(méi)有絕對(duì)的對(duì)錯(cuò)測(cè)試時(shí)計(jì)算的價(jià)值就相對(duì)有限因?yàn)轵?yàn)證環(huán)節(jié)很難設(shè)計(jì)。另外還要注意測(cè)試時(shí)計(jì)算是以更多算力開(kāi)銷換質(zhì)量提升。在實(shí)際工程中需要評(píng)估延遲和成本是否能接受。2. 訓(xùn)練階段計(jì)算與測(cè)試時(shí)計(jì)算的對(duì)比2.1 訓(xùn)練階段計(jì)算離線、批量、權(quán)重更新先看傳統(tǒng)方式。訓(xùn)練階段計(jì)算發(fā)生在模型上線之前通過(guò)大量樣本計(jì)算梯度并更新模型權(quán)重。這個(gè)過(guò)程的特點(diǎn)是離線進(jìn)行時(shí)間跨度長(zhǎng)。一次性投入大量 GPU 算力。結(jié)果是一組固定的權(quán)重。模型能力在訓(xùn)練結(jié)束后基本定型。訓(xùn)練階段計(jì)算解決的是“模型學(xué)會(huì)多少知識(shí)”的問(wèn)題。模型不會(huì)做某類題通常是因?yàn)橛?xùn)練數(shù)據(jù)里沒(méi)見(jiàn)過(guò)或者模型容量不夠。這種情況下只能通過(guò)重新訓(xùn)練或微調(diào)來(lái)改變。2.2 測(cè)試時(shí)計(jì)算在線、采樣、選擇測(cè)試時(shí)計(jì)算則完全不同。模型權(quán)重保持不動(dòng)我們?cè)谕评黼A段做額外的計(jì)算讓模型生成多個(gè)候選結(jié)果。對(duì)候選結(jié)果進(jìn)行驗(yàn)證或篩選。選出一個(gè)最終答案或者綜合多個(gè)答案。這個(gè)過(guò)程是“在線”的每次請(qǐng)求都可能產(chǎn)生不同的計(jì)算路徑。它解決的是“模型其實(shí)會(huì)但單次沒(méi)發(fā)揮好”的問(wèn)題。這兩類計(jì)算方式并不互斥而是可以疊加。訓(xùn)練階段決定了模型能力的上限測(cè)試時(shí)計(jì)算則盡量逼近這個(gè)上限。2.3 兩者如何配合使用在實(shí)際項(xiàng)目中合理的做法是先用訓(xùn)練階段的計(jì)算把模型能力提到足夠高。對(duì)于仍然不穩(wěn)定的任務(wù)在推理階段引入測(cè)試時(shí)計(jì)算。當(dāng)一個(gè)任務(wù)經(jīng)過(guò)測(cè)試時(shí)計(jì)算仍然無(wú)法解決時(shí)才考慮重新訓(xùn)練或微調(diào)。這樣做的好處非常明顯訓(xùn)練一次模型成本很高而測(cè)試時(shí)計(jì)算按量付費(fèi)。對(duì)于低頻但高價(jià)值的任務(wù)測(cè)試時(shí)計(jì)算幾乎是性價(jià)比最高的優(yōu)化手段。3. 核心機(jī)制一并行采樣3.1 并行的含義多個(gè)獨(dú)立推理并行采樣的思路很直接同一個(gè) prompt同時(shí)讓模型生成 N 個(gè)答案而不是只生成一個(gè)。這里的“并行”既可以是真正的多路同時(shí)推理也可以是同一模型多次順序采樣只要每次采樣保持隨機(jī)性效果類似。打個(gè)比方你問(wèn)一個(gè)聰明但偶爾粗心的人一道題他答一次可能失誤你讓他答 10 次然后統(tǒng)計(jì)出現(xiàn)次數(shù)最多的答案正確率通常會(huì)高很多。在代碼實(shí)現(xiàn)上并行采樣通常有兩種方式顯式循環(huán)在代碼中調(diào)用 N 次模型接口。批量輸入構(gòu)造 N 條相同的 prompt 一起請(qǐng)求。3.2 溫度參數(shù)與多樣性并行采樣要發(fā)揮作用關(guān)鍵在于“樣本之間的多樣性”。如果采樣出來(lái)的 N 個(gè)答案一模一樣那投票和驗(yàn)證都沒(méi)有意義?？刂贫鄻有缘暮诵膮?shù)是溫度temperature。溫度越高模型生成時(shí)的隨機(jī)性越大候選答案越多樣但同時(shí)單條答案的質(zhì)量可能下降溫度越低輸出越確定但多樣性不足。實(shí)際使用中常見(jiàn)做法是把采樣溫度設(shè)置在 0.7 到 1.0 之間具體需要根據(jù)任務(wù)調(diào)節(jié)。數(shù)學(xué)推理類任務(wù)建議溫度略低比如 0.7 左右創(chuàng)意生成類任務(wù)可以高一點(diǎn)比如 0.9 以上。另一個(gè)注意點(diǎn)是 top-p核采樣它控制候選 token 的累積概率。一般情況下并行采樣時(shí)適當(dāng)調(diào)低 top-p 可以減少低質(zhì)量候選但不要在并行采樣場(chǎng)景把 top-p 設(shè)得過(guò)低否則多樣性會(huì)受影響。3.3 并行采樣的參數(shù)組合一個(gè)典型的并行采樣配置看起來(lái)像這樣參數(shù)說(shuō)明建議值n采樣次數(shù)4 到 16temperature隨機(jī)性0.7 到 1.0top_p核采樣概率0.9 到 1.0max_tokens最大生成長(zhǎng)度根據(jù)任務(wù)調(diào)整stop停止符按需配置下面是一個(gè)調(diào)用 OpenAI 兼容接口進(jìn)行并行采樣的 Python 示例。示例思路可用于任意兼容接口實(shí)際運(yùn)行需要你配置自己的 API Key 和服務(wù)地址。# 文件路徑parallel_sample.py import openai client openai.OpenAI( api_keyyour-api-key, base_urlyour-base-url ) prompt 一個(gè)三角形的三個(gè)內(nèi)角分別是 2x、3x 和 4x求 x 的值。 def parallel_sample(prompt: str, n: int 5) - list[str]: responses [] for i in range(n): try: resp client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: 你是一個(gè)嚴(yán)謹(jǐn)?shù)臄?shù)學(xué)解題助手。}, {role: user, content: prompt} ], temperature0.7, top_p0.9, max_tokens500 ) responses.append(resp.choices[0].message.content) except Exception as e: print(f第 {i1} 次采樣失敗: {e}) return responses if __name__ __main__: answers parallel_sample(prompt, n5) for idx, ans in enumerate(answers, 1): print(f候選 {idx}:\n{ans}\n)這里有幾個(gè)值得注意的地方每次采樣都是獨(dú)立請(qǐng)求互不影響。采樣過(guò)程中的異常需要單獨(dú)捕獲避免單次失敗導(dǎo)致整個(gè)流程中斷。在實(shí)際工程中可以把循環(huán)改成線程池或異步任務(wù)提高吞吐。4. 核心機(jī)制二驗(yàn)證器與選擇策略并行采樣生成了很多候選答案但哪個(gè)更好這時(shí)候就需要驗(yàn)證器。4.1 為什么要驗(yàn)證采樣只是產(chǎn)生候選采樣只解決“有沒(méi)有更多備選”的問(wèn)題并沒(méi)有解決“哪個(gè)備選更好”的問(wèn)題。直接隨機(jī)選一個(gè)候選正確率并不會(huì)提升多少。所以必須有一個(gè)選擇策略。選擇策略大致分兩類無(wú)需額外訓(xùn)練的比如多數(shù)投票、啟發(fā)式規(guī)則。需要訓(xùn)練的比如訓(xùn)練一個(gè)驗(yàn)證器模型對(duì)候選結(jié)果進(jìn)行打分。兩者各有優(yōu)劣。無(wú)需訓(xùn)練的方案上手快適用面廣訓(xùn)練驗(yàn)證器則需要額外數(shù)據(jù)標(biāo)注和訓(xùn)練成本但通常效果更好。4.2 不需要訓(xùn)練的驗(yàn)證方案多數(shù)投票與自一致性先看多數(shù)投票Majority Voting也叫自一致性Self-Consistency。核心邏輯是如果多個(gè)獨(dú)立采樣得到同一個(gè)答案那么這個(gè)答案正確的概率更大。舉個(gè)例子。5 次采樣結(jié)果中有 3 次答案是 20 度1 次是 25 度1 次是 30 度。按照多數(shù)投票規(guī)則最終答案是 20 度。但這里有一個(gè)關(guān)鍵細(xì)節(jié)不能對(duì)完整文本做簡(jiǎn)單去重因?yàn)槟Ｐ偷拇朕o可能不同。更合理的做法是提取“最終答案”部分參與投票。下面是一個(gè)簡(jiǎn)單的多數(shù)投票實(shí)現(xiàn)# 文件路徑majority_vote.py import re from collections import Counter def extract_answer(text: str) - str: # 簡(jiǎn)化版抽取規(guī)則實(shí)際項(xiàng)目需要根據(jù)任務(wù)定制 patterns [ r答案是[:]\s*([^\n。]), r最終答案[:]\s*([^\n。]), r\bx\s*\s*([^\n。]) ] for pattern in patterns: match re.search(pattern, text) if match: return match.group(1).strip() return text.strip() def majority_vote(answers: list[str]) - tuple[str, int]: extracted [extract_answer(ans) for ans in answers] counter Counter(extracted) best_answer, count counter.most_common(1)[0] return best_answer, count if __name__ __main__: sample_answers [ 設(shè)三個(gè)角分別為 2x、3x、4x三角形內(nèi)角和為 180 度。9x 180所以 x 20。答案是 20。, 2x 3x 4x 1809x 180x 20。最終答案20。, x 25。, 內(nèi)角和為 180 度。2x3x4x9x180最終 x 20。, 這道題中 x 20 度。 ] result, cnt majority_vote(sample_answers) print(f多數(shù)投票結(jié)果: {result}出現(xiàn)次數(shù): {cnt})多數(shù)投票的適用前提是任務(wù)有明確的答案形式且模型大部分情況下能給出正確答案。如果模型本身能力較弱正確率低于隨機(jī)水平投票也救不回來(lái)。4.3 需要訓(xùn)練的驗(yàn)證器結(jié)果驗(yàn)證器與過(guò)程驗(yàn)證器當(dāng)任務(wù)答案形式復(fù)雜或者候選答案難以自動(dòng)抽取時(shí)可以考慮訓(xùn)練一個(gè)驗(yàn)證器。驗(yàn)證器本質(zhì)上是一個(gè)二分類模型或打分模型輸入是“問(wèn)題 候選答案”輸出是一個(gè)分?jǐn)?shù)表示這個(gè)答案的可信度。常見(jiàn)做法有兩種結(jié)果驗(yàn)證器Outcome Reward Model, ORM只看最終答案是否正確給最終結(jié)果打分。過(guò)程驗(yàn)證器Process Reward Model, PRM在一步步推理中逐步打分能定位到錯(cuò)誤步驟但訓(xùn)練成本更高。結(jié)果驗(yàn)證器適合大多數(shù)工程場(chǎng)景過(guò)程驗(yàn)證器更適合推理鏈路長(zhǎng)、需要定位錯(cuò)誤位置的任務(wù)。驗(yàn)證器的訓(xùn)練數(shù)據(jù)怎么來(lái)常見(jiàn)思路是用大模型為同一個(gè)問(wèn)題生成多個(gè)候選答案然后通過(guò)人工標(biāo)注或者用權(quán)威答案自動(dòng)比對(duì)給每個(gè)候選打上正確/錯(cuò)誤標(biāo)簽再用排序損失訓(xùn)練一個(gè)打分模型。4.4 用大模型自身做驗(yàn)證如果不方便訓(xùn)練驗(yàn)證器還有一種折中方案讓大模型充當(dāng)驗(yàn)證器。做法是把問(wèn)題、候選答案一起給模型要求它判斷這個(gè)答案是否正確或者對(duì)多個(gè)答案進(jìn)行排序。這種方式無(wú)需訓(xùn)練效果取決于大模型自身的判斷能力。示例 prompt請(qǐng)判斷以下解題過(guò)程是否正確。如果正確請(qǐng)回答“正確”如果不正確請(qǐng)指出錯(cuò)誤原因。 題目一個(gè)三角形的三個(gè)內(nèi)角分別是 2x、3x 和 4x求 x 的值。 候選解答 2x 3x 4x 180 9x 180 x 20 請(qǐng)給出你的判斷。這種方式的好處是靈活缺點(diǎn)是會(huì)額外消耗 token而且大模型可能“看不出”錯(cuò)誤。在工程中可以先做字符串規(guī)則抽答案再用 LLM 驗(yàn)證沒(méi)有抽到答案的候選這樣成本更可控。5. 完整實(shí)戰(zhàn)案例為數(shù)學(xué)推理任務(wù)加入采樣與驗(yàn)證流程現(xiàn)在把前面講的內(nèi)容串起來(lái)實(shí)現(xiàn)一個(gè)“采樣 → 投票/驗(yàn)證 → 最終輸出”的完整流程。示例任務(wù)仍然是數(shù)學(xué)題但這套流程可以擴(kuò)展到代碼生成、SQL 生成、日志分析等任務(wù)。5.1 流程設(shè)計(jì)整體流程分四步接收用戶問(wèn)題。并行采樣生成 N 個(gè)候選答案。對(duì)候選答案做歸一化和抽取。用多數(shù)投票篩選最終答案若投票無(wú)法收斂則用 LLM 驗(yàn)證。5.2 完整代碼# 文件路徑test_time_pipeline.py import re from collections import Counter import openai client openai.OpenAI( api_keyyour-api-key, base_urlyour-base-url ) SYSTEM_PROMPT 你是一個(gè)嚴(yán)謹(jǐn)?shù)臄?shù)學(xué)解題助手。請(qǐng)分步推理并在最后單獨(dú)一行輸出最終答案。 def generate_answer(question: str, temperature: float 0.7) - str: resp client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: question} ], temperaturetemperature, max_tokens500 ) return resp.choices[0].message.content def extract_answer(text: str) - str: # 優(yōu)先抽取“最終答案”后面的內(nèi)容 patterns [ r最終答案[:]\s*([^\n。]), r答案是[:]\s*([^\n。]), rx\s*\s*([^\n。]), r([-]?\d(?:\.\d)?) ] for pattern in patterns: match re.search(pattern, text) if match: return match.group(1).strip() return text.strip() def majority_vote(answers: list[str]) - tuple[str | None, int]: extracted [extract_answer(ans) for ans in answers] counter Counter(extracted) answer, count counter.most_common(1)[0] if count 1: return None, count return answer, count def llm_verify(question: str, answer: str) - bool: verify_prompt f 請(qǐng)判斷下面的最終答案是否正確。如果正確請(qǐng)回答“正確”否則回答“不正確”。 題目{question} 最終答案{answer} 你的判斷 resp client.chat.completions.create( modelyour-model-name, messages[ {role: user, content: verify_prompt} ], temperature0, max_tokens100 ) content resp.choices[0].message.content return 正確 in content def solve_with_test_time_compute(question: str, n: int 5) - str: # Step 1: 并行采樣 candidates [generate_answer(question) for _ in range(n)] # Step 2: 多數(shù)投票 best_answer, count majority_vote(candidates) if best_answer is not None: return f多數(shù)投票結(jié)果: {best_answer}獲得 {count}/{n} 票 # Step 3: 投票不收斂時(shí)用 LLM 驗(yàn)證 for idx, cand in enumerate(candidates): extracted extract_answer(cand) if extracted and llm_verify(question, extracted): return fLLM 驗(yàn)證通過(guò): {extracted}來(lái)自第 {idx1} 個(gè)候選 # Step 4: 兜底返回第一個(gè)候選 return f驗(yàn)證未通過(guò)返回第一個(gè)候選: {extract_answer(candidates[0])} if __name__ __main__: q 一個(gè)三角形的三個(gè)內(nèi)角分別是 2x、3x 和 4x求 x 的值。 result solve_with_test_time_compute(q, n5) print(result)5.3 運(yùn)行結(jié)果說(shuō)明假設(shè)模型本身具備基礎(chǔ)數(shù)學(xué)能力那么 5 次采樣中通常會(huì)出現(xiàn) 3 到 4 次答案一致的情況程序會(huì)直接走“多數(shù)投票”分支并輸出結(jié)果。如果模型能力偏弱5 次采樣各自給出不同答案程序會(huì)進(jìn)入 LLM 驗(yàn)證分支逐一驗(yàn)證候選答案直到找到模型自身認(rèn)可的答案。如果所有候選都無(wú)法通過(guò)驗(yàn)證程序返回第一個(gè)候選作為兜底避免接口無(wú)輸出。這種設(shè)計(jì)保證了整個(gè)流程在工程上是健壯的不會(huì)因?yàn)槟骋淮尾蓸赢惓；蝌?yàn)證異常導(dǎo)致整體失敗。5.4 工程改造建議上面的代碼是一個(gè)串行演示版本。在實(shí)際服務(wù)中建議做以下改造用 asyncio 或線程池并發(fā)發(fā)起采樣請(qǐng)求把 5 次采樣時(shí)間從“5 倍單次延遲”壓縮到“接近 1 倍單次延遲”。對(duì)候選答案做緩存相同 prompt 在短時(shí)間內(nèi)的采樣結(jié)果可以復(fù)用。把投票和驗(yàn)證邏輯封裝成獨(dú)立服務(wù)方便不同模塊復(fù)用。增加超時(shí)和重試機(jī)制防止某個(gè)采樣請(qǐng)求一直阻塞。6. 常見(jiàn)問(wèn)題與排查思路測(cè)試時(shí)計(jì)算在實(shí)踐中會(huì)遇到不少問(wèn)題下面整理幾個(gè)高頻場(chǎng)景。問(wèn)題現(xiàn)象常見(jiàn)原因解決思路采樣結(jié)果千篇一律投票沒(méi)有意義溫度參數(shù)過(guò)低模型輸出趨于確定調(diào)高 temperature適當(dāng)降低 top_p多數(shù)投票選出的答案是錯(cuò)的模型本身能力不足大多數(shù)采樣都錯(cuò)考慮換更強(qiáng)的模型或訓(xùn)練任務(wù)專用驗(yàn)證器答案抽取不準(zhǔn)確投票失效正則規(guī)則沒(méi)覆蓋到模型的表述習(xí)慣先觀察 20 條真實(shí)輸出再完善抽取規(guī)則并行采樣導(dǎo)致接口延遲過(guò)高所有請(qǐng)求串行執(zhí)行用異步或線程池并發(fā)調(diào)用驗(yàn)證結(jié)果不穩(wěn)定同樣的輸入有時(shí)通過(guò)有時(shí)不通過(guò)LLM 驗(yàn)證時(shí)溫度過(guò)高隨機(jī)性大驗(yàn)證請(qǐng)求設(shè)置 temperature0多次驗(yàn)證取多數(shù)算力成本暴增采樣數(shù)量 N 設(shè)置過(guò)大先測(cè) N4 的效果再逐步增加到 8 或 16采樣結(jié)果長(zhǎng)度過(guò)長(zhǎng)token 消耗大沒(méi)有限制 max_tokens模型輸出冗長(zhǎng)設(shè)置合理的 max_tokens并要求“只輸出最終答案”這里重點(diǎn)說(shuō)一下答案抽取。很多人做多數(shù)投票時(shí)直接對(duì)完整文本去重結(jié)果發(fā)現(xiàn)同樣的答案因?yàn)楸磉_(dá)方式不同被當(dāng)成不同結(jié)果。比較好的辦法是先讓模型在 prompt 中按固定格式輸出比如“最終答案xxx”。代碼里先按固定標(biāo)記抽取。抽不到再走正則兜底。最后才考慮用 LLM 抽取。這樣做的核心原則是能用規(guī)則解決的事情不要用模型能一次抽準(zhǔn)的事情不要二次加戲。7. 最佳實(shí)踐與工程建議7.1 采樣數(shù)量 N 不是越大越好N 越大效果通常會(huì)更好但收益遞減非常明顯。從實(shí)際項(xiàng)目經(jīng)驗(yàn)看N4 到 N8 時(shí)性價(jià)比最高N 超過(guò) 16 后正確率提升趨于平緩成本和延遲卻線性增長(zhǎng)。建議上線前先做小規(guī)模實(shí)驗(yàn)畫出“N 值-正確率”曲線再?zèng)Q定線上參數(shù)。7.2 溫度參數(shù)要與任務(wù)匹配數(shù)學(xué)推理、代碼生成建議 temperature0.7top_p0.9。開(kāi)放對(duì)話、創(chuàng)意寫作建議 temperature0.9 以上。驗(yàn)證環(huán)節(jié)建議 temperature0。同一套并行采樣邏輯用在不同任務(wù)上需要單獨(dú)調(diào)參不要追一個(gè)參數(shù)走天下。7.3 驗(yàn)證器要關(guān)注“錯(cuò)誤接受率”用 LLM 做驗(yàn)證時(shí)最容易出問(wèn)題的不是把好答案拒掉而是把錯(cuò)誤答案放進(jìn)來(lái)。比如模型對(duì)錯(cuò)誤答案也說(shuō)“正確”這時(shí)候驗(yàn)證就失去了意義。在工程上可以引入“多次驗(yàn)證取多數(shù)”或者“驗(yàn)證規(guī)則雙重校驗(yàn)”來(lái)降低錯(cuò)誤接受率。在安全敏感的領(lǐng)域比如代碼生成、數(shù)據(jù)庫(kù) SQL 生成建議加上沙箱測(cè)試而不是只靠 LLM 判斷。7.4 并行采樣的資源控制并行采樣會(huì)放大對(duì)底層模型的調(diào)用壓力。建議在代碼中加入并發(fā)數(shù)限制例如用信號(hào)量控制最大并發(fā)請(qǐng)求數(shù)避免短時(shí)間大量請(qǐng)求打爆服務(wù)。下面是一個(gè)簡(jiǎn)單的并發(fā)控制示例# 文件路徑concurrency_control.py import asyncio import openai client openai.OpenAI( api_keyyour-api-key, base_urlyour-base-url ) semaphore asyncio.Semaphore(3) async def guarded_generate(prompt: str) - str: async with semaphore: loop asyncio.get_event_loop() def sync_call(): resp client.chat.completions.create( modelyour-model-name, messages[{role: user, content: prompt}], temperature0.7, max_tokens300 ) return resp.choices[0].message.content return await loop.run_in_executor(None, sync_call) async def parallel_generate(prompt: str, n: int 5) - list[str]: tasks [guarded_generate(prompt) for _ in range(n)] return await asyncio.gather(*tasks, return_exceptionsTrue) if __name__ __main__: results asyncio.run(parallel_generate(解釋一下什么是測(cè)試時(shí)計(jì)算。, n5)) for idx, res in enumerate(results, 1): if isinstance(res, Exception): print(f候選 {idx} 異常: {res}) else: print(f候選 {idx}: {res})7.5 日志與可復(fù)現(xiàn)性測(cè)試時(shí)計(jì)算引入了隨機(jī)性會(huì)導(dǎo)致同一個(gè)請(qǐng)求在不同時(shí)間得到不同的結(jié)果。這在調(diào)試時(shí)非常痛苦。建議在日志中記錄每個(gè)請(qǐng)求的prompt 版本溫度和 top_p 參數(shù)采樣次數(shù)每個(gè)候選答案及其抽取結(jié)果最終采用的候選編號(hào)同時(shí)在采樣時(shí)為每次請(qǐng)求生成一個(gè)隨機(jī)種子方便復(fù)現(xiàn)問(wèn)題。7.6 安全與權(quán)限邊界在真實(shí)項(xiàng)目中如果測(cè)試時(shí)計(jì)算用于生產(chǎn)環(huán)境涉及 SQL 生成、命令執(zhí)行、代碼生成等場(chǎng)景必須嚴(yán)格限制最終結(jié)果的執(zhí)行權(quán)限。建議所有生成結(jié)果默認(rèn)不自動(dòng)執(zhí)行先經(jīng)過(guò)人工確認(rèn)。代碼生成結(jié)果必須在沙箱環(huán)境中進(jìn)行測(cè)試。數(shù)據(jù)庫(kù) SQL 生成結(jié)果必須經(jīng)過(guò)只讀賬號(hào)驗(yàn)證并在測(cè)試庫(kù)執(zhí)行。在安全敏感操作中加入審批流程。測(cè)試時(shí)計(jì)算只是提升模型輸出質(zhì)量的手段不應(yīng)該繞過(guò)任何已有的安全邊界。7.7 評(píng)估線上效果時(shí)要注意評(píng)估測(cè)試時(shí)計(jì)算的效果不能只看正確率。需要同時(shí)觀察延遲P95 延遲是否可接受。成本單次請(qǐng)求的 token 消耗和 API 費(fèi)用。錯(cuò)誤模式是多數(shù)投票能解決還是必須上驗(yàn)證器?；赝藱C(jī)制驗(yàn)證不通過(guò)時(shí)是否有兜底策略。建議先在離線數(shù)據(jù)集上跑通全流程再小流量上線對(duì)比。8. 總結(jié)與后續(xù)學(xué)習(xí)方向測(cè)試時(shí)計(jì)算的核心邏輯并不復(fù)雜既然單次采樣不可靠那就多做幾次再引入驗(yàn)證機(jī)制來(lái)篩選。它把“訓(xùn)練時(shí)多花算力”變成了“推理時(shí)多花算力”在沒(méi)有改變模型權(quán)重的前提下提升了模型在推理任務(wù)上的可靠性。本文講清楚了幾件事什么是測(cè)試時(shí)計(jì)算以及它與訓(xùn)練階段計(jì)算的本質(zhì)區(qū)別。并行采樣如何通過(guò)溫度等參數(shù)控制多樣性。驗(yàn)證器的兩種路線無(wú)需訓(xùn)練的多數(shù)投票以及需要訓(xùn)練的驗(yàn)證器模型。一個(gè)完整的采樣投票LLM 驗(yàn)證流程及其代碼實(shí)現(xiàn)。工程落地時(shí)關(guān)于延遲、成本、護(hù)欄和評(píng)估的注意事項(xiàng)。下一步建議你在自己的任務(wù)上先跑一遍并行采樣基線記錄 N1、N4、N8 時(shí)的正確率和成本曲線。確認(rèn)收益后再考慮是否引入訓(xùn)練驗(yàn)證器。如果對(duì)思維搜索和過(guò)程驗(yàn)證器感興趣還可以進(jìn)一步看樹(shù)搜索在推理任務(wù)中的應(yīng)用。如果你在做 AI 智能體開(kāi)發(fā)或者正在搭建模型評(píng)估流程建議把文中的 pipeline 代碼改成你自己的任務(wù)格式跑一遍。測(cè)試時(shí)計(jì)算是一個(gè)“投入小、見(jiàn)效快”的優(yōu)化方向值得花一個(gè)下午做實(shí)驗(yàn)看看在你的任務(wù)上能提升多少。