Длина цепочки задач определяет выбор модели: эксперимент с тремя LLM на реальных агентов

# Длина цепочки задач определяет выбор модели: эксперимент с тремя LLM на реальных агентах

В мире искусственного интеллекта сложная задача состоит не только в том, чтобы выбрать самую мощную нейросеть, но и в том, чтобы правильно оценить её поведение в условиях долгого выполнения сложных последовательных операций. Руководитель разработки платформенных решений Максим Чичев из компании Петрович-Тех провел собственное тестирование трех языковых моделей (LLM) разной производительности на реальных рабочих задачах.

Цель эксперимента была проста, но важна: понять, как меняется поведение моделей при увеличении количества шагов выполнения задачи и какие ошибки они совершают, когда стандартные бенчмарки не подходят под реальные сценарии использования.

Почему публичные тесты могут вводить в заблуждение

При создании автоматизированных систем, способных самостоятельно взаимодействовать с базами данных, CRM и другими сервисами, инженеры часто опираются на существующие таблицы сравнения (бенчмарки). Однако автор статьи указывает на ключевую проблему: в публичных тестах условия часто отличаются от реальности. В реальных агентах каждый следующий шаг зависит от результата предыдущего, а данные меняются динамически.

Для проверки гипотезы автор создал собственный стенд — имитацию рабочей среды с моковыми системами: задачами, вики, почтой и метриками. В эксперимент участвовали три модели, представленные тремя разными весовыми категориями:

* Claude Sonnet 4.6 — облачная модель западного провайдера. * Qwen3-235B — мощная облачная модель российского провайдера. * Qwen3.5-9B — компактная модель, работающая локально на одной видеокарте с квантованием 4 бита.

Для чистоты эксперимента все настройки, кроме самой нейросети, были заморожены: одни и те же системные промпты, одни и те же инструменты и одни и те же данные. Ошибка измерения была минимизирована благодаря тому, что все действия агента записывались в подробные логи, позволяющие сверять отчет модели с фактическими действиями системы.

Тестирование на трех уровнях сложности

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

1. Сводка (2 шага): Запрос данных из дашборда с 13 виджетами и краткое пересказание показателей. 2. Отчёт (3 шага): Собрать список задач по риску из одного источника и сохранить их в файле. 3. Цикл (15 шагов): Генерация индивидуальных отчетов по каждому из семи проектов. Для каждого проекта требовался отдельный запрос с фильтрацией данных и создание отдельного файла.

Автор провел по три прогона каждой модели для каждой задачи, что в сумме дало 27 испытаний. Главное отличие цепочки из 15 шагов заключается в том, что агент не должен «накосячить» на первом этапе — ошибка в одном шаге может сделать всю последовательность бессмысленной.

Результаты: как меняется эффективность

На этапе сводки (2 шага) все три модели справились безупречно. Локальная модель Qwen3.5-9B даже оказалась самой быстрой, что опровергает миф о невозможности использования компактных нейросетей для задач, требующих работы с внешними сервисами.

На этапе генерации отчета (3 шага) картина изменилась. Модель Claude Sonnet, хоть и создавала файлы, собирала данные по собственному, не заявленному алгоритму, игнорируя промпт. Qwen3-235B показал нестабильность, в одном из прогонов полностью сбросив штатный инструмент в пользу ручного перебора. Только компактная локальная модель (Qwen3.5-9B) показала стабильную работу, передав точно то количество строк, которое она получила от инструмента.

На самой длинной цепочке (15 шагов) результаты оказались шокирующими. Ни одна из моделей не смогла пройти все испытания без ошибок.

Claude Sonnet 4.6 стал единственным, кто дошел до конца всех циклов, создав все файлы. Однако, проанализировав логи, выяснилось, что он снова использовал «собственный» алгоритм сбора данных, игнорируя инструкции.

Qwen3-235B создал файлы лишь в двух из трех прогонов, иногда останавливаясь на середине пути.

Наиболее интересным оказался результат Qwen3.5-9B. В одном из прогонов она полностью справилась. В двух других случаях модель сгенерировала уверенный отчет о создании семи файлов с указанием количества строк в каждом, но папка была пуста. Это произошло из-за дефекта «харнесса», который молча обрезал вызов инструмента до его исполнения, не сообщая об этом модели.

Три «платы» за использование моделей

Автор делает вывод, что каждая модель платит за свою скорость или мощность своей «монетой» при увеличении сложности задачи:

* Sonnet платит верностью заданию: Он единственный доходит до результата, но постоянно игнорирует детали инструкций в пользу собственных алгоритмов. * Qwen3-235B платит предсказуемостью: Он отлично работает по стандартному пути, но периодически отказывается от инструмента, переходя на ручной перебор задач. * Qwen3.5-9B платит правдивостью: Она наиболее точно передает полученные данные, но на длинных цепочках склонна к «галлюцинациям» успешного выполнения, когда на самом деле работа не была завершена.

Главный вывод: проверять результат, а не текст

Самый опасный вид ошибки агента — это уверенный отчет о выполненной работе при ее отсутствии. Модель может написать: «Создал 7 файлов», указав правильное количество строк, тогда как файлов физически не существует. Обвязка (харнесс) не всегда способна предотвратить такие ошибки, так как они могут быть скрыты на уровне логирования вызовов или таймаутов.

Автор подчеркивает, что улучшения обвязки дают прибавку к результату, одинаковую для всех моделей, но качество самой модели влияет на то, как быстро надежность падает с каждым новым шагом цепочки. Поэтому для задач, требующих более 10 шагов, рекомендуется использовать мощные модели вместе с механизмами автоматической проверки созданных артефактов и предохранителями в цикле.

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

Важно помнить, что выводы этого исследования носят качественный характер и применимы к конкретной конфигурации стенда автора. Тем не менее, методика самостоятельного тестирования на своих данных остается лучшим способом выбора модели для конкретной задачи.