クラウドのアプリの中で動くスライド生成ツールはもう珍しくありませんが、自分で動かせて自社の様式を教え込めるモデルはより希少です。小さなオープンモデルはスライド作りが本当に苦手だからです。タイトルが背景に溶け込み、文字が端からはみ出し、図形が互いに重なります。IBMのPaletteはそれを直そうとする研究上の試みで、最も再利用できる発想はモデルそのものではなく、その周りの手法です。
中心にある工夫は、デッキを一つの仕事として扱うのをやめることです。スライドを作るには同時に二つの異なる判断が要ります。何を言い、どう見せるかという編集上の判断と、どこに正確に置くかという幾何の判断です。Paletteはこれを、一つのLoRAアダプターが担う二つの役割に分けます。designerは計画を読み、構造化されたJSONのブリーフを書きます。配色、書体の体系、各スライドのレイアウトと内容、そして短い根拠です。続いてcoderが一枚のスライドのブリーフを受け取り、pptxgenjsでそれを描くJavaScriptを書きます。間にあるブリーフは読めて編集でき、人やエージェントがデッキ全体を作り直さずに一枚のレイアウトを変えられます。各スライドの文脈が先に確定するため、coderは並列で動き、その段階がおよそ6〜7倍速くなります。
学習データ自体も合成です。計画、設計上の判断、スライドのコードの公開コーパスがないため、IBMはより大きな教師モデルから約1,000のデッキ、おおよそ10,000枚のスライドを生成しました。それぞれがジャンル、長さ、レイアウトを定めるレシピから始まり、制御用データに網羅性を持たせています。各例には反事実として書かれた根拠が付いており、却下された選択がなぜ誤りだったかを説明するので、モデルは結果だけでなくその背後の規則を学びます。
真似すべきはチェッカーです。合成された各デッキは描画され、推論時に使うのと同じ仕組みで重なりやはみ出しが検査され、壊れたスライドは修復されます。修正はチェッカーがスライドの改善を確認したときだけ残されます。これにより修復のループはあらゆる出力に安全に使えます。スライドを直せても、悪くすることはありません。PresentBenchでは、この仕組みが131のデッキ平均で3.5点を加え、Paletteは三つの領域でNotebookLMの60.8に対し59.7で2位に入ります。単一の20Bのオープンウェイトモデルとしてです。当サイトでは、この問題のホスト型版を解くGammaやBeautiful.aiといったクラウドの競合をレビューしています。
注意点は実在します。この記事はベースモデルも、ライセンスも、重みのダウンロード先も示しておらず、今のところ、今日から自分でホストできるものというより研究の報告として読めます。IBMは、忠実性が最も難しい問題だと率直に認めています。ブリーフが六×五の表を求めながら三つの箇条書きしか与えなければ、coderは残りを作り出すしかなく、どのプロンプト規則もそれを確実には防げません。他のチームが構造化された文書を生成する際に持ち帰るべきは、ベンチマークの点数ではなく、この手法です。