IBM 开源 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 让他们通过指令来提出这些要求，这些简短的指令直接写在规划中并用 [[ ]] 包裹：

## 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 在 Economics 和 Education 上排名第一，在 Talk 上排名第三，在三个领域的平均值上排名第二。

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

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

下一步

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

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

我们的经验

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

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