Palette: как обучить маленькую модель создавать презентации в вашем стиле

Попросите передовую языковую модель (LLM) создать презентацию, и вы получите качественный результат. Но если вы попросите создать десять таких презентаций, они начнут выглядеть одинаково: одни и те же тактичные настройки по умолчанию, один и тот же «домашний стиль» и едва заметный оттенок «сгенерировано ИИ». Это нормально, пока вам не нужно, чтобы слайды выглядели именно так, как в вашем корпоративном шаблоне. У передовых моделей есть свой собственный стиль, и никакие промпты не могут навсегда отвлечь их от него. Кроме того, иногда контент является конфиденциальным и вообще не должен покидать вашу инфраструктуру.

Оба этих факта указывают на необходимость модели, которой вы владеете: с открытыми весами, работающей на вашей собственной инфраструктуре и обученной на вашем собственном дизайн-языке. Проблема в том, что маленькие открытые модели, которые вы действительно можете развернуть самостоятельно, плохо справляются с этой задачей. Их презентации часто оказываются сломанными: заголовки растворяются в фоне, текст вылезает за пределы слайда, фигуры накладываются друг на друга.

Palette — это проверка одной гипотезы: может ли маленькая открытая модель, обученная на синтетических данных в вашем дизайн-языке и проверенная с помощью специальной системы контроля, конкурировать с передовыми системами, сохраняя при этом полный контроль над результатом. Мы дообучили модель объемом 20 миллиардов параметров (20B) так, чтобы она создавала презентации так, как это делают люди: дизайнер планирует структуру, а программист рисует каждый слайд. Ее обучающие данные следуют стандартам IBM Design Language, и на бенчмарке PresentBench она заняла первое место в двух из трех измеренных нами доменов. В этой статье мы подробно разберем, как мы синтезировали данные, обучили модель и построили вокруг нее надежную систему контроля качества.

01Почему презентации — это сложно для маленьких моделей

Презентация выглядит простой, но ее создание требует от модели выполнения трех задач, с которыми маленькие модели справляются плохо. Во-первых, модель должна расположить элементы на слайде, не видя его визуально. Модель не рисует слайды напрямую; она пишет код, который размещает каждый элемент по координатам x, y, с определенной шириной и размером шрифта. Вопрос о том, поместится ли заголовок из 75 символов на две строки при размере 56pt, — это арифметика, которую модель прокручивает в уме, и она узнает об ошибке только после того, как код будет отрендерен. Маленькие модели часто ошибаются в этом, что и приводит к наложению фигур и вылезанию текста за пределы слайда.

Во-вторых, модель должна принимать два вида решений одновременно. Решение о том, что должно быть на каждом слайде и как это показать (график или таблица? что вырезать?) — это редакторское суждение. Размещение элементов точно — это геометрия. Один проход должен выполнить оба типа задач для 10–20 слайдов, сохраняя при этом согласованность палитры, типографики и макета. В-третьих, отсутствуют данные, показывающие, как презентации создаются на самом деле. Существует множество готовых презентаций, но нет данных о причинах дизайнерских решений или коде, который их произвел.

02Строим как человек: дизайнер и программист

Никто не делает презентацию за один проход. Сначала вы решаете историю (сколько слайдов, что говорит каждый из них, где нужна диаграмма, а где таблица), и только затем строите каждый слайд. Palette разделяет работу именно так, на две роли, обслуживаемые одним адаптером LoRA:

• Дизайнер читает план и пишет структурированный JSON-бриф: палитру, систему типов, а для каждого слайда — его макет, точное содержание и краткое дизайнерское обоснование.
• Программист берет спецификацию одного слайда из брифа и пишет JavaScript-код на pptxgenjs, который рисует его, предваряя это своим рассуждением.

Каждая роль теперь принимает только один вид решений: дизайнер занимается редакторским суждением, а программист — геометрией. Бриф между ними читаем и редактируем, поэтому человек или агент может изменить макет одного слайда без перегенерации всей презентации. И поскольку контекст каждого слайда фиксируется до начала написания кода, вызовы программиста можно запускать параллельно, по одному на слайд, что делает этап кодирования примерно в 6–7 раз быстрее.

Мы обучили адаптер с помощью LoRA (Low-Rank Adaptation), а не полного дообучения: это учит формату и навыку поверх способной базовой модели, не нарушая того, что база уже знает, и делает каждый эксперимент дешевым. Один важный урок: примеры для программиста примерно в 5 раз длиннее примеров для дизайнера, поэтому наивное смешивание недообучало дизайнера, пока мы не увеличили выборку его примеров в 5 раз.

03Синтез презентаций и их обоснования

Публичного корпуса данных, содержащего планы, дизайнерские решения и код слайдов, не существует, поэтому мы сгенерировали его с помощью большой открытой модели-учителя. Каждая презентация начинается с рецепта, который задает ее жанр, длину, макеты и любые пользовательские директивы, так что мы контролируем, какие данные охватываются. Планы варьируются от аккуратных outlines до сырых выгрузок контента, поэтому модель учится сокращать и конденсировать. Мы сгенерировали около 1000 презентаций, охватывающих примерно 10 000 слайдов.

Каждый пример также содержит обоснование, написанное в виде контрфактуального анализа: трассировка взвешивает альтернативу и говорит, почему она была отвергнута, так что модель учит правило за выбором, а не просто сам выбор. Дизайнер рассуждает о содержании и форме. Например:

