Всем привет!

Сегодня разберем почему знания Python критически важны для оценки AI моделей, область, где без навыков понимания Python будет сложно.

Python - это основа процессов оценки:
Python позволяет реализовать пользовательские метрики под специфику задачи. Готовые метрики часто есть в библиотеках, но они не всегда могут быть применимы в лоб для оценки AI.
Кроме того, обработка результатов требует парсинг ответов AI модели, сравнение с эталонными данными, агрегацию оценок по различным критериям. Все это сложно без понимания того, как работает Python.

Например, автоматические метрики требуют понимания их реализации. Многие метрики имеют нюансы в использовании, которые видны только через код.
LLM-as-a-Judge подходы требуют написания промптов для оценки, парсинг структурированных ответов от модели-судьи, обработку случаев когда модель возвращает некорректный формат.

Кроме того, важно уметь читать документацию. Официальная документация многих инструментов, например, HuggingFace, DeepEval, GitHub репозитории кастомных метрик содержат различные детали, которые нужно учитывать при использовании.

Поэтому если вы еще не изучали python, я советую начать.

Вот пару беспалатных курсов, которые я могу порекомендовать

Короткий курс по Python с deepleaening.ai

Бесплатный курс на youtube (по которому я учился)

А еще с 08.09 стартует мой курс по оценке качества работы AI, там тоже я опционально дам небольшой блок по Python.

Если вы еще не записались, то самое время это сделать тут , количество мест ограничено.


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI

Сегодня разберем различные архитектуры AI агентов. Понимание архитектурных особенностей критически важно для evaluation, поскольку каждая архитектура создает свои специфические точки контроля качества.

ReAct (Reasoning and Acting)
ReAct представляет собой одну из наиболее популярных современных архитектур, где агент чередует фазы рассуждения (Reasoning) и действия (Acting). Ключевая идея заключается в том, что агент на каждом шаге анализирует текущую ситуацию, принимает обоснованное решение о следующем действии, выполняет его и анализирует полученные результаты.

Plan-and-Execute
Архитектура Plan-and-Execute четко разделяет фазы планирования и исполнения. Сначала агент анализирует поставленную задачу и создает подробный план действий, включающий все необходимые шаги и их последовательность. Затем агент переходит к фазе исполнения, последовательно выполняя запланированные действия.

Toolformer
Toolformer представляет собой архитектуру, где модель обучается самостоятельно определять, когда и какие инструменты использовать. Ключевая особенность заключается в том, что модель учится встраивать вызовы инструментов непосредственно в естественный текст, делая процесс использования инструментов более органичным и гибким.

AutoGPT
AutoGPT представляет архитектуру автономного агента, который способен самостоятельно ставить подцели, планировать действия и выполнять их без постоянного участия человека.

Multi-agent архитектуры
Существует несколько основных паттернов такого Multi-agent взаимодействия:

Debate (Дебаты): Несколько агентов представляют разные точки зрения на проблему и спорят друг с другом, что помогает выявить слабые места в рассуждениях и найти более обоснованные решения.

Cooperation (Сотрудничество): Агенты сотрудничают, разделяя задачи по своим специализациям. Каждый агент выполняет ту часть работы, в которой он наиболее компетентен, а результаты объединяются для достижения цели.


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI

Сегодня поговорим о том, почему оценка качества 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 связано только с ChatGPT и подобными LLM. Но AI включает десятки направлений, и LLM лишь один из слоев.

Направления AI:

Машинное обучение (ML)
Алгоритмы, которые учатся на данных: классификация, регрессия, деревья решений, ансамбли. Применяются в прогнозах, рекомендациях, анализе рисков.

Глубокое обучение (DL)
Нейросети, которые сделали возможным компьютерное зрение, распознавание речи и большие языковые модели.

Компьютерное зрение (CV)
Системы, которые «видят» и понимают изображения: от распознавания лиц до диагностики по снимкам.

Обработка естественного языка (NLP)
Переводчики, чат-боты, поиск, анализ тональности текста, все, что связано с пониманием и генерацией языка.

Генеративный AI
Модели, создающие тексты, картинки, музыку, видео и код. ChatGPT, MidJourney, Stable Diffusion относятся сюда.

