Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Локальные открытые модели заметно чаще доводят реальные задачи до конца, если агентная обвязка учитывает их типичные сбои. В препринте Hao Wang и Ting Huang, который не прошёл рецензирование и приводит замеры самих авторов, Mingbird получила сводную оценку 0,886 против 0,631 у ближайшей альтернативы. Для локального агента это меняет порядок работы: прежде чем брать более крупную модель, стоит проверить программу, которая даёт ей инструменты и управляет ходом задачи.
Обвязка мешает модели ещё до первого действия
Агентная обвязка собирает запрос, описывает доступные инструменты, исполняет команды и решает, когда задача закончена. Системы для облачных моделей часто передают длинный перечень функций и рассчитывают, что модель сама исправит неудачный вызов. Небольшая модель тратит на этот перечень существенную часть контекста, хуже удерживает исходную цель и зацикливается после ошибки.
Mingbird сокращает статическую часть запроса, которую система добавляет перед каждой задачей. Она сначала определяет категорию задачи, а затем подключает только относящиеся к ней инструменты в плоском формате. Базовый запрос ограничен 797 токенами, а автоматическая проверка запрещает увеличивать его без сокращения другого фрагмента.
Такой бюджет влияет не только на доступный контекст, но и на задержку. В опыте с небольшой моделью описание 256 инструментов занимало 33,6 секунды обработки перед каждым ответом. Агент из-за этого может потратить минуты на чтение служебных схем, хотя ещё не начал выполнять задачу.
Второй механизм не принимает заявление о завершении сразу. Обвязка снова показывает модели исходное задание и требует сверить результат с ним. Это закрывает характерный сценарий, когда агент сообщает о готовом файле, хотя файл не создал, или прекращает работу после промежуточного шага.
Зацикливание Mingbird определяет по сигнатуре: названию инструмента и нормализованным аргументам. Поэтому косметически различающиеся повторы считаются одной попыткой. Отдельный слой перехватывает вызовы, которые модель написала обычным текстом или оформила с ошибкой, вместо того чтобы молча отбросить их.
Остальные механизмы снижают цену неудачного действия: сохраняют резервные копии при редактировании, создают контрольные точки после сбоев, ограничивают доступ к путям и не дают дочерним агентам бесконтрольно расширять работу. Ни один из этих приёмов не улучшает саму LLM — они не позволяют предсказуемым ошибкам превратиться в провал всей задачи.
Одна и та же модель дала разные результаты
В собственном тесте LRAB сравнили четыре открытые модели на 18 задачах: написание кода, работу с файлами, поиск и многошаговые процессы. Для Mingbird, goose, opencode и agent-mini зафиксировали одну машину, Ollama, лимиты времени и правила оценки. Результат определяли по созданным артефактам, а не по текстовому заявлению агента.
На младшей модели Mingbird получила 0,821, тогда как остальные обвязки оказались в диапазоне от 0,017 до 0,271. Разрыв возникал при одинаковой модели: альтернативные системы перегружали её служебным контекстом, принимали ложное завершение или не выводили из повторяющихся вызовов.
Направление результата сохранилось и на стороннем тесте с задачами из розницы, авиаперевозок и связи. Однако LRAB составили разработчики Mingbird, все запуски прошли на одной машине, а каждая комбинация получила одну попытку. Даже при детерминированной генерации выполнение команд менялось между повторами, поэтому результаты длинных задач подходят для проверки гипотезы, но не для точного рейтинга продуктов.
Работа также показывает границу подхода. Некоторые малые модели систематически передавали несуществующие аргументы инструментов, повторяли ошибку после подсказки и не создавали артефактов. Обвязка может восстановить потерянный вызов или остановить цикл, но не заменит модель, которая не освоила схему инструмента.
Сначала проверять контур исполнения, затем менять модель
Командам, которые строят локального агента на Windows и Ollama, работа даёт практичный план диагностики. Нужно отдельно измерять размер служебного запроса, долю ложных завершений, повторяющиеся сигнатуры вызовов, ошибки в аргументах и наличие итоговых артефактов. Общая метрика успеха без журнала шагов не покажет, где именно потерялась способность модели.
Для сравнения обвязок следует закрепить модель, сервер, лимиты и проверку результата. Если после добавления шлюза завершения и защиты от циклов та же модель начинает выполнять задачу, причина была в контуре исполнения. Если она продолжает вызывать инструменты с выдуманными полями, вероятнее модельный предел.
Переходить на Mingbird целиком необязательно. Бюджет статического запроса, проверку результата перед завершением, нормализацию повторных вызовов и контрольные точки можно добавить в существующего агента независимо. Но прямые замеры пока относятся к Windows, Ollama и выбранным наборам задач, поэтому перенос на другую платформу стоит подтверждать собственным испытанием.
Главное изменение планов касается выбора модели. Размер модели остаётся важен, но сравнивать кандидатов внутри одной случайно выбранной обвязки недостаточно: слабый исполнительный контур может скрыть доступные способности и сделать обновление модели дороже, не устранив исходный сбой.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
