SavePearlHarbor

Evals: что должен знать каждый AI-инженер в 2026

—

от автора

admin

В июле 2025 coding-агент в Replit проигнорировал явный запрет на изменения файлов (code-freeze) и удалил production-базу – данные примерно 1200 компаний, позже заявив, что «сделал катастрофическую ошибку». Operator от OpenAI, которого попросили всего лишь найти дешевые яйца, сам купил их на Instacart на $31.43 – в обход собственного подтверждения покупки. Официальный чатбот мэрии Нью-Йорка советовал предпринимателям нарушать закон: говорил, что можно забирать чаевые работников и отказывать арендаторам с жилищными ваучерами Section 8. Эти и другие инциденты сведены в обзоре «Towards a Science of AI Agent Reliability», где каждый разделен по характеру сбоя: тяжесть вреда, нарушение полномочий, плохая калибровка.

Ни один из этих случаев не всплыл бы в обычном демо. И ни один бенчмарк про них заранее бы не предупредил.

Публичные бенчмарки полезны – по ним видно, какая модель в целом сильнее и куда движется фронтир. Но они отвечают на другой вопрос. Высокий балл на лидерборде не говорит, справляется ли система с вашими задачами: для этого нужны собственные evals и бенчмарки под конкретные задачи. А часть аспектов – безопасность, устойчивость к злоупотреблениям, поведение под атакой – бенчмарком в принципе не измерить; в этих случаях работает red-teaming. Современная AI-система – это модель в симбиозе с retrieval, tools, memory, routing, prompts, state, permissions. Вы ответственны за всю систему и хотите понимать, как хорошо работает именно она, в то время как публичный бенчмарк измеряет только модель.

Эта статья описывает:

  • что каждому AI-инженеру стоит понимать про evals в 2026

  • почему это становится одним из самых ценных навыков на рынке

Почему этим стоит заняться именно сейчас

AI систем стало много, и они массово пошли в прод. Бизнесу теперь важно не то, как выглядит демо, а возможность измерить AI продукт и спрогнозировать его рост – иначе непонятно, во что вкладываться и что обещать клиентам. Без evals этого не сделать. Четыре причины, почему заняться ими стоит уже сейчас:

Агенты перестали отвечать и начали действовать. Раньше плохой ответ был погрешностью – пользователь его игнорировал. Теперь цена ошибки стала материальной. Система пишет код, тратит деньги, ходит в прод, дергает чужие API. Деплоить действующего агента без evals – деплоить его вслепую.

Vibes не масштабируются. «На демо выглядит хорошо» – это вывод по паре-тройке примеров, которые вы прокликали руками. В проде через систему проходят тысячи разных запросов, и глазами уже не понять, стало ли лучше после смены промпта, модели или retrieval. Без evals любое улучшение – это вера, а не знание.

Это дефицитный навык, и он не привязан к инструменту. Вызвать LLM умеет каждый, а вот отличить систему, которая действительно решает задачу, от той, что лишь выдает уверенный, но неверный ответ – почти никто. OpenAI прямо называет eval-датасет «differentiated, context-specific dataset that is hard to copy» – то, что не скопируешь вместе с весами модели (How Evals Drive the Next Chapter in AI). И он не устаревает с релизами: дело в методологии измерений, а не в том, какая модель сегодня в топе.

И в след за всем этим факт: за последние ~18 месяцев прирост надежности заметно отстает от прироста способностей – модели стали точнее, но не надежнее (Towards a Science of AI Agent Reliability).

Измерять надо систему, а не модель

Еще недавно всех интересовало, какая модель умнее. Сейчас куда важнее, насколько надежно вся система доводит реальные задачи до конца.

Возьмите один неудачный запрос: модель все поняла верно, retrieval достал не тот файл, tool call упал, retry испортил state – и ответ оказался неверным. Каждый компонент сам по себе отработал нормально, а система – нет. Это подтверждают и бенчмарки:

  • τ²-bench вводит dual-control: агент должен не просто действовать сам, а вести пользователя. На новом dual-control-домене (Telecom) gpt-4.1 (pass^1) берет лишь 34% – против 74% на классическом single-control-домене Retail. Тот же класс модели проседает там, где появляется координация с человеком, а не чистый reasoning.

  • На MCP-Atlas (1000 задач, 220 инструментов) 63% диагностированных провалов оказались cognitive, а не tool-call: модель вызвала инструменты правильно, а потом остановилась слишком рано или плохо синтезировала результат.

Результат одной и той же модели меняется на десятки пунктов в зависимости от системы вокруг нее. Значит, единица оценки – это система, а полезный выход eval’а – не общий pass rate, а разбивка по тому, где именно сломалось: reasoning или координация, tool-call или синтез, retrieval или модель. Именно это говорит вам, что стоит чинить.

