Почему агентам аналитики ИИ нужен семантический слой вместо чистого SQL
Функция Text-to-SQL для необработанных таблиц создает метрики и игнорирует правила доступа. Семантический слой, такой как Cube, предоставляемый через MCP, придает ИИ-агентам управляемый бизнес-смысл.
Источники: The Semantic Layer for AI Agents: How to Stop LLMs From Inventing Metrics
Позволение агенту для анализа на основе ИИ писать SQL — это быстрейший способ получить демонстрацию, которая впечатлит людей. Это также быстрейший способ создать опасность, если этот SQL будет выполняться с использованием сырых таблиц склада без учета бизнес-контекста. Проблемы возникают не в синтаксисе, а в значении.
Возьмем слово «доход» и спросим, что оно включает в себя:
- Валовый или чистый?
- Учитываются ли возвраты?
- Какая колонка с датой определяет квартал?
- Означает ли «активный клиент» активность на момент оформления заказа или активность сегодня?
- Какое соответствие регионов применяется?
- Какое правило конвертации валют?
- Разрешено ли этому пользователю вообще просматривать данные этого клиента?
Прямая конвертация текста в SQL терпит неудачу именно по этим причинам. Модель может генерировать корректный SQL, база данных может его выполнить без проблем, но результат всё равно может быть неверным. По этой причине аналитическому агенту необходим слой семантики между ним и бизнес-данными. Cube — это хороший пример такого слоя, который используется в приведённом ниже примере.
Схемы не несут смысла
Идея преобразования текста в SQL хороша: она позволяет разработчикам, аналитикам и бизнес-пользователям работать быстрее. Однако схема хранилища редко содержит тот смысл, который от неё ожидает человек.
В таблице имеются такие столбцы, как amount, status, created_at, customer_type, region_id и currency, но никто в бизнесе не формулирует вопросы в таком виде. Никто не спрашивает sum(amount) grouped by region_id where status = 'paid'. Вместо этого они спрашивают, как вырос доход компании в Южной Индии в прошлом квартале.
В этом одном предложении скрыта целая серия решений. Что такое доход, и что делает компанию клиентом? Какая дата обозначает квартал, и как отображается Южная Индия? Удаляются ли возвраты средств и отменённые заказы? Какое правило валюты применяется, и что может видеть пользователь? Модель может только предполагать ответы на каждый из этих вопросов. Однако предположения — это не управление. Если ответ агента отличается от данных на панели управления, люди теряют к нему доверие. Если он использует неверную таблицу, цифры могут казаться правдоподобными, но при этом быть неверными. Если агент игнорирует правила доступа, ответ превращается в утечку данных.
Поэтому настоящий вопрос не в том, может ли модель писать SQL. Вопрос в том, должна ли модель вообще создавать бизнес-логику.
Что делает семантический слой
Семантический слой находится между необработанными данными и теми, кто их использует, преобразуя технические структуры базы данных в упорядоченные бизнес-концепции. Он определяет показатели, метрики, измерения, способы объединения данных, сегменты, иерархии, правила доступа, правила кэширования, предварительную агрегацию данных, а также API для их запроса, вместо того чтобы отображать таблицы и столбцы напрямую.
Конкретно говоря, orders.amount, customers.type, orders.created_at и refunds.amount превращаются в «Доход», «Корпоративный клиент», «Дата заказа» и «Доход после корректировки на возвраты». Агентам необходим такой словарь терминов. Без семантического слоя агент анализирует схему и делает выводы самостоятельно; с его наличием агент работает на основе утвержденных определений. Агент по-прежнему не идеален, но одна из основных причин ошибок в аналитике исчезает, поскольку определения показателей больше не требуется воссоздавать из первоначальных таблиц.
Это категория, а не отдельный продукт. Cube, Semantic Layer от dbt (созданный на базе MetricFlow) и LookML от Looker — все они решают одну и ту же проблему в своих собственных экосистемах. Cube привлекает внимание здесь потому, что его подход для агентов выглядит необычайно полным, хотя архитектура важнее бренда.
Почему Cube — хороший пример
Cube — это не просто слой для дашбордов. Один управляемый модель обеспечивает данные как для инструментов BI, так и для встроенного анализа, API и ИИ-агентов; он состоит из кубов, метрик, измерений, соединений, сегментов, иерархий, предварительных агрегатов и политик доступа. Это практически точно те элементы, которые нужны аналитическому агенту.
Само описание его архитектуры хорошо отражает суть: агенты не запрашивают данные непосредственно из хранилища, они запрашивают данные у семантического слоя, а движок выполнения выступает в роли защитного барьера между агентом и хранилищем.
Сравните, что каждый из них передаёт модели. При получении необработанной таблицы модель видит только названия столбцов. При наличии семантического слоя она также получает утверждённые концепции, логику расчётов для каждой из них, способы их взаимосвязи, то, с чем может работать текущий пользователь, и безопасный способ выполнения запросов. Повторное выявление бизнес-логики при каждом вопросе — это расточительство, поэтому агент должен запрашивать информацию у слоя, который уже её содержит.
Соединение плюс смысл: где находит применение MCP
MCP — это стандартный способ подключения ИИ-ассистентов к внешним инструментам и данным, однако подключение не равносильно пониманию. Даже если через MCP предоставить агенту прямой доступ к необработанным таблицам склада, ему всё равно придётся самостоятельно интерпретировать смысл, что является первоначальной проблемой в новой реализации.
Более эффективный подход предусматривает направление агента через семантический слой:
AI agent
→ MCP client
→ semantic-layer MCP server (e.g. Cube's)
→ semantic layer (governed metrics, dimensions, joins, policies)
→ data warehouse
MCP отвечает за управление доступом, а семантический слой — за интерпретацию значений. Агент не должен запрашивать у базы данных, какие таблицы необходимо объединить для расчёта дохода; вместо этого он должен обращаться к семантическому слою за утверждёнными показателями дохода и допустимыми для использования размерностями.
Существуют два важных замечания, которые помогают сохранять объективность, поскольку эта область развивается быстро, и легко преувеличивать её потенциал. Официальный сервер MCP Cube, входящий в состав Cube Cloud и доступный через HTTPS с использованием OAuth, отличается от серверов MCP сообщества для Cube, таких как те, что распространяются через Smithery. Уровень их надёжности, поддержки и технического обслуживания различается, поэтому для производственного использования предпочтительнее официальный вариант. Кроме того, нативная поддержка MCP появилась в этой сфере совсем недавно — она добавлена поверх REST-, SQL- и GraphQL-API, которые эти продукты предлагали на протяжении многих лет. Этот подход работает, но это функционал 2025–2026 годов, поэтому необходимо убедиться, что он совместим с версией, которая у вас используется.
Более безопасная архитектура от начала до конца
При полном сборке поток выглядит следующим образом:
user question
→ AI analytics agent
→ MCP / tool call
→ semantic layer (approved metrics, dimensions, joins, segments, policies)
→ data warehouse
→ governed result
→ agent explanation
Агент не имеет полной свободы действий с необработанными данными. Он использует управляемый интерфейс, благодаря которому команда контролирует, какие метрики существуют, какие измерения являются допустимыми, как происходит объединение данных, какие фильтры разрешены, кто может просматривать те или иные строки, приходят ли ответы из кэша или из заранее агрегированных данных, и как запросы предоставляются через API. Это лучше, чем просто просить модель написать SQL в надежде на правильное выполнение бизнес-логики.
Пример применения: рост доходов
Запросите информацию о росте доходов компании за прошлый квартал. Без семантического слоя агент должен сам определить, в какой таблице хранятся данные о доходах, являются ли они валовыми, чистыми, зарегистрированными или признанными, учитываются ли возвраты, как идентифицируются корпоративные счета, какая колонка времени определяет прошлый квартал, требуется ли конвертация валют и может ли данный пользователь просматривать все сегменты данных. SQL-запрос может быть выполнен, но его выполнение не означает, что результат будет правильным.
Благодаря семантическому слою такие ответы уже существуют. Доход — это утверждённая метрика, корпоративные клиенты — утверждённый сегмент, дата заказа — утверждённая временная размерность; логика возврата средств определяется один раз, а политика доступа применяется в зависимости от того, кто запрашивает информацию. Агент не выдумывает новые метрики, а запрашивает уже утверждённые. Это отличает генерацию SQL на естественном языке от управляемого агентного анализа.
Что может пойти не так с прямым доступом к складу
Прямой доступ даёт агенту слишком много свободы для догадок, и сбои здесь предсказуемы:
- Выдумка метрик: доход рассчитывается иначе, чем на панели управления финансами.
- Неправильные объединения: запрос выполняется, но объединение приводит к дублированию строк или удалению записей.
- Отсутствие фильтров: отменённые заказы, тестовые учётные записи, удалённые записи или внутренние пользователи остаются в результатах.
Агентам, отвечающим на бизнес-вопросы, нужны более строгие механизмы контроля, чем те, что предоставляет генерация SQL. Им необходимы семантические ограничения.
Использование SQL без раскрытия исходных таблиц
Отказ от гибкости — это не цена регулирования. Зрелый семантический слой может сохранить возможность использования SQL, направив его на управляемые объекты вместо физических таблиц. В SQL API Cube каждый куб или представление выглядит как таблица, а его показатели, измерения и сегменты — как столбцы. Благодаря использованию протокола и диалекта Postgres почти любой клиент, поддерживающий Postgres, может подключиться.
Инструменты и агенты сохраняют возможность выполнения запросов в стиле SQL, но модель определяет, что можно запрашивать. Агент не просматривает сырые таблицы — он работает с утверждёнными метриками и размерностями, что представляет собой практический компромисс, ближе всего соответствующий способу работы аналитики в производственной среде.
Правила доступа имеют такое же значение, как и метрики
Для чат-агентов контроль доступа становится критически важным, поскольку чат-бокс позволяет задавать открытые вопросы. Кто-то пишет «покажите доход по клиентам», и системе необходимо знать, каких клиентов может просмотреть этот человек, какой регион или арендатор применим, а также разрешено ли получение деталей на уровне клиентов или должны возвращаться только агрегированные данные.
Cube применяет политики доступа и механизмы безопасности на уровне строк внутри семантического слоя. Такое расположение не случайно: никто не должен полагаться на агента для автоматического воспроизведения всех правил без дополнительных указаний. Запись фразы «никогда не раскрывать несанкционированные данные» в запрос представляет собой просьбу; ограничение конкретного пользователя определенными строками, измерениями и размерностями является механизмом обеспечения соблюдения правил. Механизм обеспечения соблюдения правил гораздо более эффективен и находится в слое данных, а не в запросе.
Аспекты производительности: кэширование и предварительная агрегация
Анализ в формате диалога носит итеративный характер. Человек сначала запрашивает данные о доходах по регионам, затем разделяет их по товарам, сравнивает с прошлым кварталом, после чего ограничивает анализ клиентами из категории корпоративных. Если каждый шаг превращается в новый сложный запрос к хранилищу данных, задержки и затраты растут быстро.
Предварительная агрегация данных и кэширование в Cube, обеспечиваемые его движком CubeStore, ускоряют выполнение распространённых аналитических запросов. Одним из отмеченных результатов стало примерно вдвое снижение затрат на склад после того, как агрегированные данные были перемещены в хранилище Cube. Таким образом, для часто задаваемых вопросов семантический слой выполняет функцию не только для управления данными, но и для повышения производительности.
Где это решение оправдывает себя
Больше всего выгоды получают агенты, отвечающие на вопросы о доходах, сегментах клиентов, использовании продуктов, встроенных аналитических инструментах для клиентов, операционных панелях управления, KPI и объяснениях показателей, а также любые сценарии самообслуживания в области BI.
Наибольшая польза проявляется там, где уже существуют стандартные определения. Определите один раз такие показатели, как ARR, MRR, доход, уровень оттока клиентов, удержание клиентов, активные пользователи, коэффициент конверсии, валовая маржа, время решения проблем и степень внедрения функций, и каждый агент будет использовать их заново, вместо того чтобы пересчитывать их при каждом изменении запроса.
В чём командам следует проявлять осторожность
Всё это не волшебство, и механизмы управления должны быть реальными, а не просто названиями. Неполная модель затрудняет работу агента. Неверные определения метрик приводят к получению корректно управляемых, но неверных чисел. Чрезмерно широкие политики доступа всё равно приводят к чрезмерной уязвимости данных. Модель, перегруженная запутанными почти идентичными метриками, позволяет агенту выбрать неверную из них. А если свежесть данных не видна, ответ может казаться актуальным, хотя основан на устаревших данных.
Поэтому важный вопрос заключается не в том, существует ли семантический слой, а в том, достаточно ли он качественным, чтобы агент мог им безопасно пользоваться. Модель должна быть задокументирована, иметь версии, проходить тестирование, подлежать контролю доступа и быть понятной, соответствовать панелям управления, которым люди уже доверяют, быть связанной с проверками качества данных и чётко указывать на свежесть и ограничения. Слабый слой приводит к слабым ответам агента.
От сырого SQL к управляемой аналитике
Различия между подходами заключаются в том, что видит агент и что может сломаться:
- Прямой преобразование текста в SQL: агент видит таблицы и столбцы склада, а основной риск — выдуманная бизнес-логика.
- SQL плюс документация схемы: это улучшение, но объединения таблиц и метрики по-прежнему легко используются неправильно.
- Только семантический слой: агент работает с определёнными метриками, измерениями, связями и правилами. Это более безопасно, причём качество контролируется моделью, стоящей за ним.
- Семантический слой плюс MCP: управляемый анализ, предоставляемый в виде инструментов для агентов, в настоящее время является лучшим решением для контролируемого искусственного интеллекта в аналитике.
Преобразование текста в SQL остаётся полезным, но для бизнес-аналитики оно должно осуществляться на основе управляемой семантики, а не на основе догадок относительно сырой схемы.
Чек-лист перед тем, как агент будет работать с бизнес-данными
- Сначала поместите основные метрики в семантический слой.
- Укажите, какие измерения и способы соединения считаются допустимыми.
- Внедрите политики доступа и правила на уровне строк в данном слое.
- Предоставьте управляемые API вместо исходных таблиц.
- Доступ к слою через MCP возможен только с использованием утвержденных официальных инструментов.
- Ведите журнал всех запросов агента вместе с генерируемыми ими SQL-запросами.
- Каждый ответ должен сопровождаться определением используемой метрики.
- В каждом ответе указывайте степень свежести данных.
- Повторяйте типовые бизнес-запросы и сравнивайте результаты с надежными дашбордами.
- Отключите прямой доступ к конфиденциальным таблицам склада.
- Определите, что происходит, если запрашиваемая метрика не имеет определения.
- Научите агента отвечать «не определено», вместо того чтобы импровизировать.
- Версионируйте определения метрик, как код.
- Протестируйте правила доступа с использованием реальных ролей пользователей.
- Обращайте внимание на запросы, которые возвращают ошибки или неоднозначные результаты.
Самое важное правило: если показатель не определён, агент не должен его выдумывать. Он должен попросить уточнения или сказать, что такого показателя нет.
Вопросы для команд по разработке продукта
Прежде чем предоставить новому аналитическому агенту полную схему склада, сначала остановитесь и урегулируйте несколько вопросов. Определите, на какие бизнес-вопросы он должен отвечать, какие показатели одобрены, какие измерения допустимы и какие соединения безопасны. Решите, кто может видеть что, насколько свежими должны быть данные, какие ответы требуют определения или ссылки, а какие запросы необходимо отклонить. Только после этого предоставляйте агенту суженный набор информации.
Куб — это один из способов построения поверхности данных, а dbt Semantic Layer, LookML и MetricFlow решают ту же проблему с других точек зрения. Основной урок не связан ни с каким конкретным продуктом: агентам необходимы управляемые бизнес-семантики перед тем, как они начинают работать с бизнес-данными.
Основная идея
Рассматривать аналитику с использованием ИИ исключительно как задачу преобразования текста в SQL — значит упускать суть, поскольку управление смыслом является более сложной частью. Агент, работающий с необработанными таблицами хранилища, может писать совершенно корректный SQL, но всё равно предоставлять неверные бизнес-ответы из-за выдуманных метрик, некорректных объединений, игнорирования прав доступа или данных, противоречащих данным на панели управления. Семантический слой меняет интерфейс: одобренные метрики, измерения, объединения, политики и API заменяют необработанную структуру данных, требующую интерпретации. MCP обеспечивает подключение, семантический слой — смысл, а управляемая аналитика нуждается в обоем.
Связанные материалы
- Создание агента для оценки качества потенциальных клиентов с использованием ИИ на Python с помощью FastAPI и Pydantic — Преобразование необработанных потенциальных клиентов в квалифицированных: структурированный извлечение данных с помощью LLM, проверка с использованием Pydantic, оценка по правилам, хранение в PostgreSQL, очереди и возможность ручного рассмотрения.
- Сравнение управляемых агентов: Anthropic, LangGraph и Google ADK — Кто контролирует среду выполнения, учетные данные и логи? Сравнение Anthropic Managed Agents, LangGraph и Google ADK с информацией о ценах, способах сбоев и кратким руководством по принятию решений.