Презентация и защита решения
Презентация и защита решения
Ты спроектировал, написал, протестировал и задокументировал промпт. Последний навык промпт-инженера — умение презентовать свою работу и защищать принятые решения. Это не софт-скилл, а часть профессии: если ты не можешь объяснить, почему промпт такой, тебе не дадут его внедрить.
Кому ты презентуешь
В реальной работе у твоей презентации — три аудитории:
| Аудитория | Что им важно | Их вопросы |
|---|---|---|
| Product-менеджер | Решает ли промпт бизнес-задачу? | «Насколько это лучше ручного написания?» |
| Разработчики | Как интегрировать промпт? | «Какой формат входа/выхода? Какие задержки?» |
| Маркетологи (заказчик) | Устраивает ли качество? | «Можно ли менять тон? Что делать с ошибками?» |
Твоя презентация должна ответить на вопросы всех трёх.
Структура презентации (7 слайдов / 10 минут)
1. Задача и контекст (1 мин)
Напомни, зачем ты это делаешь. Не пересказывай весь проект — одну строку контекста и суть:
Маркетологи тратят ~40 часов в неделю на описание товаров.
Цель: промпт, который генерирует описание по характеристикам
с качеством не хуже ручного.
2. Решение: архитектура промпта (2 мин)
Покажи структуру промпта — не построчно, а схематично:
[Роль] → задаёт тон и контекст
[Инструкции] → что делать и какие правила соблюдать
[Примеры] → 3 образца (богатый вход, бедный, сложный)
[Входные данные] → подстановка {{product_data}}
[Самопроверка] → встроенная защита от галлюцинаций
Объясни, ПОЧЕМУ выбрал именно такую структуру. Каждая секция решает конкретную проблему.
3. Демо: вход → выход (2 мин)
Самый сильный момент — живой пример:
Вход: (показываешь данные товара)
Выход: (показываешь сгенерированное описание)
Идеально — показать 2 примера: «хороший» вход (6+ характеристик) и «сложный» вход (1–2 характеристики). Показать, что промпт справляется с обоими.
4. Метрики: что измерили и как (2 мин)
Покажи таблицу метрик, но НЕ просто цифры. Объясни:
- Что измеряли: точность, полноту, длину, тон.
- Как измеряли: eval set из 10 товаров, автоматическая проверка фактов + ручная оценка тона.
- Результат: все метрики в целевых значениях (покажи таблицу из документации).
- Прогресс: покажи график v1 → v2 → v3 (60% → 80% → 100%).
График прогресса всегда впечатляет больше, чем одна финальная цифра. Он показывает, что ты не «угадал» промпт, а методично его улучшал.
5. Ограничения и риски (1 мин)
Честность покупает доверие. Скажи, что промпт НЕ умеет:
- Не работает с товарами вне электроники.
- При экстремально бедном входе описание короче целевых 3 предложений.
- Нужна финальная проверка редактором перед публикацией (на случай
единичных галлюцинаций — промпт не даёт 100% гарантии).
Лучше самому назвать ограничения, чем получить их как «претензию» от заказчика через неделю после внедрения.
6. Интеграция: что нужно от разработки (1 мин)
Объясни, как встроить промпт в систему:
- Формат входа: структурированный текст (как в карточке товара).
- Формат выхода: строка (описание).
- Задержка: ~2–5 секунд на генерацию.
- Обработка ошибок: если модель вернула пустой ответ — повторить.
- Где хранить промпт: в файле (Git), загружать через API.
Эти детали — мост между твоей работой и production-кодом.
7. Следующие шаги (1 мин)
Что дальше:
- Внедрение на 5% товаров (пилот).
- Ручная проверка редактором в течение 2 недель.
- Если качество подтверждается — расширение на весь каталог.
- Следующая итерация: адаптация промпта для другой категории (одежда).
Защита: как отвечать на вопросы
После презентации — вопросы. Вот типичные и как на них отвечать.
«А что, если модель ошибётся?»
Ответ: «Мы замерили точность на 10 товарах — 100% по критерию "не придумывать". Но гарантии 100% на любых данных дать нельзя. Поэтому мы рекомендуем: (1) пилот на 5% товаров, (2) редактор проверяет описания первые 2 недели, (3) метрики логируются для аудита.»
«Почему не использовать шаблоны вместо модели?»
Ответ: «Шаблоны требуют ручной настройки под каждую категорию и каждый товар. Промпт адаптируется автоматически: он выделяет ГЛАВНОЕ преимущество для каждого товара. Шаблон для наушников и ноутбука — разный. Промпт — один. Это масштабируемость: один промпт на все товары против десятков шаблонов.»
«Можно ли поменять тон?»
Ответ: «Да. Тон задан в системном промпте и инструкциях. Чтобы изменить его — нужно заменить роль и уточнить правила в инструкциях. Это изменение на 5 минут. Но учтите: после изменения нужно заново прогнать eval set — изменение тона может повлиять на другие метрики.»
«Как долго это будет работать?»
Ответ: «Промпт не зависит от конкретной модели. Он использует универсальные техники (few-shot, роли, структурирование, самопроверку), которые работают на всех современных моделях. При смене модели или версии — нужно прогнать eval set и, возможно, скорректировать примеры. Но структура останется.»
Типичная ошибка: защищать промпт как «идеальный»
Промпт-инженер, который говорит «мой промпт работает без ошибок» — вызывает недоверие. Любой опытный разработчик знает: без ошибок не бывает.
Правильная позиция: «Промпт показывает 100% точность на eval set из 10 товаров. Это не гарантирует 100% на любых данных, поэтому мы закладываем пилот и ручную проверку. Eval set будем расширять по мере обнаружения краевых случаев.»
Такая позиция показывает, что ты реалистично оцениваешь риски и закладываешь защиту — это вызывает доверие.
Проверь себя
Ты презентуешь промпт для классификации обращений. Технический директор спрашивает: «А что будет, если клиент напишет матом или на другом языке?» Как ответишь?
Итог
- Презентация — это не «показать код». Это объяснить: задача → решение → метрики → риски → интеграция.
- Разные слушатели хотят разного: продакт — бизнес-ценность, разработчик — интеграцию, заказчик — качество.
- Демо (живой пример вход→выход) — самая убедительная часть презентации.
- График прогресса (v1→v2→v3) показывает методичность, а не «угадал».
- Признавай ограничения до того, как их «найдут» за тебя. Это покупает доверие.
- Метрики — твой главный аргумент. «Мнение» проигрывает «данным».
Что дальше
Ты завершил курс «Промпт-инжиниринг для LLM». Ты прошёл путь от базовых принципов до полного production-цикла: проектирование, написание, тестирование, итерации, документирование, презентация. Дальше — практика. Бери реальные задачи и применяй методологию: требования → архитектура → eval set → версия 1 → итерации → production.