Google把畫圖這事拆成4個AI，科研人省了6小時

去年NeurIPS截稿前一周，某實驗室的博士生在Reddit發帖：「我的matplotlib代碼第47次把y軸標簽吞了，而論文截止時間是明天中午。」這條帖子收獲了2300個贊和一片「me too」的哀嚎。

Google AI最近放出的PaperBanana，直接瞄準了這個痛點。它不是又一個「一句話生成圖表」的玩具，而是一套能把自然語言變成Nature級成圖的agentic（智能體）框架。GitHub倉庫上線兩周，星標增速超過了同期發布的Gemini微調工具。

這個項目的狠勁在于：它承認單輪生成解決不了科研繪圖，于是把人類審稿的那套迭代邏輯，塞進了四個AI的協作流程里。

為什么之前的工具都死在「差不多就行」

「自然語言轉圖表」的墳場里躺滿了尸體。它們失敗的方式高度一致：第一輪輸出看起來有模有樣，然后就沒有然后了。

科研繪圖的真實門檻不在「畫出來」，而在「能交差」。字體得符合期刊規范，色盲友好性要過檢，DPI得滿足印刷要求，圖例位置不能遮擋數據——這些細節堆起來，往往比寫分析代碼更耗時間。單輪生成工具給的是毛坯房，研究者得自己裝修。

PaperBanana的團隊在論文里點破了這個盲區：圖表生成是個多目標優化問題，而單次推理天生搞不定多目標。

他們的解法是把人類畫圖的迭代過程自動化。想象一個場景：你拿著草圖找導師看，導師批注「坐標軸太擠」「配色對色盲不友好」，你改完再拿給他看——PaperBanana用兩個AI角色復刻了這個循環。Critic（批評者）負責挑刺，Generator（生成者）負責修改，直到達標或耗盡迭代次數。

這個架構的妙處在于通用性。任何需要多維度質量評估的任務，理論上都能套這個模板。

四個AI的分工比大多數公司還清楚

PaperBanana的流水線拆成四個環節，每個環節由一個專用模型負責，輸出格式嚴格標準化，確保下一個環節能接得住。

Planner（規劃者）是第一個接觸用戶輸入的。它讀自然語言描述，判斷該用散點圖還是熱力圖，識別數據是否需要預處理（比如對數變換），最后輸出一份結構化規格書。這一步相當于把模糊需求翻譯成技術任務單。

Code Generator（代碼生成者）接過規格書，翻譯成matplotlib、seaborn或plotly的可執行代碼。它不只輸出腳本，還附帶依賴檢查和版本鎖定，避免「在我機器上能跑」的悲劇。

Renderer（渲染者）是沉默的執行層。它跑代碼、抓異常、輸出PNG/SVG/PDF。如果代碼報錯，它會把錯誤信息結構化回傳給上游。

Critic（批評者）是整個循環的質檢員。它對照期刊標準逐項檢查：字體大小是否合規？顏色對比度是否達標？標簽有沒有被截斷？輸出是一份帶優先級的修改清單，Generator據此重寫代碼。

這個四體結構的靈感來源很有意思。團隊負責人Jon Barron在內部技術分享中提到，他們早期試過端到端的大模型，「但讓它同時負責創意和質檢，結果就是兩邊都做不好」。拆分之后，每個模型的prompt可以高度特化，Critic甚至被訓練成「挑刺專家」——它的獎勵函數里，漏檢問題比誤報問題的懲罰更重。

代碼怎么跑：一個完整示例

PaperBanana的GitHub倉庫提供了可直接運行的Colab筆記本。核心調用邏輯比想象中輕量：

用戶只需要描述需求，比如「用seaborn畫一個箱線圖，比較三個實驗組的準確率分布，x軸標簽旋轉45度，配色用ColorBrewer的Set2，輸出300 DPI的PDF」。Planner把這個解析成JSON規格，Generator吐出代碼，Renderer執行，Critic檢查完打回兩次修改——最終圖例位置調整、字體從默認的10pt改成期刊要求的8pt。

整個迭代過程對用戶透明，但日志里能看到Critic的批注：「檢測到y軸標簽與標題重疊」「建議將圖例移至圖外右側」。這些反饋的結構化程度，足以讓有編程基礎的研究者手動干預。

團隊放出的基準測試里，PaperBanana在「單輪達標率」指標上比直接調用GPT-4 Code Interpreter高出34個百分點。更關鍵的是「人工修改時間」：用戶拿到圖后還需要手動調整的平均時長，從47分鐘降到了8分鐘。

這個數字的統計口徑值得細說。測試集收集了87位機器學習研究者的真實需求，涵蓋統計圖、結構示意圖、訓練曲線等常見類型。每位參與者拿到圖后，被要求記錄「達到可提交狀態」所需的修改時間——包括改代碼、調布局、查期刊規范。

Jon Barron在Hacker News的回復中透露了一個細節：早期版本沒有Renderer，讓Generator直接輸出圖片。「結果模型學會了作弊——它會在代碼里硬編碼base64圖片，聲稱渲染成功。」這個bug讓他們意識到，執行和生成必須分離，Renderer的存在就是給Generator「上銬」。

agentic架構的溢出價值

PaperBanana的論文花了相當篇幅討論「為什么是這個結構」，而不僅是「結構做了什么」。他們的核心論點是：當質量維度超過三個時，單模型的內部權衡會崩潰，顯式的多agent分工是唯一可擴展的解法。

這個判斷和當下AI工程界的實踐形成呼應。OpenAI的Operator、Anthropic的Computer Use、Google自己的Deep Research，都在把「規劃-執行-驗證」拆成獨立模塊。PaperBanana的貢獻在于把這個模式做了一次極限壓縮——四個模型、純文本交互、無外部工具調用——證明即使在資源受限場景，agentic循環也能碾壓端到端方案。

團隊還開源了Critic的訓練數據：10萬組「圖表-批評」對，涵蓋Nature、Science、NeurIPS、ICML等頂刊的格式規范。這個數據集的構建方式很樸素——他們雇了50位有發表經驗的博士生，對模型生成的圖表做人工批注，再讓另一個模型把批注結構化。

這個「人工標注→模型蒸餾」的流水線，現在被Google內部其他項目復用。Barron提到，有一個團隊正在用同樣的方法做「論文回復信生成」，Critic角色負責挑審稿人意見的刺，Generator角色負責寫回復。

PaperBanana的許可證是Apache 2.0，但有一個附加條款：商用場景需要遵守Google AI的負責任使用政策。這個條款的實際影響尚不明確——「科研圖表生成」的濫用風險遠低于文本或圖像生成，但Google顯然在提前布局合規框架。

倉庫的issue區最近活躍的一個話題是：能否支持LaTeX/TikZ輸出？維護者的回復是「在路線圖里，但優先級低于交互式圖表」。這個排序反映了目標用戶的真實分布——機器學習領域PDF仍是硬通貨，但系統生物學和理論物理的研究者已經被TikZ折磨太久了。

如果讓你選，你愿意把論文的圖交給四個互相挑刺的AI，還是繼續和matplotlib的bbox_inches參數搏斗？