Тестирование и оценка ИИ

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

Подробнее про особенность модели можно почитать тут: https://typesafe.ai/blog/introducing-system-one-models-and-jev или тут https://habr.com/ru/articles/1084030/

Вчера в 23 часа вечера ко мне пришла идея попробовать применить JEV к оценке ИИ систем, и попробовать создать новый подход Jev-as-a-Judge, в итоге почти ночью быстро в eval-ai-library сделал реализацию под Answer Relevancy, пошел за API ключем и тадам,

регистрация недоступна из-за того , что TypeSafeAI не справились с нагрузкой…

В общем теперь сижу жду, когда наконец-то проверю возможности данной модели в оценки ИИ и обязательно расскажу потом вам


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

С чего начать оценку ИИ агента, если у вас сейчас есть только прототип вашего ИИ агента. Попробую поделиться своим взглядом по этапам, потому что процесс оценки ИИ должен развиваться вместе с агентом, а не появляться внезапно перед релизом.

Этап 1. Первый прототип. Возможно еще пока еще четко понятных метрик, но уже с первого этапа нужно иметь трейсинг. Тут можно подключите Langfuse или любой другой аналог. Также начните сохранять в файл сценарии, которые вы проверяете вручную, это будет первый данные для драфта датасета.

Этап 2. Golden dataset. Когда поведение ИИ агента становится более-менее стабильным, из собранных сценариев формируется первый датасет. Это примерно 30-50 примеров, включающих edge cases и негативные сценарии, желательно с примерным ожидаемым результатом для каждого.

Этап 3. Измерение метрик. Когда датасет увеличится до сотни кейсов, и ручной прогон станет долгим, начинайте автоматизировать. Начните с детерминированных метрик, например, проверка, вызван ли нужный тул, правильный ли формат, укладывается ли в лимит агент. Потом уже можно подключить использование LLM as a Judge.

Этап 4. CI/CD. Далее можно внедрить оценку в пайплайн, чтобы она запускалась каждый раз при изменениях промпта, модели или тулов.

Этап 5. Мониторинг в продакшене. После релиза часть трафика анализируется на тех же метриках, что и в предпродакшен стадии, чтобы заметить деградацию качества из-за обновлений модели или новых сценариев пользователей. А проблемные кейсы возвращаются в golden dataset, и процесс начинается заново.

На каком этапе сейчас ваши проекты? 👇


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Сегодня хочу поговорить про оценку голосовых AI агентов, потому что иногда вижу, что команды берут для них те же метрики, что и для текстовых чат-ботов, что в итоге приводит к тому, что ряд важных акспектов просто искллючаются из оценки. Важно понимать, что голос это не текст, который озвучили, там есть свой набор проблем, на которых надо фокусироваться.

1. Каскад ошибок. ASR расслышал «пятнадцать» как «пятьдесят», а LLM дальше уверенно решает не ту задачу. По транскрипту все выглядит хорошо, метрики зеленые, а пользователь получил не то, что ожидал., поэтому оценивать нужно всю цепочку от аудио до результата, а не только текстовый запрос/ответ.

2. Длительность и задержки. Пауза в 2 секунды в чате почти не замечается, а в голосе воспринимается как то, что агент завис. Тут нужны перцентили по каждому этапу работы агента, STT, LLM, TTS, а не средняя по всему разговору.

3. Turn-taking. Так может случиться, что ИИ агент может начать перебивать пользователя, игнорирует его фразы или решает, что человек договорил, когда тот просто взял паузу подумать. Это отдельный класс сценариев, которые нужно учитывать при оценке голосовых ботов.

4. Реальные условия. Шум на фоне, акценты, быстрая речь, слова-паразиты, самоисправления типа «в среду, нет, в четверг». На чистых студийных записях агент отлично работает, а в проде ломается на первом же звонке из необычных окружающих условий.

5. Ответы, непригодные для речи. Слишком длинные ответы, списки и markdown, которые зачитываются вслух, неправильно произнесенные числа, даты и имена. Текстом это выглядит нормально, а на слух это звучит ужасно, поэтому надо проверять как отрабатывает TTS.

