Как писать промпты: шаблоны для работы с данными

Как писать промпты для анализа данных — коротко

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

Шесть элементов удобно держать в одном порядке: роль исполнителя, контекст, задача, формат, ограничения, проверка. Роль — не заклинание «ты гений», а описание работы: «напиши SQL для PostgreSQL». Контекст — схема и определения. Задача — конкретная метрика и период. Формат — код и короткое объяснение. Ограничения — что нельзя предполагать. Проверка — контрольный итог или тест.

Самый ценный элемент часто не роль, а право на отказ: если данных недостаточно, модель должна перечислить пробелы. После ответа всё равно нужно запустить код и сверить результат. Промпт организует работу; он не превращает генерацию текста в вычислитель.

Плохой и хороший запрос на одной таблице

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

Рабочий вариант указывает day.csv, зерно «одна строка — один рейс», поле revenue, период выгрузки, ожидаемые 548 строк и требование показать Python-код. Эталонную сумму 438 406 200 ₽ можно использовать для сверки после независимого расчёта; если вы просите модель получить ответ честно, не подсказывайте ей итог до запуска. Сначала попросите код, затем выполните его и сравните. Иначе модель может подогнать объяснение под известное число.

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

Ты пишешь Python для аналитика.
Файл: <путь к CSV>. Одна строка — <зерно>.
Колонки: <список колонок и типы>.
Задача: вычислить <метрика> за <период>; отмены <правило>.
Верни только код, затем список допущений и проверок числа строк.
Не называй итог до выполнения кода. Если данных не хватает, перечисли их.

Промпт-инжиниринг: что это на самом деле

Промпт-инжиниринг — проектирование инструкции и контекста так, чтобы задача была понятна и результат можно было проверить. Это часть работы с инструментом, а не отдельная магическая грамматика. Текст «думай глубже» не заменит схему таблиц; длинное описание роли не устранит дубли в JOIN.

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

Польза от промпта зависит от способа работы. Когда модель только пишет текст по вставленному CSV, точные числа могут быть неверны; наш эксперимент показал это на 548 рейсах. Когда она пишет код, который выполняет база или Python, ошибки становятся видимыми и исправимыми. Сам запрос к модели — лишь начало цепочки.

Перед библиотекой: как пользоваться плейсхолдерами

Ниже угловые скобки обозначают место для ваших данных: <схема>, <метрика>, <контрольный итог>. Их надо заменить, а не отправлять буквально. Лучше передавать короткие реальные примеры значений и названия колонок, чем выдуманную «типичную» схему. Для приватных данных подготовьте обезличенную структуру и тестовые строки.

Шаблоны дают разные результаты для разных задач. В SQL укажите диалект, у Excel — язык функций и разделитель аргументов, у Python — формат файла и библиотеку. Для классификации текстов определите классы так, чтобы один отзыв не требовал угадывать намерение автора. Для резюме руководителю передайте уже проверенные цифры, а не сырую выгрузку.

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

SQL: запрос по схеме

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

Напиши SQL для <диалект>.
Таблицы: <DDL или список колонок>. Зерно: <одна строка = ...>.
Метрика: <определение>, период: <границы и часовой пояс>.
Верни запрос и объясни каждый JOIN, фильтр и знаменатель.
Если столбца нет в схеме, остановись и назови пробел.

SQL: проверить кардинальность JOIN

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

Проверь SQL <запрос> на размножение строк.
Левая таблица: <схема и ключ>. Правая: <схема и ключ>.
Ожидаемая связь: <1:1 / 1:N / N:1>.
Верни диагностические COUNT(*), COUNT(DISTINCT <ключ>) до и после JOIN.
Не меняй запрос без объяснения причины.

SQL: разобрать ошибку выполнения

Передайте сообщение движка целиком и исходный запрос. Если приложить только «не работает», модель будет гадать о причине. Хороший ответ указывает конкретное место ошибки, предлагает минимальное исправление и не меняет смысл метрики. Выполняйте исправление сначала на безопасной копии или в read-only сессии.

Движок: <PostgreSQL / DuckDB>.
Исходный SQL: <запрос>. Ошибка: <полный текст и позиция>.
Найди причину, исправь минимально, покажи diff логики.
Не выдумывай недостающие таблицы и не меняй определение <метрика>.

