Хороший промпт для SQL и анализа данных не должен просить «сделай красиво». Он должен задавать контекст, структуру таблиц, ограничения, ожидаемый формат и способ проверки. Ниже — 10 прикладных заготовок для рабочих задач: от написания запроса до проверки метрик и объяснения выводов бизнесу. Используйте их как черновик, а не как замену ревью: результат ИИ зависит от модели, качества входных данных и ваших ограничений.
Как пользоваться подборкой
В каждом блоке есть сценарий применения, готовый текст, переменные для замены, ожидаемый результат, проверка качества и частая ошибка. Перед отправкой промпта добавьте схему таблиц, тип СУБД, пример строк и бизнес-правила. Если данные чувствительные, обезличьте их.
Таблица выбора промпта
| Задача | Подходящий промпт | Что проверить |
|---|---|---|
| Написать SQL с нуля | Промпт 1 | Поля, join, фильтры, диалект SQL |
| Ускорить медленный запрос | Промпт 2 | План выполнения, индексы, кардинальность |
| Найти ошибки в данных | Промпт 3 | Дубликаты, null, диапазоны, форматы |
| Посчитать метрику | Промпт 4 | Определение числителя и знаменателя |
| Сравнить периоды или сегменты | Промпт 5 | Размер выборки, сезонность, смещения |
| Подготовить выводы | Промпт 10 | Связь с данными и ограничения |
Промпты для SQL-запросов
Промпт 1
Когда использовать: нужно получить корректный SQL-запрос по описанию бизнес-задачи.
Ты — аналитик данных. Напиши SQL для
{диалект_SQL}. Задача:{бизнес_вопрос}. Таблицы:{схема_таблиц}. Ограничения:{фильтры_и_период}. Верни: 1) запрос, 2) пояснение логики, 3) список допущений, 4) проверки результата.
Переменные: {диалект_SQL}, {бизнес_вопрос}, {схема_таблиц}, {фильтры_и_период}.
Ожидаемый output: один SQL-запрос и краткое объяснение join, group by и фильтров.
Проверка качества: запустите запрос на ограниченной выборке и сравните количество строк с ручным расчетом.
Частая ошибка: модель придумывает поля, если схема дана неполно.
Промпт 2
Когда использовать: запрос работает, но выполняется слишком долго или дорого.
Проанализируй SQL-запрос для
{СУБД}и предложи оптимизацию без изменения бизнес-логики. Запрос:{SQL}. Есть индексы:{индексы}. Объемы таблиц:{объемы}. Верни улучшенную версию, причины изменений и риски.
Переменные: {СУБД}, {SQL}, {индексы}, {объемы}.
Ожидаемый output: варианты переписывания, подсказки по индексам, предупреждения по full scan.
Проверка качества: сравните план выполнения, время, стоимость и совпадение результата.
Частая ошибка: совет по индексу без учета частоты обновления таблицы.
Промпт 3
Когда использовать: нужно найти проблемы качества данных перед отчетом или моделью.
Составь SQL-проверки качества данных для таблицы
{таблица}. Схема:{поля_и_типы}. Бизнес-правила:{правила}. Проверь null, дубликаты, диапазоны, невозможные даты, нарушения связей и выбросы. Верни набор запросов и интерпретацию результатов.
Переменные: {таблица}, {поля_и_типы}, {правила}.
Ожидаемый output: чек-запросы для аудита и таблица возможных дефектов.
Проверка качества: подтвердите правила с владельцем данных, а не только с моделью.
Частая ошибка: считать все null ошибкой, хотя часть полей может быть необязательной.
Промпты для очистки и подготовки данных
Промпт 4
Когда использовать: нужно нормализовать грязные значения: статусы, каналы, города, категории.
Предложи план очистки поля
{поле}в таблице{таблица}. Примеры значений:{примеры}. Целевой справочник:{справочник}. Верни правила маппинга, SQL для применения, список неоднозначных случаев и проверки после очистки.
Переменные: {поле}, {таблица}, {примеры}, {справочник}.
Ожидаемый output: правила преобразования и отдельный список значений для ручного решения.
Проверка качества: посчитайте долю значений, попавших в «прочее» или unresolved.
Частая ошибка: агрессивно объединять похожие строки без бизнес-подтверждения.
Промпт 5
Когда использовать: нужно собрать витрину для регулярной аналитики.
Спроектируй аналитическую витрину для задачи
{задача}. Источники:{таблицы}. Гранулярность:{уровень}. Метрики:{метрики}. Верни структуру витрины, SQL-сборку, ключи, правила обновления и проверки целостности.
Переменные: {задача}, {таблицы}, {уровень}, {метрики}.
Ожидаемый output: схема витрины, расчетные поля и порядок обновления.
Проверка качества: проверьте, что одна бизнес-сущность не размножается из-за join.
Частая ошибка: смешивать разные уровни детализации в одной строке витрины.
Промпты для метрик и экспериментов
Промпт 6
Когда использовать: нужно формализовать метрику до написания SQL.
Помоги описать метрику
{название_метрики}. Контекст:{контекст}. Дай определение, числитель, знаменатель, окно расчета, фильтры, исключения, SQL-пример и тестовые кейсы для проверки.
Переменные: {название_метрики}, {контекст}.
Ожидаемый output: спецификация метрики, пригодная для аналитической документации.
Проверка качества: согласуйте определение с продуктом, финансами или владельцем процесса.
Частая ошибка: менять фильтры между отчетами и получать несравнимые значения.
Промпт 7
Когда использовать: нужно сравнить сегменты, периоды или когорты.
Подготовь анализ сравнения
{что_сравниваем}по метрике{метрика}. Данные:{описание_таблиц}. Период:{период}. Укажи SQL, контрольные срезы, возможные confounders, ограничения и формат итоговой таблицы.
Переменные: {что_сравниваем}, {метрика}, {описание_таблиц}, {период}.
Ожидаемый output: запросы для сравнения и список факторов, которые могут исказить вывод.
Проверка качества: сравните размеры групп и проверьте сезонность.
Частая ошибка: объявлять разницу причиной, хотя это только наблюдаемая корреляция.
Промпт 8
Когда использовать: нужно проверить A/B-тест или экспериментальный вывод.
Проверь дизайн и анализ эксперимента. Гипотеза:
{гипотеза}. Группы:{группы}. Метрики:{метрики}. Данные:{схема}. Верни SQL для агрегации, проверки SRM, guardrail-метрики, ограничения и осторожную интерпретацию.
Переменные: {гипотеза}, {группы}, {метрики}, {схема}.
Ожидаемый output: план проверки эксперимента и SQL-агрегации по группам.
Проверка качества: отдельно проверьте распределение пользователей по группам и исключения.
Частая ошибка: смотреть только целевую метрику и игнорировать побочные эффекты.
Промпты для проверяемых выводов
Промпт 9
Когда использовать: нужно найти аномалии и объяснить, где копать дальше.
Проанализируй аномалию в метрике
{метрика}. Описание:{что_изменилось}. Доступные разрезы:{разрезы}. Таблицы:{схема}. Предложи диагностические SQL-запросы, дерево причин, проверки данных и список выводов, которые нельзя делать без дополнительных данных.
Переменные: {метрика}, {что_изменилось}, {разрезы}, {схема}.
Ожидаемый output: гипотезы, диагностические запросы и приоритизация проверок.
Проверка качества: сначала исключите сбой трекинга, изменение ETL и неполную загрузку.
Частая ошибка: объяснять аномалию первым найденным сегментом без проверки базы сравнения.
Промпт 10
Когда использовать: нужно превратить результаты анализа в аккуратный бизнес-вывод.
Сформулируй выводы по анализу. Факты из данных:
{факты}. Метод расчета:{метод}. Ограничения:{ограничения}. Аудитория:{аудитория}. Верни краткое резюме, подтверждающие цифры, что можно утверждать, что нельзя утверждать и следующие шаги.
Переменные: {факты}, {метод}, {ограничения}, {аудитория}.
Ожидаемый output: текст без завышенных обещаний, с цифрами и оговорками.
Проверка качества: каждое утверждение должно ссылаться на расчет, период и сегмент.
Частая ошибка: превращать предположение в доказанный причинно-следственный вывод.
Стартовый шаблон для любого аналитического промпта
Если не знаете, с чего начать, используйте каркас: роль, задача, данные, ограничения, формат ответа, проверки. Чем меньше контекста вы дадите, тем выше риск правдоподобной, но неверной SQL-логики.
Ты —
{роль}. Реши задачу{задача}на данных{схема_и_примеры}. Не придумывай отсутствующие поля. Если информации недостаточно, задай вопросы. Верни результат в формате{формат}и добавь проверки качества.
Запуск: чеклист перед использованием
- Указан диалект SQL: PostgreSQL, BigQuery, ClickHouse, MySQL или другой.
- Добавлены схемы таблиц, ключи, типы данных и примеры строк.
- Описаны бизнес-правила, исключения и период анализа.
- Модель попросили явно перечислить допущения и неизвестные поля.
- SQL проверен на тестовой выборке и сопоставлен с ручным расчетом.
- Выводы отделены от гипотез, а ограничения записаны рядом с результатом.
FAQ
Можно ли сразу запускать SQL от ИИ в production? Нет. Сначала ревью, тестовая среда, лимиты и проверка результата. Особенно опасны массовые update и delete.
Что делать, если модель уверенно пишет несуществующие поля? Дайте точную схему и добавьте инструкцию: не использовать поля, которых нет в списке; при нехватке данных задавать вопросы.
ИИ может сам сделать надежный аналитический вывод? Он может помочь структурировать вывод, но надежность зависит от данных, методики и проверки человеком.
Источники и ограничения
Материал подготовлен как практическая редакционная подборка COMRAD404. Полезные справочные материалы по промптингу: OpenAI: prompt engineering best practices, Zapier: AI prompt templates, Zapier: how to prompt AI. Выводы ИИ требуют человеческой проверки и зависят от модели, формулировки задачи, схемы данных, качества трекинга и полноты входной информации.