Production prompt engineering: что остаётся после красивого демо
Начните с процесса и критерия принятого ответа
Сравните шаблон, workflow и LLM на одинаковых случаях
Авторское дерево RELEASE-GATE-7
Права, доказательства, стоимость и откат
$ decide --contract RELEASE-GATE-7
> bind: owner / accepted outcome
> compare: template / workflow / LLM
> gate: evidence / rights / recovery
> route: pilot / review / releaseДемо показывает, что модель может ответить на один удачный запрос. Рабочий процесс должен предсказуемо обрабатывать обычные, неполные и ошибочные входы, соблюдать права доступа и оставлять понятный след решения. Поэтому production prompt engineering начинается с владельца процесса и критерия принятого результата. Формулировка инструкции — лишь один компонент системы.
Этот разбор отвечает на узкий вопрос: что проверить между убедительным прототипом и выпуском в работу. О принципах самой инструкции читайте системный промпт как контракт. Широкий обзор услуги находится на странице prompt engineering; критерии выбора исполнителя в Армении — в отдельном руководстве.
Исходная бизнес-задача
Представим синтетический сценарий: команда поддержки хочет ускорить подготовку ответа по внутренним инструкциям. В демо оператор вставляет вопрос и один актуальный документ. В работе вопросы приходят из нескольких каналов, документы меняются, часть записей закрыта для отдельных ролей, а ответ может повлиять на заказ. Доказательством готовности будет не красивый текст, а согласованный ответ с разрешёнными источниками либо корректный отказ с передачей человеку.
До выбора модели запишите единицу работы: кто задаёт вопрос, какой результат принимает владелец процесса, какие источники разрешены, что нельзя сообщать, когда нужен человек и сколько стоит ошибочный ответ. Разделите чтение документов и запись в CRM: у них разные права и способы подтверждения результата. Если исходный процесс не определён, промпт не создаст его автоматически.
Какие варианты решения существуют
| Вариант | Подходит, когда | Что проверить первым |
|---|---|---|
| Шаблон и поиск | ответ можно собрать из фиксированных полей и известных страниц | актуальность документа и понятность шаблона |
| Детерминированный workflow | шаги известны, ветвления ограничены | правила маршрутизации и обработку исключений |
| LLM с разрешённым поиском | вопросы вариативны, нужен пересказ источников | полноту retrieval, цитаты и отказ без доказательств |
| LLM с инструментами | нужен предложенный системой вызов действия | отдельные права, схема аргументов, read-back и журнал |
| Человек в контуре | ошибка дорого стоит или политика не определена | очередь, SLA и достаточность контекста для решения |
Минимальный вариант, который проходит критерии приёмки, обычно легче наблюдать и сопровождать. LLM не обязателен для каждого этапа. Если модель используется, храните версию промпта, входные источники, схему выхода и тестовый набор как единый релизный контракт.
Дерево выбора RELEASE-GATE-7
Ниже авторская процессная схема для этого материала. Это метод выбора, а не измеренный результат проекта.
1. Определён ли принятый результат и владелец исключений?
нет → остановить автоматизацию и уточнить процесс.
2. Достаточны ли фиксированные поля, поиск или шаблон?
да → проверить простой вариант на типовых и ошибочных случаях.
3. Нужна ли генерация ответа по изменяемым документам?
да → retrieval по правам + цитаты + маршрут «нет доказательств».
4. Требуется ли внешнее действие?
да → отдельная авторизация, лимиты, idempotency и read-back.
5. Есть ли набор репрезентативных примеров и допустимые пороги?
нет → собрать тесты до запуска, особенно для отказов и конфликтов.
6. Есть ли мониторинг ошибок, стоимости и дрейфа документов?
нет → ограниченный пилот с ручной проверкой.
7. Проходит ли кандидат критерии и восстановление после сбоя?
да → поэтапный выпуск с возможностью отката; иначе доработать.Пункты не заменяют экспертную оценку. Например, валидный JSON подтверждает формат, но не истинность ответа. Цитата на разрешённый документ подтверждает происхождение, но не обязательно логическую связь с выводом. Эти качества проверяются отдельно.
Критерии выбора
Сравните варианты на одинаковых запросах, включая пограничные. Задайте критерии до просмотра результатов: доля ответов с достаточным основанием, доля правильных отказов, нарушения прав, время до принятого ответа, стоимость с ручной проверкой и восстановление после неизвестного исхода действия. У каждого критерия должен быть владелец и правило, по которому кандидат допускается к пилоту. Цифры для собственного процесса появятся после измерения; нельзя переносить показатели чужого демо.
Матрица приоритетов полезна при ограниченном времени. Блокирующие условия — доступ к чужим данным, неподтверждённая запись, невозможность отката — проверяйте раньше стилистики текста. Затем оценивайте качество и стоимость. Если два подхода проходят одни критерии, выбирайте меньший объём новой операционной нагрузки.
Риски и ограничения
Устаревшие или недоступные источники. Поиск должен учитывать версию документа и права роли. Текст промпта не исправляет ошибку фильтра доступа. При отсутствии основания нужен явный отказ.
Смешение инструкции и данных. Внешний документ может содержать команды для модели. Передавайте его как недоверенный источник, а права и исполнение действий проверяйте сервером. Смежный разбор — контракт системного промпта.
Скрытая стоимость сопровождения. Каждая новая версия модели, шаблона, схемы или источника может менять ответы. Нужны regression-набор, журнал версии и владелец релиза. Считайте стоимость принятого ответа, включая разметку тестов, ручную проверку, инциденты и обновления.
Неизвестный исход записи. Тайм-аут после вызова CRM не доказывает, что запись не сделана. Сначала сверяйте целевое состояние и ключ попытки; слепой повтор может создать дубль. Для действий нужна отдельная архитектура AI-автоматизации.
Ложная уверенность пилота. Десять удобных примеров показывают возможность, но не покрывают редкие отказные пути. Набор должен включать неполный вопрос, противоречивые документы, недоступный источник, неверный формат, смену роли, ошибку инструмента и неоднозначный результат.
Рекомендуемый план действий
- Опишите один процесс и единицу принятого результата. Назначьте владельца исключений и цену ошибки.
- Снимите базовый процесс без LLM: реальные типы входов, ограничения источников, ручные шаги и места задержки.
- Сравните шаблон, workflow и LLM на одном наборе случаев. До эксперимента запишите критерии допуска.
- Для LLM зафиксируйте версию промпта, разрешённые источники, схему ответа, refusal route и независимую проверку действий.
- Проведите ограниченный пилот без автоматической записи там, где эффект необратим. Разбирайте каждый неверный ответ и отказ.
- Подготовьте выпуск: мониторинг по версиям, бюджет вызовов, очередь ручной проверки, откат и ответственного за обновления.
- Расширяйте охват только после проверки качества и восстановления на собственных данных.
Итоговый артефакт discovery — короткая карта процесса, набор тестовых случаев, сравнительная таблица вариантов и решение о следующем ограниченном шаге. Если нужен независимый взгляд, запросите короткий аудит процесса, приложив обезличенный пример входа и критерий принятого ответа.
if (!task.owner || !task.acceptance) return discovery;
const options = testSameFixtures(template, workflow, llm);
const safe = options.filter(x => x.rightsValid && x.recovers);
return safe.length ? stagedPilot(leastCost(safe)) : humanReview;