Хочу поговорить про то, что я наблюдаю довольно часто, когда команды начинают заниматься оценкой своих AI систем.
Первый вопрос, который мне обычно задают - это какой инструмент использовать (или еще на курсе спрашивают, а будет ли мы изучать то-то). В итоге идет выбор инструмента, DeepEval, Promptfoo, Ragas, Opik Comet, дальше начинается обсуждение фич, интеграций, лицензий, получают какие-то цифры, и на этом часто все заканчивается, потому что что с этими цифрами делать дальше непонятно.
И вот в чём проблема.
Инструмент ИИ оценки - это просто механизм запуска метрик.
Он не скажет вам на каких данных нужно тестировать вашу систему, потому что синтетические запросы и реальный продакшн запросы дают принципиально разные результаты.
Он не скажет вам какие аспекты важны именно для вашего домена.
Он не скажет вам какие метрики можно использовать и нужно ли их калибровать.
Он не скажет вам как интерпретировать результаты, особенно когда одна метрика растет, а другая падает.
Все это по факту методологические решения, которые остаются за человеком независимо от того, какой инструмент вы выбрали.
Я видел команды, которые месяцами использовали DeepEval, получали красивые дашборды с метриками, и при этом не могли ответить на простой вопрос, стала ли их AI система лучше после последнего обновления промпта? Потому что метрики были, но они измеряли только какие-то базовые аспеки ИИ системы, при этом упуская важные нюансы, которые докручиваются уже с помощью методологии.
Сталкивались с такой ситуацией?
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Первый вопрос, который мне обычно задают - это какой инструмент использовать (или еще на курсе спрашивают, а будет ли мы изучать то-то). В итоге идет выбор инструмента, DeepEval, Promptfoo, Ragas, Opik Comet, дальше начинается обсуждение фич, интеграций, лицензий, получают какие-то цифры, и на этом часто все заканчивается, потому что что с этими цифрами делать дальше непонятно.
И вот в чём проблема.
Инструмент ИИ оценки - это просто механизм запуска метрик.
Он не скажет вам на каких данных нужно тестировать вашу систему, потому что синтетические запросы и реальный продакшн запросы дают принципиально разные результаты.
Он не скажет вам какие аспекты важны именно для вашего домена.
Он не скажет вам какие метрики можно использовать и нужно ли их калибровать.
Он не скажет вам как интерпретировать результаты, особенно когда одна метрика растет, а другая падает.
Все это по факту методологические решения, которые остаются за человеком независимо от того, какой инструмент вы выбрали.
Я видел команды, которые месяцами использовали DeepEval, получали красивые дашборды с метриками, и при этом не могли ответить на простой вопрос, стала ли их AI система лучше после последнего обновления промпта? Потому что метрики были, но они измеряли только какие-то базовые аспеки ИИ системы, при этом упуская важные нюансы, которые докручиваются уже с помощью методологии.
Сталкивались с такой ситуацией?
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥4❤2
Периодически вижу в разных обсуждениях тему AI-assisted exploratory testing, и мнения, где одни говорят что это революция в тестировании, другие что очередной хайп. Хочу поделиться своим взглядом на эту тему.
Для начала стоит разделить два разных сценария, которые часто смешивают в одно.
Первый - это когда AI помогает тестировщику в процессе исследовательского тестирования. Генерирует идеи для тест-сценариев, предлагает edge cases на основе требований, помогает быстро разобраться в незнакомой части системы. Здесь AI реально полезен, потому что он расширяет охват того, о чем тестировщик может подумать, особенно в условиях ограниченного времени. Это работает, и я это вижу на практике.
Второй - это когда AI сам проводит exploratory testing автономно, без участия человека. И вот здесь я бы был осторожен с ожиданиями, потому что exploratory testing по своей сути это не просто генерация сценариев и их выполнение. Это исследование системы с пониманием бизнес-контекста, пользовательских ожиданий и интуицией о том, где именно стоит покопать глубже. Это то, что AI пока делает значительно хуже человека, особенно без наличия должного контекста.
Есть еще один момент, который мне кажется важным. Exploratory testing ценен именно тем, что тестировщик замечает неожиданные вещи, где поведение которое формально не является багом, но ощущается неправильным, или сценарий который никто не предусмотрел в требованиях. AI оптимизирует под известные паттерны, и именно эти неожиданные находки он с большой вероятностью пропустит.
Так что я бы сказал, что AI-assisted exploratory testing реально работает как усилитель тестировщика, но пока не как полноценная его замена. Если воспринимать его как инструмент, который помогает думать шире и быстрее, это ценно. Если ожидать что он заменит человеческое исследование системы, то пока это все лишь хайп.
А вы используете AI в exploratory testing? Что реально помогает, а что не оправдало ожиданий? 👇
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Для начала стоит разделить два разных сценария, которые часто смешивают в одно.
Первый - это когда AI помогает тестировщику в процессе исследовательского тестирования. Генерирует идеи для тест-сценариев, предлагает edge cases на основе требований, помогает быстро разобраться в незнакомой части системы. Здесь AI реально полезен, потому что он расширяет охват того, о чем тестировщик может подумать, особенно в условиях ограниченного времени. Это работает, и я это вижу на практике.
Второй - это когда AI сам проводит exploratory testing автономно, без участия человека. И вот здесь я бы был осторожен с ожиданиями, потому что exploratory testing по своей сути это не просто генерация сценариев и их выполнение. Это исследование системы с пониманием бизнес-контекста, пользовательских ожиданий и интуицией о том, где именно стоит покопать глубже. Это то, что AI пока делает значительно хуже человека, особенно без наличия должного контекста.
Есть еще один момент, который мне кажется важным. Exploratory testing ценен именно тем, что тестировщик замечает неожиданные вещи, где поведение которое формально не является багом, но ощущается неправильным, или сценарий который никто не предусмотрел в требованиях. AI оптимизирует под известные паттерны, и именно эти неожиданные находки он с большой вероятностью пропустит.
Так что я бы сказал, что AI-assisted exploratory testing реально работает как усилитель тестировщика, но пока не как полноценная его замена. Если воспринимать его как инструмент, который помогает думать шире и быстрее, это ценно. Если ожидать что он заменит человеческое исследование системы, то пока это все лишь хайп.
А вы используете AI в exploratory testing? Что реально помогает, а что не оправдало ожиданий? 👇
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍5🔥2
5 выводов, которые я сделал за 3 года работы с ИИ проектами:
1. Не сильно важно, какой фреймворк вы используете, гораздо важнее какая методология лежит в основе оценки ИИ систем.
2. При все популярности базовых метрик, таких как Task Compliteness, Answer Relevancy, и так далее, вам все равно нужны будут ваша кастомные метрики под специфику ваших проектов.
3. Датасеты для позитивного, негативного, edge cases, метаморфического тестирования и прочего стоит делать и запускать отдельно.
4. Неважно насколько сильный или популярный фреймворк, вам все равно нужно будет делать ручной анализ результатов и трейсов.
5. Все говорят о том, что ИИ системам нельзя доверять, при этом еще не разу не видел выстроенного процесса оценки ИИ систем
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
1. Не сильно важно, какой фреймворк вы используете, гораздо важнее какая методология лежит в основе оценки ИИ систем.
2. При все популярности базовых метрик, таких как Task Compliteness, Answer Relevancy, и так далее, вам все равно нужны будут ваша кастомные метрики под специфику ваших проектов.
3. Датасеты для позитивного, негативного, edge cases, метаморфического тестирования и прочего стоит делать и запускать отдельно.
4. Неважно насколько сильный или популярный фреймворк, вам все равно нужно будет делать ручной анализ результатов и трейсов.
5. Все говорят о том, что ИИ системам нельзя доверять, при этом еще не разу не видел выстроенного процесса оценки ИИ систем
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥2❤1
Одной из проблем для компаний в части использования ИИ агентов является не только качество, но и стоимость токенов при работе таких ИИ агентов.
Поэтому хотел узнать,если тут кто-то кто уже зававался этим вопросом и находил какие-то решения в части оптимизации?
То что знаю, это:
• промпт оптимизация
• кеширование
• легкие модели для простых задач
• управление моделями
• оптимизация памяти агента
• сокращение размера контекста
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Поэтому хотел узнать,если тут кто-то кто уже зававался этим вопросом и находил какие-то решения в части оптимизации?
То что знаю, это:
• промпт оптимизация
• кеширование
• легкие модели для простых задач
• управление моделями
• оптимизация памяти агента
• сокращение размера контекста
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍3❤1
Многие сейчас либо паникуют что AI заменит тестировщиков, либо наоборот игнорируют изменения и делают вид что ничего особо не происходит. Попробую поделиться тем, что я реально наблюдаю.
Если говорить честно, то часть работы тестировщика AI уже делает лучше и быстрее. Генерация тест-кейсов по требованиям, написание автотестов по готовым сценариям, поиск похожих багов в базе, базовое регрессионное покрытие, по идее все это AI агенты умеют делать вполне прилично, и с каждым месяцем делают это лучше.
Но вот что я замечаю параллельно. Чем больше AI берет на себя исполнение, тем более критичными становятся навыки, которые к исполнению не относятся.
Поэтому я выделил ключевые навыки, которые считаю должны быть у тестировщика при работе с AI:
Понимание того что тестировать и почему - это не про написание тест-кейсов, это про понимание рисков продукта, пользовательских сценариев и бизнес-контекста. AI генерирует тесты на основе того, что вы ему объяснили. Если вы сами это понимаете плохо, тесты будут покрывать не то.
Умение оценить качество того, что сгенерировал AI - это отдельный навык, который раньше не был так важен. Автотест написанный AI может быть синтаксически правильным, запускаться без ошибок и при этом проверять совсем не то, что нужно.
Стратегическое мышление о покрытии - не набор скриптов, а понимание что нужно проверить в первую очередь, где самые высокие риски, как выстроить процесс так чтобы AI агенты работали эффективно в его рамках.
По сути роль тестировщика смещается от исполнения к управлению качеством и это, на мой взгляд, делает профессию более интересной, а не менее востребованной.
А как вы сами ощущаете этот сдвиг в своей работе? 👇
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Если говорить честно, то часть работы тестировщика AI уже делает лучше и быстрее. Генерация тест-кейсов по требованиям, написание автотестов по готовым сценариям, поиск похожих багов в базе, базовое регрессионное покрытие, по идее все это AI агенты умеют делать вполне прилично, и с каждым месяцем делают это лучше.
Но вот что я замечаю параллельно. Чем больше AI берет на себя исполнение, тем более критичными становятся навыки, которые к исполнению не относятся.
Поэтому я выделил ключевые навыки, которые считаю должны быть у тестировщика при работе с AI:
Понимание того что тестировать и почему - это не про написание тест-кейсов, это про понимание рисков продукта, пользовательских сценариев и бизнес-контекста. AI генерирует тесты на основе того, что вы ему объяснили. Если вы сами это понимаете плохо, тесты будут покрывать не то.
Умение оценить качество того, что сгенерировал AI - это отдельный навык, который раньше не был так важен. Автотест написанный AI может быть синтаксически правильным, запускаться без ошибок и при этом проверять совсем не то, что нужно.
Стратегическое мышление о покрытии - не набор скриптов, а понимание что нужно проверить в первую очередь, где самые высокие риски, как выстроить процесс так чтобы AI агенты работали эффективно в его рамках.
По сути роль тестировщика смещается от исполнения к управлению качеством и это, на мой взгляд, делает профессию более интересной, а не менее востребованной.
А как вы сами ощущаете этот сдвиг в своей работе? 👇
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥8❤5💯2
Команда запускает оценку, получает accuracy 95% и считает что система работает хорошо. Но когда начинаешь разбираться глубже, оказывается что за этой цифрой может скрываться совершенно разная картина в зависимости от того, как именно она была получена.
Я выделил основные вопросы, которые должны возникать у AI eval инженера, при интерпертации метрик:
1. На каких данных считалась эта метрика. Реальные пользователи задают вопросы иначе, используют другую лексику, уходят от ожидаемого сценария. Система с 95% на синтетическом датасете вполне может показывать 70% на реальном трафике.
2. Что именно считается правильным ответом. Для разных доменов это принципиально разная планка. Медицинский ассистент с 95% accuracy - это значит что в 5% случаев он даёт потенциально опасную информацию. Для чат-бота поддержки те же 5% ошибок абсолютно некритичны. Одна и та же цифра, принципиально разные выводы.
3. Как распределены эти 5% ошибок. Система может ошибаться равномерно по всем типам запросов, а может стабильно работать на 99% кейсов и полностью ломаться на конкретной категории. Агрегированная метрика это скрывает, и именно в этой скрытой категории может лежать самый критичный бизнес-сценарий.
4. По сравнению с чем это 95%. Без baseline непонятно это хорошо или плохо. Предыдущая версия системы давала 97%? Тогда это деградация. Давала 80%? Тогда это прогресс. Цифра без динамики не говорит ничего.
Поэтому когда мне показывают результаты оценки AI системы в виде одной красивой цифры, первое что я делаю, начинаю задавать именно эти вопросы, потому что метрика без контекста - это не знание о качестве системы, это иллюзия этого знания.
А вы сталкивались с ситуацией когда красивые цифры в оценке расходились с реальным поведением системы? 👇
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Я выделил основные вопросы, которые должны возникать у AI eval инженера, при интерпертации метрик:
1. На каких данных считалась эта метрика. Реальные пользователи задают вопросы иначе, используют другую лексику, уходят от ожидаемого сценария. Система с 95% на синтетическом датасете вполне может показывать 70% на реальном трафике.
2. Что именно считается правильным ответом. Для разных доменов это принципиально разная планка. Медицинский ассистент с 95% accuracy - это значит что в 5% случаев он даёт потенциально опасную информацию. Для чат-бота поддержки те же 5% ошибок абсолютно некритичны. Одна и та же цифра, принципиально разные выводы.
3. Как распределены эти 5% ошибок. Система может ошибаться равномерно по всем типам запросов, а может стабильно работать на 99% кейсов и полностью ломаться на конкретной категории. Агрегированная метрика это скрывает, и именно в этой скрытой категории может лежать самый критичный бизнес-сценарий.
4. По сравнению с чем это 95%. Без baseline непонятно это хорошо или плохо. Предыдущая версия системы давала 97%? Тогда это деградация. Давала 80%? Тогда это прогресс. Цифра без динамики не говорит ничего.
Поэтому когда мне показывают результаты оценки AI системы в виде одной красивой цифры, первое что я делаю, начинаю задавать именно эти вопросы, потому что метрика без контекста - это не знание о качестве системы, это иллюзия этого знания.
А вы сталкивались с ситуацией когда красивые цифры в оценке расходились с реальным поведением системы? 👇
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍4
Всем привет!
Сегодня хочу поговорить о терминологии, которая часто вызывает путаницу, а именно почему в контексте ИИ правильно говорить "evaluation" (оценка), а не "testing" (тестирование).
Также это касается поиска информации, потому что если вы будете искать в интернете информацию по тестированию AI, то вам будет выдавать в основном только тестирование с помощью AI, не как проверять сами AI-based системы, потому что правильно будет именно evaluation AI и сейчас разберем почему.
На первый взгляд может показаться, что это просто семантические различия, но на самом деле за этим стоят принципиально разные подходы к проверке качества систем.
Testing (тестирование) - это классический подход из мира традиционного ПО, где мы проверяем соответствие системы четко определенным спецификациям. Есть входные данные, есть ожидаемый результат, есть бинарная оценка: работает/не работает, прошел тест/не прошел.
Evaluation (оценка) - это более подходящий термин для ИИ-систем, потому что здесь мы измеряем качество, а не правильность. Нет единственно верного ответа, есть градации качества.
Например, если мы тестируем калькулятор, то 2+2 должно равняться 4, то это тест. А если мы оцениваем качество генерации текста для решения какой-то задачи, то может быть несколько корректных вариантов, каждый с разным уровнем качества, это и есть evaluation.
В мире ИИ мы работаем с метриками, которые дают нам численную оценку качества, поэтому они не говорят нам "правильно/неправильно", они говорят "лучше/хуже".
Когда мы говорим о проверке ИИ-систем, правильно использовать термин "AI evaluation", а не "AI testing". Это не просто лингвистическая точность, это отражение принципиально другого подхода к оценке качества недетерминированных систем.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Сегодня хочу поговорить о терминологии, которая часто вызывает путаницу, а именно почему в контексте ИИ правильно говорить "evaluation" (оценка), а не "testing" (тестирование).
Также это касается поиска информации, потому что если вы будете искать в интернете информацию по тестированию AI, то вам будет выдавать в основном только тестирование с помощью AI, не как проверять сами AI-based системы, потому что правильно будет именно evaluation AI и сейчас разберем почему.
На первый взгляд может показаться, что это просто семантические различия, но на самом деле за этим стоят принципиально разные подходы к проверке качества систем.
Testing (тестирование) - это классический подход из мира традиционного ПО, где мы проверяем соответствие системы четко определенным спецификациям. Есть входные данные, есть ожидаемый результат, есть бинарная оценка: работает/не работает, прошел тест/не прошел.
Evaluation (оценка) - это более подходящий термин для ИИ-систем, потому что здесь мы измеряем качество, а не правильность. Нет единственно верного ответа, есть градации качества.
Например, если мы тестируем калькулятор, то 2+2 должно равняться 4, то это тест. А если мы оцениваем качество генерации текста для решения какой-то задачи, то может быть несколько корректных вариантов, каждый с разным уровнем качества, это и есть evaluation.
В мире ИИ мы работаем с метриками, которые дают нам численную оценку качества, поэтому они не говорят нам "правильно/неправильно", они говорят "лучше/хуже".
Когда мы говорим о проверке ИИ-систем, правильно использовать термин "AI evaluation", а не "AI testing". Это не просто лингвистическая точность, это отражение принципиально другого подхода к оценке качества недетерминированных систем.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥4❤2👍1
Сегодня поговорим о том, почему оценка качества AI-систем стала критически важной.
Современный AI переживает революцию: от простых классификаторов мы дошли до моделей, которые пишут код, создают изображения, управляют роботами. Но вместе с этим пришли и новые вызовы.
1. Масштаб.
Модели обучаются на терабайтах данных, и классические методы вроде cross-validation уже не работают, потому что это слишком дорого и сложно.
2. Черный ящик.
Почему GPT-4 или 5 дает именно такой ответ или как Stable Diffusion выбирает детали изображения, нам понять практически невозможно. Поэтому оценка современных генеративный AI решений фокусируется на оценке результата.
3. Ответственность.
AI всё чаще работает в критичных сферах: медицина, финансы, автономное вождение. Ошибка в диагнозе - это уже вопрос жизни.
Еще 5 лет назад все было проще. Для классификация, перевод, распознавание речи были стандартные метрики, например, accuracy, BLEU, WER. Сегодня этого стало недостаточно.
Что изменилось:
- Появились LLM и генеративный AI, в которых нужно оценить креативность картинки или полезность ответа.
- Модели стали мультизадачными: пишут код, пишут тексты, создают картинки и видео. Одной метрики для их оценки теперь мало.
- На первый план вышли новые типы проблем, которых раньше не было, а именно предвзятость, справедливость, галлюцинации, безопасность и согласованность.
Именно поэтому сегодня evaluation - это уже не просто подбор метрик, а отдельная дисциплина, которая определяет, насколько безопасно и надежно мы можем доверять современным AI-системам.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Современный AI переживает революцию: от простых классификаторов мы дошли до моделей, которые пишут код, создают изображения, управляют роботами. Но вместе с этим пришли и новые вызовы.
1. Масштаб.
Модели обучаются на терабайтах данных, и классические методы вроде cross-validation уже не работают, потому что это слишком дорого и сложно.
2. Черный ящик.
Почему GPT-4 или 5 дает именно такой ответ или как Stable Diffusion выбирает детали изображения, нам понять практически невозможно. Поэтому оценка современных генеративный AI решений фокусируется на оценке результата.
3. Ответственность.
AI всё чаще работает в критичных сферах: медицина, финансы, автономное вождение. Ошибка в диагнозе - это уже вопрос жизни.
Еще 5 лет назад все было проще. Для классификация, перевод, распознавание речи были стандартные метрики, например, accuracy, BLEU, WER. Сегодня этого стало недостаточно.
Что изменилось:
- Появились LLM и генеративный AI, в которых нужно оценить креативность картинки или полезность ответа.
- Модели стали мультизадачными: пишут код, пишут тексты, создают картинки и видео. Одной метрики для их оценки теперь мало.
- На первый план вышли новые типы проблем, которых раньше не было, а именно предвзятость, справедливость, галлюцинации, безопасность и согласованность.
Именно поэтому сегодня evaluation - это уже не просто подбор метрик, а отдельная дисциплина, которая определяет, насколько безопасно и надежно мы можем доверять современным AI-системам.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥4
AI Harness в тестировании
В индустрии сейчас все больше набирает популярность новый модный термин - agent harness. Это весь софт вокруг LLM, который превращает “модель, отвечающую на промпт” в агента, который реально делает работу. Инструменты, управление контекстом, цикл “действие → результат → следующий шаг”, память, обработка ошибок, все это является harness.
Почему это важно?
Сегодня в том же SWE-bench одна и та же базовая модель с разной обвязкой (harness) дает solve rate от 5% до 30%+, поэтому получается, что качество ИИ-помощника в тестировании определяет не выбор GPT vs Claude, а то, что вы дали агенту вокруг:
- доступ к нужным инструментам (запустить тест, прочитать код, дёрнуть API, открыть приложение)
- правильный контекст в окне (требования, спека, структура проекта, а не всё подряд)
- цикл обратной связи (прогнал тест → увидел падение → починил → перепрогнал)
- стоп-условия и обработку ошибок, чтобы агент не уходил в бесконечный цикл
предопределенные вокрфлоу (каждая активность заранее частично предопределена)
И сегодня хороший AI-assisted testing - это не нашли модель поумнее. Это инженерия харнеса, когда даешь агенту нужные руки, нужный контекст, правильно и оптимально выстроенные вокрфлоу и нормальную петлю обратной связи, и тогда он начинает реально помогать, а не выдавать правдоподобный мусор, причем даже с не супер мощными моделями.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
В индустрии сейчас все больше набирает популярность новый модный термин - agent harness. Это весь софт вокруг LLM, который превращает “модель, отвечающую на промпт” в агента, который реально делает работу. Инструменты, управление контекстом, цикл “действие → результат → следующий шаг”, память, обработка ошибок, все это является harness.
Почему это важно?
Сегодня в том же SWE-bench одна и та же базовая модель с разной обвязкой (harness) дает solve rate от 5% до 30%+, поэтому получается, что качество ИИ-помощника в тестировании определяет не выбор GPT vs Claude, а то, что вы дали агенту вокруг:
- доступ к нужным инструментам (запустить тест, прочитать код, дёрнуть API, открыть приложение)
- правильный контекст в окне (требования, спека, структура проекта, а не всё подряд)
- цикл обратной связи (прогнал тест → увидел падение → починил → перепрогнал)
- стоп-условия и обработку ошибок, чтобы агент не уходил в бесконечный цикл
предопределенные вокрфлоу (каждая активность заранее частично предопределена)
И сегодня хороший AI-assisted testing - это не нашли модель поумнее. Это инженерия харнеса, когда даешь агенту нужные руки, нужный контекст, правильно и оптимально выстроенные вокрфлоу и нормальную петлю обратной связи, и тогда он начинает реально помогать, а не выдавать правдоподобный мусор, причем даже с не супер мощными моделями.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍4🔥4❤1💯1
s43067-026-00374-6.pdf
2.2 MB
Всем привет!
Сегодня хочу поделиться своим новым исследованием, которое прошло рецензирование и было опубликовано в Journal of Electrical Systems and Information Technology.
Ссылка на публикацию
В статье проводится анализ существующих подходов к оценке качества систем, построенных на основе генеративного искусственного интеллекта. Рассматриваются лексические методы (TF-IDF и BM25), семантические эмбеддинги, гибридные подходы на основе концепции LLM-as-a-Judge, а также методы, основанные на распознавании логического следования в естественном языке (Natural Language Inference, NLI).
Особое внимание уделено разработке алгоритма выбора оптимальной стратегии оценки для различных задач с учетом таких факторов, как скорость оценки, точность и интерпретируемость результатов, а также стабильность и воспроизводимость оценки.
В работе также представлены результаты сравнительного анализа различных методов оценки на примере проверки точности и релевантности ответов ИИ-системы на наборе из 500 тестовых примеров. В зависимости от выбранного подхода корреляция с экспертными оценками реального человека составила от 0,67 до 0,92.
Предложенный алгоритм может использоваться для построения эффективного процесса оценки ИИ-систем в самых разных предметных областях.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Сегодня хочу поделиться своим новым исследованием, которое прошло рецензирование и было опубликовано в Journal of Electrical Systems and Information Technology.
Ссылка на публикацию
В статье проводится анализ существующих подходов к оценке качества систем, построенных на основе генеративного искусственного интеллекта. Рассматриваются лексические методы (TF-IDF и BM25), семантические эмбеддинги, гибридные подходы на основе концепции LLM-as-a-Judge, а также методы, основанные на распознавании логического следования в естественном языке (Natural Language Inference, NLI).
Особое внимание уделено разработке алгоритма выбора оптимальной стратегии оценки для различных задач с учетом таких факторов, как скорость оценки, точность и интерпретируемость результатов, а также стабильность и воспроизводимость оценки.
В работе также представлены результаты сравнительного анализа различных методов оценки на примере проверки точности и релевантности ответов ИИ-системы на наборе из 500 тестовых примеров. В зависимости от выбранного подхода корреляция с экспертными оценками реального человека составила от 0,67 до 0,92.
Предложенный алгоритм может использоваться для построения эффективного процесса оценки ИИ-систем в самых разных предметных областях.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥6👍4
Для всех, кто использует ИИ, но всегда задавался вопросом, а как же собственно LLM работают, я хочу поделиться подборкой видео от 3blue1brown.
3Blue1Brown объясняют сложные концепции через визуализации, которые делают абстрактные идеи понятными. В нескольких видео они разбирают принципы и архитектуру работы LLM, показывая, как LLM работает под капотом.
Что вы узнаете из видео:
Tokenization - как текст превращается в числа, которые может обрабатывать модель.
Attention mechanism - сердце современных LLM. Визуально показано, как модель "обращает внимание" на разные части контекста при предсказании следующего слова.
Embeddings в действии, а именно как слова превращаются в векторы и почему похожие слова оказываются рядом в многомерном пространстве.
Training process - как модель учится предсказывать следующий токен и почему это приводит к "пониманию" языка.
После просмотра вы лучше поймете, почему LLM иногда "галлюцинируют", как влияет размер контекста на качество ответов, и почему промпт-инжиниринг вообще работает.
Есть русский перевод
Ссылки на видео:
Large Language Models explained briefly
Transformers, the tech behind LLMs
Attention in transformers, step-by-step
How might LLMs store facts
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
3Blue1Brown объясняют сложные концепции через визуализации, которые делают абстрактные идеи понятными. В нескольких видео они разбирают принципы и архитектуру работы LLM, показывая, как LLM работает под капотом.
Что вы узнаете из видео:
Tokenization - как текст превращается в числа, которые может обрабатывать модель.
Attention mechanism - сердце современных LLM. Визуально показано, как модель "обращает внимание" на разные части контекста при предсказании следующего слова.
Embeddings в действии, а именно как слова превращаются в векторы и почему похожие слова оказываются рядом в многомерном пространстве.
Training process - как модель учится предсказывать следующий токен и почему это приводит к "пониманию" языка.
После просмотра вы лучше поймете, почему LLM иногда "галлюцинируют", как влияет размер контекста на качество ответов, и почему промпт-инжиниринг вообще работает.
Есть русский перевод
Ссылки на видео:
Large Language Models explained briefly
Transformers, the tech behind LLMs
Attention in transformers, step-by-step
How might LLMs store facts
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
❤4🔥2👍1
Сегодня разберем частые ошибки, которые могут встречаться в в работе AI агентов. Если тестируете AI агентов, то этот список поможет сфокусироваться на ключевых проблемах.
1. Зацикливание (Infinite Loops). Агент повторяет одни и те же действия бесконечно, например, агент пытается получить информацию, но получает ошибку или считает, что информации недостаточно для продолжения работы и повторяет запрос снова и снова.
2. Неправильная декомпозиция задач. Агент разбивает сложную задачу на неправильные подзадачи или слишком мелко дробит простые задачи. Например, для "забронировать отель" создает 15 подзадач вместо 3-4 логичных шагов. Тестируйте планирование выполнения AI агентами на задачах разной сложности.
3. Потеря контекста между действиями. AI Агент "забывает" результаты предыдущих шагов и принимает решения без учета контекста. Особенно критично в задачах с длинной логикой. Проверяйте сохранение состояний между шагами.
4. Неэффективное использование инструментов. Агент вызывает MCP или сервис с неправильными параметрами, использует медленные инструменты вместо быстрых, или вызывает один инструмент несколько раз подряд. Мониторьте вызовы и ищите паттерны неэффективности.
5. Плохая обработка ошибок. При получении ошибки AI агент либо останавливается, либо игнорирует ошибку и продолжает с некорректными данными. Тестируйте поведение при различных типах ошибок, как вариант, использовать мокирование сервисов.
6. Неточная интерпретация результатов. Агент неправильно понимает ответы от инструментов. Например, MCP возвращает "no results found", а агент интерпретирует это как успешный результат. Проверяйте обработку граничных ответов.
7. Избыточная детализация планов. AI агент создает слишком подробные планы для простых задач, тратя время на планирование вместо выполнения. Оценивайте соотношение времени планирования к выполнению.
8. Неправильные приоритеты. Агент фокусируется на неважных деталях, игнорируя ключевые аспекты задачи. Например, при анализе проблемы тратит время на форматирование отчета вместо поиска решения. Проверяйте согласованность агента с целями задачи.
9. Отсутствие валидации финального результата. AI агент не проверяет, действительно ли задача выполнена. Может "завершить" задачу с частичным результатом. Тестируйте завершенность финальных результатов.
10. Галлюцинации в промежуточных шагах. AI агент "придумывает" результаты действий, которые не были выполнены, или неправильно интерпретирует внешние данные. Сравнивайте заявленные результаты с фактическими данными.
Практические советы для тестирования:
- Анализируйте все действия агента для анализа паттернов ошибок
- Создавайте тест кейсы для каждого типа ошибок
- Тестируйте крайние случаи и сценарии отказов
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
1. Зацикливание (Infinite Loops). Агент повторяет одни и те же действия бесконечно, например, агент пытается получить информацию, но получает ошибку или считает, что информации недостаточно для продолжения работы и повторяет запрос снова и снова.
2. Неправильная декомпозиция задач. Агент разбивает сложную задачу на неправильные подзадачи или слишком мелко дробит простые задачи. Например, для "забронировать отель" создает 15 подзадач вместо 3-4 логичных шагов. Тестируйте планирование выполнения AI агентами на задачах разной сложности.
3. Потеря контекста между действиями. AI Агент "забывает" результаты предыдущих шагов и принимает решения без учета контекста. Особенно критично в задачах с длинной логикой. Проверяйте сохранение состояний между шагами.
4. Неэффективное использование инструментов. Агент вызывает MCP или сервис с неправильными параметрами, использует медленные инструменты вместо быстрых, или вызывает один инструмент несколько раз подряд. Мониторьте вызовы и ищите паттерны неэффективности.
5. Плохая обработка ошибок. При получении ошибки AI агент либо останавливается, либо игнорирует ошибку и продолжает с некорректными данными. Тестируйте поведение при различных типах ошибок, как вариант, использовать мокирование сервисов.
6. Неточная интерпретация результатов. Агент неправильно понимает ответы от инструментов. Например, MCP возвращает "no results found", а агент интерпретирует это как успешный результат. Проверяйте обработку граничных ответов.
7. Избыточная детализация планов. AI агент создает слишком подробные планы для простых задач, тратя время на планирование вместо выполнения. Оценивайте соотношение времени планирования к выполнению.
8. Неправильные приоритеты. Агент фокусируется на неважных деталях, игнорируя ключевые аспекты задачи. Например, при анализе проблемы тратит время на форматирование отчета вместо поиска решения. Проверяйте согласованность агента с целями задачи.
9. Отсутствие валидации финального результата. AI агент не проверяет, действительно ли задача выполнена. Может "завершить" задачу с частичным результатом. Тестируйте завершенность финальных результатов.
10. Галлюцинации в промежуточных шагах. AI агент "придумывает" результаты действий, которые не были выполнены, или неправильно интерпретирует внешние данные. Сравнивайте заявленные результаты с фактическими данными.
Практические советы для тестирования:
- Анализируйте все действия агента для анализа паттернов ошибок
- Создавайте тест кейсы для каждого типа ошибок
- Тестируйте крайние случаи и сценарии отказов
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍3💯3❤2🔥1
Недавно подумал насколько мы привыкли использовать ИИ в своей работе, особенно кодинг агентов, типа Cursor или Claude Code, что начали постепенно забывать по аспекту связанные с качеством и что немаловажно эффективность работы такого агента.
И я пришел к этому выводу не случайно. Буквально недавно я создал мультиагента ИИ агента на базе claude code sdk, который решает различные задачи связанные с тестирование, такие статическое тестирование, создание ручных тестов, выполнение ручных проверок, создание и дебаг автотестов и многое другое, и я попробовал его на ряде проектов и в целом результаты положительные, агент генерирует неплохие результаты, и вроде бы все хорошо, но…
Я себя как раз и поймал на мысли, что по факту я занимаюсь вайб чеккингом, базовой проверкой happy path сценариев, которые мне интересны.
И мне кажется 90% делают примерно также, когда вацбкодят свои продукты.
И я решил посмотреть, а что же все такие происходит внутри. В общем взял я и подключил Langfuse чтобы полностью в трейсе отследить работу агента на конкретными задачами, и знаете что я нашел??
Ошибки при выполнении различных тулов, неэффективные вызовы, которые по факту не нужны, тонна ненужно информации, которую по факту агент никак не использует.
И это еще не все. Когда встал вопрос оптимизации, то появился и вопрос, как нормально то эту оптимизацию проверить? Ведь я до этого вайбкодил, проверял через exploratory testing только нужные мне сценарии и по факту ничего не документировал. А такого глобальное изменение конечно надо проверять, делать сравнение с пошлой версией, анализировать качество и так далее
В общем к чему я все это. Вы можете навайбкодить ИИ агента, неважно, для бизнеса или для себя, но без должного тестирования, с тестами, анализом логов, голден датасетом, вы будете как в темном лесу пытаться понять, в правильную сторону вы ли идете.
Вывод: не пренебрегайте глубоким и полноценным тестированием ИИ систем, даже если вам кажется, что все работает отлично.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
И я пришел к этому выводу не случайно. Буквально недавно я создал мультиагента ИИ агента на базе claude code sdk, который решает различные задачи связанные с тестирование, такие статическое тестирование, создание ручных тестов, выполнение ручных проверок, создание и дебаг автотестов и многое другое, и я попробовал его на ряде проектов и в целом результаты положительные, агент генерирует неплохие результаты, и вроде бы все хорошо, но…
Я себя как раз и поймал на мысли, что по факту я занимаюсь вайб чеккингом, базовой проверкой happy path сценариев, которые мне интересны.
И мне кажется 90% делают примерно также, когда вацбкодят свои продукты.
И я решил посмотреть, а что же все такие происходит внутри. В общем взял я и подключил Langfuse чтобы полностью в трейсе отследить работу агента на конкретными задачами, и знаете что я нашел??
Ошибки при выполнении различных тулов, неэффективные вызовы, которые по факту не нужны, тонна ненужно информации, которую по факту агент никак не использует.
И это еще не все. Когда встал вопрос оптимизации, то появился и вопрос, как нормально то эту оптимизацию проверить? Ведь я до этого вайбкодил, проверял через exploratory testing только нужные мне сценарии и по факту ничего не документировал. А такого глобальное изменение конечно надо проверять, делать сравнение с пошлой версией, анализировать качество и так далее
В общем к чему я все это. Вы можете навайбкодить ИИ агента, неважно, для бизнеса или для себя, но без должного тестирования, с тестами, анализом логов, голден датасетом, вы будете как в темном лесу пытаться понять, в правильную сторону вы ли идете.
Вывод: не пренебрегайте глубоким и полноценным тестированием ИИ систем, даже если вам кажется, что все работает отлично.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
💯6❤5
Кажется то, что происходит с бенчмарками агентов последние пару месяцев, реально стоит обсудить.
В апреле 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)
В апреле 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)
👍3🤔3🔥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)
Ииии…. мы начинаем 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)
🔥5❤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)
Результат получился интересным, потому что судья меняет вердикт в среднем в 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🤔2
Сегодня поговорим о Robustness testing через призму метаморфического тестирования.
Немного разберем, что такое метаморфическое тестирование. Это метод тестирования программного обеспечения, при котором проверка корректности основана не на самих результатах, а на метаморфических отношениях - ожидаемых зависимостях между входами и выходами программы.
Проще говоря:
Мы задаём системе вход X и получаем результат Y.
Затем трансформируем вход (например, перефразируем запрос, добавляем шум, изменяем порядок элементов) и получаем новый результат Y1.
Вместо того чтобы знать точное значение Y1, мы проверяем, что оно связано с Y через заранее определённое правило (метаморфизм).
Теперь вернемся к проверке устойчивости AI к перефразировкам и шуму.
Смысл простой:
Если модель правильно отвечает на вопрос «Какая столица у Франции?», то и на все перефразировки («Франция столица какого города?», «Столичный город Франции?») она должна давать тот же корректный ответ — «Париж».
Это и есть метаморфизм: изменяя входные данные (перефраз, шум, опечатка), мы ожидаем, что результат должен остаться инвариантным или близко похожим к оригинальному (наш Y1).
Как формировать датасеты для такого тестирования:
⁃ Берем базовый набор запросов с известным правильным ответом.
⁃ Автоматически генерируем перефразировки (через LLM, шаблоны или вручную).
⁃ Добавляем «шумные» варианты: опечатки, случайные символы, жаргон.
Что это дает?
Мы строим не просто тестовый набор, а семейства запросов, которые проверяют:
1. Сохраняет ли модель правильность при изменении формы вопроса?
2. Насколько она устойчива к «грязным» данным?
3. Есть ли случаи, где она внезапно «ломается» и начинает галлюцинировать?
По сути, Robustness testing - это частный случай метаморфического тестирования. Мы заранее знаем правильный ответ и проверяем, что он не изменяется серьезно при трансформации запроса.
⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Немного разберем, что такое метаморфическое тестирование. Это метод тестирования программного обеспечения, при котором проверка корректности основана не на самих результатах, а на метаморфических отношениях - ожидаемых зависимостях между входами и выходами программы.
Проще говоря:
Мы задаём системе вход X и получаем результат Y.
Затем трансформируем вход (например, перефразируем запрос, добавляем шум, изменяем порядок элементов) и получаем новый результат Y1.
Вместо того чтобы знать точное значение Y1, мы проверяем, что оно связано с Y через заранее определённое правило (метаморфизм).
Теперь вернемся к проверке устойчивости AI к перефразировкам и шуму.
Смысл простой:
Если модель правильно отвечает на вопрос «Какая столица у Франции?», то и на все перефразировки («Франция столица какого города?», «Столичный город Франции?») она должна давать тот же корректный ответ — «Париж».
Это и есть метаморфизм: изменяя входные данные (перефраз, шум, опечатка), мы ожидаем, что результат должен остаться инвариантным или близко похожим к оригинальному (наш Y1).
Как формировать датасеты для такого тестирования:
⁃ Берем базовый набор запросов с известным правильным ответом.
⁃ Автоматически генерируем перефразировки (через LLM, шаблоны или вручную).
⁃ Добавляем «шумные» варианты: опечатки, случайные символы, жаргон.
Что это дает?
Мы строим не просто тестовый набор, а семейства запросов, которые проверяют:
1. Сохраняет ли модель правильность при изменении формы вопроса?
2. Насколько она устойчива к «грязным» данным?
3. Есть ли случаи, где она внезапно «ломается» и начинает галлюцинировать?
По сути, Robustness testing - это частный случай метаморфического тестирования. Мы заранее знаем правильный ответ и проверяем, что он не изменяется серьезно при трансформации запроса.
⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍2❤1🔥1