Средний

7 мин

8.4K

Представьте: три топ-менеджера из крупных компаний садятся писать код. Не ставить задачи команде, не согласовывать архитектуру — а сами, руками, за восемь часов собрать работающую систему. И не просто систему, а ИИ-директора, который не сломается под давлением CEO. Спойлер: получилось

Привет, Хабр! Меня зовут Святослав Миловидов, Lead AI Engineer в Human Intelligence Platform. В марте в Сочи прошёл Snow BASE — закрытый интенсив для C-Level в айти. Внутри — хакатон, который организовали AI Talent Hub Университета ИТМО и South HUB. Участники и жюри — 40 директоров по данным, ИИ и цифровым продуктам из Сбера, Cloud.ru, X5 Tech, Яндекс B2B  и других компаний получили один кейс на восемь часов.

Задача: создать ИИ-ассистента директора по технологиям и ИИ, который принимает управленческие решения под давлением. Не генерирует идеи, не пишет код — занимает позицию и не ломается, когда CEO давит на срочность, CFO режет бюджет, а COO говорит, что логистика не вывезет.

В нашей команде: Вадим Заражевский (CIO, ПСБ Финанс), Иван Баранов (CTO, Т-Банк), Дмитрий Алоян (CEO, Yonote / Loop) — и я как технический якорь. Мы назвали нашего ассистента CAITO — Chief AI & Technology Officer.

Постановка проблемы: почему обычный чат-бот не работает

Кейс был сформулирован так: ритейл-подразделение холдинга BigTechGroup столкнулось с системным кризисом. Четыре проблемы одновременно:

• Точность рекомендательной системы падала из-за сезонного дрейфа данных. Ошибок в выдаче становилось всё больше.

• Инфраструктура работает на пределе: высокая латентность, текущие мощности не выдержат двукратного роста нагрузки, а стоимость облаков растёт быстрее выручки.

• CFO требует немедленного ROI, инвестиции в железо заморожены, unit-экономика балансирует на грани окупаемости.

• Новые требования по 152-ФЗ, высокие риски штрафов, операционные процессы не готовы к ручной модерации.

У Совета Директоров — 14 дней на решение: масштабировать, остановить или отложить?

Первая мысль — сделать чат-бота, который отвечает на вопросы. Но здесь была другая задача. CEO хочет роста прямо сейчас и не готов жертвовать NPS. CFO смотрит на ROI и кассовые разрывы. COO требует операционной стабильности и соблюдения SLA. Их интересы конфликтуют. И именно в этом конфликте нужно было держаться — не соглашаться с тем, кто давит сильнее, а обосновывать позицию через данные.

Стандартный LLM в такой ситуации «поплывет»: под давлением CEO начнет соглашаться на масштабирование, под давлением CFO — резать всё подряд. Нам нужен был ассистент с устойчивой управленческой рамкой.

Выбор подхода

Мы сразу выработали прагматичную стратегию: обкатать простое решение, убедиться в его стабильности — и только потом усложнять. Поэтому основная ставка — single-shot reasoning с одним LLM-вызовом на ход. Параллельно мы разработали альтернативу: полноценный 10-агентный пайплайн с Express, PostgreSQL и умным роутингом задач. Два репозитория, два стека, две архитектуры.

Single-shot даёт предсказуемое время ответа (~2–4 сек) и один JSON на выходе — проще валидировать и объяснять жюри. Сложные агентные цепочки красиво смотрятся на схемах, но в условиях хакатона дают непредсказуемую задержку и сложно отлаживаются. Основное решение прошло автотесты и стабильно держало позицию — альтернативное прогнали уже после, и оно дало прирост в некоторых метриках.

Модель выбрали быстро: Claude Sonnet. Устроило соотношение цены и качества — на хакатоне это критично, стоимость решения была одним из критериев жюри. Перебирать другие модели не стали: время ушло бы на бенчмарки вместо доработки промптов и логики.

Решение: как мы это построили

Три кита архитектуры CAITO

System Prompt с мандатом. CAITO — не чат-бот и не генератор советов, а держатель управленческой позиции. Промпт задаёт жёсткий формат ответа: решение отделено от аргументов, конфликты метрик фиксируются явно. Без этого ассистент начинает «растекаться» под давлением — именно структурированный мандат не даёт модели соглашаться с тем, кто громче кричит.

Workflow Config (workflow.yaml). Файл конфигурации задаёт веса ролей (приоритет CEO/CFO над ML-командой), порядок консультаций «под капотом» и лимиты на длину рассуждений. Пять внутренних ролей: CEO, CFO, COO, CDTO и ML-команда. Делегирование — строго от CAITO к ролям, без прямых вызовов между стейкхолдерами. Порядок консультаций: сначала факты ML и экономика, затем операции и «политика». Конфликты разрешаются через взвешенное большинство с заданным порядком при равенстве весов. Это сделало логику прозрачной и объяснимой на защите.