AI в робототехнике
Алгоритмы для автономных дронов, автомобилей и промышленных роботов, которые принимают решения в реальном мире.

Важно понимать, что AI не равно только ChatGPT. Это целый спектр технологий от аналитических моделей до автономных систем, которые меняют наше взаимодействие с цифровым и физическим миром.

И на моем курсе по тестированию и оценке AI, который стартует уже 08.09, мы будем разибрать, как выполнять оценку практически всех направлений. кроме робототехники. Так что если вы еще не успели записаться на курс, то сейчас самое время это сделать по ссылке https://eval-ai.com


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI

Сегодня разберем, как оценивают AI-системы для генерации изображений.

Если с текстовыми моделями все более менее понятно, можно замерить точность ответа, проанализировать набор слов во фразе, изучить семантику и так далее, то вот с картинками всё сложнее, потому что не всегда понятно как измерить «красоту», «реализм» или «креативность»?

Представим, что мы дали промпт: «Кот в космическом скафандре на Марсе» и получили картинку.

Ключевые подходы:

Автоматические метрики
⁃ FID (Fréchet Inception Distance). Мы сравниваем распределение признаков изображения с реальными фото. Если картинка выглядит «живой» и не содержит серьезных искажений, FID будет низким. Это значит, картинка приближена к реальности.

⁃ IS (Inception Score). Модель ИИ «смотрит» на изображение и решает, насколько оно четкое и однозначно распознается.
Пример: если на картинке действительно виден кот в скафандре, и нейросеть уверенно определяет это как «кошка», а не путает с «собака» или «инопланетянин», то IS будет высоким. Если же изображение размытое и непонятно, что балл ниже.

⁃ CLIPScore. Сравнивает текст запроса с изображением. Если «кот в скафандре» реально совпадает с тем, что видим, то метрика высокая. Если скафандра нет, а модель нарисовала просто кота на красном фоне, то CLIPScore будет низким.

Human evaluation
Часто метрики так или иначе не отражают субъективное восприятие. Поэтому экспертная оценка по прежнему остается важной при оценкие генерации картинок по критериям:
⁃ реализм
⁃ креативность
⁃ соответствие запросу.

Специализированные тесты
Например, проверка на bias (гендерные или культурные стереотипы), устойчивость к токсичным промптам и способность работать с редкими объектами.

Главная проблема: автоматические метрики не всегда совпадают с человеческим восприятием.

Поэтому сегодня активно развивается гибридный подход FID/CLIPScore + human evaluation, который позволяет более точно оценить работу ИИ для генерации картинок.



Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI

Я часто упониманию DeepEval и RAGAS как основные оперсорс фреймворки, которые я использую в своей работе, но сегодня я хочу написать по альтернативные решения, которые есть на рынке и которые тоже моэно использовать для оценки AI решений.

Evidently.ai - оперсорс Python фреймворк для оценки, тестирования и мониторинга ML- и LLM-систем; включает множество встроенных метрик и может использоваться как для экспериментов и оценки, так и для продакшн-мониторинга качества работы AI решений.

Arize Phoenix - оперсорс библиотека для мониторинга за AI приложениями, трассировки и интерактивной оценки.

Galileo AI - автоматизированный инструмент (включая оперсорс компоненты) для оценки генеративных AI систем с акцентом на accuracy, safety, RAG‑метрики, обнаружение галлюцинаций и возможность интеграции в CI/CD процессы

Promptfoo - оперсорс CLI и библиотека для оценки AI приложений, позволяющая строить надежные промпты, выполнять red teaming, сравнивать модели и интегрировать проверки в CI/CD.

LangTest - оперсорс фреймворк для оценки RAG‑систем, включающий генерацию и выполнение тестов, измерение надёжности и точности Retrieval‑Augmented Generation через интеграцию с LlamaIndex и визуализацией результатов.


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI

Сегодня поговорим о Robustness testing через призму метаморфического тестирования.

Немного разберем, что такое метаморфическое тестирование. Это метод тестирования программного обеспечения, при котором проверка корректности основана не на самих результатах, а на метаморфических отношениях - ожидаемых зависимостях между входами и выходами программы.

