В июне в Красной Поляне прошёл пятый South HUB, ежегодный кэмп для C-level в ІТ, который собрал более 500 CTO, CEO, CIO и CPO крупнейших российских компаний. В этом году добавили новый формат – хакатон AI South Hack, оператором которого выступила GIGASCHOOL. Участниками стали руководители, которые в своих компаниях принимают решения о внедрении AI и ставят задачи инженерным командам. На три дня они сами погрузились в разработку: проектировали архитектуру и собирали мультиагентные системы на синтетических данных.
По условиям кейса организация Meridian, вымышленный крупный B2B-маркетплейс услуг для среднего бизнеса с клиентской базой более 4 млн компаний и оборотом 180 млрд рублей в год, столкнулась с падением выручки и ростом оттока клиентов, а руководству не хватало скорости принятия решений.
Более 40 участников за три дня создавали AI-аналитика, способного напрямую отвечать на вопросы руководителей на естественном языке, самостоятельно исследовать данные компании, выявлять причины изменений ключевых метрик и формировать регулярные отчёты.
Знакомьтесь с победителями: команда под номером 3 разработала AI-платформу для бизнес-аналитики, объединяющую возможности BI-систем и мультиагентного ИИ.
-
Ринальд Садыков, CEO, Terabit Digital
-
Иван Муратов, СТО, WALIOT
-
Сергей Суханов, Генеральный директор, Триада
-
Анатолий Шишкин, руководитель IT-департамента, Российский Аукционный Дом
Поговорили с участниками команды о том, как они подошли к решению кейса, почему начали с бизнес-анализа, а не технологий, какие выводы сделали на этапе исследования данных и как это повлияло на архитектуру всей системы.
Отталкиваемся от бизнес-проблемы
«Мы понимали, что многие команды будут просто отдавать данные GPT и ждать готового решения. Но по нашему опыту с генерацией кода не всё так просто. Поэтому мы разделили задачу на два этапа и двигались от бизнес-анализа к системному.» – Ринальд Садыков, CEO, Terabit Digital
Первостепенной задачей стали не выбор LLM или проектирование агентов, а разведочный анализ данных.
Команда изучила структуру витрины, связи между таблицами и бизнес-метрики и выделила три ограничения:
-
подготовка аналитики занимает слишком много времени;
-
данные содержат противоречия и потенциальные ошибки;
-
конечными пользователями системы должны стать топ-менеджеры, а не технические специалисты.
Концепцией стали простой интерфейс для пользователя и максимальное количество проверок внутри системы.
По условиям задачи требовалось реализовать минимум четырёх агентов. В рамках концепции команда выделила роли:
-
агент-критик проверяет и размечает некорректные данные;
-
агент-аналитик делает выводы на основе данных.
-
агент защиты от флуда (ML определяет, стоит ли тратить токены);
-
агент-извлекатель данных (расчёты производит Python);
Поверх этого команда добавила отправку отчётов, чат для управления дашбордом и интерактивный Data Explorer.
Что показал анализ данных?
До проектирования системы команда провела EDA-анализ витрины, где поверхностные выводы по данным оказались неверными.
Разбираем ловушки:
-
GMV рос, но выручка снижалась;
-
Показатели NPS улучшались, но после анализа когорт выяснилось, что часть недовольных клиентов просто переставала участвовать в опросах;
-
Отток клиентов снижался, но доля спящих клиентов росла.
Эти находки и легли в основу проверок внутри системы.
«Ключевое инженерное решение заключалось в том, что каждое найденное правило мы фиксировали дважды. Сначала в каноническую логику расчёта и подготовки данных, потом в guard-слой критика, который не даёт модели протащить неверный вывод», – Иван Муратов, СТО, WALIOT.
Почему чат стал центром интерфейса?
BI-системы ориентированы на аналитиков. А топ-менеджерам нужны базовые метрики на дашборде и аналитика через чат, поэтому их намеренно объединили в один интерфейс.
«У нас был дашборд, которым управлял чат. Мы ориентировались на топ‑менеджеров (нашу аудиторию): им нужно было видеть базовые метрики на дашбордах и получать аналитику по цифрам через чат (например, «Почему у нас отток продаж?»).
Поэтому решили использовать чат как коммуникационную среду, в том числе для дашборда. Если в чате написать «Покажи выручку за последние 3 месяца прошлого года», система откроет нужный дашборд, найдёт график и покажет его, а также даст аналитику.
Изначально была идея отдельно собрать дашборды и отдельно чатик, но потом мы их связали, чтобы это было полноценным инструментом.», – Ринальд Садыков, CEO, Terabit Digital
Архитектура
Команда построила конечный автомат из нескольких специализированных ролей, где модель отвечает за рассуждение, а факты считаются кодом («harness > model»).
LLM используется там, где нужна интерпретация данных и формулировка выводов, а бизнес-правила, канонические метрики и проверки рассчитываются детерминированно. Получилась двухслойная архитектура, которая позволила свести к нулю количество галлюцинаций.
Логика решения
Роутер определяет тип запроса и отсеивает болтовню, инъекции и запросы, требующие уточнения, позволяя экономить токены.
Извлекатель преобразует вопрос пользователя в SQL и получает необходимые данные. Перед исполнением каждый запрос проходит детерминированные проверки, где разрешаются только операции чтения, автоматически ограничивается объём выборки и блокируются потенциально опасные конструкции. Благодаря чему LLM не имеет прямого доступа к выполнению произвольного SQL.
Аналитик формирует бизнес-выводы, а критик проверяет выводы на соответствие данным и при необходимости отправляет их на доработку.
Визуализация строится без участия LLM, а тип графика определяется детерминированными правилами.
POST /api/chat ↓[Роутер] — data / smalltalk / injection / clarify ├─ smalltalk / injection ──→ шаблонный ответ (без аналитического пайплайна) ├─ clarify ────────────────→ уточняющий вопрос └─ data ↓[Извлекатель] — NL→SQL, DuckDB (read-only sandbox) └─ missing && !datasets ──→ честный отказ insufficient_data ↓[Аналитик] — выводы на языке бизнеса, каждый тезис привязан к цифре ↓[Критик] — чек-лист + канонические цифры, посчитанные КОДОМ ├─ revise (≤1) ──→ назад к аналитику с замечаниями └─ approve ↓[Визуализация] — rule-based выбор графика (0 вызовов LLM) ↓FinalAnswer: response + assumptions + trace + chart + dashboard_action
Вход в тяжёлый пайплайн открывает только классификация data; приветствия, офтопик и инъекции отбиваются шаблоном до запуска чего-либо тяжёлого. Решение строить ли график принимается по форме данных, а не отдельным запросом к модели. Если извлекатель возвращает пустоту со списком недостающих сущностей, то наружу уходит честный отказ.
Критик возвращает список Issue с полями target (extractor/analyst) и severity – это позволяет адресовать ревизию конкретному агенту.
В trace записывается каждый этап работы системы (тип агента, какие данные он получил, какой SQL был исполнен и необходимость ревизии ответа). Журнал одновременно используется для отладки и позволяет на защите показать весь путь обработки.
```pythontrace.append(TraceStep(agent="extractor", summary=f"datasets={len(ext.datasets)}, missing={ext.missing}", sql="; ".join(qq.sql for qq in ext.queries) or None))```
Почему свой тонкий оркестратор, а не LangGraph или CrewAI
Для оркестрации команда не использовала готовые агентные фреймворки, вместо этого написали FSM на чистом Python вместо фреймворка по трём причинам, и каждая завязана на критерии оценки кейса.
«Первая – контроль над каждым токеном. Экономика решения – это критерий жюри, и мы хотели тратить токены только там, где они дают точность. Свой оркестратор позволяет, например, гонять роутер на pro-модели только при наличии истории (переформулировка follow-up требует качества), а без истории – на быстрой lite. Это
pro=bool(history)в одной строке.Вторая – чистые логи. Каждая LLM-роль – это наш системный промпт на русском с меткой
[РОЛЬ: …]в первой строке. В логах Yandex AI Studio видны только наши промпты. И в результате мы могли показать ровно то, что ушло в модель. Да, также можно и с LangGraph, но помним, что это не единственная причина.Третья – объяснимость. Любое решение в пайплайне мы можем обосновать собственной строчкой кода. Тайм-бюджеты, fail-open критика, выбор промпта в LLM – это явные ветвления в нашем коде.», – Иван Муратов, СТО, WALIOT.
Про отказоустойчивость
Главный инвариант системы заключался в том, что сбой отдельного агента не должен приводить к отказу всего пайплайна. Любое необработанное исключение превращается в понятный JSON-ответ вместо ошибки 500.
Например, если критик не смог завершить проверку, пользователю всё равно возвращается ответ аналитика с соответствующей отметкой в trace. Если данных недостаточно для вывода, система честно сообщает, каких сущностей не хватает, вместо того чтобы достраивать ответ с помощью LLM.
```pythonexcept Exception: logger.exception("critic failed — fail-open approve") trace.append(TraceStep(agent="critic", status="error", summary="критик упал — ответ принят без проверки")) return CriticVerdict(verdict="approve", checked=["fail-open: критик упал"])```
Как боролись с галлюцинациями?
Большинство защитных механизмов сформировались после анализа данных.
Например, критик проверяет ответы на несколько типовых ошибок:
-
выдуманные триллионные значения;
-
ложные выводы об отсутствии данных;
-
ошибки в знаке тренда;
-
выводы об отсутствии существенных изменений при заметной динамике.
При этом многие проверки выполнялись вообще без участия LLM.
Код самостоятельно вычислял канонические значения ключевых метрик и сравнивал их с выводами аналитика, а модель отвечала только за интерпретацию результатов.
Подводим итоги
«Мы подошли к проекту с первого и главного вопроса: как этим будут пользоваться клиенты, и этот ответ значительно важнее требований технического задания. Поэтому пока конкуренты делали чат-боты, мы делали современную систему bi-аналитики с чат-ботом как важной, но далеко не единственной функцией. В итоге получилась платформа с визуализацией данных и возможностью общаться с данными, которые интерактивно перестраивают интерфейс отвечая на вопрос пользователя.» – Сергей Суханов, Генеральный директор, Триада.
Команда не пыталась заставить модель делать всё самостоятельно. Они собрали вокруг неё понятный каркас из валидации, fallback-механизмов и критической проверки, грамотно ограничивали и направляли её. И в этом оказался успех решения.
«Наша задача была не выиграть хакатон и не думать о том, что делают другие, а решить бизнес‑проблему наиболее эффективным способом. Фокус был на бизнесовой части, а не на технической, несмотря на то, что у меня и сокомандников сильный технический бэкграунд», – Ринальд Садыков, CEO, Terabit Digital.
Делимся ссылкой на систему ребят: team-003.aisouthhack.ru
И на репозиторий: github.com/binakot/Southhub-2026-Meridian-AI-Assistant
ссылка на оригинал статьи https://habr.com/ru/articles/1054978/