Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Агенту с большим реестром API научились выдавать короткий список подходящих инструментов на каждом шаге. В препринте команды с участием Microsoft, который не прошёл рецензирование и содержит замеры самих авторов, GPT-5.4 получал пять инструментов из 128 и тратил на 80% меньше входных токенов при той же доле выполненных задач. Такой слой можно поставить перед LLM, не меняя сами инструменты и логику их исполнения.
Как последовательность вызовов сужает реестр
Обычный поиск инструментов рассматривает каждый шаг отдельно: сравнивает текущий запрос с описаниями всех API и выбирает самые похожие. Это плохо работает с инструментами, которые описаны почти одинаково, но нужны в разных местах процесса.
TRACER учитывает уже сделанные вызовы. Он хранит успешные последовательности в trie (префиксном дереве): корень соответствует началу хода, каждый узел — выполненной последовательности, а исходящие рёбра — инструментам, которые раньше вызывали следующими.
Например, после поиска клиента и загрузки заказа набор разумных действий уже, чем в начале обращения. TRACER берёт из дерева инструменты, которые встречались после той же последовательности, и оценивает их по двум сигналам.
Первый сигнал — частота перехода: как часто конкретный инструмент следовал за текущей последовательностью. Второй — сходство текущего диалога с разговорами, в которых этот переход происходил раньше. Для него система сохраняет на каждом ребре усреднённое векторное представление прошлых контекстов.
Небольшая обучаемая модель решает, как смешать эти сигналы в текущем состоянии. Иногда достаточно статистики переходов, а иногда формально одинаковый путь обслуживает разные намерения и важнее содержание разговора. После ранжирования LLM получает схемы только выбранных инструментов и сама принимает окончательное решение.
Если система не находит текущую последовательность в дереве или оценки кандидатов почти не различаются, она возвращается к поиску по описаниям во всём реестре. Для сред с универсальными служебными API предусмотрен другой вариант: несколько таких инструментов постоянно добавляют к кандидатам.
Меньший контекст помог выбирать точнее
В основном эксперименте точность выбора следующего инструмента — доля шагов, на которых модель выбрала эталонный API, — выросла на 4,7 процентного пункта относительно передачи полного реестра. Сокращение списка не только экономило контекст, но и убирало похожие инструменты, которые отвлекали модель.
В одном сценарии пользователь просил готовую этикетку для возврата. При полном реестре модель пыталась заново запустить сам возврат, тогда как TRACER исключил этот инструмент и оставил точный вызов get_return_label. В банковском сценарии дерево не показывало операцию открытия счёта, пока агент не выполнил обязательный вызов разблокировки.
Авторы отдельно запустили агента без эталонной истории, когда каждая собственная ошибка меняет следующие шаги. Доля завершённых задач осталась в пределах погрешности относительно полного реестра, а входной контекст на шаг сократился на 61%. Это более строгая проверка, чем изолированный выбор: агент должен не только угадать очередной API, но и дойти до нужного состояния системы.
Метод проверяли в шести средах и на четырёх моделях. В набор вошли розничные и телекоммуникационные процессы, банковские операции, API-Bank и BFCL v3; основной смешанный тест дополнили синтетическими API и сценариями. Во всех средах любой инструмент оставался доступен на каждом шаге, поэтому статистика переходов отражала выбор агента, а не заранее заданные ограничения.
Планы стоит менять после накопления успешных сценариев
TRACER имеет смысл рассматривать как отдельный слой извлечения перед LLM, если продукт уже хранит проверенные последовательности вызовов. Он не заменяет планировщик, модель или контроль доступа: слой лишь решает, какие схемы инструментов попадут в контекст на очередном шаге.
Для первого внедрения безопаснее сохранить полный реестр как запасной путь для неизвестных состояний. На шагах вне дерева такой переход повысил бы точность на 38 пунктов, при этом сохранил бы 84% сокращения токенов. Это снижает риск, что новая последовательность действий оборвётся из-за отсутствующего кандидата.
Подход хуже подходит для холодного старта: без журнала успешных выполнений дерево пусто, и система превращается в обычный поиск по описаниям. Польза также зависит от структуры реестра. Если несколько универсальных инструментов применяются почти везде, как поиск по базе знаний в банковской среде, их нужно добавлять глобально, иначе дерево будет часто скрывать правильный вариант.
Практический пилот должен проверить три вещи на собственных журналах: долю шагов вне дерева, качество выполнения задачи целиком и расход входных токенов. Если процессы повторяются, а реестр велик и содержит похожие API, работа даёт основание перестать передавать модели все схемы на каждом шаге. Для быстро меняющегося реестра без проверенных историй архитектурные планы пока менять рано.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
