Идея, которая казалась простой

Привет.

Меня зовут Сергей Жилко, в Диасофт я занимаюсь продуктами, связанными с брокерским обслуживанием.

Прошлым летом у нас появились первые видеокарты, мы установили первые LLM модели, провели первые тесты и в итоге решили делать пилотный проект по применению LLM при создании продуктов. Все началось с банальной мысли: "А что если научить ИИ проектировать логические модели в нашем low-code-инструменте?"

У нас есть Digital Q.Archer — low-code платформа для создания enterprise-приложений. Ее ключевая фича - библиотека из ~100 готовых компонентов, которые можно переиспользовать (Packaged Business Libraries, PBL).

Типичная задача архитектора:

  1. Прочитать 200-страничное ЧТЗ

  2. Выбрать подходящие компоненты из библиотеки

  3. Спроектировать недостающие бизнес-объекты

  4. Нарисовать логическую схему бизнес-объектов

  5. Связать все воедино

На это уходит от нескольких часов до нескольких дней. "LLM же умеют в reasoning, — думали мы, — давайте просто скормим ей все описание и получим готовый проект!"

Спойлер: не получили. Но путь к решению оказался интереснее, чем мы думали.

Первая итерация: монолитный агент

Что мы сделали

Написали один большой промпт:

Вот тебе:
- Описание задачи
- 100 архитектурных паттернов
- Описания всех PBL
- Описания PBC базовой поставки
- Требования

Спроектируй решение!

Запустили на Qwen2.5-32B-Instruct (это было до того, как мы перешли на GPT-OSS-120b).

Что получили

💥 Переполнение контекста.

Размеры промпта:

  • Задача: 1-2k токенов

  • Архитектурные паттерны: ~40k токенов

  • Описания PBL: ~50k токенов (каждое — несколько страниц)

  • Описания PBC: ~20k токенов

  • Эталонные примеры: ~10k токенов

Итого: 120-130k токенов в одном промпте.

У нас был Qwen2.5-32B-Instruct на Nvidia 4090 24GB. Модель формально влезала, но к концу промпта уже "забывала" начало и начинала выдумывать несуществующие PBL.

Первое озарение

Контекст. Если запихнуть туда все сразу, модель начинает "забывать".

Решение: Разбить процесс на этапы. Не один монолитный агент, а рой специализированных агентов.

Рождение роя: паттерн Work-Check-Correct

Второе озарение

На одной из встреч наш архитектор Миша сказал: "Давайте для каждого создающего агента сделаем проверяющего агента!"

Идея простая: Агент-исполнитель делает работу, Агент-проверяльщик ищет ошибки, а если есть замечания → корректируем и повторяем

Получился универсальный паттерн:

Задание → Исполнитель → Проверка нужна?
                              ↓ Да
                         Проверяльщик → Замечания есть?
                              ↓ Да            ↓ Нет
                       Коррек��ировка        Готово!
                              ↓
                         [возврат]

Этот паттерн мы стали использовать для каждого этапа проектирования.

Архитектура из двух этапов

Этап 1: Определение состава решения

  • Агент анализирует задачу

  • Выбирает подходящие PBL и PBC

  • Формирует бизнес-возможности и функционал

  • Проверяльщик валидирует выбор

Этап 2: Создание логической схемы

  • Агент определяет нужные бизнес-объекты

  • Ищет "близкие по смыслу" в библиотеках (семантический поиск!)

  • Создает только новые объекты (переиспользует существующие)

  • Генерирует Mermaid ER-диаграмму (логическую схему) специально выбрали эту нотацию, так как она близка к тому ,как у нас выглядит логическая схема.

  • Проверяльщик валидирует схему

Каждый этап работает со своим подмножеством данных, и контекст под контролем.


Борьба с моделями: Qwen vs OSS-120

Qwen: красивая, но упрямая

Зажали модель настройками, topK, topP, температурой.

Начали с Qwen 32b, потому что она была доступна и неплохо справлялась с reasoning.

Проблема: Qwen 32b не любила следовать шаблонам.

Пример:

Мы в промпте:

### Используемые PBL
<Таблица с полями: **Наименование PBL**, Решаемая задача.
СТРОГО наименование из описания PBL. 
Не добавляй ничего>

Qwen:

### Используемые PBL
| Наименование | Решаемая задача | Приоритет | Статус |

Откуда "Приоритет" и "Статус"?! Их не просили!

Пытались бороться через промпт:

  • "Не ДОБАВЛЯЙ дополнительные поля"

  • "ТОЛЬКО указанные поля"

  • "СТРОГО следуй шаблону"

Иногда помогало, иногда нет. Это была лотерея.

OSS-120: строгая и послушная

Когда получили доступ к H200 и перешли на gpt-oss-120b (120B параметров), все изменилось.

Главное отличие: OSS-120 отлично следует шаблонам, если ей дать эталонный пример.

Добавили в промпт:

<details>
<summary>Эталонный пример ответа</summary>

