1. 可復現(xiàn)性到底是什么從“能跑”到“能復現(xiàn)”前陣子幫一個同學復現(xiàn)一篇圖像分類論文的結果代碼直接從對方倉庫里 clone數(shù)據(jù)用的也是同一個公開數(shù)據(jù)集理論上應該是“跑一遍就出結果”的事。結果我連續(xù)折騰了兩天訓練曲線怎么都對不上最終指標比論文里寫明的數(shù)字低了約 1.2 個百分點。后來定位到原因居然藏在三個不起眼的角落里PyTorch 版本不一致、DataLoader 的隨機順序沒固定、數(shù)據(jù)增強里隨機裁剪的參數(shù)范圍有出入。這就是“AI 可復現(xiàn)性”最常見的打開方式——它往往不是那種高深到需要重新設計框架的問題而是一堆看似“跑通就行”的具體細節(jié)在背后悄悄累積。干了幾年 AI 工程我對“復現(xiàn)”這件事一直保持敬畏。這篇文章想把我復現(xiàn)別人、以及被團隊同事復現(xiàn)的過程中踩過的坑、總結出的方法完整講一遍。內(nèi)容既適合還在跑實驗寫論文的學生也適合要在團隊里維護一份“別人能跑起來”代碼庫的算法研發(fā)更歡迎被各種沒頭沒尾的 README 折磨過的朋友來評論區(qū)一起吐槽。1.1 可復現(xiàn)性的三個層次很多人一提“可復現(xiàn)”第一反應是“代碼能跑就行”。這其實是把概念理解得太窄了。我習慣把可復現(xiàn)性拆成三層一層比一層嚴格第一層是“代碼可運行”。把倉庫拉下來裝好依賴能跑出 loss 曲線不報錯。這一層只證明代碼本身是完整的跟結果對不對完全沒關系。第二層是“環(huán)境可重建”。換一臺機器、換一個人、隔三個月后再跑依然能裝好同樣的環(huán)境跑出同樣的數(shù)值范圍。這層需要依賴鎖定、版本管理、硬件記錄。很多論文給的代碼卡在這一層就過不去。第三層是“結果可對齊”。同一份代碼、同一個環(huán)境、同一份數(shù)據(jù)跑出來的核心指標差異控制在一個合理范圍內(nèi)比如精度差不超過 0.1 到 0.2 個百分點loss 曲線形態(tài)基本一致。這是工業(yè)級復現(xiàn)的要求也是論文審稿人真正想看到的“復現(xiàn)”。三層之間的差距就是不同團隊對實驗嚴謹性的要求差距。一個只在單機單卡上跑過、要求不高的項目能做到第一層就夠用但要支撐團隊協(xié)作、模型迭代、甚至對外發(fā)布基準結果至少要做到第二層并向第三層努力。1.2 “復現(xiàn)不出來”不等于“論文有問題”這是我最想先糾正的一個心態(tài)。復現(xiàn)結果對不上時很多人第一反應是“作者是不是造假了”但實際經(jīng)驗里絕大多數(shù)情況不是這樣。我見過太多次人家論文沒問題只是某些細節(jié)沒寫清楚或者說寫清楚了但被忽略了。比如論文只說“使用 SGD 優(yōu)化器初始學習率 0.01”但沒告訴你學習率在第幾個 epoch 衰減、用什么衰減策略論文說“用了數(shù)據(jù)增強”但沒說隨機裁剪的 scale 范圍是多少論文說“batch size 為 128”但沒提梯度積累步數(shù)——這些信息在原文里可能只是一句話甚至一個小括號但任何一個變了最終指標都會飄。所以“復現(xiàn)不上”更像一個排查信號說明還有某個關鍵變量沒對齊。把它當成論文造假只會讓你錯過真正的 bug。冷靜下來按環(huán)境、數(shù)據(jù)、代碼、超參四個維度去逐個排查通常都能找到答案。1.3 為什么 AI 在“復現(xiàn)”這件事上特別容易翻車傳統(tǒng)軟件工程里可復現(xiàn)性不是一個這么扎眼的話題。一段 C 排序代碼你在一臺機器上測出 100 萬條數(shù)據(jù)排 0.2 秒換一臺配置高點的機器雖然時間變了但排序結果應該完全一致。這是因為傳統(tǒng)程序往往是確定性的同一個輸入對應的就是同一個輸出。但 AI 訓練過程天然帶著隨機性。模型初始化是隨機的數(shù)據(jù)加載的 shuffle 順序是隨機的Dropout 是隨機的多卡并行時梯度歸約的順序也會帶來浮點誤差。再加上訓練本身就是一次次迭代優(yōu)化的過程一步順序不同后面的整個軌跡都可能不同。所以 AI 項目的復現(xiàn)本質(zhì)上是在“一條充滿隨機變量的時間線上”復現(xiàn)某一次軌跡難度自然比傳統(tǒng)程序高一個量級。這也解釋了為什么明明把 seed 固定了結果有時候還是不一樣。因為隨機性的來源遠不止一個np.random.seed()能管住的后面還能看到更多案例。2. 藏在訓練細節(jié)里的“復現(xiàn)殺手”聊完定義進入正題到底哪些東西在悄悄破壞可復現(xiàn)性我把幾年里踩過的坑歸成四類每一類都值得單獨拉出來講。2.1 隨機性從種子到并行先做個熱身題固定了random.seed(42)、np.random.seed(42)、torch.manual_seed(42)訓練結果就一定完全一樣嗎答案是不一定。第一個問題是隨機性來源太多。Python 自帶的 random、NumPy 的隨機、PyTorch 的 CPU/GPU 隨機、操作系統(tǒng)的隨機種子、還有給 DataLoader 單獨設置的 generator它們彼此獨立必須全部固定。任何一處漏掉后續(xù)的數(shù)據(jù)順序就可能不同。第二個問題是硬件層面的不確定。GPU 上很多操作是并行計算的比如矩陣乘法里多個計算單元各自算一部分再按某種順序加總。浮點數(shù)的加法不滿足結合律元素加總順序不同最后一位小數(shù)就會不同。這種誤差會隨著訓練步數(shù)放大導致曲線細微偏離。PyTorch 里torch.backends.cudnn.deterministic True能解決一部分算子的問題但不是所有算子都支持確定性版本有些情況下只能接受“近似可復現(xiàn)”。第三個問題是數(shù)據(jù)加載順序。很多代碼里 DataLoader 的 shuffle 用的隨機序列是在沒有設置固定 generator 的情況下隱式產(chǎn)生的。同樣的 seed如果把num_workers從 4 改成 8數(shù)據(jù)到達 GPU 的順序都可能變化訓練效果就跟著變。這算是復現(xiàn)排查里最容易忽略的環(huán)節(jié)。2.2 環(huán)境漂移同一個代碼換了石頭就跑偏我見過一個特別折磨人的場景同事在我的機器上復現(xiàn)一個模型代碼完全一樣數(shù)據(jù)完全一樣甚至 seed 都一樣但 loss 曲線就是差了一點。折騰了半天最后發(fā)現(xiàn)他的 PyTorch 版本比我的新了兩個大版本某些底層算子的實現(xiàn)邏輯已經(jīng)重構過了。AI 項目對底層庫的敏感程度遠超普通應用。CUDA 驅(qū)動、cuDNN 版本、PyTorch 版本、甚至 NumPy 版本一變浮點計算的順序和精度就可能跟著變。很多開源項目寫requirements.txt時習慣用torch1.9.0這種寫法看起來沒問題實際上一臺機器解析出來的依賴樹跟另一臺機器能差出一大截。環(huán)境漂移的隱蔽性在于它不像代碼報錯那樣直接可見。代碼照樣能跑指標偶爾也沒差多少但它足以讓“結果對齊”變得不穩(wěn)定。等到你要復現(xiàn)一個月前自己跑的實驗時環(huán)境已經(jīng)悄悄更新過好幾輪當時的曲線怎么都找不回來。2.3 論文沒寫的“隱形超參”這是復現(xiàn)論文時最讓人頭疼的部分。公開代碼里往往只能看到模型結構和訓練腳本而真正影響結果的細節(jié)常常散落在論文的實驗部分、插圖標題、甚至附錄的腳注里。我總結過幾類最容易被忽略的“隱形超參”學習率調(diào)度策略。論文說“初始學習率 0.01”但實際是每 30 個 epoch 乘以 0.1還是余弦退火還是帶 warmup 的三階段策略這三者的收斂結果差異可能接近一個百分點。數(shù)據(jù)增強參數(shù)。同一個“隨機裁剪”scale 范圍到底是(0.08, 1.0)還是(0.5, 1.0)有沒有用RandomResizedCrop的默認值這些默認值在不同版本框架里還可能被改動。Batch Size 與梯度更新頻率。有的論文寫 batch size 512實際因為顯存限制用了 128 加 4 步梯度積累但這跟真正的 512 批次在 BatchNorm 統(tǒng)計上是有差異的。EMA指數(shù)移動平均權重。很多自監(jiān)督和半監(jiān)督模型依賴 EMA 來平滑模型參數(shù)但 EMA 的衰減系數(shù)往往只寫在附錄里甚至只藏在代碼的默認參數(shù)里。混合精度開關。混精度訓練會把前向和反向計算的精度降低到 FP16同時保留 FP32 的主權重。這個開關是否開啟、動態(tài) loss scaling 的策略是什么都會影響數(shù)值軌跡。這些參數(shù)在論文里不顯眼但對結果的影響卻是實打?qū)嵉?。復現(xiàn)時看到差異往這些方向排查的命中率很高。2.4 數(shù)據(jù)與預處理也是“代碼的一部分”我見過最“冤”的復現(xiàn)失敗是這樣一個人下載了訓練集另一個人下載了訓練集目錄結構一樣文件也一樣但下載工具的校驗邏輯不同圖片文件順序不同導致訓練時數(shù)據(jù)讀取順序完全不同。另外數(shù)據(jù)預處理腳本也是復現(xiàn)鏈路的一部分。歸一化的均值/方差是(0.485, 0.456, 0.406)還是(0.5, 0.5, 0.5)圖像 resize 的方式是雙線性還是雙三次這些細節(jié)寫在腳本里但腳本本身如果不放在版本控制里很容易在某次“順手改一下”之后徹底失憶再也找不回原始處理流程。把數(shù)據(jù)和預處理腳本納入版本管理跟鎖代碼同等重要。這一點在下一章會展開講。3. 一套可落地的可復現(xiàn)方案鎖環(huán)境、鎖代碼、鎖數(shù)據(jù)復現(xiàn)問題討論再多最終還是要落到行動上。下面這套方法是這幾年實際驗證過的每一步都不難難的是把它變成習慣。核心思路可以用一句話概括把影響實驗結果的每一個變量都記錄下來并且鎖死。3.1 環(huán)境鎖定requirements 只是起點哈希鎖零很多項目會提供一個requirements.txt但這里有個常見誤區(qū)這個文件往往只寫了頂層依賴沒有鎖定傳遞依賴的版本。也就是說你在pip install -r requirements.txt的時候依賴解析器會在你當前的機器上下載“當時最新”的某個子依賴版本而這個版本可能跟上個星期已經(jīng)不一樣了。我更推薦的做法是在干凈的環(huán)境中做完所有代碼調(diào)試后用pip freeze生成一份完整的鎖定文件。# 在訓練用的虛擬環(huán)境里執(zhí)行 python -m pip freeze requirements-lock.txt這份文件會把當前環(huán)境下所有通過 pip 安裝的包以及精確版本全部記錄下來?；謴铜h(huán)境時直接python -m pip install -r requirements-lock.txt這樣雖然不完美Python 生態(tài)里還有系統(tǒng)級依賴、編譯器版本、OpenBLAS 等細節(jié)沒法被 pip 管住但已經(jīng)能解決 80% 的版本漂移問題。更進一步可以把 lock 文件內(nèi)容生成一個哈希值跟實驗結果一并記錄下來。sha256sum requirements-lock.txt記錄這個哈希值之后任何時候想確認“當前環(huán)境跟當時是否一致”一條命令就能驗證。每次環(huán)境改動都要重新生成 lock 文件并且同步更新哈希記錄。3.2 種子管理一套“不打架”的種子方案種子管理看似簡單但要做好需要把每個隨機源都照顧到。我平時用的工具函數(shù)長這樣import os import random import numpy as np import torch def set_global_seed(seed: int 42): # 注意這個 os.environ 設置必須在導入 numpy/torch 之前才完全生效 # 所以最好在腳本最開頭調(diào)用或者單獨放在一個模塊里最先導入。 os.environ[PYTHONHASHSEED] str(seed) random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) # 讓 cuDNN 使用確定性算法并關閉 benchmark 自動調(diào)優(yōu) torch.backends.cudnn.deterministic True torch.backends.cudnn.benchmark False有兩個細節(jié)值得提醒。第一PYTHONHASHSEED只影響 Python 字符串哈希的隨機化。如果你在代碼里用字典或者集合時依賴鍵的順序就要設這個變量而且必須在 Python 解釋器啟動時生效。所以在import之前就設置os.environ是必要的靠函數(shù)內(nèi)部臨時設置已經(jīng)來不及了。第二torch.backends.cudnn.benchmark False很多人會忽略。benchmark 開啟時cuDNN 會在一些算法之間做自動調(diào)優(yōu)第一次跑的時候選擇的算法可能跟第二次不同導致不確定的結果。把它關掉才能讓卷積計算路徑相對固定。僅僅調(diào)用這個函數(shù)還不夠還必須確認 DataLoader 的 shuffle 也使用固定 generator。做法是在創(chuàng)建 DataLoader 時傳入一個獨立的 Generatorfrom torch.utils.data import DataLoader import torch g torch.Generator() g.manual_seed(42) loader DataLoader( dataset, batch_size128, shuffleTrue, generatorg, num_workers4, )注意num_workers的變化會影響數(shù)據(jù)到達順序所以鎖定時要連這個參數(shù)一起固定。多卡訓練時DistributedSampler也要設置set_epoch(seed)否則每個 epoch 的 shuffle 順序會隨系統(tǒng)時鐘變化。3.3 數(shù)據(jù)與預處理不可變固定好環(huán)境和隨機狀態(tài)之后下一步是確保數(shù)據(jù)本身不可變。我給自己定的規(guī)矩是原始數(shù)據(jù)集一旦下載完畢就把它放到只讀位置并記錄一個 SHA-256 校驗值。每次訓練腳本啟動時先驗證數(shù)據(jù)目錄的哈希不一致就直接報錯退出。# 計算訓練數(shù)據(jù)目錄的校驗值 find /path/to/train_data -type f -exec sha256sum {} \; | sort | sha256sum這行命令會把目錄下所有文件的哈希算出來再合并最終得到一個“目錄指紋”。雖然速度不快但在每次啟動訓練前做一次驗證能徹底杜絕“數(shù)據(jù)被人不小心改了一個文件”這類事故。預處理腳本同樣要納入版本控制。我的習慣是把從“原始圖片”到“訓練輸入 tensor”的全部變換封裝成一個獨立的 Python 模塊并把該模塊的 commit hash 寫進訓練日志。這樣任何時候回看一次訓練都能清楚知道這條數(shù)據(jù)流水線當時的狀態(tài)。3.4 用實驗管理工具記錄“誰在什么上跑過”人腦的記憶是不可靠的。三個月前你調(diào)了一個實驗當時覺得肯定是記錄下來了但真的被人問起“你這個模型的超參是什么”時很難從命令行歷史里準確還原。實驗管理工具能把這個問題系統(tǒng)性解決。這類工具會自動記錄每個實驗的代碼版本、依賴環(huán)境、超參數(shù)、指標曲線、模型權重和日志文件。我在團隊里推動過幾個項目使用開源實驗管理工具核心收益是兩個一是自動記錄。不需要手動維護一個 Markdown 表格每個人跑訓練時工具自動把環(huán)境信息和參數(shù)抓走形成一條可檢索的實驗記錄。二是方便對比。當你連續(xù)跑了十幾個實驗工具會自動把每條曲線放在一起展示指標優(yōu)劣一目了然。比自己在 Excel 里復制粘貼要靠譜得多。即使不想引入新工具至少也得建立一個“每個實驗一條記錄”的習慣內(nèi)容包含git commit hash、seed、超參配置、環(huán)境 lock 文件哈希、GPU 型號、啟動時間、結束時間、關鍵指標。這份記錄就是以后你的“數(shù)字考古系統(tǒng)”。3.5 容器把整臺機器變成一枚“郵票”環(huán)境鎖定的終極形態(tài)是容器化。把 CUDA 驅(qū)動的內(nèi)核模塊暴露給宿主機之外的所有依賴都封進鏡像等于把“操作系統(tǒng)級別的環(huán)境”也固定下來。任何人拿到這個鏡像在同類 GPU 環(huán)境下運行得到的環(huán)境就是同一套。容器的好處眾所周知可控的限制也同樣重要容器不解決硬件差異問題。同一個鏡像在 A100 和 RTX 3090 上跑由于 GPU 架構不同、并行調(diào)度策略不同結果依然可能出現(xiàn)微小偏差。所以容器里還要額外記錄 GPU 型號和驅(qū)動版本。訓練開始時把以下信息寫進日志文件成本很低但價值很高nvidia-smi --query-gpuname,driver_version,memory.total --formatcsv容器不是銀彈但配合前面幾層措施已經(jīng)足以把可復現(xiàn)性從“概率性事件”變成“常規(guī)現(xiàn)象”。4. 實操復盤一個圖像分類模型從“對不上”到“完全鎖定”方法論講完拿一個真實踩過的坑做完整復盤。為了讓描述更通用我隱去具體數(shù)據(jù)和模型名稱但整個排查過程完全按實際經(jīng)歷來寫。4.1 復現(xiàn)目標與最初的現(xiàn)象當時要在某復現(xiàn)項目中跑一個公開骨干網(wǎng)絡結構的圖像分類實驗。論文給出的 Top-1 精度是 77.5%我用對方公開的代碼和數(shù)據(jù)集第一次跑出來只有 76.3%差了 1.2 個百分點。這個差距不算特別大但足夠讓所有后續(xù)實驗失去可信度。我做的第一件事不是調(diào)參而是先檢查硬環(huán)境。記錄下 PyTorch 版本、CUDA 版本、GPU 型號、Python 版本然后看對方倉庫里有沒有環(huán)境鎖定文件。結果發(fā)現(xiàn)對方只提供了一個很粗的requirements.txt沒有哈希鎖定也沒有容器鏡像。這意味著環(huán)境變量完全處于“漂移”狀態(tài)。4.2 第一輪排查鎖定環(huán)境版本我建了一個全新的虛擬環(huán)境按對方的requirements.txt安裝依賴但把關鍵的 PyTorch 和 torchvision 版本按照倉庫歷史記錄里的版本號重新指定降級到當時實驗所用的版本。裝好后重跑訓練精度從 76.3% 提到了 76.7%曲線形態(tài)也比之前平滑了一些。很明顯算子的底層實現(xiàn)差異確實是影響因素之一但它只解釋了一部分差距。4.3 第二輪排查鎖定隨機狀態(tài)環(huán)境對齊之后我把目光轉(zhuǎn)到隨機性。仔細檢查訓練腳本發(fā)現(xiàn)它只調(diào)用了一次torch.manual_seed(42)但有兩處遺漏一是 DataLoader 沒有單獨設置 generatorshuffle 順序其實沒被固定二是torch.backends.cudnn.benchmark保持默認開啟狀態(tài)同樣的輸入在不同時間甚至可能選到不同卷積算法。我把這兩個問題修掉重新跑了三個不同隨機種子下的實驗發(fā)現(xiàn)精度穩(wěn)定到了 76.9%比最初的 76.3% 提高了 0.6 個百分點。到這里環(huán)境 隨機這兩個因素已經(jīng)修正了大約 0.6 個百分點的差異。4.4 第三輪排查數(shù)據(jù)順序與預處理細節(jié)還差最后的 0.6 個百分點。我先把目標縮小到預處理流程逐行對比數(shù)據(jù)集加載代碼和論文描述終于發(fā)現(xiàn)兩個問題。第一個是隨機裁剪范圍。我復現(xiàn)代碼里寫的RandomResizedCrop的 scale 參數(shù)是默認值(0.08, 1.0)但原作者的實現(xiàn)里實際用的是(0.5, 1.0)。這個差異導致訓練時模型看到的圖片裁剪區(qū)域普遍偏大特征分布跟論文設定有偏差。第二個是歸一化參數(shù)。我用了通用的 ImageNet 統(tǒng)計量(0.485, 0.456, 0.406)但原作者在代碼里把歸一化參數(shù)改成了(0.5, 0.5, 0.5)。這個改動在數(shù)據(jù)預處理里不起眼但對最終精度的影響實實在在。修掉這兩處之后重新訓練精度直接跳到了 77.3%加上前面已經(jīng)修正的環(huán)境和隨機項最終達到了 77.4%與論文的 77.5% 只差 0.1 個百分點。這個差距在合理浮動范圍內(nèi)。4.5 最終方案五個鎖一起上性能對齊之后我開始把整個復現(xiàn)過程固化下來目的就是讓這個結果以后隨時能被重新找回。最終的做法是五個鎖同時生效第一鎖定代碼版本。把復現(xiàn)倉庫打上 commit hash所有關鍵腳本凍結。第二鎖定環(huán)境。用pip freeze導出完整 locked requirements并記錄哈希值。第三鎖定隨機狀態(tài)。統(tǒng)一 seed 函數(shù) DataLoader generator cudnn deterministic benchmark off。第四鎖定數(shù)據(jù)。計算訓練目錄的 SHA-256 指紋訓練腳本啟動時自動校驗。第五鎖定硬件信息。記錄 GPU 型號、驅(qū)動版本、CUDA 版本并寫進訓練日志。后來我把這套流程總結成團隊內(nèi)部的一份 Runbook之后每次復現(xiàn)別人的模型或重新拉起自己的實驗都按這個清單走一遍成功率明顯提升。5. 常見問題速查手冊與幾個“反直覺”經(jīng)驗5.1 十類常見復現(xiàn)問題速查表現(xiàn)象排查方向處理建議結果與論文有可觀察差距環(huán)境版本不一致 / 隨機種子沒鎖鎖定依賴 統(tǒng)一 seed 對比版本同一個代碼兩次結果就不同DataLoader 無固定 generator / benchmark 開啟固定 DataLoader generator、關閉 benchmark換一臺機器指標變化GPU 型號 / 驅(qū)動版本 / 庫實現(xiàn)差異容器化 記錄 nvidia-smi 信息固定 seed 后仍有細微波動并行浮點累加順序 / 非確定性算子開啟 cudnn deterministic接受微小浮動訓練后精度接近但曲線對不上學習率調(diào)度策略不一致核對 warmup、decay、scheduler 細節(jié)圖片數(shù)據(jù)能跑但結果偏預處理參數(shù)不一致檢查 resize、歸一化、裁剪范圍依賴裝完跑不起來lock 文件缺失 / 傳遞依賴漂移用 pip freeze 生成完整鎖定文件找不到某次實驗的記錄實驗日志不系統(tǒng)引入實驗管理工具或建立固定記錄模板目錄數(shù)據(jù)被改動影響結果數(shù)據(jù)盤可寫設置只讀 啟動時校驗目錄指紋多卡訓練結果不穩(wěn)定分布式采樣隨機 / 歸約順序固定 DistributedSampler epoch、統(tǒng)一進程數(shù)5.2 我跑實驗時定的幾條硬規(guī)矩這些規(guī)矩不一定適合所有人但每一招都是從真實教訓里換來的。第一git commit 必須走在訓練啟動之前。哪怕只改了一行配置也要先提交再跑實驗。不然過了幾天自己都分不清某個結果是對應哪份代碼。第二所有依賴鎖定文件都提交到版本控制里。requirements-lock.txt、環(huán)境描述文件、容器構建腳本必須和訓練代碼放在同一個倉庫。禁止把環(huán)境配置單獨放在某個不靠譜的個人筆記里。第三每個新實驗先跑一個小規(guī)模冒煙測試。用 100 個樣本、2 個 epoch、一個 batch驗證代碼能跑通、日志能落地、隨機狀態(tài)生效再開正式實驗。這個習慣能省掉大量“跑了一天發(fā)現(xiàn)腳本早該報錯”的悲劇。第四實驗報告的“復現(xiàn)信息”一欄永遠留出來。記錄 git hash、seed、環(huán)境哈希、數(shù)據(jù)指紋、GPU 型號五個字段缺任何一個都要在報告里說明原因。5.3 警惕“偽可復現(xiàn)”比不復現(xiàn)更麻煩接觸過不少項目表面上看已經(jīng)做了可復現(xiàn)工作但深入一查全是漏洞比完全不做還麻煩。舉幾個常見的“偽可復現(xiàn)”例子。只鎖了直接依賴沒鎖傳遞依賴。requirements.txt里有torch1.12.0但 torch 自身的依賴沒鎖過一段時間numpy或pillow可能已經(jīng)被更新到一個奇怪版本訓練時某些算子自動走新路徑結果就變了。固定了 seed但沒有固定數(shù)據(jù)的讀取順序。同一臺機器上文件系統(tǒng)遍歷順序可能因為目錄內(nèi)容變化而改變用 glob 匹配文件時不同平臺的排序規(guī)則也不同。seed 只影響混排算法混排的輸入序列如果是亂的輸出自然也是亂的。容器鏡像打了 tag但沒有記錄 digest。很多人以為“鏡像 tag 不變就萬事大吉”但 tag 可能被覆蓋鏡像內(nèi)容已經(jīng)悄悄換了?？煽康挠涗浄绞绞怯涗涚R像的 digestsha256而不是只寫一個v1.0這種符號名。少做一個環(huán)節(jié)的后果是出了問題反而更難排查因為你以為已經(jīng)全都鎖死了潛意識里不會再去懷疑環(huán)境層面。所以我一直強調(diào)可復現(xiàn)是一個“全鏈路”的概念任何一環(huán)的缺失都會讓整個鏈條的可靠性歸零。我把可復現(xiàn)性當成一種“實驗衛(wèi)生”而不是“額外負擔”。它不產(chǎn)出新的模型效果不提升 accuracy但它確保你的每一次努力都能被追溯、被信任、被延續(xù)。我個人的體會有兩點第一別追求一次做到完美可以先從“每次訓練前打一個 commit”這種小動作開始慢慢把整個流程補齊第二把可復現(xiàn)當成團隊協(xié)作的接口協(xié)議而不是某個人的個人習慣大家一起遵守才能讓知識在所有實驗之間流動起來。最后送你一個小技巧給自己維護的所有訓練倉庫統(tǒng)一放一個REPRODUCE.md文件把環(huán)境、數(shù)據(jù)、隨機、硬件四類信息怎么記錄寫清楚。下次無論誰來跑這份代碼都不會再來敲你的門問“這個參數(shù)到底是多少”。