Проще говоря:
Мы задаём системе вход X и получаем результат Y.
Затем трансформируем вход (например, перефразируем запрос, добавляем шум, изменяем порядок элементов) и получаем новый результат Y1.
Вместо того чтобы знать точное значение Y1, мы проверяем, что оно связано с Y через заранее определённое правило (метаморфизм).

Теперь вернемся к проверке устойчивости AI к перефразировкам и шуму.

Смысл простой:
Если модель правильно отвечает на вопрос «Какая столица у Франции?», то и на все перефразировки («Франция столица какого города?», «Столичный город Франции?») она должна давать тот же корректный ответ — «Париж».

Это и есть метаморфизм: изменяя входные данные (перефраз, шум, опечатка), мы ожидаем, что результат должен остаться инвариантным или близко похожим к оригинальному (наш Y1).

Как формировать датасеты для такого тестирования:
⁃ Берем базовый набор запросов с известным правильным ответом.
⁃ Автоматически генерируем перефразировки (через LLM, шаблоны или вручную).
⁃ Добавляем «шумные» варианты: опечатки, случайные символы, жаргон.

Что это дает?
Мы строим не просто тестовый набор, а семейства запросов, которые проверяют:
1. Сохраняет ли модель правильность при изменении формы вопроса?
2. Насколько она устойчива к «грязным» данным?
3. Есть ли случаи, где она внезапно «ломается» и начинает галлюцинировать?

По сути, Robustness testing - это частный случай метаморфического тестирования. Мы заранее знаем правильный ответ и проверяем, что он не изменяется серьезно при трансформации запроса.


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI

Когда мы говорим об оценке AI, то часто думаем о метриках точности или качества. Но есть еще одна не менее важная грань, это объяснимость (Explainability) и корректность рассуждений (Correctness of reasoning).

Современные модели умеют выдавать ответы, которые выглядят правильно. Проблема в том, что иногда они (модели) угадывают, а иногда придумывают объяснения постфактум. Для критичных областей этого мало, потому что нужен не только правильный ответ, но и понятная логика за ним.

Немного по терминам:
Explainability - насколько прозрачно и понятно человеку решение модели.
Correctness of Reasoning - насколько корректна сама логическая цепочка рассуждений.

Что именно мы оцениваем?
⁃ Насколько объяснение модели прозрачно и понятно человеку.
⁃ Насколько reasoning действительно отражает внутренние шаги, а не случайный текст «для красоты».

Как это оценивать:
⁃ Сравнивать объяснения на близких примерах: если ответы одинаковые, логика тоже должна совпадать (вспоминаем прошлый пост про Метаморфические тесты).
⁃ Проверять, действительно ли объяснение модели опирается на внутренние признаки модели, а не выдумано постфактум (Faithfulness tests).
⁃ Использовать датасеты, где вместе с ответами зафиксированы правильные рассуждения, например, Chain-of-Thought Hub или XAI datasets
⁃ Подключать экспертов, потому что человек быстро замечает, если объяснение звучит убедительно, но не имеет отношения к задаче.

Простой пример:
AI рекомендует фильм и поясняет: «Мы выбрали его, потому что вы смотрели комедии с этим актёром». Если объяснение совпадает с логикой работы алгоритма — reasoning корректен. Но если в реальности рекомендация основана на рекламных приоритетах, а «актёр» просто добавлен для убедительности — reasoning рушится.

По сути, explainability evaluation - это проверка доверия, можно ли положиться на логику модели так же, как на её финальный ответ.


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI

Сегодня про Tool-augmented evaluation, а именно как понимать, справляется ли модель с инструментами (tools) (калькуляторы, API, БД), когда важен не только ответ, но и как он получен.

Представьте запрос: “Посчитай счёт 860 ₽ + 15% чаевых”. Сильное ИИ решение планирует шаги, вызывает калькулятор, получает 989 и возвращает итог. Слабое ИИ решение считает в голове, складывает 860 + 15, пишет 875, что выглядит уверенно, но выбор инструмента и интерпретация задачи провалены.

