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 在经济学和教育领域排名第一，在 Talk 领域排名第三，在三个领域的平均值上排名第二。

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

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

下一步

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

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

我们学到了什么

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

1. 把推理放进数据里。训练模型理解某个选择为何做出（包括哪些方案被否决），比只训练选择本身能教给模型更多。
2. 先修正示例，再添加规则。当教师模型出错时，我们的第一反应是往它的提示词里加一条规则，但这很少有用。教师模型更多是在照抄它的参考演示文稿，而不是遵循指令，所以真正改变其输出的是修正参考材料。
3. 让修复默认安全。只有当修复能可衡量地带来帮助时才保留它，这样的修复可以应用到每一个输出上。
4. 先构建检查器。正是它让数据可信、让输出可以安全交付。