Попросите передовую модель сделать презентацию, и вы получите хороший результат. Попросите десять — и они начнут выглядеть одинаково: те же аккуратные шаблоны по умолчанию, тот же фирменный стиль, едва уловимый оттенок «презентации, созданной ИИ». Это нормально, пока вы не захотите, чтобы презентация выглядела в точности как ваш шаблон. У передовых моделей есть собственный стиль, и никакие промпты не заставят их прекратить возвращаться к нему. К тому же иногда контент является конфиденциальным и вообще не должен покидать ваши системы.
Все это указывает на необходимость модели, которой владеете вы сами: с открытыми весами, работающей на вашей инфраструктуре и обученной вашему языку дизайна. Подвох в том, что небольшие открытые модели, которые вы действительно могли бы разместить на собственных серверах, плохо с этим справляются. Их презентации получаются испорченными: заголовки сливаются с фоном, текст вылезает за пределы слайда, фигуры накладываются друг на друга.
Palette проверяет одну гипотезу: небольшая модель с открытыми весами, обученная на синтетических данных в вашем фирменном стиле и проверяемая специальным инструментом контроля, может конкурировать с передовыми системами, в то время как вы сохраняете контроль над результатом. Мы дообучили модель с 20 миллиардами параметров создавать презентации так, как это делают люди: дизайнер планирует презентацию, а кодер отрисовывает каждый слайд. Данные для ее обучения соответствуют IBM Design Language, а в тесте PresentBench она занимает первое место в двух из трех измеренных нами доменов. В этом посте рассказывается о том, как мы синтезировали данные, обучали модель и создали вокруг нее контролирующий инструмент.
Почему презентации даются небольшим моделям с трудом
Слайд-презентация выглядит просто, но ее создание требует от модели трех вещей, с которыми небольшие модели справляются плохо.
Она верстает слайд, не видя его. Модель не рисует слайды; она пишет код, который размещает каждый элемент по координатам x, y, с заданными шириной и размером шрифта. Поместится ли заголовок из 75 символов в две строки при кегле 57pt — это арифметическая задача, которую модель решает в уме, и она узнает об ошибке только после того, как код будет отрендерен. Небольшие модели часто ошибаются в этом, из-за чего и возникают накладывающиеся друг на друга фигуры и текст, выходящий за границы слайда.
Она принимает два типа решений одновременно. Решение о том, что говорит каждый слайд и как это показать (диаграмма или таблица? что сократить?) — это редакторская задача. Точное размещение элементов — это геометрия. Один проход должен выполнять и то, и другое для 10–20 слайдов, сохраняя при этом согласованность палитры, шрифтов и макета.
Нет данных о том, как создаются презентации. Существует множество готовых презентаций, но нет обоснования дизайнерских решений или кода, который их породил.
Создавайте их как человек: дизайнер и кодер
Никто не делает презентацию за один проход. Сначала вы определяете сюжет (сколько слайдов, о чем говорит каждый из них, для какого используется диаграмма, а для какого — таблица) и только потом собираете каждый слайд. Palette разделяет работу точно так же, на две роли, которые выполняет один адаптер LoRA:
- Дизайнер читает план и пишет структурированное техническое задание в формате JSON: палитру, типографику, а для каждого слайда — его макет, точное содержание и краткое обоснование дизайнерского решения.
- Кодер берет спецификацию одного слайда из ТЗ и пишет JavaScript, который отрисовывает его, предварительно приводя логику своего решения.
Теперь каждая роль принимает только один тип решений: дизайнер берет на себя редакторскую оценку, а кодер — геометрию. ТЗ между ними легко читается и редактируется, поэтому человек или агент может изменить макет одного слайда без пересоздания всей презентации. И поскольку контекст каждого слайда фиксируется до написания какого-либо кода, вызовы кодера выполняются параллельно, по одному на каждый слайд, что делает этап кодирования примерно в 6–7 раз быстрее.
Мы обучили адаптер с помощью LoRA, а не полного дообучения: это прививает формат и навык поверх способной базовой модели, не нарушая того, что базовая модель уже знает, и делает каждый эксперимент дешевым. Один из выводов: примеры для кодера примерно в 5 раз длиннее примеров для дизайнера, поэтому при наивном смешивании дизайнер получал недостаточное обучение, пока мы не увеличили количество его примеров в 5 раз.
Синтез презентаций и их логики
Не существует публичного корпуса планов, дизайнерских решений и кода слайдов, поэтому мы сгенерировали его с помощью большой открытой модели-учителя. Каждая презентация создается на основе рецепта, который задает ее жанр, длину, макеты и любые пользовательские инструкции, поэтому мы контролируем то, что охватывают данные. Планы варьируются от аккуратных набросков до сырого контента, поэтому модель учится сокращать и уплотнять текст. Мы сгенерировали около 1000 презентаций, охватывающих примерно 10 000 слайдов.
Каждый пример также содержит обоснование, написанное как контрфактуал: трассировка рассматривает альтернативу и объясняет, почему она была отклонена, благодаря чему модель усваивает правило, стоящее за выбором, а не просто сам выбор. Дизайнер рассуждает о содержании и форме. Например:
«Выручка за четыре квартала с четкой восходящей тенденцией. Я рассматривал таблицу, но суть этого слайда заключается в тренде, а не в точных цифрах, поэтому гистограмма делает его заметным с первого взгляда».
«Выручка за четыре квартала с четкой восходящей тенденцией. Я рассматривал таблицу, но суть этого слайда заключается в тренде, а не в точных цифрах, поэтому гистограмма делает его заметным с первого взгляда».
Кодер рассуждает о геометрии:
«Заголовок состоит из 62 символов. При размере 44pt он перенесется на три строки и наложится на диаграмму внизу, поэтому я установил размер 36pt, который помещается в две строки и оставляет место над диаграммой».
«Заголовок состоит из 62 символов. При размере 44pt он перенесется на три строки и наложится на диаграмму внизу, поэтому я установил размер 36pt, который помещается в две строки и оставляет место над диаграммой».
Сама по себе модель-учитель не делает данные качественными — это делает цикл проверки вокруг нее. Каждая синтезированная презентация рендерится и проверяется на наличие наложений и переполнения текста тем же проверяющим модулем, который инструмент контроля использует при инференсе. Испорченные слайды восстанавливаются, а их логика переписывается в виде того же контрфактуала, объясняющего, в чем была ошибка исходного макета и почему исправление работает. Каждая ошибка, обнаруженная проверяющим модулем, превращается в лучший обучающий пример.
Самой сложной задачей была достоверность. Худший сбой — это слайд с фактами, которых не было во входных данных, и мы выяснили, что правило в промпте не может этого предотвратить. Если в ТЗ требуется таблица шесть на пять, но указаны только три пункта, кодер вынужден выдумывать остальное.
Проблему решили эталонные презентации, а не правила: исправление эталона надежно меняло результат работы учителя, тогда как добавление правила — редко. Учитель видит несколько эталонных презентаций в своем промпте и копирует их гораздо сильнее, чем следует инструкциям.
Управление презентацией на обычном английском языке
Пользователям часто требуется более точный контроль над конкретными дизайнерскими решениями: диаграмма вместо таблицы, определенный цвет, более темная обложка. Palette позволяет запрашивать их с помощью директив — коротких инструкций, написанных прямо в плане и заключенных в квадратные скобки [[ ]]:
Дизайнер встраивает каждую директиву в ТЗ, а кодер следует ей при отрисовке слайда. Без директивы модель закономерно отобразила бы эти вехи в виде таблицы; с ней модель вместо этого рисует временную шкалу.
Модель следует директивам, потому что была обучена этому. Рецепты данных включают директивы из 12 категорий, некоторые из которых показаны ниже, причем каждая сформулирована несколькими разными способами, чтобы модель улавливала смысл, а не фиксированную фразу.
Рисунок 1. Иллюстрация одного и того же плана без директивы [[make this a timeline]] (слева) и с ней (справа).
Создание проверяющего и корректирующего инструмента
Даже хорошо обученная модель иногда выдает испорченный слайд: заголовок того же цвета, что и фон, или два блока, наложенных друг на друга. Поэтому Palette не возвращает вывод модели напрямую; каждая презентация сначала проходит через специальную систему проверки (harness).
Рисунок 2. Дизайнер составляет техническое задание, кодер пишет код каждого слайда параллельно, а система проверки проверяет и исправляет каждый слайд перед возвратом презентации.
Сначала простые правила исправляют известные ошибки, такие как неправильный код цвета, который иначе сделал бы каждый слайд черным. Затем каждый слайд визуализируется и измеряется: средство проверки геометрии помечает текст, который накладывается, обрезается или выходит за пределы слайда. Помеченные слайды отправляются отдельной модели-редактору, которая переписывает код этого слайда.
Ключевое правило заключается в том, что исправление сохраняется только в том случае, если средство проверки подтверждает улучшение слайда; в противном случае остается оригинал. Это делает систему проверки безопасной для запуска на любой презентации. Она может исправить слайд, но не может сделать его хуже.
Рисунок 3. Иллюстрация исправления. В исходном виде (слева) заголовок каждой карточки наложен на ее описание; система проверки обнаруживает наложения и перестраивает карточки в сетку 2×2 (справа).
Чтобы оценить этот эффект, мы сгенерировали каждую презентацию PresentBench один раз и оценили ее с системой проверки и без нее. На 131 презентации система проверки добавляет в среднем 3,5 балла.
Оценка
Мы проводим оценку на PresentBench, которая оценивает сгенерированные презентации по пяти критериям: основы, визуальный дизайн, полнота, корректность и точность. PresentBench предоставляет исходный документ, а не план, поэтому для этих прогонов отдельная передовая модель составляла каждый план на основе своего документа, а Palette создавала презентацию на основе этого плана. Мы приводим данные по трем доменам; базовые цифры взяты из статьи о PresentBench.
Рисунок 4. Оценки PresentBench по доменам. Palette (синий) против NotebookLM, Manus 1.6 и пяти других систем (серый). Palette занимает первое место в категориях «Экономика» и «Образование», третье в категории «Выступление» и второе по среднему значению для трех доменов.
Palette справляется лучше всего там, где структурированный контент и числовая точность определяют оценку, занимая первое место в категориях «Экономика» и «Образование». В категории «Выступление», где презентации носят повествовательный и ориентированный на речь характер, две закрытые системы набирают больше баллов, а Palette занимает третье место. По совокупности трех доменов она занимает второе место, отставая от NotebookLM на 1,1 балла (59,7 против 60,8) и опережая остальных участников как единая открытая модель с весами в 20B параметров.
PresentBench измеряет качество презентации, но не то, следует ли она определенному языку дизайна. Нам неизвестны бенчмарки, которые это делают, и мы надеемся помочь заполнить этот пробел.
Что дальше
Система проверки уже вычисляет дешевые, проверяемые сигналы: рендерится ли слайд, есть ли наложения или переполнения, прослеживается ли каждый факт до технического задания. Сегодня мы используем их для исправления вывода после генерации. Далее мы хотим использовать те же проверки в качестве наград для обучения с подкреплением, чтобы модель изначально перестала совершать эти ошибки. Поскольку кодер работает с одним слайдом за раз, каждый слайд представляет собой короткий, независимо проверяемый фрагмент прогона, что отлично подходит для обучения в стиле GRPO.
Мы также хотим сократить отставание на презентациях с большим количеством графиков путем извлечения графиков из исходных документов (например, с помощью Docling) и их размещения с помощью системы проверки. И мы изучаем более простой способ использования собственных шаблонов: перенос оформления из одного или двух существующих файлов .pptx без переобучения.
Чему мы научились
Создание Palette научило нас нескольким эффективным методам, которые естественным образом применимы к другим задачам, вывод которых имеет структуру, проверяемую в коде, от графиков и диаграмм до макетов пользовательского интерфейса:
- Заложите рассуждения в данные. Обучение на примерах того, почему было принято то или иное решение, включая то, что было отклонено, дает больше, чем просто выбор.
- Исправляйте примеры перед добавлением правила. Когда учитель делал что-то не так, нашим первым инстинктом было добавить правило в его промпт, и это редко помогало. Учитель копировал свои эталонные презентации гораздо сильнее, чем следовал инструкциям, поэтому именно исправление эталона реально изменило его результат.
- Делайте исправления безопасными по умолчанию. Исправление, которое сохраняется только тогда, когда оно измеримо помогает, может применяться к любому выводу.
- Сначала создайте средство проверки. Именно оно делает данные надежными, а результаты — безопасными для выпуска.