Оценка здесь - это не просто сверка числа. Мы смотрим, приняла ли модель правильное решение звать инструмент, корректно ли передала аргументы, не исказила ли результат и не потеряла ли шаги по дороге. Тот же запрос, переформулированный как “начисли 15% на 860” или “добавь 15% чаевых к 860”, должен приводить к той же последовательности действий и тому же результату - это проверка устойчивости и согласованности.

Где всё это видно на практике? В системах, которые собирают трейсы. Там по шагам фиксируются: намерение (например, нужен такой-то инструмент для ответа), сам вызов (имя инструмента и аргументы), ответ инструмента (сырой результат), интерпретация ответа моделью и финальный вывод. По таким трейсам легко заметить типовые сбои, например, инструмент не вызван, вызван не тот, аргументы перепутаны, ответ пришёл верный, но модель неверно его округлила или подставила не туда.

Для работы с трейсами используются трейсинг/обсервабилити-решения уровня приложения (например, LangSmith, Langfuse, Arize Phoenix, OpenLLMetry на базе OpenTelemetry): они как раз дают полный лог цепочки внутри ИИ агента, какие шаги были, в каком порядке, с какими параметрами и что на каждом шаге вернулось. Именно по таким следам и оценивается зрелость ИИ решения: планирование, выбор, корректное применение и честная интерпретация результата.


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI

Сегодня хочу поделиться мыслями о недавнем исследовании по оценке reasoning у LLM через Bayesian inference.

Авторы предлагают рассматривать работу модели через призму байесовского подхода: модель должна аккуратно обновлять свои вероятности, используемые для генерации ответа, при изменении входного контекста. Идея в том, что LLM может галлюцинировать и менять результаты в зависимости от порядка примеров или кусков текста (chunks).

По сути, это ещё один угол зрения на процесс генерации: насколько модель устойчива к изменению порядка фактов и насколько предсказуемо обновляет свои ответы.

Но есть нюанс: такая метрика оценивает не качество финального результата, а сам процесс рассуждений. Чтобы проверить её на практике, нужно уметь вручную менять порядок контекста и отслеживать, насколько сильно меняется ответ. В большинстве случаев итоговая релевантность останется прежней, поэтому ценность метрики может быть ограниченной, особенно если у нас уже используется reranking и порядок chunk’ов фиксирован.

Кстати, исследование проводилось на GPT-3, и пока не очевидно, насколько та же проблема проявляется в более современных моделях.

Как можно тестировать в таком духе:
1. Задаем один и тот же вопрос, но меняем порядок документов. Смотрим, насколько стабилен ответ. Байесовский агент должен выдавать одинаковый результат.
2. Добавляем документы по одному: сначала А документы → спрашиваем, потом А+B документы → спрашиваем, потом А+B+C документы. Байесовский ИИ агент в этом случае будет аккуратно накапливать знания, а не перескакивать между разными интерпретациями.

В итоге скажу, что это не метрика качества ответа, а скорее инструмент для проверки предсказуемости reasoning. Полезно для исследований, но в реальных проектах нужно взвешивать трудозатраты и реальную пользу.

Ссылка на исследование


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Сегодня хочу обсудить интересную тему: Self-evaluation у моделей.

Обычно мы говорим о внешней оценке, например, метрики, бенчмарки, human evaluation. Но есть другой подход, когда сама модель оценивает свои ответы.

Что это значит? После того как LLM генерирует результат, ее можно попросить: “Оцени свой ответ по шкале от 1 до 5” или “Насколько он соответствует фактам?”. Иногда используют отдельную модель-оценщик, иногда ту же самую.

Зачем это нужно:
- Для фильтрации галлюцинаций (модель сама помечает сомнительные ответы).
- Для повышения надежности в пайплайнах, если уверенность низкая, то можно подключить дополнительные проверки или переспросить пользователя.
- Для обучения, например, self-evaluation часто используют в reinforcement learning, когда модель сама сигнализирует о качестве результата.

Но у подхода есть и ограничения. Модель может быть чрезмерно уверенной в галлюцинациях или, наоборот, занижать качество ответа.

Пример:
Задаём вопрос: “Кто написал Преступление и наказание?”. AI отвечает: “Фёдор Достоевский”. Потом сама добавляет: “Уверенность: 95%”. Если AI ошибcя, но все равно написал 95%, это сигнал о проблеме с self-evaluation.

