BPMN Assistant: подход на основе больших языковых моделей (LLM) к моделированию бизнес-процессов

Исследование доказывает, что для генерации сложных структурированных данных (в данном случае, диаграмм бизнес-процессов) с помощью LLM гораздо эффективнее запрашивать у модели не конечный сложный формат (XML), а промежуточный, упрощенный JSON. Этот подход значительно повышает надежность, скорость и, что самое важное, успешность редактирования сгенерированных данных с помощью последующих текстовых команд.

Ключевой результат: Использование упрощенного JSON вместо XML-разметки кардинально повышает стабильность и качество работы LLM при решении задач по созданию и изменению структурированной информации.

Суть метода заключается в "разделении труда" для языковой модели. Вместо того чтобы просить LLM одновременно и понять суть задачи, и сгенерировать сложный, синтаксически безупречный код (например, XML или HTML с множеством вложенных тегов и атрибутов), мы упрощаем для нее задачу.

Метод предлагает следующий подход: 1. Определите простую структуру: Вместо громоздкого стандарта (XML) вы сами придумываете очень простую и логичную структуру в формате JSON, которая описывает нужные вам сущности. Например, вместо <task id="t1" name="Отправить письмо"> вы определяете { "type": "task", "label": "Отправить письмо" }. Это интуитивно понятнее и требует от модели меньше усилий на соблюдение синтаксиса. 2. Создайте "шаблон" в промпте: Вы даете модели четкий пример этой JSON-структуры и просите ее генерировать ответ, строго следуя этому шаблону. Модель перестает быть "изобретателем" сложного кода и становится "заполнителем" простой формы. 3. Работайте с простым форматом: В результате вы получаете чистый, предсказуемый и легко читаемый JSON. Его гораздо проще проверить на ошибки и, как показало исследование, гораздо легче модифицировать дальнейшими командами ("удали шаг 'Подготовить документы'").

Концептуально, мы используем JSON как промежуточный язык (intermediate representation), который понятен и удобен для LLM. Модель тратит свои ресурсы на семантику (что делать), а не на синтаксис (как это правильно записать в сложном формате). А уже полученный простой JSON можно легко преобразовать в любой конечный формат (XML, HTML, график) с помощью простого скрипта или даже другой LLM, но это уже отдельная, более простая задача.

• Прямая применимость: Абсолютно прямая. Любой пользователь, которому нужно получить от LLM структурированные данные (список контактов, план статьи, рецепт, маршрут путешествия), может применить этот метод. Вместо того чтобы просить "сделай мне таблицу с планом поездки", пользователь может сказать: "Сделай мне план поездки в формате JSON, где каждый день — это объект с полями day, city, activities (массив строк) и transport_notes". Это дает гораздо более стабильный и предсказуемый результат, чем попытки модели "нарисовать" таблицу в тексте.

• Концептуальная ценность: Главная идея — LLM не компилятор, она плохо справляется со строгой грамматикой сложных языков разметки. Она — мастер заполнения шаблонов. Это исследование дает пользователю понимание: "Чтобы получить хороший результат, я должен предоставить модели хороший, простой шаблон". Это меняет подход от "дай мне X" к "заполни для меня вот эту форму для X".

• Потенциал для адаптации: Метод легко адаптируется для любой задачи, где требуется структурированный вывод. Механизм адаптации прост:

  1. Проанализируйте, какие данные вам нужны на выходе.
  2. Спроектируйте минималистичную JSON-структуру, которая описывает эти данные.
  3. Включите описание и пример этой структуры в свой промпт как обязательное условие для формата ответа.

Ты — опытный SMM-менеджер. Твоя задача — создать контент-план на 3 дня для Instagram-аккаунта кофейни "Утренний Боб".

**ВАЖНО:** Твой ответ должен быть СТРОГО в формате JSON. Никакого лишнего текста до или после JSON-блока.

