IBM Research 发布 Palette：用 LoRA 微调 20B 开源模型按自有设计语言生成幻灯片

向前沿模型要一份幻灯片，你会得到一份不错的。要十份，它们就开始千篇一律：同样体面的默认样式，同样的固定风格，隐约的“AI生成幻灯片”既视感。这没什么问题，直到你想让幻灯片看起来像你自己的模板。前沿模型有它们自己的固定风格，无论怎么提示都阻止不了它们漂移回去。而且有时内容是机密的，根本不能离开你的系统。

这两点都指向一个你拥有的模型：开放权重、跑在你自己的基础设施上、用你自己的设计语言训练。问题在于小型开放模型——你真正会自托管的那种——在这件事上很糟糕。它们生成的幻灯片是坏的：标题消失在背景里，文字跑出幻灯片，形状层层叠叠。

Palette 验证了一个赌注：一个小型开放权重模型，用你的设计语言合成数据训练、由一套 harness 校验，能与你保留结果所有权的前提下和前沿系统一较高下。我们微调了一个 20B 模型，让它像人一样制作幻灯片：设计师规划整套幻灯片，程序员绘制每一页。它的训练数据遵循 IBM Design Language，在 PresentBench 上，它在我们测量的三个领域中两个排名第一。本文介绍我们如何合成数据、训练模型并围绕它构建 harness。

为什么幻灯片对小模型很难

幻灯片看起来简单，但制作一份需要模型做三件小模型不擅长的事。

它要在看不见幻灯片的情况下排版。模型并不绘制幻灯片；它编写代码，把每个元素放到指定的 x、y 坐标、宽度和字号上。一个 75 字符的标题以 56pt 字号能否排在两行内，是模型在脑中做的算术，而它只有在代码渲染之后才知道自己错了。小模型经常算错，这就是形状重叠和文字跑出幻灯片的来源。

它要同时做两类决策。决定每页幻灯片说什么、如何呈现（用图表还是表格？删掉什么？）是编辑判断。精确放置它是几何问题。单次生成必须在 10–20 页幻灯片上同时完成两者，还要保持配色、字体和布局一致。

没有数据展示幻灯片是如何被制作的。现成的幻灯片很多，但设计选择背后的考量以及生成它们的代码却不存在。

像人一样构建：一个设计师和一个程序员

没有人一次就做完一份幻灯片。你先确定故事线（多少页、每页说什么、哪页用图表、哪页用表格），然后再构建每一页。Palette 以同样的方式分工，由一个 LoRA 适配器承担两个角色：

• 设计师读取规划并写出结构化的 JSON brief：配色、字体系统，以及每页幻灯片的布局、确切内容和一个简短的设计说明。
• 程序员从 brief 中取出某一页的规格，编写绘制该页的 pptxgenjs JavaScript，之前先给出它的推理过程。

每个角色现在只做一类决策：设计师负责编辑判断，编码者负责几何布局。两者之间的简报是可读且可编辑的，因此人或智能体可以只修改某一张幻灯片的布局，而不必重新生成整个演示文稿。而且由于每张幻灯片的上下文在编写任何代码之前就已固定，编码者的调用可以并行执行——每张幻灯片一个——这使得编码阶段快了约 6–7 倍。

我们用 LoRA 训练适配器，而不是全量微调：它在一个强大的基座模型之上教会一种格式和一项技能，而不会干扰基座已有的知识，同时也让每次实验都很廉价。一个教训是：编码者的样本大约是设计师样本的 5 倍长，因此简单的混合训练会导致设计师训练不足，直到我们将其样本过采样 5 倍才解决。

合成演示文稿及其推理

目前没有关于规划、设计决策和幻灯片代码的公开语料库，所以我们用一个大型的开放教师模型生成了一个。每个演示文稿都从一个配方开始，该配方设定其类型、长度、布局和任何用户指令，从而让我们控制数据的覆盖范围。规划从整洁的大纲到原始的内容堆砌不等，因此模型学会裁剪和精简。我们生成了大约 1000 份演示文稿，涵盖约 10,000 张幻灯片。

每个样本还附带其背后的推理，写成反事实的形式：推理轨迹会权衡一个备选方案并说明为何将其否决，从而让模型学到选择背后的规则，而不仅仅是选择本身。设计师对内容和形式进行推理。例如：

"四个季度的营收，呈现一个明显的上升趋势。我考虑过用表格，但这张幻灯片的重点是趋势而非精确数字，所以柱状图能让人一眼看清。"

编码者对几何布局进行推理：

"标题有 62 个字符。用 44pt 会折成三行并挤入下方的图表，所以我设为 36pt，正好两行，并在图表上方留出空间。"

光有教师模型并不能让数据变好；围绕它的循环才起作用。每个合成的演示文稿都会被渲染，并由 harness 在推理时使用的同一个检查器检测重叠和溢出。有问题的幻灯片会被修复，其推理也被改写成同样的反事实形式，说明原始布局错在哪里以及修复为何有效。检查器发现的每一个错误都成为更好的训练样本。

最棘手的问题是忠实性。最糟糕的失败是幻灯片包含输入中没有的事实，而我们发现提示规则无法阻止这一点。如果简报要求一个六行五列的表格，却只提供了三条要点，编码者就不得不编造其余内容。

真正解决问题的是参考演示文稿，而不是规则：修改参考文稿能可靠地改变教师模型的输出，而添加规则却很少奏效。教师模型在提示中看到几份参考演示文稿后，模仿它们的程度远高于遵循指令的程度。

用平实的英文引导演示文稿

用户常常希望对具体的设计选择有更细粒度的控制：用图表代替表格、指定某种颜色、更暗的封面。Palette 允许用户通过指令（directives）提出这些要求——直接写在规划中的简短说明，用 [[ ]] 包裹：

## 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 衡量的是一份幻灯片是否好，而不是它是否遵循某种特定的设计语言。据我们所知，目前还没有这样的基准测试，而这正是我们希望帮助弥补的一个空白。

下一步

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

我们还希望通过从源文档中提取图表（例如使用 Docling）并借助测试框架进行排版，来缩小图表密集型幻灯片与人工水平之间的差距。此外，我们正在探索一种更轻量的自定义模板方式：对你现有的一两个 .pptx 文件的输出进行换肤，而无需重新训练。

我们的心得

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

1. 把推理放进数据。训练时不仅包含做了什么选择，还包含为什么这样选择、以及放弃了哪些选项，这比只学选择本身更有价值。
2. 先修复示例，再添加规则。当教师模型出错时，我们的第一反应是往它的提示词里加规则，但很少奏效。教师模型对参考幻灯片的模仿远多于对指令的遵循，所以修复参考内容才是真正改变其输出的做法。
3. 让修复默认安全。只有当修复在可衡量的程度上确实有帮助时才予以保留，这样的修复机制才能在每一次输出上运行。
4. 先构建校验器。正是它让数据变得可信，让输出得以安全发布。