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