Palette: teaching a small model to build decks in your design language

本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

Palette: teaching a small model to build decks in your design language

Palette：教导小型模型使用您的设计语言制作演示文稿

Ask a frontier model for a slide deck and you’ll get a good one. Ask for ten and they start to look alike: the same tasteful defaults, the same house style, a faint “AI-generated deck” look. That’s fine until you want the deck to look like your template. Frontier models have their own house style, and no amount of prompting stops them drifting back to it. And sometimes the content is confidential and can’t leave your systems at all. Both of those point to a model you own: open weights, running on your own infrastructure, trained on your own design language.

向尖端模型索要一份演示文稿，你会得到一份不错的作品。但如果索要十份，它们就会开始变得千篇一律：同样的默认设置、同样的风格，以及一种淡淡的“AI生成感”。这在您不需要演示文稿符合特定模板时尚可接受。尖端模型拥有其固有的风格，无论如何提示都无法阻止它们回归这种风格。此外，有时内容属于机密，不能离开您的系统。这两个原因都指向了您需要一个自主拥有的模型：开放权重、在自有基础设施上运行，并使用您自己的设计语言进行训练。

The catch is that small open models, the kind you’d actually self-host, are bad at this. Their decks come out broken: titles that vanish into the background, text running off the slide, shapes stacked on top of each other. Palette tests one bet: that a small open-weight model, trained on synthetic data in your design language and checked by a harness, can compete with frontier systems while you keep ownership of the result. We fine-tuned a 20B model to build decks the way people do: a designer plans the deck and a coder draws each slide. Its training data follows the IBM Design Language, and on PresentBench it ranks first on two of the three domains we measured. This post covers how we synthesized the data, trained the model and built a harness around it.

问题在于，适合自托管的小型开源模型在处理此类任务时表现不佳。它们生成的演示文稿往往存在缺陷：标题消失在背景中、文字超出幻灯片边界、图形相互重叠。Palette 验证了一个假设：一个使用您的设计语言合成数据进行训练，并由测试框架进行校验的小型开放权重模型，可以在保持结果所有权的同时，与尖端系统相媲美。我们微调了一个 20B 参数的模型，使其像人类一样制作演示文稿：由“设计师”规划文稿，由“编码员”绘制每一页幻灯片。其训练数据遵循 IBM 设计语言，在 PresentBench 测试中，我们在测量的三个领域中的两个领域排名第一。本文将介绍我们如何合成数据、训练模型并构建配套的测试框架。

Why decks are hard for small models: A slide deck looks simple, but making one asks a model to do three things small models are bad at. It lays out the slide without seeing it. The model doesn’t draw slides; it writes code that places every element at an x, y, width and font size. Whether a 75-character title fits on two lines at 56pt is arithmetic the model does in its head, and it only finds out it was wrong after the code renders. Small models get this wrong often, which is where overlapping shapes and text running off the slide come from. It makes two kinds of decisions at once. Deciding what each slide says and how to show it (a chart or a table? what to cut?) is editorial judgment. Placing it precisely is geometry. A single pass has to do both across 10–20 slides, while keeping the palette, type and layout consistent. There’s no data showing how decks get made. Plenty of finished decks exist, but not the rationale behind the design choices or the code that produced them.

为什么演示文稿对小型模型来说很难：演示文稿看起来很简单，但制作它需要模型完成三项小型模型不擅长的任务。首先，它在“看不见”幻灯片的情况下进行布局。模型并不直接绘制幻灯片，而是编写代码，将每个元素放置在特定的 x、y 坐标、宽度和字号上。一个 75 字符的标题在 56pt 字号下是否能排成两行，是模型在脑中进行的算术运算，只有在代码渲染后它才知道是否出错。小型模型经常出错，这就是图形重叠和文字溢出的原因。其次，它需要同时做出两种决策。决定每页幻灯片的内容及呈现方式（图表还是表格？删减什么？）属于编辑判断；而精确放置元素则属于几何问题。模型必须在 10 到 20 页幻灯片中一次性完成这两项任务，同时保持配色、字体和布局的一致性。目前没有关于演示文稿制作过程的数据。现成的演示文稿很多，但缺乏设计选择背后的逻辑或生成这些文稿的代码。

Build it like a human: a designer and a coder. Nobody makes a deck in one pass. You decide the story first (how many slides, what each one says, which gets a chart and which gets a table) and only then build each slide. Palette splits the work the same way, into two roles served by a single LoRA adapter: The designer reads the plan and writes a structured JSON brief: the palette, the type system, and for each slide its layout, its exact content and a short design rationale. The coder takes one slide’s spec from the brief and writes the pptxgenjs JavaScript that draws it, preceded by its reasoning. Each role now makes one kind of decision: the designer handles the editorial judgment, and the coder handles the geometry. The brief between them is readable and editable, so a person or an agent can change one slide’s layout without regenerating the deck. And because every slide’s context is fixed before any code is written, the coder calls run in parallel, one per slide, which makes the coding stage about 6–7× faster. We trained the adapter with LoRA rather than full fine-tuning: it teaches a format and a skill on top of a capable base without disturbing what the base already knows, and it made each experiment cheap. One lesson: coder examples are about 5× longer than designer examples, so a naive mix undertrained the designer until we oversampled its examples 5×.

