Сравнение LLM по навыку анализа бизнес-процессов

Всё чаще аналитики бизнес-процессов используют LLM для поиска неэффективностей. Звучит логично: большие языковые модели умеют искать паттерны, а Process Mining как раз об этом. Но на практике результаты пляшут так, что становится понятно: не все LLM одинаково полезны для операционной аналитики. Решил разработать методологию тестирования LLM на предмет релевантности использования для задач анализа процессов.
Было подготовлено три теста, имитирующих реальные сценарии анализа:
Тест 1. Сырой лог событий.
Сгенерировал журнал в классическом формате: id экземпляра процесса, название этапа, временная метка завершения. Всего 20,5 тысяч записей, 1,6 тысячи экземпляров процесса. Внутри спрятал 200 типовых аномалий: зацикливания, bottle neck, избыточные этапы и т.д. Модель получала таблицу «как есть» - без подсказок и форматирования. Оценка: +1 балл за верно найденный кейс, -0,25 за ложное срабатывание. Итог рассчитывался как процент от максимально возможных 200 баллов. Если модель трижды молчала или выдавала «всё идеально» или какую-то ерунду, то стравился ноль.
Тест 2. Регламент с шумом.
Текстовый документ с описанием процесса: этапы, роли, условия переходов. Но также там было добавлено и много "воды" слабо относящейся к самому процессу. К этом тексте "регламенте" было спрятано 100 неэффективностей. Та же система баллов, рассчитывалась доля найденых кейсов, за галлюцинирование штрафы по минус 0,25 балла за каждую галлюцинацию.
Тест 3. Визуальная схема.
PNG с диаграммой BPMN: 20 блоков, около сотни переходов. На схеме было 20 логических ошибок: циклы без условия выхода, неиспользуемые шлюзы, избыточные маршруты, повисшие этапы и т.д.. Проверял, система оценки таже +1 балл за найденный кейс, -0,25 балла за глюс, и считался процент от всех спрятаных проблем.
Финальный скор считался с весами: 80% - анализ лога(таблица с журналом событий) , 10% - текст-"регламент", 10% - картинка с BPMN.
Результаты немного опечалили, что в целом было предсказуемо.