Сегодня self-evaluation рассматривается как часть будущих саморефлексивных AI-систем, где модель не только выдает ответы, но и умеет честно судить о качестве собственной работы.


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Сегодня поговорим о том, как использовать метаморфические отношения (Metamorphic Relations) для оценки AI-решений.

Если у вас возникал вопрос, как именно наполнять датасет для оценки AI решения, как составлять правильно покрытие, то именно метаморфические отношения частично могут помочь вам в этом.

Когда мы формируем датасет для тестирования, важно не только проверять базовые запросы, но и смотреть, как модель ведет себя при изменении формулировки запроса. Метаморфическое тестирование помогает именно в этом, мы задаем один и тот же запрос в разных вариациях и проверяем, что результат остаётся корректным.

Причем метаморфические отношения могут использовать не только для оценки генерации текста, но и картинок, видео и аудио.

Какие отношения обычно используют:

MR1: Замена синонимов. Проверка того, умеет ли модель обрабатывать синонимы и возвращать релевантный результат.
MR2: Перефразировка. Оценка способности модели корректно отвечать на перефразированные (идентично изменненные) входные данные.
MR3: Добавление контекста. Проверка влияния дополнительного контекста на точность извлечения и генерации.
MR4: Негация. Оценка того, как модель справляется с отрицанием в запросах.
MR5: Сдвиг фокуса. Проверка, удерживает ли модель правильный фокус в запросе и не теряет ли целевую информацию.
MR6: Составной вопрос. Оценка качества работы с составными вопросами и способностью давать точные ответы на все части.
MR7: Двусмысленность. Проверка, может ли модель правильно разрешать неоднозначность и выбирать верную сущность.
MR8: Частичная информация. Оценка способности модели работать с урезанными запросами и всё равно выдавать точный ответ.

Суть в том, что мы создаём семейства запросов, где правильный ответ известен, и проверяем, остаётся ли он инвариантным при трансформациях. Это позволяет оценить не только фактологическую точность, но и реальную устойчивость модели к вариативности данных.


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Сегодня будет краткий разбор типов атак на AI, которые часто встречаются в red-teaming и security-оценке моделей. По каждому типу давайте разберем, что это и почему важно знать.

HEX - ввод данных в шестнадцатеричной форме (hex). Часто используется для того, чтобы замаскировать полезную нагрузку или обойти простые фильтры парсинга: модель может не распознать смысл запроса и вести себя непредсказуемо.

ROT13 - простая подстановка символов (сдвиг на 13). Применяется как трюк, чтобы спрятать запрещенный текст от прямых фильтров.

BASE64 - кодирование полезной нагрузки в base64. Популярно у атакующих, текст скрыт, но при декодировании может появиться вредоносная инструкция.

LEETSPEAK - замена букв цифрами/символами (h4x0r-язык). Используется для обхода словарных фильтров и тестирования надежности токенайзера.

PROMPT_INJECTION - внедрение инструкций в контекст запроса, чтобы заставить модель игнорировать ограничения или выполнять нежелательные команды. Критичная угроза для LLM-агентов.

MATH_PROBLEM - специально составленные задачки или подсчёты, которые заставляют модель ошибаться (или раскрыть промежуточные рассуждения).

MULTILINGUAL - атаки через переключение языка или смешение языков: цель - сбить модель с толку, вызвать некорректные ответы или обойти фильтры.

JAILBREAK - попытки вытащить модель из ограничений, обойти контент-политики и заставить выполнять запрещённые инструкции. Это одна из самых опасных категорий.

Для нас, как для тестировщиков, эти атаки фактически являются набором тестовых сценариев, через которые мы проверяем уязвимость модели. Задача тестировщика - это не просто найти, где модель ломается, а системно собрать такие кейсы в тестовый набор и превратить их в повторяемые проверки.

П.С. Я не рекомендую тестировать внешнии ИИ системы, разработанные не вашей компанией, данными типами атак во избежание негативных последствий.


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Сегодня разберем тему проверки надежности Retrieval в RAG-системах.

Когда мы тестируем RAG, часто фокус уходит только на генерацию. Мы проверяем, насколько правильны ответы от AI Но часто источник ошибок - это retrieval. Даже если генерация работает идеально, слабый поиск по контексту ломает итоговый ответ.

