Проблема: статические навыки — это кэш без инвалидации
Большинство современных AI-агентов используют статические навыки: факты и процедуры «замораживаются» в markdown-файлах. Когда источник данных меняется (таблица депрекейтится, ключи джойна обновляются), навык продолжает использовать устаревшие данные. Это приводит к трем проблемам:
- Рассинхронизация: навыки не знают об изменениях в источниках.
- Инфляция навыков: авторы создают копии навыков для каждой вариации задачи, так как не могут предсказать, какие факты понадобятся модели.
- Противоречия: разные копии одного навыка дрейфуют по своим расписаниям обновлений.
Стандартные решения вроде реестров с полями «владелец» или ежеквартальными проверками лишь добавляют метаданные к уже неверным знаниям. По сути, статический навык — это кэш без протокола инвалидации.
Решение Modus: Разделение намерения и фактов
В новой архитектуре Modus markdown-файл хранит только намерение (intent), процедуру, контракт вывода и правила безопасности. Все факты разрешаются динамически в момент запроса агента через живой контекстный слой. Markdown становится «артефактом сборки» с временем жизни в один вызов.
Ключевое отличие от RAG и MCP:
- Против RAG: Фильтр здесь — это авторизованная конфигурация, компилируемая один раз на вызов. В отличие от RAG, где фильтр пересобирается для каждого пути запроса, здесь он гарантирует, что удаленные активы не будут возвращены (match nothing, а не match everything).
- Против MCP: MCP переносит выборку на время вызова, но выбор ресурса остается на клиенте. В модели Modus выбор происходит на сервере с учетом прав доступа (principals) и бюджета токенов, что позволяет одному навыку генерировать разные документы для финансового аналитика и подрядчика.
Техническая реализация: Граф стратегий
Система использует граф стратегий, где каждая стратегия объявляет предикат и вносит кандидатов только при его срабатывании. Это позволяет обрабатывать запросы, пересекающие разные уровни иерархии (схемы, таблицы, колонки, wiki-страницы), без создания «forest of if-else».
| Элемент графа | Функция | Пример логики |
|---|---|---|
| Entity Extraction | Извлечение сущностей | Ключевые слова и эмбеддинг-поиск |
| Hierarchy Gate | Иерархический шлюз | Обход от выборок к таблицам и колонкам батчами |
| Orphan Repair | Восстановление сирот | Запрос родителя, если найдены только дети |
| Relatives | Расширение окружения | Поиск связанных элементов вокруг хитов |
Важнейшая дисциплина внутри графа — контроль вызовов LLM. Система использует пороговые значения:
- Несколько кандидатов: выборка целиком.
- Сотни кандидатов: фильтр релевантности через LLM.
- Тысячи кандидатов: векторный поиск + кросс-энкодерное переупорядочивание.
Конфигурация вместо хардкода
Вместо указания конкретных имен таблиц (например, dim_customers_v3), автор пишет правила выбора. Если таблица меняется, глоб-правило автоматически разрешается к новому набору данных при следующем вызове.
{
"contextSelections": [
{
"kind": "query",
"rules": [
{ "field": "data_asset", "operator": "globIn", "value": ["1042:analytics/fact_*", "1042:analytics/dim_*"] },
{ "field": "context_type", "operator": "in", "value": ["table_metadata", "column_metadata", "golden_query"] },
{ "field": "verification_status", "operator": "=", "value": "verified" }
]
},
{
"kind": "static_ids",
"value": ["ci_note_8f31c0", "ci_savedquery_2b90ad"]
}
]
}
Поле static_ids служит «аварийным выходом» для критически важных, неизменных фактов (например, правила о двойном учете возвратов до 2024 года). Остальные факты подтягиваются динамически, что позволяет объединить множество схожих навыков в один с широким охватом.
Бюджет как часть навыка
Статические навыки не имеют модели бюджета: автор пишет столько, сколько считает нужным, и система платит за это на каждом вызове. В новой модели markdown-бюджет по умолчанию ограничен 15,000 токенами с жестким потолком. Это заставляет архитектуру быть эффективной: система выбирает только релевантные факты, а не тащит весь «склад» знаний за каждый вопрос.
Источник: Towards Data Science ↗