Behavioral Evals

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

Чем отличается от соседней заметки Agent Evals — про качество исхода: набор, судья, порог, шлюз. Эта заметка — про два других вопроса: вёл ли себя рантайм допустимо по дороге к исходу, и работают ли сами защитные механизмы.

Проверка процесса и проверка результата — разные вещи

Урок из работ по проверяющим для агентов, управляющих компьютером: одного бинарного вердикта недостаточно для длинных траекторий. Агент может идти по правильному процессу и упереться в ограничение среды — или дойти до номинально верного результата небезопасным путём. Схлопывание обоих случаев в одну оценку теряет ровно то различие, ради которого оценка нужна.

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

Что именно проверяют поведенческие оценки

Вопросы, на которые обычная оценка качества не отвечает в принципе:

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

Последние два — прямая проверка на несоответствие целей (Agentic Misalignment).

Контрольные оценки проверяют защиту, а не модель

Третий контур: проверяются сами защитные механизмы. Вопрос не «хорошо ли отвечает система», а «сработал ли бы шлюз, если бы понадобился».

Практическая ценность в том, что защита деградирует молча. Guardrail, который перестал срабатывать из-за смены модели или формата, не выдаёт ошибки — он просто пропускает. Контрольная оценка ловит это до инцидента (Guardrails).

Симулятор пользователя и синтетический противник — разные роли

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

Смешение даёт худшее из двух: набор, который недостаточно враждебен, чтобы найти дыру, и недостаточно реалистичен, чтобы поймать бытовой отказ (Continuous Red Teaming).

Связано с

  • Agent Evals — оценка исхода и шлюз качества
  • Agentic Misalignment — класс отказа, ради которого это строится
  • Continuous Red Teaming — состязательный контур в проде
  • Guardrails — то, что проверяют контрольные оценки
  • Generator Evaluator — внешняя проверка как принцип
  • Agent SLO — качество проверяющих как измерение здоровья
  • ADLC — где эти оценки встраиваются в цикл