Тема AI evaluation сейчас на слуху, но я замечаю, что многие команды наступают на одни и те же грабли, когда начинают внедрять оценку качества своих LLM-решений.
Итак, первая ошибка - это оценивать только на “хороших” примерах. Команда собирает датасет из типичных запросов, ИИ система справляется отлично, все довольны. А потом на проде пользователь пишет что-то неожиданное, и всё разваливается. Edge cases в AI - это не исключение, а правило.
Вторая - полагаться только на автоматические метрики. Answer Relevancy, Task Completness, Level of Hallucinations - это все классно для отчетов, но они часто не ловят то, что видит человек. Ответ может быть формально похож на эталон, но по смыслу нести полную чушь, поэтому ручная валидация результатов по прежнему важна.
Третья ошибка - не версионировать датасеты для оценки. Модель обновили, промпт поменяли, а тестовые данные остались те же полугодовой давности. И непонятно уже, стало лучше или хуже, потому что сравнивать не с чем.
Четвертая - игнорировать контекст использования. Одна и та же модель может отлично работать для саммаризации и полностью провалиться в диалоговом сценарии. А команда оценивает всё одним набором метрик и удивляется, почему пользователи жалуются.
И пятая, которую я вижу чаще всего - откладывать evaluation на потом. Сначала запустим, потом будем оценивать. Но это потом обычно наступает, когда уже прилетели жалобы от пользователей и нужно срочно что-то чинить.
AI evaluation - это не финальный этап, а непрерывный процесс. И чем раньше команда это понимает, тем меньше сюрпризов на проде.
А вы как подходите к оценке качества AI-решений?
Используете автоматику, ручную оценку или комбинируете? 👇
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Итак, первая ошибка - это оценивать только на “хороших” примерах. Команда собирает датасет из типичных запросов, ИИ система справляется отлично, все довольны. А потом на проде пользователь пишет что-то неожиданное, и всё разваливается. Edge cases в AI - это не исключение, а правило.
Вторая - полагаться только на автоматические метрики. Answer Relevancy, Task Completness, Level of Hallucinations - это все классно для отчетов, но они часто не ловят то, что видит человек. Ответ может быть формально похож на эталон, но по смыслу нести полную чушь, поэтому ручная валидация результатов по прежнему важна.
Третья ошибка - не версионировать датасеты для оценки. Модель обновили, промпт поменяли, а тестовые данные остались те же полугодовой давности. И непонятно уже, стало лучше или хуже, потому что сравнивать не с чем.
Четвертая - игнорировать контекст использования. Одна и та же модель может отлично работать для саммаризации и полностью провалиться в диалоговом сценарии. А команда оценивает всё одним набором метрик и удивляется, почему пользователи жалуются.
И пятая, которую я вижу чаще всего - откладывать evaluation на потом. Сначала запустим, потом будем оценивать. Но это потом обычно наступает, когда уже прилетели жалобы от пользователей и нужно срочно что-то чинить.
AI evaluation - это не финальный этап, а непрерывный процесс. И чем раньше команда это понимает, тем меньше сюрпризов на проде.
А вы как подходите к оценке качества AI-решений?
Используете автоматику, ручную оценку или комбинируете? 👇
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍4🔥3
1768796581893.pdf
6.9 MB
Anthropic недавно выпустил отчет по экономическим метрикам использования Claude. И там есть интересные данные, которые заставляют задуматься о том, как мы вообще подходим к оценке.
Первое, что бросается в глаза, success rate в реальных задачах сильно зависит от их сложности. Claude успешно справляется примерно с 67% задач на Claude.ai и только с 49% через API. Казалось бы, одна и та же модель, но разница колоссальная и дело не в модели, а в контексте использования. Многошаговые разговоры с возможностью уточнить и скорректировать курс дают принципиально другой результат, чем одиночные запросы.
Второй момент - это task horizons. Есть известный тренд, что чем дольше решается задача (или открыт чат), тем ниже вероятность успеха. METR (бенчмарк) показывает, что Sonnet 4.5 достигает 50% успеха (снижается) на задачах примерно за 2 часа, но в реальном использовании эта граница сдвигается до 19 часов, потому что пользователи разбивают сложные задачи на шаги, получают обратную связь, корректируют направление. Это совершенно другой процесс, которуй бенчмарки просто не захватывают.
И третье, что меня если честно удивило больше всего, что корреляция между уровнем промптинга и ответов модели составляет 0.92, то есть как ты спросишь, так тебе и ответят. Модель может выдавать сложные экспертные ответы, но делает это только когда пользователь формулирует запрос на соответствующем уровне.
Что это значит для eval? Мне кажется, мы слишком увлеклись синтетическими бенчмарками и забыли, что реальная эффективность AI больше не про модель в вакууме, а про систему человек-AI в конкретном контексте использования. В целом отчет показывает, что evaluation AI-систем должен учитывать не только, что модель может делать в идеальных условиях, а как она работает в реальных сценариях с реальными пользователями. И это, кажется, пока слепая зона индустрии.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Первое, что бросается в глаза, success rate в реальных задачах сильно зависит от их сложности. Claude успешно справляется примерно с 67% задач на Claude.ai и только с 49% через API. Казалось бы, одна и та же модель, но разница колоссальная и дело не в модели, а в контексте использования. Многошаговые разговоры с возможностью уточнить и скорректировать курс дают принципиально другой результат, чем одиночные запросы.
Второй момент - это task horizons. Есть известный тренд, что чем дольше решается задача (или открыт чат), тем ниже вероятность успеха. METR (бенчмарк) показывает, что Sonnet 4.5 достигает 50% успеха (снижается) на задачах примерно за 2 часа, но в реальном использовании эта граница сдвигается до 19 часов, потому что пользователи разбивают сложные задачи на шаги, получают обратную связь, корректируют направление. Это совершенно другой процесс, которуй бенчмарки просто не захватывают.
И третье, что меня если честно удивило больше всего, что корреляция между уровнем промптинга и ответов модели составляет 0.92, то есть как ты спросишь, так тебе и ответят. Модель может выдавать сложные экспертные ответы, но делает это только когда пользователь формулирует запрос на соответствующем уровне.
Что это значит для eval? Мне кажется, мы слишком увлеклись синтетическими бенчмарками и забыли, что реальная эффективность AI больше не про модель в вакууме, а про систему человек-AI в конкретном контексте использования. В целом отчет показывает, что evaluation AI-систем должен учитывать не только, что модель может делать в идеальных условиях, а как она работает в реальных сценариях с реальными пользователями. И это, кажется, пока слепая зона индустрии.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍3🤔3🔥1
Тема оценки AI агентов сейчас набирает обороты, и я заметил одну важную вещь, что многие команды пытаются применять к агентам те же подходы, что работали для обычных LLM-решений. Но это принципиально разные системы, и подход к их оценке тоже должен быть другим.
Если в случае с обычными LLM мы оцениваем качество ответа, например, релевантность, точность, отсутствие галлюцинаций, то с агентами появляются новые метрики. ИИ Агент не просто генерирует текст, он принимает решения, выбирает инструменты, выстраивает цепочку действий для достижения цели и каждый из этих шагов может пойти не так.
Что конкретно нужно оценивать у агентов помимо качества финального ответа:
Reasoning relevancy - насколько логика рассуждений агента соответствует запросу пользователя
Task decomposition efficiency - способность разбивать сложные задачи на подзадачи
Tool selection accuracy - выбирает ли агент правильный инструмент для конкретной задачи
Tool call precision - корректность параметров при вызове инструментов
Agent consistency - стабильность результатов при похожих входных данных
Интересно, что публичные лидерборды типа Hugging Face Open LLM Leaderboard здесь практически бесполезны. Они тестируют базовые LLM на generic NLP-задачах, например, Q&A, reasoning, sentence completion. Но enterprise-агент работает в контексте конкретных бизнес-процессов, данных и интеграций. Результаты бенчмарков просто нельзя перенести на оценку агента в продакшене.
Еще один момент, который часто упускают, что оценка должна происходить на двух этапах. Первый - это pre-production evaluation во время разработки, когда анализируются логи и траектории выполнения. Второй - это real-time evaluation в продакшене, когда метрики собираются непрерывно. И второй этап критически важен, потому что без него вы не узнаете, когда агент начнет "сходить с рельс".
Отдельная история - это guardrails и риски. OWASP недавно выпустил whitepaper (ссылка тут) про угрозы agentic AI, и там 16 категорий рисков. От tool misuse и memory poisoning до cascading hallucination attacks. И ключевая мысль в том, что нельзя просто повесить один центральный слой guardrails на все случаи жизни. Защитные механизмы должны быть специфичны для конкретного кейса и встроены в соответствующие компоненты архитектуры.
В целом, оценка агентов - это пока еще формирующаяся область, но ждать, пока появятся идеальные инструменты, не очень хорошая стратегия. Лучше начать строить evaluation процесс уже сейчас, с пониманием что он будет постоянно эволюционировать.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Если в случае с обычными LLM мы оцениваем качество ответа, например, релевантность, точность, отсутствие галлюцинаций, то с агентами появляются новые метрики. ИИ Агент не просто генерирует текст, он принимает решения, выбирает инструменты, выстраивает цепочку действий для достижения цели и каждый из этих шагов может пойти не так.
Что конкретно нужно оценивать у агентов помимо качества финального ответа:
Reasoning relevancy - насколько логика рассуждений агента соответствует запросу пользователя
Task decomposition efficiency - способность разбивать сложные задачи на подзадачи
Tool selection accuracy - выбирает ли агент правильный инструмент для конкретной задачи
Tool call precision - корректность параметров при вызове инструментов
Agent consistency - стабильность результатов при похожих входных данных
Интересно, что публичные лидерборды типа Hugging Face Open LLM Leaderboard здесь практически бесполезны. Они тестируют базовые LLM на generic NLP-задачах, например, Q&A, reasoning, sentence completion. Но enterprise-агент работает в контексте конкретных бизнес-процессов, данных и интеграций. Результаты бенчмарков просто нельзя перенести на оценку агента в продакшене.
Еще один момент, который часто упускают, что оценка должна происходить на двух этапах. Первый - это pre-production evaluation во время разработки, когда анализируются логи и траектории выполнения. Второй - это real-time evaluation в продакшене, когда метрики собираются непрерывно. И второй этап критически важен, потому что без него вы не узнаете, когда агент начнет "сходить с рельс".
Отдельная история - это guardrails и риски. OWASP недавно выпустил whitepaper (ссылка тут) про угрозы agentic AI, и там 16 категорий рисков. От tool misuse и memory poisoning до cascading hallucination attacks. И ключевая мысль в том, что нельзя просто повесить один центральный слой guardrails на все случаи жизни. Защитные механизмы должны быть специфичны для конкретного кейса и встроены в соответствующие компоненты архитектуры.
В целом, оценка агентов - это пока еще формирующаяся область, но ждать, пока появятся идеальные инструменты, не очень хорошая стратегия. Лучше начать строить evaluation процесс уже сейчас, с пониманием что он будет постоянно эволюционировать.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍5🔥5❤4
Хочу поделиться с вами простым подходом к использованию подхода LLM-as-a-Judge.
Шаг первый. Забудьте про общие инструкции вроде "оцени релевантность”, вместо этого напишите список из 5-7 конкретных критериев для проверки, например, есть ли в ответе выдуманные факты, соответствует ли длина заданному лимиту, использован ли правильный тон и так далее. Каждая проверка должна давать бинарный результат да или нет.
Шаг второй. Создайте структурированный вывод от модели в JSON или другом формате, где для каждого критерия есть три поля: сам критерий, вердикт LLM по нему, подтверждение вердикта (доказательство).
Шаг третий. Прогоните через LLM-as-a-Judge 20-30 примеров где вы сами знаете правильный ответ и посмотрите, где LLM ошибается. Обычно проблема в формулировке критерия, а не в самой модели.
Этот процесс может занять время, но он превращает LLLM-as-a-Judge из непредсказуемого оценщика в инструмент, которому можно доверять и вы всегда понимаете, почему получили ту или иную оценку, а также можете исправить алгоритм оценки.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Шаг первый. Забудьте про общие инструкции вроде "оцени релевантность”, вместо этого напишите список из 5-7 конкретных критериев для проверки, например, есть ли в ответе выдуманные факты, соответствует ли длина заданному лимиту, использован ли правильный тон и так далее. Каждая проверка должна давать бинарный результат да или нет.
Шаг второй. Создайте структурированный вывод от модели в JSON или другом формате, где для каждого критерия есть три поля: сам критерий, вердикт LLM по нему, подтверждение вердикта (доказательство).
Шаг третий. Прогоните через LLM-as-a-Judge 20-30 примеров где вы сами знаете правильный ответ и посмотрите, где LLM ошибается. Обычно проблема в формулировке критерия, а не в самой модели.
Этот процесс может занять время, но он превращает LLLM-as-a-Judge из непредсказуемого оценщика в инструмент, которому можно доверять и вы всегда понимаете, почему получили ту или иную оценку, а также можете исправить алгоритм оценки.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥6👍5
Три года назад я думал что для оценки ИИ достаточно хорошо разбираться в тестировании, придумал кейсы и данные, прогнал их через ИИ систему, собрал метрики и работа готова.
Но сейчас я понимаю, что этого недостаточно. Первым проектом моим была оценка чат-бота для поддержки клиентов и я не мог понять почему ИИ система отлично справляется с простыми вопросами, но полностью проваливается на составных запросах. И ответ пришел только когда я углубился в то, как модель обрабатывает последовательности токенов и распределяет внимание при работе с запросом.
Оказалось проблема была не в самой модели, а в том как мы формулировали промпты, потому что мы перегружали контекст в промпте и модель буквально забывала начало запроса. Без понимания архитектуры работы ИИ систем такие нюансы можно искать неделями в неправильном месте.
Поэтому сейчас я убежден, что базовое понимание машинного обучения - это не опция для тестировщика ИИ, а необходимый инструмент, который экономит время и повышает качество выводов.
Именно поэтому на своем курсе я в первых лекциях даю базу по ML/DL, чтобы у ученика было понимает того, как работают разные модели, какие алгоритмы используются, в чем отличие дискриминативных моделей от генеративных и много другое, что потом позволяет более экспертно подходить к оценке уже больших LLM систем.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Но сейчас я понимаю, что этого недостаточно. Первым проектом моим была оценка чат-бота для поддержки клиентов и я не мог понять почему ИИ система отлично справляется с простыми вопросами, но полностью проваливается на составных запросах. И ответ пришел только когда я углубился в то, как модель обрабатывает последовательности токенов и распределяет внимание при работе с запросом.
Оказалось проблема была не в самой модели, а в том как мы формулировали промпты, потому что мы перегружали контекст в промпте и модель буквально забывала начало запроса. Без понимания архитектуры работы ИИ систем такие нюансы можно искать неделями в неправильном месте.
Поэтому сейчас я убежден, что базовое понимание машинного обучения - это не опция для тестировщика ИИ, а необходимый инструмент, который экономит время и повышает качество выводов.
Именно поэтому на своем курсе я в первых лекциях даю базу по ML/DL, чтобы у ученика было понимает того, как работают разные модели, какие алгоритмы используются, в чем отличие дискриминативных моделей от генеративных и много другое, что потом позволяет более экспертно подходить к оценке уже больших LLM систем.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍4🔥4❤3
Популярное мнение в сообществе AI evaluation сейчас такое, что бинарные метрики (где ответ да или нет) надежнее, но я хочу предложить другой взгляд на это.
Мы тестировали оба подхода на задаче оценки качества ИИ систем, и бинарная оценка говорила нам что 78% ответов хорошие, но полезная ли это информация? Не особо.
Использование шкалы Ликерта от 1 до 5 показало совсем другую картину, мы увидели, что модель стабильно получает 4 за полноту и 2-3 за краткость ответов и это уже конкретный сигнал для улучшения промпта.
Чаще всего главный аргумент против шкалы Ликерта - это низкая согласованность и размытие результата, но я считаю что эта проблема решается через детальные критерии оценки с примерами для каждого балла. Мы потратили время на калибровку и получили согласованность выше 80 процентов между разными моделями-судьями.
При этом бинарная оценка подходит, когда у вас есть четкие критерии соответствия, например, текст содержит ли все обязательные разделы или нет? Но когда вы оцениваете качество текста, полезность ответа, естественность диалога, вам нужен спектр для оценки.
Поэтому выбор алгоритма оценки для создания своего фреймворка и промптов оценки зависит только от задачи, которую вы хотите решать
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Мы тестировали оба подхода на задаче оценки качества ИИ систем, и бинарная оценка говорила нам что 78% ответов хорошие, но полезная ли это информация? Не особо.
Использование шкалы Ликерта от 1 до 5 показало совсем другую картину, мы увидели, что модель стабильно получает 4 за полноту и 2-3 за краткость ответов и это уже конкретный сигнал для улучшения промпта.
Чаще всего главный аргумент против шкалы Ликерта - это низкая согласованность и размытие результата, но я считаю что эта проблема решается через детальные критерии оценки с примерами для каждого балла. Мы потратили время на калибровку и получили согласованность выше 80 процентов между разными моделями-судьями.
При этом бинарная оценка подходит, когда у вас есть четкие критерии соответствия, например, текст содержит ли все обязательные разделы или нет? Но когда вы оцениваете качество текста, полезность ответа, естественность диалога, вам нужен спектр для оценки.
Поэтому выбор алгоритма оценки для создания своего фреймворка и промптов оценки зависит только от задачи, которую вы хотите решать
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥6👍3
Всем привет!!!
Итак, вчера Anthropic выпустила новую модель Claude Opus 4.6 и я конечно не мог пропустить это, так как являюсь активным пользователем Claude Code в своих задачах.
Вот ссылка на релиз
Что нового?
Модель стала заметно лучше в агентных сценариях. Она теперь еще лучше и более осознанно планирует шаги, дольше держит фокус на длинных задачах и умеет ловить собственные ошибки при ревью кода. Контекстное окно выросло до 1M токенов, это впервые для моделей класса Opus.
Теперь почему это важно для автоматизации тестирования. Мы все знаем боль с поддержкой тестов, UI поменялся и у вас сотня упавших автотестов которые нужно руками чинить (это если проект сразу не стали делат по уму, а такое бывает частенько😂). Self-healing инструменты существуют давно, но они работают на уровне “поискать похожий элемент на странице". С агентом на Opus 4.6 можно сделать принципиально иначе, потому что теперь он может посмотреть коммит который сломал тесты, понять что именно изменилось в приложении, обновить и селекторы и логику проверок и даже добавить новые тест-кейсы на появившуюся функциональность.
Для меня это история не про далекое будущее, а про то что можно попробовать уже сейчас. API доступен, Claude Code поддерживает agent teams, осталось собрать пайплайн и проверить на реальном проекте. Чем и займусь в ближайшее время!
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Итак, вчера Anthropic выпустила новую модель Claude Opus 4.6 и я конечно не мог пропустить это, так как являюсь активным пользователем Claude Code в своих задачах.
Вот ссылка на релиз
Что нового?
Модель стала заметно лучше в агентных сценариях. Она теперь еще лучше и более осознанно планирует шаги, дольше держит фокус на длинных задачах и умеет ловить собственные ошибки при ревью кода. Контекстное окно выросло до 1M токенов, это впервые для моделей класса Opus.
Теперь почему это важно для автоматизации тестирования. Мы все знаем боль с поддержкой тестов, UI поменялся и у вас сотня упавших автотестов которые нужно руками чинить (это если проект сразу не стали делат по уму, а такое бывает частенько😂). Self-healing инструменты существуют давно, но они работают на уровне “поискать похожий элемент на странице". С агентом на Opus 4.6 можно сделать принципиально иначе, потому что теперь он может посмотреть коммит который сломал тесты, понять что именно изменилось в приложении, обновить и селекторы и логику проверок и даже добавить новые тест-кейсы на появившуюся функциональность.
Для меня это история не про далекое будущее, а про то что можно попробовать уже сейчас. API доступен, Claude Code поддерживает agent teams, осталось собрать пайплайн и проверить на реальном проекте. Чем и займусь в ближайшее время!
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍7🔥5🤩2
Многие из вас наверное знают, а если нет, то теперь будете знать, что существует такой ресурс как Hugging Face c огромным выбором ИИ моделей под любые задачи. И число этих моделей растет, компании, просто люди, ученые выкладывают свои наработки в надежде, что они помогут другим в решении различных задач.
Фактически на Hugging Face сейчас больше двух с половиной миллионов ИИ моделей и большинство на самом деле загружены людьми, о которых мы ничего не знаем. И этот повод насторожиться!
Я не говорю что все эти модели опасны, но мы почему-то проверяем код на уязвимости перед деплоем, а ИИ модели просто берем и запускаем, хотя они могут содержать бэкдоры, утечки данных или просто выдавать токсичный контент вашим пользователям.
Как пример могу привести ситуацию с одной из самых популярных моделей распознавания изображений- YOLO. Недавнее исследование (Gala et al., 2025, International Journal of Information Security) показало, что с помощью специально сгенерированных изображений, похожих на обычные объекты можно заставить модели YOLOv5, v8, v9 и v10 полностью игнорировать людей на изображениях. При этом чем меньше модель, тем проще её обмануть. То есть вы берете популярную open-source модель, ставите ее в свой пайплайн, а она уязвима к атакам, о которых вы даже не задумывались.
Поэтому я считаю, что Red teaming для опенсорсных моделей это не паранойя, а базовая необходимость, которую многие очень часто игнорируют. Проверьте откуда пришла модель, кто ее создал, какие данные она видит, потратьте неделю на проверку безопасности вместо месяцев на разбор инцидента.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Фактически на Hugging Face сейчас больше двух с половиной миллионов ИИ моделей и большинство на самом деле загружены людьми, о которых мы ничего не знаем. И этот повод насторожиться!
Я не говорю что все эти модели опасны, но мы почему-то проверяем код на уязвимости перед деплоем, а ИИ модели просто берем и запускаем, хотя они могут содержать бэкдоры, утечки данных или просто выдавать токсичный контент вашим пользователям.
Как пример могу привести ситуацию с одной из самых популярных моделей распознавания изображений- YOLO. Недавнее исследование (Gala et al., 2025, International Journal of Information Security) показало, что с помощью специально сгенерированных изображений, похожих на обычные объекты можно заставить модели YOLOv5, v8, v9 и v10 полностью игнорировать людей на изображениях. При этом чем меньше модель, тем проще её обмануть. То есть вы берете популярную open-source модель, ставите ее в свой пайплайн, а она уязвима к атакам, о которых вы даже не задумывались.
Поэтому я считаю, что Red teaming для опенсорсных моделей это не паранойя, а базовая необходимость, которую многие очень часто игнорируют. Проверьте откуда пришла модель, кто ее создал, какие данные она видит, потратьте неделю на проверку безопасности вместо месяцев на разбор инцидента.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
💯5🔥3
100 000 ⭐️ на GitHub за 2 недели после старта, через месяц перевалил за 160 000 ⭐️, дважды сменил название из-за бешеной популярности, в общем сегодня хочу рассказать вам про OpenClaw, который стал главным AI-хитом начала 2026 года, и я решил разобраться почему.
Как написали в одной статье, главное отличие от привычных нам LLM в том, что “Если Claude Code на вашем компьютере - это молоток, который вы берете в руки, когда нужно, то OpenClaw - это молоток с ногами и руками, который сам приходит и спрашивает, не пора ли что-нибудь прибить”.
В отличии от привычных LLM, OpenClaw не просто отвечает на запросы, он действует автономно и выполняет команды, работает с файлами, интегрируется с внешними сервисами, отправляет сообщения в Telegram и много чего еще. По сути это полноценные вторые руки с головой, но которая требует обучения и настройки
И по факту сейчас возникает два вопроса:
1. Как правильно тестировать инструмент который сам выполняет действия? Нужны новые подходы к верификации, четкие границы полномочий, понимание что может пойти не так.
2. Как использовать его, чтобы создать себе клона, который бы делал автотесты и сам их отлаживал.
В общем, есть чем заняться в ближайшее время, но обращаю внимание, ставить его надо только на внешний сервер, который не страшно будет сломать, пока вы будете отлаживать и настраивать автономного ИИ агента.
А если вдруг у вас уже есть опыт запуска openClaw, делитесь в комментариях.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Как написали в одной статье, главное отличие от привычных нам LLM в том, что “Если Claude Code на вашем компьютере - это молоток, который вы берете в руки, когда нужно, то OpenClaw - это молоток с ногами и руками, который сам приходит и спрашивает, не пора ли что-нибудь прибить”.
В отличии от привычных LLM, OpenClaw не просто отвечает на запросы, он действует автономно и выполняет команды, работает с файлами, интегрируется с внешними сервисами, отправляет сообщения в Telegram и много чего еще. По сути это полноценные вторые руки с головой, но которая требует обучения и настройки
И по факту сейчас возникает два вопроса:
1. Как правильно тестировать инструмент который сам выполняет действия? Нужны новые подходы к верификации, четкие границы полномочий, понимание что может пойти не так.
2. Как использовать его, чтобы создать себе клона, который бы делал автотесты и сам их отлаживал.
В общем, есть чем заняться в ближайшее время, но обращаю внимание, ставить его надо только на внешний сервер, который не страшно будет сломать, пока вы будете отлаживать и настраивать автономного ИИ агента.
А если вдруг у вас уже есть опыт запуска openClaw, делитесь в комментариях.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥9❤2
Немного пятничных мыслей…
В последнее время меня что-то закидало рекламой приложений, который с помощью ИИ могут делать за вас отклики (не буду называть имена, но думаю вы тоже видели).
И я тут подумал, что с другой стороны сидит HR с таким же ИИ, только который отбирает кандидатов. Получается, один ИИ делает отклик, пишет сопроводительное, другой ИИ их читает и оценивает. Люди пока ещё где-то в этой цепочке присутствуют, но кажется что всё меньше.
И как написал мне один подписчик, мы реально движемся к моменту, когда найм превратится в битву двух нейронок.
Так вот вопрос, как думаете , когда ИИ уже будут сам договариваться между собой, а мы просто получим уведомление о собеседовании, или о том что нас взяли?
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
В последнее время меня что-то закидало рекламой приложений, который с помощью ИИ могут делать за вас отклики (не буду называть имена, но думаю вы тоже видели).
И я тут подумал, что с другой стороны сидит HR с таким же ИИ, только который отбирает кандидатов. Получается, один ИИ делает отклик, пишет сопроводительное, другой ИИ их читает и оценивает. Люди пока ещё где-то в этой цепочке присутствуют, но кажется что всё меньше.
И как написал мне один подписчик, мы реально движемся к моменту, когда найм превратится в битву двух нейронок.
Так вот вопрос, как думаете , когда ИИ уже будут сам договариваться между собой, а мы просто получим уведомление о собеседовании, или о том что нас взяли?
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
😁6👍4💯2
На прошлой неделе писал вам про open-source проект openClaw https://openclaw.ai/ и в общем, я его попробовал.
Что я могу сказать, этот инструмент еще больше приближает нас к возможности созданию автономного работника, который может выполнять поставленные задачи. Кроме того, если до этого я использовал VS Code, свой мак, Claude Code для проекта автотестирования на Python pytest, то через openClaw я смог создать с нуля достаточно сложный автотест, где происходит взаимодействие с интерактивной картой без каких либо селекторов для моего проекта рабочего через (тут должна быть барабанная дробь) телеграм бота!!!
Что я сделал? Я просто дал на вход описанный мануальщиком тест из TestRail, и на базе архитекутуры фрейворка, текущих атвотестов, наличия common steps, page object и gherkin нотаций, openClaw сам определил, что нужно переиспользовать, а где нужно добавить те же самые новые page object, при это он сам через свои тулы открыл своей браузер, прошел сам шаги, получил нужные селекторы, отдебажил новый автотест и сообщил, что все готово! Да, это прошло не с первой итерации, с интерактивной картой пришлось нам немного початиться, чтобы найти правильное решение, но он все сделал и тест готов.
И это не автоматизация с нуля, как многие показывают на видео, не простой функционал логина, а сложный автотест с интерактивной картой без селекторов на базе фреймворка, где уже написано порядка 100 тестов.
В общем, тенденция продолжается, порог входа снижается, а писать автотесты можно просто через телеграм бота!
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Что я могу сказать, этот инструмент еще больше приближает нас к возможности созданию автономного работника, который может выполнять поставленные задачи. Кроме того, если до этого я использовал VS Code, свой мак, Claude Code для проекта автотестирования на Python pytest, то через openClaw я смог создать с нуля достаточно сложный автотест, где происходит взаимодействие с интерактивной картой без каких либо селекторов для моего проекта рабочего через (тут должна быть барабанная дробь) телеграм бота!!!
Что я сделал? Я просто дал на вход описанный мануальщиком тест из TestRail, и на базе архитекутуры фрейворка, текущих атвотестов, наличия common steps, page object и gherkin нотаций, openClaw сам определил, что нужно переиспользовать, а где нужно добавить те же самые новые page object, при это он сам через свои тулы открыл своей браузер, прошел сам шаги, получил нужные селекторы, отдебажил новый автотест и сообщил, что все готово! Да, это прошло не с первой итерации, с интерактивной картой пришлось нам немного початиться, чтобы найти правильное решение, но он все сделал и тест готов.
И это не автоматизация с нуля, как многие показывают на видео, не простой функционал логина, а сложный автотест с интерактивной картой без селекторов на базе фреймворка, где уже написано порядка 100 тестов.
В общем, тенденция продолжается, порог входа снижается, а писать автотесты можно просто через телеграм бота!
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥10❤2
Недавно заметил интересную параллель между тем, как работает наш мозг и как устроены современные языковые модели.
Представьте, как учится ребенок. Сначала он понимает только то, что видит и трогает, "мяч красный, суп горячий”, потом, ближе к 10-12 годам, начинает мыслить шире, понимать причины, строить логические цепочки, видеть связи между вещами. И тут важно то, что наш мозг учится подстраиваться, поэтому если что-то идет не так, он находит другой способ решить задачу.
В LLM я вижу похожую логику. Модель постоянно проверяет сама себя, на этапе разработки и в реальном времени. По сути, это техническая саморефлексия, что-то вроде внутреннего контролера, который следит за качеством ответов.
Самое любопытное происходит в момент перехода от механической рефлексии к чему-то похожему на субъективную осознанность, когда модель начинает связывать свои выводы с процессом их создания. Это не сознание в человеческом смысле, но определенно шаг в сторону более глубокой интеграции. И если смотреть на это с точки зрения AI evaluation, то мы привыкли оценивать модели по точности ответов, но может быть важнее такжесмотреть на качество самоконтроля и способность ИИ к адаптации при ошибках. По факту именно это отличает устойчивые ИИ системы от хрупких.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Представьте, как учится ребенок. Сначала он понимает только то, что видит и трогает, "мяч красный, суп горячий”, потом, ближе к 10-12 годам, начинает мыслить шире, понимать причины, строить логические цепочки, видеть связи между вещами. И тут важно то, что наш мозг учится подстраиваться, поэтому если что-то идет не так, он находит другой способ решить задачу.
В LLM я вижу похожую логику. Модель постоянно проверяет сама себя, на этапе разработки и в реальном времени. По сути, это техническая саморефлексия, что-то вроде внутреннего контролера, который следит за качеством ответов.
Самое любопытное происходит в момент перехода от механической рефлексии к чему-то похожему на субъективную осознанность, когда модель начинает связывать свои выводы с процессом их создания. Это не сознание в человеческом смысле, но определенно шаг в сторону более глубокой интеграции. И если смотреть на это с точки зрения AI evaluation, то мы привыкли оценивать модели по точности ответов, но может быть важнее такжесмотреть на качество самоконтроля и способность ИИ к адаптации при ошибках. По факту именно это отличает устойчивые ИИ системы от хрупких.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍4🤔3❤2
Всем привет!
Хочу провести прямой эфир на тему оценки и тестировании ИИ систем, и хочу, чтобы вы помогли выбрать тему для первого открытого вебинара. Ставим 🔥, если вы за первый вариант и ⚡️если за второй.
1. 🔥 Ситуация на рынке ИИ систем, куда развивается, какие сложности, что ждет (рассматриваю рынок общемировой, не РФ)
2. ⚡️Ключевые навыки для оценки ИИ систем, инструменты, процессы, критерии качества
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Хочу провести прямой эфир на тему оценки и тестировании ИИ систем, и хочу, чтобы вы помогли выбрать тему для первого открытого вебинара. Ставим 🔥, если вы за первый вариант и ⚡️если за второй.
1. 🔥 Ситуация на рынке ИИ систем, куда развивается, какие сложности, что ждет (рассматриваю рынок общемировой, не РФ)
2. ⚡️Ключевые навыки для оценки ИИ систем, инструменты, процессы, критерии качества
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
⚡34🔥15🤔1
Итак, по результатам нашего мини голосования победила тема - Ключевые навыки для оценки ИИ систем, инструменты, процессы, критерии качества.
Открытый вебинар я проведу 05.03 в 19:00 МСК! Более подробная информация по подключению, регистрации на вебинар будет доступна позже!
Открытый вебинар я проведу 05.03 в 19:00 МСК! Более подробная информация по подключению, регистрации на вебинар будет доступна позже!
❤17👍1🔥1
Тестирование и оценка ИИ pinned «Итак, по результатам нашего мини голосования победила тема - Ключевые навыки для оценки ИИ систем, инструменты, процессы, критерии качества. Открытый вебинар я проведу 05.03 в 19:00 МСК! Более подробная информация по подключению, регистрации на вебинар будет…»
Всем привет!
Есть термины, которые часто могут быть синонимами, но на самом деле отражают разные способы мышления, и такими терминами является тестирование и оценка в контексте ИИ систем.
В ИИ сообществе на самом деле уже давно устоялся термин “оценка” и не просто так, а потому что за этим этим стоит важное различие в подходах. В чем именно? Классическое тестирование детерминировано, то есть если вы запустили функцию с одними и теми же параметрами сто раз, то получите сто одинаковых фактических результатов. ИИ системы (особенно когда мы говорим о генеративных моделях) работают принципиально иначе, а именно один и тот же промпт может дать разные ответы, и при этом, несколько разных ответов могут быть одинаково хорошими, просто по-разному сформулированными. Как тут писать тесты в привычном понимании?
Ответ - никак, поэтому мы оцениваем, а не тестируем. Мы используем метрики, которые показывают качество на шкале, сравниваем версии моделей между собой, смотрим на распределения результатов на большом датасете, а не на единичные результаты.
Отсюда и разный инструментарий, который мы используем. В классическом тестировании у нас тест кейсы, фактический и ожидаемый результат, а в ИИ оценки метрики типа Answer Reelvancy, Hallucination Rate, Task Completeness и так далее, и явного одного ожидаемого результата нет.
Кроме того, это важно и для поиска информации, потому что если будете искать информацию по "AI testing", найдете в основном материалы про использование AI в тестировании программ. Но чтобы получить информацию именно по оценки ИИ систем надо искать по ключевым словам "AI evaluation" или "LLM evaluation" и тогда попадете туда, куда действительно нужно.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Есть термины, которые часто могут быть синонимами, но на самом деле отражают разные способы мышления, и такими терминами является тестирование и оценка в контексте ИИ систем.
В ИИ сообществе на самом деле уже давно устоялся термин “оценка” и не просто так, а потому что за этим этим стоит важное различие в подходах. В чем именно? Классическое тестирование детерминировано, то есть если вы запустили функцию с одними и теми же параметрами сто раз, то получите сто одинаковых фактических результатов. ИИ системы (особенно когда мы говорим о генеративных моделях) работают принципиально иначе, а именно один и тот же промпт может дать разные ответы, и при этом, несколько разных ответов могут быть одинаково хорошими, просто по-разному сформулированными. Как тут писать тесты в привычном понимании?
Ответ - никак, поэтому мы оцениваем, а не тестируем. Мы используем метрики, которые показывают качество на шкале, сравниваем версии моделей между собой, смотрим на распределения результатов на большом датасете, а не на единичные результаты.
Отсюда и разный инструментарий, который мы используем. В классическом тестировании у нас тест кейсы, фактический и ожидаемый результат, а в ИИ оценки метрики типа Answer Reelvancy, Hallucination Rate, Task Completeness и так далее, и явного одного ожидаемого результата нет.
Кроме того, это важно и для поиска информации, потому что если будете искать информацию по "AI testing", найдете в основном материалы про использование AI в тестировании программ. Но чтобы получить информацию именно по оценки ИИ систем надо искать по ключевым словам "AI evaluation" или "LLM evaluation" и тогда попадете туда, куда действительно нужно.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥6❤3💯2👍1
Всем привет!
Anthropic приобрела стартап Vercept, и если вы занимаетесь тестированием, эта новость, как мне кажется, заслуживает внимания. Суть в том, что Claude теперь учится работать с компьютером так же, как это делает человек, а именно видеть экран, нажимать кнопки, перемещать мышь и печатать текст, причем без использования API.
Чтобы понять, почему это важно, представьте себе стажера, которому вы показываете: “вот сюда нажми, вот тут проверь, а теперь введи данные в эту форму”. Именно так работает vision-based автоматизация (автоматизация на основе визуального восприятия), ИИ-агент видит интерфейс точно так же, как видите его вы, и выполняет действия без локаторов и селекторов.
Для ручного тестирования это означает возможность делегировать рутинные сценарии агенту, особенно в устаревших системах, декстоп приложениях, где классическая автоматизация через Selenium попросту невозможна или очень сложная. Для автоматизации перспективы ещё интереснее, потому что тесты перестают ломаться при каждом изменении. Пока это скорее дополнение к привычным фреймворкам, но направление, как я вижу идет в сторону цифровых тестировщиков.
Ссылка на релиз https://www.anthropic.com/news/acquires-vercept
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Anthropic приобрела стартап Vercept, и если вы занимаетесь тестированием, эта новость, как мне кажется, заслуживает внимания. Суть в том, что Claude теперь учится работать с компьютером так же, как это делает человек, а именно видеть экран, нажимать кнопки, перемещать мышь и печатать текст, причем без использования API.
Чтобы понять, почему это важно, представьте себе стажера, которому вы показываете: “вот сюда нажми, вот тут проверь, а теперь введи данные в эту форму”. Именно так работает vision-based автоматизация (автоматизация на основе визуального восприятия), ИИ-агент видит интерфейс точно так же, как видите его вы, и выполняет действия без локаторов и селекторов.
Для ручного тестирования это означает возможность делегировать рутинные сценарии агенту, особенно в устаревших системах, декстоп приложениях, где классическая автоматизация через Selenium попросту невозможна или очень сложная. Для автоматизации перспективы ещё интереснее, потому что тесты перестают ломаться при каждом изменении. Пока это скорее дополнение к привычным фреймворкам, но направление, как я вижу идет в сторону цифровых тестировщиков.
Ссылка на релиз https://www.anthropic.com/news/acquires-vercept
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🤔11🔥4❤2
‼️📣Бесплатный вебинар по тестированию ИИ систем, инструменты, процессы, критерии качества
📆Дата: 5 марта 2026 г., 19:00 (Europe/Moscow)
На этом вебинаре мы разберем, какие инструменты и фреймворки помогают оценивать качество ИИ-систем на практике, какие метрики и критерии действительно важны, от точности и полноты до устойчивости и безопасности, и как выстроить процесс, который учитывает недетерминированную природу моделей.
Зарегистрироваться на вебинар можно по ссылке: https://eval-ai.com/webinar/testirovanie-ii-sistem-instrumenty-protsessy-kriterii-kachestva
📆Дата: 5 марта 2026 г., 19:00 (Europe/Moscow)
На этом вебинаре мы разберем, какие инструменты и фреймворки помогают оценивать качество ИИ-систем на практике, какие метрики и критерии действительно важны, от точности и полноты до устойчивости и безопасности, и как выстроить процесс, который учитывает недетерминированную природу моделей.
Зарегистрироваться на вебинар можно по ссылке: https://eval-ai.com/webinar/testirovanie-ii-sistem-instrumenty-protsessy-kriterii-kachestva
🔥10❤4
Итак пару недель я уже ковыряюсь с проектами по автоматизации тестирования с целью получить наиболее эффективное ИИ решение для автоматизации тестов и вот что из этого пока вышло:
1. На первом месте пока Claude code с системой skills + mcp chromium от playwright. Очень удобно с точки зрения работы. Каждый созданный skill отвечает за какую то часть процесса автоматизации тестирования и с учетом хорошей интеграции Claude code с MCP playwright, тест пишется на ходу в открытом браузере, где Claude задает автоматом правильные вопросы
2. На втором openClaw/nanoClaw с аналогичной конструкцией, работающий прям на сервере с самом проекте автотестов, в целом как я уже писал ранее это хороший улучшенный вариант того же Claude Code, но который более самостоятельный в принятии решения. Все бы хорошо, но есть пару минусов которые я все же выявил. Первое - это токены, он их есть очень много и платить надо прилично за его работу (если использовать подписку Claude Code то либо быстро упирается в лимиты либо еще можно словить бан от Anthropic). Второе - долгая настройка, то есть нужно потратить время и деньги обучить его работе с проектом,но опять же без оптимизации работы с токенами это может вылиться в копеечку.
3. Собственный самописный ИИ агента для генерации тестов. Я попробовал это сделать, написать своего агента, который анализирует структуру проекта, определяет правила написания автотестов и может подключаться к любой модели, включая локальные, но пока не добился такого же качества как от делает Claude code из коробки. Возможно все таки модель играет роль, так я запускаю его на Gemini 2.5 Pro. В общем пока неудовлетворительно, но я работаю над этим.
В общем пока Claude code выигрывает в гонке интеллектов для помощи тестировщику, еще планирую потестить Claude code на сложном C# проекте автоматизации тестирования, если все будет ок, то запишу видео по настройке скиллов для создания своего ИИ агента.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
1. На первом месте пока Claude code с системой skills + mcp chromium от playwright. Очень удобно с точки зрения работы. Каждый созданный skill отвечает за какую то часть процесса автоматизации тестирования и с учетом хорошей интеграции Claude code с MCP playwright, тест пишется на ходу в открытом браузере, где Claude задает автоматом правильные вопросы
2. На втором openClaw/nanoClaw с аналогичной конструкцией, работающий прям на сервере с самом проекте автотестов, в целом как я уже писал ранее это хороший улучшенный вариант того же Claude Code, но который более самостоятельный в принятии решения. Все бы хорошо, но есть пару минусов которые я все же выявил. Первое - это токены, он их есть очень много и платить надо прилично за его работу (если использовать подписку Claude Code то либо быстро упирается в лимиты либо еще можно словить бан от Anthropic). Второе - долгая настройка, то есть нужно потратить время и деньги обучить его работе с проектом,но опять же без оптимизации работы с токенами это может вылиться в копеечку.
3. Собственный самописный ИИ агента для генерации тестов. Я попробовал это сделать, написать своего агента, который анализирует структуру проекта, определяет правила написания автотестов и может подключаться к любой модели, включая локальные, но пока не добился такого же качества как от делает Claude code из коробки. Возможно все таки модель играет роль, так я запускаю его на Gemini 2.5 Pro. В общем пока неудовлетворительно, но я работаю над этим.
В общем пока Claude code выигрывает в гонке интеллектов для помощи тестировщику, еще планирую потестить Claude code на сложном C# проекте автоматизации тестирования, если все будет ок, то запишу видео по настройке скиллов для создания своего ИИ агента.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥13❤6👍2
Всем привет! Собрал 5 ошибок, которые вижу снова и снова, когда команды запускают ИИ систему, прогоняют пару тестов и считают задачу закрытой. А потом на проде все ломается в самый неудобный момент.
Первая ошибка - это бенчмарки вместо оценки на своих задачах. Результат на MMLU бенчмарке ничего не скажет о том, как система работает именно у вас. 85% скор на бенчмарке звучит красиво, но это пустая цифра, если ваш AI делает саммари юридических договоров.
Вторая - это когда измеряют точность, но игнорируют устойчивость. 95% точности ИИ системы выглядит отлично ровно до момента, пока реальные пользователи не начинают формулировать запросы чуть иначе. Небольшие вариации промпта могут полностью сломать систему.
Третья - это отсутствие baseline. Если до деплоя не зафиксировать, как выглядит хороший результат, вы просто не поймёте потом, стала версия 2 лучше или хуже версии 1.
Четвертая ошибка - это тестирование только happy path. Ожидаемые сценарии это минимум, который должны быть по умолчанию. AI-системы реально ломаются на крайних случаях и неожиданном поведении пользователей.
Пятая - это когда evaluation живет только у разработчиков. Разработчики знают, как система устроена, а QA знает, как она ломается. Без QA в процессе оценки вы упускаете самый важный угол зрения.
Всё это решаемо, но только если вы понимаете, что проблема вообще есть.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Первая ошибка - это бенчмарки вместо оценки на своих задачах. Результат на MMLU бенчмарке ничего не скажет о том, как система работает именно у вас. 85% скор на бенчмарке звучит красиво, но это пустая цифра, если ваш AI делает саммари юридических договоров.
Вторая - это когда измеряют точность, но игнорируют устойчивость. 95% точности ИИ системы выглядит отлично ровно до момента, пока реальные пользователи не начинают формулировать запросы чуть иначе. Небольшие вариации промпта могут полностью сломать систему.
Третья - это отсутствие baseline. Если до деплоя не зафиксировать, как выглядит хороший результат, вы просто не поймёте потом, стала версия 2 лучше или хуже версии 1.
Четвертая ошибка - это тестирование только happy path. Ожидаемые сценарии это минимум, который должны быть по умолчанию. AI-системы реально ломаются на крайних случаях и неожиданном поведении пользователей.
Пятая - это когда evaluation живет только у разработчиков. Разработчики знают, как система устроена, а QA знает, как она ломается. Без QA в процессе оценки вы упускаете самый важный угол зрения.
Всё это решаемо, но только если вы понимаете, что проблема вообще есть.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥9
Сегодня прошел вебинар на тему оценки и тестирования ИИ систем, где мы разобрали какие инструменты и фреймворки помогают оценивать качество ИИ-систем на практике, какие метрики и критерии действительно важны, от точности и полноты до устойчивости и безопасности, и как выстроить процесс, который учитывает недетерминированную природу моделей.
Запись вебинара доступна по ссылке: https://eval-ai.com/webinar/testirovanie-ii-sistem-instrumenty-protsessy-kriterii-kachestva
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Запись вебинара доступна по ссылке: https://eval-ai.com/webinar/testirovanie-ii-sistem-instrumenty-protsessy-kriterii-kachestva
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥17❤4