做LLM預測LLM Forecasting之前我一直低估了評估指標的力量——一個Proper Scoring Rules正確評分規(guī)則的選型直接決定了模型在預測任務上長成什么樣。這兩年我陸續(xù)在幾個預測類產(chǎn)品里用大模型做概率判斷、趨勢估計和風險打分踩了很多評估上的坑之后才明白不是模型不會預測而是你用什么尺子去量它它就會朝什么方向長。這篇文章就把這塊經(jīng)驗完整梳理一遍從評分規(guī)則的原理到它對LLM訓練和推理的隱性影響再到完整的實操流程和排錯清單希望對正在做預測類LLM應用的同學有實際幫助。1. 為什么LLM預測繞不開評分規(guī)則1.1 準確率不是萬能的預測問題需要概率化評估我們做LLM應用時習慣性用準確率來評判模型效果預測漲了結(jié)果真漲了就算對預測跌了結(jié)果漲了就算錯。但真實場景里LLM預測很少是一個二選一的判斷題它通常要求模型輸出一個概率比如明日指數(shù)上漲的可能性是68%未來三個月需求波動超過20%的概率為四成。這時候用準確率去評估就完全失真了——你只會得到一個二值化的判定而模型輸出里最關鍵的概率信息被徹底丟棄。舉個直觀的例子模型A預測某事件發(fā)生概率為51%模型B預測為99%如果事件確實發(fā)生了用準確率看兩者都是正確但顯然模型B的判斷質(zhì)量遠高于模型A。反過來如果事件沒有發(fā)生模型A預測51%可能只是輕微偏差模型B預測99%就是極端置信下的巨大失誤準確率卻一視同仁地把兩者都判為錯誤。這種粗糙的評估方式無法區(qū)分蒙對的預測和真正理解不確定性的預測也就沒法指導你下一步該怎么優(yōu)化模型。所以做預測類應用第一步就是拋棄準確率思維換成能對概率質(zhì)量打分的評估指標。這也是我在實際項目里踩過最大的坑一開始用Accuracy衡量模型結(jié)果模型越調(diào)越極端輸出概率全部往0和1兩端擠因為這樣做更容易猜對。后來換成了Proper Scoring Rules正確評分規(guī)則來做評估模型的概率分布才變得合理起來。1.2 Brier Score與Log Loss最基礎的兩個正確評分規(guī)則Proper Scoring Rules是一類評分函數(shù)的統(tǒng)稱核心性質(zhì)是當預測者真實相信某個概率p時按照p來報告預測才能拿到最優(yōu)的期望分數(shù)。也就是說誠實報告是最好的策略任何虛報、極端化、保守化的報告都會在期望上吃虧。這個性質(zhì)對LLM尤其重要因為它給了模型一個說真話的數(shù)學激勵。實操中最常用的兩個評分規(guī)則是Brier Score和Log Loss對數(shù)損失。Brier Score的計算方式是預測概率與實際結(jié)果之差的平方公式很簡單[ Brier \frac{1}{N} \sum_{i1}^{N} (p_i - y_i)^2 ]其中p_i是模型給出的概率y_i是實際結(jié)果發(fā)生為1不發(fā)生為0。Brier Score的范圍是0到1越小越好。Log Loss則是取實際發(fā)生結(jié)果對應的預測概率的負對數(shù)[ LogLoss -\frac{1}{N} \sum_{i1}^{N} [y_i \cdot log(p_i) (1 - y_i) \cdot log(1 - p_i)] ]兩者性質(zhì)上有些微妙差別指標對極端錯誤的懲罰對中間概率的偏好適用場景Brier Score溫和按平方懲罰相對友好一般分類、比賽評估、業(yè)務風控Log Loss極強概率趨近0/1時損失趨近無窮鼓勵概率不要過于極端需要避免過度自信的場景CRPS連續(xù)值擴展版對分布整體打分銷量預測、天氣預測、量化交易Log Loss對模型在完全錯誤方向上的極端自信比如預測99%結(jié)果卻錯了懲罰極其猛烈這是比Brier Score更敏感的診斷工具也是為什么很多前沿預測競賽選擇用它做最終排名的原因。1.3 用錯評分規(guī)則的代價模型會學會鉆空子我不止一次看到團隊在評估LLM預測時用了一套不合適的規(guī)則導致模型的預測行為被帶偏。最有名的案例邏輯是這樣的如果評估只看預測概率是否超過50%這個閾值那么模型只要把概率盡量往極值推就能最大化命中率——反正超過50%就算贏。結(jié)果就是模型輸出的概率嚴重失真看起來預測很自信實際上完全經(jīng)不起校準檢驗。Proper Scoring Rules之所以proper在于它天然杜絕了這種鉆空子行為。如果你真實認為概率是70%虛報到90%并不能提高你的期望得分因為Brier Score和Log Loss都懲罰過度自信虛報到50%也同樣吃虧因為這會損失你在正確方向上的一部分正收益。這種機制保證了誠實報告的期望收益最大化。再往深一層想評分規(guī)則不只是事后評估工具它本質(zhì)上是優(yōu)化目標的載體。無論你是在做RLHF獎勵模型還是在下游任務里微調(diào)LoRA只要損失函數(shù)里隱含了對預測行為的衡量評分規(guī)則就在悄悄改變模型的策略空間。所以選對評分規(guī)則本質(zhì)上是在給模型立規(guī)矩——這也是Proper Scoring Rules Shape LLM Forecasting這句話背后最核心的機制。2. 評分規(guī)則如何反向塑造LLM的預測行為2.1 交叉熵損失LLM從出生就在被評分規(guī)則訓練聊到LLM工作原理很多人第一反應是預測下一個token但很少有人在預測下一個token和Proper Scoring Rules之間畫等號。事實上LLM預訓練階段的損失函數(shù)——交叉熵損失就是Log Loss的廣義版本。模型每預測一個token都是在給整個詞表上的每個候選詞分配一個概率分布然后用真實token對應位置的負對數(shù)似然作為損失。所以嚴格來說LLM在訓練階段已經(jīng)經(jīng)歷了海量的評分規(guī)則優(yōu)化它被反復訓練成盡可能準確地用概率表達下一個token的可能性。這帶來一個有意思的推論——大模型的底層表征對概率預測是有先天敏感度的它天生被訓練為不撒謊的概率預測器。但問題是這個訓練目標是在token空間里而不是在用戶問的事件空間里。當你問模型你覺得明天漲的概率有多少時模型需要把它在海量文本里學到的統(tǒng)計規(guī)律轉(zhuǎn)化成一個具體領域的概率數(shù)值。這個過程容易出錯原因有兩個第一事件空間的邊界模糊用戶說上漲到底指漲幅超過多少第二模型在文本生成過程中受語氣、上下文、角色設定的影響太大容易被帶偏。所以雖然底層機制在誠實預測但表層輸出卻容易出現(xiàn)各種偏差。2.2 對齊階段的隱性信號獎勵函數(shù)也在用評分邏輯到了RLHF基于人類反饋的強化學習階段評分規(guī)則的影響就更加直接了。RLHF的核心是訓練一個獎勵模型來模擬人類偏好然后用強化學習讓LLM的輸出拿到更高獎勵。如果你希望LLM在預測任務上表現(xiàn)好那么獎勵模型的構(gòu)建方式、評估數(shù)據(jù)的標注方式本質(zhì)上就是在定義一個評分規(guī)則。我做預測類產(chǎn)品時觀察到一個很典型的例子人類標注員在評估LLM預測質(zhì)量時天然傾向于結(jié)果對了就打高分結(jié)果錯了就打低分而不是去評估模型給出的概率是否合理。這樣一來獎勵模型就變成了一個二值化的馬后炮評判器模型在RLHF階段學到的策略就會變成要么給出模糊的、難以證偽的預測要么在內(nèi)部自我確認后給出極端概率盡量規(guī)避被打低分的風險。這就解釋了為什么很多通用LLM在零樣本預測任務上表現(xiàn)不理想——它被對齊成了讓人滿意而非預測準確。想糾正這一點要么在提示詞層面設計更精細的評估框架要么在微調(diào)階段直接用Brier Score或Log Loss這類Proper Scoring Rules作為獎勵函數(shù)的一部分。后者已經(jīng)有研究論文在探索核心思想是讓強化學習的獎勵信號來自校準的預測質(zhì)量而不是人類的事后主觀判斷。2.3 置信度與校準模型的概率輸出值不值得信評估LLM預測時我特別看重一個概念校準度Calibration。校準度指的是當模型說某事有70%概率發(fā)生時這件事在現(xiàn)實中是否真的以接近70%的頻率發(fā)生。一個高度校準的模型它的概率輸出與真實頻率高度吻合而一個校準差的模型可能說70%但實際只有40%也可能說60%但實際到80%。用生活化的方式理解校準一個天氣預報員如果說明天降雨概率70%那么一周之內(nèi)他給出70%預報的日子應該有大約7成真的下雨。如果實際只有3天下雨那這個預報員就嚴重過度自信了。LLM也是如此我見到太多模型在回答預測類問題時傾向于輸出80%到95%的高概率區(qū)間無論問題多難、信息多不充分。這種過度自信本質(zhì)上是模型生成聽起來合理文本的副作用而不是真實的不確定性表達。校準度與評分規(guī)則的關系非常密切Brier Score和Log Loss都可以分解為校準誤差和銳度兩部分。校準誤差衡量的是預測概率與實際頻率的系統(tǒng)性偏差銳度衡量的是預測分布的尖銳程度——一個總是輸出50%的模型校準可能很好但銳度很差因為它沒有提供任何有效區(qū)分信息。Proper Scoring Rules同時懲罰校準誤差和銳度的不均衡所以它評估的不只是準不準還有有沒有信息量。2.4 輸出空間的選擇文本、JSON、還是多次采樣在真實系統(tǒng)里LLM預測的輸出形式直接影響評分質(zhì)量。我建議預測類應用盡量不要讓模型自由發(fā)揮輸出一段包含概率的文字描述因為解析成本高、概率容易缺失、語義模糊。更務實的做法是定義嚴格的輸出schema讓模型結(jié)構(gòu)化的輸出JSON比如{ event: stock_index_up, probability: 0.68, confidence_interval: [0.55, 0.80], reasoning: 基于近期流動性改善和情緒修復 }不過要注意一點很多LLM平臺比如接入LLM時常用的dify或自研框架在配置模型輸出時默認會讓模型附帶思考過程或推理鏈路這在對話場景里很有用但用在預測打分場景里就是災難——思考過程會占用token預算導致schema輸出被截斷甚至把概率值擠到被忽略的位置。所以接入時一定要顯式關閉輸出思考過程或者設置合理的max_tokens讓模型優(yōu)先保證結(jié)構(gòu)化字段的完整性。另外單個采樣得到的概率值方差很大。同一個prompt在temperature1.0下跑十次可能得到0.4、0.5、0.7、0.35這樣跳來跳去的結(jié)果。一個很有效的工程技巧是多次采樣取均值或者對多個采樣結(jié)果做整體分布統(tǒng)計把模型平均概率作為最終輸出。這本質(zhì)上是在用蒙特卡洛方法平滑單次生成的隨機性得到更穩(wěn)定的概率估計。3. 實操給LLM搭一套評分與校準的完整流程3.1 任務定義與數(shù)據(jù)準備先確定你要預測什么完整流程的第一步是明確定義預測任務。我以一個很常見的場景為例預測某只股票未來五個交易日的漲跌概率。這類任務有兩個好處一是結(jié)果可驗證五天后數(shù)據(jù)自然出結(jié)果二是能持續(xù)積累測試集方便做長期的評分追蹤。數(shù)據(jù)準備階段要注意把歷史數(shù)據(jù)切成獨立的樣本避免數(shù)據(jù)泄漏。比如你計劃用過去兩年的數(shù)據(jù)進行回測就要把數(shù)據(jù)集按時間順序劃分訓練窗口在時間上嚴格早于測試窗口。預測日期、預測事件漲跌幅閾值、實際結(jié)果是三個核心字段。不要用模型已經(jīng)見過的未來信息去提示它哪怕你只是在prompt里無意中提到了本周市場已經(jīng)上漲了3%這都會干擾測試的有效性。3.2 設計Prompt模板與輸出Schema提示詞模板的質(zhì)量直接影響預測效果。我的經(jīng)驗是預測類Prompt應該包含四部分任務背景、輸入數(shù)據(jù)、預測要求、輸出格式。任務背景要講清楚你是一個資深策略分析師之類角色設置但不建議過度渲染角色因為過度角色化會讓模型傾向于輸出有觀點而不是有概率的結(jié)論。輸入數(shù)據(jù)部分盡量用簡潔的表格或列表呈現(xiàn)避免大段文字把模型的注意力帶偏。預測要求部分要顯式寫清楚請基于給定信息給出嚴謹?shù)母怕逝袛嗖灰獮榱肆龆鴺O端化概率如果信息不足請適當降低置信度。這類句子能一定程度上抑制模型的過度自信。輸出格式部分用JSON Schema描述得越具體越好同時附上最少一個示例模型對few-shot格式的學習能力遠強于對純描述的遵循能力。一個我在項目中反復調(diào)優(yōu)后的Prompt模板大致長這樣你是一位嚴格遵循貝葉斯思維的概率預測助手。請根據(jù)以下歷史數(shù)據(jù)和市場背景 預測目標事件發(fā)生的概率。注意概率必須是校準的即你認為有70%把握時 事件實際發(fā)生頻率應接近70%。 [數(shù)據(jù)輸入] 股票X近20個交易日收盤價 [...] 近期成交量變化 [...] [任務] 預測3個交易日內(nèi)股票X收盤價上漲超過1%的概率是多少 請輸出JSON格式{probability: 0到1之間的小數(shù), reasoning: 不超過50字的依據(jù)} [要求] 1. 嚴格輸出JSON不要輸出其他內(nèi)容。 2. probability必須是0到1之間的數(shù)字不要使用百分比字符串。3.3 采樣、解析與評分計算拿到模型的輸出后先做解析和過濾。我會用JSON解析庫讀取probability字段如果解析失敗就把該樣本標記為異常如果reasoning字段缺失但不影響概率解析也可以保留。多做一步很值得對同一個預測任務重復采樣3到5次把多次概率取平均后作為最終預測值。實測下來多次采樣平均能把單次生成的隨機噪聲大幅降低校準表現(xiàn)更穩(wěn)定。接下來就是評分環(huán)節(jié)。這里給出一個可直接復制的Python實現(xiàn)用來計算Brier Score和Log Lossimport numpy as np from sklearn.metrics import brier_score_loss, log_loss # predictions和outcomes是平行數(shù)組 # predictions是0到1之間的概率outcomes是0或1的實際結(jié)果 predictions np.array([0.68, 0.42, 0.90, 0.31, 0.75]) outcomes np.array([1, 0, 1, 0, 1]) brier brier_score_loss(outcomes, predictions) ll log_loss(outcomes, predictions, labels[0, 1]) print(fBrier Score: {brier:.4f}) print(fLog Loss: {ll:.4f}) # 對比baseline預測長期基準頻率比如樣本中正類占比 base_rate outcomes.mean() baseline_pred np.full_like(predictions, base_rate) brier_base brier_score_loss(outcomes, baseline_pred) ll_base log_loss(outcomes, baseline_pred, labels[0, 1]) print(fBaseline Brier: {brier_base:.4f}) print(fBaseline Log Loss: {ll_base:.4f})如果模型的Brier Score和Log Loss比baseline好不了太多說明模型并沒有真正學到預測信號只是在輸出感覺上合理的概率。這個對比基準是很多團隊最容易漏掉的一步——不做baseline對比你根本不知道模型的絕對分數(shù)是優(yōu)秀還是不及格。3.4 校準檢查與溫度調(diào)節(jié)評分計算完之后一定要做校準檢查。最簡單高效的診斷手段是可靠性圖Reliability Diagram把預測概率分為幾個區(qū)間比如0-0.1、0.1-0.2……0.9-1.0然后統(tǒng)計每個區(qū)間的實際結(jié)果頻率看兩者是否接近對角線。如果點都落在對角線下方說明模型整體過度自信落在線下方說明預測概率系統(tǒng)性偏高。修正校準偏差有幾種常用手段。第一種是溫度縮放Temperature Scaling把模型的logits除以一個常數(shù)溫度T后再做softmaxT越大預測概率越趨于平滑。對LLM而言temperature參數(shù)不僅影響生成多樣性也直接影響概率輸出的銳度降低temperature能讓輸出概率更保守、更集中。第二種是經(jīng)驗校準Empirical Calibration收集模型在歷史測試集上的預測結(jié)果擬合一個從模型概率到實際頻率的映射函數(shù)然后再對后續(xù)預測做映射修正。這個方法在工程上最實用等于是給模型加了一層事后的誠實化校正。第三種是用提示詞引導告訴模型如果你的預測過度自信請降低概率之類的話效果存在但不如前兩種穩(wěn)定。我在一個實際項目里用溫度縮放做了一組對比測試temperature0.2時模型的Brier Score比temperature1.0時改善了約30%主要原因是極端概率的出現(xiàn)頻率明顯下降校準曲線更貼近對角線。但溫度過低也會導致預測喪失區(qū)分度所以最終參數(shù)通常需要通過驗證集調(diào)優(yōu)而不是盲目取低。4. 常見問題與排查技巧實錄4.1 請求超時與模型無響應預測類應用經(jīng)常遇到LLM請求超時報錯信息是llm request timed out. the model did not produce a response before the deadline。這類問題的根因通常不是網(wǎng)絡而是模型在生成長篇思考過程或reasoning字段時消耗了過多token導致響應時間超過網(wǎng)關設置的閾值。排查思路很直接先看調(diào)用日志里實際生成的token數(shù)再看max_tokens配置是否過小最后看prompt是否觸發(fā)了模型輸出大量分析文本。我的做法是預測類任務統(tǒng)一設置max_tokens在200到500之間并顯式要求模型不要輸出除JSON外的任何解釋性內(nèi)容。如果任務本身需要復雜的邏輯推理就把推理拆到單獨一個prompt里完成再讓另一個prompt基于推理結(jié)果輸出預測。這樣能避免一個請求干太多事導致的超時問題代價是增加了調(diào)用次數(shù)但勝在穩(wěn)定可控。4.2 模型不按Schema輸出接入LLM平臺時經(jīng)常遇到provider rejected the request schema or tool payload這類錯誤。出現(xiàn)這個問題的原因通常是輸出schema定義過于復雜或者使用了平臺不支持的類型標簽。文檔里說得清楚但實際踩坑時才發(fā)現(xiàn)很多平臺只支持部分JSON Schema特性。我的建議是schema盡量扁平不要嵌套太深boolean類型能不用就不用統(tǒng)一用0/1或字符串替代數(shù)組元素類型保持一致避免混合類型。另外就是容錯解析。即便schema定義正確模型偶爾也會輸出殘缺的JSON尤其當token預算吃緊時。我習慣在解析層做三層兜底第一層直接json.loads第二層用正則提取probability字段第三層如果提取失敗就把這條樣本標記為預測失敗讓它不參與評分。千萬不要讓解析失敗拖垮整個評分流程記錄好失敗率本身也是一個重要的質(zhì)量指標。4.3 預測概率輸出不穩(wěn)定同一個prompt同一個模型連續(xù)跑三次得到完全不同的概率這是概率輸出不穩(wěn)定問題。模型生成存在隨機性這是常識但對預測類應用來說這種不穩(wěn)定是致命的因為用戶會質(zhì)疑系統(tǒng)的專業(yè)性。最有效的治理手段是多次采樣平均。我在工程里會把采樣次數(shù)設為5逐個請求再合并結(jié)果計算平均概率和標準差。標準差本身也能提供額外信息如果某個預測問題的標準差特別大說明模型對這個問題沒有一致的意見這個預測本身就更值得懷疑。這一招在金融預測類場景里尤其好用可以把模型不確定變成產(chǎn)品的一個賣點。另外很多推理框架支持設置隨機種子固定seed能讓同一輸入得到穩(wěn)定輸出適合A/B測試對齊場景。4.4 模型過度自信輸出永遠在90%以上我遇到最多的預測質(zhì)量問題就是LLM無論什么問題都給出80%以上的高概率似乎什么事件都很有把握。這類問題光看Brier Score不容易發(fā)現(xiàn)因為它有時甚至能拿到不錯的分數(shù)但要疊加可靠性圖就原形畢露——預測90%的樣本實際準確率可能只有60%。診斷方法把多次預測結(jié)果按概率分箱統(tǒng)計各箱的實際頻率。如果預測概率和實際頻率的系統(tǒng)偏差很規(guī)律首選溫度縮放如果偏差集中在某個概率段考慮用經(jīng)驗校準映射。我見過一個比較離譜的case模型因為系統(tǒng)提示詞里寫了你是專家級分析師結(jié)果把專家理解成必須自信所有預測都往90%以上走。把角色設定改成嚴謹、承認不確定性的科研人員后概率分布立刻恢復正常。所以排查時先看提示詞的角色設定是否在誘導模型極端輸出這一條往往被人忽略但其實改動成本最低、效果最直接。最后做個小結(jié)之外的經(jīng)驗分享做LLM預測評估別把目光只盯在猜得對不對上。我個人的體會是一套靠譜的評分體系加上校準檢查比換更大的模型、調(diào)更長的prompt帶來的提升都明顯。評估規(guī)則設計好了模型自然會被引導著輸出更誠實、更有區(qū)分度的預測——這個先有尺子再量長度的思路比你反復試各種提示詞技巧重要得多。如果你也在做類似的預測應用建議從Log Loss加可靠性圖的組合開始先跑通再優(yōu)化這個基礎打牢之后后續(xù)的模型微調(diào)和提示詞工程才有可靠的標尺。