像人类一样构建：设计师与编码员。没有人能一次性完成演示文稿。您首先要确定故事线（有多少页、每页说什么、哪页用图表、哪页用表格），然后再制作每一页。Palette 以同样的方式将工作拆分为两个角色，由同一个 LoRA 适配器提供支持：设计师阅读计划并编写结构化的 JSON 简报，包含配色、字体系统，以及每页幻灯片的布局、确切内容和简短的设计逻辑。编码员从简报中获取单页幻灯片的规范，并编写用于绘制它的 pptxgenjs JavaScript 代码，并在代码前附上推理过程。现在，每个角色只负责一种决策：设计师处理编辑判断，编码员处理几何布局。两者之间的简报是可读且可编辑的，因此人类或智能体可以在不重新生成整个文稿的情况下更改单页布局。由于每页幻灯片的上下文在编写代码前已固定，编码员可以并行运行，每页一个进程，这使编码阶段的速度提高了约 6 到 7 倍。我们使用 LoRA 而非全量微调来训练适配器：它在强大的基础模型之上教授格式和技能，而不干扰基础模型已有的知识，这使得每次实验的成本都很低。经验教训：编码员的示例比设计师的示例长约 5 倍，因此简单的混合训练会导致设计师部分训练不足，直到我们将设计师的示例过采样了 5 倍。

Synthesizing decks and their reasoning: There’s no public corpus of plans, design decisions and slide code, so we generated one with a large open teacher. Each deck starts from a recipe that sets its genre, length, layouts and any user directives, so we control what the data covers. Plans range from tidy outlines to raw content dumps, so the model learns to cut and condense. We generated around 1000 decks covering roughly 10,000 slides. Every example also carries the reasoning behind it, written as a counterfactual: the trace weighs an alternative and says why it was rejected, so the model learns the rule behind a choice, not just the choice. The designer reasons about content and form. For example: “Revenue for four quarters, with one clear upward trend. I considered a table, but the point of this slide is the trend, not the exact figures, so a bar chart makes it visible at a glance.” The coder reasons about geometry: “The title is 62 characters. At 44pt it would wrap to three lines and run into the chart below, so I set it at 36pt, which fits on two lines and leaves room above the chart.” The teacher alone doesn’t make the data good; the loop around it does. Every synthesized deck is rendered and checked for overlaps and overflow by the same checker the harness uses at inference. Broken slides are repaired, and their reasoning is rewritten as the same kind of counterfactual, covering what the original layout got wrong and why the fix works. Each mistake the checker catches becomes a better training example. The hardest problem was faithfulness. The worst failure is a slide with facts that weren’t in the input, and we found that a prompt rule can’t prevent it. If a brief asks for a six-by-five table but carries only three bullets, the coder has to invent the rest. What fixed it was reference decks, not the rules: fixing a reference reliably changed the teacher’s output, while adding a rule rarely did. The teacher sees a few reference decks in its prompt and copies them far more.

合成演示文稿及其推理过程：目前没有关于计划、设计决策和幻灯片代码的公开语料库，因此我们使用一个大型开放模型作为教师来生成数据。每个演示文稿都从一个设定了类型、长度、布局和用户指令的“配方”开始，从而控制数据的覆盖范围。计划从整洁的大纲到原始的内容堆砌不等，使模型学会如何删减和浓缩。我们生成了约 1000 份演示文稿，涵盖约 10,000 页幻灯片。每个示例都包含其背后的推理，以反事实的形式编写：追踪过程权衡了替代方案并说明了为何被拒绝，因此模型学习的是选择背后的规则，而不仅仅是选择本身。设计师对内容和形式进行推理。例如：“四个季度的收入，有一个明显的上升趋势。我考虑过使用表格，但这张幻灯片的重点是趋势而非确切数字，所以柱状图能让人一目了然。”编码员对几何布局进行推理：“标题有 62 个字符。在 44pt 字号下会换行成三行并与下方的图表重叠，所以我将其设为 36pt，这样可以排成两行，并在图表上方留出空间。”仅靠教师模型无法保证数据质量，循环校验机制才是关键。每个合成的演示文稿都会被渲染，并由推理阶段使用的同一个检查器进行重叠和溢出检查。损坏的幻灯片会被修复，其推理过程也会被重写为同样的反事实形式，涵盖原始布局的错误之处以及修复方案为何有效。检查器捕获的每一个错误都成为了更好的训练示例。最困难的问题是忠实度。最严重的失败是幻灯片中出现了输入中不存在的事实，我们发现提示词规则无法阻止这一点。如果简报要求一个六行五列的表格，但只提供了三个要点，编码员就不得不编造其余内容。解决这个问题的是参考文稿而非规则：固定一个参考文稿能可靠地改变教师的输出，而增加规则几乎无效。教师模型在提示词中看到几份参考文稿后，会更有效地进行模仿。