Финально могу сказать, что тест-сет для голосового агента это не просто набор вопросов и ответов, а набор аудио с шумом, акцентами, перебиваниями и обрывками, и оценивать в нем нужно каждый слой pipeline отдельно, потому что итоговый ответ может быть правильным даже при сломанном ASR.

А вы сталкивались с тестированием голосовых агентов? Что оказалось самым сложным? 👇


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Недавно наткнулся на разбор того, как одна команда переводила ИИ агента с Claude Opus на GPT-5.6, и там получилась очень показательная история про то, что происходит при смене модели на самом деле.

Первый прогон голден датасета на новой модели дал кучу фейлов, и можно подумать, что новая модель просто хуже, но когда они пошли по трейсам и разобрали каждое падение, то оказалось, что примерно треть провалов - это не модель, а ограничения старого harness под прошлого провайдера. Так произошло потому, что harness годами затачивался под то, как ведет себя Claude, и для другой модели эти доработки просто перестали работать.

Самый яркий пример - тулы. У инструмента чтения файлов было 25 опциональных параметров, Claude передавал только нужные, а GPT-5.6 заполнял все 25 выдуманными значениями, по факту галлюционировал. В результате 52-64% чтений файлов возвращали пустоту, причем без единой ошибки в логах, агент просто тихо не видел код. Плюс отвалилось кеширование промптов, потому что у провайдеров разная логика префиксов, и стоимость на первом прогоне выглядела в разы хуже реальной.
После того как харнес починили,все встало на свои места и новая модель оказалась в 2.2 раза быстрее и на 27% дешевле.

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


Источник: https://ploy.ai/blog/migrating-a-production-ai-agent-to-gpt-5-6


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Сегодня поговорим про ситуацию, с которой сталкивается почти каждый, кто начинает оценивать ИИ системы, а именно отсутствие эталонного ответа. ИИ ассистент отвечает на открытый вопрос, генерирует объяснение или саммари, и один и тот же запрос можно закрыть разными вариантами ответов. В данной ситуации получается, что сравнивать с reference просто не с чем, но оценивать это все таки нужно.

В таком случае фокус смещается с вопроса совпал ли ответ с эталоном на вопрос соответствует ли ответ запросу, контексту и требованиям к системе. И под это есть свой набор reference-free метрик:
Answer Relevancy - отвечает ли ответ на то, что спросили, а не на соседний вопрос.
Faithfulness / Groundedness - опирается ли ответ на переданный контекст, или модель что-то добавила от себя. Это главная метрика, особенно для RAG.
Completeness - закрыты ли все части запроса, если пользователь спросил три вещи, а ответ про одну
Role adherence и tone - остается ли система в рамках своей роли, формата и стиля.
Consistency - дает ли система похожий ответ на перефразированный запрос, это уже метаморфическое тестирование.

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

Теперь про подводные камни.

Первое, все эти метрики считаются через LLM as a Judge, а судья шумит и имеет свои bias, поэтому одного прогона недостаточно и часть результатов все равно нужно смотреть руками.
Второе, judge не умеет проверять факты без контекста, он оценивает правдоподобность, а не истинность, поэтому faithfulness без хорошего контекста ничего не защищает.
Третье, базовые метрики из коробки часто дают высокие оценки, и без кастомных критериев под ваш домен вы получите красивые 90% везде и ноль понимания, где система реально ломается.


Поэтому, отсутствие groundtruth не означает, что нельзя оценить ИИ систему, просто оценка становится многомерной, а ее качество упирается в то, насколько хорошо вы описали критерии.


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

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

На чем стоит фокусироваться?

Начинайте с seed-примеров из реального использования. Возьмите 10–15 диалогов из продакшена или из ручного тестирования. Не придумывайте с нуля, потому что LLM будет генерировать вариации вокруг реальных кейсов, а не выдумывать их из воздуха.