Что такое RAG и retrieval разбирал тут

Что проверять на надежность:
⁃ Перестановки документов. Если мы меняем порядок выдачи, результат должен оставаться тем же. Если ответ внезапно меняется, значит, модель слишком чувствительна к ранжированию.
⁃ Удаление релевантного документа. Проверяем, умеет ли система честно сказать не знаю или начинает галлюцинировать.
⁃ Шум в источниках. Добавляем лишние тексты, нерелевантные документы. Надежная AI RAG система не должна отвлекаться на них и терять фокус.
⁃ Смешение доменов. Проверяем, не ломается ли retrieval, если рядом с профильными документами появляются материалы из другой области.

Важно: надежный retrieval это стабильная генерация. Если при малейших изменениях порядок фактов или шум сбивают модель, значит RAG небезопасен для реальных сценариев.

По сути, тестирование надежности retrieval - это метаморфическое тестирование на уровне источников, где мы меняем контекст, но правильный ответ должен оставаться тем же.


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Почему современные AI модели стали такими умными и что лежит у них под капотом.

За последние 10 лет произошёл прорыв, от простых нейросетей мы пришли к системам, которые понимают язык, видят изображения, создают код и управляют роботами. Основной секрет работы данных AI моделей не только в данных, но и в архитектуре глубокого обучения, каждая из которых внесла свой вклад.

Итак, какие на текущий момент есть продвинутые и популярные виды архитектур для обучения моделей?

CNN (Convolutional Neural Networks).
Именно эти алгоритмы научили машины полноценно видеть. Фильтры извлекают сначала простые признаки (линии, углы), а потом все более сложные структуры. Без CNN не было бы компьютерного зрения и распознавания образов.

RNN / LSTM / GRU.
Эти сети добавили память в модели. Они обрабатывают последовательности и учитывают контекст. Благодаря им стало возможным распознавание речи и первые системы машинного перевода.

Transformers.
Главный переломный момент. Attention-механизм позволяет учитывать все связи между словами или элементами сразу. Именно эта архитектура дала жизнь LLM вроде GPT и сделала возможным масштабирование до миллиардов параметров.

GNN (Graph Neural Networks).
Дали возможность работать со сложными структурами, где важны связи между объектами. Это биоинформатика, социальные сети, рекомендательные системы.

Diffusion Models.
Перевернули генерацию изображений. Идея проста, модель учится восстанавливать данные из шума, шаг за шагом. Так появились Stable Diffusion и другие генеративные модели, которые создают реалистичные картинки и видео.

По сути, то, что мы называем умными моделями, LLM - это просто результат накопления архитектурных идей. CNN дали зрение, RNN память, трансформеры - масштабируемое внимание, GNN - понимание структур, diffusion - способность генерировать. Все это вместе и создало современные AI системы, которые мы видим сегодня.


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Всем привет!

Недавно Google выпустил Chrome DevTools MCP сервер! И теперь данное решение может усилить автоматизацию тестирования веб-приложений с участием AI или агентов.

До появления MCP агенты могли генерировать код автотестов, но не видеть, как он ведет себя при запуске в браузере. Chrome DevTools MCP сервер меняет это. Он дает агентам возможность контролировать браузер, инспектировать исполнение, читать логи, трассировать производительность и даже эмулировать поведение пользователя.

Для тестировщика это открывает новые возможности автоматизации. Разработанный агент может не просто предсказать, что исправить, но сам проверить, работает ли исправление в живом браузере.

Примеры сценариев автоматизации, которые становятся реалистичными с помощью MCP:
• После генерации кода агент запускает страницу, выполняет навигацию, клики, ввод данных и следит, что элементы отображаются правильно.
• Агент записывает трассировку производительности (performance trace), анализирует её и предлагает улучшения для снижения задержек загрузки.
• Агент проверяет консоль ошибок и сетевые запросы, например, ловит CORS-проблемы или сбои в API, и возвращает отчёт с рекомендациями.
• Агент может применять визуальные исправления, инспектировать CSS, структуру DOM, изменять стили и проверять, устранилась ли проблема визуально.

