Для всех, кто использует ИИ, но всегда задавался вопросом, а как же собственно 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)
🔥6❤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🤔3
Сегодня поговорим о 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)
👍3❤1🔥1
Пока весь фокус на 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)
Они прогнали ИИ агентов через примерно 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)
👍5
Хочу поделиться апдейтом, который я недавно добавил в свою библиотеку 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)
Когда команды берут готовые инструменты оценки, такие как 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)
🔥9❤1
Всем привет, я напоминаю, что 9 сентября начинается новый поток на моем курсе по оценке и тестированию ИИ систем
И если вы все еще хотите записаться и получить скидку 10%, то осталось всего 7 дней!
🔗 Оставить заявку можно тут: https://eval-ai.com
На текущий момент это едистенный рускоязычный курс по тестированию ИИ, где мы изучаем
📌 Как тестировать ML/DL, LLM, RAG, AI-агентов
📌 Как строить процесс оценки ИИ
📌 Как работать с DeepEval, Promptfoo, Ragas, LangFuse и др.
📌 Какмо создавать тестовые данные для тестирования
📌 Как искать уязвимости в ИИ системах
В общей сложности 40+ часов практики на реальных ИИ-системах
Присоединяйтесь и откройте для себя новые скиллы и знания!
И если вы все еще хотите записаться и получить скидку 10%, то осталось всего 7 дней!
🔗 Оставить заявку можно тут: https://eval-ai.com
На текущий момент это едистенный рускоязычный курс по тестированию ИИ, где мы изучаем
📌 Как тестировать ML/DL, LLM, RAG, AI-агентов
📌 Как строить процесс оценки ИИ
📌 Как работать с DeepEval, Promptfoo, Ragas, LangFuse и др.
📌 Какмо создавать тестовые данные для тестирования
📌 Как искать уязвимости в ИИ системах
В общей сложности 40+ часов практики на реальных ИИ-системах
Присоединяйтесь и откройте для себя новые скиллы и знания!
AI Evaluation Course
Курс по оценке и тестированию ИИ систем (RAG, LLM, AI-агенты)
Практический онлайн-курс по тестированию AI-систем: LLM, RAG, AI-агенты, мультимодальные модели.
👍2❤1
Нашел вот такой полезный ресурс, в котором рассматриваются различные подходы к созданию harness вокруг ваших ИИ агентов.
Также дополнительно есть раздел метрик, которые могут быть использованы для оценки harness для агентов.
Источник: https://github.com/justxor/Harness_ru
⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Также дополнительно есть раздел метрик, которые могут быть использованы для оценки harness для агентов.
Источник: https://github.com/justxor/Harness_ru
⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥5❤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)
Но речь не о самом Джеффе, а о мемах, которые сделали вокруг него в компании. Эти шутки возникли среди разработчиков Google из-за реального огромного вклада Дина в поисковые алгоритмы и искусственный интеллект и фактически являются аналогом мемов про Чак Норриса, но в ИТ. Для Джеффа в том числе в Google придумали 11 грейд, хотя их все 10:)
В общем, если вам хочется поднять себе немного настроения, ссылка на полную библиотеку тут:
https://github.com/LRitzdorf/TheJeffDeanFacts
Вот парочка оттуда:
• Джеффу Дину пришлось изобрести асинхронные API, когда после его оптимизации функция вернула значение прежде, чем её вызвали
• Компиляторы не предупреждают Джеффи Дина. Джефф Дин предупреждает компиляторы
• На клавиатуре Джеффа Дина две клавиши: 1 и 0
• Джефф Дин однажды поднял веб-сервер одним вызовом printf(). Другие инженеры добавили тысячи строк комментариев с пояснениями, но так и не поняли, как он работает. Сегодня программа работает в качестве фронтэнда Google Search
• Джеффу Дину приходится деоптимизировать свой код, чтобы ревьюеры могли понять, что там написано
⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
GitHub
GitHub - LRitzdorf/TheJeffDeanFacts: A consolidated list of the Jeff Dean Facts!
A consolidated list of the Jeff Dean Facts! Contribute to LRitzdorf/TheJeffDeanFacts development by creating an account on GitHub.
😁6👍2🔥1
Список факапов, которые регулярно вижу у многих команд.
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)
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)
👍5
Вчера записывал новое видео по promptfoo в рамках моего курса по оценке и тестированию ИИ систем, и в который раз убеждаюсь, насколько неинтуитивный и сложный в настройке этот инструмент именно для оценки качества ИИ систем (я тут не говорю про redteaming и безопасность).
Я попробовал их UI интерфейс для настройки подключения к моему ИИ прилдожение, потратил минут 30 пытаясь что-то настроить, потом оказалось, что могу через UI только настроить парсинг ответа от ИИ, а вот метаданные уже нет.
В итоге опять пришло спрашивать OpenAI как настроить YAML promptfoo для работы с моим AI агентом и в итоге потратил почти 2 часа просто на неинтуитивную настройку и конфигурацию этого YAML файла. По факту без LLM чисто по документации я бы потратил наверное еще больше времени на это.
В общем не знаю, почему все так хвалял и продвигают этот тул, скудный набор метрик, сложный парсинг нужных данных для оценки, неинтуитивная настройка метрик, визуализация результатов тоже оставляет желать лучшего.
Пробовали, что думаете, согласны или нет?
⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Я попробовал их UI интерфейс для настройки подключения к моему ИИ прилдожение, потратил минут 30 пытаясь что-то настроить, потом оказалось, что могу через UI только настроить парсинг ответа от ИИ, а вот метаданные уже нет.
В итоге опять пришло спрашивать OpenAI как настроить YAML promptfoo для работы с моим AI агентом и в итоге потратил почти 2 часа просто на неинтуитивную настройку и конфигурацию этого YAML файла. По факту без LLM чисто по документации я бы потратил наверное еще больше времени на это.
В общем не знаю, почему все так хвалял и продвигают этот тул, скудный набор метрик, сложный парсинг нужных данных для оценки, неинтуитивная настройка метрик, визуализация результатов тоже оставляет желать лучшего.
Пробовали, что думаете, согласны или нет?
⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍2💯1
Когда агент работает через 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)
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)
🔥2❤1👍1
Всем привет, я напоминаю, что 9 сентября начинается новый поток на моем курсе по оценке и тестированию ИИ систем
Осталось совсем немного времени, чтобы оставить заявку и попасть в новый поток!
🔗 Оставить заявку можно тут: https://eval-ai.com
На текущий момент это едистенный рускоязычный курс по тестированию ИИ, где мы изучаем
📌 Как тестировать ML/DL, LLM, RAG, AI-агентов
📌 Как строить процесс оценки ИИ
📌 Как работать с DeepEval, EvalLib, Promptfoo, Ragas, LangFuse и др.
📌 Как создавать тестовые данные для тестирования
📌 Как искать уязвимости в ИИ системах
В общей сложности 40+ часов практики на реальных ИИ-системах
Присоединяйтесь и откройте для себя новые скиллы и знания!
Осталось совсем немного времени, чтобы оставить заявку и попасть в новый поток!
🔗 Оставить заявку можно тут: https://eval-ai.com
На текущий момент это едистенный рускоязычный курс по тестированию ИИ, где мы изучаем
📌 Как тестировать ML/DL, LLM, RAG, AI-агентов
📌 Как строить процесс оценки ИИ
📌 Как работать с DeepEval, EvalLib, Promptfoo, Ragas, LangFuse и др.
📌 Как создавать тестовые данные для тестирования
📌 Как искать уязвимости в ИИ системах
В общей сложности 40+ часов практики на реальных ИИ-системах
Присоединяйтесь и откройте для себя новые скиллы и знания!
AI Evaluation Course
Курс по оценке и тестированию ИИ систем (RAG, LLM, AI-агенты)
Практический онлайн-курс по тестированию AI-систем: LLM, RAG, AI-агенты, мультимодальные модели.
🔥2
Обычно, чтобы оценить работу ИИ агента, нам нужны тест-кейсы, или по другому датасет оценки. Писать большой датасет вручную часто достаточно медленно и скучно, поэтому можно рассмотреть возможность использования синтетического датасета, но при условии, если построен правильно.
На чем стоит фокусироваться?
Начинайте с seed-примеров из реального использования. Возьмите 10–15 диалогов из продакшена или из ручного тестирования. Не придумывайте с нуля, потому что LLM будет генерировать вариации вокруг реальных кейсов, а не выдумывать их из воздуха.
Разворачивайте вариации по трем осям. Одного и того же пользователя с одним запросом недостаточно. Варьируйте: формулировку (как человек спрашивает), намерение (что он на самом деле хочет), поведение (терпеливый, агрессивный, меняет тему на полуслове). Из одного seed-кейса так получают 20–30 дополнительных тестов.
Включайте сложные кейсы намеренно. Датасет только из happy path запросов не покрывает ничего интересного. Генерируйте сценарии где пользователь противоречит себе, запрашивает невозможное, пишет с опечатками и обрывками. Именно на этом агенты ломаются чаще всего.
Проверяйте качество датасета перед использованием. Синтетика часто дает слишком правильные диалоги, который содержат идеальные фразы, чёекие запросы. Прогоните 10% через быструю проверку: если все выглядит как учебник, датасет нереалистичен и стоит вернуться к первым 3-м пунктам выше.
Версионируйте датасет как код. Изменился агент или промпт, значит вам нужна новая версия датасета, иначе непонятно, стало лучше или хуже на каком наборе.
Датасет - это фактически 90% качественного тестирования ИИ системы, поэтому всегда нужно тщательно и правильно подходить к его подготовке.
⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 9 сентября! 🔥
Полезная информация:
Курс по 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)
🔥4👍1💯1
Сегодня поговорим про ситуацию, с которой сталкивается почти каждый, кто начинает оценивать ИИ системы, а именно отсутствие эталонного ответа. ИИ ассистент отвечает на открытый вопрос, генерирует объяснение или саммари, и один и тот же запрос можно закрыть разными вариантами ответов. В данной ситуации получается, что сравнивать с 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)
В таком случае фокус смещается с вопроса совпал ли ответ с эталоном на вопрос соответствует ли ответ запросу, контексту и требованиям к системе. И под это есть свой набор 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)
👍6❤2💯2🔥1
Недавно наткнулся на разбор того, как одна команда переводила ИИ агента с 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)
Первый прогон голден датасета на новой модели дал кучу фейлов, и можно подумать, что новая модель просто хуже, но когда они пошли по трейсам и разобрали каждое падение, то оказалось, что примерно треть провалов - это не модель, а ограничения старого 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)
👍4🔥2🤔1
Сегодня хочу поговорить про оценку голосовых 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)
1. Каскад ошибок. ASR расслышал «пятнадцать» как «пятьдесят», а LLM дальше уверенно решает не ту задачу. По транскрипту все выглядит хорошо, метрики зеленые, а пользователь получил не то, что ожидал., поэтому оценивать нужно всю цепочку от аудио до результата, а не только текстовый запрос/ответ.
2. Длительность и задержки. Пауза в 2 секунды в чате почти не замечается, а в голосе воспринимается как то, что агент завис. Тут нужны перцентили по каждому этапу работы агента, STT, LLM, TTS, а не средняя по всему разговору.
3. Turn-taking. Так может случиться, что ИИ агент может начать перебивать пользователя, игнорирует его фразы или решает, что человек договорил, когда тот просто взял паузу подумать. Это отдельный класс сценариев, которые нужно учитывать при оценке голосовых ботов.
4. Реальные условия. Шум на фоне, акценты, быстрая речь, слова-паразиты, самоисправления типа «в среду, нет, в четверг». На чистых студийных записях агент отлично работает, а в проде ломается на первом же звонке из необычных окружающих условий.
5. Ответы, непригодные для речи. Слишком длинные ответы, списки и markdown, которые зачитываются вслух, неправильно произнесенные числа, даты и имена. Текстом это выглядит нормально, а на слух это звучит ужасно, поэтому надо проверять как отрабатывает TTS.
Финально могу сказать, что тест-сет для голосового агента это не просто набор вопросов и ответов, а набор аудио с шумом, акцентами, перебиваниями и обрывками, и оценивать в нем нужно каждый слой pipeline отдельно, потому что итоговый ответ может быть правильным даже при сломанном ASR.
А вы сталкивались с тестированием голосовых агентов? Что оказалось самым сложным? 👇
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍5🔥1