Разворачивайте вариации по трем осям. Одного и того же пользователя с одним запросом недостаточно. Варьируйте: формулировку (как человек спрашивает), намерение (что он на самом деле хочет), поведение (терпеливый, агрессивный, меняет тему на полуслове). Из одного seed-кейса так получают 20–30 дополнительных тестов.

Включайте сложные кейсы намеренно. Датасет только из happy path запросов не покрывает ничего интересного. Генерируйте сценарии где пользователь противоречит себе, запрашивает невозможное, пишет с опечатками и обрывками. Именно на этом агенты ломаются чаще всего.

Проверяйте качество датасета перед использованием. Синтетика часто дает слишком правильные диалоги, который содержат идеальные фразы, чёекие запросы. Прогоните 10% через быструю проверку: если все выглядит как учебник, датасет нереалистичен и стоит вернуться к первым 3-м пунктам выше.

Версионируйте датасет как код. Изменился агент или промпт, значит вам нужна новая версия датасета, иначе непонятно, стало лучше или хуже на каком наборе.

Датасет - это фактически 90% качественного тестирования ИИ системы, поэтому всегда нужно тщательно и правильно подходить к его подготовке.


⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Всем привет, я напоминаю, что 9 сентября начинается новый поток на моем курсе по оценке и тестированию ИИ систем

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

🔗 Оставить заявку можно тут: https://eval-ai.com

На текущий момент это едистенный рускоязычный курс по тестированию ИИ, где мы изучаем
📌 Как тестировать ML/DL, LLM, RAG, AI-агентов
📌 Как строить процесс оценки ИИ
📌 Как работать с DeepEval, EvalLib, Promptfoo, Ragas, LangFuse и др.
📌 Как создавать тестовые данные для тестирования
📌 Как искать уязвимости в ИИ системах

В общей сложности 40+ часов практики на реальных ИИ-системах

Присоединяйтесь и откройте для себя новые скиллы и знания!

Когда агент работает через MCP-инструменты, стандартный "ответ правильный / неправильный" не работает. Нужно смотреть на то, что происходит внутри.

1. Tool selection accuracy измеряет, выбрал ли агент нужный инструмент. Звучит просто, но в реальных сценариях с 10+ инструментами агент не всегда выбирает тот что нужен

2. Argument correctness проверяет, передал ли правильные аргументы в тул. Инструмент вызван верный, но параметры кривые, как следствие задача феил, причем даже часто без явной ошибки. Это нужно проверять отдельно.

3. Task completion rate измеряет, дошел ли агент до нужного результата. Сквозная метрика по всей цепочке вызовов, а не только по финальному ответу.

4. Chain efficiency измеряет, сколько tool calls потребовалось. Агент решил задачу за 8 вызовов вместо 3? Значит что-то идет не так, тут либо проблема в инструкции, либо в промпте, либо в модели.

5. Error recovery rate показывает, как агент ведет себя, когда инструмент (MCP) вернул ошибку. Попробовал ли агент другой путь или сразу сдался? Это один из главных индикаторов зрелости и стабильности работы агента.

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


⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Вчера записывал новое видео по promptfoo в рамках моего курса по оценке и тестированию ИИ систем, и в который раз убеждаюсь, насколько неинтуитивный и сложный в настройке этот инструмент именно для оценки качества ИИ систем (я тут не говорю про redteaming и безопасность).

Я попробовал их UI интерфейс для настройки подключения к моему ИИ прилдожение, потратил минут 30 пытаясь что-то настроить, потом оказалось, что могу через UI только настроить парсинг ответа от ИИ, а вот метаданные уже нет.

В итоге опять пришло спрашивать OpenAI как настроить YAML promptfoo для работы с моим AI агентом и в итоге потратил почти 2 часа просто на неинтуитивную настройку и конфигурацию этого YAML файла. По факту без LLM чисто по документации я бы потратил наверное еще больше времени на это.

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

Пробовали, что думаете, согласны или нет?


⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Список факапов, которые регулярно вижу у многих команд.

1. Тестируют только happy path. Агент прошел идеальный сценарий и вроде ксе отлично, но только в проде так не бывает. Нет edge cases, пустых ответов, недоступных инструментов, отсюда нет понимания, что будет, если что-то пойдет не так.

