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

Фундамент: Эвалюации (Evaluations)

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

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

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

Пример из кейса поддержки телеком-компании:

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

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

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

Цель: Улучшить работающий промпт, который начал давать сбои (например, после миграции на новую модель).

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

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

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

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

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

Шаг 2: Чёткий контракт на вывод (Output Contract)

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

Рекомендации:

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

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

Шаг 3: Целевое исправление ошибок (Failure Modes)

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

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

• Симптом: Вместо того чтобы сказать, что у клиента 5 ГБ hotspot-данных (это есть в контексте), модель отсылает его проверять данные в личном кабинете.
• Причина: В промпте был «заплаточный» пункт для старой модели: «Никогда не давай клиенту неверные данные. Вместо этого направляй по URL». Новая модель следует слишком буквально.
• Решение: Сбалансируйте инструкцию. Укажите, что данные в контексте клиента — это источник истины, и их можно сообщать.

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

• Симптом: Модель рассуждает о пропорциональном платеже, но даёт размытый ответ без суммы.
• Причина: Инструкция «Критически важно всегда правильно рассчитывать» не даёт модели способности делать точные вычисления.
• Решение: Дайте модели инструмент (tool). Опишите в промпте и API схему инструмента calculate_proration и реализуйте его логику.

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

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

• Симптом: При биллинговой ошибке модель пытается сама диагностировать, а не передаёт специалисту.
• Причина: Перекос: «Избегай эскалации, стоит $8». Модель оптимизировала цель минимизации затрат.
• Решение: Дайте обе стороны trade-off: «Эскалация стоит $8, но ошибка приведёт к возврату и потере доверия».

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

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

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

Подход: Экспериментировать по трём направлениям

• Модель (Sonnet vs Opus)
• Промпт (простой vs улучшенный)
• Архитектура (одношаговый vs агентский цикл)

Сравнение подходов:

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

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

Три этапа:

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

Преимущества этого подхода:

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

Итог:

Агентский подход эффективнее и гибче, чем один монолитный промпт. Разделение на этапы (генерация, оценка, исправление) позволяет масштабировать систему.

Ключевые выводы

1. Эвалюации — основа. Это база для объективной оценки любых изменений в промпте или модели.
2. Начинайте с гигиены. Структурирование и очистка промпта часто дают быстрый прирост качества без изменения логики.
3. Избегайте длинных запретительных списков. Однобокие инструкции запутывают модель. Давайте сбалансированные указания с компромиссами.
4. Инструкции ≠ возможности. Для сложных задач (расчёты, поиск, проверка) предоставляйте модели инструменты (tools).
5. Для сложных use-case рассмотрите архитектуру. Агентский подход (Generate-Evaluate-Repair) может быть эффективнее и гибче одного промпта.
6. Используйте контроль версий. Отслеживайте, зачем были добавлены защитные инструкции — это поможет при миграции на новые модели.