Сегодня хочу рассказать про два интересных инструмента, которые я недавно увидел на рынке и которые закрывают нишу, про которую раньше почти никто не говорил, а именно тестирование голосовых AI агентов.
Cekura - платформа для автоматизированного тестирования и мониторинга голосовых и чат AI агентов. Она позволяет запускать симуляции разговоров с разными пользовательскими персонажами, тестировать как агент реагирует на прерывания, нестандартные сценарии и off-script поведение пользователей. Из интересного - это 25+ встроенных метрик специфичных именно для голоса, такие как gibberish detection, interruption tracking, latency, pitch, sentiment. Плюс поддержка 32 языков с учётом региональных акцентов, что важно если агент работает на глобальную аудиторию.
LambdaTest Agent-to-Agent Testing - это платформа для тестирования AI агентов. Идея в том, что один AI агент тестирует другой, генерируя разнообразные сценарии автоматически. Работает как для текстовых чат-ботов, так и для голосовых агентов. Вы загружаете требования в любом формате, например, текст, изображения, аудио, видео, и система генерирует тест-сценарии с метриками по bias, hallucinations, completeness, toxicity. Под капотом используется несколько LLM одновременно для более полного покрытия.
Для меня оба инструмента интересны тем, что они решают задачу, которую традиционные фреймворки оценки практически игнорируют - голосовой канал и multi-turn диалоги в реальных условиях. Потому что оценить текстовый вывод LLM через RAGAS это одно, а проверить как голосовой агент ведет себя когда пользователь перебивает, говорит с акцентом или уходит от скрипта, это совсем другая задача.
А вы сталкивались с задачей тестирования голосовых AI агентов? Как решали? 👇
⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 7 мая! 🔥
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Cekura - платформа для автоматизированного тестирования и мониторинга голосовых и чат AI агентов. Она позволяет запускать симуляции разговоров с разными пользовательскими персонажами, тестировать как агент реагирует на прерывания, нестандартные сценарии и off-script поведение пользователей. Из интересного - это 25+ встроенных метрик специфичных именно для голоса, такие как gibberish detection, interruption tracking, latency, pitch, sentiment. Плюс поддержка 32 языков с учётом региональных акцентов, что важно если агент работает на глобальную аудиторию.
LambdaTest Agent-to-Agent Testing - это платформа для тестирования AI агентов. Идея в том, что один AI агент тестирует другой, генерируя разнообразные сценарии автоматически. Работает как для текстовых чат-ботов, так и для голосовых агентов. Вы загружаете требования в любом формате, например, текст, изображения, аудио, видео, и система генерирует тест-сценарии с метриками по bias, hallucinations, completeness, toxicity. Под капотом используется несколько LLM одновременно для более полного покрытия.
Для меня оба инструмента интересны тем, что они решают задачу, которую традиционные фреймворки оценки практически игнорируют - голосовой канал и multi-turn диалоги в реальных условиях. Потому что оценить текстовый вывод LLM через RAGAS это одно, а проверить как голосовой агент ведет себя когда пользователь перебивает, говорит с акцентом или уходит от скрипта, это совсем другая задача.
А вы сталкивались с задачей тестирования голосовых AI агентов? Как решали? 👇
⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 7 мая! 🔥
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍5🔥1
Всем привет!
У меня хорошие новости, потому что недавно Anthropic запустил бесплатные курсы, в том числе и технические по работе с Claude Code, mcp и агентской архитектурой.
Я советую изучать сразу как работать Claude Code, например, Claude Code in Action, Claude Code 101, Introduction to Model Context Protocol, Introduction to agent skills.
Сегодня понимание как работают ИИ агенты очень полезно, даже тестировщикам, чтобы как минимум вайбкодить своих агентов для тестирования.
ссылка на обучения
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
У меня хорошие новости, потому что недавно Anthropic запустил бесплатные курсы, в том числе и технические по работе с Claude Code, mcp и агентской архитектурой.
Я советую изучать сразу как работать Claude Code, например, Claude Code in Action, Claude Code 101, Introduction to Model Context Protocol, Introduction to agent skills.
Сегодня понимание как работают ИИ агенты очень полезно, даже тестировщикам, чтобы как минимум вайбкодить своих агентов для тестирования.
ссылка на обучения
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥10❤2👍1
Недавно наткнулся на несколько исследований про over-reliance (чрезмерную зависимость) на AI, и хочу поделиться своим взглядом на эту тему, потому что она в последнее время активно обсуждается, но часто с неправильным углом.
Типичная позиция звучит так, что люди слишком доверяют AI, перестают думать сами, деградируют как специалисты. В этом есть доля правды, но я думаю, что сама постановка вопроса немного неверная.
Over-reliance - это не проблема использования AI, это проблема отсутствия понимания того, как AI принимает решения и где он ошибается.
Приведу пример из тестирования. Если тестировщик принимает все тест-кейсы, которые сгенерировал AI агент, без проверки - это over-reliance, но не потому что он использует AI, а потому что он не понимает, что агент оптимизирует под паттерны и систематически пропускает edge cases, которые в этих данных не встречались. Как только ты это понимаешь, ты начинаешь проверять именно эти места, и AI из источника риска превращается в инструмент, который реально ускоряет работу.
Поэтому мой взгляд такой, что да, over-reliance - это реальная проблема, но решается она не ограничением использования AI, а повышением экспертизы у тех, кто с ним работает. Нужно понимать не только как использовать инструмент, но и где он врет, где галлюцинирует, где уверенно ошибается.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Типичная позиция звучит так, что люди слишком доверяют AI, перестают думать сами, деградируют как специалисты. В этом есть доля правды, но я думаю, что сама постановка вопроса немного неверная.
Over-reliance - это не проблема использования AI, это проблема отсутствия понимания того, как AI принимает решения и где он ошибается.
Приведу пример из тестирования. Если тестировщик принимает все тест-кейсы, которые сгенерировал AI агент, без проверки - это over-reliance, но не потому что он использует AI, а потому что он не понимает, что агент оптимизирует под паттерны и систематически пропускает edge cases, которые в этих данных не встречались. Как только ты это понимаешь, ты начинаешь проверять именно эти места, и AI из источника риска превращается в инструмент, который реально ускоряет работу.
Поэтому мой взгляд такой, что да, over-reliance - это реальная проблема, но решается она не ограничением использования AI, а повышением экспертизы у тех, кто с ним работает. Нужно понимать не только как использовать инструмент, но и где он врет, где галлюцинирует, где уверенно ошибается.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍6❤1💯1
Сегодня хочу поговорить про регрессионное тестирование AI систем, потому что на практике я вижу, что большинство команд либо не делают его вообще, либо делают так же как для обычного ПО, и оба варианта приводят к проблемам.
В классическом тестировании регрессия работает просто. Есть функция, есть ожидаемый результат, есть тест, который проверяет что после изменений результат не изменился. Всё детерминировано, всё воспроизводимо.
В AI системах этого нет. LLM по своей природе стохастична, и один и тот же запрос при одних и тех же настройках может дать разные ответы. Это означает, что классический подход "запустил тест, сравнил вывод с эталоном" здесь просто так не работает.
Но это только первая сложность. Вторая, на мой взгляд, более серьезная. Даже если вы зафиксировали baseline метрики в момент запуска, что уже само по себе делают единицы, вам нужно решить что именно вы регрессируете, потому что AI система может полностью изменить формат, тон и структуру ответов после обновления промпта или смены модели, при этом формально отвечать правильно по всем метрикам, и только живой пользователь заметит, что что-то стало другим.
Третья сложность - это сами провайдеры моделей, которые обновляют их без уведомления. То есть ваша AI система может начать вести себя иначе в продакшене даже если вы не меняли ничего со своей стороны. Стандартный CI/CD пайплайн это не поймает, потому что он запускается только при изменениях в вашем коде.
Получается, что регрессионное тестирование AI систем требует принципиально другого подхода: не разовую проверку перед релизом, а непрерывный мониторинг поведения модели в продакшене с зафиксированными baseline метриками по каждому типу задач.
Как вы у себя решаете задачу регрессии для AI систем? Или пока это открытый вопрос? 👇
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
В классическом тестировании регрессия работает просто. Есть функция, есть ожидаемый результат, есть тест, который проверяет что после изменений результат не изменился. Всё детерминировано, всё воспроизводимо.
В AI системах этого нет. LLM по своей природе стохастична, и один и тот же запрос при одних и тех же настройках может дать разные ответы. Это означает, что классический подход "запустил тест, сравнил вывод с эталоном" здесь просто так не работает.
Но это только первая сложность. Вторая, на мой взгляд, более серьезная. Даже если вы зафиксировали baseline метрики в момент запуска, что уже само по себе делают единицы, вам нужно решить что именно вы регрессируете, потому что AI система может полностью изменить формат, тон и структуру ответов после обновления промпта или смены модели, при этом формально отвечать правильно по всем метрикам, и только живой пользователь заметит, что что-то стало другим.
Третья сложность - это сами провайдеры моделей, которые обновляют их без уведомления. То есть ваша AI система может начать вести себя иначе в продакшене даже если вы не меняли ничего со своей стороны. Стандартный CI/CD пайплайн это не поймает, потому что он запускается только при изменениях в вашем коде.
Получается, что регрессионное тестирование AI систем требует принципиально другого подхода: не разовую проверку перед релизом, а непрерывный мониторинг поведения модели в продакшене с зафиксированными baseline метриками по каждому типу задач.
Как вы у себя решаете задачу регрессии для AI систем? Или пока это открытый вопрос? 👇
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍7❤2💯2
Галлюцинации в AI системах - это одна из тех тем, про которые все слышали, но мало кто понимает насколько по-разному они проявляются в зависимости от типа системы и насколько сложно их реально обнаружить.
Попробую разобрать это по уровням, потому что детекция галлюцинаций в чистой LLM, в RAG системе и в агентном пайплайнет, это три совершенно разные задачи.
В чистой LLM галлюцинация - это когда модель генерирует информацию, которой нет в реальности, но делает это уверенно и правдоподобно. Детектировать это сложно, потому что нет внешнего источника правды с которым можно сравнить ответ. Самый распространенный подход - это бенчмарки. TruthfulQA проверяет склонность модели воспроизводить распространённые заблуждения, HaluEval оценивает галлюцинации на задачах вопрос-ответ, диалогов и суммаризации, SimpleQA от OpenAI фокусируется на коротких фактических вопросах с однозначным ответом. Суть в том, что у нас есть размеченный датасет с правильными ответами, и мы можем измерить насколько часто модель отклоняется от них. Это воспроизводимо и сравнимо между моделями.
В RAG системе задача детекции теоретически проще, потому что есть контекст, а именно набор документов, которые были переданы модели. Галлюцинация здесь это когда модель генерирует что-то, что не поддерживается этим контекстом. Это можно проверить автоматически через faithfulness/groundness метрики. Но на практике есть нюанс: около 80% сбоев RAG систем происходят не на уровне генерации, а на уровне retrieval, то есть модель получает неправильный контекст и галлюцинирует уже на его основе. И тут faithfulness/groundness метрика покажет зеленый результат, потому что ответ формально соответствует переданному контексту, просто контекст был неправильный.
В агентных системах это становится еще сложнее. Агент может галлюцинировать на уровне выбора инструмента, на уровне аргументов которые он передаёт в tool call, на уровне интерпретации результата инструмента и на уровне финального ответа пользователю. Каждый из этих уровней нужно проверять отдельно, и каскадная ошибка на первом шаге может привести к уверенному неправильному ответу в конце, который очень сложно отследить до источника.
Когда меня спрашивают как тестировать галлюцинации, мой ответ всегда начинается с вопроса, а в какой именно системе и на каком уровне? Потому что универсального подхода здесь нет, и метрики которые работают для одного типа системы могут давать ложное чувство безопасности в другом.
Сталкивались с галлюцинациями в своих AI системах? На каком уровне было сложнее всего их обнаружить? 👇
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Попробую разобрать это по уровням, потому что детекция галлюцинаций в чистой LLM, в RAG системе и в агентном пайплайнет, это три совершенно разные задачи.
В чистой LLM галлюцинация - это когда модель генерирует информацию, которой нет в реальности, но делает это уверенно и правдоподобно. Детектировать это сложно, потому что нет внешнего источника правды с которым можно сравнить ответ. Самый распространенный подход - это бенчмарки. TruthfulQA проверяет склонность модели воспроизводить распространённые заблуждения, HaluEval оценивает галлюцинации на задачах вопрос-ответ, диалогов и суммаризации, SimpleQA от OpenAI фокусируется на коротких фактических вопросах с однозначным ответом. Суть в том, что у нас есть размеченный датасет с правильными ответами, и мы можем измерить насколько часто модель отклоняется от них. Это воспроизводимо и сравнимо между моделями.
В RAG системе задача детекции теоретически проще, потому что есть контекст, а именно набор документов, которые были переданы модели. Галлюцинация здесь это когда модель генерирует что-то, что не поддерживается этим контекстом. Это можно проверить автоматически через faithfulness/groundness метрики. Но на практике есть нюанс: около 80% сбоев RAG систем происходят не на уровне генерации, а на уровне retrieval, то есть модель получает неправильный контекст и галлюцинирует уже на его основе. И тут faithfulness/groundness метрика покажет зеленый результат, потому что ответ формально соответствует переданному контексту, просто контекст был неправильный.
В агентных системах это становится еще сложнее. Агент может галлюцинировать на уровне выбора инструмента, на уровне аргументов которые он передаёт в tool call, на уровне интерпретации результата инструмента и на уровне финального ответа пользователю. Каждый из этих уровней нужно проверять отдельно, и каскадная ошибка на первом шаге может привести к уверенному неправильному ответу в конце, который очень сложно отследить до источника.
Когда меня спрашивают как тестировать галлюцинации, мой ответ всегда начинается с вопроса, а в какой именно системе и на каком уровне? Потому что универсального подхода здесь нет, и метрики которые работают для одного типа системы могут давать ложное чувство безопасности в другом.
Сталкивались с галлюцинациями в своих AI системах? На каком уровне было сложнее всего их обнаружить? 👇
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
💯3👍2🔥2❤1
Сегодня я хотел вам напомнить о моей опенсорсной библиотеки по оценке систем на базе ИИ.
За последнее время библиотека несколько преобразилась, а именно:
• теперь есть поддержка более 50 различных AI провайдеров в качестве оценщика, включая готовую интеграцию для кастомных моделей, ollama self-hosted и MLX моделей
• расширилось количество агентских метрик до 9
• подключить свою ИИ систему можно просто как в Postman, просто указав параметры API запроса
• и много мелких правок дефектов!
Кроме того, мой фремворк запускается локально, и вы можете запускать оценки через нативный UI интерфейс.
Если вы еше не пробовали, как это работает, то полная документация доступна тут по ссылке library.eval-ai.com, установить можно простой командой
pip install eval-ai-library
после чего достаточно ввести к командной строке
eval-ai dashboard
Буду отдельно благодарен за звезды ⭐️ на github https://github.com/meshkovQA/Eval-ai-library, а также поддержку в развитии данного фреймворка!
Кроме того, если вас интересует подход, который я использую для вычисления метрик, то данную информацию вы также можете найти в моей работе на arxiv https://arxiv.org/abs/2604.08595
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
За последнее время библиотека несколько преобразилась, а именно:
• теперь есть поддержка более 50 различных AI провайдеров в качестве оценщика, включая готовую интеграцию для кастомных моделей, ollama self-hosted и MLX моделей
• расширилось количество агентских метрик до 9
• подключить свою ИИ систему можно просто как в Postman, просто указав параметры API запроса
• и много мелких правок дефектов!
Кроме того, мой фремворк запускается локально, и вы можете запускать оценки через нативный UI интерфейс.
Если вы еше не пробовали, как это работает, то полная документация доступна тут по ссылке library.eval-ai.com, установить можно простой командой
pip install eval-ai-library
после чего достаточно ввести к командной строке
eval-ai dashboard
Буду отдельно благодарен за звезды ⭐️ на github https://github.com/meshkovQA/Eval-ai-library, а также поддержку в развитии данного фреймворка!
Кроме того, если вас интересует подход, который я использую для вычисления метрик, то данную информацию вы также можете найти в моей работе на arxiv https://arxiv.org/abs/2604.08595
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
❤4👍4🔥3
Всем привет!
Вчера с Сергеем провели совместный эфир на тему работы с Claude Code, в том числе в части создания агентов по тестированию.
Много говорили на эту тему, поэтому если вас интересует особенности работы с claude code в части тестирования, да и в целом про работу с ИИ моделями, то советую посмотреть!
Ссылка
https://www.youtube.com/watch?v=7tSGtTraWFs
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Вчера с Сергеем провели совместный эфир на тему работы с Claude Code, в том числе в части создания агентов по тестированию.
Много говорили на эту тему, поэтому если вас интересует особенности работы с claude code в части тестирования, да и в целом про работу с ИИ моделями, то советую посмотреть!
Ссылка
https://www.youtube.com/watch?v=7tSGtTraWFs
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥12❤1👍1
Хочу поговорить про то, что я наблюдаю довольно часто, когда команды начинают заниматься оценкой своих 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