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