2. Игнорируют порядок tool calls. Многие проверяют финальный ответ от агента, но не смотрят, что происходит внутри. Агент мог дойти до результата кривым путем, делая лишние запросы, неверный порядок, но без анализа цепочки трейсов это увидеть невозможно.

3. Слишком полагаются на LLM-judge. Там где можно сделать детерминированную проверку, надо делать ее, потому что LLM-судья может в разных прогонах дать разные вердикты и результаты, причем на одном и том же кейсе.

4. Нет бейзлайна. Получили 73% task completion. Хорошо это или плохо? Без точки отсчета это просто цифры, по которым сложно принять решение.

5. Не трекают токен-costs в трейсах. Агент решил задачу, но потратил втрое больше токенов, пока вы один пользуетсь агентов, все ок, но когда количество пользователей возрастет, то могут начаться проблемы.

6. Подключают evaluation после деплоя. Самый дорогая с точки зрения рисков ошибка. Evaluation надо строить с первого прототипа ИИ системы, не после того как что-то сломалось.

Большинство из этого исправляется не сложными инструментами, а правильно выстроенным системным процессом, просто нужно изначаль вам приложить усилия к построению процесса оценки ИИ.


⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Недавно наткнулся на интересную новость, что один ключевой сотрудник Google уходит из компании спустя 27 лет работы. Речь о Джефф Дине, который был 30-м сотрудников Google и фактически являлся ключевым разработчиком в компании, является автором большого количества библиотек, включая TensorFlow - одной из ключевых библиотек в обучении ИИ моделей.

Но речь не о самом Джеффе, а о мемах, которые сделали вокруг него в компании. Эти шутки возникли среди разработчиков Google из-за реального огромного вклада Дина в поисковые алгоритмы и искусственный интеллект и фактически являются аналогом мемов про Чак Норриса, но в ИТ. Для Джеффа в том числе в Google придумали 11 грейд, хотя их все 10:)

В общем, если вам хочется поднять себе немного настроения, ссылка на полную библиотеку тут:

https://github.com/LRitzdorf/TheJeffDeanFacts


Вот парочка оттуда:

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

• Компиляторы не предупреждают Джеффи Дина. Джефф Дин предупреждает компиляторы

• На клавиатуре Джеффа Дина две клавиши: 1 и 0

• Джефф Дин однажды поднял веб-сервер одним вызовом printf(). Другие инженеры добавили тысячи строк комментариев с пояснениями, но так и не поняли, как он работает. Сегодня программа работает в качестве фронтэнда Google Search

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


⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Нашел вот такой полезный ресурс, в котором рассматриваются различные подходы к созданию harness вокруг ваших ИИ агентов.

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

Источник: https://github.com/justxor/Harness_ru


⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Всем привет, я напоминаю, что 9 сентября начинается новый поток на моем курсе по оценке и тестированию ИИ систем

И если вы все еще хотите записаться и получить скидку 10%, то осталось всего 7 дней!

🔗 Оставить заявку можно тут: https://eval-ai.com

На текущий момент это едистенный рускоязычный курс по тестированию ИИ, где мы изучаем
📌 Как тестировать ML/DL, LLM, RAG, AI-агентов
📌 Как строить процесс оценки ИИ
📌 Как работать с DeepEval, Promptfoo, Ragas, LangFuse и др.
📌 Какмо создавать тестовые данные для тестирования
📌 Как искать уязвимости в ИИ системах

В общей сложности 40+ часов практики на реальных ИИ-системах

Присоединяйтесь и откройте для себя новые скиллы и знания!

Мир меняется, но требования остаются неизменными 😂😂

Хочу поделиться апдейтом, который я недавно добавил в свою библиотеку eval-ai-library, и заодно рассказать, почему я вообще над этим работал.

Когда команды берут готовые инструменты оценки, такие как DeepEval, Ragas, Promptfoo, то они получают набор стандартных метрик: faithfulness, answer relevancy, contextual precision и так далее. Работает это отлично, пока ваша AI система решает более-менее типовую задачу. RAG над документами, чат-бот поддержки, что-то в этом роде.

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