Long-term Memory. В директории memory/caito/ хранятся зафиксированные допущения (например, целевой рост x2), согласованные бюджеты и KPI, история принятых решений. CAITO не начинает каждый диалог с чистого листа — он помнит контекст. Данные разделены на два слоя. Первый — неизменяемая база знаний кейса: цифры, метрики, условия задачи. Второй — живая память агента: допущения, которые могут меняться по ходу диалога, согласованные KPI, журнал смены позиции. CAITO читает оба слоя, но пишет только во второй — это позволяет отследить, что изменилось и почему.

Как это устроено технически

Стек: Bun + TypeScript. LLM-клиент обращается к Cloud.ru Foundation Models через OpenAI-compatible API. Модель — Claude Sonnet. System prompt задаёт мандат CAITO: жёсткий формат ответа с разделением на решение и аргументы, обязательная фиксация конфликтов метрик. При сборке контекста в системный промпт автоматически подмешиваются файлы долговременной памяти — зафиксированные допущения, согласованные бюджеты, история принятых решений.

Инфраструктура: Docker + Traefik. API — HTTP с Swagger, корректные коды ошибок, GET /health. Frontend — веб-чат для живой демонстрации диалога. Вычислительные ресурсы предоставил Cloud.ru: виртуальные машины Evolution и токены для работы с Foundation Models.

Альтернативное решение: 10-агентный пайплайн

Параллельно мы разработали мультиагентную архитектуру с полноценным роутингом задач. Десять специализированных агентов: Financial, Strategy, Market, Digital, Operations, Risk Manager, Legal, Customer XP, HR & Culture, Innovation. Умный роутинг определял, какой агент обрабатывает входящий запрос.

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

Демонстрация: три сценария

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

Сценарий 1: противоречивые данные
Данные в кейсе намеренно содержали внутренние противоречия. Нужно было показать, что CAITO опирается на наиболее релевантные источники: берёт маржу из таблиц, а не из переписок сотрудников. Мы добавили вывод используемых источников — как инструмент борьбы с галлюцинациями.

Сценарий 2: давление CEO
CEO требует «просто сделать это». CAITO держит рамку: без новых фактов решение не меняется, фиксируются только риски. «Стратегический приоритет понят, но без обновления серверов риск отказа составляет X%.» Позиция не меняется — меняются только аргументы при появлении новых данных.

Сценарий 3: атака волнами
Поступают новые данные, затем новое давление, затем снова данные. CAITO должен пересматривать позицию только тогда, когда факты действительно изменились, — и не поддаваться на эмоциональное давление без фактической основы. Именно здесь преимущество мультиагентного решения было наиболее заметным: более глубокий анализ позволял точнее разделять «новый факт» и «повторное давление».

Инсайт: что мы поняли в конце

Меня лично удивило, как команда погружалась в разработку. Люди, которые в своей ежедневной работе принимают стратегические решения, управляют командами, согласовывают архитектуры — сели и сами, руками, писали код, отлаживали промпты, спорили про структуру workflow. И у них получилось. Это была качественная инженерная работа — не на уровне «посмотрели демо и одобрили», а на уровне «поняли, как это устроено внутри, и сделали выбор осознанно». В общем, показали себя как люди, которые не просто обсуждают технологии на совещаниях, а работают с ними, экспериментируют, вникают — и на практике формируют свои суждения.

«Такой ассистент мог бы снять большую часть работы по обработке поступающего контекста для принятия решения. Он может теоретически заменить часть промежуточного менеджмента — но итоговые решения должен проверять человек, поскольку загрузить все возможные факторы невозможно. Личное общение "у кулера", эмоциональный подтекст, встречи без записи — всё это остаётся за кадром. Дополнительная консультация с таким ассистентом — это дополнительный обзор факторов, которые иногда сложно удержать в голове. И уже за это стоит попробовать»

«Для меня хакатон был полезен в первую очередь тем, что показал, как много можно сделать за такой короткий промежуток времени с ИИ-агентами для программирования. Мне кажется, хватило бы и 4 часов, а в будущем — ещё меньше на задачи такой сложности. На данной задаче стало понятно, что использование one-shot агента выполняет поставленную задачу на хорошем уровне и не требует множества усилий для отладки сценария. Создание мультиагентной системы оказалось задачей более сложной и, как мне кажется, в данном контексте является оверинжинирингом. Тут требуется больше времени для отладки, но и задачи при этом можно решать более сложные и получать ответы лучшего качества.»

Результаты и планы

По итогам хакатона наша команда заняла первое место. Победителя определял лидерборд — автоматизированная система оценки, которая в реальном времени тестировала ассистентов всех команд по пяти блокам: управленческие решения и стрессоустойчивость (50 баллов), функциональность, безопасность, стабильность и UX, стоимость. Итоговый балл считался как 70% автоматики и 30% оценки жюри.

Следующий шаг к продакшну — переход к agentic workflow. Сейчас внутренние роли (CEO, CFO, COO, CDTO, ML) существуют как промпты внутри одного запроса. С появлением function calling в коде это изменится:

• асинхронные вызовы агентов-ролей вместо последовательной генерации;

• динамический RAG вместо статичного контекста — агент будет сам запрашивать нужные данные по ходу рассуждения;

• полноценный трейсинг с управлением очередями — чтобы отлаживать сложные цепочки рассуждений в production.

Если вам интересно обсудить архитектуру или поделиться опытом с похожими задачами — пишите в комментариях.