IBM 训练 20B 小模型 Palette 按自有设计语言生成幻灯片
Palette: teaching a small model to build decks in your design language
IBM 研究团队微调 20B 开源权重模型 Palette,采用设计师编写 JSON 简报、编码器逐页生成 pptxgenjs 代码的两角色 LoRA 方案,根据 IBM 设计语言生成幻灯片。
IBM 使用合成数据加检查修复闭环训练 20B 小模型制作幻灯片,提供可迁移到其他结构化产出的方法。
向前沿模型请求幻灯片演示文稿,你会得到一个不错的。请求十个,它们开始看起来都一样:相同雅致的默认设置,相同的公司风格,一种淡淡的“AI生成的演示文稿”的外观。直到你想让演示文稿看起来像 你 的模板。前沿模型有自己的公司风格,无论你如何提示,它们都会回到这种风格。而且有时内容是机密的,根本不能离开你的系统。
这两点都指向一个你拥有的模型:开源权重,运行在你自己的基础设施上,使用你自己的设计语言进行训练。问题是,小型开源模型,你实际上会自行托管的那种,在这方面表现不佳。它们的演示文稿会出问题:标题消失在背景中,文本超出幻灯片,形状堆叠在彼此之上。
调色板 测试了一个赌注:一个小型开源权重模型,使用你自己的设计语言中的合成数据进行训练,并由一个测试框架进行检查,能否在与前沿系统竞争的同时保持对结果的所有权。我们对一个 20B 模型进行了微调,以像人们实际做的那样构建演示文稿:设计师规划演示文稿,程序员绘制每一张幻灯片。其训练数据遵循 IBM 设计语言,在 PresentBench 上,我们在测量的三个领域中两个领域排名第一。本文涵盖了我们如何合成数据、训练模型并在其周围构建一个测试框架。
小型模型为何难以制作演示文稿
幻灯片演示文稿看起来很简单,但要制作一个,需要模型做三件事,而小型模型在这三件事上都表现不佳。
它在看不见幻灯片的情况下布局幻灯片。 模型不绘制幻灯片;它编写代码,将每个元素放置在 x、y、宽度和字体大小上。一个 75 个字符的标题是否适合在 56 磅字体下分成两行是模型在脑海中进行的算术,只有代码渲染后才知道自己错了。小型模型经常做错这一点,这就是形状重叠和文本超出幻灯片的原因。
它同时做出两种类型的决定。 决定每张幻灯片的内容以及如何展示它(图表还是表格?什么要被删减?)是编辑判断。精确放置是几何学。一次遍历必须在 10-20 张幻灯片中同时完成这两件事,同时保持调色板、类型和布局的一致性。
没有数据显示演示文稿是如何制作的。 许多完成的演示文稿存在,但没有设计选择背后的推理或生成它们的代码。
像人类一样构建:设计师和程序员
没有人一次就能制作演示文稿。你首先决定故事(有多少张幻灯片,每张幻灯片说什么,哪张需要图表,哪张需要表格),然后才构建每张幻灯片。调色板以相同的方式分割工作,由一个单个 LoRA 适配器执行的两个角色:
- 设计师阅读计划并编写结构化的 JSON 简报:调色板、类型系统,以及对于每张幻灯片,它的布局、它的确切内容和简短的设计推理。
- 程序员从简报中获取一张幻灯片的规范,并编写绘制它的 pptxgenjs JavaScript,前面是它的推理。
每个角色现在只做一种决策:设计师负责编辑判断,而编码员负责几何处理。他们之间的简报是可读和可编辑的,因此一个人或代理可以更改一个幻灯片的布局而无需重新生成整个演示文稿。并且因为每个幻灯片的上下文在编写任何代码之前都是固定的,所以编码员并行运行,每个幻灯片一个,这使得编码阶段大约快6-7倍。
我们用LoRA而不是完整微调来训练适配器:它在强大的基础上教授格式和技能,而不会干扰基础已经知道的内容,并且它使每个实验都变得廉价。一个教训:编码器示例大约是设计师示例的5倍长,所以一个天真的混合方式在未训练设计师的情况下过度训练了它,直到我们将其示例过采样了5倍。
合成演示文稿及其推理
没有公开的计划、设计决策和幻灯片代码语料库,所以我们用一个大型开放教师生成了一个。每个演示文稿从一个食谱开始,该食谱设置其类型、长度、布局和任何用户指令,因此我们控制了数据涵盖的内容。计划范围从整洁的提纲到原始的内容倾倒,所以模型学习剪切和压缩。我们生成了大约1000个演示文稿,涵盖大约10000个幻灯片。
每个示例还携带其背后的推理,以反事实的形式编写:跟踪权衡一个替代方案并说明它被拒绝的原因,所以模型学习选择背后的规则,而不仅仅是选择。设计师对内容和形式进行推理。例如:
"四个季度的收入,有一个清晰的上行趋势。我考虑过表格,但这个幻灯片的重点是趋势,而不是确切数字,所以条形图使其一目了然."
编码员对几何进行推理:
"标题是62个字符。在44pt时它会换到三行,并会与下面的图表冲突,所以我将其设置为36pt,这样它可以放在两行上,并在图表上方留出空间."
单独的教师并不能使数据变得良好;围绕它的循环才能。每个合成的演示文稿都由与推理时 harness 使用的相同检查器进行渲染和检查,以检查重叠和溢出。损坏的幻灯片被修复,并且它们的推理被重写为相同类型的反事实,涵盖原始布局出错的原因以及修复为何有效。检查器捕获的每个错误都变成了更好的训练示例。
最难的问题是忠实度。最糟糕的失败是一个包含输入中未提及事实的幻灯片,我们发现提示规则无法防止这种情况。如果简报要求一个六乘五的表格但只包含三个要点,编码员必须编造其余部分。
使其得到解决的是参考演示文稿,而不是规则:修复参考可靠地改变了教师的输出,而添加规则很少这样做。教师在其提示中看到几个参考演示文稿,并比遵循指令更多地复制它们。
用纯英语引导演示文稿
用户通常希望对特定的设计选择进行更细粒度的控制:图表而不是表格、特定的颜色、更深的封面。调色板让他们可以用 指令 来请求这些,这些是直接写在计划中并用 [[ ]] 包装的简短指令:
## 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个类别的指令,其中一些如下所示,每种表达方式都不同,因此模型学习意图而不是固定短语。
| 类别 | 示例指令 |
|---|---|
| 布局 | [[make this a timeline]] |
| 语气 | [[be candid, no spin]] |
| 受众 | [[this is for the board]] |
| 顺序 | [[lead with the ask]] |
| 省略 | [[no pricing]] |
| 强调 | [[highlight the headline number]] |
图1。同一个计划的插图,没有(左)和有(右)[[make this a timeline]]指令。
构建检查和修复 harness
即使是训练良好的模型有时也会产生一个损坏的幻灯片:标题与背景颜色相同,或者两个盒子堆叠在一起。因此,Palette不会直接返回模型的输出;每个演示文稿都首先通过一个harness。
图2。设计师起草简报,编码器并行编写每个幻灯片的代码,并且harness在演示文稿返回之前检查和修复每个幻灯片。
首先,简单的规则修复已知的错误,例如一个格式错误的颜色代码,否则会使每个幻灯片变黑。然后每个幻灯片被渲染和测量:一个几何检查器标记重叠的文本,被剪切或超出幻灯片的文本。标记的幻灯片被发送到另一个编辑器模型,该模型重写该幻灯片的代码。
关键规则是,只有当检查器确认幻灯片改进时才保留重写;否则原始内容保持不变。这使得harness可以在每个演示文稿上安全运行。它可以修复一个幻灯片,但不能使其变得更糟。
图3。一个修复的插图。如生成(左),每张卡片的标题堆叠在其描述之上;harness检测到重叠并重新排列卡片为2×2网格(右)。
为了衡量其效果,我们一次生成每个PresentBench演示文稿,并使用和未使用harness对其进行评分。在131个演示文稿中,harness平均增加3.5分。
评估
我们在PresentBench上评估,它根据五个标准对生成的演示文稿进行评分:基础知识、视觉设计、完整性、正确性和保真度。PresentBench提供一个源文档而不是计划,因此在这些运行中,一个单独的前沿模型从其文档中起草每个计划,并且Palette从该计划构建演示文稿。我们报告三个领域;基线数字来自PresentBench论文。
图4。PresentBench按领域的评分。Palette(蓝色)对NotebookLM、Manus 1.6和五个其他系统(灰色)。Palette在经济学和教育领域排名第一,在谈话领域排名第三,在三个领域平均值排名第二。
Palette在结构化内容和数值准确性决定分数的地方表现最好,在经济学和教育领域排名第一。在谈话领域,其中演示文稿是叙事和语音驱动的,两个封闭系统得分更高,Palette排名第三。在三个领域它排名第二,1.1分落后于NotebookLM(59.7 vs 60.8),并且领先于其他领域,作为一个单一的20B开放权重模型。
PresentBench衡量一个演示文稿是否好,但不是它是否遵循特定的设计语言。我们不知道有任何基准,这是一个我们希望帮助弥补的差距。
下一步是什么
这个 harness 已经能计算廉价且可验证的信号:幻灯片是否渲染正常,是否有重叠或溢出,每个事实是否都能追溯到简要说明。如今我们使用它们来修复生成后的输出。下一步,我们希望将这些检查用作强化学习的奖励,以便模型从一开始就停止犯这些错误。因为编码人员一次处理一个幻灯片,每个幻灯片都是一个短小且可独立检查的 rollout,非常适合 GRPO 风格的训练。
我们还希望通过从源文档中提取图形(例如使用 Docling)并将它们放置到 harness 中来缩小图形密集型幻灯片的差距。我们还在探索一种更轻量级的方法来引入你自己的模板:重新包装你一个或两个现有的 .pptx 文件的输出,而无需重新训练。
我们学到的知识
Building Palette 教会了我们一些有效的方法,这些方法自然地扩展到其他任务,这些任务的输出可以在代码中检查结构,从图表和图表到 UI 布局:
- 将推理放在数据中。基于选择原因进行训练,包括被拒绝的内容,比仅选择本身教得多。
- 在添加规则之前先修复示例。当老师出错时,我们的第一反应是向其提示添加规则,这很少有帮助。老师更多地复制了其参考幻灯片而不是遵循指令,因此修复参考实际上是改变了其输出。
- 默认情况下使修复安全。只有当它能明显帮助时才保留的修复可以在每个输出上运行。
- 首先构建检查器。这是使数据可信并使输出安全可交付的关键。
来源: Hugging Face Blog · huggingface.co