Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Wenbo Wang описал интерфейсное цензурирование траекторий ИИ-агентов в препринте, который не проходил рецензирования: модель формирует корректный вызов инструмента, но обслуживающий стек не передаёт его исполнителю. На BFCL v4 одна и та же модель получила 0,00 или 0,96 в зависимости от конфигурации адаптера сервера. Это важно командам, которые сравнивают модели с вызовом инструментов, строят многошаговых агентов или обучают их с подкреплением.
Что сделали
Авторы исследовали долю вызовов инструментов — отношение запросов, в которых обслуживающий сервер распознал и зарегистрировал вызов. Обычно эту метрику читают как характеристику модели: если вызовов нет, значит модель не умеет или не хочет использовать инструмент. Работа показывает, что такое объяснение смешивает поведение модели с поведением интерфейса.
Между ответом модели и выполнением функции находятся несколько компонентов. Шаблон диалога сообщает модели, в каком формате отвечать. Модель создаёт текст с именем функции и аргументами. Парсер ищет в этом тексте ожидаемую структуру. Исполнитель запускает функцию, а агент возвращает результат модели для следующего шага.
Адаптер сервера связывает эти компоненты: выбирает шаблон, форматирует описание инструментов и подключает парсер. Если модель обучена выдавать обычный JSON, а парсер принимает только JSON внутри специальных тегов, каждый компонент может работать по своим правилам, но их контракт остаётся несовместимым. Сервер при этом возвращает успешный HTTP-ответ с пустым массивом вызовов, поэтому сбой выглядит так же, как отказ модели от инструмента.
Чтобы отделить модель от интерфейса, авторы фиксировали веса, задания, параметры генерации, случайные начальные значения, исполнитель и оценщик. Они меняли только адаптер, а затем отдельно комбинировали два шаблона диалога с двумя парсерами. Дополнительно они сохраняли исходный текст ответа и независимо проверяли, содержался ли в нём полноценный вызов, даже если сервер его не распознал.
Что показали
В факторном эксперименте на BFCL v4 замена только шаблона или только парсера не помогала. Вызовы появлялись лишь тогда, когда одновременно совпадали оба компонента. Авторы поэтому относят эффект не к дефекту отдельного парсера, а к взаимодействию формата, которому следует модель, с форматом, который принимает сервер.
На интерактивных заданиях τ-bench замена адаптера подняла число распознанных и выполненных вызовов с полного отсутствия до 636; инструменты начали выполняться в 103 заданиях. Однако улучшение итоговой доли решённых заданий осталось в пределах статистической погрешности. Исправление канала восстанавливает возможность действовать, но само по себе не гарантирует правильных аргументов, полезного результата инструмента или успешного завершения задачи.
В серии с Qwen2.5-Coder расхождение увеличивалось вместе с размером модели. Для варианта 32B независимая проверка нашла корректно оформленный вызов в 80 ответах из 100, тогда как сервер не распознал ни одного. По интерпретации авторов, наблюдаемая доля вызовов в такой конфигурации отражает границу парсера, а не отсутствие намерения у модели.
Почему ошибка попадает в обучение
При обучении агента с подкреплением действие модели должно пройти через сериализацию, парсер и исполнитель, прежде чем среда вернёт наблюдение и награду. Нераспознанный вызов остаётся текстом и не становится действием. В собранных траекториях поэтому отсутствует опыт работы с инструментом, хотя исходные ответы модели могут содержать подходящие команды.
Это меняет смысл не только метрики, но и обучающей выборки. Нулевая доля выполненных вызовов не доказывает, что политика модели никогда их не создаёт. Она показывает, что в наблюдавшихся запусках ни один вызов не прошёл весь интерфейсный контракт. Обучение по таким траекториям не получает прямого сигнала о результатах использования инструмента.
Ограничения
Основные проверки проведены на 200 случаях BFCL v4, 115 розничных заданиях τ-bench и собственной выборке из 100 задач по программированию. Рост скрытой доли вызовов с размером измерен внутри семейства Qwen2.5-Coder, поэтому работа не устанавливает общий закон масштабирования для других моделей, доменов и обслуживающих стеков.
Сравнение показывает восстановление механизма вызова, но не статистически значимое улучшение результата задач. Использованный исправленный адаптер также не подтверждён как оптимальный. В эксперименте с обучением контрольная ветка одновременно меняла протокол и интерфейс, поэтому она не изолирует вклад одного адаптера. Авторы называют недостающим отдельное обучение с исправленным вызовом функций при прочих равных.
Что это значит
Работа не требует пересматривать выбор базовой модели только из-за низкой серверной доли вызовов. Она меняет порядок проверки: до сравнения моделей нужно подтвердить совместимость контрольной точки, шаблона диалога, схемы инструмента, парсера и исполнителя. Иначе команда может заменить модель или отказаться от многошагового сценария из-за ошибки измерительного стека.
Практическая проверка должна сохранять исходный ответ модели и отдельно фиксировать этапы прохождения вызова: намерение в тексте, распознавание сервером, выполнение функции, возврат наблюдения и продолжение диалога. Полезны положительный тест с заведомо допустимым вызовом, отрицательный тест с неверным форматом и повторный разбор сохранённых ответов альтернативным парсером.
Для рабочего контура конфигурацию шаблона и парсера следует версионировать вместе с моделью, а обновления сервера проверять регрессионными тестами. Долю распознанных вызовов корректнее считать метрикой всего стека. Решения об архитектуре агента стоит принимать по конечному выполнению задач, но только после подтверждения, что интерфейс действительно пропускает действия модели.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
