Проблема масштабирования MCP
Большинство современных MCP-хостов (Model Context Protocol) работают по принципу «всё или ничего»: при запуске они загружают JSON-схемы всех доступных инструментов и внедряют их в системный промпт. Этот подход критически ломается при переходе от 5 к 50 и более инструментам. Возникают две фундаментальные проблемы:
- Токен-перерасход: Каждая схема занимает 200–400 токенов. При 100 инструментах это 20 000–40 000 токенов только на определения, которые сжигаются на каждом шаге, даже если агенту они не нужны.
- Нестабильность KV-кэша: Любое изменение системного промпта (например, добавление нового сервера) инвалидирует кэш, заставляя модель пересчитывать префикс с нуля. Garry Tan ранее отмечал это как ключевую причину проблем MCP при масштабировании.
Решение Grok Build: BM25 вместо промпта
В открытом коде Grok Build найден элегантный паттерн: модели никогда не показываются полные схемы. Вместо этого в системный промпт внедряются только два инструмента:
search_tool(query)— ищет по скрытому каталогу, возвращая краткие имена и описания кандидатов.use_tool(tool_name, arguments)— выполняет вызов, после чего хост подставляет полную JSON-схему только для выбранного инструмента.
Системный промпт остается константой. Добавление нового сервера обновляет только индекс BM25, сохраняя валидность KV-кэша.
Почему BM25 лучше эмбеддингов для поиска инструментов
BM25 (Best Matching 25) — классический алгоритм ранжирования, который идеально подходит для технических каталогов благодаря трем принципам:
- Частота терминов (TF): Учитывает повторения, но с убывающей полезностью.
- Обратная частота документов (IDF): Редкие технические термины (например, «telemetry») дают больший вес, чем общие («data»).
- Нормализация длины: Краткие, точные описания ранжируются выше размытых длинных текстов.
Для запроса «create github issue» алгоритм четко выделяет инструмент create_issue в сервере github без необходимости в ресурсоемких векторных эмбеддингах.
Сравнение подходов
| Критерий | Традиционный подход (Dumping) | Паттерн Grok Build (BM25) |
|---|---|---|
| Размер промпта | Растет линейно с числом инструментов (до 40k+ токенов) | Постоянный (фиксированное число токенов) |
| Стабильность KV-кэша | Низкая (инвалидация при любом изменении) | Высокая (промпт не меняется) |
| Масштабируемость | Проблематична после 50 инструментов | Легко масштабируется до сотен серверов |
| Сложность реализации | Низкая (прямая инъекция) | Средняя (требуется индексация и поиск) |
Как это реализовать
Для внедрения паттерна необходимо «сплющить» каждую схему инструмента в текстовый документ, объединив имя сервера, имя инструмента, описание и параметры. Затем этот текст индексируется через библиотеку BM25 (например, rank-bm25 в Python). При запросе агента система возвращает топ-N кандидатов, и только после выбора агента полная схема загружается в контекст для выполнения вызова.
Источник: Towards AI pub ↗