非確定性輸出的歸一化Harness層后處理做LLM應(yīng)用的不確定性最常被掛在嘴邊的就是采樣溫度、top-p好像把這兩個參數(shù)穩(wěn)住輸出就穩(wěn)了。直到有一次我排查一個線上事故同一批prompt、同一個模型版本、同一組參數(shù)只是發(fā)版排期差了半天用戶的反饋是“結(jié)果和昨天不一樣了而且格式開始飄”當(dāng)時第一反應(yīng)是模型被人動過查了一圈之后發(fā)現(xiàn)根本沒動最后才把鍋扣在了一堆看似不起眼的工程細(xì)節(jié)上。那次之后我認(rèn)真做了一件事在harness層加了一套輸出后處理專門用來歸一化非確定性輸出。這里說的“非確定性”不是算法上故意保留的那部分隨機(jī)性而是工程實現(xiàn)帶來的、本不該出現(xiàn)的差異。把這類差異在harness層消化掉下游拿到的結(jié)果才談得上穩(wěn)定、可比、可回歸。這篇文章就把當(dāng)時踩過的坑和這套后處理的實現(xiàn)思路完整拆開講。1. 先想清楚要歸一化的到底哪里不確定1.1 兩種非確定性設(shè)計與工程要分開看LLM輸出的非確定性來自兩個層面。一個是采樣機(jī)制本身比如temperature大于0時每次結(jié)果不一樣這屬于設(shè)計上故意保留的隨機(jī)性給足了對話的“生命力”不需要歸一化也不能歸一化另一種是工程實現(xiàn)引入的差異例如GPU算子執(zhí)行順序、浮點累加誤差、批量padding對attention mask的影響、緩存命中狀態(tài)不一致等等。這類差異有一個共同特點即使把隨機(jī)種子固定、把采樣參數(shù)調(diào)成完全一致輸出仍然會抖。我們團(tuán)隊做的是某企業(yè)內(nèi)部知識庫問答系統(tǒng)的推理層底層接了開源的中等規(guī)模模型。當(dāng)時線上遇到的現(xiàn)象很有意思用戶問同樣一句話只要不問同一個批次的請求返回的答案一會兒是“74.5%”一會兒是“74.499999999%”一會兒是“74.5 %”。這就是典型的浮點路徑不同產(chǎn)生的差異加上模型在生成數(shù)字token時對精度極其敏感一個小數(shù)點的形式差異就會讓下游的數(shù)據(jù)模塊直接解析失敗。再深挖一點模型自回歸生成時每一步的logits都依賴之前所有token的路徑。如果第一步因為padding mask的形狀不同產(chǎn)生了一個微小浮點偏差這個偏差會隨著生成長度逐步累積。短文本還不明顯長文本到了后面可能連答案的主干都換了。1.2 底層差異如何穿透到最終輸出我做過一次典型的對比實驗固定seed同一個promptbatch size分別設(shè)為1和4貪心解碼不做任何后處理。batch size為4的時候每條prompt為了和其他樣本對齊高度都會被pad到相同長度。表面上padding token被mask掉了但這種mask是通過給attention score加一個極大的負(fù)數(shù)實現(xiàn)的在fp16精度下極負(fù)數(shù)加上gradient累積之后softmax分母的極小差異會衍生出截然不同的采樣路徑。更隱蔽的是前綴緩存prefix cache這一層。請求如果命中了緩存decode從緩存斷點開始走沒命中的話從prompt第一token開始算。兩邊的浮點路徑天然不一致導(dǎo)致即使兩個請求的prompt完全一樣命中緩存和不命中緩存返回的結(jié)果也可能不一樣。我在線下復(fù)現(xiàn)時發(fā)現(xiàn)這種差異在temperature0的貪心解碼里都能出現(xiàn)。這也是為什么必須把歸一化放在harness層——光靠“統(tǒng)一參數(shù)”根本無法消除這類差異差異是穿透所有參數(shù)設(shè)置直達(dá)最終文本的。2. 歸一化為什么必須放在Harness層2.1 三種歸一化位置的取舍關(guān)于歸一化邏輯放在哪一層我考慮過三個位置推理引擎內(nèi)部、harness層、應(yīng)用側(cè)。推理引擎內(nèi)部最徹底比如在采樣算子前強(qiáng)制對齊浮點路徑在attention計算后統(tǒng)一做一次數(shù)值規(guī)整。但這么做代價極高引擎是第三方開源組件改動意味著要維護(hù)fork版本一旦上游升級所有補(bǔ)丁都要重新適配回歸成本太大。應(yīng)用側(cè)也能做但應(yīng)用側(cè)面對的是最終用戶的直接請求每個調(diào)用方對“穩(wěn)定”的理解不一樣有人希望格式統(tǒng)一有人希望保留markdown規(guī)范寫在應(yīng)用側(cè)管不住其他人怎么調(diào)用。harness層是推理服務(wù)和上層應(yīng)用之間的編排層所有請求和響應(yīng)都必須經(jīng)過這里。在這里做歸一化有三個好處第一是位置天然適合做“兜底”不管上游引擎輸出什么harness層都有機(jī)會修正第二是不污染引擎本身發(fā)布和回滾都友好第三是接口協(xié)議穩(wěn)定下游應(yīng)用拿到的一直是同一套規(guī)范化的結(jié)構(gòu)不會因為接入方變了輸出格式就崩。2.2 Harness層后處理的邊界有人會擔(dān)心歸一化會不會把模型真正“想表達(dá)”的內(nèi)容給改掉。這個擔(dān)心是有道理的所以我給后處理定了一條硬性原則只做形式歸一化不做內(nèi)容改寫。具體來說凡是影響下游解析、展示、統(tǒng)計、比較的形式差異都在后處理范圍內(nèi)。例如JSON輸出的鍵順序不同、數(shù)字精度不同、markdown代碼塊標(biāo)記不同、全半角符號混用、換行符不統(tǒng)一、列表符號風(fēng)格漂移這些都要處理。而模型生成的語義內(nèi)容比如答案的主體文字、觀點方向、關(guān)鍵結(jié)論一律不碰。這條邊界守不住歸一化就會變成一把殺敵一千自損八百的刀。我還做了一件事在后處理前后各打一份日志把原始輸出和處理后的輸出同時記錄下來。這樣既能追溯問題也能檢驗歸一化規(guī)則是否越界——如果某條規(guī)則把語義內(nèi)容也不小心改了通過對比日志能快速定位是哪條規(guī)則干的。2.3 我們實際用的Harness結(jié)構(gòu)我在代碼里搭了一個非常輕量的后處理管線核心思路是把“抽取、規(guī)范化、重排、校驗”四步串起來class OutputNormalizer: def normalize(self, raw_output: str) - str: text self._extract_content(raw_output) text self._canonicalize_format(text) text self._rebuild_structure(text) self._validate(text, raw_output) return text每一步都有獨立的規(guī)則模塊方便單獨調(diào)試。抽取看圖、格式化管格式、重建管結(jié)構(gòu)、校驗管安全職責(zé)分開后規(guī)則越加越多也能保持可控。3. 這幾類差異是真正坑過我的逐一說明3.1 JSON鍵順序與縮進(jìn)差異模型生成的JSON鍵順序經(jīng)常不固定。今天返回{name: ..., score: 0.97}明天就變成{score: 0.97, name: ...}。如果下游直接拿字符串做hash對比、或者按位置解析字段就會出現(xiàn)“內(nèi)容沒變程序覺得變了”的詭異問題。我在歸一化里強(qiáng)制做了canonical JSON處理鍵按字典序排序、冒號后不留空格、逗號后不留空格、確保ASCII字符不轉(zhuǎn)義。用Python的話就是import json def canonicalize_json(obj): return json.dumps( obj, sort_keysTrue, ensure_asciiFalse, separators(,, :) )值得注意的坑是ensure_ascii默認(rèn)值True會把中文轉(zhuǎn)成\uXXXX這會讓同一個中文內(nèi)容在字符串層面看起來完全不同。必須置為False。另外sort_keys對嵌套的dict同樣生效這能保證最終結(jié)果的穩(wěn)定。3.2 數(shù)字精度與格式差異數(shù)字是重災(zāi)區(qū)。模型在生成數(shù)字token時一個token是“74.5”下一個token可能是“%”也可能是“.0%”。還有科學(xué)計數(shù)法“7.45e01”和普通計數(shù)“74.5”混用的情況。歸一化策略分三步先嘗試把字符串轉(zhuǎn)成float再把規(guī)范化的數(shù)字文本提取出來然后統(tǒng)一精度例如統(tǒng)一保留1位或按需求保留固定小數(shù)位最后對單位、百分號等后綴做對齊。代碼思路如下import re from decimal import Decimal, ROUND_HALF_UP def normalize_number(text: str) - str: text text.strip().replace(,, ) if text.endswith(%): value Decimal(text[:-1]).quantize( Decimal(0.1), roundingROUND_HALF_UP) return f{value}% try: value Decimal(text).quantize( Decimal(0.1), roundingROUND_HALF_UP) return str(value) except Exception: return text.strip()這里用Decimal而不是float是因為float在二進(jìn)制表示下會出現(xiàn)74.499999999這種奇葩值Decimal配合ROUND_HALF_UP能穩(wěn)定四舍五入。3.3 全角半角空格、換行這些“看不見的敵人”中英文混排場景下模型經(jīng)常一會兒輸出全角逗號“”一會兒輸出半角逗號“,”JSON字段名后面一會兒有空格一會兒沒空格換行符可能是\n可能是\r\n。對用戶來說肉眼幾乎無差別但對文本比較、格式解析來說完全是兩個字符串。我的歸一化規(guī)則里加了一條全角轉(zhuǎn)半角的邏輯但只針對標(biāo)點符號不轉(zhuǎn)換中文內(nèi)容本身的字符FULL_TO_HALF { : ,, 。: ., : :, : ;, : (, : ), : !, : ?, “: , ”: , ‘: , ’: } def normalize_punctuation(text: str) - str: for full, half in FULL_TO_HALF.items(): text text.replace(full, half) return text.replace(\r\n, \n).strip()換行統(tǒng)一用\n首尾空格去掉。如果下游是數(shù)據(jù)庫或網(wǎng)頁展示這步能省掉無數(shù)無效報警。3.4 Markdown代碼塊與標(biāo)記語言差異很多模型的輸出是帶格式的開頭結(jié)尾、前后有語言標(biāo)記、內(nèi)部有縮進(jìn)。如果下游是一個純文本展示組件代碼塊標(biāo)記會原樣顯示出來觀感很差如果下游是一個解析器標(biāo)記不一致又會導(dǎo)致整段解析失敗。我做的后處理規(guī)則是檢測markdown fence標(biāo)記提取代碼塊內(nèi)的正文內(nèi)容再根據(jù)下游需求決定是否保留語言標(biāo)記。例如當(dāng)返回文本不需要代碼塊時直接把python替換成空字符串并把代碼塊中的內(nèi)容保留為普通文本。import re FENCE_RE re.compile(r[a-zA-Z0-9_-]*\n(.*?), re.DOTALL) def extract_code_block(text: str) - str: match FENCE_RE.search(text) if match: return match.group(1).strip() return text.strip()這條規(guī)則特別適合用在知識庫答案抽取的場景——我只需要答案正文不需要一堆fence干擾下游展示。3.5 伴隨狀態(tài)剔除與統(tǒng)一模型有時候會在正式答案前加一些狀態(tài)描述比如“好的我來分析一下這個問題”、“根據(jù)我的理解”、“需要注意的是”。這些語句本身不攜帶關(guān)鍵信息但對需要做純結(jié)構(gòu)解析的下游來說就是噪音。后處理會把這層概述去掉只保留答案主干如果需要給用戶看“對話感”再在harness層重新拼接模板。做這步時一定要謹(jǐn)慎。我只能剝離“狀態(tài)描述”不能剝離“結(jié)論性語句”。判斷標(biāo)準(zhǔn)是如果去掉這句話答案的語義是否受影響。不受影響才允許剝離。4. 在引擎?zhèn)茸龅膸讉€配套確定性保障4.1 選擇確定性解碼算子harness層的歸一化只是兜底不能只靠它。我在推理引擎?zhèn)纫沧隽艘幌盗信涮坠ぷ?。第一件事就是把采樣路徑固定下來。開源模型的推理代碼里sampling部分通常會調(diào)torch.multinomial、F.softmax等算子。這些算子在GPU上有非確定性實現(xiàn)但很多框架也提供了deterministic開關(guān)。我在配置里強(qiáng)制打開確定性模式并固定torch.manual_seed。這個操作不能簡單寫一行要在每次推理前重置seed同時確保多卡并行時各卡拿到一致的seed。import torch def setup_deterministic(seed: int): torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) torch.backends.cudnn.deterministic True torch.backends.cudnn.benchmark FalsebenchmarkFalse要解釋一下cuDNN的benchmark模式會根據(jù)輸入形狀選擇最快的卷積實現(xiàn)速度快但選中的算子可能隨輸入尺寸變化而變化導(dǎo)致同一模型在不同batch size下走不同實現(xiàn)、產(chǎn)生不同浮點結(jié)果。關(guān)了之后性能略降但換來的是穩(wěn)定性。4.2 消除padding引入的logits噪聲padding是隱藏最深的不確定源。動態(tài)batch通常會把同批次請求pad到相同長度不同批次的pad位置不同attention mask覆蓋的范圍不同softmax計算時的分母也會不同差異就順著自回歸路徑傳下來了。我在harness層做了一個調(diào)度調(diào)整按請求的max_new_tokens和輸入長度分組讓同批次請求盡可能有相近的輸入長度。長度差異太大的請求拆到不同批次里這樣被padding影響的概率就小了。再來我在后處理中做了一次歸一化校驗——如果發(fā)現(xiàn)同一請求被引擎以不同批次處理時輸出明顯不一致就記錄下來并觸發(fā)分批次重算。這里有個取舍要說明拆batch會降低吞吐但因為后處理payload本身不大實際線上耗時增量可以接受。4.3 固定隨機(jī)源與統(tǒng)一批次形狀除了采樣算子的seed還要關(guān)注prompt拼接時使用的random函數(shù)是否被污染。有一次發(fā)現(xiàn)一個同事在構(gòu)建prompt模板時用了random.choice來選開場白雖然結(jié)果是合法的但導(dǎo)致同一條prompt在兩次請求中的實際輸入不同。這種問題后處理完全兜不住因為輸入就不一致了。后來在harness層加了一個prompt指紋校驗每次構(gòu)建完prompt計算一個hash值如果同一業(yè)務(wù)請求的hash不一致直接報錯返回。這樣能把“污染輸入”的問題堵在源頭。5. 常見問題與排查技巧實錄5.1 盲區(qū)一都是貪心解碼為什么還是不一致這是被問得最多的一個問題。很多人的直覺是temperature0解碼就是argmax應(yīng)該完全確定。但實際不是。貪心解碼過程中的每一步還是要走softmax算概率分布再取最大概率token。GPU上softmax的實現(xiàn)可能因為數(shù)據(jù)并行、算子融合策略不同在最后的浮點比較上產(chǎn)生細(xì)微差異。如果兩個token的概率差在10的負(fù)6次方以下這個差異就會被放大成不同的選擇。排查時先別懷疑模型先把同一份輸入多跑幾次把softmax輸出的具體數(shù)值打印出來比較。如果每次的logits最后一位不一樣問題基本就在算子層面。5.2 盲區(qū)二歸一化后batch1和batch8的結(jié)果仍然不一致這通常不是后處理的鍋而是padding對logits_mask的影響已經(jīng)超出了形式層。歸一化只能處理文本形式和結(jié)構(gòu)差異無法處理因為mask不同導(dǎo)致的語義走向不同。此時需要在harness層強(qiáng)制按“單條獨立”或“同形狀”方式調(diào)度。我檢查后發(fā)現(xiàn)罪魁禍?zhǔn)资情L度分組沒做徹底。后來在調(diào)度邏輯里加了一個更嚴(yán)格的約束同一批次的輸入長度上限差值不能超過8個token超出就拆分批次。5.3 盲區(qū)三日志與返回內(nèi)容不一致有陣子線上排查問題時發(fā)現(xiàn)日志里的原始輸出和用戶看到的內(nèi)容完全對不上。后來發(fā)現(xiàn)是后處理改了文本但日志打的是原始內(nèi)容這其實很正常。問題是排查的人不知道后處理做了什么誤以為是引擎bug。我的解法是讓日志同時輸出歸一化前后的兩個版本并且附上歸一化規(guī)則ID列表。這樣任何人排查時都能快速定位是引擎變了還是后處理規(guī)則變了還是下游解析邏輯變了。5.4 盲區(qū)四歸一化不小心把多樣性也抹掉了在做多候選答案時遇到過一種尷尬為了比較多個生成結(jié)果我把它們?nèi)孔隽藲w一化結(jié)果兩個本來語義不同的答案因為格式統(tǒng)一后變得難以區(qū)分——這不是歸一化錯而是我忘記在比較前保留語義層面的差異。我的建議是歸一化永遠(yuǎn)只用于“格式比較”和“結(jié)構(gòu)解析”不用于“語義質(zhì)量評估”。語義評估必須回到原始輸出上進(jìn)行。后處理流程里加一個開關(guān)有語義評估需求的場景跳過歸一化直接消費(fèi)原始文本。6. 最后分享一個調(diào)試技巧用差分腳本快速定位是哪層引入的不確定性如果線上又出現(xiàn)結(jié)果漂移別急著改規(guī)則。先跑差分腳本把同一個prompt分別經(jīng)過“引擎直出”、“harness后處理”、“harness引擎整體鏈路”三個路徑對比三個路徑的輸出差異。哪一步開始產(chǎn)生不一致哪一步就是問題層。我把這個腳本寫成了一個簡易工具python diff_probe.py \ --prompt 某條線上真實問題 \ --engine-output /tmp/engine.txt \ --harness-output /tmp/harness.txt \ --log-level debug腳本會在harness層每個子規(guī)則前后打印文本快照和文本hash讓我瞬間定位到是哪條歸一化規(guī)則把文本改了還是引擎本身就飄了。這個方法救了我很多次強(qiáng)烈建議有同樣困擾的團(tuán)隊都搭一個。踩過幾次坑之后我現(xiàn)在對“穩(wěn)定輸出”的理解已經(jīng)變了——不是要求模型每次都一模一樣而是讓所有不該變化的層面都穩(wěn)定下來把該保留的隨機(jī)性留給模型自己。harness層后處理就是這最后一道閘門兜住工程差異把真實的不確定性還給大家。