Python: чтение и профиль файла

Перед группировками убедитесь, что файл прочитан целиком. Укажите кодировку, разделитель и ожидаемые колонки; попросите вывести форму таблицы, пропуски и типы. Этот шаг обнаруживает ситуацию, когда заголовок распознан как строка данных или часть CSV обрезана. Ожидаемый размер лучше хранить вне промпта в тесте.

Напиши pandas-код для чтения <путь и формат>.
Ожидаемые поля: <список>. Зерно: <строка = ...>.
Выведи shape, dtypes, пропуски и по 3 примера значений категорий.
Не удаляй строки автоматически. Покажи предупреждение, если схема не совпала.

Python: очистка без потери исходника

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

Есть DataFrame <имя> со столбцами <схема>.
Правила: <для каждого критичного поля>.
Напиши функцию очистки без изменения входного DataFrame.
Верни код и контроль: строки до/после, причины исключения, суммы до/после.
Если правило не задано — не заменяй пропуски догадкой.

Python: группировка с проверкой суммы

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

Сгруппируй <DataFrame> по <ключ> и посчитай <метрика>.
Пустой ключ: <отдельная группа / исключить с отчётом>.
Верни pandas-код, общий итог до группировки и сумму итогов групп.
Если они не равны, не скрывай разницу: покажи строки-источник.

Excel: формула с локалью

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

Нужна формула Excel для <задача>.
Версия и локаль: <версия / русский или английский>.
Разделитель аргументов: <; или ,>. Диапазоны: <адреса>.
Верни формулу, объясни абсолютные ссылки и покажи проверку на <тестовые строки>.
Не предлагай функции, недоступные в этой версии.

Excel: сводная таблица по задаче

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

Опиши настройку сводной таблицы по <источник>.
Одна строка = <зерно>. Нужно ответить на вопрос <вопрос>.
Укажи строки, столбцы, значения, агрегатор и фильтры.
Отдельно назови контрольный итог и риск дублей <ключ>.

Объяснить чужой SQL или Python

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

Объясни код <код> аналитику, который будет его поддерживать.
Для каждого шага: входное зерно, преобразование, выходное зерно.
Назови скрытые фильтры, обработку NULL и места возможного размножения строк.
Предложи 3 тестовых входа с ожидаемым результатом.

Найти риск в чужом запросе

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

Проведи ревью <SQL или Python>. Целевая метрика: <определение>.
Ищи только риски: неверное зерно, JOIN, NULL, даты, дубли, округление.
Для каждого риска дай минимальный тест, ожидаемый симптом и последствия.
Не называй ошибкой то, что нельзя проверить по переданной схеме.

Разметка отзывов: темы

В тексте может быть две проблемы одновременно. Решите заранее, допускаете ли несколько тем и как отмечать отсутствие темы. Классы с определениями важнее примеров в стиле «будь внимателен». Для промышленной разметки проверьте качество на независимой ручной выборке.

Разметь отзыв <текст> по темам <темы и определения>.
Можно выбрать <одну / несколько> тем. Нет подходящей — класс <other>.
Верни JSON: id, темы, короткий фрагмент-доказательство.
Не выводи личные данные в объяснении.

Разметка отзывов: тональность

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

Для отзыва <текст> оцени тональность по аспектам <список>.
Метки: positive, negative, neutral, mixed; определения: <правила>.
Верни JSON с фрагментом текста для каждой ненейтральной оценки.
Не угадывай эмоцию, если в тексте нет оценки.

Резюме руководителю из проверенных цифр

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

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

Короткий вывод для карточки метрики

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

Напиши подпись к метрике <название> за <период>.
Проверенные значения: <текущее, предыдущее, знаменатель>.
Верни 2 предложения: наблюдение и какую проверку сделать дальше.
Не называй причиной событие <релиз>, если это только совпадение по дате.

Поиск гипотез для падения конверсии

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

Метрика <определение> изменилась <наблюдение>.
Контекст: <сегменты, события, релизы, качество трекинга>.
Предложи гипотезы с тестом на данных, ожидаемым сигналом и альтернативой.
Ранжируй по скорости проверки, не по выдуманной вероятности.

План проверки гипотезы

