Почему идеальный промт не спасает плохого агента
Спецификация агента, структура промта, структурированный вывод и выбор вариантов по результатам тестов
Хорошо написанный промт не исправит ошибки в архитектуре агента. Разберём, как спецификация превращается в инструкцию для модели, почему структура промта важнее его длины, зачем автоматизации структурированный вывод и как генерировать и выбирать варианты по результатам тестов.
Идеальный промт, плохой агент
Промт — это инструкция, а не архитектура.
Если роль агента, его цель, входные данные, инструменты, ограничения и критерии хорошего результата ещё не определены, выверенные формулировки промта этого не исправят.
Эти требования определяют до написания промта и фиксируют в спецификации агента — описании его задач и правил работы. В статье об архитектуре агента мы выделили семь полей спецификации, от роли до формата результата, и назвали заполненную спецификацию контрактом агента. Критерии успешного завершения задачи в ней относятся к полю «Цель».
Поэтому сначала определяют, какие решения агент может принимать самостоятельно и какими инструментами пользоваться. Затем эти требования превращают в инструкцию для модели.
Права доступа, допустимость действий и лимиты выполнения нужно проверять программно. Одного запрета в промте недостаточно, чтобы обеспечить соблюдение этих ограничений.
Промт наследует дефекты
Хороший промт — следствие хорошей спецификации агента.
Недоработки спецификации могут перейти и в промт. Если требования противоречат друг другу, противоречивым получится и промт: модели придётся выбирать, какое правило соблюдать.
Второй дефект — неопределённый результат. Если мы сами не решили, какой ответ считать правильным, модель может заполнить пробелы своими предположениями. Чем больше таких решений остаётся на её усмотрение, тем менее предсказуемо поведение агента.
и только потом пишем промт
Структура важнее длины
Промт на две страницы может работать хуже, чем короткая инструкция.
Хорошему промту нужна понятная структура. Сначала в нём задают роль агента и конкретную задачу. Затем — критерии: как понять, что результат правильный. После этого фиксируют ограничения и приоритеты правил.
Приоритеты правил нужны на случай, когда требования противоречат друг другу. Отвечать быстро важно, но защита персональных данных всегда важнее скорости. Такой порядок записывают заранее, чтобы модели не пришлось выбирать самой.
Отдельно определяют, когда агент должен остановиться или передать задачу человеку. Наконец, задают формат результата. В автоматизации он особенно важен: ответ модели часто читает следующий компонент системы.
Одна только длина текста не определяет качество промта. Важно, насколько ясно задан каждый элемент. Есть и ещё два условия: промт должен соответствовать архитектуре агента и быть проверяемым, чтобы на тестовых примерах можно было оценить, как система соблюдает требования.
Когда ответ читает система
ИИ может ответить правильно по смыслу — и всё равно сломать автоматизацию.
Свободный текст удобен человеку, но следующему шагу автоматизации часто нужны конкретные поля. Допустим, агент оценил клиента и написал: «У клиента, вероятно, повышенный риск». Человеку всё понятно. А следующий компонент не знает, какой поставить статус, запускать ли проверку и что делать дальше.
Когда следующий шаг должен автоматически использовать ответ, нужен структурированный вывод: агент заполняет заранее заданные поля. В нашем примере их шесть: тип обращения, решение, недостающие данные, следующее действие, нужна ли передача человеку и короткое объяснение. Значения полей должны опираться на исходные данные и правила процесса. Если сведений не хватает, это нужно явно указать.
Формат — ещё не решение
Структурированный вывод упрощает обработку ответа и проверку его формата. Но сам по себе не гарантирует правильного решения.
Получив структурированный ответ, программа проверяет его по заданной схеме. Она смотрит, все ли обязательные поля на месте, правильные ли у них типы и входят ли значения в разрешённые варианты.
Если структура нарушена, заранее выбирают способ обработки: повторить генерацию, перейти на резервный сценарий или остановиться. Число повторных попыток ограничивают.
повтор генерации, резервный сценарий или остановка
Но и ответ, прошедший все три проверки, может быть ошибочным: поля заполнены по правилам, а риск при этом оценён неверно. То же с уверенностью модели: если она говорит, что уверена на 95 %, это не значит, что её точность действительно 95 %. Проверка схемы контролирует формат. Надёжность решений оценивают на тестовых данных и отслеживают в работе системы.
Формат можно задать схемой, например JSON Schema, и использовать режим структурированного вывода, если модель его поддерживает. Но система всё равно должна обрабатывать отказ модели, незавершённый ответ и нарушения бизнес-правил. Просьба «верни JSON» в промте сама по себе не гарантирует соблюдения схемы.
Десятки вариантов вместо ручного подбора
Вместо ручного подбора формулировок можно генерировать и сравнивать десятки вариантов промта.
Если у агента есть качественная спецификация, её можно автоматически превратить в промт. Перед генерацией проверяют требования на противоречия, а из одной спецификации получают несколько вариантов промта.
Дальше все варианты прогоняют на одном наборе тестов, и различия между ними становятся видны. Один может оказаться точнее, но дороже. Другой — быстрее, но слабее на редких случаях. Третий — чаще передаёт задачу человеку. На тестах проверяют, помогает ли это снизить число опасных ошибок и насколько увеличивает нагрузку на людей.
Тогда промт выбирают по измеримым результатам тестов: качеству, времени выполнения, стоимости и частоте передачи человеку. Выбранную версию дополнительно проверяют на отдельном наборе примеров, который не использовали при подборе, чтобы не подогнать промт под знакомые тесты.
Промт как инженерный артефакт
Работа над промтом становится циклом: спецификация, генерация, тест, оценка, улучшение.
Спецификация задаёт требования для всего цикла: из неё генерируют варианты и по её критериям оценивают результаты. После оценки уточняют промт, а при необходимости — требования или архитектуру. Изменения сохраняют как новую версию.
Меняется и роль человека. Вместо бесконечного подбора слов он отвечает за качество требований, тестовых сценариев и критериев оценки. Так промт превращается из текста, который редактируют на глаз, в инженерный артефакт, версии которого сохраняют, сравнивают и могут оптимизировать автоматически.
Человек вручную подбирает слова и оставляет вариант, который «звучит лучше».
Без результатов тестов трудно объяснить, почему одна версия лучше другой.
Промт генерируется из спецификации, у каждой версии — номер и результаты тестов.
Человек отвечает за требования, тестовые сценарии и критерии оценки.
Что важно запомнить
Промт — следствие спецификации
Роль, цель, входные данные, инструменты, ограничения и критерии результата определяют до первой строки промта.
Пробелы оставляют место для догадок
Противоречивые требования дают противоречивый промт, неопределённый результат — догадки модели. Чем больше решений оставлено ей, тем менее предсказуем агент.
Однозначность вместо объёма
Роль и задача, критерии, ограничения, приоритеты, передача человеку и формат результата — каждый элемент задан однозначно и проверяется на тестовых примерах.
Процессу нужны поля
Структурированный вывод отвечает на вопросы следующего компонента: какой статус поставить, запускать ли проверку, что делать дальше.
Формат проверяют, решение — тестируют
Проверка структуры выявляет пропущенные поля, неверные типы и недопустимые значения. Но «уверена на 95 %» не значит точность 95 % — надёжность показывают тесты на данных и метрики.
Промт выбирают по тестам
Варианты генерируются из спецификации и сравниваются на одном наборе тестов. Человек отвечает за требования, сценарии и критерии оценки.
Сначала проектируем систему, потом пишем промт.
Читайте также
Всё обучение
Как понять, что ИИ-агент действительно стал лучше
Инженерия обвязки: что делает ИИ-агента управляемым и надёжным
Инженерия контекста: как научить ИИ-агента понимать ситуацию
Как данные движутся по ИИ-воркфлоу
ИИ-операции и инструменты: как решение модели становится действием
Архитектура ИИ-агента: от LLM-функции до графа навыков
ИИ-платформа: как собрать агентов в единую систему
Где процессу нужен ИИ-агент, а где хватит правила
Что нужно, чтобы ИИ-автоматизация реально заработала
Как превратить человеческое мышление в работающего ИИ-агента
AI-First компания: какая работа остаётся человеку в мире ИИ-агентов
Как перестроить процесс под ИИ-агентов и не потерять контроль
Как найти точки автоматизации с максимальной отдачей
Как увидеть бизнес-процесс таким, какой он есть на самом деле
Как провести рентген бизнеса и извлечь знания экспертов
Как выбрать правильный процесс для автоматизации
От механизации до ИИ-агентов: как эволюционировала автоматизация
Бизнес как система процессов: как потоки данных создают ценность
AI-First-компания: новые роли и новая оргструктура
AgentOps: шесть шагов от идеи до работающего ИИ-агента
ИИ-стратегия: три уровня внедрения ИИ-агентов в бизнес
Готова ли ваша компания к ИИ-трансформации?
Три трансформации, которые полностью изменили бизнес
Где ИИ-агенты создают бизнесу максимум ценности
Пять уровней эволюции ИИ-агентов
Кто такой ИИ-агент и почему он меняет устройство компании
Что такое AI-First-компания и как она работает
Дальше — практика
Материал основан на третьей лекции курса по автоматизации бизнес-процессов с ИИ-агентами.
В следующей статье — инженерия контекста: чем контекст отличается от промта, как его собирают под конкретную задачу, почему агенту нужно уметь забывать и зачем давать модели минимально достаточный набор данных, а не всё сразу.
От диагностики бизнеса
— до работающего агента.