ИИ знает о структуре ваших таблиц, но это не помогает автоматизировать вашу аналитику

Год назад казалось, что ИИ решит все проблемы с SQL. Подключи к базе — и аналитик больше не нужен. Реальность оказалась другой.

Вот что происходит на практике.

Подключаете LLM к PostgreSQL. Спрашиваете: «покажи продажи за последний квартал по регионам». Модель пишет SQL, запускает, получает данные. Отлично.

На следующий день: «а теперь добавь динамику по месяцам». Модель галлюцинирует имена таблиц. Та же модель, та же база — но контекст схемы не сохранился.

Это не баг. Это архитектура. Большинство LLM-ассистентов получают схему через `information_schema` в начале каждого запроса. Они не помнят, как данные связаны между собой — только что существуют.

information_schema говорит: «есть таблица orders, в ней колонки id, customer_id, amount, status». Это синтаксис.

Но чтобы ответить на реальный бизнес-вопрос, нужно знать:

- что customer_id в orders джойнится с clients.id, а не с users.id (в базе две пользовательские таблицы с разной историей)

- что amount — это сумма без НДС, а total_amount — с

- что статус cancelled_refund нужно исключать из большинства витрин, потому что так решили три года назад

Это знание о данных — data lineage, бизнес-семантика, история решений. Его нет в схеме. Его не выведет LLM без контекста.

Вместо «дай модели доступ к базе» — дай модели карту данных: как объекты связаны, какие трансформации применяются, что откуда считается.

Это и есть происхождение данных (data lineage). Не как инфраструктурный инструмент для DBA, а как контекст для AI.

Когда у модели есть граф зависимостей — она знает, что revenue_by_region считается из sales_facts, которая джойнит orders и geo_mapping. Она не придумывает колонки. Она пишет правильный SQL.

Уровень 1 — структура (что есть): таблицы, колонки, типы. Это то, что даёт information_schema. Модели этого хватает для синтаксически верного SQL.

Уровень 2 — lineage (откуда берётся): как данные трансформируются через процедуры, представления, ETL. Модель с этим контекстом пишет семантически верный SQL.

Уровень 3 — бизнес-семантика (что значит): почему amount ≠ revenue, когда исключать статусы, какие правила заложены в логику витрин. Пока это в головах аналитиков и в комментариях к PR трёхлетней давности.

Большинство AI-ассистентов останавливаются на уровне 1. Уровень 2 — технически решаем уже сейчас. Уровень 3 — следующий горизонт.

AI governance растёт примерно на 40% в год. Регуляторы начинают спрашивать: на каких данных обучена модель? Откуда берутся входные данные для AI-решений?

Ответить на этот вопрос без происхождения данных невозможно. Не потому что это требование комплаенса — а потому что без него вы сами не знаете, на что влияет изменение в источнике.

Data lineage становится не инфраструктурным артефактом, а частью AI-стека.

Я исследую подходы к аналитике данных — без ИИ и с помощью ИИ в Seiðr Studio. Пишу об этом в Телеграмм-канале: https://t.me/SampleofOne