Чи зможе 20B-модель створювати слайд-деки у вашому дизайн-стилі?

Чому малі моделі ламають деки

Слайд-дек виглядає просто. Але для його створення модель має вирішити три задачі, у яких малі моделі слабкі.

Модель розміщує елементи на слайді, не бачачи його. Вона пише код, що задає x, y, ширину та розмір шрифту для кожного об'єкта. Чи вміститься 75-символьний заголовок у два рядки при 56 пт — це арифметика, яку модель виконує «в голові». Помилку вона виявить лише після рендерингу. Малі моделі часто помиляються. Накладені фігури та текст, що вилізає за межі слайду — наслідок саме цього.

Відбуваються два види рішень одночасно. Визначити, що йде на кожен слайд і як це показати — редакційне судження. Розмістити все точно — геометрія. Один прохід має об'єднати обидва аспекти на 10–20 слайдах, зберігаючи палітру та типографію узгодженими. Компоновку треба тримати в межах єдиного стилю.

Ніде не показано, як саме створюються деки. Готових презентацій багато. Але обґрунтування дизайнерських виборів та код, що їх породив, — відсутні.

Розділ праці, як це роблять люди

Ніхто не робить дек за один прохід. Спочатку визначають історію. Потім будують кожен слайд. Palette ділить роботу так само — на дві ролі, які виконує один LoRA-адаптер.

Дизайнер читає план і пише структурований JSON-опис. У ньому — палітра, типографічна система, для кожного слайду: компоновка та точний контент. Коротке обґрунтування дизайну теж потрапляє в опис. Кодер бере специфікацію одного слайду і пише JavaScript для pptxgenjs, що малює його. Тепер кожна роля приймає лише один вид рішень. Дизайнер — редакційне судження. Кодер — геометрія.

Опис між ними читабельний і редагований. Людина або агент може змінити компоновку одного слайду без регенерації всього деку. Оскільки контекст кожного слайду фіксується до написання коду, виклики кодера працюють паралельно. Один на слайд. Це прискорює етап кодування у 6–7 разів.

Навчання використовувало LoRA, а не повне донавчання. Це вчить формат і навичку поверх потужної базової моделі, не порушуючи те, що вона вже вміє. Кожен експеримент залишався дешевим. Один урок: приклади для кодера у 5 разів довші за приклади для дизайнера. Наївне змішування не дало дизайнеру досить уваги, поки команда не переважила його приклади у 5 разів.

Синтетичні дані та ремонтна система

Публічного корпусу планів, дизайнерських рішень і коду слайдів не існує. Команда згенерувала його за допомогою великої open-моделі-вчителя. Кожен дек починається з рецепта, що задає жанр, довжину, компоновки та директиви користувача. Плани — від чистих конспектів до сирих вивантажень контенту. Модель вчиться скорочувати та стискати.

Згенеровано близько 1000 деків, що охоплюють приблизно 10 000 слайдів. Кожен приклад несе рассудження, записане як контрфактуальний сценарій. Трейс розглядає альтернативу і пояснює, чому її відхилили. Модель вчиться правилу за вибором, а не лише самому вибору.

Контент і форма — турбота дизайнера. Геометрія — домен кодера. Сама по собі вчителька не робить дані якісними. Цикл навколо неї — так. Кожен синтетичний дек відображається і перевіряється на накладання та вихід за межі тим самим валідатором, що працює на інференсі. Зламані слайди ремонтуються. Їх рассудження переписуються як той самий контрфактуаль: що початкова компоновка зламала і чому виправлення працює. Кожна помилка, що ловить перевірка, стає кращим навчальним прикладом.

Вірність вихідним даним — найскладніша проблема. Найгірша помилка — слайд з фактами, яких не було на вхіді. Правило в промпті не може це запобігти. Якщо опис просить таблицю 6 на 5, а несе лише три пункти, кодер змушений вигадати решту. Виправило це еталон-деки, а не правила. Виправлення еталону надійно змінювало вивід вчителя. Додавання правила — рідко. Вчитель бачить кілька еталон-деків у промпті і копіює їх набагато частіше, ніж слідує інструкціям.

