ИИ для SQL-запросов: сложные выборки без риска в 2026

Обновлено в июне 2026: я переработал статью под практику Text2SQL, добавил проверку запросов, шаблон промпта и безопасный рабочий процесс.

Раньше разговор про генерацию SQL нейросетью часто сводился к простой просьбе: «напиши запрос». Такой подход работает на витринных примерах, где есть одна таблица orders и три понятных поля. В живой аналитике всё иначе. Есть витрина продаж, справочник клиентов, таблица возвратов, календарь, статусы оплат, часовые пояса, дубли и поля с историческими названиями. Один неверный JOIN может раздуть выручку в 3 раза, а забытый фильтр по дате покажет красивую, но бесполезную цифру.

Я отношусь к нейросети как к младшему SQL-аналитику, который быстро пишет черновик, но не знает внутренней кухни базы. Ей надо дать схему, правила бизнеса, примеры правильных запросов и критерии проверки. Тогда задача меняется: мы не просим «угадать SQL», а строим управляемый процесс от вопроса к проверенной выборке.

Что изменилось в обновлённой версии статьи

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

Обновление затронуло три места. Первое, раздел про инструменты: теперь фокус не на названиях моделей, а на том, какие условия нужны любой языковой модели для нормального SQL. Второе, безопасность: запрос надо запускать сначала с LIMIT, под read-only пользователем и без прав на изменение данных. Третье, контроль качества: я добавил чек-лист, который ловит типовые ошибки, от лишнего INNER JOIN до неверной группировки по месяцу.

Если вы только выстраиваете работу с запросами к нейросети, сначала полезно освоить базовую механику постановки задач. Я подробно разбирал её в статье про правильную формулировку запросов для нейросетей, а здесь покажу тот же принцип на SQL.

Где нейросеть реально экономит время аналитика

Самый заметный выигрыш появляется не на запросах в 5 строк, а на задачах с несколькими таблицами, окнами, подзапросами и условиями. Например, аналитик хочет посчитать удержание клиентов по когортам: дата первой покупки, повторная покупка в течение 30 дней, исключение отменённых заказов, группировка по месяцу регистрации. Вручную такой запрос легко превращается в 80–120 строк SQL. Черновик нейросеть может собрать за минуты, если ей дать схему и правила.

Практические зоны экономии выглядят так:

Условный пример: интернет-магазин с таблицами orders, order_items, payments и refunds просит получить валовую выручку за 12 месяцев, исключить отмены и отдельно показать долю возвратов. Без контекста нейросеть может сложить все оплаты и забыть возвраты. С контекстом она получает правило: «выручка считается по успешным платежам, возвраты вычитаются по дате возврата, тестовые заказы исключаются». Разница между этими двумя постановками, это разница между красивым текстом запроса и аналитическим результатом.

Почему одного вопроса недостаточно

SQL зависит от схемы сильнее, чем обычный текст зависит от темы. Названия полей часто обманчивы. created_at может означать дату создания заказа, дату попадания в CRM или техническую дату записи. Поле status = paid не всегда равно успешной оплате, если деньги подтверждаются в отдельной таблице. В одной базе клиент хранится как user_id, в другой как account_id, в третьей одна компания имеет несколько пользователей.

Поэтому я начинаю с контекста. Минимальный пакет для нейросети занимает 30–80 строк текста и включает:

1. Названия таблиц и 5–10 главных полей в каждой.
2. Связи между таблицами: один-к-одному, один-ко-многим, многие-ко-многим.
3. Словарь метрик: что значит «выручка», «активный клиент», «повторная покупка».
4. Диалект SQL: синтаксис функций дат и ограничений отличается между СУБД.
5. Ограничения: не использовать изменение данных, сначала писать только SELECT.
6. Пример правильного запроса на похожую задачу.

Для повторяемых задач удобно держать такой контекст в шаблоне. В SoftChat можно использовать шаблоны промптов для стартовых формулировок и вести диалог с сохранённой историей в рамках организации. Это подходит для сценария, где команда постепенно уточняет словарь метрик и возвращается к прошлым обсуждениям. Если нужен отдельный стиль ответа, например «сначала объясняй логику, потом давай SQL», в диалоге можно задать системную инструкцию или работать с кастомным ассистентом.

Шаблон запроса для сложного SQL

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

Ты помогаешь написать безопасный SQL-запрос для аналитической выборки.
Диалект SQL: PostgreSQL.
Пиши только SELECT, без INSERT, UPDATE, DELETE, DROP, ALTER.

Задача бизнеса:
Посчитать удержание покупателей по месяцу первой покупки и долю повторных покупок в течение 30 дней.

