IBMは20Bモデルにスライドを作らせた。決め手は検証ループにある

IBM Researchは、IBM Design Languageのスライド生成向けにLoRAでfine-tuningした20B open-weight model、Paletteを発表しました。一つのadapterが二つの役割を担います。designerが構造化JSON briefを作り、coderが各slideを描画するPptxGenJSのJavaScriptを生成します。

training dataは合成です。約1,000 deck、約10,000 slideを作り、採用しなかったdesign案の理由も加えました。coderはslideごとに並列実行でき、この段階は著者らによると約6倍から7倍高速になりました。

生成はモデルの最初の出力で終わりません。harnessがdeckをrenderし、重なり、文字切れ、canvas外の要素を検出します。editorが問題のslideを書き直しますが、checkerが改善を確認した場合だけ新しい版を採用します。131 deckの評価では、平均3.5 point向上しました。

Paletteは難しい一工程を編集可能なbriefとslide codeに分けた

モデルは、全体の物語、正確な内容、幾何配置を同時に決める必要がありません。designerが各slideのtypography、色、layout、内容を決め、coderはページごとに処理します。

中間結果は人にも別のagentにも読めます。一つの主張やlayoutだけを変え、全体を再生成せずに済みます。この境界はslide以外にも応用でき、chart、diagram、UIにも使える考え方です。

企業に効くのはpromptの追加よりcheckerによる制御である

IBMが最も難しいとしたのは事実への忠実性です。6行5列のtableを求めるbriefに3項目しかなければ、coderは残りを作り出してしまいました。prompt ruleを増やすより、training exampleの参照deckを直す方が効果的だったとしています。

enterprise AIへの教訓は明確です。品質は大きなモデルを選ぶだけでは生まれません。構造化した中間形式、検証可能な規則、自分の修正案を却下できる仕組みが必要です。open weightsなら、機密文書を自社infrastructure内に保つ選択肢もあります。

Benchmarkはslide品質を測るが企業styleへの忠実性は測らない

PaletteのPresentBench scoreは59.7でした。公開された3領域の平均で2位となり、60.8のNotebookLMとの差は1.1 pointです。EconomicsとEducationでは1位、Talkでは3位でした。

比較には二つの大きな制約があります。PresentBenchは特定のdesign languageへの忠実性を測りません。そこはPaletteの中心的な狙いです。また、別のfrontier modelがsource documentをplanに変換してからPaletteがdeckを作りました。つまり、20B modelだけで完結する完全localなend-to-end systemの結果ではありません。

企業templateと事実確認と図表の多いslideが本当の試験になる

IBMは今後、checker signalをreinforcement learningのrewardに使い、source documentからfigureを抽出し、一つか二つの既存.pptx templateから再学習なしでstyleを移す方法を検討しています。最後の項目が、他社のdesign languageに適応できるかを直接試します。

本番導入では幾何検査だけでは足りません。事実の出典、承認済みfontと色、logo、accessibility、修正時の内容保持まで確認する必要があります。そこまで到達して初めて、研究pipelineに顧客向けpresentationを任せられます。

Lilithの判定

Paletteの強みは一つの巨大な頭脳ではなく、各slideの後に定規を持つ検査役が現れ、修正案を却下できることです。その小さな権限が、派手なdemoと使えるproductionを分けます。