Керування простими англійськими директивами

Користувачі хочуть тонший контроль над окремими дизайнерськими виборами. Діаграма замість таблиці. Конкретний колір. Темніша титульна сторінка. Palette дозволяє просити це директивами. Короткі інструкції, написані безпосередньо у плані і обгорнуті у [[ ]].

Директиви потрапляють у опис через дизайнера. Кодер слідує їм при малюванні слайду. Без директиви модель розумно показала б етапи як таблицю. З нею — малює таймлайн. Модель слідує директивам, бо навчалася на цьому. Рецепти даних включають директиви з 12 категорій. Кожна сформульована кількома різними способами, щоб модель вчилася наміру, а не фіксованій фразі.

Перевірка-виправлення система

Навіть добре натренована модель іноді видає зламаний слайд. Заголовок того ж кольору, що фон. Два блоки, накладені один на один. Palette не повертає вивід моделі безпосередньо. Кожен дек проходить через систему.

Прості правила виправляють відомі помилки. Некоректний код кольору, що інакше зафарбовував би всі слайди в чорний. Потім кожен слайд відображається і вимірюється. Геометричний валідатор позначає текст, що накладається, обрізається або вилізає за межі. Позначені слайди йдуть до окремого редакторського моделі, яке переписує код цього слайду. Ключове правило: переписування зберігається лише якщо валідатор підтверджує покращення. Інакше залишається оригінал. Це робить систему безпечною для запуску на кожному деку. Вона може виправити слайд. Не може зробити гірше.

Щоб вимірити ефект, команда згенерувала кожен дек PresentBench раз і оцінила з системою і без. На 131 деку система додає в середньому 3,5 бали.

Оцінка на PresentBench

Згенеровані деки оцінюють за п'ятьма критеріями: Основи, Візуальний дизайн, Повнота, Коректність, Вірність. PresentBench надає вихідний документ, а не план. Для цих запусків окрема frontier-модель склала план з документа. Palette збудувала дек з цього плану.

Palette перша за Economics і Education. Третя за Talk. Друга за середнім по трьох доменах. Palette найкраща там, де рішають структурований контент і числова точність. На Talk, де деки наративні і орієнтовані на промову, дві закриті системи вищі. За трьома доменами Palette друга, відстає від NotebookLM на 1,1 бала (59,7 проти 60,8) і перевершує решту поля як єдина 20B open-weight модель.

Бенчмарк вимірює, чи дек хороший. Не чи слідує він конкретній дизайн-мові. Команда не знає тесту, що це робить. Ця прогалина залишається.

Що далі

Система вже обчислює дешеві верифіковані сигнали. Чи відображається слайд. Чи є накладання чи вихід за межі. Чи кожен факт слідує з опису. Сьогодні вони ремонтують вивід після генерації. Далі хочуть використовувати ті самі перевірки як нагороди для reinforcement learning. Щоб модель перестала робити ці помилки на етапі генерації. Оскільки кодер працює по одному слайду, кожен слайд — короткий незалежно перевірюваний роллаут. Природний фіт для GRPO-стилю навчання.

Також хочуть закрити прогалину на фігуро-насичених деках, витягуючи фігури з вихідних документів через Docling і розміщуючи їх системою. І досліджують легший спосіб принести власні шаблони. Рескін виводу з одного- двох ваших .pptx файлів без перенавчання.

Чому навчився проект

Створення Palette вивчило кілька ефективних методів, що поширюються на інші задачі, де вивід має структуру, перевіряємому в коді. Графіки. Діаграми. UI-компоновки.

Кладіть рассудження в дані. Навчання на тому, чому прийнято рішення, включаючи те, що відхилено, вчить більше за сам вибір. Виправляйте приклади перед додаванням правила. Коли в