Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Поиск инструментов для ИИ-агента научили учитывать не только смысл запроса, но и недавние сбои API. В RATED доля выбора недоступных инструментов при 30-процентном искусственном отказе упала с 86,2 до 2,9 процента по сравнению с ToolLLM API Retriever; работа Weiliang Chen и Song Liao пока не рецензирована, а числа получили сами авторы. Архитектура позволяет отделить стабильный семантический поиск от быстро меняющейся эксплуатационной надёжности, не переобучая модель после каждого сбоя.
Смысл запроса не показывает, работает ли API
Обычный поиск инструментов решает статическую задачу: сопоставляет запрос пользователя с описаниями API и ставит наиболее подходящий вариант выше остальных. Если несколько сервисов выполняют одну функцию, такой поиск не знает, какой из них сейчас отвечает, требует рабочую авторизацию или возвращает ошибку.
RATED разделяет эти сигналы. Семантическая часть отвечает на вопрос, подходит ли инструмент для задачи, а отдельный модуль оценивает вероятность успешного вызова. Благодаря этому временный сбой не требует менять представления запросов и документации, которые модель уже выучила.
Для проверки метода создан EcoAgent: каталог из 5 172 инструментов LangChain, CrewAI, LlamaIndex и n8n и более 210 тысяч пар «запрос — инструмент». Кодировщик обучали на синтетических запросах, а качество проверяли на запросах из ToolBench, которые сопоставили с каталогом полуавтоматически и частично проверили вручную.
На реальных запросах RATED улучшил метрику MRR относительно ToolLLM API Retriever на 52,2 процента. MRR показывает, насколько высоко система в среднем ставит первый правильный результат. При этом RATED уступил Ada-002 и SPLADE-v3 в части офлайн-метрик, поэтому основной результат работы связан не с абсолютным лидерством в поиске, а с реакцией на сбои.
Эксперимент воспроизводит постоянное отключение части инструментов в заранее собранном каталоге, а не работу с живыми API. Отказы вводили программно, инструменты оставались недоступными до конца прогона, а обучение и проверку проводили на EcoAgent.
Как обратная связь меняет порядок инструментов
На первом этапе два отдельных кодировщика превращают запрос и документацию инструмента в числовые представления. Их дообучили так, чтобы подходящие пары сближались, а похожие, но неправильные варианты расходились. После развёртывания кодировщики остаются замороженными: новый инструмент достаточно добавить в каталог и один раз обработать его документацию.
Семантический поиск передаёт десять лучших кандидатов модулю повторного ранжирования. Тот соединяет три сигнала: близость к запросу, исходную оценку качества каталога и историю реальных вызовов. Исходная оценка учитывает согласованность названия с описанием, источник записи и полноту документации.
Историю вызовов обрабатывает контекстный бандит — алгоритм, который выбирает вариант, получает результат только для него и корректирует следующее решение. В RATED у каждого инструмента есть собственная модель, а старые наблюдения постепенно теряют вес. Поэтому серия свежих ошибок быстрее опускает отказавший API в выдаче, но не исключает его навсегда.
После вызова агент передаёт один двоичный результат: успех либо ошибка или тайм-аут. Модуль обновляет только состояние выбранного инструмента. Такой цикл не требует собирать пакет траекторий и заново обучать планировщик агента, как в подходах на основе GRPO.
Метаданные закрывают начальный период, когда у нового API ещё нет истории исполнения. Это важная инженерная деталь: без неё алгоритму пришлось бы пробовать неизвестные инструменты почти вслепую либо ждать, пока накопятся отдельные проверки доступности.
Когда работа меняет архитектурный план
RATED меняет план системы, если агент выбирает API из общего растущего каталога и несколько инструментов могут выполнить одну задачу. В такой архитектуре надёжность стоит хранить рядом с поисковым индексом как изменяемое состояние, а не встраивать в веса модели или правила планировщика.
Практический контур состоит из стабильного семантического поиска, быстрого повторного ранжирования и записи результата каждого вызова. Для этого потребуется единообразно различать успешный ответ, ошибку и тайм-аут, а также сохранять статистику отдельно для каждого инструмента. Если обратная связь теряется между запросами, система сводится к статическому ранжированию и лишается основного преимущества метода.
В эксперименте доля успешного выбора после отключений оставалась выше 82 процентов. Повторное ранжирование добавляло к обработке одного запроса 0,172 миллисекунды на использованном авторами GPU, поэтому вычислительная цена адаптации оказалась мала относительно кодирования запроса.
Результат не требует переносить весь RATED целиком. Главный архитектурный вывод — не смешивать функциональную пригодность API с его текущей доступностью. Первую можно обновлять при изменении каталога, вторую — после каждого исполнения, не затрагивая основную модель поиска.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
