Проблема: AI видит данные, но не понимает контекст
Традиционные облачные хранилища данных (CLOUD DWH) проектировались с учетом человеческого контроля: инженеры готовили данные, аналитики писали запросы, а руководители принимали решения. AI-агенты ломают эту цепочку, самостоятельно выбирая источники, генерируя SQL и рекомендуя действия. Однако, как отмечает Шифек Ур Рахман (Shafeeq Ur Rahaman), наличие метаданных и описаний таблиц не гарантирует, что агент интерпретирует метрики так, как того требует бизнес.
Схема может сообщить агенту, что «стоимость кампании» — это число, но не объяснит, включены ли комиссии агентств, стандартизирована ли валюта или вычтены ли возвраты. Без явных бизнес-правил агент может выдать технически верный, но бизнес-ошибочный результат.
Кейс: Валидный SQL ведет к неверному решению
Рассмотрим сценарий оптимизации рекламных кампаний. Компания просит AI-агента определить, какие кампании нужно приостановить для защиты ROAS. Агент генерирует корректный SQL, но рекомендация оказывается ошибочной по следующим причинам:
- Несинхронизированные данные: На одной платформе конверсии еще не загрузились полностью, на другой — учтена выручка до вычета отмен, на третьей — используется другой часовой пояс.
- Игнорирование логики отчетности: Агент выбирает сырые исходные таблицы, так как их имена лучше соответствуют запросу, игнорируя слой нормализации, который уже учитывает эти нюансы.
Это не «галлюцинация» модели, а архитектурный пробел: хранилище сделало таблицы доступными, но не передало правила их использования.
Решение: Семантический слой и Контракт решений
Автор предлагает внедрить два ключевых элемента:
- Семантический слой (Semantic Layer): Например, в Snowflake это позволяет определить бизнес-сущности, факты, метрики и отношения поверх физических данных. Агент должен опрашивать управляемую бизнес-модель, а не реконструировать её из сырых схем.
- Контракт решений (Decision Contract): Это машиночитаемый документ (например, в YAML), который специфицирует, как система может использовать данные для конкретного класса решений. Он включает:
- Утвержденные источники данных.
- Минимальный исторический период.
- Определение метрик (например, нормализованные затраты на медиа и атрибутированная чистая выручка).
- Правила свежести: какие данные считаются полными, а какие — нет.
- Политики действий: разрешено ли агенту только рекомендовать изменение или исполнять его напрямую.
Почему это важно для безопасности и контроля
Внедрение контрактов решений позволяет точно локализовать источник ошибки. Если результат неверен, команда может проверить каждый слой отдельно: сырые данные, правило свежести, семантическую модель, сгенерированный запрос и политику действий. Без таких границ команда получает лишь размытый вывод: «ИИ выдал плохой ответ».
| Аспект | Традиционный подход | Подход для AI-агентов (Agent-Ready) |
|---|---|---|
| Доступ к данным | Контроль прав (кто может читать таблицу) | Контроль интерпретации (подходит ли данные для решения) |
| Свежесть данных | Технический статус: «задача выполнена» | Бизнес-статус: «данные готовы для принятия решения» |
| Определение метрик | Встроено в SQL, дашборды или документацию | Явное описание в семантическом слое и контрактах |
| Ответственность за ошибку | «ИИ ошибся» | Локализация: источник, модель, запрос или политика |
Рекомендации по архитектуре
Для создания безопасного пути запросов для агентов автор советует:
- Скрыть сырые данные: Агент должен обращаться к интерфейсам бизнес-областей (например, «эффективность кампании»), а не к тысячам сырых таблиц.
- Добавить границу безопасности: Сгенерированный SQL должен проходить валидацию через сервис выполнения запросов перед запуском.
- Версионирование: Контракты решений должны версионироваться вместе с моделями данных, чтобы изменения в моделях атрибуции или порогах одобрения отслеживались.
Источник: Towards Data Science ↗