В июне в Красной Поляне прошёл пятый 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-анализ витрины, где поверхностные выводы по данным оказались неверными.

Разбираем ловушки:

1. GMV рос, но выручка снижалась;

2. Показатели NPS улучшались, но после анализа когорт выяснилось, что часть недовольных клиентов просто переставала участвовать в опросах;

3. Отток клиентов снижался, но доля спящих клиентов росла.

Эти находки и легли в основу проверок внутри системы.

«Ключевое инженерное решение заключалось в том, что каждое найденное правило мы фиксировали дважды. Сначала в каноническую логику расчёта и подготовки данных, потом в 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 был исполнен и необходимость ревизии ответа). Журнал одновременно используется для отладки и позволяет на защите показать весь путь обработки.

```python

trace.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.

```python
except 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