Чому метрики оцінювання AI-агентів брешуть про реальні результати

Ви запускаєте AI-агента. Він проходить усі бенчмарки, тести зелені, а дашборд спокійний. За три тижні користувач повідомляє, що агент у продакшені ухвалює катастрофічно хибні рішення, яких жодна метрика не показала. У статті на DEV Community автор Tamizuddin доводить, що це зазвичай не збій моделі, а збій вимірювання.

Пастка проксі-метрик

Більшість конвеєрів оцінювання агентів складаються з проксі-метрик: точність, precision, recall, оцінки reward-моделі й відсоток завершених задач. Їх дешево рахувати, легко обіграти й легко обдурити, бо вони вимірюють те, що агент зробив, а не те, що він мав зробити.

Мовні моделі стохастичні, контекстні й цілеспрямовані, а агенти на їх основі ще більше, проте їх оцінюють детермінованими статичними метриками зі supervised learning. 99% точності на датасеті не заважає катастрофічно помилятися на незнайомих вхідних даних. Задачу можна «завершити», видаливши не той файл або порушивши політику. А reward-моделі успадковують шум і упередження людських переваг, на яких навчалися. Глибша проблема: агенти оптимізують не вашу метрику, а середовище, і будь-який розрив між ними буде використано.

Міряти наслідки, а не вихід

Альтернатива — перестати міряти те, що агент каже чи робить, і почати міряти те, що відбувається внаслідок цього. У reinforcement learning цей стандарт відомий давно: return, кумулятивна винагорода за реальний або змодельований епізод. В оцінюванні агентів його замінили сурогатними винагородами, бо реальні наслідки дорогі, повільні або небезпечні для спостереження.

Пропоноване виправлення — замінити кожну метрику перевіркою фінального стану світу: головною метрикою має бути валідатор стану, а не класифікатор поведінки, а успіх треба визначати в середовищі, а не в транскрипті. «Якщо ви не можете визначити фінальний стан, ви не знаєте, що будуєте», — пише автор. Проксі ще годяться для швидкої ітерації, але мають бути червоним прапорцем, а не зеленим світлом.

Ціна найдешевшого сигналу

Реальні наслідки вимагають реальних середовищ, даних і відповідальності, тому більшість команд обирають евристики, збіг ключових слів чи оцінку моделлю. Для ітерацій це нормально, для розгортання — фатально. Виправлення технічне й культурне водночас: ставтеся до кожної метрики як до підозрюваного, доки не доведено протилежне, і перевіряйте її питанням: якщо метрика ідеальна, чи може агент усе одно завдати шкоди? Щоб почати, радять інструментувати середовище, логувати фінальний стан після кожного запуску і писати перевірки для 3-5 критичних інваріантів.