В статье, опубликованной на arXiv 13 октября 2026 года, авторы сравнили два порядка поиска API для ИИ-агентов. В их испытаниях на ToolBench поиск до планирования лучше работал для запросов с одним инструментом, а планирование до поиска — для запросов, требующих нескольких инструментов. Для разработчиков это означает, что порядок поиска может влиять и на результат, и на вычислительные затраты: авторы оценивают дополнительные расходы второго подхода примерно в удвоение стоимости инференса.
Авторы статьи «Plan or Retrieve First? A Scale Study of Tool Discovery Architectures» указали аффилиацию Apple. В исследовании использовали ToolBench с 46 984 конечными точками API в 50 категориях. Читать статью на arXiv.
Чем отличаются два порядка поиска
В схеме Retrieve-then-Plan (RtP) агент сначала ищет API по запросу пользователя, а затем строит план с найденными инструментами. В Plan-then-Retrieve (PtR) модель сначала составляет предполагаемые сигнатуры — краткие описания функций и нужных аргументов, — а затем использует эти заготовки как запросы к каталогу.
Авторы разделили задания на запросы с одним инструментом, с несколькими инструментами из одной категории и с инструментами из разных категорий. В PtR заготовка не обязана совпадать с настоящим названием API: она описывает требуемую функцию, чтобы искать её в каталоге.
Когда предварительный план помогает
Авторы сообщают о закономерности, зависящей от сложности запроса: RtP превосходил PtR на заданиях с одним инструментом, а PtR — на многосоставных. Они наблюдали это соотношение при разных бюджетах поиска и размерах каталога, а также в испытаниях с Gemini 2.5 Flash и gpt-oss-120b.
Такой результат может быть важен, если пользователь просит выполнить несколько связанных действий и не называет нужные сервисы: функциональные заготовки помогают искать инструмент для каждой части задачи. Но на простом запросе с конкретным названием API та же абстракция может стереть сигнал, который RtP использует при поиске по исходной формулировке. Авторы также описывают риск: модель может предложить правдоподобное, но несуществующее имя API.
Дополнительные затраты и границы результата
По оценке авторов, дополнительный вызов модели для генерации заготовок примерно удваивает стоимость инференса; в их результатах эти расходы оправдывались на многосоставных запросах, но ухудшали соотношение затрат и результата на простых. Это оценка в рамках исследования, а не цена внедрения для конкретного сервиса.
Авторы предлагают адаптивно выбирать порядок поиска, используя оценку top-1 результата обычного поиска как сигнал для перехода к планированию. Это направление, предложенное в статье, а не независимо подтверждённая универсальная рекомендация. Выводы основаны на ToolBench и испытаниях с Gemini 2.5 Flash и gpt-oss-120b; независимых тестов в доступных источниках нет, поэтому переносить результаты на другие модели, каталоги и рабочие нагрузки без отдельной проверки нельзя.
