Как проверять SQL, написанный ИИ: безопасный стенд, тестовые запросы и ручное подтверждение

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

Этот гайд предназначен для аналитика или владельца небольшого отчёта, который хочет ускорить подготовку черновика запроса, не отдавая модели право менять базу. Он не заменяет обзор безопасности вашей инфраструктуры и не является готовой инструкцией для любой СУБД. Названия команд, синтаксис и роли различаются; перед применением сверяйтесь с документацией используемой базы и внутренними правилами компании.

Шаг 1. Уменьшите последствия возможной ошибки

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

Не отправляйте в публичный сервис персональные данные и секреты подключения. Удалите имена, адреса, токены, клиентские идентификаторы и комментарии, которые не нужны для логики запроса. Если для работы требуется схема, подготовьте минимальный словарь: название поля, тип, смысл, связь с другими таблицами и известные исключения. Проверяйте политику хранения и использования данных конкретного сервиса; слово «чат» само по себе ничего не говорит о том, кто увидит содержимое.

Шаг 2. Опишите бизнес-вопрос до запроса

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

Полезный запрос к помощнику ограничивает задачу: «Предложи SELECT для этой схемы; не используй неизвестные столбцы; покажи допущения; добавь фильтр по периоду; не выполняй запрос». Запрос должен оставаться черновиком. Если модель предлагает несколько трактовок, зафиксируйте, какая согласована с владельцем данных. Для регулярных метрик храните определения рядом с SQL, а не в устном объяснении.

Шаг 3. Подготовьте эталонные случаи

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

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

Шаг 4. Сначала проверяйте запрос, не исполняя его

Прочитайте каждую таблицу и соединение. Подтвердите, что агрегирование делается на правильном уровне, фильтр даты включает ожидаемые границы, а JOIN не размножает строки. Посмотрите, не использует ли черновик UPDATE, DELETE, INSERT, DDL-команды или подзапросы, которые не нужны для чтения. Если локальный синтаксис позволяет выполнять несколько выражений, проверьте каждое отдельно и не полагайтесь только на слово «SELECT» в начале.

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

Шаг 5. Запустите на копии с ограничениями

Используйте тестовую среду, EXPLAIN или аналогичный план запроса, если ваша СУБД это поддерживает. Поставьте ограничение строк для предварительной проверки и короткий тайм-аут. Важно: LIMIT ограничивает возвращаемые строки, но не всегда уменьшает объём сканирования. План выполнения помогает увидеть тяжёлые соединения и отсутствие индекса, однако не подтверждает правильность бизнес-смысла.

Сверьте результат минимум двумя способами: с известным ручным расчётом и независимым запросом по другой логике. Проверьте суммы до и после группировки, число уникальных заказов и количество исходных строк. Если модель дала объяснение, сопоставьте его с фактическими частями запроса. Не публикуйте показатель в отчёте, пока ответственное лицо не подтвердило и код, и смысл числа.

Шаг 6. Зафиксируйте процесс и пределы

Храните исходный вопрос, версию схемы, запрос модели, правки аналитика, контрольные значения и дату проверки. Это позволит понять, почему результат изменился после обновления модели или таблицы. Для автоматизации используйте pull request или другой процесс ревью, а не прямую запись в production. Назначьте человека, который подтверждает метрику и отвечает за её доступность.

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

Частые вопросы

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

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

Нужно ли сохранять промпт? Да, если результат используется в отчёте: без него сложнее восстановить допущения и повторить проверку.