Text-to-SQL: автоматическая генерация SQL из текста

Text-to-SQL: где ломается доступ к данным

Аналитик в типовой компании закрывает десятки внеплановых вопросов в неделю: «сколько клиентов вернулось в этом сегменте», «какая конверсия по каналу за квартал». Каждый такой вопрос — ручные SQL-запросы: найти нужную таблицу, вспомнить, как считается активность, не забыть исключить тестовые аккаунты. Очередь растёт быстрее, чем команда, и решение по цифрам откладывается на дни.

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

Именно здесь находится узкое место аналитики: доступ к данным упирается не в мощность хранилища, а в ручной перевод вопроса на язык запросов. Пока это делает человек, скорость ограничена его загрузкой, а корректность — тем, помнит ли он все договорённости о метриках.

Text-to-SQL снимает этот слой: вопрос на естественном языке превращается в запрос к заранее описанной модели данных, где метрики, связи таблиц и обязательные фильтры зафиксированы один раз. Генерация SQL из текста не заменяет аналитика — она убирает ожидание в очереди для типовых вопросов и убирает разнобой в определениях.

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

Что меняется в работе аналитической команды

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

Главная метрика — доля вопросов, закрытых без участия инженера. Типовые срезы (выручка по каналам, активность по когортам, конверсия по шагам воронки) перестают занимать очередь, и на команду остаются только задачи со сложной логикой: нестандартные соединения таблиц, оконные функции, расчёты поверх нескольких источников.

Время до ответа на вопрос уходит из диапазона «часы и сутки» в диапазон «минуты» — это и есть ускорение аналитики: оно про исчезновение ожидания, а не про скорость набора текста. Снижение нагрузки на аналитиков при этом не означает, что их работу отдали машине.

Отдельный эффект — уходит целый класс ошибок ручных выборок: забытый фильтр по периоду, неверно выбранный тип соединения, дубли строк на связи «многие ко многим», расхождение условий между отчётами. Генерация идёт от единого описания схемы, поэтому два человека, задавшие один вопрос разными словами, получают сопоставимые числа. Самостоятельная аналитика становится нормой для смежных команд, а аналитик занимается моделью данных, а не переписыванием однотипных запросов под каждого заказчика.

Text-to-SQL: варианты внедрения и их ограничения

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

Практически выбор сводится к четырём альтернативам — от готового сервиса до своей модели на схеме данных.

Ограничения, общие для всех вариантов

Генерация проверяет синтаксис и соответствие схеме, но не смысл вопроса — поэтому в любом контуре остаются доступ только на чтение, ограничение по числу строк и предварительный просмотр запроса перед выполнением. Если схема меняется чаще, чем раз в квартал, выбирайте вариант с автоматической сверкой метаданных: иначе запросы начнут падать на переименованных полях. Разбираем, какой вариант закрывает вашу схему.

Этапы внедрения: от аудита схемы до передачи

Внедрение text-to-sql начинается не с модели, а со схемы данных. Пока не описан словарь метрик — какие показатели считаются и из каких таблиц, — генерация запросов даёт правдоподобный, но неверный результат. Ниже последовательность, в которой риски снимаются до промышленной эксплуатации.

1. Аудит схемы данных: таблицы, связи, типы, дубли и «мусорные» исторические поля, представления из отчётности. На выходе — карта сущностей и список мест, требующих переименований или вычисляемых колонок.
2. Словарь метрик: определения выручки, активного клиента, конверсии — из каких таблиц и с какими фильтрами. Синонимы («клиент», «заказчик», «аккаунт») сводим к одному понятию.
3. Настройка генерации: схема и словарь становятся контекстом для модели, плюс ограничения — только чтение, обязательный фильтр по периоду, лимит объёма выборки.
4. Приёмка на исторических вопросах: берём реальные вопросы аналитиков и руководителей, сверяем сгенерированные запросы с эталонными ответами. Расхождения уточняют словарь, а не формулировку обращения к модели.
5. Разграничение доступа: роли наследуют права источника, пользователь не видит недоступные ему данные. Каждый запрос логируется — что спросили и что вернулось.
6. Передача: документация по словарю, схема развёртывания, набор эталонных вопросов и регламент обновлений при изменениях в источнике.

Артефакты внедрения: схемы, политики доступа, регламенты

После внедрения у заказчика остаётся комплект, по которому систему можно эксплуатировать и развивать без автора. Без него доработка начинается с обратного проектирования, а передача задач другому исполнителю обходится в недели простоя.

