Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
LLM-агента научили не путать инструменты, когда функции переименовывают, переставляют или дополняют похожими вариантами. В работе University of Washington и Uniphore, которая не прошла рецензирование и содержит замеры самих авторов, изменение интерфейса снизило точность почти на 25%, а новый метод вернул 10,5% без потери качества на исходном интерфейсе. Команды, которые дообучают агентов под собственные API, могут уменьшить привязку модели к именам и порядку функций.
Почему разнообразия интерфейсов недостаточно
При дообучении агент может освоить не назначение инструмента, а короткий путь к правильному ответу. Например, он запоминает знакомое имя функции или её место в списке. Пока интерфейс не меняется, такая стратегия получает ту же награду, что и выбор по описанию.
Проблема проявляется после обычных изменений в инфраструктуре. Поставщик переименовывает метод, реестр объединяет инструменты из разных источников, рядом появляется более дешёвый аналог. Задача остаётся прежней, но агент выбирает знакомое имя, даже если его описание больше не подходит.
Обучение на нескольких вариантах интерфейса помогает только с уже показанными изменениями. Каждый вариант оценивают отдельно, поэтому модель всё ещё может найти свой короткий путь для всей обучающей выборки. Из нового типа перестановки или нового похожего инструмента этот путь не следует.
Как CIPR сравнивает выбор под разными именами
Регуляризация политики между интерфейсами, CIPR, сначала скрывает исходные имена. Адаптер заменяет названия функций и аргументов нейтральными идентификаторами, но сохраняет описания, типы и значения. При запуске тот же адаптер переводит вызов модели обратно в формат исполняемого API.
Для каждого обучающего примера метод создаёт второй интерфейс. Инструменты получают другие идентификаторы и меняются местами, а рядом с каждым появляется ухудшенная копия: устаревшая, более медленная либо лишённая нужного аргумента. Поскольку копию строит сама система обучения, соответствие между исходными и изменёнными действиями известно заранее.
Затем CIPR сравнивает вероятности эквивалентных действий. Модель штрафуют, если под одним интерфейсом она выбирает подходящий инструмент, а под другим переносит вероятность на функцию с иным назначением. Для сравнения используют дивергенцию Кульбака — Лейблера, то есть меру расхождения двух распределений вероятностей.
Первый вариант штрафа сохраняет готовый ответ, меняет в нём имена и повторно оценивает вероятности действий. Дополнительная генерация здесь не нужна. Второй позволяет модели независимо рассуждать под каждым интерфейсом и сравнивает средние распределения действий по новым ответам. Он подходит для случаев, когда изменился набор доступных инструментов, но требует дополнительных прогонов при обучении.
Штраф дополняет основную функцию потерь, а не заменяет её. Поэтому согласованность между интерфейсами сама по себе не считается успехом: агент по-прежнему должен решить задачу. Новая разметка для сопоставления инструментов не нужна, поскольку пары строятся автоматически.
Когда метод стоит включить в план обучения
Самый наглядный результат получен на AgentLM в WebShop. Замена действий search и click синонимами снизила награду с 78,9 до 5,5. После обучения с CIPR агент набрал 76,0 под новыми именами. При намеренно перепутанных названиях обе версии модели всё равно ошибались, поэтому адаптер с нейтральными идентификаторами остаётся обязательной частью развёртывания.
Проверка компонентов показала, что одного разнообразия интерфейсов недостаточно: добавление штрафа за расхождение улучшило выбор при изменениях стоимости и задержки. Особенно полезными оказались ухудшенные копии инструментов. Без них модель чаще ориентировалась на позицию функции, а не на указанную в описании стоимость.
CIPR имеет смысл закладывать в конвейер, если команда сама дообучает агента на траекториях или с подкреплением и контролирует слой вызова API. Потребуются генератор парных интерфейсов, таблица соответствий между действиями и адаптер перед моделью. Если используется только закрытый API готовой модели без дообучения, работа не даёт способа подключить CIPR как внешний фильтр.
Метод проверяли на BFCL, WebShop и интерактивных задачах τ2-bench, в обучении с подкреплением и под наблюдением. Масштаб моделей доходил до 9 млрд параметров; для каждой конфигурации провели один обучающий запуск, а основная часть опытов относится к однократным вызовам функций. Результат для более крупных моделей и длинных многошаговых процессов из этой проверки не следует.
CIPR также контролирует выбор инструмента и решение вызвать его, но не согласованность аргументов: их по-прежнему учит основная задача. Поэтому метод закрывает конкретный риск интерфейсных изменений, а не заменяет проверки схем, значений аргументов и выполнения вызова.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