Программист рассуждает о геометрии:

Сама по себе модель-учитель не делает данные хорошими; это делает цикл вокруг нее. Каждая синтезированная презентация рендерится и проверяется на перекрывания и переполнения тем же чекером, который использует система контроля при выводе. Сломанные слайды ремонтируются, и их обоснование переписывается в том же виде контрфактуального анализа, охватывая то, что оригинальный макет сделал неправильно, и почему исправление работает. Каждая ошибка, которую ловит чекер, становится лучшим обучающим примером.

Самой сложной проблемой была верность фактам. Худший сбой — это слайд с фактами, которых не было во входных данных, и мы обнаружили, что правило в промпте не может этого предотвратить. Если бриф просит таблицу 6x5, но содержит только три пункта, программисту приходится придумывать остальные. То, что это исправляло, — это эталонные презентации, а не правила: исправление эталона надежно меняло вывод учителя, тогда как добавление правила редко помогало. Учитель видит несколько эталонных презентаций в своем промпте и копирует их гораздо больше, чем следует инструкциям.

04Управление презентацией на обычном английском

Пользователи часто хотят более тонкого контроля над конкретными дизайнерскими решениями: график вместо таблицы, определенный цвет, более темная обложка. Palette позволяет запрашивать это с помощью директив — коротких инструкций, написанных непосредственно в плане и обернутых в [[ ]] .

## 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 категорий, некоторые из которых показаны ниже, каждая сформулирована несколькими разными способами, так что модель учит намерение, а не фиксированную фразу.

05Построение системы контроля и ремонта

Даже хорошо обученная модель иногда создает сломанный слайд: заголовок того же цвета, что и фон, или две фигуры, наложенные друг на друга. Поэтому Palette не возвращает вывод модели напрямую; каждая презентация сначала проходит через систему контроля.

Во-первых, простые правила исправляют известные ошибки, такие как некорректный код цвета, который в противном случае сделал бы все слайды черными. Затем каждый слайд рендерится и измеряется: геометрический чекер отмечает текст, который перекрывается, обрезается или вылезает за пределы слайда. Отмеченные слайды отправляются в отдельную модель-редактор, которая переписывает код этого слайда.

Ключевое правило заключается в том, что переписанный код сохраняется только если чекер подтверждает, что слайд улучшился; в противном случае остается оригинал. Это делает систему контроля безопасной для запуска на любой презентации. Она может исправить слайд, но не может сделать его хуже. Для измерения ее эффекта мы сгенерировали каждую презентацию PresentBench один раз и оценили ее с системой контроля и без нее. В среднем по 131 презентации система контроля добавляет 3.5 балла.

06Оценка

Мы оцениваем работу на PresentBench, который оценивает сгенерированные презентации по пяти критериям: основы, визуальный дизайн, полнота, правильность и верность. PresentBench предоставляет исходный документ, а не план, поэтому для этих запусков отдельная передовая модель составила каждый план из его документа, а Palette построила презентацию на основе этого плана. Мы сообщаем о трех доменах; базовые числа взяты из статьи PresentBench.

Palette лучше всего справляется там, где структурированный контент и числовая точность определяют оценку, занимая первое место в экономике и образовании. В домене «Talk», где презентации нарративны и основаны на речи, две закрытые системы показывают более высокие результаты, и Palette занимает третье место. В среднем по трем доменам она занимает второе место, уступая NotebookLM на 1.1 балла (59.7 против 60.8) и опережая остальную часть поля как единая открытая модель с 20 миллиардами параметров.

PresentBench измеряет, хороша ли презентация, но не то, следует ли она конкретному дизайн-языку. Нам неизвестно о бенчмарке, который это делает, и это пробел, который мы надеемся помочь закрыть.

07Что это значит на практике

Построение Palette научило нас нескольким эффективным методам, которые естественно расширяются на другие задачи, чей вывод имеет структуру, которую можно проверить в коде, от диаграмм и схем до макетов пользовательских интерфейсов. Во-первых, включайте обоснование в данные. Обучение тому, почему было сделано определенное решение, включая то, что было отвергнуто, учит больше, чем сам выбор. Во-вторых, исправляйте примеры перед добавлением правил. Когда учитель ошибался, нашей первой инстинктивной реакцией было добавить правило в его промпт, и это редко помогало. Учитель копировал свои эталонные презентации гораздо больше, чем следовал инструкциям, поэтому исправление эталона было тем, что фактически меняло его вывод.

В-третьих, делайте ремонты безопасными по умолчанию. Исправление, которое сохраняется только тогда, когда оно измеримо помогает, может запускаться на любом выводе. В-четвертых, стройте чекер первым. Именно он делает данные надежными, а выводы безопасными для отправки. В будущем мы хотим использовать те же проверки в качестве вознаграждений для обучения с подкреплением, чтобы модель перестала допускать эти ошибки с самого начала. Поскольку программист работает по одному слайду за раз, каждый слайд является короткой, независимо проверяемой разверткой, что является естественным подходом для обучения стиля GRPO. Мы также хотим закрыть разрыв в презентациях с большим количеством фигур, извлекая фигуры из исходных документов (например, с помощью Docling) и размещая их с помощью системы контроля. И мы исследуем более легкий способ привнесения ваших собственных шаблонов: перекрашивание вывода из одного или двух ваших существующих файлов .pptx без переобучения.

Источник: Hugging Face ↗