Eval-стэк, который вам реально нужен

Eval-стэк собирается из нескольких слоев проверок, и у каждого свои сильные стороны и слепые зоны (их я разберу ниже по очереди). Ни один слой в одиночку не ловит все, поэтому их комбинируют так, чтобы то, что проскочило сквозь один слой, поймал другой. Этот принцип хорошо разобран в инженерном гайде Anthropic «Demystifying Evals for AI Agents», на который я ниже неоднократно буду ссылаться.

Offline evals прогоняется до релиза в CI – регрессии, промпты, апгрейды модели, routing, изменения инструментов. Дешево и повторяемо. Тут стоит запомнить одно различие из того же гайда Anthropic: capability-evals стартуют с низкого pass rate, а regression-evals должны держаться около 100%. Целевой результат 100% сам по себе полезен только, чтобы ловить регрессии. Он не показывает, что именно улучшать, потому что расти уже некуда.

Online evals прогоняются на реальном трафике – task completion, latency, cost, drop-off, human overrides. Ближе к реальности и шумнее. Они дополняют продуктовые A/B-тесты на живых пользователях, но не заменяют их: eval измеряет качество ответов системы, а A/B – влияние изменений на метрики продукта.

Human evals – это слой, где вы задаете, что значит «хорошо»: usefulness, ясность, вкус. Дорого, но незаменимо. OpenAI советует собрать небольшой golden set из примеров вида input→желаемый output и относиться к нему, как к авторитетному эталону суждения вашей команды.

LLM-as-judge полезен, но опасен. Хорош для первичной сортировки, проверок стиля и тона, сравнений по рубрике, обобщения типовых ошибок. Но плох как единственный источник истины для factual correctness, security, тонкой корректности кода, любых adversarial-задач. И у него есть biases, которые заметить труднее, чем у людей. Если используете судью – не доверяйте ему на слово, а измеряйте, насколько его оценки совпадают с человеческими: в Bloom от Anthropic судью (Opus 4.1) сверили с людьми на 40 транскриптах – корреляция Spearman 0.86. То есть судья годится, чтобы отсортировать и подсветить проблемы, но не чтобы выносить окончательный вердикт.

Execution-based evals – золотой стандарт для агентов, про них – отдельный раздел ниже.

Safety и red-teaming evals – слой, который чаще всего пропускают. Red teaming наступателен: вы проактивно ищете провал сами, а не ждете, пока он проявится. Но у метода есть важное ограничение, на которое прямо указывает Microsoft: red-teaming находит уязвимости, но не измеряет, насколько они распространены – один найденный jailbreak еще не говорит, насколько он часто-воспроизводимый.

Execution-based evals: оценивайте по фактическому результату, а не по словам агента

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

Канонический паттерн – SWE-bench Verified: агент выдает патч, патч применяется в контейнере, и прогоняется настоящий тестовый набор репозитория. Задача засчитана, только если все ранее падавшие тесты (FAIL_TO_PASS) теперь зеленые, и все ранее зеленые (PASS_TO_PASS) остались зелеными – фикс должен отработать и ничего не сломать. Никакого судьи, никакого string-match. То же самое делают OSWorld на реальной ОС и Terminal-Bench в терминале.

Так это работает и в проде: в Gaijin Entertainment на проекте EdenSpark eval-suite агента проверяет не его отчет, а сам результат – собрался ли артефакт без ошибок, на месте ли нужные элементы и связи. Так ловятся баги, незаметные в тексте ответа, например, рассинхрон состояния (state-drift), когда агент планирует по своей памяти о сделанных действиях, а не по реальному состоянию, и со стороны это выглядит как слабая модель, хотя дело в harness.

Собрать такие проверки помогает Inspect AI от UK AISI.

Что делает eval хорошим