Схема:
customers(id, created_at, segment, is_test)
orders(id, customer_id, created_at, status, total_amount)
payments(id, order_id, paid_at, status, amount)

Связи:
orders.customer_id = customers.id
payments.order_id = orders.id
У одного заказа может быть несколько платежей.

Правила метрик:
Покупатель считается реальным, если customers.is_test = false.
Покупка учитывается, если orders.status = 'completed' и есть payment.status = 'success'.
Дата покупки, это paid_at.
Повторная покупка, это вторая успешная покупка в течение 30 дней после первой.

Формат ответа:
1. Кратко объясни логику.
2. Дай SQL.
3. Перечисли 5 проверок результата.

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

Пошаговый рабочий процесс

Я бы не запускал сгенерированный SQL сразу на полной базе. Надёжнее идти по этапам.

Шаг 1. Сформулируйте аналитический вопрос одной строкой. Например: «Какая доля клиентов делает вторую покупку в течение 30 дней после первой успешной оплаты?» Если вопрос нельзя выразить одной строкой, сначала уточните его с заказчиком.

Шаг 2. Добавьте словарь метрик. Для удержания нужны минимум 4 определения: кто клиент, что считается покупкой, какая дата считается датой покупки, что такое повтор.

Шаг 3. Передайте схему таблиц. Достаточно полей, которые участвуют в фильтрах, соединениях, группировке и расчётах. Типы данных помогают: дата, число, строка, булево поле.

Шаг 4. Попросите объяснить логику до SQL. Если объяснение уже неверное, запрос почти наверняка неверен. Я часто прошу: «Сначала опиши план в 5 пунктах, затем напиши SQL».

Шаг 5. Запустите запрос на ограниченной выборке. Используйте LIMIT 100, фильтр по одному месяцу или тестовую копию. Для тяжёлых таблиц сначала посмотрите EXPLAIN. Если план показывает полное сканирование миллиардной таблицы, запрос надо переписать до запуска.

Шаг 6. Сверьте контрольные числа. Берите 3–5 известных значений: число заказов за вчера, сумма оплат за один день, количество тестовых клиентов. Если базовая проверка не сходится, сложная метрика не заслуживает доверия.

Такой процесс хорошо сочетается с обычным внедрением нейросетей в работу: сначала один повторяемый сценарий, затем шаблоны, затем правила проверки. Я описывал эту логику шире в материале про внедрение нейросетей в рабочие процессы.

Как проверять SQL, который написала нейросеть

Проверка нужна даже тогда, когда запрос выглядит аккуратно. Красивое форматирование не доказывает корректность. Я смотрю на 8 пунктов.

1. Тип соединения. INNER JOIN удаляет строки без совпадения. Для отчёта по всем клиентам часто нужен LEFT JOIN.
2. Кардинальность. Если заказ соединён с несколькими платежами и несколькими товарами, сумма может умножиться.
3. Фильтры по статусам. completed, paid, success, refunded нельзя считать взаимозаменяемыми без правил бизнеса.
4. Границы дат. Интервал BETWEEN '2026-01-01' AND '2026-01-31' может потерять записи после полуночи последнего дня, если поле содержит время.
5. Часовой пояс. Отчёт по Москве и отчёт по UTC дают разные сутки на границах дня.
6. Дубли клиентов. Один человек может иметь несколько аккаунтов, если в компании нет нормализации идентификаторов.
7. Нули и пустые значения. Деление на ноль и NULL часто ломают доли.
8. Производительность. Оконные функции по всей таблице без предварительного фильтра могут работать минуты или часы.

Для примера: если запрос считает средний чек по таблице заказов и присоединяет строки товаров, заказ с 5 позициями попадёт в расчёт 5 раз. Лечение простое: сначала агрегировать товары до уровня заказа, затем соединять с платежами. Нейросеть может предложить этот вариант, если прямо попросить: «Проверь риск умножения строк при соединениях».

Что можно делать в SoftChat, а что остаётся за вами

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

При этом SoftChat не надо превращать в инструмент исполнения SQL. Запуск запроса, права доступа, подключение к базе, мониторинг нагрузки и аудит остаются на стороне вашей аналитической инфраструктуры. Это здоровое разделение. Нейросеть пишет и объясняет. Человек проверяет. База выполняет запрос под контролируемыми правами.

Для команд полезны две привычки. Первая, хранить проверенные промпты как шаблоны: «когортный анализ», «воронка», «поиск дублей», «сверка оплат». Вторая, просить модель после каждого SQL дать раздел «Риски запроса». Там должны появиться дубли, неверные статусы, тяжёлые соединения и спорные границы дат.

Пример разбора сложной аналитической задачи