С MCP тестовые сценарии становятся end-to-end на уровне браузера, без необходимости вручную запускать Selenium или Puppeteer. Агент сам становится тестовым драйвером и инспектором.

Ссылка MCP сервер


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Всем привет!

Нашел очень классный FAQ по evaluation, где есть ответы на большое количество вопросов, связанных с оценкой AI.

Кто интересуется оценкой AI решений, рекомендую к прочтению.


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Сегодня поговорим о том, что такое bias в AI и почему его важно оценивать.

Bias - это систематическая предвзятость в работе модели. Она возникает из-за того, что данные, на которых обучалась модель, не идеально отражают реальность. Если в датасете больше примеров одного типа, чем другого, модель начинает воспроизводить этот перекос.

Например:
⁃ В рекомендательной системе фильмы определенного жанра могут показываться чаще, потому что таких данных было больше.
⁃В NLP модели ассоциации программист - мужчина и медсестра - женщина закрепляются из-за перекоса в текстах.
⁃ В медицинских AI датасет может быть собран в одном регионе, и тогда модель хуже работает для других групп пациентов.

Почему это важно для тестировщика и исследователя?
Если bias не учитывать, система будет несправедливой и небезопасной. В бизнесе это может привести к дискриминации пользователей, в медицине, к риску для жизни, в образовании, к неправильным рекомендациям и так далее.

Оценка bias - это проверка, насколько модель одинаково хорошо работает для разных групп, ситуаций и формулировок. Для этого создаются специальные тестовые датасеты, где балансируются примеры, используются крайние и граничные кейсы и проверяется, не дает ли модель систематически искаженных ответов.

Bias также может проявляться при использование LLM как оценщика для другой модели, потому что по-моему опыту, если просить в лоб LLM оценить какую-то метрику, то в большинтсве случаев LLM будет завышать показатель, так как будет стараться быть полезной.

По сути, bias-тестирование не про метрики точности, а про справедливость, надежность и непредвзятость модели. Ведь AI-система, которая воспроизводит социальные перекосы, не критична к себе и генерируемым ответам, может быть даже опаснее модели с просто низкой accuracy.


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

В оценке AI часто может потребоваться эталон, на который можно опираться при проверках. Эту роль играет golden датасет, поэтому сегодня хочу разобрать, как он работает и зачем он нужен.

Golden датасет - это эталонный набор данных (например, пользовательских запросов) с заранее проверенными правильными ответами (expected answer).

Зачем он нужен:

Проверка регрессий. Каждый новый билд ИИ решения сравнивается с golden датасетом. Если ответы от AI изменились там, где меняться не должны — значит, появилась ошибка.

Стабильная точка контроля. Golden набор фиксирует, что именно считается правильным результатом, и убирает двусмысленность.

Автоматизация. Такой датасет легко подключается в CI/CD, где тесты гоняются автоматически при каждом изменении, и команда сразу видит, где что-то пошло не так.

Как правильно его спроектировать:
1. Подбирать репрезентативные кейсы. Сценарии, которые отражают ключевые требования бизнеса или реальные кейсы использования вашего AI решения на проде.
2. Добавлять edge cases. Golden датасет отличное место для фиксирования багов, которые однажды нашли и больше не хотят ловить в проде.
3. Фиксировать корректные ответы. Каждому тесту нужен эталонный результат, согласованный командой или экспертами вашей компании.
4. Поддерживать версионность. Golden датасет должен жить вместе с системой и если требования меняются, набор также должен обновляться.
5. Встраивать в пайплайн. Проверка golden набора должна быть обязательной частью CI/CD, чтобы любая регрессия ловилась до релиза новых изменений, например, при изменении системного промпта, источников или кода ИИ решения в целом.

По сути, golden датасет должен говорить нам о том, что новые версии AI решения не ломают логику работы. Это та самая контрольная работа, которую AI продукт сдает перед каждым релизом.

Для сравнения оптимально использовать не точное сравнение (exact match), так как мы знаем AI может генерировать разные стили ответов, а семантическое сравнение или сравнение по ключевым словам в ответе.


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Когда в системе не один AI агент, а несколько, стандартные метрики вроде accuracy уже недостаточны. Нужно оценивать взаимодействие, координацию, коммуникацию и устойчивость всей группы AI агентов. Ниже я привел ряд метрик, которые помогут более глубоко понять качество работы multi-agent AI системы:

