Paletteは、オープンウェイトの200億パラメータモデルを派生させたプレゼンテーション生成モデルであり、その重みはアクセス可能で自社インフラで実行可能です。開発者は、このモデルにIBMのデザイン言語でスライドを作成するよう訓練しました。ベンチマークPresentBenchでは、測定された3分野のうち2分野で首位を獲得し、3分野の平均ではNotebookLMに次いで2位となりました。
大規模言語モデルにプレゼンテーションを依頼すると、一般的には適切な結果が得られますが、生成物はリクエストごとに似通ったものになり、モデル特有のスタイルが目立ちます。自社のプレゼンテーションテンプレートを遵守したい企業や、機密コンテンツを自社サーバー内に保持する必要がある企業にとって、このアプローチはすぐに限界に達します。一方、小型のオープンウェイトモデルは、多くの場合、欠陥のあるスライドを生成します。例えば、背景に埋もれたタイトル、はみ出したテキスト、重なり合った図形などです。
デザイナーとコーダーの役割
この問題は3つの難しさに起因します。モデルは自身が構築するスライドを視覚的に認識できません。各要素の位置、幅、フォントサイズを指定するコードを記述するだけで、エラーはレンダリング後に初めて明らかになります。また、モデルは同時に2種類の判断（編集的判断：何を言うか、どのグラフを選ぶか）と幾何学的判断（要素の配置）を行わなければなりません。最後に、学習データが不足しています。完成したプレゼンテーションは存在しますが、デザイン選択の理由やそれを生成したコードは存在しません。
Paletteは人間の手法を採用しています。まず、デザイナーが構成を決定し、JSON形式の構造化されたブリーフを作成します。このブリーフには、カラーパレット、タイポグラフィシステム、そして各スライドごとのレイアウト、コンテンツ、簡単な理由が記述されます。次に、コーダーが各スライドに対して、その推論を前置きしたpptxgenjsコードを記述して描画します。この2つの役割は、単一のLoRAアダプターによって担われます。これは、ベースモデルの重みを変更せずに追加される小型の学習レイヤーです。コーダーの呼び出しはスライドごとに並列で行われるため、コーディング段階は、開発者によれば約6～7倍高速になるとされています。
合成データとコントローラー
公開コーパスがないため、チームはオープンソースの大規模な「教師」モデルを使用して、約1,000件のプレゼンテーション（約10,000スライド）を生成しました。各例には、代替案を提示し、なぜそれが採用されなかったかを説明する反実仮想的な推論が付随します。生成されたスライドに欠陥がある場合、それは修正され、その推論もそれに合わせて書き直されます。
ソースコンテンツへの忠実性を保証するため、プロンプト内のルールだけでは不十分であることが開発者によって確認されました。有効だったのは、教師モデルに提供される参照プレゼンテーションの修正です。教師モデルは指示に従うよりも、これらの参照を多く模倣します。ユーザーはまた、二重角括弧内に記述された「[]」のような指示で結果を方向付けることができます。これらの指示は12のカテゴリに分類され、学習データ内では複数の方法で表現されています。
プレゼンテーションを返す前に、Paletteは検証ハーネスを通過します。単純なルールが既知のエラーを修正した後、各スライドがレンダリングされ、幾何学的コントローラーによって測定されます。このコントローラーは、重なり合う、切り取られる、またはページからはみ出るテキストを検出します。問題のあるスライドは別個の編集モデルによって書き直されますが、書き直しはコントローラーが改善を確認した場合にのみ保持されます。PresentBenchの131件のプレゼンテーションにおいて、このハーネスは平均3.5ポイントの向上をもたらしました。
対照的な結果
PresentBenchは5つの基準を評価します：基礎、ビジュアルデザイン、完全性、正確性、忠実性です。Paletteは、経済学と教育学の分野で最高の順位を獲得しました。一方、プレゼンテーションが物語形式であるTalk分野では、2つのクローズドシステムが上位を占め、Paletteは3位となりました。3分野の平均スコアは59.7で、NotebookLMの60.8に次ぐ結果でした。
開発者は、今後のステップとして、ハーネスの制御をGRPO（Group Relative Policy Optimization）型の強化学習の報酬信号として利用すること、およびDoclingを用いたソースドキュメントからの図表抽出を含めると述べています。
