Семантический слой и LLM

«ИИ скоро заменит аналитиков» — твердят маркетологи и продавцы BI-лицензий. Правда в том, что без семантического слоя ИИ не заменит даже самого ленивого стажёра. Он просто заменит его ошибками.

Давать большой языковой модели сырую схему базы данных — это как отправить очень умного, но абсолютно неопытного новичка на сложные переговоры с клиентом, вручив ему вместо вводных только технический паспорт продукта. Он знает термины и может красиво их скомбинировать, но итог будет либо сухим и неубедительным, либо вообще не тем, что нужно. В худшем случае — откровенная галлюцинация, от которой краснеют даже видавшие виды дата-инженеры.

Сейчас все помешаны на Text-to-SQL. Бизнес хочет написать в чат «покажи выручку за третий квартал» и мгновенно получить красивый график. Маркетологи трубят, что аналитики скоро станут бесполезны, а LLM заменят целые отделы BI. Но давайте спустимся с небес на землю и посмотрим, что происходит, когда вы скрещиваете жадную до данных нейросеть с вашей реальной, немытой базой данных.

Анатомия ИИ-галлюцинации

Когда вы скармливаете LLM сырой DDL-код (CREATE TABLE и всё такое), это напоминает бесконтрольную вечеринку без куратора. Модель видит много голых таблиц, быстро делает какие-то выводы, и поначалу вам даже кажется, что всё получилось. Но при свете монитора вы понимаете: джойны не те, агрегации уехали в космос, а выручка оказалась в три раза больше реальной из-за классического веерного соединения.

Проблема в том, что LLM — не оракул. Это просто очень продвинутый автодополнятор текста. Она не знает вашего бизнеса. Она не знает, что:

1. В таблице orders колонка status со значением 1 означает «оплачено», а не «в процессе», как можно было бы подумать.
2. При расчёте «чистой выручки» нужно вычесть не только налоги, но и refunds, которые лежат в совершенно другой таблице с хитрой логикой сторнирования.
3. Колонка created_at в таблице transactions — это время проведения платежа, а не время создания заказа, и для отчёта по продажам она не подходит.

Без контекста модель начинает угадывать. Если в генерации стихов ошибка не так страшна, то в аналитике галлюцинация LLM стоит денег. CFO получит не те цифры, примет неверное решение, а вы будете объяснять, почему ИИ решил, что маржинальность упала до минус сорока процентов.

Семантический слой как фильтр для данных

И вот тут на сцену выходит семантический слой. Если сырая база данных — это стихия и хаос, то семантический слой — это надёжный фильтр, который не даёт грязи попасть в финальный отчёт. Он берёт ваши таблицы, нормализованные до седьмой нормальной формы или, наоборот, денормализованные до состояния каши, и оборачивает их в чистые, понятные бизнес-сущности: измерения (Dimensions) и метрики (Metrics).

Когда вы подключаете семантический слой к вашему Text-to-SQL пайплайну, происходит магия. Вы больше не суёте LLM сырые схемы. Вы даёте ей готовый, выверенный контекст.

Как это работает под капотом

Давайте посмотрим, как именно семантический слой превращает вашего ИИ-аналитика из новичка в профи.

1. Метрики как объекты первого класса

Вместо того чтобы заставлять LLM писать простыню SQL вида SUM(CASE WHEN status = 'paid' THEN amount - refund ELSE 0 END), вы просто говорите ей: «Рассчитай метрику Net_Revenue». В семантическом слое (будь то Cube, dbt Semantic Layer или что-то другое) уже прописано, как именно считается Net_Revenue. LLM просто вызывает эту метрику. Ошибиться в формуле становится физически невозможно, потому что формула живёт не в голове у нейросети, а в коде семантического слоя.

2. Жёсткие и понятные связи

LLM обожает делать декартовы произведения, если ей не запретить. Семантический слой чётко указывает: «Таблица orders джойнится к users по полю user_id». Когда модель генерирует запрос, она использует эти предопределённые связи. Никаких случайных джойнов по полям, которые просто похожи по смыслу.

3. Обогащённый промпт (Context Injection)

Семантический слой выступает в роли богатого системного промпта. Он передаёт LLM не только структуру, но и бизнес-глоссарий. Модель видит: «Ага, когда пользователь спрашивает про "отток" (churn), мне нужно использовать метрику Churn_Rate, а не делить отвалившихся клиентов на общую базу». Это убирает двусмысленность.

Пример: до и после

Посмотрим, как отличается запрос.

Без семантического слоя LLM генерирует сырой SQL:

SELECT     DATE_TRUNC('month', o.created_at) as month,    SUM(o.total_amount) as revenueFROM orders oLEFT JOIN users u ON o.user_id = u.idWHERE o.status = 1GROUP BY 1;

Выглядит красиво, но total_amount включает налоги, status = 1 может быть не тем статусом, а джойн к users мог создать дубликаты, если у пользователя несколько адресов. Выручка в отчёте будет завышена.

С семантическим слоем LLM генерирует запрос к слою метрик:

{  "metrics": ["Net_Revenue"],  "dimensions": ["Date.Month"],  "filters": []}

Или, если она всё же пишет SQL, опирается на семантические представления:

SELECT     month,    Net_RevenueFROM semantic_layer.sales_monthly;

Вся сложная логика, фильтрация статусов, обработка возвратов и правильные джойны уже инкапсулированы внутри Net_Revenue. LLM просто берёт готовый, безопасный результат.

Итог

Тренды идут к тому, что классический Text-to-SQL, где нейросеть пишет сырой SQL с нуля, уступает место архитектуре, где LLM выступает в роли переводчика для семантического слоя. Нейросеть отлично понимает естественный язык, но ужасно понимает вашу специфическую бизнес-логику, если вы не объясните её явно.

Не позволяйте вашему ИИ хвататься за любые сырые таблицы и делать вид, что разбирается в ситуации. Дайте ему семантический слой — надёжного наставника, который знает предпочтения бизнеса, расставляет границы и подсказывает, что можно, а что нельзя.

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