Нейросеть для аналитики: SQL-запросы и отчёты

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

Что подавать на вход

Без этого модель работает вслепую и додумывает.

Схему таблиц. Названия таблиц, столбцов и типы. Это главное: без схемы модель придумает orders.total_amount, когда у вас orders.sum_total.

Описания столбцов. Не только имя, но и что в нём лежит. status — это что: строка, число, какие значения бывают? Одна строка описания снимает целый класс ошибок.

Связи между таблицами. По каким ключам соединяются. Иначе получите соединение по совпадающим названиям, а не по смыслу.

Особенности данных. Мягкое удаление, тестовые записи, дубли, единицы измерения. То, что аналитик знает и не проговаривает, — самая частая причина неверных цифр.

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

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

Что модель делает хорошо

Пять операций, где выигрыш очевиден.

Черновик запроса по вопросу словами. «Сколько заказов по регионам за прошлый месяц» — рабочая заготовка за секунды.

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

Переписывание под другую задачу. Взять существующий запрос и поменять группировку или период.

Поиск ошибки в запросе. Особенно синтаксической и особенно в длинном.

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

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

Что она делает плохо

Список, который определяет границы применения.

Арифметику. Считать по данным должна база, а не модель. Она может сложить и ошибиться, подав результат как вычисленный.

Бизнес-логику, которой нет в схеме. «Активный клиент» у вас определяется как-то конкретно; модель предположит своё.

Выбор метрики. Вопрос «как измерить успех кампании» — это не про SQL.

Интерпретацию. Что означает падение на 12% — вопрос к человеку, знающему контекст.

Молчаливо неверный запрос. Самая опасная категория: выполняется, возвращает числа, считает не то. Ни синтаксическая проверка, ни отсутствие ошибок этого не ловят.

Последний пункт — прямое следствие того, что модель достраивает правдоподобное. В аналитике это особенно опасно, потому что результат выглядит как факт, а не как мнение.

Обязательные проверки

Пять, без которых схему нельзя пускать дальше эксперимента.

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

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

Смотрите на порядок величин. Ответ на порядок больше или меньше ожидаемого — сигнал, даже если формально всё корректно.

Проверяйте, что не потеряны строки. Классическая ошибка — соединение, которое молча отбрасывает часть данных.

Читайте запрос глазами перед боевым прогоном. Модель ускоряет написание, а не отменяет ревью.

Практическое правило: проверяйте результат, а не текст запроса. Красивый запрос, считающий не то, встречается чаще, чем кривой.

Как не пустить модель туда, куда не следует

Раздел про доступ, и он важнее всего остального.

Модель не должна выполнять запросы. Она возвращает текст, выполняет ваш код. Между намерением и выполнением всегда стоит ваша программа — как это устроено при вызове функций.

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

Белый список таблиц. Модель не должна даже видеть схему того, к чему ей нельзя.

Никаких персональных данных в схеме и примерах. Схема уходит в модель при каждом запросе; примеры с настоящими именами клиентов уходят вместе с ней — что вообще уходит провайдеру.

Отдельный ключ на этот сценарий. Видимый расход и локализованный риск — как их хранить.

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

Сколько это стоит

Приятная часть, с одной оговоркой.

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

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

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

Для этой задачи почти наверняка достаточно недорогой позиции: в каталоге на 5 сентября 2026 года платные текстовые начинаются от 1 ₽ за миллион, восемь позиций тарифицируются по нулевой ставке — что там доступно.

Как встроить в работу

Порядок, который окупается быстрее всего.

1. Начните с помощника для аналитика, а не с интерфейса для всех. Человек, который умеет читать SQL, поймает ошибку; остальные — нет.
2. Соберите двадцать типовых вопросов с эталонными запросами. Это и проверка качества, и примеры для промпта — как тестировать.
3. Опишите схему один раз и держите её в конфигурации. Она меняется реже, чем вопросы.
4. Логируйте вопрос, запрос и результат. Через неделю станет видно, где модель систематически ошибается.
5. Расширяйте на других сотрудников только после этого — и с проверкой прав и белым списком таблиц.

Чего мы не утверждаем

Не сравниваем модели по качеству SQL. Своих замеров мы не делали; проверять надо на своей схеме и своём диалекте.

Не рекомендуем конкретные инструменты. Их много, и выбор зависит от вашего стека.

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

Что нужно, чтобы попробовать

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов. Оплата российской картой в рублях, один ключ на весь каталог.

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

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

Что держать в голове

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

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

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Проверить на своей схеме: keydealer.ru/login.