IBM says its 20B slide-building model ranks second in a three-domain benchmark

IBM Research has described a 20-billion-parameter model trained to make slide decks in the IBM Design Language, reporting results close to NotebookLM on three benchmark domains. Published November 3, the Palette research pairs specialized training with automated repairs—but its evaluation also relied on a separate frontier model to turn source documents into plans.

Close to NotebookLM, not an end-to-end comparison

IBM reports that Palette placed first in Economics and Education and third in Talk on PresentBench. Its three-domain mean was 59.7, compared with NotebookLM’s 60.8. That put Palette second overall in this comparison, with its strongest results in domains where structured content and numeric accuracy drive the score.

The comparison has an important boundary. PresentBench supplies source documents, not ready-made deck plans. For IBM’s runs, a separate frontier model drafted those plans before Palette built the slides. The competing systems’ scores came from the PresentBench paper, rather than fresh baseline runs described in IBM’s post.

PresentBench assesses fundamentals, visual design, completeness, correctness and fidelity. It does not measure whether slides follow a specific design language—the central customization goal behind Palette. IBM says it knows of no benchmark that does. The post describes research, not a public release: it announces no availability, license or pricing.

One model, two different jobs

Palette separates editorial choices from precise placement. A designer role writes a structured brief covering colors, typography, slide layouts, exact content and design rationale. A coder role then turns each slide’s specification into JavaScript using pptxgenjs, the library that draws the slides. Both roles use the same trained adapter.

The intermediate brief is readable and editable, allowing a person or agent to change a slide’s layout without regenerating the deck. Because each slide’s context is settled before coding starts, the coding calls can run in parallel. IBM says this makes that stage about six to seven times faster.

The team used LoRA, a method for adapting a base model without retraining all its weights. A large open teacher model generated around 1,000 training decks containing roughly 10,000 slides. Examples included explanations of rejected alternatives: why a chart suited a trend better than a table, or why a title needed smaller type.

Training also taught Palette to follow short instructions inside double square brackets, such as asking for a timeline or omitting pricing. IBM found a harder problem in factual faithfulness: an underspecified table could push the coder to invent content. Improving the teacher’s reference decks worked more reliably than adding prompt rules.

A better model still needs a layout checker

Palette does not return raw model output. Its checking-and-repair system first applies rules for known errors, including malformed color codes. It then renders each slide and measures the layout for overlapping, clipped or overflowing text. Flagged slides go to a separate editor model that rewrites their code.

A rewrite is accepted only when the checker confirms an improvement; otherwise, the original survives. That safeguard is tied to what the checker measures, rather than a guarantee of overall slide quality. Across 131 PresentBench decks, IBM says the repair system added an average of 3.5 points compared with the same generated decks without it.

IBM’s next proposed step is to use those checks as training rewards, so Palette learns to avoid mistakes rather than repair them afterward. The researchers also want to improve figure-heavy decks by extracting images from source documents, and are exploring restyling output from one or two existing PowerPoint files without retraining.