Перед анализом согласуйте, что опровергло бы объяснение. Модель должна описать нужные сегменты, период до и после, контрольную группу или ограничение, если её нет. Это переводит разговор из «почему случилось» в проверяемый вопрос.

Гипотеза: <формулировка>. Данные: <таблицы и события>.
Составь план проверки: метрика, срезы, сравнение, критерий опровержения.
Назови, какие наблюдения нельзя трактовать как причинный эффект.
Если данных для сравнения нет, скажи это явно.

Документация метрики

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

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

Документация изменения метрики

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

Есть старая формула <старая> и новая <новая>.
Составь change note: причина, дата применения, затронутые отчёты, backfill, тесты.
Отметь, какие сравнения до/после становятся некорректными.
Не утверждай, что история пересчитана, пока это не подтверждено.

Как проверять шаблоны на своей задаче

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

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

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

Ошибки, которые шаблон не исправит

Первая ошибка — передать неверную схему. Модель точно следует вымышленным полям, код не запускается или обращается не туда. Подтвердите имена колонок в базе.

Вторая — забыть зерно. Запрос синтаксически верен, но соединение заказов с позициями удваивает выручку. Проверьте число сущностей до и после JOIN.

Третья — скрыть исключения из определения метрики. Модель посчитает валовую выручку вместо чистой, если не сообщить о возвратах. Утвердите правило до промпта.

Четвёртая — принять убедительное резюме за доказанную причину. Модель связывает падение конверсии с релизом только по календарю. Нужен дизайн сравнения и альтернативы.

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

Чек-лист перед отправкой промпта

Убедитесь, что можно понять одну строку каждой таблицы и есть имена полей. Зафиксируйте период, часовой пояс, знаменатель и правила исключений. Назовите движок или библиотеку, если просите код. Попросите вернуть допущения, а не прятать их. Опишите формат ответа, который позволит быстро проверить результат.

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

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

• Задача и источник определены.
• Схема и зерно даны.
• Формат и ограничения записаны.
• Эталон хранится вне промпта.
• Результат будет запущен и проверен.

Когда просить JSON, а когда обычный текст

JSON нужен, когда результат будет читать программа: темы отзывов, список проверок или структура карточки метрики. Укажите допустимые поля и значения, потребуйте один объект на один входной ID. Затем валидируйте ответ парсером и проверяйте полноту. Даже формально корректный JSON может содержать неверную тему или придуманную цифру; формат контролирует форму, а не истину.

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

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

Как возвращать модели найденную ошибку

После запуска кода не ограничивайтесь сообщением «неправильно». Передайте конкретный сигнал: PostgreSQL сообщает, что столбца нет; сумма групп меньше исходной; после merge стало больше строк, хотя ожидалась связь многие к одному. Спросите минимальное исправление и причину. Так модель получает новую информацию, а не приглашение к новой догадке.

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

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

Контекст без лишних персональных данных

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

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

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

Приёмка результата важнее «идеальной формулы»

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

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

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

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

Как правильно писать промпты для ChatGPT и других моделей? Начните с задачи и контекста, затем задайте формат, ограничения и проверку. Роль помогает выбрать стиль работы, но не заменяет данные.

Нужен ли длинный промпт? Нет. Нужны сведения, которые меняют ответ: схема, определение метрики, период и критерий готовности. Лишняя инструкция может скрыть важное.

Помогает ли фраза «не галлюцинируй»? Она не создаёт недостающий источник и не выполняет расчёт. Попросите код, ссылку на документ и право ответить «данных недостаточно».

Можно ли копировать эти шаблоны без изменений? Замените плейсхолдеры и протестируйте на своём срезе. Формулировка, которая подходит к рейсам, может ошибаться на заказах с возвратами.

Что читать дальше

Если чаще всего просите SQL, следующий шаг — разобраться, как проверить JOIN, фильтры и зерно результата. Если модель пишет Python, начинайте с контроля загрузки файла и суммы до преобразований. Шаблон промпта имеет смысл только вместе с процедурой проверки.

Для тренировки без доступа к боевой базе можно взять учебную базу «Авиаперевозки». Составьте собственное задание, попросите модель написать запрос и выполните его в тренажёре, где результат можно сравнить с контрольным числом.