IBM Research 发布 Palette：用 20B 开源模型按你的设计语言生成幻灯片

Hugging Face 社区博客·2026-11-04 00:35· 57 分钟前AI 评分59

Palette：教小模型用你的设计语言构建幻灯片

AI 导读

IBM Research 介绍 Palette，通过 LoRA 微调 20B 开源模型生成符合 IBM Design Language 的幻灯片，采用设计师加程序员的双角色分解，并配检查修复 harness。

正文 · 原文

让前沿模型做一份幻灯片，你会得到一份不错的成品。让它做十份，它们就开始变得千篇一律：同样雅致的默认样式、同样的品牌风格、隐约透出一股“AI 生成幻灯片”的味道。这本来没什么问题，直到你希望幻灯片看起来像你的模板。前沿模型有自己的品牌风格，无论怎么提示都无法阻止它们漂移回那种风格。而且有时内容属于机密，根本不能离开你的系统。

这两点都指向一个你自己拥有的模型：开放权重、运行在你自己的基础设施上、用你自己的设计语言训练。问题在于，小型开放模型——也就是你真正会自托管的那种——在这方面表现很差。它们生成的幻灯片会出问题：标题融入背景消失不见、文字跑出幻灯片、形状彼此堆叠。

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

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

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

它要在看不到幻灯片的情况下进行布局。模型并不直接绘制幻灯片；它编写代码，把每个元素放在指定的 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. 先构建检查器。正是它让数据可信、让输出可以安全交付。

来源：Hugging Face 社区博客 · huggingface.co