Миллион tools: выбор без переполнения context

Почему нельзя показать модели всё

Каждый tool (инструмент, функция для агента) попадает в context (всё, что модель видит за вызов) своим описанием и schema (параметрами с типами). Документация Claude о Tool Search Tool (открыта 10.10.2026) даёт два числа. Обычная связка из пяти серверов (GitHub, Slack, Sentry, Grafana, Splunk) съедает около 55 000 tokens (кусков слов, единиц длины текста) одних определений до начала работы. И точность выбора tool у модели падает, когда tools больше 30–50.

Теперь прикинь миллион. Если одно определение — около 200 tokens (оценка для короткого описания с парой параметров), то миллион tools — это 200 миллионов tokens. Такого окна нет ни у одной модели, а даже если бы было, выбор среди миллиона почти одинаковых строк провалился бы задолго до предела. Значит, описания должны жить не в context, а в индексе.

Главная идея: выбор tool — это поиск

Tool selection (выбор инструмента) — задача retrieval (поиска), то есть RAG (подкачки документов) над описаниями tools. Описания по-прежнему ключ к выбору, просто они лежат в поисковом индексе. Семь шагов:

1. Индекс заранее (offline). Для каждого tool хранишь имя, описание, краткую schema и несколько примеров запросов. Строишь vector index (поиск по смыслу через embeddings, числовые векторы текста) и keyword index (поиск по словам, BM25).
2. Сначала фильтр по metadata (служебным полям). Убираешь tools, которые этому пользователю и агенту нельзя: права, продукт, канал, регион.
3. Кандидаты. Hybrid search (гибридный поиск: по смыслу плюс по словам) по запросу пользователя или текущей подзадаче агента, около 50 кандидатов.
4. Rerank (пересортировка точной моделью) до 5–10 лучших; только их полные schema идут в context.
5. Модель может искать снова. Агенту даётся tool «найти tool», чтобы посреди задачи запросить другой инструмент, а не получать всё сразу.
6. Иерархия на огромном масштабе. Tools группируются по namespace (общему префиксу) или серверу: карты, платежи, кредиты. Сначала выбирается группа, потом tool: миллион → тысячи → горстка.
7. Безопасный отказ. Если ни один кандидат не подходит по порогу оценки, агент задаёт уточняющий вопрос или передаёт человеку. Ближайший неподходящий tool не вызывается никогда.

Почему фильтр по правам стоит до поиска

Две причины. Безопасность: tool, которого агент не видит, он не может вызвать по ошибке или по наущению prompt injection (инструкции, спрятанной в данных). Качество: если фильтровать после поиска (post-filter), запрещённые tools займут места в топ-50, и после их удаления останется мало кандидатов или ни одного. Фильтр внутри запроса (pre-filter) отдаёт 50 разрешённых. Это то же правило, что для документов в RAG: ACL (список, кто что может видеть) проверяется в запросе поиска, до ранжирования.

Что даёт готовый Tool Search Tool

Anthropic выпускает это как часть API (по документации, открытой 10.10.2026). Tools с флагом defer_loading: true передаются в запросе, но не попадают в context, пока поиск их не найдёт. Есть два варианта поиска: regex (модель пишет регулярное выражение) и BM25 (модель пишет запрос словами). По умолчанию поиск возвращает 5 tools. Документация советует 3–5 самых частых tools не откладывать (оставить без defer_loading), чтобы они были видны сразу, и заявляет сокращение tokens на определения больше чем на 85%. В статье «Advanced tool use» Anthropic приводила рост точности на своих MCP-оценках: Opus 4.5 с 79,5% до 88,1%, Opus 4 с 49% до 74% (цифры из статьи, открытой 08.10.2026).

Два практических следствия. Поиск — лишний круг перед первым вызовом, поэтому частые tools держат видимыми сразу. И отложенные tools не ломают prompt caching (кэширование начала запроса у поставщика): по документации они не входят в начало запроса, а найденные определения дописываются в разговор, так что закэшированная часть не меняется. Обычный вызов без поиска документация советует, когда tools меньше 10, или каждый нужен в каждом запросе, или все определения вместе меньше 100 tokens.

Важный предел: не больше 10 000 отложенных tools на запрос. Миллион в одну строку настроек не влезает. Ответ для собеседования: до 10 000 — встроенный поиск; на миллион — свой индекс (фильтр по правам → hybrid → rerank) и иерархия, а найденное возвращается модели через блоки tool_reference из собственного tool поиска. Документация прямо разрешает такую свою реализацию, например на embeddings.

Как это измерить

Раздели систему на две половины, как в RAG, и мерь их отдельно:

Пример: на 400 размеченных запросах верный tool попал в топ-10 в 372 случаях — recall@10 = 93%. Из этих 372 модель вызвала верный tool в 350 — 94%. Полный успех 350 из 400 = 87,5%, и ты знаешь, какую половину чинить. Частая причина промахов — почти одинаковые tools с похожими описаниями: их объединяют или переписывают описания так, чтобы различие было в первых словах.

Почему не «классификатор по названию»: имена короткие и двусмысленные, а классификатор на миллион классов надо переобучать на каждый новый tool. Индекс просто получает новую строку. Тот же принцип, что у skills: короткое описание видно, полное тело грузится по требованию.