Условный пример: компания из сферы подписочного SaaS, ~80 сотрудников, хочет понять, сколько платящих клиентов продлевают подписку на второй месяц. Есть таблицы accounts, subscriptions, invoices, payments, plans. Задача кажется простой, но в ней есть минимум 6 ловушек: бесплатный пробный период, смена тарифа, отмена с последующим возвратом, неуспешный платёж, ручная скидка, несколько аккаунтов у одной компании.

Хороший запрос к нейросети в таком случае начинается не с «напиши SQL», а с описания правил:

Продление считается успешным, если второй оплаченный счёт имеет payment.status = 'success'.
Пробный период не считаем оплатой.
Смена тарифа внутри первого месяца не считается продлением.
Если был возврат всей суммы, платёж исключаем.
Группировка нужна по месяцу первой успешной оплаты.

После этого модель может собрать запрос с несколькими CTE: paid_invoices, first_payment, second_month_payment, финальная агрегация по месяцу. CTE удобны тем, что каждый блок можно проверить отдельно. Сначала считаем успешные оплаты. Затем первую оплату по аккаунту. Затем факт продления. Потом долю.

Я предпочитаю просить модель добавлять диагностические запросы. Например: «Дай отдельный SQL, который покажет 20 аккаунтов, попавших в продление, с датами первой и второй оплаты». Такая выборка помогает быстро увидеть странности: вторая оплата через 2 дня, отрицательная сумма, один и тот же счёт дважды.

Типовые ошибки Text2SQL

У нейросетей есть устойчивые ошибки, которые повторяются в разных базах.

Придуманные поля. Модель может написать users.email_verified, хотя в схеме есть только confirmed_at. Это лечится жёсткой инструкцией: «используй только перечисленные таблицы и поля».

Слишком уверенные предположения. Если в задаче не сказано, как считать возвраты, модель может выбрать удобный вариант. Просите задавать уточняющие вопросы, когда правила метрики неполные.

Неверный диалект. Функция даты из одной СУБД не всегда работает в другой. Указывайте диалект в первой строке промпта.

Запрос без проверки производительности. Для маленькой тестовой базы всё летает. На таблице в сотни миллионов строк тот же SQL может упереться в сортировку или соединение без индекса. Попросите вариант с предварительной фильтрацией и объяснением, какие индексы помогут.

Смешение бизнес-даты и технической даты. В отчётах почти всегда есть спор между created_at, paid_at, closed_at, shipped_at. Называйте нужную дату явно.

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

Безопасность: какие ограничения ставить сразу

Безопасный режим для Text2SQL начинается с прав. Пользователь, под которым аналитик проверяет запрос, должен иметь только чтение. Команды INSERT, UPDATE, DELETE, DROP, ALTER, TRUNCATE надо запретить на уровне роли, а не только в тексте промпта. Промпт снижает риск, права его закрывают.

Второй слой, ограничение объёма. Для первичной проверки используйте один период, один сегмент или LIMIT. Если запрос строит временную таблицу или сортирует большой набор, сначала нужен план выполнения. В ряде СУБД можно поставить таймаут запроса, например 30–120 секунд для интерактивной аналитики. Конкретное значение зависит от хранилища и нагрузки.

Третий слой, маскирование чувствительных данных. Нейросети обычно не нужен список почт, телефонов или ФИО, чтобы написать SQL. Для промпта достаточно схемы и 3–5 обезличенных примеров строк. Если нужно показать формат значения, замените реальные данные на синтетические: user_001@example.test, 79990000000, Иванов И..

Когда нейросеть лучше не использовать

Есть задачи, где Text2SQL даёт слабый выигрыш. Если запрос меняет данные в продакшене, его должен писать и ревьюить инженер по обычному процессу. Если метрика юридически значима, например для финансовой отчётности, нейросеть может помочь с черновиком, но итоговый SQL требует формального контроля. Если схема базы закрыта или плохо описана, сначала надо навести порядок в документации.

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

Заключение: обновлённый подход к SQL с нейросетью

Обновлённая версия статьи сводится к простой практике: нейросеть ускоряет написание SQL, если вы управляете контекстом и проверкой. Дайте схему, правила метрик, диалект, примеры и ограничения. Попросите объяснение до запроса. Запускайте SQL сначала на малом объёме. Проверяйте дубли, статусы, даты, кардинальность и план выполнения.

Такой подход не заменяет аналитика. Он снимает рутину: набросать CTE, переписать вложенный запрос, добавить оконную функцию, составить чек-лист проверки. Часы уходят не на борьбу с синтаксисом, а на смысл метрики. Именно там человек всё ещё незаменим: понять вопрос, заметить странность в данных и не принять аккуратный SQL за истину.