🧠➡️🗃️ Text-to-SQL и семантический слой: почему LLM не убил аналитика(хотя и сильно повлияло на рынок)

Мой тезис из поста про будущее: «1 Data-спец + LLM закроет весь цикл». Пора его уточнить. Есть место, где LLM красиво падает лицом в стол - когда его пускают напрямую к сырой схеме БД. Разбираемся, почему Text-to-SQL работает на демке и разваливается на проде.

🎬 Обещание вендоров
Пишешь «покажи выручку по регионам за Q2» → LLM генерит SQL → готово. На трёх таблицах магия работает, все в восторге.

🔴 Почему ломается на реальном DWH (это уже прозвали accuracy cliff)

LLM угадывает смысл данных по косвенным признакам — именам таблиц и колонок. Он не знает, что такое «активный клиент», какой из пяти столбцов revenue настоящий и где soft-delete. И вы можете хоть усраться с инструкцией - промптом это все не работает поверьте мне я пытался такую систему создать почти год.

200 таблиц не влезут в контекст. Чтобы демо взлетело, схему грузят в промпт целиком - на большой базе так нельзя.

Самое опасное: ошибка Text-to-SQL выглядит не как ошибка, а как правдоподобный НЕправильный ответ. Запрос отработал, цифра красивая - а join не тот. Глазами это не ловится.
Порядок величин: в бенчмарке dbt (2026) на «сложных» вопросах голый Text-to-SQL давал ~50–65% верных ответов. Почти половина - тихий брак. Это проверено лично мной это с воздуха цифры.

🟢 Что реально помогает - семантический слой
dbt Semantic Layer, Cube, LookML.
Метрики, сущности и связи описаны один раз и версионируются в git.
Дальше LLM обращается не к 200 сырым таблицам, а к метрике revenue - а слой сам разворачивает корректный SQL(из RAG памяти) с нужными джойнами и фильтрами.
Ключевая разница - слой детерминирован. Вопрос вне его области → ты получаешь ошибку, а не выдуманную цифру. В том же бенчмарке на вопросах «в области» слоя точность - 66-78%. Это уже сильно лучше но построение этой архитектуры это большой сложный пайплайн + надо его поддерживать решать проблемы улучшать ответы, делать тюн модели, авто расширять RAG память.
И вот эти все приседания стоят месяцев работы, кучи сгоревших токенов, времени специалиста а эффект как бы по прежнему не 100%.
При этом человек пописавший SELECTы придет с какой то доказательной базой к стейкхолдерам и докажет свою точку зрения на данных, LLM вы либо верите либо нет 😁 потому что ее доказательства они могут быть какими угодно - дабы угодить пользователю - то есть вам. Таков принцип этих моделей давать вам средневзвешанное наиболее подходящее.

🧰 Плюс паттерны grounding (пока слоя нет)

RAG по описаниям таблиц и бизнес-глоссарию;
few-shot из проверенных, «золотых» запросов;
LLM работает не по всей схеме, а по ограниченному набору вью;
«LLM предлагает - тесты/человек подтверждают», а не «LLM сразу в прод».

🛠 Мой взгляд - что это значит для DE и других DATA специалистов.
LLM сдвигает работу не в «писать меньше SQL», а в «строить семантику и контракты, на которые модель может опереться». Инженер данных = тот, кто делает данные понятными для машины: чистые метрики, документированные сущности, governance. Это и есть та самая «база» из прошлых постов - архитектура важнее синтаксиса.
И это лищь продолжение поста(мысли) про каталоги: семантический слой + governance — ровно то, без чего нельзя пускать к данным ни аналитика-LLM, ни автономного агента.

Есть еще один слой в этом посте который я давно уже заметил. Ваш ИИ помошник - настолько же умен, насколько умны вы 😎. Я расскрою тему вам в следующем посте по теме ИИшных дел.

Пробовали Text-to-SQL на проде? Взлетело или тихо врало? И строите ли семантический слой — dbt, Cube, LookML, своё? 👇

#data_engineering #AI #LLM #text2sql #semantic_layer #DataJungle