Сегодня будет последний пост в этом году!
И я решил, что если у вас будет много свободного времени и нечем заняться в ближайшие пару недель, то советую посмотреть открытый базовый курс от университета Stanford по трансформерам и большим языковым моделям. 8 лекция кстати посвящена оценки LLM систем.
Ссылка на записи курса https://youtube.com/playlist?list=PLoROMvodv4rOCXd21gf0CF4xr35yINeOy&si=sNh9N0ZR9f79iLcy
Также напоминаю, что через 5 дней заканчивается скидка на новый поток на курсе по оценке и тестированию ИИ, поэтому если еще не записались, самое время это сделать сейчас тут eval-ai.com
Ну и в целом всем желаю праздничного настроения и с наступающим Новым годом!🎄
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
И я решил, что если у вас будет много свободного времени и нечем заняться в ближайшие пару недель, то советую посмотреть открытый базовый курс от университета Stanford по трансформерам и большим языковым моделям. 8 лекция кстати посвящена оценки LLM систем.
Ссылка на записи курса https://youtube.com/playlist?list=PLoROMvodv4rOCXd21gf0CF4xr35yINeOy&si=sNh9N0ZR9f79iLcy
Также напоминаю, что через 5 дней заканчивается скидка на новый поток на курсе по оценке и тестированию ИИ, поэтому если еще не записались, самое время это сделать сейчас тут eval-ai.com
Ну и в целом всем желаю праздничного настроения и с наступающим Новым годом!🎄
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥7👍4❤2
Новогодние праздники у большинства закончились (хотя там где я живу их нет в таком количестве), и я возвращаюсь к вам.
И буквально в начале этого года одно из моих исследований было опубликовано в канадском научном журнале IJMADA, где я предлагаю методологию оценки надежности ИИ агентов через таксономию ошибок и risk-based testing.
Ну и конечно прикладываю ссылку на мою работу, кому интересно почитать
https://zenodo.org/records/18120416
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
И буквально в начале этого года одно из моих исследований было опубликовано в канадском научном журнале IJMADA, где я предлагаю методологию оценки надежности ИИ агентов через таксономию ошибок и risk-based testing.
Ну и конечно прикладываю ссылку на мою работу, кому интересно почитать
https://zenodo.org/records/18120416
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥13👍6
Напомню, что это едиственный полноценный русскоязычный курс по тестированию ИИ, которые охватывает большое количество апспектов работы с ИИ, такие как:
- Оценка моделей ML/DL
- Оценка и тестирование LLM
- Оценка и тестирование RAG систем и AI агентов
- Оценка генерации картинок и видео
- Оценка предвзятости моделей и их безопасность
Курс включает в себя:
1. Теоретические знания (16 часов онлайн лекций в живую)
2. Лекции по практике (более 20 часов дополнительных видео)
3. Домашние задания (в среднем у ученика уходит от 2-8 часов на выполнение домашней работы после каждой лекции)
4. Работу с реальными ИИ системами (для курса подготовлены реальный RAG системы, ИИ агенты, модели OpenAI и Google Gemini)
Если вы думали, но неуспели оставить заявку, задать свои вопросы или просто забыли, то сегодня еще есть возможность присоединиться к группе!
👇Оставить заявку можно на сайте: eval-ai.com или написать мне в ЛС: @al_meshkov
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Тема 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)
🔥8❤2
Немного пятничных мыслей…
В последнее время меня что-то закидало рекламой приложений, который с помощью ИИ могут делать за вас отклики (не буду называть имена, но думаю вы тоже видели).
И я тут подумал, что с другой стороны сидит HR с таким же ИИ, только который отбирает кандидатов. Получается, один ИИ делает отклик, пишет сопроводительное, другой ИИ их читает и оценивает. Люди пока ещё где-то в этой цепочке присутствуют, но кажется что всё меньше.
И как написал мне один подписчик, мы реально движемся к моменту, когда найм превратится в битву двух нейронок.
Так вот вопрос, как думаете , когда ИИ уже будут сам договариваться между собой, а мы просто получим уведомление о собеседовании, или о том что нас взяли?
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
В последнее время меня что-то закидало рекламой приложений, который с помощью ИИ могут делать за вас отклики (не буду называть имена, но думаю вы тоже видели).
И я тут подумал, что с другой стороны сидит HR с таким же ИИ, только который отбирает кандидатов. Получается, один ИИ делает отклик, пишет сопроводительное, другой ИИ их читает и оценивает. Люди пока ещё где-то в этой цепочке присутствуют, но кажется что всё меньше.
И как написал мне один подписчик, мы реально движемся к моменту, когда найм превратится в битву двух нейронок.
Так вот вопрос, как думаете , когда ИИ уже будут сам договариваться между собой, а мы просто получим уведомление о собеседовании, или о том что нас взяли?
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍4😁2💯1