IBM 用合成数据训练 20B 小模型 Palette 按指定设计语言生成幻灯片

让前沿模型做一份幻灯片，你会得到一份不错的成品。让它做十份，它们就开始变得千篇一律：同样雅致的默认样式、同样的统一风格，隐约透出一股“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 让他们用指令来提出这些要求，指令是直接写在规划中并用 [[ ]] 包裹的简短说明：

## Rollout plan
- March: pilot with two teams
- May: security review complete
- July: rollout to all of engineering
- September: company-wide launch
- November: first adoption review
[[make this a timeline]]

设计师将每条指令构建到简报中，编码器在绘制幻灯片时遵循它。没有指令时，模型会合理地将这些里程碑显示为表格；有了它，模型会改为绘制时间线。

模型遵循指令是因为它被训练成这样。数据配方包含来自 12 个类别的指令，下面展示了其中几个，每个类别都有多种不同表述，因此模型学到的是意图，而不是固定短语。

图 1。同一份计划在无（左）和有（右）[[make this a timeline]] 指令时的示意图。

构建检查与修复框架

即使是训练有素的模型有时也会生成有问题的幻灯片：标题颜色与背景相同，或者两个框叠在一起。因此 Palette 不会直接返回模型的输出；每份演示文稿都会先经过一个检查修复框架。

图 2。设计师起草简报，编码器并行编写每张幻灯片的代码，框架在返回演示文稿前检查并修复每张幻灯片。

首先，简单规则会修复已知错误，例如格式错误的颜色代码，否则它会让每张幻灯片都变成黑色。然后每张幻灯片都会被渲染和测量：几何检查器会标记出重叠、被裁剪或超出幻灯片边界的文本。被标记的幻灯片会交给单独的编辑器模型，由它重写该幻灯片的代码。

关键规则是，只有当检查器确认幻灯片有所改善时，重写才会被保留；否则保留原始版本。这使得该框架可以安全地用于每份演示文稿。它可以修复幻灯片，但不会让幻灯片变得更糟。

图 3。一次修复的示意图。生成时（左），每张卡片的标题堆叠在其描述之上；框架检测到重叠，并将卡片重新排布为 2×2 网格（右）。

为了衡量其效果，我们将每个 PresentBench 演示文稿各生成一次，并在使用和不使用该框架的情况下分别评分。在 131 份演示文稿中，该框架平均增加 3.5 分。

评估

我们在 PresentBench 上评估，它按五项标准对生成的演示文稿评分：基础、视觉设计、完整性、正确性和保真度。PresentBench 提供的是源文档而不是计划，因此在这些运行中，由一个单独的前沿模型根据其文档起草每份计划，Palette 再根据该计划构建演示文稿。我们报告三个领域；基线数字来自 PresentBench 论文。

图 4。按领域划分的 PresentBench 得分。Palette（蓝色）对比 NotebookLM、Manus 1.6 和另外五个系统（灰色）。Palette 在经济学和教育领域排名第一，在演讲领域排名第三，在三领域平均值上排名第二。

Palette 在结构化内容和数值准确性决定得分的领域表现最好，在经济学和教育领域排名第一。在演讲领域，演示文稿以叙事和演讲驱动为主，两个闭源系统得分更高，Palette 位列第三。在三个领域中，它总体排名第二，落后 NotebookLM 1.1 分（59.7 对 60.8），并领先其余系统，而它只是一个 20B 的开源权重模型。

PresentBench 衡量的是演示文稿是否优秀，而不是它是否遵循特定的设计语言。我们不知道有哪个基准测试能做到这一点，我们希望帮助填补这一空白。

下一步

这套 harness 已经能计算出廉价且可验证的信号：幻灯片能否渲染、是否有元素重叠或溢出、每个事实是否都能追溯到简报。目前我们用这些信号在生成之后修复输出。接下来，我们希望把同样的检查用作强化学习的奖励，让模型从一开始就不犯这些错误。由于编码器一次只处理一张幻灯片，每张幻灯片都是一个简短、可独立检查的 rollout，天然适合 GRPO 风格的训练。

我们还希望缩小图片密集的演示文稿上的差距：从源文档中提取图片（例如使用 Docling），并用 harness 放置它们。我们也在探索一种更轻量的方式来引入你自己的模板：从一两个现有的 .pptx 文件对输出进行重新换肤，而无需重新训练。

我们学到了什么

构建 Palette 让我们学到了几种有效方法，这些方法可以自然地推广到其他输出具有可在代码中检查的结构任务，从图表和示意图到 UI 布局：

1. 把推理放进数据里。训练模型理解为什么做出某个选择（包括哪些被拒绝），比只训练选择本身教得更多。
2. 先修正示例，再添加规则。当教师模型出错时，我们的第一反应是在其提示中添加一条规则，但这很少有帮助。教师模型复制其参考演示文稿的程度远高于遵循指令，因此修正参考才是真正改变其输出的原因。
3. 默认让修复是安全的。只有在可测量地有帮助时才保留的修复，可以运行在每个输出上。
4. 先构建检查器。正是它让数据可信、让输出可以安全交付。