1. 一周論文速覽的整理思路與篩選邏輯每周固定花半天時間刷目標檢測方向的新論文是我做了快三年的習慣。這周0927-1003的整理工作照例從幾個預(yù)印本平臺的更新列表開始最終篩出12篇值得細讀的工作其中5篇做了完整精讀和筆記歸檔。整理這件事本身沒什么技術(shù)含量但篩選邏輯和歸檔結(jié)構(gòu)直接決定了你后續(xù)能不能真正用上這些論文而不是收藏夾里吃灰。先說篩選。目標檢測這個方向現(xiàn)在每周的新投稿量大概在80到150篇之間浮動全看等于沒看。我的第一層過濾是看標題和摘要里的任務(wù)關(guān)鍵詞如果一篇論文的核心貢獻只是把某個backbone換成另一個、或者在COCO上刷了0.3個點直接跳過。真正值得花時間的是三類工作提出了新的檢測范式比如從anchor-based到anchor-free那種級別的變化、解決了某個長期存在的痛點小目標、密集場景、開放詞匯、或者給出了非常有說服力的消融實驗和可視化分析。第二層過濾是看實驗設(shè)置的誠意。有些論文只在COCO val上跑一遍就敢說SOTA連test-dev都不跑這種基本可以判定為灌水。我會優(yōu)先關(guān)注那些在多個數(shù)據(jù)集上驗證、并且給出了推理速度對比的工作。畢竟目標檢測不是純分類任務(wù)精度和速度的權(quán)衡才是這個領(lǐng)域的核心矛盾。第三層是看代碼和權(quán)重是否開源。這周篩出的12篇里有7篇標注了代碼即將開源3篇已經(jīng)放出了倉庫鏈接。對于已經(jīng)開源的我會直接拉下來跑一遍推理腳本看看實際效果和論文里寫的是否一致。這個習慣幫我避開了不少“論文很美、代碼很坑”的雷。歸檔結(jié)構(gòu)上我用的是一個很樸素的Markdown模板每篇論文一個文件包含標題、作者單位只記機構(gòu)類型不記具體名稱、核心貢獻一句話、方法關(guān)鍵點、實驗結(jié)論、個人評價、可復現(xiàn)性評級。這個模板看起來簡單但堅持下來你會發(fā)現(xiàn)三個月后你還能快速回憶起某篇論文到底講了什么而不是只記得“好像在哪看過”。提示整理論文最忌諱的是只存PDF不寫筆記。我試過一年后翻自己的收藏夾完全想不起來某篇論文為什么當時覺得重要。后來強制自己每篇至少寫三句話總結(jié)情況才好轉(zhuǎn)。這周的整體感受是基于Transformer的檢測器依然占據(jù)主流但純Transformer架構(gòu)在邊緣設(shè)備上的部署問題開始被更多工作關(guān)注。另外開放詞匯檢測和少樣本檢測的交叉方向出現(xiàn)了幾篇有意思的工作后面會詳細展開。2. 本周核心論文分類精讀2.1 開放詞匯檢測方向的兩篇代表性工作這周開放詞匯檢測Open-Vocabulary Detection方向有兩篇工作值得細看。第一篇的核心思路是用視覺-語言預(yù)訓練模型的區(qū)域-文本對齊能力來替代傳統(tǒng)的分類頭。具體來說它不再像傳統(tǒng)檢測器那樣在固定類別上做softmax而是把每個候選區(qū)域的視覺特征和文本編碼器生成的類別嵌入做相似度匹配。這樣做的好處是推理時只需要提供新類別的文本描述模型就能直接檢測不需要重新訓練。這篇論文的關(guān)鍵創(chuàng)新在于區(qū)域特征和文本特征的融合方式。之前的工作大多是把區(qū)域特征直接和文本嵌入做點積但這篇論文發(fā)現(xiàn)區(qū)域特征里包含了大量背景噪聲直接匹配會導致新類別的誤檢率很高。它的解決方案是引入一個輕量級的特征凈化模塊用注意力機制把區(qū)域特征中與文本描述無關(guān)的部分抑制掉。消融實驗顯示這個模塊在novel類別上的AP提升了大概4個點而且?guī)缀鯖]有增加推理延遲。第二篇工作走的是另一條路用偽標簽做自訓練。它的流程是先用基類訓練一個檢測器然后用這個檢測器在無標注圖像上生成偽標簽再用偽標簽和基類標注一起訓練。聽起來很簡單但難點在于偽標簽的質(zhì)量控制。這篇論文設(shè)計了一個不確定性感知的偽標簽篩選機制對每個偽框計算一個不確定性分數(shù)只保留低不確定性的框參與訓練。這個思路在半監(jiān)督檢測里也有類似的工作但用在開放詞匯場景下效果確實比直接拿CLIP做零樣本推理要好。兩篇論文的實驗設(shè)置都挺扎實第一篇在LVIS數(shù)據(jù)集上做了完整的零樣本評估第二篇在COCO和LVIS上都跑了跨數(shù)據(jù)集實驗。不過第一篇的代碼還沒開源第二篇的倉庫已經(jīng)放出來了我試跑了一下推理速度比論文里寫的慢大概15%可能是我的環(huán)境配置問題。對比維度第一篇特征凈化第二篇偽標簽自訓練核心思路區(qū)域-文本對齊特征凈化基類檢測器偽標簽迭代新類別AP較高中等推理速度快中等訓練成本低無需重新訓練高需要多輪迭代代碼開源未開源已開源2.2 小目標檢測的改進方案小目標檢測這周有一篇工作提出了一個很實用的改進在特征金字塔的每一層都引入一個可學習的上采樣模塊而不是像FPN那樣只用簡單的最近鄰插值。這個想法的出發(fā)點是小目標在淺層特征圖上雖然分辨率高但語義信息弱在深層特征圖上語義強但分辨率低。傳統(tǒng)的FPN通過橫向連接把深層語義傳下來但上采樣的方式太粗糙導致小目標的特征對齊不夠精確。這篇論文的可學習上采樣本質(zhì)上是一個輕量級的卷積網(wǎng)絡(luò)輸入是低分辨率特征圖輸出是高分辨率特征圖中間用亞像素卷積PixelShuffle做上采樣。相比雙線性插值這種方式的參數(shù)量增加了不到0.1M但在小目標上的AP提升了2到3個點。論文里還做了一個很直觀的可視化用可學習上采樣生成的特征圖小目標的邊緣響應(yīng)明顯更清晰。不過這篇論文有一個問題它只在COCO上做了實驗而COCO里的小目標占比其實不算特別高。真正的小目標檢測 benchmark 應(yīng)該是像VisDrone或者無人機航拍數(shù)據(jù)集那種目標像素面積普遍小于32x32的場景。我打算下周自己在這個方向上補一組實驗看看可學習上采樣在極端小目標場景下是否依然有效。注意小目標檢測的論文一定要看它在什么數(shù)據(jù)集上評估的。COCO上的小目標AP和航拍數(shù)據(jù)集上的小目標AP完全是兩回事前者的小目標可能還有20x20像素后者可能只有5x5像素。2.3 實時檢測器的輕量化設(shè)計實時檢測方向這周有一篇工作提出了一個基于神經(jīng)架構(gòu)搜索的輕量化backbone專門針對邊緣設(shè)備。它的搜索空間設(shè)計得挺巧妙不是搜索整個網(wǎng)絡(luò)而是搜索每個stage的通道數(shù)和下采樣位置。這樣做的好處是搜索成本低而且搜出來的結(jié)構(gòu)可以直接替換現(xiàn)有檢測器的backbone不需要重新設(shè)計整個檢測頭。論文里給出的最優(yōu)結(jié)構(gòu)在驍龍865上跑到了45FPS精度比YOLOv5s高了1.2個點。不過我對這個結(jié)果持保留態(tài)度因為論文里沒有說明是否用了TensorRT或者NCNN做推理加速如果只是原生PyTorch在手機上跑45FPS這個數(shù)字有點可疑。另外搜索出來的結(jié)構(gòu)在服務(wù)器GPU上的表現(xiàn)如何論文里也沒提這讓我懷疑它是不是過擬合到了移動端。另一篇實時檢測的工作走的是知識蒸餾路線用一個大模型比如Swin-L級別的檢測器去蒸餾一個小模型。它的創(chuàng)新點在于蒸餾損失的設(shè)計不是簡單地讓學生模型模仿老師的輸出logits而是讓學生模型模仿老師在特征金字塔每一層上的注意力圖。這個思路在分類任務(wù)里有人做過但用在檢測上效果確實更好因為檢測任務(wù)對空間信息更敏感。2.4 基于Transformer的檢測器新進展Transformer檢測器這周有兩篇值得關(guān)注。第一篇是對DETR系列的一個改進核心是解決DETR收斂慢的問題。DETR的收斂慢主要是因為匈牙利匹配在訓練初期不穩(wěn)定導致梯度噪聲大。這篇論文提出了一種漸進式匹配策略訓練初期先用簡單的IoU匹配隨著訓練進行逐漸過渡到匈牙利匹配。這個想法很直觀但實現(xiàn)起來需要仔細設(shè)計過渡的時機和方式。論文里給出的結(jié)果是收斂速度提升了大概30%最終精度和原始DETR持平。第二篇工作關(guān)注的是Transformer檢測器的部署效率。它發(fā)現(xiàn)DETR類模型在推理時大部分計算量花在了encoder的多頭自注意力上而decoder的cross-attention其實計算量不大。于是它設(shè)計了一個稀疏化的encoder只對特征圖中響應(yīng)高的區(qū)域做自注意力其余區(qū)域直接跳過。這個思路和可變形注意力Deformable Attention有點像但實現(xiàn)更簡單不需要額外的偏移量預(yù)測網(wǎng)絡(luò)。在COCO上稀疏化encoder把推理速度提升了40%精度只掉了0.5個點。不過這兩篇論文都有一個共同的問題它們都只在COCO上做了實驗沒有在更復雜的場景比如密集人群、遮擋嚴重下驗證。Transformer檢測器在簡單場景下表現(xiàn)很好但在復雜場景下的魯棒性一直是個問號。3. 精讀論文的完整實操流程3.1 從摘要到方法快速判斷論文價值拿到一篇論文我的閱讀順序是摘要 → 圖表 → 方法 → 實驗 → 結(jié)論。摘要決定要不要繼續(xù)讀圖表決定這篇論文的核心貢獻是否直觀方法決定技術(shù)深度實驗決定可信度結(jié)論基本不看因為結(jié)論通常是摘要的復述。摘要的閱讀重點是找三個東西任務(wù)是什么、現(xiàn)有方法有什么問題、這篇論文提出了什么。如果摘要里只有“我們提出了一個XXX模塊在COCO上達到了SOTA”但沒有說清楚為什么需要這個模塊這篇論文大概率是增量式改進優(yōu)先級可以降低。圖表是判斷論文質(zhì)量的一個捷徑。好的論文通常有一張整體架構(gòu)圖能讓你在30秒內(nèi)理解方法的輸入輸出和核心模塊。如果架構(gòu)圖畫得含糊不清或者需要讀正文才能看懂說明作者自己可能都沒想清楚。另外可視化結(jié)果圖也很重要比如檢測結(jié)果的可視化、注意力圖的可視化、特征圖的可視化這些能直觀展示方法的效果。方法部分我會重點看公式和偽代碼。公式是否簡潔、變量定義是否清晰、偽代碼是否完整這些都能反映作者的嚴謹程度。如果方法部分充斥著大量沒有解釋的符號和復雜的公式堆砌但核心思想其實很簡單這種論文通常是在故意制造閱讀門檻。實驗部分我關(guān)注三個點對比方法是否全面、消融實驗是否充分、是否有失敗案例的分析。對比方法只跟弱基線比、消融實驗只做一兩個模塊、沒有失敗案例分析這三個問題出現(xiàn)任何一個論文的可信度都要打折扣。3.2 復現(xiàn)論文的關(guān)鍵步驟與參數(shù)配置復現(xiàn)一篇論文我的流程是環(huán)境配置 → 數(shù)據(jù)準備 → 基線復現(xiàn) → 方法復現(xiàn) → 結(jié)果對比。這個流程看起來簡單但每一步都有坑。環(huán)境配置上我一般用conda建一個獨立環(huán)境Python版本和PyTorch版本盡量和論文里寫的一致。如果論文沒寫就去翻它的requirements.txt或者setup.py。CUDA版本也要注意有些論文用的PyTorch版本比較老和新版CUDA不兼容這時候要么降CUDA版本要么用Docker。數(shù)據(jù)準備是最容易出問題的一步。COCO數(shù)據(jù)集還好標準的下載和解壓流程就行。但有些論文用了自定義的數(shù)據(jù)集劃分或者數(shù)據(jù)增強這些細節(jié)往往寫在附錄里容易被忽略。我的習慣是先把論文里提到的所有數(shù)據(jù)相關(guān)配置都列出來逐條核對?；€復現(xiàn)是驗證環(huán)境是否正確的重要步驟。如果論文里對比了YOLOv5我會先把YOLOv5在相同環(huán)境下跑一遍看看精度是否和論文里寫的一致。如果基線都對不上那方法復現(xiàn)的結(jié)果也沒有參考價值。方法復現(xiàn)時我會先跑通推理再跑訓練。推理腳本通常比較簡單能快速驗證模型結(jié)構(gòu)是否正確。訓練腳本涉及的東西多學習率、優(yōu)化器、數(shù)據(jù)增強、損失函數(shù)權(quán)重任何一個參數(shù)不對都可能導致結(jié)果偏差。我的做法是先用論文里給出的默認參數(shù)跑一遍如果結(jié)果差太多再逐個參數(shù)調(diào)整。提示復現(xiàn)論文時學習率是最容易出問題的參數(shù)。有些論文用的是線性縮放規(guī)則learning rate base_lr * batch_size / 64但沒在正文里寫清楚。如果你用的batch size和論文不一樣學習率也要相應(yīng)調(diào)整。3.3 實驗記錄與結(jié)果對比的規(guī)范做法實驗記錄我用的是一張Excel表格每行一次實驗列包括實驗編號、日期、論文名稱、數(shù)據(jù)集、模型配置、學習率、batch size、訓練輪數(shù)、mAP、AP50、AP75、APs、APm、APl、推理速度、備注。這個表格看起來笨但當你跑了上百次實驗之后沒有這張表你根本記不住哪個配置對應(yīng)哪個結(jié)果。結(jié)果對比時我堅持同一環(huán)境下對比的原則。有些論文里的結(jié)果是在不同GPU、不同框架、不同數(shù)據(jù)增強下得到的直接拿來比沒有意義。我的做法是把所有要對比的方法都在自己的環(huán)境下跑一遍用相同的數(shù)據(jù)增強和訓練輪數(shù)。這樣做雖然費時間但結(jié)果可信。另外推理速度的測量也要統(tǒng)一。有些論文測的是GPU上的batch inference速度有些測的是單張圖片的端到端延遲這兩個數(shù)字沒有可比性。我一般會統(tǒng)一測單張圖片在相同GPU上的端到端延遲包括預(yù)處理和后處理的時間。實驗編號模型數(shù)據(jù)集mAPAPs推理延遲(ms)備注E001基線ACOCO val42.124.318.2官方權(quán)重E002論文BCOCO val43.526.121.5復現(xiàn)結(jié)果E003論文B改進COCO val44.227.822.1自研改進3.4 論文筆記的歸檔與檢索方法論文筆記我用的是Markdown Git的方案。每篇論文一個Markdown文件文件名格式是年份-會議-一作姓氏-關(guān)鍵詞.md比如2026-arxiv-某作者-開放詞匯檢測.md。文件內(nèi)容用統(tǒng)一的模板包括元信息標題、鏈接、代碼鏈接、核心貢獻、方法細節(jié)、實驗結(jié)果、個人評價、相關(guān)論文。Git倉庫的作用是版本管理和全文檢索。我會定期用grep或者VS Code的全局搜索找關(guān)鍵詞比如搜“小目標”就能找到所有相關(guān)筆記。另外我還會維護一個索引文件按方向分類列出所有論文方便快速瀏覽。這個方案的好處是完全本地化不依賴任何在線服務(wù)而且Markdown格式通用性強十年后還能打開。壞處是需要自己維護但每周花10分鐘整理長期來看完全值得。4. 常見問題與排查技巧實錄4.1 論文復現(xiàn)結(jié)果對不上的排查思路復現(xiàn)結(jié)果對不上是家常便飯我總結(jié)了一個排查順序先查數(shù)據(jù)再查模型最后查訓練。數(shù)據(jù)問題最常見。比如COCO數(shù)據(jù)集的標注文件版本不對、數(shù)據(jù)增強的隨機種子沒固定、圖像預(yù)處理的方式和論文不一致有些論文用RGB有些用BGR。我遇到過一次論文里寫的mAP是43我復現(xiàn)出來只有38查了兩天才發(fā)現(xiàn)是數(shù)據(jù)增強里的RandomResize的尺度范圍設(shè)錯了。模型問題通常是結(jié)構(gòu)實現(xiàn)有誤。比如某個模塊的通道數(shù)寫錯了、激活函數(shù)用錯了、歸一化的位置不對。排查方法是逐層對比輸出維度用torchsummary或者手動打印每一層的輸出shape和論文里的描述核對。訓練問題包括學習率、優(yōu)化器、損失權(quán)重、訓練輪數(shù)。學習率的問題前面說過了優(yōu)化器方面有些論文用SGD有些用AdamW這兩個的收斂行為差別很大。損失權(quán)重方面檢測任務(wù)通常有分類損失和回歸損失兩者的權(quán)重比例對最終精度影響很大論文里如果沒寫清楚需要自己調(diào)。注意如果排查了一圈還是對不上先別懷疑自己的實現(xiàn)去看看論文的GitHub issue區(qū)。很多時候別人已經(jīng)踩過同樣的坑而且作者可能已經(jīng)回復了。4.2 論文代碼運行報錯的典型解決方案論文代碼跑不起來原因通常就那么幾個依賴版本沖突、CUDA不匹配、路徑配置錯誤、缺少預(yù)訓練權(quán)重。依賴版本沖突是最煩的。有些論文的requirements.txt寫得很隨意比如torch1.7但實際上代碼里用了1.9才有的API。我的做法是先看論文里寫的PyTorch版本然后嚴格按那個版本裝不要用最新版。CUDA不匹配通常表現(xiàn)為RuntimeError: CUDA error: no kernel image is available for execution on the device。這是因為PyTorch編譯時的CUDA架構(gòu)和你的GPU架構(gòu)不匹配。解決方法是裝對應(yīng)CUDA版本的PyTorch或者從源碼編譯。路徑配置錯誤一般是代碼里硬編碼了絕對路徑。解決方法是全局搜索/home/或者/data/把路徑改成自己的。缺少預(yù)訓練權(quán)重的話去論文的GitHub release頁面找或者看README里有沒有下載鏈接。有些論文的權(quán)重放在Google Drive上需要特殊處理才能下載這個就不展開了。4.3 論文創(chuàng)新點判斷與避坑經(jīng)驗判斷一篇論文的創(chuàng)新點是否靠譜我有一個簡單的標準如果這個想法我在讀之前就能想到那它大概率不是真正的創(chuàng)新。真正的創(chuàng)新通常是反直覺的或者需要一定的技術(shù)深度才能實現(xiàn)。避坑經(jīng)驗方面有幾類論文我會特別警惕。第一類是只刷點不分析的論文mAP漲了但沒有任何可視化或消融實驗解釋為什么漲。第二類是實驗設(shè)置不透明的論文比如不寫學習率、不寫訓練輪數(shù)、不寫數(shù)據(jù)增強細節(jié)。第三類是對比方法不公平的論文比如自己的方法用了更強的backbone或者更多的訓練數(shù)據(jù)但對比方法用的是原始配置。另外arXiv上的論文沒有經(jīng)過同行評審質(zhì)量參差不齊。我的習慣是對于arXiv上的論文先看作者單位只記機構(gòu)類型如果是知名研究機構(gòu)的工作可信度會高一些如果是完全沒聽過的機構(gòu)我會更謹慎地評估。問題類型典型表現(xiàn)排查方法數(shù)據(jù)問題精度整體偏低檢查標注版本、增強參數(shù)、預(yù)處理方式模型問題輸出shape不對逐層打印shape對比論文描述訓練問題收斂慢或不收斂檢查學習率、優(yōu)化器、損失權(quán)重環(huán)境問題運行時報錯檢查依賴版本、CUDA版本、路徑配置4.4 高效追蹤目標檢測前沿的實用技巧追蹤前沿不是每天刷arXiv那樣效率太低。我的做法是建立信息源矩陣預(yù)印本平臺arXiv、OpenReview 頂會論文集CVPR、ICCV、ECCV、NeurIPS 幾個高質(zhì)量的技術(shù)博客 幾個活躍的GitHub倉庫。預(yù)印本平臺我一般每周刷兩次每次半小時只掃標題和摘要。頂會論文集我會在會議結(jié)束后集中看重點看oral和highlight的論文。技術(shù)博客我關(guān)注的是那些有實操經(jīng)驗的作者而不是純新聞搬運的賬號。GitHub倉庫我關(guān)注的是那些持續(xù)更新的檢測框架比如MMDetection、Detectron2、YOLO系列它們的更新日志里經(jīng)常會有新方法的實現(xiàn)。另外Twitter或者X上的目標檢測社區(qū)其實很活躍很多作者會在上面發(fā)論文的簡短介紹和可視化結(jié)果。不過這個需要你花時間篩選關(guān)注列表關(guān)注那些真正做研究的人而不是營銷號。最后不要試圖讀完所有論文。目標檢測這個方向太大了每周的新論文你不可能全部看完。我的策略是精讀5篇泛讀10篇剩下的只看標題。精讀的論文要寫筆記、跑代碼、做實驗泛讀的論文只看摘要和圖表剩下的知道有這么個東西就行。5. 本周整理的個人體會這周整理下來最大的感受是目標檢測的研究重心正在從“刷COCO”轉(zhuǎn)向“解決實際問題”。前幾年大家比的是誰在COCO上mAP高現(xiàn)在越來越多的工作開始關(guān)注開放詞匯、小目標、邊緣部署這些更貼近實際應(yīng)用的方向。這個趨勢是好事說明這個領(lǐng)域在成熟。另一個感受是Transformer檢測器的部署優(yōu)化開始成為一個獨立的研究方向。之前大家只關(guān)心怎么把Transformer檢測器訓得更好現(xiàn)在開始有人關(guān)心怎么讓它跑得更快。這個轉(zhuǎn)變和當年CNN檢測器從學術(shù)走向工業(yè)界的過程很像說明Transformer檢測器正在經(jīng)歷從“能用”到“好用”的過渡。最后分享一個我自己的小技巧每周整理完論文后花10分鐘寫一段“本周印象最深的論文和原因”。不用長兩三句話就行。這個習慣堅持了半年后我發(fā)現(xiàn)自己對領(lǐng)域的判斷力明顯提升了因為你在強迫自己從一堆論文里挑出真正重要的那幾篇而不是被動地接收信息。