Чому агентам аналітики ШІ потрібен семантичний шар замість сирого 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 перетворюються на Revenue, Enterprise Customer, Order Date та Refund-Adjusted Revenue. Агентам потрібна така термінологія. Без семантичного шару агент аналізує схему та робить висновки самостійно. З його наявністю агент працює за затвердженими визначеннями. Агент все ще не є ідеальним, але одна з основних причин хиб у аналітиці зникає, оскільки визначення показників більше не потрібно відновлювати з необроблених таблиць.
Це категорія, а не окремий продукт. Cube, dbt Semantic Layer (створений на основі MetricFlow) та Looker’s LookML — кожен з них вирішує ту саму проблему у власних екосистемах. Cube привертає увагу тут через те, що його підхід для агентів є надзвичайно повним, хоча архітектура має більше значення, ніж бренд.
Чому Cube є гарним прикладом
Cube — це не лише шар панелей керування. Один керований модель живить інструменти BI, вбудовану аналітику, API та AI-агентів, створених на основі кубів, показників, вимірів, з’єднань, сегментів, ієрархій, попередніх агрегацій та політик доступу. Це майже точно ті елементи, які потрібні аналітичному агенту.
Його власний опис дизайну добре відображає суть: агенти не запитують базу даних безпосередньо, вони запитують семантичний шар, а механізм виконання виступає як захисний бар’єр між агентом та базою даних.
Порівняйте, що кожен з них передає моделі. Якщо надати необроблену таблицю, вона бачить лише назви стовпців. Якщо надати семантичний шар, вона також отримує схвалені концепції, обчислення, які стоять за ними, способи їхнього взаємозв’язку, те, до чого може дістатися поточний користувач, та безпечний спосіб запиту. Перевірка бізнес-логіки з кожним запитом є марною, тому агент повинен запитувати шар, який вже містить її.
З’єднання плюс значення: де застосовується 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: керована аналітика, яка доступна як інструменти агента, наразі є найкращим варіантом для контрольованої AI-аналітики.
Переклад тексту у SQL залишається корисним, але для бізнес-аналітики його слід використовувати на основі керованої семантики, а не припущень щодо сирої схеми.
Чек-лист перед тим, як агент буде працювати з бізнес-даними
- Спочатку розмістіть основні метрики у семантичному шарі.
- Вказати конкретно, які виміри та з’єднання є допустимими.
- Забезпечити дотримання політик доступу та правил на рівні рядків у цьому шарі.
- Надати керовані API замість первинних таблиць.
- Доступ до шару через MCP можливий лише за допомогою схвалених офіційних інструментів.
- Вести журнал кожного запиту агента разом із SQL-запитом, який він створив.
- Надсилати кожну відповідь разом із визначенням метрики, яка її підтримує.
- У кожній відповіді вказувати, наскільки свіжими є дані.
- Перевіряти знайомі бізнес-запити та порівнювати результати з надійними панелями керування.
- Заборонити прямий доступ до конфіденційних таблиць складу.
- Вирішити, що робити, якщо запитувана метрика не має визначення.
- Навчити агента відповідати «не визначено», замість того щоб імпровізувати.
- Версіонувати визначення метрик, як код.
- Протестувати правила доступу з використанням реальних ролей користувачів.
- Стежте за запитами, які повертають помилки або неоднозначні результати.
Найважливіше правило: якщо певна метрика не визначена, агент не повинен її вигадувати. Він має запитати про уточнення або сказати, що метрика недоступна.
Питання до команд з розробки продукту
Перш ніж надати новому аналітичному агенту повну схему складу, зупиніться та вирішіть кілька речей спочатку. Визначте бізнес-питання, на які він має відповідати, схвалені метрики, допустимі виміри та безпечні способи об’єднання даних. Вирішіть, хто може бачити що, наскільки свіжими мають бути дані, які відповіді потребують визначення чи посилання, а які запити слід відхилити. Лише тоді представте цю скорочену структуру агенту.
Куб — це один із способів створення поверхні даних, а dbt Semantic Layer, LookML та MetricFlow підходять до цієї проблеми з інших ракурсів. Основний урок не пов’язаний із конкретним продуктом. Агентам потрібна контрольована бізнес-семантика перед тим, як вони почнуть працювати з бізнес-даними.
Ключова ідея
Розглядання аналітики на основі ШІ як суто завдання перетворення тексту на SQL призводить до неправильного розуміння суті, адже керування значеннями є складнішою частиною. Агент, який працює з необробленими таблицями складу, може писати абсолютно коректний SQL, проте все одно надавати неправильні бізнес-відповіді через вигадані показники, некоректні з’єднання, ігнорування правил доступу чи цифри, що суперечать дашборду. Семантичний шар змінює інтерфейс: схвалені показники, виміри, з’єднання, політики та API замінюють необроблену схему, яку потрібно інтерпретувати. MCP забезпечує з’єднання, семантичний шар — значення, а контрольована аналітика потребує обох.
Пов’язана література
- Створіть агента для оцінки якості потенційних клієнтів за допомогою AI у Python з використанням FastAPI та Pydantic — Перетворіть необроблені потенційні клієнти на кваліфікованих: структуроване видобуття даних за допомогою LLM, перевірка за допомогою Pydantic, оцінка за правилами, зберігання у PostgreSQL, черги та можливість людського перегляду.
- Порівняння керованих агентів: Anthropic, LangGraph та Google ADK — Хто керує сандбоксом, обліковими даними та логами? Порівняння Anthropic Managed Agents, LangGraph та Google ADK з точками ціноутворення, способами збоїв та коротким посібником з прийняття рішень.