大型模型雖然能生成精美簡報，卻缺乏客製化風格且有資料隱私疑慮；而小型模型在排版上表現不佳。Palette 透過微調一個 20B 的小型模型，利用合成資料、模擬人類「設計師與程式設計師」的分工模式，並搭配修復機制，成功讓模型能依循特定設計語言生成簡報，同時保有資料所有權，並在基準測試中取得競爭力。
向頂尖模型索取一份簡報，您會得到一份不錯的成果。但若要求十份，它們看起來就會開始雷同：同樣的預設風格、同樣的內部樣式，帶有一種淡淡的「AI 生成簡報」感。這在您不要求簡報符合特定範本時沒問題，但頂尖模型有其固有的風格，無論您如何調整提示詞，它們最終都會回歸原樣。有時內容涉及機密，根本無法離開您的系統。
這兩種情況都指向您需要一個自己擁有的模型：開放權重、在您自己的基礎設施上運行，並以您自己的設計語言進行訓練。然而，問題在於小型開放模型，也就是您實際會自行託管的那種，在這方面表現不佳。它們生成的簡報會出現問題：標題融入背景、文字超出投影片範圍、形狀相互堆疊。
Palette 驗證了一個假設：一個小型開放權重模型，透過您的設計語言合成資料進行訓練，並由一個校驗機制檢查，可以在您保留結果所有權的同時，與頂尖系統競爭。我們微調了一個 20B 模型，使其像人類一樣製作簡報：由設計師規劃簡報，程式設計師繪製每張投影片。
其訓練資料遵循 IBM Design Language，在 PresentBench 上，它在我們測量的三個領域中有兩個排名第一。本文將介紹我們如何合成資料、訓練模型並圍繞它建立校驗機制。
為什麼簡報對小型模型來說很難？
一份簡報看起來很簡單，但製作它卻要求模型完成三件小型模型不擅長的事情。
它在沒有看到投影片的情況下進行排版。模型不會直接繪製投影片；它會編寫程式碼，將每個元素放置在特定的 x、y 座標、寬度和字體大小。一個 75 個字元的標題能否以 56pt 的字體分兩行顯示，是模型在腦中進行的算術，它只有在程式碼渲染後才會發現自己錯了。小型模型經常會出錯，這就是形狀重疊和文字超出投影片的原因。
它同時做出兩種決策。決定每張投影片的內容以及如何呈現（圖表還是表格？該刪減什麼？）是編輯判斷。精確地放置它們則是幾何學。單次處理必須在 10-20 張投影片上同時完成這兩件事，同時保持調色板、字體和版面的一致性。
沒有資料顯示簡報是如何製作的。現成的簡報很多，但缺乏設計選擇背後的理由或生成它們的程式碼。
像人類一樣製作：一位設計師和一位程式設計師
沒有人會一次性完成一份簡報。您會先決定故事內容（多少張投影片、每張投影片說什麼、哪張用圖表、哪張用表格），然後才製作每張投影片。Palette 以同樣的方式將工作分成兩個角色，由單一的 LoRA 轉接器提供服務：
設計師閱讀計畫並編寫結構化的 JSON 簡報：包括調色板、字體系統，以及每張投影片的版面、確切內容和簡短的設計理由。
程式設計師從簡報中獲取一張投影片的規格，並編寫繪製該投影片的 pptxgenjs JavaScript 程式碼，前面附有其推理過程。
現在每個角色只做一種決策：設計師處理編輯判斷，程式設計師處理幾何學。它們之間的簡報是可讀且可編輯的，因此一個人或一個代理可以更改一張投影片的版面，而無需重新生成整個簡報。由於每張投影片的上下文在任何程式碼編寫之前都已固定，程式設計師可以並行調用，每張投影片一個，這使得程式編寫階段快了約 6-7 倍。
我們使用 LoRA 而非完全微調來訓練轉接器：它在一個有能力的基礎模型之上教授一種格式和技能，而不會干擾基礎模型已知的知識，並且使每次實驗的成本都很低。一個經驗是：程式設計師的範例比設計師的範例長約 5 倍，因此在我們將設計師的範例過度取樣 5 倍之前，單純的混合會導致設計師訓練不足。
合成簡報及其推理
由於沒有公開的計畫、設計決策和投影片程式碼語料庫，我們使用一個大型開放教師模型生成了一個。每份簡報都從一個設定其類型、長度、版面和任何使用者指令的「食譜」開始，這樣我們就可以控制資料涵蓋的內容。計畫範圍從整潔的提綱到原始內容轉儲，因此模型學會了剪裁和濃縮。我們生成了大約 1000 份簡報，涵蓋約 10,000 張投影片。
每個範例也帶有其背後的推理，以反事實的形式編寫：追蹤會權衡一個替代方案並說明為何被拒絕，因此模型學會了選擇背後的規則，而不僅僅是選擇本身。設計師推理內容和形式。例如：
「四個季度的收入，呈現明顯的上升趨勢。我考慮過表格，但這張投影片的重點是趨勢，而不是確切的數字，所以長條圖可以一目了然。」
程式設計師推理幾何學：
「標題有 62 個字元。如果設為 44pt，它會換行成三行並與下面的圖表重疊，所以我將它設為 36pt，這樣可以分兩行顯示並為圖表上方留出空間。」
僅靠教師模型並不能使資料變好；圍繞它的循環才是關鍵。每份合成的簡報都會被渲染並由與推論時校驗機制相同的檢查器檢查是否有重疊和溢出。損壞的投影片會被修復，其推理會以相同的反事實形式重寫，涵蓋原始版面哪裡出錯以及修復為何有效。檢查器捕獲的每個錯誤都成為更好的訓練範例。
最困難的問題是忠實度。最糟糕的失敗是投影片中包含輸入中沒有的事實，我們發現提示詞規則無法阻止這種情況。如果簡報要求一個六乘五的表格但只包含三個項目符號，程式設計師就必須發明其餘的內容。
解決這個問題的是參考簡報，而不是規則：可靠地修復參考簡報會改變教師模型的輸出，而添加規則則很少有效。教師模型在其提示詞中會看到一些參考簡報，並且複製它們的程度遠超過遵循指令的程度。
以白話文引導簡報
使用者通常希望對特定的設計選擇有更細緻的控制：圖表而非表格、特定顏色、更深的封面。Palette 允許他們透過指令來要求這些，這些指令是直接寫在計畫中並用 [[ ]] 包裹的簡短說明：
[[製作成時間軸]]
設計師將每個指令納入簡報中，程式設計師在繪製投影片時遵循它。如果沒有指令，模型可能會合理地將這些里程碑顯示為表格；有了指令，模型就會繪製時間軸。
模型遵循指令是因為它經過訓練。資料食譜包含來自 12 個類別的指令，其中一些如下所示，每個指令都以幾種不同的方式表達，因此模型學習的是意圖而不是固定的短語。
| 類別 | 範例指令 |
|---|---|
| 版面 | [[製作成時間軸]] |
| 語氣 | [[坦誠，不加修飾]] |
| 受眾 | [[這是給董事會看的]] |
| 順序 | [[先提出要求]] |
| 排除 | [[不含定價]] |
| 強調 | [[突顯關鍵數字]] |
圖 1. 同一份計畫在沒有（左）和有（右）[[製作成時間軸]] 指令時的圖示。
建立檢查與修復機制
即使是訓練有素的模型，有時也會產生損壞的投影片：標題與背景顏色相同，或兩個方框相互堆疊。因此，Palette 不會直接返回模型的輸出；每份簡報都會先經過一個校驗機制。
圖 2. 設計師起草簡報，程式設計師並行編寫每張投影片的程式碼，然後校驗機制在簡報返回之前檢查並修復每張投影片。
首先，簡單的規則會修復已知的錯誤，例如格式錯誤的顏色代碼，否則會使所有投影片變成黑色。然後，每張投影片都會被渲染和測量：幾何檢查器會標記重疊、被裁剪或超出投影片的文字。被標記的投影片會發送給一個單獨的編輯模型，該模型會重寫該投影片的程式碼。
關鍵規則是，只有當檢查器確認投影片有所改進時，重寫才會被保留；否則原始版本會保留。這使得校驗機制可以安全地運行在每份簡報上。它可以修復投影片，但不會使其變得更糟。
圖 3. 修復的圖示。生成時（左），每張卡片的標題都堆疊在描述上方；校驗機制檢測到重疊並將卡片重新排列成 2x2 的網格（右）。
為了衡量其效果，我們對每份 PresentBench 簡報生成一次，並在有無校驗機制的情況下進行評分。在 131 份簡報中，校驗機制平均增加了 3.5 分。
評估
我們在 PresentBench 上進行評估，該基準根據五個標準對生成的簡報進行評分：基本要素、視覺設計、完整性、正確性和忠實度。PresentBench 提供的是原始文件而非計畫，因此在這些運行中，一個單獨的頂尖模型從文件中起草了每個計畫，然後 Palette 根據該計畫建立簡報。我們報告了三個領域的結果；基準數據來自 PresentBench 論文。
圖 4. 按領域劃分的 PresentBench 分數。Palette（藍色）與 NotebookLM、Manus 1.6 和其他五個系統（灰色）進行比較。Palette 在經濟學和教育領域排名第一，在演講領域排名第三，在三個領域的平均排名第二。
Palette 在結構化內容和數字準確性決定分數的領域表現最佳，在經濟學和教育領域排名第一。在演講領域，簡報以敘事和演講為主導，兩個閉源系統得分更高，Palette 排名第三。在三個領域中，它排名第二，比 NotebookLM（59.7 對 60.8）低 1.1 分，但領先於其他競爭者，作為一個單一的 20B 開放權重模型。
PresentBench 衡量簡報是否良好，但未衡量其是否遵循特定的設計語言。我們不知道有任何基準能做到這一點，這是我們希望幫助彌補的空白。
下一步
校驗機制已經可以計算廉價且可驗證的訊號：投影片是否渲染、是否有任何重疊或溢出、每個事實是否都能追溯到簡報。目前我們使用它們在生成後修復輸出。接下來，我們希望將相同的檢查作為強化學習的獎勵，這樣模型從一開始就不會犯這些錯誤。由於程式設計師一次處理一張投影片，每張投影片都是一個簡短、可獨立檢查的運行，非常適合 GRPO 風格的訓練。
我們還希望透過從原始文件中提取圖形（例如使用 Docling）並使用校驗機制放置它們來彌補圖形豐富簡報的差距。我們正在探索一種更輕量級的方式來引入您自己的範本：無需重新訓練，即可從您現有的一兩個 .pptx 文件中重新設計輸出。
我們學到了什麼
建立 Palette 教會了我們一些有效的方法，這些方法自然地擴展到其他輸出具有可程式碼檢查結構的任務，從圖表和圖形到使用者介面佈局：
將推理放入資料中。訓練模型了解做出選擇的「原因」，包括被拒絕的選項，比單純的選擇本身更能教會模型。
在添加規則之前修復範例。當教師模型出錯時，我們的第一反應是向其提示詞添加規則，但這很少有幫助。教師模型複製其參考簡報的程度遠超過遵循指令的程度，因此修復參考簡報才是真正改變其輸出的方法。
預設情況下使修復安全。只有當修復被證明有助於改進時才保留，這樣它就可以運行在每個輸出上。
首先建立檢查器。這是使資料值得信賴並使輸出安全發布的關鍵。
覺得值得一看？分享給朋友。
以上為 AI 自動翻譯導讀。原文版權歸 Hugging Face Blog 所有， 建議透過「閱讀原文」前往原始網站，以取得最完整資訊並支持原作者。
43 個來源、每 2 小時更新，太多看不完。電子報每週挑最值得看的幾則，附上 Max 的看法。
