Все посты /

Семантический каталог: как enterprise-команды инженерят контекст

Почему Text-to-SQL и прямой маппинг REST API не работают, и как семантический граф бизнес-сущностей решает проблему доставки контекста в enterprise.

#context-engineering #mcp #enterprise #semantic-catalog

Проблема

Text-to-SQL казался элегантным решением. Агент понимает вопрос, генерирует SQL, получает данные. На практике — проблемы с безопасностью, ошибки синтаксиса, падение production.

Прямой маппинг REST API в инструменты MCP не лучше. Агенты путаются в избыточных параметрах и сложных цепочках вызовов. Чем больше эндпоинтов, тем хуже результат.

Обе стратегии объединяет одно: они дают агенту доступ к “сырым” данным и надеются, что он разберётся.

Контекст

Когда команды работают с крупными компаниями, простые методы перестают работать. Не потому что модели недостаточно умны — GPT-4 и Claude справляются с логикой. Проблема в том, как мы доставляем контекст.

Агент видит таблицы базы данных. Он не понимает, что customer_id связан с order_id, который связан с product_sku. Он не знает бизнес-логику: какие транзакции считаются подозрительными, как связаны возвраты и фрод.

Мы даём ему ингредиенты и просим приготовить блюдо. Но он не знает рецепта и не понимает, как эти ингредиенты сочетаются.

Решение

Команды, добившиеся успеха в enterprise, используют другой подход — семантический каталог.

Граф бизнес-сущностей

Вместо таблиц — бизнес-объекты. Вместо foreign keys — смысловые связи.

# Пример семантического каталога
catalog = SemanticCatalog()

catalog.add_entity("Customer", {
    "attributes": ["name", "email", "risk_score"],
    "relations": {
        "orders": "Order",
        "support_tickets": "Ticket"
    }
})

catalog.add_entity("Order", {
    "attributes": ["amount", "status", "timestamp"],
    "relations": {
        "customer": "Customer",
        "items": "Product"
    }
})

Агент теперь понимает структуру бизнеса, а не схему базы данных.

Протокол MCP и возможность исследования

Семантический каталог превращается в MCP-эндпоинт через проекты вроде Enrich MCP. Модель может “общаться” с данными на одном языке.

Ключевое отличие: агент не получает готовый ответ. Он может исследовать иерархию данных:

  1. Получить список заказов за период
  2. Найти аномалии по сумме
  3. Перейти к данным о пользователе
  4. Проверить связанные атрибуты (история, возвраты, риск-скор)
  5. Сделать вывод

Агент сам навигирует по данным, пока не найдёт решение.

Единая поверхность контекста

Вместо разделения на память, векторный поиск и структурированные данные — единый интерфейс. Агент выбирает лучший способ навигации в зависимости от задачи:

  • Поиск по вектору для неструктурированных данных
  • Поиск по ключу для точных запросов
  • Обход графа для исследования связей

Метафора: не давай повару нарезанные ингредиенты по одному. Пусти его на профессионально организованную кухню. Всё подписано, разложено по категориям, логически связано. Повар сам решает, какой нож взять и в каком холодильнике искать нужный продукт.

Инсайт

Проблема enterprise AI — не в интеллекте модели. Современные модели достаточно умны.

Проблема в доставке контекста. Мы даём агенту доступ к данным, но не даём понимания структуры. Мы показываем таблицы, но не показываем связи.

Семантический каталог — это инженерная проработка контекста. Не RAG, не prompt engineering, а полноценная система, которая позволяет агенту самостоятельно извлекать нужные фрагменты данных в реальном времени.

Результат: выход за рамки простого поиска по документам к системам, способным решать аналитические бизнес-задачи.

Источники