IBM 开源 Palette 小模型 定制企业风格 PPT 生成
IBM Research 推出 Palette，一种基于开源权重的小语言模型，专门用于在本地基础设施上生成符合特定企业设计语言的演示文稿。该方案旨在解决前沿大模型输出风格同质化及数据隐私泄露问题，通过“先构建检查器”和“安全修复机制”确保输出质量与指令遵循度。
报道正文
本文目录9 个章节
Palette：教一个小模型用你的设计语言制作演示文稿
企业级文章 发布于 2026 年 11 月 3 日 点赞 - Praveen Venkateswaran praveenv 关注 ibm-research Anupama Murthi anupamamurthi 关注 ibm-research Hamid Adebayo harmedox 关注 ibm-research
向一个前沿模型（frontier model）索要一份幻灯片，你会得到不错的结果。但如果你要十份，它们开始变得千篇一律：相同的精致默认设置、相同的固有风格，以及一种淡淡的“AI 生成感”。这在你希望幻灯片看起来像你的模板之前都还好。前沿模型有其固有的风格，无论怎么提示都无法阻止它们回归这种风格。而且有时内容属于机密，根本无法离开你的系统。
这两点都指向了一个你拥有的模型：开放权重、运行在你自己的基础设施上、并使用你自己的设计语言进行训练。问题在于，那些小型开源模型——也就是你实际上会自托管的那类——在这方面的表现很差。它们生成的幻灯片往往漏洞百出：标题融入背景看不见、文字溢出幻灯片边界、形状相互重叠堆叠。
Palette 验证了一个假设：一个小型开放权重模型，如果经过基于你的设计语言的合成数据训练，并由测试框架（harness）进行检查，就能在保持对成果所有权的同时与前沿系统竞争。我们对一个 20B 参数的模型进行了微调，使其像人类一样构建幻灯片：由设计师规划整体结构，由编码者绘制每一页幻灯片。其训练数据遵循 IBM 设计语言，并且在 PresentBench 基准测试中，在我们测量的三个领域中的两个排名第一。本文介绍了我们如何合成数据、训练模型并围绕它构建测试框架。
为什么幻灯片对小模型来说很难
幻灯片看起来很简单，但制作一张幻灯片要求模型完成三件小模型不擅长的事情。
它是在“盲写”幻灯片。 模型并不直接绘制幻灯片，而是编写代码，将每个元素定位在特定的 x、y 坐标，并设定宽度和字号。一个 75 字符的标题在 56pt 字号下是否能排成两行，是模型在脑海中进行的算术运算，而只有当代码渲染后，它才会发现算错了。小模型经常在这一步出错，这正是导致形状重叠和文字溢出幻灯片边界的原因。
它同时处理两类决策。 决定每张幻灯片的内容及其呈现方式（是用图表还是表格？该删减什么？）属于编辑判断；而精确放置元素则属于几何计算。单次生成必须在 10–20 张幻灯片中同时完成这两项任务，还要保持配色、字体和布局的一致性。
缺乏展示幻灯片制作过程的数据。 虽然存在大量成品演示文稿，但缺少支撑设计决策的理由以及生成这些内容的代码。
像人类一样构建：设计师与程序员
没有人能一次性做出完美的演示文稿。你首先确定故事线（多少张幻灯片、每张讲什么、哪张用图表、哪张用表格），然后才逐张构建。Palette 以同样的方式拆分工作，由单个 LoRA 适配器承担两个角色：
- 设计师阅读规划并编写结构化的 JSON 简报：包括调色板、字体系统，以及每张幻灯片的布局、确切内容和简短的设计理由。
- 程序员从简报中提取单张幻灯片的规格，编写用于绘制该幻灯片的 pptxgenjs JavaScript 代码，并在代码前附上推理过程。
现在每个角色只负责一类决策：设计师处理编辑判断，程序员处理几何计算。两者之间的简报清晰可读且可编辑，因此人或智能体可以修改某张幻灯片的布局，而无需重新生成整个演示文稿。此外，由于在编写任何代码之前，每张幻灯片的上下文都已固定，程序员的调用可以并行执行（每张幻灯片一次），这使得编码阶段的速度提升了约 6–7 倍。
我们使用 LoRA 而非全量微调来训练适配器：它在强大的基础模型之上教授一种格式和技能，而不干扰基础模型已有的知识，同时也让每次实验的成本更低。一个经验教训是：程序员的示例长度约为设计师示例的 5 倍，因此简单的混合训练会导致设计师欠拟合，直到我们将设计师的示例过采样 5 倍才解决这一问题。
合成演示文稿及其推理过程
由于目前不存在包含演示文稿规划、设计决策和幻灯片代码的公开语料库，我们利用一个大型开源教师模型生成了这样一个数据集。每个演示文稿都始于一份“配方”，其中定义了其类型、长度、布局以及任何用户指令，从而让我们能够控制数据所涵盖的范围。规划内容从整洁的大纲到原始的内容堆砌不等，因此模型学会了如何删减和精简内容。我们生成了约 1000 个演示文稿，涵盖了大约 10,000 张幻灯片。
每个示例还附带了其背后的推理过程，并以反事实（counterfactual）的形式呈现：推理轨迹会权衡一种替代方案并说明为何拒绝它，从而使模型学会选择背后的规则，而不仅仅是选择本身。设计师会对内容和形式进行推理。例如：
“四个季度的营收数据，呈现出一个明显的上升趋势。我考虑过使用表格，但这张幻灯片的重点在于趋势而非具体数值，因此柱状图能让趋势一目了然。”
编码员则会对几何布局进行推理：
“标题有 62 个字符。如果设置为 44pt，它会换行成三行并与下方的图表重叠，所以我将其调整为 36pt，这样既能容纳在两行内，又能在图表上方留出空间。”
仅靠教师模型并不能保证数据的质量；围绕它的闭环流程才是关键。每个合成的演示文稿都会经过渲染，并由与推理阶段使用的相同检查器来检测重叠和溢出问题。损坏的幻灯片会被修复，其推理过程也会被重写为同类型的反事实描述，涵盖原始布局错在哪里以及修复为何有效。检查器捕捉到的每一个错误，都转化为更好的训练样本。
最难解决的问题是忠实度（faithfulness）。最糟糕的情况是幻灯片包含了输入中不存在的事实，我们发现仅靠提示词中的规则无法防止这种情况。如果简报要求一个六行五列的表格，但只提供了三个要点，编码员就必须自行编造其余内容。
真正解决问题的是参考演示文稿（reference decks），而不是规则：提供固定的参考演示文稿能可靠地改变教师模型的输出，而添加规则很少起作用。教师模型在提示词中看到几个参考演示文稿后，模仿它们的程度远高于遵循指令的程度。
用通俗英语引导演示文稿
用户通常希望对特定的设计选择拥有更细粒度的控制权：比如用图表代替表格、指定某种颜色或加深封面色调。Palette 允许他们通过 directives（指令）提出这些要求，即直接写在规划中并用 [[ ]] 包裹的简短说明：
## 发布计划
- 3月：两个团队试点
- 5月：安全审查完成
- 7月：推广至整个工程部门
- 9月：全公司上线
- 11月：首次采用情况回顾
[[将此内容转换为时间线]]设计师将每条指令融入简报中，编码员在绘制幻灯片时遵循这些指令。如果没有该指令，模型会合理地以表格形式展示这些里程碑；有了该指令，模型则会改为绘制时间线。
模型之所以遵循指令，是因为它在训练过程中被如此教导。数据配方包含了来自 12 个类别的指令，其中部分示例如下所示。每个类别都采用了多种不同的措辞方式，以便模型学习其意图而非固定的短语。
| 类别 | 指令示例 |
|---|---|
| 布局 | [[将此内容转换为时间线]] |
| 语气 | [[直言不讳，避免粉饰]] |
| 受众 | [[这是给董事会看的]] |
| 顺序 | [[先提出请求]] |
| 省略 | [[不要包含定价信息]] |
| 强调 | [[突出显示标题数字]] |
图 1. 同一计划在未使用（左）和使用（右）[[将此内容转换为时间线]] 指令时的对比示意图。
构建检查与修复框架
即使经过良好训练的模型，有时也会生成有缺陷的幻灯片：例如标题颜色与背景相同，或者两个方框重叠堆叠。因此，Palette 不会直接返回模型的输出；每份演示文稿都会先经过一个处理框架。
图 2. 设计师起草简报，编码员并行编写每张幻灯片的代码，处理框架在返回演示文稿前对每张幻灯片进行检查和修复。
首先，简单的规则用于修正已知错误，例如格式错误的颜色代码可能导致所有幻灯片变成黑色。然后，系统会对每张幻灯片进行渲染和测量：几何检查器会标记出文本重叠、被裁剪或超出幻灯片边界的情况。被标记的幻灯片会被发送给一个独立的编辑模型，由该模型重写对应幻灯片的代码。
核心规则在于：只有当检查器确认幻灯片质量有所提升时，才会保留重写后的版本；否则将维持原样。这使得该测试框架（harness）可以安全地应用于每一套演示文稿。它能够修复某张幻灯片，但绝不会使其变得更差。
图 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 vs 60.8），并领先于其他所有系统——值得注意的是，这仅是一个拥有 200 亿参数的开源权重模型所取得的成果。
PresentBench 能够衡量演示文稿的质量优劣，但无法判断其是否遵循特定的设计语言。据我们所知，目前尚无涵盖此方面的基准测试，而这正是我们希望协助填补的空白。
下一步计划
harness 已经能够计算廉价且可验证的信号：幻灯片是否成功渲染、是否存在重叠或溢出、以及每个事实是否都能追溯到简报。目前，我们利用这些信号在生成后修复输出。接下来，我们希望将同样的检查机制作为强化学习的奖励信号，从而让模型从一开始就避免犯这类错误。由于 coder 是逐页处理幻灯片的，每一页都是一个简短且可独立验证的 rollout（轨迹），这非常适合 GRPO 风格的训练。
我们还希望缩小在处理图表密集型演示文稿时的差距，具体方法是从源文档中提取图表（例如使用 Docling），并通过 harness 进行放置。此外，我们正在探索一种更轻量级的“自带模板”方案：通过对一两个现有 .pptx 文件的输出进行重新皮肤化（re-skinning），而无需重新训练模型。
我们学到的经验
构建 Palette 让我们总结出几种行之有效的方法，这些方法可以自然地扩展到那些输出结构可通过代码验证的其他任务中，从图表和示意图到 UI 布局：
- 将推理过程融入数据。 在训练时不仅包含最终的选择，还包含做出该选择的理由（包括被拒绝的选项），比仅学习选择本身能带来更好的效果。
- 先修正示例，再添加规则。 当 teacher 模型出错时，我们的第一反应通常是往其 prompt 中添加一条规则，但这很少奏效。teacher 模型复制参考演示文稿的程度远高于遵循指令的程度，因此修正参考内容才是真正改变其输出的关键。
- 默认确保修复操作的安全性。 只有当修复措施能带来可衡量的改进时才予以保留，这样的策略可以在所有输出上安全运行。
- 先构建检查器。 它是确保数据可信以及输出可安全发布的基础。