• Описание схемы данных. Таблицы, связи, ключи, назначение полей и пометки о тех, что нельзя использовать в генерации: устаревшие дубли, технические и расчётные столбцы.
• Слой бизнес-терминов. Соответствие «как называет сущность заказчик» → конкретные поля и таблицы. Именно он обеспечивает работу text-to-SQL, поэтому обновляется при каждом изменении схемы.
• Конфигурации и окружения. Параметры подключения, ограничения на объём выборки и время выполнения запроса, разграничение доступа между средами, настройки журналирования.
• Политики доступа. Какие роли видят какие схемы и столбцы, ограничения на уровне строк, правила маскирования персональных данных. Права проверяются до генерации, а не после.
• Эталонный набор вопросов с проверенным SQL. По нему после каждой правки прогоняется регрессия: доля корректных запросов известна до выката, а не по жалобам пользователей.
• Регламент работы с запросами. Как формулировать вопрос, кто проверяет результат, что делать при неверной генерации и как обратная связь возвращается в слой терминов.
• Регламенты сопровождения. Порядок обновления при миграции схемы, частота прогонов регрессии, версионирование конфигураций и откат на предыдущую версию.
• Журнал аудита и инструкции. История запросов с автором и результатом, памятки для пользователей и администраторов.

Кейс: разгрузка аналитиков и рост доверия к данным

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

Что было

Хуже другое: одни и те же метрики считались по-разному — кто-то брал дату заказа, кто-то дату отгрузки, кто-то вычитал возвраты. Руководитель видел две цифры по одному показателю и переставал доверять обеим. Причина была не в качестве хранилища, а в отсутствии единого определения метрики.

Что изменили

Мы описали семантический слой на dbt: у каждой метрики появилось одно определение, владелец и правило фильтрации. Генерация SQL из текста работает поверх этого слоя — модель видит только описанные сущности и не может выдумать поле или обойти фильтр. Простые вопросы бизнес закрывает сам, спорные уходят аналитику вместе с черновиком запроса. Сгенерированный запрос дополнительно прогоняется на эталонном наборе — расхождение видно до того, как цифра попадёт в отчёт.

Аналитики переключились на моделирование и разбор причин вместо выгрузок, а цифры в отчётах стали сходиться. Разгрузка команды здесь не самоцель: пока метрика определена один раз, ответ на вопрос воспроизводится в любой день и у любого сотрудника.

Что делать, если часть данных уже лежит в готовых витринах

Готовые витрины и генерация запросов решают разные задачи, и подменять одно другим не стоит. Витрина отвечает на уже известный вопрос предсказуемо и быстро, а генератор закрывает то, что заранее не перечислить: произвольные срезы, составные фильтры, разовые исследования. Вопрос не «или-или», а где провести границу между ними.

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

Расхождение метрик возникает там, где определение показателя живёт в двух местах. Лечится это единым слоем определений: выручка, активный клиент, возврат считаются один раз в трансформациях — ведём их на dbt — а витрины собираются из тех же моделей, к которым обращается генератор. Тогда «то же число другим запросом» перестаёт быть сюрпризом.

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

Технические сомнения: точность, безопасность, поддержка

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

Что происходит, если запрос всё-таки неверный?

Запрос выполняется в режиме только чтение, с лимитом строк и времени работы, поэтому ошибка не доходит до изменений в данных. При неоднозначной формулировке система задаёт уточняющий вопрос вместо догадки, а пара «вопрос — запрос — результат» попадает в журнал и становится материалом для правки описаний.

Как разграничивается доступ к данным?

Запрос идёт от имени пользователя, а не от сервисной учётной записи с полным доступом, поэтому ограничения на уровне таблиц и строк продолжают действовать. Руководитель направления и аналитик на один и тот же вопрос получат разные срезы.

Работает ли решение в закрытом контуре?

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

Обсудим задачу и вернёмся с оценкой и планом

Чтобы оценка внедрения text-to-sql была предметной, а не средней по рынку, к разговору стоит собрать несколько вводных. Всё это обычно уже есть у команды, которая работает с базой, — понадобится доступ к этим данным и полчаса на сбор.

• Схема базы: таблицы, связи и представления, к которым должны идти запросы. По ней сразу видно, где нужны синонимы и словарь бизнес-терминов.
• 20–50 реальных вопросов к данным — в тех формулировках, что используют аналитики и руководители, вместе с эталонными ответами.
• Сложные случаи: агрегаты по периодам, сравнение с прошлым отрезком, расчёт долей и накопительных итогов.
• Права доступа: какие роли и подразделения должны видеть какие строки и столбцы.
• Ограничения по нагрузке и режим работы с рабочей базой: только чтение, отдельная копия, окно для тяжёлых запросов.
• Куда попадает результат — отчёт, чат, выгрузка — и в каком виде его ждут пользователи.
• Как проверяем точность: доля вопросов, на которые система обязана отвечать верно.

Из этих вводных складывается план работ: словарь терминов, контур доступа, набор проверок и этапы внедрения с контрольными точками. Опишите задачу — вернёмся с вариантами решения, оценкой и планом работ.