Проверки качества и наблюдение

Проверка качества отвечает на заранее поставленный вопрос. Наблюдение показывает, что происходит в работе. Вместе они дают основание продолжить, ограничить или остановить процесс.

Вероятностную систему нельзя принять по одному удачному примеру. Но и бесконечный набор искусственных задач не заменяет производственный результат. Нужны три связанные области:

1. проверка до выпуска;
2. наблюдение в эксплуатации;
3. обновление постоянных проверок по результатам и инцидентам.

Начните с решения #

Перед созданием теста запишите, какое решение он изменит.

Плохая формулировка: «оценить качество ответов».

Рабочая формулировка: «решить, можно ли разрешить системе готовить ответы для сегмента X на A1 при доле критических фактических ошибок ниже согласованного порога и обязательной ссылке на источник».

Порог выбирается по цене ошибки, исходному уровню и возможностям проверки. Универсального процента для всех процессов нет.

Проверяйте составную систему #

Результат создаёт не модель в изоляции. Его создают:

• модель и её настройки;
• постоянный и оперативный контекст;
• инструкция;
• навыки;
• инструменты;
• порядок выполнения;
• права;
• проверки и обработка ошибок.

Проверка хода действий исследует составную систему «агент плюс навык», а не навык в отрыве от среды. [G1-D3-p24], Agent Skills_Day_3.pdf, с. 24.

Поэтому запись результата без версий зависимостей мало пригодна для сравнения. Смена одного компонента может изменить поведение всей системы.

Семь видов проверок #

1. Детерминированные проверки #

Они проверяют точные свойства:

• формат и схема;
• обязательные поля;
• арифметика;
• допустимый диапазон;
• отсутствие запрещённого действия;
• права доступа;
• сборка и тесты кода.

Если правило можно выразить точно, его не следует поручать вероятностному судье.

2. Эталонные примеры #

Набор содержит обычные, пограничные, редкие и вредоносные случаи. Для каждого записано допустимое множество результатов и причина.

Набор разделяют на разработочную и контрольную части. Иначе команда подгонит инструкцию под известные ответы и переоценит устойчивость.

3. Проверка человеком #

Эксперт оценивает смысл, последствия и случаи, которые трудно выразить правилом. Рецензенты получают одинаковую шкалу и примеры. Расхождения разбираются, а не усредняются молча.

Человеческая оценка тоже ошибается. Для существенного решения проверяют согласованность экспертов и сохраняют обоснование.

4. Проверка другой моделью #

Модель может помочь обработать большой поток, когда детерминированного правила недостаточно. Сначала её решения калибруют по человеческой выборке. Затем отслеживают расхождения и смещение.

Такую оценку калибруют по человеческим решениям и применяют там, где правил недостаточно. [G1-D4-p33], Vibe Coding Agent Security and Evaluation_Day_4.pdf, с. 33.

5. Проверка хода действий #

Она исследует:

• выбранный навык;
• порядок шагов;
• вызванные инструменты;
• прочитанные источники;
• использованные права;
• согласования;
• повторы и обходные пути;
• условия остановки.

Хороший финальный результат не оправдывает запрещённый путь. И наоборот, не каждый иной порядок является ошибкой. План задаёт обязательные и запрещённые переходы, а остальное оценивает по результату и расходу.

6. Испытания безопасности #

Они включают внедрение вредоносных инструкций, утечку данных, обход полномочий, подмену инструмента, загрязнение памяти, вредоносную зависимость и неконтролируемое повторение действий.

OWASP перечисляет такие классы риска для агентных приложений. Перечень помогает искать угрозы, но не доказывает достаточность выбранных мер. [OWASP-AGENTIC-TOP10-2026]

Статический анализ, анализ зависимостей и испытания поведения покрывают разные ошибки. Их следует сочетать. [G1-D4-p32]

7. Проверка в эксплуатации #

Реальные входы отличаются от набора. Команда сравнивает сегменты, наблюдает ухудшение, выборочно проверяет результаты и собирает причины ручного вмешательства.

Производственное наблюдение не оправдывает выпуск без предварительных проверок. Оно отвечает за неизвестные случаи, а не заменяет известные.

Проверка результата #

Критерии результата зависят от процесса, но обычно охватывают:

• фактическую правильность;
• полноту;
• соответствие правилам;
• полезность получателю;
• своевременность;
• отсутствие запрещённых данных;
• возможность проверить источник;
• корректное действие в системе.

Для творческой задачи допустимо несколько решений. Тогда шкала описывает свойства результата, а не единственный текст.

Проверка хода действий #

Наблюдаемость должна фиксировать внешне доступные события. Не обещайте чтение скрытых рассуждений модели.

Минимальная запись:

• идентификатор запуска;
• время и инициатор;
• версия среды;
• версия инструкции и навыков;
• ссылки или идентификаторы источников;
• вызовы инструментов и их итоговые состояния;
• выданные и использованные права;
• согласования;
• срабатывания ограничений;
• итог и категория ошибки;
• связь с последующим действием.

Для проверки хода задачи нужны наблюдаемые события и состояния, но не заявление о полном доступе к «мыслям» системы. [G1-D4-p35]

Показатели надёжности #

Один показатель не описывает процесс. Используйте небольшой набор, связанный с решением.

Сходимость всей сессии полезна, но она не скрывает опасный промежуточный шаг. [G1-D4-p37]

Сегменты важнее среднего #

Средняя доля успешных ответов может скрывать провал на редком, но опасном сегменте. Разбивайте результаты как минимум по:

• типу задачи;
• языку или рынку, если это влияет;
• источнику данных;
• уровню риска;
• версии модели и навыка;
• обычному и редкому случаю;
• автоматическому и ручному пути.

Минимальный объём выборки определяется ожидаемой частотой ошибки и решением, которое нужно принять. Если критическое событие редко, отсутствие ошибки в маленькой серии почти ничего не доказывает.

Как обнаруживать ухудшение #

Ухудшение может появиться после смены модели, данных, инструкции, инструмента или состава входов.

Используйте три сигнала:

1. повторный прогон постоянного набора;
2. производственные показатели по сегментам;
3. выборочная человеческая проверка свежих случаев.

Порог предупреждения даёт время разобраться. Порог остановки переводит процесс на A1, A0 или резервный режим. Значения и ответственные согласуются до инцидента.

Разбор ошибки #

Не записывайте «модель ошиблась» как корневую причину. Проверьте:

• был ли результат определён;
• был ли источник верным и свежим;
• выбрала ли система правильный навык;
• были ли инструменты доступны;
• позволяли ли права безопасно выполнить шаг;
• работала ли проверка;
• увидел ли оператор сигнал;
• была ли возможность остановить.

Гипотеза о том, что большинство сбоев агентов вызвано конфигурацией среды, в материалах Google не подтверждена репрезентативной выборкой. [G1-D1-p31], The New SDLC With Vibe Coding_Day_1.pdf, с. 31. Поэтому расследование не должно заранее выбирать виновника.

Рабочая карточка главы #