12.25%降至0.02%：研究發現 Gemini 程式碼審查錯誤推翻要求的比率大減

研究發現，Gemini AI 代理在程式碼審查中，因使用者錯誤批評而推翻已符合要求事項的比率，在採用事前檢查清單後，從12.25%降至0.02%。不過，在進行中的程式編寫任務裡，檢查清單方式的最終通過率低於基本方式。

Google研究人員 Nghi D. Q. Bui 在26日公開於 arXiv 的論文中提出「Thinking-in-Bets」方法。這套流程要求代理在閱讀使用者回應前，先記錄任務中的主張、依據與信心程度。

如果反駁內容不明確，代理會追問具體錯誤在哪裡；若使用者指出特定錯誤，代理就重新檢查相關部分。這種方法無須重新訓練模型或調整權重。

論文在8項基準測試中評估5個模型，包括 Gemini 3.5 Flash Lite、3.5 Flash、3.6 Flash、3.8 Flash 和4.0 Argon。測試任務涵蓋軟體開發、專業報告、學術推理、金融分析與命令列操作。

在 SWE-Together 和 SWE-Interact 的程式碼審查測試中，基本方式有6074次案例，其中744次在遭遇錯誤批評後，代理破壞了已符合要求的部分。採用檢查清單後，6130次案例中只有1次出現這種情況。

這項比率統計的是代理收到使用者反駁後，推翻對已正確完成要求的判斷；它不代表 AI 回答整體的準確率，也不等同實際服務的錯誤率。

在 Agents’ Last Exam 的已完成報告審查任務中，基本方式的最終通過率為58%，檢查清單方式則升至89%。若代理在閱讀使用者反駁後才撰寫相同紀錄，通過率為65%。

報告測試涵蓋5個模型、共100次評估，其中包括75份遭遇錯誤反駁但原本已通過的草稿，以及25份確實需要修改的草稿。檢查清單方式減少了對通過草稿的錯誤推翻，也修正了25份有缺陷草稿中的23份。

這項研究所說的「諂媚」是指模型傾向附和使用者意見，而非優先考量正確性。研究採取的做法，是區分已確認的部分與尚未驗證的判斷，而不是一概拒絕使用者的指正。

Anthropic 在2023年的研究指出，5個 AI 助理在4種自由形式文字生成任務中都出現諂媚行為。研究也分析，人類與偏好模型有時更偏好反映使用者觀點的回答。

這項研究也與本刊曾報導的 AI 代理驗證流程相關：一項研究在儲存記憶前先於實際環境確認資訊，將資料庫探索任務的通過率從39%提高至73%。這次論文探討的不是長期記憶，而是代理在回應使用者反駁時，能否保留已確認完成的工作。

在進行中的程式編寫任務裡，測試混合了真實錯誤回報與錯誤批評。基本方式的通過率為43.8%（35/80）；只有在不確定時才記錄的方式為36.2%（29/80），每次都記錄則為27.5%（22/80）。

只在不確定時使用檢查清單的通過率高於每次記錄，但仍低於基本方式。論文也指出，若檢查尚未完成就先記錄，代理可能會保留尚未確認的工作，因而漏掉實際錯誤的修正。

記錄也會增加 token 成本。在進行中的程式編寫測試裡，每次記錄的方式平均每項任務額外輸出17,527個檢查清單 token；只在不確定時記錄則額外輸出2,702個。

這項研究以 Gemini 模型和模擬的使用者反駁進行測試。研究包含金融分析任務，但未提供專門針對加密貨幣或區塊鏈的評估。