Prompting Playbook: Отладка и создание промптов

Фундамент: Эвалюации как основа

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

Совет: Если вы не знаете, работает ли ваш промпт, вы всегда пишете вслепую. Эвалюации — это ваша система мониторинга.

Три типа тест-кейсов:

1. Контрольный случай. Простой, однозначный запрос, который должен всегда проходить. Если он начинает падать, вы сломали что-то важное.
2. Пограничные случаи (Edge cases). Ситуации, где модель ранее ошибалась — расчёты, исключения, редкие комбинации правил.
3. Проверка границ и отказ. Понимает ли модель, когда нужно передать задачу человеку или отказаться выполнять неправомерный запрос?

Пример из кейса: Телеком-компания (поддержка клиентов)

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

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

Сценарий 1: Поддержка и миграция промпта

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

Сценарий: Промпт поддержки телеком-компании давал хорошие результаты на Claude 3.5 Sonnet, но после обновления начал скрывать доступную информацию и делать ошибки в расчётах. Нужно вернуть качество.

Шаг 1: Общая очистка и гигиена промпта

Перед точечными исправлениями приведите промпт в структурированный вид:

• Уберите ложные утверждения вроде «ты — человек» или отсылки на визуальные элементы, которых нет в контексте.
• Удалите лишнюю информацию, скопированную с веб-сайтов (упоминания картинок, cookies, фрагменты HTML-комментариев).
• Добавьте чёткую структуру с использованием XML-тегов для разделения разных областей:

<role>...</role>
<policies>...</policies>
<guidelines>...</guidelines>
<tone>...</tone>
<context>...</context>

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

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

Шаг 2: Контракт на вывод (Output Contract)

Для структурированных форматов (JSON, XML, таблицы) явно укажите ожидаемую схему:

• Дайте примеры правильного формата и, где необходимо, примеры неправильного с пояснениями, почему это не подходит.
• Для очень сложных схем используйте structured outputs (встроённая функция API Claude) — это гарантирует валидность JSON без дополнительных проверок.
• Используйте stop-последовательности, чтобы модель не генерировала излишний текст после основного ответа.

Преимущество: Явный контракт на вывод снижает случайные форматные ошибки и делает результат более предсказуемым.

Шаг 3: Целевое исправление failure modes

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

Проблема 1: Модель утаивает доступную информацию

Проблема 2: Модель не может выполнить точный расчёт

Ключевой вывод: Инструкции не добавляют возможности. Для сложных задач (математика, поиск, проверка подлинности) вы должны предоставить модели инструменты.

Проблема 3: Модель не эскалирует к человеку

Урок: Умные модели лучше справляются с компромиссами, если им дают полную картину альтернатив и их последствий.

Сценарий 2: Создание агента с нуля

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

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

Три оси для экспериментирования:

1. Модель: Sonnet (быстро, дешёво) vs Opus (дороже, но мощнее) vs Opus с Adaptive Thinking (ещё дороже, но думает дольше).
2. Промпт: Простая инструкция vs улучшенный промпт со структурой, примерами и ограничениями.
3. Архитектура: Одношаговый вызов vs агентский цикл (Generate-Evaluate-Repair).

Результаты экспериментов:

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

Агентский цикл: Generate-Evaluate-Repair

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

Три этапа цикла:

1. Генератор (Sonnet): Создаёт чёрный вариант графика, следуя основным правилам.
2. Оценщик (LLM-судья, Sonnet): Проверяет чёрный вариант на нарушения каждого правила. Формирует подробный отчёт об ошибках: какие правила нарушены, на каких сотрудниках, почему.
3. Исправитель (Sonnet): Получает отчёт оценщика и целевых образом вносит правки в график на основе выявленных ошибок.

Преимущества архитектуры:

• Гибкость: Позволяет добавлять новые правила и ограничения (например, «Гарри не любит работать в ночные смены с Салли») прямо в промпт оценщика на лету, без изменения кода.
• Разделение ответственности: Генератор фокусируется на создании, оценщик — на контроле, исправитель — на целевых правках. Каждый агент решает одну задачу.
• Контролируемость: Вы видите, на каких точных правилах падают тесты. Отладка становится явной и предсказуемой.
• Стоимость-оптимальность: Три вызова Sonnet дешевле, чем один вызов Opus с Adaptive Thinking, но результат надёжнее монолитного подхода.
• Масштабируемость: Когда вы добавите 10 новых правил, вам не нужно переписывать весь генератор. Просто расширьте список правил в оценщике.

Пример: Как выглядит цикл в коде

1. schedule = generate_schedule(employees, constraints, preferences)
2. evaluation = evaluate_schedule(schedule, rules, constraints)
3. while evaluation.violations:
     schedule = repair_schedule(schedule, evaluation.violations)
     evaluation = evaluate_schedule(schedule, rules, constraints)
4. return schedule

Важно: Добавьте limit на цикл (например, максимум 3 итерации), чтобы избежать бесконечного исправления. Если качество не улучшается, остановитесь и пересмотрите правила.

Ключевые выводы и практика

1. Эвалюации — основа всего. Без объективной системы оценки вы пишете вслепую. Начните с 3 типов тест-кейсов: контрольный, пограничные, проверка границ.
2. Начинайте с гигиены. Структурирование и очистка промпта часто дают быстрый прирост качества без изменения логики. XML-теги, разделение ролей и данных.
3. Контракт на вывод. Для структурированных выходов укажите схему явно. Примеры, стоп-последовательности, structured outputs API.
4. Избегайте длинных запретительных списков. Однобокие инструкции вроде «Никогда не…» путают модель. Давайте сбалансированные указания с компромиссами и последствиями.
5. Инструкции ≠ возможности. Инструкция «Всегда считай правильно» не даёт модели математических способностей. Для математики, поиска, проверки — используйте инструменты (tools).
6. Архитектура важнее модели. Для сложных задач агентский подход (Generate-Evaluate-Repair) часто эффективнее и дешевле, чем использование более мощной модели в монолитном вызове.
7. Контроль версий промптов. Отслеживайте, зачем были добавлены защитные инструкции и ограничения. Это поможет при миграции на новые версии моделей: вы сможете переоценить, актуальны ли старые заплатки.

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