Короткий чеклист c моими критериями:

  • Relevant – проверяет то, от чего продукт реально зависит.

  • Diagnostic – показывает причину и место провала, а не просто pass/fail.

  • Repeatable – на одинаковом входе eval дает стабильный, сравнимый от прогона к прогону результат; иначе разницу между «до» и «после» не отличить от случайного разброса. Поведение модели вероятностное, поэтому для user-facing считайте по нескольким прогонам – важно, чтобы успех был каждый раз, а не один раз из k (pass^k против pass@k, Anthropic).

  • Hard to game – eval почти всегда измеряет не саму цель, а ее proxy: «ответ полезен» напрямую измерить трудно, поэтому берут что попроще – «есть нужные ключевые слова» или «код компилируется». Проблема в том, что proxy может быть положительным, хотя задача не решена: модель наберет нужные слова или напишет код, который компилируется, но не работает. Поэтому proxy важно и грамотно выбирать, и правильно интерпретировать – положительный proxy сам по себе еще не значит, что задача решена; где можно, измеряйте результат напрямую.

  • Statistically honest – сырому результату верить нельзя: тот же eval сегодня даст 85%, завтра 80% из-за случайности. Поэтому нужно смотреть не на голый процент, а на доверительный интервал и на то, значима ли разница между прогонами – как это считать, подробно у Anthropic.

  • Runnable often – evals полезно разделять по частоте прогона. Но набор, который гоняется на каждое изменение, должен состоять из атомарных и значимых проверок: каждая быстрая и несет собственный сигнал – иначе его быстро перестанут запускать.

Определение хорошо сформулированного eval task у Anthropic: если два эксперта, глядя на один и тот же ответ, независимо вынесут одинаковый вердикт pass/fail – значит, задача сформулирована хорошо. Если вердикты расходятся – дело в формулировке, а не в оцениваемой системе.

Evals должны влиять на инженерные решения команды. Иначе – это просто красивый дашборд.

Ошибки, которые обходятся дороже всего

Самые дорогие ошибки в evals – не в модели, а в том, как вы ее измеряете и как читаете результаты.

  • Принимать ранг в leaderboard за качество продукта: публичные тест-сеты годами лежат в открытом доступе и утекают в обучение, так что высокий балл может оказаться выученным наизусть, а не реальной способностью.

  • Мерить только финальный успех и не видеть, где именно сломалось. Менять инструменты, данные, промпт и модель разом – и потом не понимать, что из этого помогло.

  • Игнорировать cost и latency.

  • Слепо доверять LLM-судье.

  • А самая коварная – это ошибка интерпретации: списать низкий балл на «слабую модель», когда на самом деле сломан сам eval. На CORE-Bench Opus 4.5 подскочила с 42% до 95% после починки grading-багов, неоднозначных формулировок и слишком жесткого scoring (он засчитывал «96.12» как ошибку, когда ждал «96.124991…») – сама модель не менялась. Прежде чем сделать вывод про агента, проверьте, не сломан ли ваш eval.

Evals становятся инфраструктурой

В 2026 evals – не research-артефакт. Это production-инфраструктура: model selection, regression testing, изменения промптов, архитектурные решения, safety-ревью, оптимизация стоимости, release gates. Anthropic формулирует так: владение и развитие evals должно быть такой же рутиной, как поддержка unit-тестов.

В зрелых AI-командах evals становятся CI/CD-слоем.

В обычной разработке эту роль играют тесты, в ML – validation sets. Для AI-систем такой слой и есть evals, только сложнее: поведение вероятностное, среда динамическая, а определение «правильно» часто не бинарно — поэтому им нужна статистическая дисциплина, а не бинарный true/false.

При этом сами evals – все еще активно развивающаяся область, и в ней остается много нерешенных вопросов. Часть из них я уже называл: модели учатся замечать, что их тестируют, и на тесте ведут себя иначе, чем в реальной работе; а система, прошедшая все behavioral-evals, все еще может быть небезопасной, когда ее намеренно пытаются обмануть или сломать (джейлбрейки, adversarial-запросы). Поэтому evals – необходимая опора, но на по-настоящему рискованных кейсах решение все равно подстраховывает живой человек.

Главное

  1. Публичные бенчмарки – сигнал, но не истина: высокий балл говорит про общий уровень модели, а не про то, решает ли система ваши задачи.

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

  3. Одного success rate мало – нужна разбивка, где именно сломалось.

  4. LLM-as-judge полезен, но проверяйте, насколько его оценки совпадают с человеческими.

  5. Для агентов оценивайте по фактическому результату, а не по словам агента.

  6. Не верьте одному прогону: смотрите на доверительный интервал и на то, значима ли разница.

  7. Хороший eval диагностичен и влияет на решение – иначе это просто дашборд.

  8. Относитесь к evals как к инфраструктуре: владейте ими, как тестами.

Инженеры, умеющие строить надежные evals, в 2026 получат преимущество. Доступ к лучшим моделям тут ни при чем – он у всех примерно одинаковый. Решает умение измерить свою систему и понять, почему она работает.

Я Артем Тарасов, пишу про evals: как измерять AI-системы, понимать, где они ломаются, и держать качество под контролем. Если вашей компании это нужно уже сегодня — я консультирую команды по проектированию и внедрению evals в production. Пишите сюда или в LinkedIn.

Источники

ссылка на оригинал статьи https://habr.com/ru/articles/1050736/