這篇解什麼問題
MAP@3 這種排序指標的隨機地板要怎麼驗證最可靠、模型拿高分是不是背過答案該怎麼實測、檢索增強什麼時候反而幫倒忙、量化模型換個推論引擎為什麼會直接把 kernel 記憶體炸掉——這四題都不是憑經驗能答的，需要查文獻。
我怎麼做
用 Google Deep Research 針對這四個主題各生成一份研究報告，存進個人知識庫當文獻筆記。接著不直接採信，派 4 個獨立的 AI agent 平行去查核每一份報告：每一條具名的論文引用都用網路搜尋核對是否真實存在、標題／作者／年份／發表管道是否正確；每一個具體數字都盡量回溯到原始論文的表格逐一核對，不採信報告自己的轉述。
結果與數據
四份報告裡，論文本身的存在性大多沒問題——沒查到憑空捏造的論文。但每一份都抓到至少一處實質錯誤，模式很一致：真實存在的論文，配上被誇大、誤植、或掛錯的具體數字與歸因。
- MAP@K 評測方法：核心數學（隨機地板 11/30 ≈ 0.367、蒙地卡羅驗證邏輯）完全正確，但有個死連結引用被反覆用來支撐三個論點，收尾段落引用的幾篇文獻主題其實不對口（Wi-Fi 數位分身、供應鏈模型），只是關鍵字剛好重疊。
- 資料污染偵測：LLMSanitize 的發表管道被誤植成 ACL 2024（實際是 TMLR 2025）；兩個具體數字——PaCoST 論文的「600 筆」樣本門檻、Oren et al. 的「50%」偵測成功率——回查原始論文的表格都查無出處；報告用來解釋「改寫版分數反而比原文高」這個現象的核心引用（Duan et al. 2024），那篇論文實際主題是別的東西（時間偏移造成的偽陽性，不是用字流暢度）；還推薦了一個結構上不可能用在已公開兩年資料集上的方法（STAMP，一種必須在資料公開「之前」就先佈署的主動浮水印技術）。
- RAG 檢索退化：多數論文引用（Lost in the Middle、Chain-of-Note、Self-RAG、ClashEval、PopQA 等）查證後準確，但報告轉述「Lost in the Middle」的退化幅度時，把論文原始數據（中段位置準確率降到約 50.5%，比零樣本低約 5.6 個百分點）誇大成「降到 40%、差距近 16 個百分點」——膨脹了將近 3 倍，剛好是最容易被拿來跟自己實驗結果做比較的那個數字。另一篇論文的作者也被錯誤標成「Xie et al.」，實際是「Jin et al.」。
- transformers 讀 GGUF：核心結論（整包解量化到 host RAM、跟裝置無關）直接對照 transformers 目前主線原始碼與真實 GitHub issue 逐字核對過，站得住腳。但有一個引用貼錯（連到一篇無關的 Windows 下載錯誤討論）、兩個「zero-copy」相關的引用內容根本沒提到 zero-copy，還有一句誇大的敘述——llama.cpp 的 GPU offload「幾乎零 host RAM」，忽略了作業系統 page cache 仍然占用實體記憶體的事實。
一句話結論
Deep Research 查回來的論文身分大多是真的，但四份報告沒有一份能直接照抄進筆記——真正危險的不是「憑空編造」，是「真論文配上被誇大或掛錯的具體數字」，這種錯誤比整篇捏造更難靠直覺抓到，必須逐條回溯原始來源才查得出來。