Промпт в продукте и промпт в чате — разные объекты

Промпт-инжиниринг для разработчиков · Урок 1 / 22

Один и тот же текст, разные требования

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

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

Что меняется при переходе в продукт

  • Разнообразие входов. Ваши десять тестовых примеров — это середина распределения. Реальный трафик приносит пустые строки, текст на трёх языках в одном поле, эмодзи вместо описания, документ на сорок страниц вместо абзаца.
  • Потребитель ответа — парсер. Человек простит «Конечно! Вот результат:» перед JSON. Код на этом упадёт или, что хуже, молча запишет мусор в базу.
  • Сбой не виден автору. В чате вы видите каждый плохой ответ. В продукте вы видите только те, о которых написал пользователь — то есть примерно один из пятидесяти.
  • Изменения накапливаются. Через полгода в промпте будет двадцать правил, добавленных разными людьми под разные инциденты, и половина из них будет конфликтовать друг с другом.
  • Стоимость и задержка становятся бюджетом. Лишний абзац контекста — это деньги на каждом вызове и миллисекунды в ответе пользователю.

Почему промпт работал на десяти примерах и сломался на сотне

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

Минимальный контракт продакшн-промпта
1. Что на входе   — типы и границы полей, что делать с пустым
2. Что на выходе  — схема, перечисление допустимых значений
3. Что при отказе — какой ответ означает "не смог"
4. Что запрещено  — чего в выводе быть не должно никогда
5. Чем проверяется — набор входов с ожидаемым результатом
Инсайт. Промпт без пункта 3 — это промпт, который на непонятном входе выдумает ответ вместо того, чтобы честно вернуть отказ. Модели не умеют молчать по умолчанию: если вы не задали форму отказа, она заполнит пустоту правдоподобным текстом.
Частая ошибка. Оценивать промпт по паре запусков в песочнице. Модель недетерминирована: один и тот же вход даёт разные ответы, и удачный прогон ничего не доказывает. Считайте долю сбоев на фиксированном наборе, а не впечатление.
Про-совет. Заведите файл с проблемными входами с первого дня разработки. Каждый инцидент — новая строка. Через месяц у вас будет регрессионный набор, который вы никогда не собрали бы специально.

Шпаргалка

  • Промпт в продукте — компонент с контрактом, а не текст для человека.
  • Проверка на десяти удобных примерах не измеряет долю сбоев.
  • Пять пунктов контракта: вход, выход, отказ, запреты, набор проверок.
  • Недетерминированность означает, что судить можно только по выборке.
1. Почему промпт, отлично работавший на десяти примерах, ломается на реальном трафике?
2. Что означает утверждение «промпт — это код без типов и без тестов»?
3. Что произойдёт, если в промпте не задана форма отказа?

🔒 Ответьте на вопрос верно, чтобы перейти к следующему уроку.

Промпт в продукте и промпт в чате — разные объекты — Промпт-инжиниринг для разработчиков — Skilvy