Стандартные метрики этого не покроют. И вот тут начинается самое интересное, потому что команды либо забивают на эти аспекты, потому что "нечем измерить", либо начинают вайкодить свои промпты, что превращается в отдельный инженерный проект.

Чтобы упростить этот процесс, я добавил в eval-ai-library возможность создавать полностью кастомные метрики буквально за несколько минут. Вы описываете промпт с динамическими переменными (input, output, context, reference, что угодно), задаете формат ответа от LLM-судьи, и библиотека сама парсит ответ, вытаскивает score и reasoning, считает стоимость оценки. Никакой возни с JSON-парсингом и обработкой ошибок LLM.

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

А что вы обычно делаете, когда стандартных метрик не хватает для вашей задачи?



⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Пока весь фокус на capability-бенчмарках, буквально пару недель назад восесь стран (Сингапур, Япония, Австралия, Канада, Франция, Кения, Корея, Великобритания) + ЕС провели совместное тестирование безопасности агентных ИИ.

Они прогнали ИИ агентов через примерно 1500 задач и 1200 тулов на девяти языках, от английского до кисуахили и главный результат, который они получили, что safety pass rate у лучшей модели составил всего около 57%.

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

Отдельным экспериментом были выполнены задачи, которые анализировали, можно ли доверить оценку поведения агентов другой модели-судье, а не человеку. И результаты оценки разошлись с человеческой оценкой на 23-28%, что говорит о том, что AI-судьи пока не могут надежно заменить людей в оценке того, что ИИ агент реально сделал.

Поэтому, если тестируешь ИИ агентов сам, то важно помнить, что да, можно прикрутить LLM as a Judge, но это все еще ненадежно и требует ревью результатов со стороны человека.


Источник: https://www.aisi.gov.uk/blog/international-joint-testing-exercise-agentic-testing


⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Сегодня поговорим о Robustness testing через призму метаморфического тестирования.

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

Проще говоря:
Мы задаём системе вход X и получаем результат Y.
Затем трансформируем вход (например, перефразируем запрос, добавляем шум, изменяем порядок элементов) и получаем новый результат Y1.
Вместо того чтобы знать точное значение Y1, мы проверяем, что оно связано с Y через заранее определённое правило (метаморфизм).

Теперь вернемся к проверке устойчивости AI к перефразировкам и шуму.

Смысл простой:
Если модель правильно отвечает на вопрос «Какая столица у Франции?», то и на все перефразировки («Франция столица какого города?», «Столичный город Франции?») она должна давать тот же корректный ответ — «Париж».

Это и есть метаморфизм: изменяя входные данные (перефраз, шум, опечатка), мы ожидаем, что результат должен остаться инвариантным или близко похожим к оригинальному (наш Y1).

Как формировать датасеты для такого тестирования:
⁃ Берем базовый набор запросов с известным правильным ответом.
⁃ Автоматически генерируем перефразировки (через LLM, шаблоны или вручную).
⁃ Добавляем «шумные» варианты: опечатки, случайные символы, жаргон.

Что это дает?
Мы строим не просто тестовый набор, а семейства запросов, которые проверяют:
1. Сохраняет ли модель правильность при изменении формы вопроса?
2. Насколько она устойчива к «грязным» данным?
3. Есть ли случаи, где она внезапно «ломается» и начинает галлюцинировать?

По сути, Robustness testing - это частный случай метаморфического тестирования. Мы заранее знаем правильный ответ и проверяем, что он не изменяется серьезно при трансформации запроса.


⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Недавно изучил исследование "Coin Flip Judge?" , в котором исследователи прогнали 29 задач из 10 категорий через две judge-модели от OpenAI, повторяя одну и ту же пару ответов много раз.

Результат получился интересным, потому что судья меняет вердикт в среднем в 13,6% прогонов. На 28% вопросов отклонение было выше 20%, а на одном вопросе судья менял решение в 56% случаев, то есть по сути как подбрасывать монетку.