Используй следующую структуру для каждого поста:
- `day`: День недели (например, "Понедельник").
- `post_type`: Тип поста ("Продающий", "Вовлекающий", "Информационный").
- `content_idea`: Краткая суть поста (2-3 предложения).
- `visual_idea`: Идея для визуала (фото или видео).
- `hashtags`: Массив из 3-5 релевантных хэштегов.

Вот пример структуры для одного поста:

{ "day": "Пример", "posttype": "Тип", "contentidea": "Описание идеи.", "visual_idea": "Описание визуала.", "hashtags": ["#пример1", "#пример2"] }

Сгенерируй JSON-массив из трех таких объектов для кофейни "Утренний Боб".

Этот промпт эффективен благодаря нескольким механикам, основанным на выводах исследования:

1. Четкое определение формата (JSON): Вместо расплывчатой просьбы "сделай контент-план", мы требуем конкретный, машиночитаемый формат. Это устраняет двусмысленность.
2. Предоставление шаблона (промежуточная репрезентация): Промпт не просто просит JSON, он дает точную "схему" этого JSON с описанием каждого поля (day, post_type и т.д.). Это значительно упрощает задачу для LLM: ей не нужно придумывать структуру, а нужно лишь заполнить готовую форму релевантным контентом.
3. Снижение когнитивной нагрузки: Модели не нужно думать о форматировании (например, как нарисовать красивую таблицу в Markdown). Она фокусируется исключительно на содержании (генерации идей для постов), что повышает качество самого контента.
4. Пример "в контексте": Включение блока с примером JSON-объекта работает как few-shot-промптинг, показывая модели не только структуру, но и ожидаемый формат данных в полях.

Выступи в роли опытного диетолога. Мне нужен план питания на 2 дня для снижения веса. Мой вес 80 кг, рост 175 см, цель — потреблять около 1800 ккал в день.

Твой ответ должен быть представлен ИСКЛЮЧИТЕЛЬНО в виде JSON-массива. Каждый элемент массива — это объект, представляющий один день.

Используй следующую JSON-структуру для каждого дня:
- `day_number`: Номер дня (1, 2, ...).
- `total_calories`: Примерное общее количество калорий за день.
- `meals`: Массив объектов, где каждый объект представляет прием пищи.
  - `meal_name`: Название приема пищи ("Завтрак", "Обед", "Ужин", "Перекус").
  - `dishes`: Массив строк с описанием блюд и их примерным весом.
  - `calories`: Примерное количество калорий для этого приема пищи.

Вот пример структуры для одного дня:

{ "daynumber": 0, "totalcalories": 1800, "meals": [ { "meal_name": "Завтрак", "dishes": ["Овсяная каша на воде (200г)", "Яблоко (1 шт)"], "calories": 400 } ] }

Создай план питания на 2 дня, строго следуя этой структуре.

Этот промпт работает по тому же принципу, что и предыдущий, и подтверждает выводы исследования:

1. Декомпозиция сложной задачи: Задача "создать план питания" разбивается на более мелкие и управляемые части: дни, приемы пищи, блюда. Предложенная вложенная структура JSON (meals внутри day_number) заставляет модель мыслить иерархически, что улучшает логику и полноту ответа.
2. Принудительная структуризация: Требование вывода в виде JSON заставляет LLM организовать информацию в четком, предсказуемом формате. Это исключает возможность получения ответа в виде сплошного текста, который было бы трудно анализировать и использовать.
3. Контроль над выводом: Задавая конкретные поля (meal_name, dishes, calories), мы направляем генерацию и гарантируем, что модель не упустит важные детали. Это делает результат не только структурированным, но и более полным и полезным.
4. Надёжность и предсказуемость: Как и в исследовании с BPMN, где JSON-подход давал более стабильные результаты, чем XML, здесь мы получаем надежный вывод, который легко можно обработать программно (например, для отображения в приложении) или просто скопировать и использовать, в отличие от часто "ломающихся" Markdown-таблиц.