## Проект нового PBC
**Наименование PBC**: Управление ИИ-агентами
**Назначение PBC**: Автоматизация работы с агентами

### Бизнес-возможности
- Централизованное управление агентами
- Мониторинг выполнения задач
...
</details>

Результат: Модель начала выдавать ровно такой же формат. Без отклонений. Без добавления своих полей.

Третье озарение

Эталонные примеры > 1000 слов инструкций.

Если хочешь, чтобы модель генерировала в определенном формате — покажи ей пример. Не описывай словами, а дай референс.

История с зависающим Mermaid

Проблема, которая бесила

На этапе создания логической схемы агент должен был генерировать Mermaid ER-диаграммы.

Что происходило:

erDiagram
"Комментарий задачи" {
    Long commentId PK "Первичный ключ"
    Long taskId FK "Задача"
    String commentText "Текст комментария"

И все. Модель останавливалась на середине. Ни ошибки, ни завершения — просто обрыв.

Что мы пробовали

  1. "Может, контекст кончается?"  Нет, токенов хватало

  2. "Может, температура слишком высокая?"  Снизили до 0.1 - не помогло

  3. "Может, max_tokens маленький?"  Увеличили в 2 раза - бесполезно

Модель генерировала примерно половину схемы и замирала. Выглядело как зависание.

Решение пришло откуда не ждали

На одной из планерок кто-то сказал: "А может, она просто не знает, как правильно выглядит полная Mermaid-диаграмма?"

Добавили в промпт эталонную схему:

  При формировании Mermaid ER-диаграммы строго следуй эталонному примеру:

И здесь мы просто перевели в качестве примера,

уже готовую логическую схему одного из наших небольших продуктов в Mermaid.


Результат: С того момента — ноль ошибок с генерацией Mermaid. Модель стала генерировать полные схемы с первого раза.

Четвертое озарение

Модели "видели" Mermaid в обучающих данных, но не обязательно видели завершенные корректные диаграммы конкретно нашего формата (ER с русскими названиями).

Эталонный пример дал модели "шаблон завершенности" — она поняла, что диаграмма должна быть полной, со всеми атрибутами и связями.

Проверка спасает от галлюцинаций

Эксперимент: агент без проверки

Попробовали запустить процесс без агента-проверяльщика, чтобы сэкономить время.

Что получили:

Задача: Создать систему управления задачами

Выбор PBL без проверки:

1. Электронная заявка ✓
2. Машина состояний ✓
3. Версионность ✓
4. Участники события ← ОШИБКА
5. Связанные файлы ← ОШИБКА

Правильные названия из библиотеки:

  • "Участники событий" (не "события")

  • "Связанные документы" (не "файлы")

Модель выдумала похожие названия! Классическая галлюцинация.

С проверкой

Агент-исполнитель:

Используемые PBL:
- Участники события
- Связанные файлы

Агент-проверяльщик:

| Наименование PBL | Замечание |
|------------------|-----------|
| Участники события | **Необходимо заменить**. 
  Правильное наименование – «Участники событий» |
| Связанные файлы | **Необходимо заменить**.
  Правильное наименование – «Связанные документы» |

Агент-исполнитель (итерация 2):

Используемые PBL:
- Участники событий ✓
- Связанные документы ✓

Агент-проверяльщик: "Замечаний нет"

Пятое озарение

LLM будут "галлюцинировать" похожие названия, даже если правильные есть в контексте.

Обязательная проверка — не перфекционизм, а необходимость для production-систем.

Статистика циклов согласования

Анализ 50 запусков:

  • 1 итерация: 45% случаев

  • 2 итерации: 40% случаев

  • 3 итерации: 12% случаев

  • 4-5 итераций: 3% случаев

Обычно модель исправляется с первого-второго раза. Редко зацикливается. 

Больше 5 не применяем, так как дальше начинаются придирки, которые не нужны.

Промпт как продукт

Эволюция промпта

Версия 1.0: "Спроектируй решение на основе требований" = Результат: хаос

Версия 2.0: Добавили определения (PBC, PBL, бизнес-возможности) = Результат: лучше, но формат гуляет

Версия 3.0: Жесткий шаблон ответа = Результат: структурированный ответ, но модель иногда игнорирует

Версия 4.0: Эталонные примеры = Результат: стабильный формат!

Версия 5.0: Запрещенные слова (~400 зарезервированных SQL/Java/Go)

  • Результат: валидные идентификаторы

Версия 6.0: Структурированная обратная связь

  • Результат: точные исправления

Структура финального промпта

### 🎯 Строгое задание [Четкая инструкция]

<details><summary>Шаблон ответа</summary>
[Жесткий шаблон с требованием Не ОТКЛОНЯТЬСЯ]
</details>

<details><summary>Эталонный пример</summary>
[Показываем, как должен выглядеть идеальный ответ]
</details>

<details><summary>Определения</summary>
[PBC, PBL, бизнес-возможности и т.д.]
</details>

<details><summary>Правила проектирования</summary>
[~100 архитектурных паттернов]
</details>

<details><summary>Описания PBL</summary>
[Структурированные JSON с объектами]
</details>

<details><summary>Запрещенные слова</summary>
[~400 зарезервированных идентификаторов]
</details>

<details><summary>Замечания</summary>
[Структурированная обратная связь от проверяльщика]
</details>

Промпт — это инженерный артефакт, требующий итеративной доработки.

Реальный кейс: налоговый агент за 20 минут

День X: тестируем на боевой задаче

Взяли реальное ЧТЗ от клиента:

  • 200 страниц

  • 50 детализированных требований

  • Налоговый агент (автоматизация налоговой отчетности)

Это то, что обычно архитекторы проектируют несколько дней.

Запуск

14:00 — Загрузили ЧТЗ, запустили процесс

14:05 — Этап 1 завершен

Выбрано 6 PBL

Выбрано 5 PBC базовой поставки

Сформированы бизнес-возможности

14:15 — Этап 2 завершен

Определено 9 бизнес-объектов

7 переиспользованы из библиотек

2 созданы с нуля

Mermaid-диаграмма сгенерирована

14:20 — Интеграция в Digital Q.Archer завершена

Итого: ~20 минут.

Что получили

Логическая схема:

Агент умно переиспользовал библиотечные компоненты:

  • Задача → "Электронная заявка" (PBL)

  • Документы → "Связанные документы" (PBL)

  • Статусы → "Машина состояний" (PBL)

  • История → "Версионность" (PBL)

  • Участники → "Участники событий" (PBL)

  • Теги → "Классификаторы" (PBL)

Создал только два новых объекта.

Схема для демонстрации:

С 7 связями к библиотечным объектам для каждого!

Оценка архитекторов

Показали результат команде архитекторов.

Вердикт: "Примерно так же, как мы сделали бы вручную".

Не лучше, не хуже — адекватно. Для первого боевого теста — отличный результат.

Что мы поняли про ИИ-агентов

1. Контекст — это бюджет, а не бездна

130k токенов на задачу — это реальность сложных enterprise-процессов. Архитектура должна экономить контекст:

  • Передавать только нужное

  • Разбивать на этапы

  • Использовать специализированных агентов

2. Проверка критична

"Один агент делает, второй проверяет" — это не перфекционизм. Это необходимость, потому что:

  • LLM галлюцинируют

  • LLM забывают

  • LLM не всегда следуют инструкциям

Work-Check-Correct — универсальный паттерн для качества.

3. Промпт — инженерная дисциплина

Промпт-инжиниринг — это не "подбор магических слов". Это:

  • Структурирование данных

  • Эталонные примеры

  • Ограничения (forbidden words)

  • Шаблоны и форматы

  • Обратная связь

Хороший промпт требует итераций и тестирования.

4. Эталоны > Инструкции

Модели лучше учатся по примерам, чем по описаниям.

Вместо "Генерируй таблицу с полями X, Y, Z" → покажи пример готовой таблицы.

5. OSS-модели готовы к enterprise

gpt-oss-120b справляется:

  • Сложный reasoning (выбор из 100 компонентов)

  • Семантический поиск ("найти близкий объект")

  • Структурированный output (таблицы, Mermaid)

  • Самокоррекция (через обратную связь)

Не нужны API проприетарных моделей для production-задач.

От PoC к Production

Что сделано

✅ Proof of Concept работает
✅ Протестирован на реальном кейсе
✅ Время: 20 минут vs несколько дней
✅ Качество: "как сделали бы архитекторы"

Текущие работы

🔄 Миграция на production-компоненты
�� Замена OpenWebUI на собственный UI
🔄 Доработка Digital Q.BPM (форк Camunda на Go)

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

Планы

📋 Агент сбора требований Сейчас нужно подробное ЧТЗ на 200 страниц. Хотим, чтобы агент сам вел диалог с заказчиком и собирал требования.

📋 N8N-style визуальный редактор Рисовать flow агентов в визуальном интерфейсе, а не BPMN-схемах.

📋 Масштабирование на другие домены.

Заключение: что мы узнали пройдя этот путь

Начинали с наивной мысли "давайте просто скормим все LLM".

Прошли через:

  • Переполнение контекста

  • Упрямую Qwen

  • Зависающий Mermaid

  • Галлюцинации без проверки

  • Миграцию железа

Закончили с рабочей системой, которая проектирует за 20 минут то, на что уходили дни.

Главные уроки:

Рой > Монолит — специализация работает для ИИ так же, как для людей

Эталоны > Инструкции — покажи пример, не описывай словами

Проверка > Надежда — без циклов согласования качество неприемлемо

Контекст ≠ ∞ — учитывай ограничения при проектировании архитектуры

Промпт = Продукт — итеративная разработка и тестирование


А какой у вас опыт проектирования архитектуры с помощью ИИ? Буду рад обсудить в комментариях.