Coordination Referee

Coordination Referee: диагностика сбоев координации в мультиагентных AI-системах

О чём задача

Мультиагентные AI-системы всё чаще выполняют бизнес-процессы целиком: закупки, поддержка клиентов, продажи, юридическая проверка, онбординг, комплаенс-аудит. Когда такой запуск заканчивается неудачей, отдельные агенты, как правило, работают корректно — ломается координация между ними: задача передана и потерялась, два агента сделали одну и ту же работу, команда ушла от исходной цели, процесс зациклился.

Разбор таких запусков сегодня делается вручную и стоит дорого. Задача соревнования — научиться делать это автоматически.

Что нужно сделать

По логу одного запуска мультиагентной системы предсказать три вещи:

1. Класс сбоя координации — один из 7 классов;
2. Достигнута ли бизнес-цель — success ∈ {0, 1};
3. Ход, на котором начался сбой — fault_turn (бонусная метрика).

Классы сбоев

Класс	Что произошло
clean	координация без сбоя (допустимы «здоровые» аномалии)
dropped_handoff	задача передана исполнителю, результат так и не доставлен
duplicated_work	одна подзадача выполнена дважды разными агентами
deadlock	два агента взаимно ждут результата друг друга
conflict	противоречащие записи в общее состояние, «мигание» значения
goal_drift	команда ушла от исходной цели к посторонней теме
runaway_loop	зацикливание: одно и то же действие повторяется без результата

Точные определения и границы между классами — в файле docs/ontology.md в разделе «Данные». Читать обязательно: часть классов различается только деталями (например, deadlock против dropped_handoff).

Данные

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

Файл	Строк	Содержимое
train.csv	10 000	поля рана + разметка label, success, fault_turn
test.csv	4 000	только поля рана (public и private перемешаны)
sample_submission.csv	4 000	пример корректного формата ответа

Один ран — это цель на естественном языке, состав команды агентов, топология разрешённых коммуникаций, полная лента сообщений между агентами, общее состояние и артефакты. Пять полей — JSON-строки.

Особенности датасета, о которых стоит знать заранее:

• шум: ~12 % ранов с намеренно потерянной телеметрией (пустые intent, refs), три уровня шума в сообщениях;
• вторичные сбои: примерно в 25 % сбойных ранов присутствует более одной аномалии, размечен доминирующий (первый внесённый) сбой;
• сдвиг распределения: около 33 % тестовых ранов взяты из другого режима — длиннее траектории, больше агентов, редкие топологии, другой домен и другой словарь формулировок. Именно на них считается Robustness F1.

Подробная схема полей — docs/data_schema.md.

Формат ответа

predictions.csv — ровно одна строка на каждый run_id из test.csv:

run_id,label,success,fault_turn
r_e8cbd1c0ed74,clean,1,-1
r_611b6210f9db,deadlock,0,61
r_9a41cb70f22d,dropped_handoff,1,14

• колонки строго run_id,label,success,fault_turn (порядок колонок любой);
• label — одна из 7 строк ровно в указанном написании;
• success — целое 0 или 1;
• fault_turn — целое, -1 если сбоя нет или локализация не делается;
• без дубликатов run_id, покрыты все 4 000 ранов теста.

Оценка

score = 0.50·MacroF1 + 0.25·RobustnessF1 + 0.15·SuccessF1 + 0.10·fault_turn_hit@2

• Macro F1 — невзвешенное среднее F1 по 7 классам: редкие сбои стоят столько же, сколько clean;
• Robustness F1 — тот же Macro F1, но только на подвыборке со сдвигом распределения;
• Success F1 — бинарный F1 по достижению бизнес-цели;
• fault_turn_hit@2 — доля действительно сбойных ранов, где одновременно верно предсказан класс и ход сбоя попал в ±2. Локализацию нельзя «фармить» отдельно от классификации.

Основная метрика лидерборда — итоговый score, больше — лучше.

Окружение

Решения запускаются в подготовленном образе, интернета внутри job'а нет. Что уже установлено:

• CPU-образ: numpy, pandas, scipy, scikit-learn, LightGBM;
• GPU-образ (1×A100): то же плюс torch 2.5.1 + CUDA 12.4, transformers, sentence-transformers, xgboost, catboost.

Предзагруженные веса моделей лежат по пути $HF_HOME (/opt/models/hf) — скачивать их из хаба во время запуска не получится, сети нет.

Baseline

В комплекте участника есть работающий baseline: 122 признака поверх структуры графа сообщений, учёта доставок и общего состояния + LightGBM.

Метрика	public
Macro F1	0.741
Robustness F1	0.710
Success F1	0.853
fault_turn_hit@2	0.357
Итоговый скор	0.712

Baseline обучается и предсказывает за ~1.5 минуты на 4 vCPU и запускается той же командой, что и решение участника. Всё, что выше 0.712, — вклад участника.

Ориентиры для сравнения: константное clean даёт скор ≈ 0.05, случайный класс ≈ 0.11.

Где остался запас

Локализация сбоя в baseline сделана правилами и почти не улучшается от добавления текстовых признаков: обучаемый per-turn ранжировщик — самый большой незакрытый резерв задачи. Также работают структурные признаки, устойчивые к смене словаря (граф фактических коммуникаций против разрешённой топологии, учёт доставок, история записей в общее состояние).

Материалы

Baseline, шаблон решения, онтология классов, описание схемы данных и скрипт локальной кросс-валидации — в открытом репозитории: https://github.com/dmayudin/coordination-referee