Плюс также был обнаружен position bias, где GPT-4o-mini в роли судьи значимо чаще выбирал ответ, который стоял на первой позиции, почти в 72% случаев, независимо от содержания.

Получается, если один раз прогнать evaluation через LLM as a judge и получить ответ, например, “модель А лучше модели Б”, то это вполне может быть просто шум рандомизации, а не реальное различие.

Что с этим делать? Авторы посчитали: чтобы мажоритарное голосование с 95% вероятностью совпало с эталонным вердиктом на 50 прогонах, нужно минимум 11 повторов на кейс, а для вопросов с высокой дисперсией около 15 и больше.

Практически в eval пайплайне это выглядит так, что каждый кейс прогоняешь через judge не 1, а 15-20 и берется общий средний вердикт, а не первый попавшийся. Также можно анализировать отклонение по кейсу, и если оно высокое, то это сигнал, что сам кейс неоднозначный, а не что судья плохой.

Да, выходит дороже по токенам, зато вердикт наконец что-то значит и будет объективен.

Источник: https://arxiv.org/abs/2606.13685



⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Всем привет! У меня отличные новости, я определился с датой старта 4-го потока на курсе по оценке и тестированию ИИ систем!

Ииии…. мы начинаем 9 сентября!

Если вы давно хотели изучить для себя эту область тестирования, но откладывали, то сейчас до 19 августа вы можете записаться на курс и получить скидку 10% на все обучение.

Для записи нужно просто оставить заявку на сайте: eval-ai.com

Напомню, что это едиственный полноценный русскоязычный курс по тестированию ИИ, которые охватывает большое количество апспектов работы с ИИ, такие как:
- Оценка моделей ML/DL
- Оценка и тестирование LLM
- Оценка и тестирование RAG систем и AI агентов
- Оценка генерации картинок и видео
- Оценка предвзятости моделей и их безопасность

Курс включает в себя:
1. Теоретические знания (16 часов онлайн лекций в живую)
2. Лекции по практике (более 20 часов дополнительных видео)
3. Домашние задания (в среднем у ученика уходит от 2-8 часов на выполнение домашней работы после каждой лекции)
4. Работу с реальными ИИ системами (для курса подготовлены реальный RAG системы, ИИ агенты, модели OpenAI и Google Gemini)

Жду все желающих расширить свои знания в части тестирования ИИ систем!


⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Кажется то, что происходит с бенчмарками агентов последние пару месяцев, реально стоит обсудить.

В апреле Berkeley RDI взломали восемь индустриальных agent-бенчмарков, таких как Terminal-Bench, SWE-bench, WebArena, OSWorld, GAIA и другие, и получили результаты, близкие к 100%, вообще не решая задачу по существу. Где-то модель просто подделывала pass результат. Где-то агент скачивал эталонный файл по ссылке из конфига задачи и сравнивал его сам с собой. Семь повторяющихся паттернов сразу на все восемь бенчмарков: агент и оценщик без изоляции, эталоны лежат рядом с тестами, слабая верификация.

И это еще не все.
OpenAI провели свой аудит SWE-bench Verified и отказались от него: из 138 провалов модели, 59,4% оказались дефектами самих тестов, а не модели.

А METR зафиксировали reward hacking у o3 на уровне 30-100% в зависимости от задачи. Но хуже другое, что модель это осознает. На вопрос " соответствует ли план намерениям пользователя?" o3 честно отвечала "нет" 10 из 10 раз и все равно продолжала делать по-своему. Даже прямой промпт "не хакай reward" снижал частоту только до 70-80%.

К чему я это?
Если полагаешься на публичные бенчмарки как на ориентир работает / не работает ИИ агент например, то сейчас это выглядит уже достаточно недостоверно. ИИ модель, которая осознанно врет про свои намерения, так же легко найдет дырку в evaluation harness.

Изоляция evaluator, свой golden dataset вне публичного размещения и проверка решена ли задача реально, а не прошел ли просто тест, теперь становится необходимым минимумом.


Источники:
Berkeley RDI
OpenAI
METR


Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)