第一次看到 TAP 這篇論文時，我最先確認的不是它修復後的圖片有多漂亮，而是兩件事：所謂的 Prompt 到底是不是文字，以及它宣稱的「輕量化」究竟省了什麼。
答案是，TAP 的 Prompt 不是使用者輸入「請幫我把雨去掉」這種自然語言指令，而是一組由模型訓練出來的內部向量。每一種影像修復任務都有自己的 Prompt，負責告訴共享模型目前應該專注處理雨、雪、霧還是鏡頭上的雨滴。
至於輕量化，TAP 確實把整體參數量控制在約 275 萬，明顯低於不少數千萬甚至接近上億參數的比較模型。不過，參數量小不等於處理高解析度圖片時一定很快。記憶體占用、注意力運算、圖片切塊和硬體支援，仍然會影響實際延遲。
這種「論文數字很好看，但正式部署還要繼續問問題」的情況，我已經很熟悉了。就像一個功能在開發者電腦上只跑三秒，不代表放到手機、邊緣設備或塞滿其他服務的正式環境後，還會是同一個數字。
TAP 的完整名稱是 Parameter-efficient Task-Aware Prompting for Adverse Weather Removal，由浙江大學研究團隊提出，並收錄於 2025 年 ACM Multimedia Conference。它的目標不是打造一個萬能修圖 AI，而是讓同一套模型以較低的額外參數，處理四種惡劣天候影像修復工作：去雨、去雪、去霧與雨滴移除。ACM MM 2025 論文資料
多任務影像修復為什麼需要 TAP？
影像修復的問題看起來很接近，實際上不同退化現象需要的處理邏輯並不相同。
雨絲通常是細長、半透明而且具有方向性的紋理；雪花可能形成大小不一的白色遮擋；霧會降低整張圖片的對比與色彩；黏在鏡頭上的雨滴則會造成局部扭曲、模糊與遮蔽。
傳統做法是每個任務訓練一個模型：
- 去雨使用一個模型。
- 去雪使用另一個模型。
- 去霧再使用第三個模型。
- 移除鏡頭雨滴又是第四個模型。
這樣做的好處是每個模型只需要專心解決自己的問題，缺點則是模型數量、儲存空間、部署流程和版本管理都會跟著增加。
如果每個模型還有不同的輸入尺寸、前處理和 GPU 記憶體需求，後端服務很快就會變成一排互相不認識的 API。半年後有人問「這張圖片為什麼走舊版去霧模型」，通常得先翻部署紀錄，再祈禱當初寫文件的人還沒離職。
因此，All-in-One Image Restoration，也就是全合一影像修復，開始嘗試用一個模型處理多種退化問題。相關研究整理顯示，目前主流方向包含視覺 Prompt、文字 Prompt、多模態模型及專家混合架構。全合一影像修復研究綜述
但共享模型也會產生新的問題：不同任務不只互相幫助，也可能互相干擾。
多任務學習真正困難的地方是任務衝突
去雨和去霧都叫影像修復，但模型在兩個任務中需要關注的資訊不同。
去雨希望刪除局部線狀紋理，同時保留後方物體細節；去霧則更關心全域對比、光線傳播和顏色恢復。若直接把兩種資料混在一起訓練，某一次更新對去雨有利，下一次更新卻可能破壞去霧能力。
這就是多任務學習中的任務衝突。
最直覺的解法，是替每個任務增加獨立分支或專家模型。但這樣一來，模型參數又會膨脹，逐漸回到「四個任務養四套模型」的老路。
TAP 採取的折衷方式是：
- 大部分影像修復能力由同一個骨幹模型共享。
- 每個任務只保留一小組專屬 Prompt。
- Prompt 直接影響模型內部的注意力。
- 先訓練共通知識，再分開調整各任務 Prompt。
你可以把共享骨幹想成一名懂得基本修圖的工程師，而任務 Prompt 則像針對不同工作的短操作手冊。切換任務時，不需要換掉整名工程師，只要換一份很小的指引。
TAP 架構的五個核心部分
一、以 SwinIR 為基礎的共享修復骨幹
TAP 的骨幹建立在 SwinIR 之上。SwinIR 是一種使用視窗式 Transformer 的影像修復架構，曾被應用於超解析、降噪和 JPEG 壓縮瑕疵修復。
TAP 並沒有完整照搬原始 SwinIR，而是改造成五階段的 U-Net 結構。圖片先逐步壓縮並提取特徵，再逐層恢復解析度，讓模型同時處理局部天候痕跡和整體畫面資訊。
研究團隊也移除了解碼器中的部分注意力層，並調整特徵融合和正規化方式，以降低參數與運算成本。TAP 完整架構與實驗
這裡有一個容易誤會的地方：TAP 不是四個完整模型塞進同一個檔案，而是一套共享的修復骨幹，搭配少量任務專屬參數。
這確實能降低模型儲存與維護成本。
二、Soft Prompt 不是人類閱讀的文字
看到 Prompt 這個詞，很容易聯想到 ChatGPT 的文字提示。但 TAP 使用的是 Soft Prompt，也就是模型自己學習的向量。
這些 Prompt 不需要能被人類讀懂，也不會直接寫著「去除雪花」或「提高霧中對比」。它們的功能是在特徵空間裡調整模型注意力，讓相同骨幹針對不同退化現象採取不同處理方式。
例如：
- 去雨 Prompt 可能讓模型更注意細長、重複的局部紋理。
- 去霧 Prompt 可能加強對全域亮度與對比變化的處理。
- 去雪 Prompt 可能關注散布在前景的白色遮擋。
- 雨滴 Prompt 可能集中處理局部模糊與折射區域。
這些都是對模型行為的概念性解釋，不代表 Prompt 裡真的存放一組可讀規則。
三、Prompt 直接介入注意力運算
部分 Prompt 方法會把提示向量加到輸入特徵前面，再送入 Transformer。但這可能改變特徵序列長度，最後還得把額外輸出切掉。
TAP 採用的是注意力層級 Prompt。Prompt 不直接變成圖片中的新區塊，而是介入注意力機制內部，影響模型應該關注哪些特徵，以及如何重新組合資訊。
這樣做有兩個目的：
- 不改變原始輸出的長度。
- 讓 Prompt 能更直接調整注意力結果。
論文的消融實驗顯示，注意力層級 Prompt 的平均修復表現優於較傳統的完整提示注入方式。研究團隊認為，原因可能是傳統方法最後需要刪除額外輸出，導致部分資訊流失。
從工程角度來看，這類設計也比外接一個大型文字編碼器實際。它不需要 BERT、CLIP 或其他視覺語言模型，自然也少了跨模態對齊和額外推論成本。
四、低秩分解拆出共享與專屬資訊
每一種天候都有自己的特徵，但它們並非完全無關。
雨、雪和雨滴都可能遮擋局部內容；雨與霧則可能同時造成透明度與對比下降。如果完全隔離每個任務，模型會浪費這些可以共用的知識。
TAP 因此把 Prompt 拆成兩部分：
- 所有任務共同使用的部分。
- 各任務自行保留的專屬部分。
這種低秩設計可以減少需要儲存和訓練的參數，也能限制 Prompt 不要過度記住特定資料集。
如果用軟體架構來比喻，它有點像把所有天候任務共用的邏輯放進核心套件，再讓每個任務只實作自己的差異。這通常比複製四份程式碼再各自修改好維護，但前提是共用介面真的設計得合理。
五、用對比學習描述任務關係
只把 Prompt 分成共用與專屬部分，仍不足以說明不同任務之間有多相似。
研究團隊先分析退化圖片與乾淨圖片之間的殘差特徵，觀察到雪與雨滴的分布較接近，雨與霧也呈現一定程度的相似性。
TAP 接著使用對比學習調整 Prompt：
- 關係較接近的任務，Prompt 表示可以保留較多共同結構。
- 差異較大的任務，專屬 Prompt 則應該更容易被區分。
這比單純要求所有任務彼此分開更合理。多任務系統不是公司組織圖，不需要每個部門都假裝完全沒有關係。
不過，論文中的任務關係主要來自特徵分布和視覺化分析。這能提供佐證，卻不能單靠一張 t-SNE 圖就證明所有任務之間的真實因果關係。
為什麼 TAP 採用兩階段訓練？
TAP 沒有從第一天開始就把骨幹和所有 Prompt 一起訓練，而是拆成兩個階段。
第一階段：學習通用修復能力
研究團隊先混合四種天候資料，訓練共享骨幹。每個訓練批次包含相同數量的去雨、去雪、去霧及雨滴資料，避免某個資料量較大的任務主導整個模型。
這個階段的目標，是先讓模型具備基本的影像內容理解與粗略修復能力。
第二階段：凍結骨幹，只訓練 Prompt
通用模型完成後，骨幹參數會被凍結。接下來只更新各任務的 Soft Prompt，以及描述任務關係的少量參數。
這樣做可以降低不同任務持續拉扯骨幹參數的問題，也讓新增或調整某個任務時，不必重新修改整個模型。
論文的消融實驗顯示，分開訓練骨幹與 Prompt，平均表現優於兩者同時最佳化。完整的任務感知 Prompt 也比未加入 Prompt 的基礎模型取得更高的平均 PSNR。TAP 訓練策略與消融實驗
工程上我也偏好這種流程。把穩定的核心模型鎖住，再更新小型任務元件，通常比較容易回滾、測試和追蹤版本。
至少不會修了去雪，隔天才發現去霧一起壞掉。
TAP 的輕量化表現如何？
論文測試了四項影像修復任務：
- OutdoorRain：去除雨和雨霧影響。
- Snow100K-L：去除雪花遮擋。
- RESIDE-SOTS：去霧。
- RainDrop：移除附著於鏡頭的雨滴。
TAP 的總參數量約為 275 萬，四項任務的平均 PSNR 為 32.82 dB，平均 SSIM 為 0.9503。
作為比較：
- Histoformer 約有 1,700 萬參數，平均 PSNR 為 32.56 dB。
- LoRA-IR 約有 8,500 萬參數，平均 PSNR 為 32.74 dB。
- PromptIR 約有 3,500 萬參數，平均 PSNR 為 30.11 dB。
- WeatherDiff 約有 8,700 萬參數，其中一組設定的平均 PSNR 為 30.40 dB。
至少從論文採用的四組測試來看，TAP 用明顯較少的參數，取得了相當有競爭力的重建結果。
這也是 TAP 最值得注意的地方：它不是單純把模型縮小，而是透過共享骨幹和少量任務 Prompt，把原本分散在不同任務中的能力重新組織。
參數少，不代表所有成本都比較低
這裡必須踩一下煞車。
TAP 論文清楚比較了參數量和修復品質，但沒有提供足夠完整的跨硬體延遲、峰值記憶體、耗電與高解析度吞吐測試。
而它的骨幹仍然包含 Transformer 注意力運算。處理 256 像素測試圖片和處理手機拍攝的 4K 照片，完全是兩回事。
正式導入前，我會另外測量：
- 720p、1080p 與 4K 圖片的實際延遲。
- GPU、CPU、Apple Neural Engine 和手機 NPU 的速度差異。
- 峰值記憶體，而不只是模型檔案大小。
- 圖片切塊後是否產生接縫。
- 半精度與整數量化造成的品質損失。
- 批次處理多張圖片時的吞吐量。
- 模型轉換到 ONNX、TensorRT 或 Core ML 是否遇到不支援的運算。
參數量比較像軟體安裝包大小，不能直接等同於執行速度。真正讓服務帳單上升的，通常是運算和記憶體搬移，不是論文摘要裡那一行參數數字。
TAP 不是完全自動辨識天候的萬能模型
TAP 使用任務專屬 Prompt，代表系統必須知道目前該選擇哪一組 Prompt。
如果輸入資料已經帶有任務標籤，例如相機系統明確知道目前啟用去霧模式，這不是問題。但如果使用者隨手丟進一張圖片，系統還需要判斷它究竟是雨、雪、霧還是鏡頭雨滴。
論文沒有把一個完整的自動退化分類器當成主要貢獻。因此，實際產品可能還要增加：
- 天候或退化類型分類器。
- 根據圖片內容選擇 Prompt 的路由機制。
- 分類信心不足時的保守處理。
- 使用者手動指定修復任務的介面。
- 多個 Prompt 同時混合的策略。
這段是根據 TAP 架構做出的工程推論，而不是論文已經完整解決的功能。
如果前面的分類器選錯 Prompt，模型可能拿去雪邏輯處理霧，結果就像拿除錯工具修 CSS：不是完全沒有作用，但方向已經不對。
混合天候仍是尚未充分驗證的問題
現實世界很少照資料集分類。
下雨時可能同時有霧，鏡頭上可能有水滴，夜間車燈還會產生眩光。雪地圖片也可能同時存在低光、運動模糊和感光噪聲。
TAP 的主要實驗是分別測試四種任務，尚不足以證明它能穩定處理：
- 雨和霧同時出現。
- 雪花搭配鏡頭水滴。
- 夜間低光與惡劣天候重疊。
- 壓縮失真、模糊和天候退化混合。
- 從未參與訓練的新型退化。
更麻煩的是，錯誤修復不一定只是「還留著一點雨」。模型可能抹掉電線、車道線、招牌文字或行人的細小輪廓。
如果輸出只是社群圖片，問題可能是照片不好看；如果後面接的是自駕辨識、監視系統或工業檢測，錯誤移除細節就可能影響決策。
真實場景測試應該怎麼看？
TAP 除了合成資料，也使用 RealRain-1K、RealSnow 和 RTTS 等真實場景資料進行評估。
因為這些真實圖片通常沒有完全對應的乾淨版本，研究使用無參考影像品質指標判斷結果。論文報告指出，TAP 在多項真實資料指標上優於比較方法。TAP 真實資料實驗
這是一項正面結果，但無參考品質分數不能完全取代人工檢查。
一張圖片可能得到不錯的品質分數，卻仍然：
- 把細雨誤認成電線。
- 將雪花附近的臉部細節一起磨掉。
- 過度提高對比，讓天空出現色帶。
- 去霧後產生不自然的飽和度。
- 把鏡頭雨滴後方的內容自行補錯。
如果模型輸出會進入其他電腦視覺系統，我還會直接測試下游任務，例如物件偵測、車牌辨識、道路分割與 OCR，而不是只看修復圖片本身。
圖片看起來更漂亮，不代表機器一定看得更準。
TAP 適合哪些實際應用？
智慧交通與行車影像
TAP 可以讓同一套修復骨幹處理雨、雪、霧和鏡頭水滴，減少車載設備需要保存的模型數量。
但正式使用前必須確認修復過程不會刪除行人、交通標誌、號誌或車道線。
無人機與戶外巡檢
無人機可能在不同天候下拍攝電塔、鐵路、橋梁與太陽能板。使用共享骨幹搭配任務 Prompt，可以降低邊緣裝置的模型儲存負擔。
相較於每遇到一種天候就切換完整模型，小型 Prompt 的版本更新也比較容易管理。
監視器與公共安全設備
戶外攝影機經常遇到霧氣、雨水與鏡頭附著物。TAP 可作為前處理模組，提升後續辨識系統的輸入品質。
不過，監視用途尤其需要保留原始影像，不能只存 AI 修復版本。模型若誤刪細節，原始資料仍是後續調查的重要依據。
手機攝影與影像編輯
使用者可以手動選擇「去雨」、「去霧」或「去除鏡頭水滴」，這種具有明確任務標籤的產品流程很適合 TAP。
因為任務由使用者指定，系統不必額外猜測應選哪個 Prompt。
雲端影像處理 API
共享骨幹可以常駐 GPU 記憶體，不同請求只需要切換小型 Prompt。若服務同時支援多種修復功能，這種架構有機會降低模型載入與版本維護成本。
但真正能省多少，仍需以實際併發、圖片尺寸與硬體測試為準。
如何把 TAP 做成可維護的服務？
如果要建立正式系統，我會把 TAP 拆成四個明確階段。
第一層：輸入檢查
檢查圖片格式、解析度、色彩空間和 EXIF 方向。過大的圖片先安全縮放或分塊，避免單一請求吃光 GPU 記憶體。
第二層：任務路由
任務可以由使用者指定，也可以由分類器判斷。如果分類信心太低，系統應允許不修復、輸出多個候選版本，或回到通用模式。
不要讓一個只有 51%信心的分類器，假裝自己非常確定這是雪。
第三層：共享骨幹與 Prompt
同一份骨幹模型常駐記憶體，根據任務載入對應 Prompt。骨幹與 Prompt 應分開記錄版本，避免新版 Prompt 搭配到不相容的舊骨幹。
第四層：輸出品質檢查
系統可以比較修復前後的結構、亮度與色彩變化。如果差異過大，應標記為高風險輸出，而不是無條件交給下游服務。
同時保存：
- 原始圖片。
- 修復圖片。
- 使用的任務 Prompt。
- 骨幹模型版本。
- 推論參數與處理時間。
- 品質檢查結果。
這些資料平常看起來很像多餘紀錄，出問題時卻會比任何會議都有效。
哪些情況不需要使用 TAP？
TAP 不是所有影像修復問題的答案。
以下情況可能有更簡單的選擇：
- 產品永遠只處理單一退化類型。
- 裝置算力極低，只能使用小型卷積網路。
- 輸入主要是影片，需要利用連續畫面資訊。
- 系統面對大量未知或混合退化。
- 任務需要生成被完全遮擋的內容，而不只是恢復可見資訊。
- 後續辨識模型本身已對天候具有足夠穩健性。
- 一般影像處理方法就能滿足品質需求。
如果產品只有去霧功能，硬是導入多任務 Prompt 架構，不一定比一個成熟的專用模型划算。
微服務如此，AI 架構也是如此：能拆不代表應該拆，能統一也不代表一定要統一。
常見問題
TAP 是什麼？
TAP 是一種參數效率導向的多任務影像修復架構。它使用共享骨幹和任務感知 Soft Prompt，處理去雨、去雪、去霧與雨滴移除。
TAP 的 Prompt 是文字嗎？
不是。TAP 使用的是模型訓練出的向量，不能直接當成人類可閱讀的文字指令。它們會影響 Transformer 內部的注意力運算。
TAP 為什麼比較輕量？
大部分修復能力由同一套骨幹共享，每個任務只需要保存少量 Prompt。論文模型約有 275 萬個參數，低於多個比較模型。
TAP 可以自動判斷雨、雪和霧嗎？
論文重點是使用任務專屬 Prompt 進行修復，而不是完整的自動退化分類系統。若輸入沒有任務標籤，產品通常還需要分類器或 Prompt 路由機制。
TAP 能同時移除雨和霧嗎？
現有主要實驗分別評估四種退化，尚未充分證明模型能處理任意混合天候。混合退化需要另外建立資料與測試。
參數少是否代表手機一定跑得快？
不一定。實際速度還受到圖片尺寸、注意力運算、記憶體頻寬、模型轉換與裝置加速器支援影響，必須在目標硬體上實測。
TAP 可以處理模糊與感光噪聲嗎？
論文主要針對雨、雪、霧和鏡頭雨滴，沒有證明相同模型已能直接處理所有模糊、噪聲或壓縮問題。新增任務通常需要新的訓練資料與 Prompt。
結語：TAP 的價值不只是縮小模型
TAP 真正有意思的地方，不是把參數從幾千萬壓到 275 萬這個單一數字，而是重新思考多任務模型如何共享知識。
它讓骨幹負責通用影像修復，讓 Soft Prompt 負責任務差異，再透過低秩分解保留任務之間可以共享的部分。兩階段訓練則降低不同任務同時更新骨幹所產生的衝突。
從研究結果來看，這套設計在四種惡劣天候修復上，用相對少的參數取得了有競爭力的畫質。
但正式部署前，仍不能只看參數量。任務如何選擇、混合天候怎麼處理、高解析度圖片跑多快、模型是否誤刪重要物體，以及下游辨識結果有沒有真的改善，才是產品能否上線的關鍵。
對我來說，TAP 是一個值得測試的架構方向，而不是下載權重後就能直接接進正式服務的完成品。
一個模型可以同時做四件事固然很好，但更重要的是，當第五件事加入、某個 Prompt 更新失敗，或週五下午主管突然要求支援夜間暴雨時，整套系統仍然有人知道該怎麼修。
立即體驗安全可靠的交易平台，點擊加入：https://www.okx.com/join?channelId=42974376