Ключевые метрики:
Task Completion Rate - доля задач, которые команда агентов успешно завершила. Это базовый индикатор эффективности системы.
Communication Overhead / Efficiency - сколько сообщений отправлено, насколько они релевантны, сколько «шумовых» коммуникаций. Чем меньше лишних сообщений, тем лучше.
Coordination Efficiency / Synchronization измеряет, как скоординировано агенты действуют, например, минимальное время ожидания, отсутствие конфликтов, отсутствие дублирующих шагов.
Robustness / Fault Tolerance как ведёт себя система, если один агент случайно дает неправильный ответ или недоступен. Надежная система должна уметь обходить и решать такие ситуации без влияния на пользователя.
Consensus / Agreement Rate используется, если AI агенты должны прийти к общему решению, измеряем, как часто их ответы совпадают или насколько они близки.

Как внедрять оценку в multi-agent AI системах
1. Логируйте всё взаимодействие. Нужны детализированные логи трейсов: кто кому что сказал, какие ответы, какие шаги, задержки между AI агентами.
2. Оценивайте планы и сообщения. Можно применять экспертную проверку или отдельный LLM-оценщик, чтобы оценить, насколько логично и уместно сообщение или план последовательности действий ИИ агентов.
3. Стресс-сценарии. Запускайте систему с выключением агента, шумом в сообщениях, перегрузкой и смотрите, как меняются метрики.
4. Сравнение с baseline. Запустите одиночного агента или простые конфигурации с очень упрощённой логикой взаимодействия, чтобы понимать, что будет вашей отправной точкой и дальшей сравнивайте усложнение multi-agent системы с baseline.
5. Используйте стандарты и бенчмарки. Например, MultiAgentBench фреймворк, который тестирует как кооперацию, так и соревнование агентов.

Как итог хочу сказать, что по сути при оценке multi-agent AI систем ключевым становится взаимодействие. Важнее не то, насколько силен каждый ИИ агент сам по себе, а насколько гармонично они действуют вместе, не конфликтуя и эффективно решая задачи.


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)

Когда мы говорим о Retrieval-Augmented Generation, важно понимать, что RAG - это не просто генерация с векторной базой.
Качество всей системы во многом определяется типом поиска, который используется для извлечения контекста.
Ниже я привел основные подходы, применяемые в современных RAG-системах.

Keyword / Lexical Search (BM25, TF-IDF)
Поиск по совпадению слов и фраз. Быстрый, интерпретируемый, подходит для коротких текстов и небольших корпусов, но не учитывает смысл, синонимы и порядок слов, что приводит к потере релевантности при перефразировках.

Vector (Semantic) Search
И запрос, и документы преобразуются в векторные представления (эмбеддинги), поиск выполняется по смысловой близости. Этот подход лежит в основе современных RAG-реализаций (FAISS, Milvus, Chroma, Pinecone). Позволяет находить контекст по смыслу, но требует больше памяти и вычислительных ресурсов.

Hybrid Search
Комбинированный подход, включает keyword-поиск, который отбирает кандидатов и vector-поиск, который уточняет результаты по смыслу. Используется в большинстве RAG-систем, так как сочетает скорость и качество. Минус - это усложнение пайплайна и необходимость оптимизации весов при объединении результатов.

Graph-based Retrieval (Knowledge Graph RAG)
Поиск по структуре знаний, где данные представлены в виде графа сущностей и связей. Подходит для доменов, где важна точность и проверяемость фактов (медицина, юриспруденция, аналитика). Главная сложность - это построение и поддержка самого графа.

Contextual / Adaptive Retrieval
Поиск, который адаптируется под тип запроса. Например, для аналитических вопросов выбираются длинные документы, для фактологических короткие фрагменты. Требует дополнительной логики или отдельной LLM-модели, которая решает, как искать.

Если смотреть с точки зрения evaluation, то каждый подход к retrieval имеет свой профиль качества. Keyword лучше по стабильности, vector по смысловой точности, hybrid по общей надёжности, graph по фактам, contextual по адаптивности.


Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)