Презентация и защита решения

Презентация и защита решения

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

Кому ты презентуешь

В реальной работе у твоей презентации — три аудитории:

АудиторияЧто им важноИх вопросы
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.

Попробуйте интерактивную версию

Практические задачи, квизы и AI-наставник — бесплатный старт без карты

Перейти к практике