Сегодня поговорим о том, как использовать метаморфические отношения (Metamorphic Relations) для оценки AI-решений.
Если у вас возникал вопрос, как именно наполнять датасет для оценки AI решения, как составлять правильно покрытие, то именно метаморфические отношения частично могут помочь вам в этом.
Когда мы формируем датасет для тестирования, важно не только проверять базовые запросы, но и смотреть, как модель ведет себя при изменении формулировки запроса. Метаморфическое тестирование помогает именно в этом, мы задаем один и тот же запрос в разных вариациях и проверяем, что результат остаётся корректным.
Причем метаморфические отношения могут использовать не только для оценки генерации текста, но и картинок, видео и аудио.
Какие отношения обычно используют:
MR1: Замена синонимов. Проверка того, умеет ли модель обрабатывать синонимы и возвращать релевантный результат.
MR2: Перефразировка. Оценка способности модели корректно отвечать на перефразированные (идентично изменненные) входные данные.
MR3: Добавление контекста. Проверка влияния дополнительного контекста на точность извлечения и генерации.
MR4: Негация. Оценка того, как модель справляется с отрицанием в запросах.
MR5: Сдвиг фокуса. Проверка, удерживает ли модель правильный фокус в запросе и не теряет ли целевую информацию.
MR6: Составной вопрос. Оценка качества работы с составными вопросами и способностью давать точные ответы на все части.
MR7: Двусмысленность. Проверка, может ли модель правильно разрешать неоднозначность и выбирать верную сущность.
MR8: Частичная информация. Оценка способности модели работать с урезанными запросами и всё равно выдавать точный ответ.
Суть в том, что мы создаём семейства запросов, где правильный ответ известен, и проверяем, остаётся ли он инвариантным при трансформациях. Это позволяет оценить не только фактологическую точность, но и реальную устойчивость модели к вариативности данных.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Если у вас возникал вопрос, как именно наполнять датасет для оценки AI решения, как составлять правильно покрытие, то именно метаморфические отношения частично могут помочь вам в этом.
Когда мы формируем датасет для тестирования, важно не только проверять базовые запросы, но и смотреть, как модель ведет себя при изменении формулировки запроса. Метаморфическое тестирование помогает именно в этом, мы задаем один и тот же запрос в разных вариациях и проверяем, что результат остаётся корректным.
Причем метаморфические отношения могут использовать не только для оценки генерации текста, но и картинок, видео и аудио.
Какие отношения обычно используют:
MR1: Замена синонимов. Проверка того, умеет ли модель обрабатывать синонимы и возвращать релевантный результат.
MR2: Перефразировка. Оценка способности модели корректно отвечать на перефразированные (идентично изменненные) входные данные.
MR3: Добавление контекста. Проверка влияния дополнительного контекста на точность извлечения и генерации.
MR4: Негация. Оценка того, как модель справляется с отрицанием в запросах.
MR5: Сдвиг фокуса. Проверка, удерживает ли модель правильный фокус в запросе и не теряет ли целевую информацию.
MR6: Составной вопрос. Оценка качества работы с составными вопросами и способностью давать точные ответы на все части.
MR7: Двусмысленность. Проверка, может ли модель правильно разрешать неоднозначность и выбирать верную сущность.
MR8: Частичная информация. Оценка способности модели работать с урезанными запросами и всё равно выдавать точный ответ.
Суть в том, что мы создаём семейства запросов, где правильный ответ известен, и проверяем, остаётся ли он инвариантным при трансформациях. Это позволяет оценить не только фактологическую точность, но и реальную устойчивость модели к вариативности данных.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍4
Сегодня будет краткий разбор типов атак на 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)
HEX - ввод данных в шестнадцатеричной форме (hex). Часто используется для того, чтобы замаскировать полезную нагрузку или обойти простые фильтры парсинга: модель может не распознать смысл запроса и вести себя непредсказуемо.
ROT13 - простая подстановка символов (сдвиг на 13). Применяется как трюк, чтобы спрятать запрещенный текст от прямых фильтров.
BASE64 - кодирование полезной нагрузки в base64. Популярно у атакующих, текст скрыт, но при декодировании может появиться вредоносная инструкция.
LEETSPEAK - замена букв цифрами/символами (h4x0r-язык). Используется для обхода словарных фильтров и тестирования надежности токенайзера.
PROMPT_INJECTION - внедрение инструкций в контекст запроса, чтобы заставить модель игнорировать ограничения или выполнять нежелательные команды. Критичная угроза для LLM-агентов.
MATH_PROBLEM - специально составленные задачки или подсчёты, которые заставляют модель ошибаться (или раскрыть промежуточные рассуждения).
MULTILINGUAL - атаки через переключение языка или смешение языков: цель - сбить модель с толку, вызвать некорректные ответы или обойти фильтры.
JAILBREAK - попытки вытащить модель из ограничений, обойти контент-политики и заставить выполнять запрещённые инструкции. Это одна из самых опасных категорий.
Для нас, как для тестировщиков, эти атаки фактически являются набором тестовых сценариев, через которые мы проверяем уязвимость модели. Задача тестировщика - это не просто найти, где модель ломается, а системно собрать такие кейсы в тестовый набор и превратить их в повторяемые проверки.
П.С. Я не рекомендую тестировать внешнии ИИ системы, разработанные не вашей компанией, данными типами атак во избежание негативных последствий.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍8🔥4
Сегодня разберем тему проверки надежности Retrieval в RAG-системах.
Когда мы тестируем RAG, часто фокус уходит только на генерацию. Мы проверяем, насколько правильны ответы от AI Но часто источник ошибок - это retrieval. Даже если генерация работает идеально, слабый поиск по контексту ломает итоговый ответ.
Что такое RAG и retrieval разбирал тут
Что проверять на надежность:
⁃ Перестановки документов. Если мы меняем порядок выдачи, результат должен оставаться тем же. Если ответ внезапно меняется, значит, модель слишком чувствительна к ранжированию.
⁃ Удаление релевантного документа. Проверяем, умеет ли система честно сказать не знаю или начинает галлюцинировать.
⁃ Шум в источниках. Добавляем лишние тексты, нерелевантные документы. Надежная AI RAG система не должна отвлекаться на них и терять фокус.
⁃ Смешение доменов. Проверяем, не ломается ли retrieval, если рядом с профильными документами появляются материалы из другой области.
Важно: надежный retrieval это стабильная генерация. Если при малейших изменениях порядок фактов или шум сбивают модель, значит RAG небезопасен для реальных сценариев.
По сути, тестирование надежности retrieval - это метаморфическое тестирование на уровне источников, где мы меняем контекст, но правильный ответ должен оставаться тем же.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Когда мы тестируем RAG, часто фокус уходит только на генерацию. Мы проверяем, насколько правильны ответы от AI Но часто источник ошибок - это retrieval. Даже если генерация работает идеально, слабый поиск по контексту ломает итоговый ответ.
Что такое RAG и retrieval разбирал тут
Что проверять на надежность:
⁃ Перестановки документов. Если мы меняем порядок выдачи, результат должен оставаться тем же. Если ответ внезапно меняется, значит, модель слишком чувствительна к ранжированию.
⁃ Удаление релевантного документа. Проверяем, умеет ли система честно сказать не знаю или начинает галлюцинировать.
⁃ Шум в источниках. Добавляем лишние тексты, нерелевантные документы. Надежная AI RAG система не должна отвлекаться на них и терять фокус.
⁃ Смешение доменов. Проверяем, не ломается ли retrieval, если рядом с профильными документами появляются материалы из другой области.
Важно: надежный retrieval это стабильная генерация. Если при малейших изменениях порядок фактов или шум сбивают модель, значит RAG небезопасен для реальных сценариев.
По сути, тестирование надежности retrieval - это метаморфическое тестирование на уровне источников, где мы меняем контекст, но правильный ответ должен оставаться тем же.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
❤3👍2🔥1
Почему современные 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)
За последние 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)
👍7
Всем привет!
Недавно 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)
Недавно 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)
🔥10👍3❤1
evals-faq.pdf
3.4 MB
Всем привет!
Нашел очень классный FAQ по evaluation, где есть ответы на большое количество вопросов, связанных с оценкой AI.
Кто интересуется оценкой AI решений, рекомендую к прочтению.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Нашел очень классный FAQ по evaluation, где есть ответы на большое количество вопросов, связанных с оценкой AI.
Кто интересуется оценкой AI решений, рекомендую к прочтению.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍7🔥4
Сегодня поговорим о том, что такое bias в AI и почему его важно оценивать.
Bias - это систематическая предвзятость в работе модели. Она возникает из-за того, что данные, на которых обучалась модель, не идеально отражают реальность. Если в датасете больше примеров одного типа, чем другого, модель начинает воспроизводить этот перекос.
Например:
⁃ В рекомендательной системе фильмы определенного жанра могут показываться чаще, потому что таких данных было больше.
⁃В NLP модели ассоциации программист - мужчина и медсестра - женщина закрепляются из-за перекоса в текстах.
⁃ В медицинских AI датасет может быть собран в одном регионе, и тогда модель хуже работает для других групп пациентов.
Почему это важно для тестировщика и исследователя?
Если bias не учитывать, система будет несправедливой и небезопасной. В бизнесе это может привести к дискриминации пользователей, в медицине, к риску для жизни, в образовании, к неправильным рекомендациям и так далее.
Оценка bias - это проверка, насколько модель одинаково хорошо работает для разных групп, ситуаций и формулировок. Для этого создаются специальные тестовые датасеты, где балансируются примеры, используются крайние и граничные кейсы и проверяется, не дает ли модель систематически искаженных ответов.
Bias также может проявляться при использование LLM как оценщика для другой модели, потому что по-моему опыту, если просить в лоб LLM оценить какую-то метрику, то в большинтсве случаев LLM будет завышать показатель, так как будет стараться быть полезной.
По сути, bias-тестирование не про метрики точности, а про справедливость, надежность и непредвзятость модели. Ведь AI-система, которая воспроизводит социальные перекосы, не критична к себе и генерируемым ответам, может быть даже опаснее модели с просто низкой accuracy.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Bias - это систематическая предвзятость в работе модели. Она возникает из-за того, что данные, на которых обучалась модель, не идеально отражают реальность. Если в датасете больше примеров одного типа, чем другого, модель начинает воспроизводить этот перекос.
Например:
⁃ В рекомендательной системе фильмы определенного жанра могут показываться чаще, потому что таких данных было больше.
⁃В NLP модели ассоциации программист - мужчина и медсестра - женщина закрепляются из-за перекоса в текстах.
⁃ В медицинских AI датасет может быть собран в одном регионе, и тогда модель хуже работает для других групп пациентов.
Почему это важно для тестировщика и исследователя?
Если bias не учитывать, система будет несправедливой и небезопасной. В бизнесе это может привести к дискриминации пользователей, в медицине, к риску для жизни, в образовании, к неправильным рекомендациям и так далее.
Оценка bias - это проверка, насколько модель одинаково хорошо работает для разных групп, ситуаций и формулировок. Для этого создаются специальные тестовые датасеты, где балансируются примеры, используются крайние и граничные кейсы и проверяется, не дает ли модель систематически искаженных ответов.
Bias также может проявляться при использование LLM как оценщика для другой модели, потому что по-моему опыту, если просить в лоб LLM оценить какую-то метрику, то в большинтсве случаев LLM будет завышать показатель, так как будет стараться быть полезной.
По сути, bias-тестирование не про метрики точности, а про справедливость, надежность и непредвзятость модели. Ведь AI-система, которая воспроизводит социальные перекосы, не критична к себе и генерируемым ответам, может быть даже опаснее модели с просто низкой accuracy.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍4❤1
В оценке 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)
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)
👍5🔥1
Когда в системе не один 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)
Ключевые метрики:
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)
👍2🔥1
Когда мы говорим о 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)
Качество всей системы во многом определяется типом поиска, который используется для извлечения контекста.
Ниже я привел основные подходы, применяемые в современных 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)
👍2🔥1
Откуда и как брать данные для оценки AI, если вы работаете с генеративными моделями и LLM? Создание эффективного датасета для evaluation требует соблюдения ряда принципов, которые определяют его полезность и надежность.
Ниже я привел ряд критериев, которые помогут правильно подойти к его созданию:
1. Использовать реалистичные сценарии из домена работы AI. Это означает, что тестовые примеры должны максимально точно отражать реальное поведение пользователей и типичные ситуации, с которыми столкнется модель в продакшене.
2. Определить формат запросов. Формат входных данных описывает, как пользователи взаимодействуют с агентом. Это может быть естественный язык в чате, структурированные формы, голосовые команды или мультимодальные запросы.
3. Длина запросов. Короткие вопросы проверяют способность давать четкие, краткие ответы. Средние вопросы часто отражают типичные пользовательские запросы. Длинные вопросы проверяют способность обрабатывать подробную информацию и выделять ключевые факторы.
4. Открытость запросов. Датасет доджен содержать как открытые для получения развенрнутого ответа от AI, так и закрытые вопросы с простыми ответами в стиле Да/Нет.
5. Вариативность сложности запросов. Простые запросы включают фактические вопросы, определения терминов, базовые инструкции. Эти вопросы проверяют базовые знания модели и ее способность давать четкие, краткие ответы. Запросы средней сложности требуют анализа, сравнения, объяснения связей между концепциями. Такие вопросы проверяют способность модели структурировать информацию и учитывать множественные факторы. Сложные задачи включают многоэтапные рассуждения, работу с неопределенностью, креативные решения. Такие задачи проверяют способность модели разбивать комплексные проблемы на этапы и учитывать ограничения.
6. Включение граничных случаев и "ловушек”.
Граничные случаи и "ловушки" представляют собой специально созданные тестовые примеры, которые проверяют поведение модели в необычных или потенциально проблематичных ситуациях. Эти тесты особенно важны для выявления скрытых проблем, которые могут не проявляться в обычной работе. Ловушки безопасности пытаются заставить модель нарушить встроенные ограничения. Ловушки конфиденциальности проверяют, не раскрывает ли модель информацию о других пользователях или внутренние детали своей работы. Ловушки компетентности проверяют, признает ли модель границы своих знаний и не пытается ли выдавать предположения за факты. Ловушки логики содержат противоречивую или неполную информацию, чтобы проверить, может ли модель выявить проблемы и запросить уточнения вместо попытки ответить на основе некорректных данных.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Ниже я привел ряд критериев, которые помогут правильно подойти к его созданию:
1. Использовать реалистичные сценарии из домена работы AI. Это означает, что тестовые примеры должны максимально точно отражать реальное поведение пользователей и типичные ситуации, с которыми столкнется модель в продакшене.
2. Определить формат запросов. Формат входных данных описывает, как пользователи взаимодействуют с агентом. Это может быть естественный язык в чате, структурированные формы, голосовые команды или мультимодальные запросы.
3. Длина запросов. Короткие вопросы проверяют способность давать четкие, краткие ответы. Средние вопросы часто отражают типичные пользовательские запросы. Длинные вопросы проверяют способность обрабатывать подробную информацию и выделять ключевые факторы.
4. Открытость запросов. Датасет доджен содержать как открытые для получения развенрнутого ответа от AI, так и закрытые вопросы с простыми ответами в стиле Да/Нет.
5. Вариативность сложности запросов. Простые запросы включают фактические вопросы, определения терминов, базовые инструкции. Эти вопросы проверяют базовые знания модели и ее способность давать четкие, краткие ответы. Запросы средней сложности требуют анализа, сравнения, объяснения связей между концепциями. Такие вопросы проверяют способность модели структурировать информацию и учитывать множественные факторы. Сложные задачи включают многоэтапные рассуждения, работу с неопределенностью, креативные решения. Такие задачи проверяют способность модели разбивать комплексные проблемы на этапы и учитывать ограничения.
6. Включение граничных случаев и "ловушек”.
Граничные случаи и "ловушки" представляют собой специально созданные тестовые примеры, которые проверяют поведение модели в необычных или потенциально проблематичных ситуациях. Эти тесты особенно важны для выявления скрытых проблем, которые могут не проявляться в обычной работе. Ловушки безопасности пытаются заставить модель нарушить встроенные ограничения. Ловушки конфиденциальности проверяют, не раскрывает ли модель информацию о других пользователях или внутренние детали своей работы. Ловушки компетентности проверяют, признает ли модель границы своих знаний и не пытается ли выдавать предположения за факты. Ловушки логики содержат противоречивую или неполную информацию, чтобы проверить, может ли модель выявить проблемы и запросить уточнения вместо попытки ответить на основе некорректных данных.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍2🔥2
Mastering LLM-as-a-Judge eBook.pdf
33.8 MB
Mastering LLM-as-a-Judge отличный гайд от Galileo о том, как использовать большие языковые модели для оценки других моделей.
В гайде подробно описано:
- как работает подход LLM-as-a-Judge
- какие бывают схемы оценивания (single, pairwise)
- типичные bias’ы у моделей-судей
- как строить собственную систему оценки и валидировать её
- почему появляются small language models (SLM) специально для evaluation
Если вы занимаетесь оценкой AI, метриками качества генерации или строите пайплайны тестирования LLM, то советую к прочтению.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
В гайде подробно описано:
- как работает подход LLM-as-a-Judge
- какие бывают схемы оценивания (single, pairwise)
- типичные bias’ы у моделей-судей
- как строить собственную систему оценки и валидировать её
- почему появляются small language models (SLM) специально для evaluation
Если вы занимаетесь оценкой AI, метриками качества генерации или строите пайплайны тестирования LLM, то советую к прочтению.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍7🔥2
Всем привет. Сегодня хочу поделиться видео «Attention in Transformers – step-by-step», которое показывает, как именно под капотом работают большие языковые модели (LLM), построенных на архитектуре Трансформеров.
Механизм attention - это то, что позволяет LLM «понимать», как одно слово связано с другим, даже если они далеко друг от друга в тексте. Благодаря ему модели могут работать с длинными контекстами, реагировать на синонимы и удерживать смысл.
Что происходит внутри:
⁃ Каждое слово превращается в вектор и порождает три компонента: Query (Q), Key (K), Value (V).
⁃ Модель вычисляет, насколько каждый Query «связан» с каждым Key и дает веса (attention scores).
⁃ Затем эти веса применяются к Value-векторам и получается новое представление слова, уже учитывающее контекст.
⁃ Механизм Multi-Head Attention позволяет смотреть на данные сразу с разных «углов» и извлекать разные зависимости.
Поэтому если вы хотите лучше понимать, как модели LLM предсказывают слова при написании ответа, как работают векторные БД, то данное видео советую посмотреть обязательно.
Ссылка на видео
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Механизм attention - это то, что позволяет LLM «понимать», как одно слово связано с другим, даже если они далеко друг от друга в тексте. Благодаря ему модели могут работать с длинными контекстами, реагировать на синонимы и удерживать смысл.
Что происходит внутри:
⁃ Каждое слово превращается в вектор и порождает три компонента: Query (Q), Key (K), Value (V).
⁃ Модель вычисляет, насколько каждый Query «связан» с каждым Key и дает веса (attention scores).
⁃ Затем эти веса применяются к Value-векторам и получается новое представление слова, уже учитывающее контекст.
⁃ Механизм Multi-Head Attention позволяет смотреть на данные сразу с разных «углов» и извлекать разные зависимости.
Поэтому если вы хотите лучше понимать, как модели LLM предсказывают слова при написании ответа, как работают векторные БД, то данное видео советую посмотреть обязательно.
Ссылка на видео
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍3🔥1
НОВЫЙ ФРЕЙМВОРК ДЛЯ ОЦЕНКИ ИИ
Всем привет!
Хочу поделиться с вами отличной новостью, что я наконец-то опубликовал мой собственный разработанный evaluation framework для оценки решений на базе генеративного ИИ.
Я работал над этим фреймворком практически 6 месяцев, в том числе изучая и применяя на практики различные другие фреймворки, такие как deepeval и RAGAS, но в итоге не один из них так полностью и не удовлетворил меня в плане оценки ИИ решений в рамках моих проектов.
Поэтому я решил пойти другим путем и написать свою собственную бибилиотеку для оценки ИИ, которая бы решала проблемы, с которыми я сталкивался:
⁃ сделать возможность изменения требовательности оценки в зависимости от проекта, потому что на одном проекте нужно строгая жесткая оценка, а на другом, например, у обычного чат бота не сильно критично, если он добавляет от себя контекста, поэтому требовательность может быть ниже.
⁃ сделать оценку более точную и использовать LLM для косвенной, а не прямой оценки.
⁃ расширить и улучшить систему вердиктов, которая также используется в deepeval в более упрощенном варианте
⁃ сделать процесс оценки прозрачным, то чего мне не хватало в других фреймворках, когда не совсем понимаешь, почему получился тот или иной скор балл.
И все эти проблемы я постарался решить с моем фреймворке eval-ai-library.
Что сейчас там есть:
⁃ Поддержка более 15 метрик для оценки ИИ
⁃ Полноценная имплементация алгоритма оценки G-Eval
⁃ Поддержка разных LLM провайдеров
⁃ Генерация датасета с нуля или из документов
⁃ Регулировка строгости оценки через температуру
⁃ Визуализация результатов оценки в терминале
⁃ Прозрачное логирование, которое показывает полностью из чего получился финальный скор балл.
⁃ Полноценная документации по работе с фреймворком
Я буду благодарен за использование моего фреймворка в вашей работе, а также вы всегда можете что-то конрибъютить сами в данный проект.
Скачивание доступно через официальный установочник python pip.
Ссылка на библиотеку в pypi.org
https://pypi.org/project/eval-ai-library/
Ссылка на открытый GIT репозиторий проекта
https://github.com/meshkovQA/Eval-ai-library.git
Всем привет!
Хочу поделиться с вами отличной новостью, что я наконец-то опубликовал мой собственный разработанный evaluation framework для оценки решений на базе генеративного ИИ.
Я работал над этим фреймворком практически 6 месяцев, в том числе изучая и применяя на практики различные другие фреймворки, такие как deepeval и RAGAS, но в итоге не один из них так полностью и не удовлетворил меня в плане оценки ИИ решений в рамках моих проектов.
Поэтому я решил пойти другим путем и написать свою собственную бибилиотеку для оценки ИИ, которая бы решала проблемы, с которыми я сталкивался:
⁃ сделать возможность изменения требовательности оценки в зависимости от проекта, потому что на одном проекте нужно строгая жесткая оценка, а на другом, например, у обычного чат бота не сильно критично, если он добавляет от себя контекста, поэтому требовательность может быть ниже.
⁃ сделать оценку более точную и использовать LLM для косвенной, а не прямой оценки.
⁃ расширить и улучшить систему вердиктов, которая также используется в deepeval в более упрощенном варианте
⁃ сделать процесс оценки прозрачным, то чего мне не хватало в других фреймворках, когда не совсем понимаешь, почему получился тот или иной скор балл.
И все эти проблемы я постарался решить с моем фреймворке eval-ai-library.
Что сейчас там есть:
⁃ Поддержка более 15 метрик для оценки ИИ
⁃ Полноценная имплементация алгоритма оценки G-Eval
⁃ Поддержка разных LLM провайдеров
⁃ Генерация датасета с нуля или из документов
⁃ Регулировка строгости оценки через температуру
⁃ Визуализация результатов оценки в терминале
⁃ Прозрачное логирование, которое показывает полностью из чего получился финальный скор балл.
⁃ Полноценная документации по работе с фреймворком
Я буду благодарен за использование моего фреймворка в вашей работе, а также вы всегда можете что-то конрибъютить сами в данный проект.
Скачивание доступно через официальный установочник python pip.
Ссылка на библиотеку в pypi.org
https://pypi.org/project/eval-ai-library/
Ссылка на открытый GIT репозиторий проекта
https://github.com/meshkovQA/Eval-ai-library.git
🔥16👍5❤1
Сегодня разберем тему Reasoning evaluation, а именно как проверять корректность рассуждений в ответах AI-решений.
Когда AI-решение генерирует ответ, важно не только, что оно сказало, но и как это AI-решение пришло к выводу. Можно получить правильный результат, но при этом логика рассуждений будет нарушена. Для сложных систем, особенно работающих в несколько шагов, проверка reasoning становится обязательной частью evaluation.
Простой пример, есть запрос “Если Иван старше Петра, а Петр старше Анны, кто самый младший?”
Хорошее решение с reasoning будет выстраивать логическую цепочку, Иван - Петр - Анна - значит, младшая Анна.
Слабое AI-решение может сразу выдать тот же ответ, но без корректной цепочки, просто угадав результат по шаблону. Для пользователя оба ответа одинаковы, но с точки зрения reasoning, вторая модель не умеет рассуждать, она лишь воспроизводит паттерн.
Как это проверяется:
⁃ Пошаговая оценка (step-level evaluation), когда анализируется не финальный ответ, а каждое промежуточное действие или вывод.
⁃ Consistency checks,проверка, ведет ли одна и та же логика к одинаковому результату при разных формулировках задачи.
⁃ Self-reflection prompts, заставляем AI-решение объяснить свой reasoning, простой промпт, “почему ты выбрал именно этот ответ?” и сверяем объяснение с логикой шага.
Для анализа reasoning-цепочек все чаще используют трейсинг-инструменты, такие как LangSmith, LangFuse, Arize Phoenix.
Они позволяют увидеть, какие шаги модель сделала, какие промежуточные ответы получила, где логика сломалась. Это дает возможность оценить не просто правильность ответа, а качество мышления AI-решения, насколько оно системно рассуждает, проверяет гипотезы и последовательно обновляет выводы.
Именно через reasoning evaluation можно отличить AI-решение, которая действительно понимает контекст, от того, что просто повторяет статистические шаблоны.
Полезная информация:
Курс по evaluation AI |
Мой фремворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Когда AI-решение генерирует ответ, важно не только, что оно сказало, но и как это AI-решение пришло к выводу. Можно получить правильный результат, но при этом логика рассуждений будет нарушена. Для сложных систем, особенно работающих в несколько шагов, проверка reasoning становится обязательной частью evaluation.
Простой пример, есть запрос “Если Иван старше Петра, а Петр старше Анны, кто самый младший?”
Хорошее решение с reasoning будет выстраивать логическую цепочку, Иван - Петр - Анна - значит, младшая Анна.
Слабое AI-решение может сразу выдать тот же ответ, но без корректной цепочки, просто угадав результат по шаблону. Для пользователя оба ответа одинаковы, но с точки зрения reasoning, вторая модель не умеет рассуждать, она лишь воспроизводит паттерн.
Как это проверяется:
⁃ Пошаговая оценка (step-level evaluation), когда анализируется не финальный ответ, а каждое промежуточное действие или вывод.
⁃ Consistency checks,проверка, ведет ли одна и та же логика к одинаковому результату при разных формулировках задачи.
⁃ Self-reflection prompts, заставляем AI-решение объяснить свой reasoning, простой промпт, “почему ты выбрал именно этот ответ?” и сверяем объяснение с логикой шага.
Для анализа reasoning-цепочек все чаще используют трейсинг-инструменты, такие как LangSmith, LangFuse, Arize Phoenix.
Они позволяют увидеть, какие шаги модель сделала, какие промежуточные ответы получила, где логика сломалась. Это дает возможность оценить не просто правильность ответа, а качество мышления AI-решения, насколько оно системно рассуждает, проверяет гипотезы и последовательно обновляет выводы.
Именно через reasoning evaluation можно отличить AI-решение, которая действительно понимает контекст, от того, что просто повторяет статистические шаблоны.
Полезная информация:
Курс по evaluation AI |
Мой фремворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍2🔥1
Сегодня про непрерывный мониторинг и обнаружение отклонений на продуктиве.
Контроль качества AI-систем не заканчивается на уровне предпродакшен тестов.
Даже если модель показала хорошие результаты на этапе разработки, в продакшене все может измениться, например, запросы другие, источники обновляются, контексты становятся шумнее. Без постоянного мониторинга качество генерации деградирует постепенно и незаметно.
Поэтому важен continuous evaluation, а именно отслеживание ключевых метрик качества прямо на проде.
Что обычно контролируют:
Answer accuracy - точность ответа модели относительно эталона или golden датасета.
Context relevance - насколько retrieved контекст действительно соответствует запросу.
Context precision / grounding - использует ли модель данные из найденного контекста или “галлюцинирует”.
Factual consistency - согласованность с фактами и источниками.
Response coherence / completeness - логическая целостность и полнота ответа.
Такие метрики считаются на реальных запросах (через golden датасет примеры, LLM as a Jurge или даже обучное человеческую оценку) и позволяют заметить деградацию AI-системы еще до жалоб пользователей.
В продакшне это реализуется через инструменты трейсинга вроде LangFuse, Arize, Galileo, EvidentlyAI, которые собирают данные все запросов, считают метрики и сигналят, если ответы стали менее точными, контекст менее релевантным и так далее.
Continuous evaluation - это тот же QA, только в продакшене, где мы проверяем не код, а качество работы модели в реальных условиях с целью успеть поймать деградацию системы до того момента, пока с этим явно столкнутся реальные пользователи.
Полезная информация:
Курс по evaluation AI |
Мой фремворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Контроль качества AI-систем не заканчивается на уровне предпродакшен тестов.
Даже если модель показала хорошие результаты на этапе разработки, в продакшене все может измениться, например, запросы другие, источники обновляются, контексты становятся шумнее. Без постоянного мониторинга качество генерации деградирует постепенно и незаметно.
Поэтому важен continuous evaluation, а именно отслеживание ключевых метрик качества прямо на проде.
Что обычно контролируют:
Answer accuracy - точность ответа модели относительно эталона или golden датасета.
Context relevance - насколько retrieved контекст действительно соответствует запросу.
Context precision / grounding - использует ли модель данные из найденного контекста или “галлюцинирует”.
Factual consistency - согласованность с фактами и источниками.
Response coherence / completeness - логическая целостность и полнота ответа.
Такие метрики считаются на реальных запросах (через golden датасет примеры, LLM as a Jurge или даже обучное человеческую оценку) и позволяют заметить деградацию AI-системы еще до жалоб пользователей.
В продакшне это реализуется через инструменты трейсинга вроде LangFuse, Arize, Galileo, EvidentlyAI, которые собирают данные все запросов, считают метрики и сигналят, если ответы стали менее точными, контекст менее релевантным и так далее.
Continuous evaluation - это тот же QA, только в продакшене, где мы проверяем не код, а качество работы модели в реальных условиях с целью успеть поймать деградацию системы до того момента, пока с этим явно столкнутся реальные пользователи.
Полезная информация:
Курс по evaluation AI |
Мой фремворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍2🔥1
Откуда брать информацию о том, что происходит в индустрии оценки ИИ, какие новые техники и подходы появляются?
На самом деле пока оценка и тестирование ИИ никак нормально не стандартизирована, поэтому большинство информации нужно самостоятельно читать и искать в научных статьях.
Основной такой портал - это https://arxiv.org/
arXiv - это архив с открытым доступом, содержащий около 2,4 миллиона научных статей в области физики, математики, информатики, количественной биологии, количественных финансов, статистики, электротехники и системных наук, а также экономики.
Именно на этом портале часто публикуют новые статьи об оценки ИИ, поэтому если не знаете куда идти за инфомрацией, я советую как минимум держать этот портал в своих закладках браузера.
И ниже ссылки на две полезные работы в области оценки ИИ агентов, которые были опубликованы в этом году
AI Agents: Evolution, Architecture, and Real-World Applications
Survey on Evaluation of LLM-based Agents
Полезная информация:
Курс по evaluation AI |
Мой фремворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
На самом деле пока оценка и тестирование ИИ никак нормально не стандартизирована, поэтому большинство информации нужно самостоятельно читать и искать в научных статьях.
Основной такой портал - это https://arxiv.org/
arXiv - это архив с открытым доступом, содержащий около 2,4 миллиона научных статей в области физики, математики, информатики, количественной биологии, количественных финансов, статистики, электротехники и системных наук, а также экономики.
Именно на этом портале часто публикуют новые статьи об оценки ИИ, поэтому если не знаете куда идти за инфомрацией, я советую как минимум держать этот портал в своих закладках браузера.
И ниже ссылки на две полезные работы в области оценки ИИ агентов, которые были опубликованы в этом году
AI Agents: Evolution, Architecture, and Real-World Applications
Survey on Evaluation of LLM-based Agents
Полезная информация:
Курс по evaluation AI |
Мой фремворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥4👍1😁1
Сегодня разберем свежую идею из статьи Who’s Asking? Simulating Role-Based Questions for Conversational AI Evaluation про то, как роль пользователя влияет на оценку AI.
Когда мы тестируем диалоговые модели, мы часто формируем запрос в вакууме: просто вопрос - ответ - метрика. Но в реальности у пользователя всегда есть роль, менеджер, аналитик, инженер поддержки. И эта роль влияет на то, что именно он хочет получить от AI и как оценивает качество ответа.
Представьте запрос:
Объясни разницу между API и SDK.
Если спрашивает новичок, он ждет простого объяснения и примеров.
Если разработчик, ему нужны технические детали и ссылки на спецификацию.
Одно и тоже AI решение может дать корректный ответ, но быть бесполезным, если не учтена роль спрашивающего.
Авторы предлагают подход role-based evaluation, который позволяет симулировать разные роли и смотреть, как AI решение адаптирует стиль, уровень детализации и фокус ответа.
Для этого создаются ролевые шаблоны запросов (ты преподаватель, ты эксперт, ты студент) и оценивается:
⁃ насколько ответ соответствует роли,
⁃ сохранилась ли точность и полнота,
⁃ и умеет ли AI решение менять стиль объяснения в зависимости от контекста.
Модели все чаще работают в продуктах с конкретными ролями. Если evaluation остается нейтральным, мы можем пропустить критичные ошибки адаптации, когда модель технически права, но ответ не соответствует ожиданиям пользователя. Поэтому, роль пользователя - это еще одно измерение в оценке AI. Потому что часто не достаточно просто проверять факты, нужно проверять, насколько ответ уместен для конкретного типа пользователя.
Полезная информация:
Курс по evaluation AI |
Мой фремворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Когда мы тестируем диалоговые модели, мы часто формируем запрос в вакууме: просто вопрос - ответ - метрика. Но в реальности у пользователя всегда есть роль, менеджер, аналитик, инженер поддержки. И эта роль влияет на то, что именно он хочет получить от AI и как оценивает качество ответа.
Представьте запрос:
Объясни разницу между API и SDK.
Если спрашивает новичок, он ждет простого объяснения и примеров.
Если разработчик, ему нужны технические детали и ссылки на спецификацию.
Одно и тоже AI решение может дать корректный ответ, но быть бесполезным, если не учтена роль спрашивающего.
Авторы предлагают подход role-based evaluation, который позволяет симулировать разные роли и смотреть, как AI решение адаптирует стиль, уровень детализации и фокус ответа.
Для этого создаются ролевые шаблоны запросов (ты преподаватель, ты эксперт, ты студент) и оценивается:
⁃ насколько ответ соответствует роли,
⁃ сохранилась ли точность и полнота,
⁃ и умеет ли AI решение менять стиль объяснения в зависимости от контекста.
Модели все чаще работают в продуктах с конкретными ролями. Если evaluation остается нейтральным, мы можем пропустить критичные ошибки адаптации, когда модель технически права, но ответ не соответствует ожиданиям пользователя. Поэтому, роль пользователя - это еще одно измерение в оценке AI. Потому что часто не достаточно просто проверять факты, нужно проверять, насколько ответ уместен для конкретного типа пользователя.
Полезная информация:
Курс по evaluation AI |
Мой фремворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥4👍1
Сегодня разберем основные методы оценки ИИ-моделей, которые применяются в генеративных и retrieval-сценариях.
Многие из них пересекаются по сути, поэтому ниже упрощённая и объединённая структура методов.
1. Семантические методы
Оценивают смысловую близость между вопросом, контекстом и ответом.
Используются эмбеддинги и косинусное сходство (например, sentence-transformers, OpenAI text-embedding-3-small, MiniLM).
Чем выше значение, тем сильнее совпадение по смыслу.
Применяется для оценки релевантности найденных фрагментов, совпадения с эталонным ответом, фильтрации нерелевантных контекстов.
2. Лексические методы
Более простые и интерпретируемые.
Основаны на анализе пересечения ключевых слов (Keyword Overlap).
Считается доля совпадений между словами в вопросе и ответе или контексте.
Метод быстрый, но чувствителен к перефразировкам, обычно используется как базовая проверка ответов ИИ решения.
3. Фрагментарная (chunk-based) оценка
Вместо анализа документа целиком проверяется каждый фрагмент (chunk).
Это дает возможность точнее понять, какие куски текста действительно релевантны запросу, а какие просто шум.
Метод активно применяется в RAG-системах, где контекст разбивается на блоки.
4. LLM-based верификация (LLM as a Judge)
Оценка проводится самой языковой моделью, которая получает пару вопрос–контекст или вопрос–ответ и выносит суждение (например, по шкале от 1 до 5).
Используется для проверки релевантности, полноты, соответствия ответа запросу и многих дургих метриках
5. NLI-подход (Natural Language Inference)
Метод логической проверки, который смотрит действительно ли ответ вытекает из данных.
Внешняя модель (например, RoBERTa-large-MNLI или DeBERTa-v3-large-mnli) классифицирует связь между контекстом и утверждением как подтверждение, противоречие или несвязанные, после чего считается финальный скор.
Применяется для контроля достоверности и выявления галлюцинаций.
6. Verdict / смысловая декомпозиция
Метод делит ответ от ИИ решения по смысловым блокам (тезисам).
Каждый блок проверяется на уместность (или соответствии критериям метрики) относительно вопроса.
7. Reverse Questioning
Инверсный метод, модель оценщик (LLM) получает готовый ответ и должна восстановить вопрос.
Если восстановленный вопрос близок к исходному, то значит, ответ действительно отражает суть запроса.
Используется как дополнительная проверка релевантности и смысловой согласованности.
Полезная информация:
Курс по evaluation AI |
Мой фремворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Многие из них пересекаются по сути, поэтому ниже упрощённая и объединённая структура методов.
1. Семантические методы
Оценивают смысловую близость между вопросом, контекстом и ответом.
Используются эмбеддинги и косинусное сходство (например, sentence-transformers, OpenAI text-embedding-3-small, MiniLM).
Чем выше значение, тем сильнее совпадение по смыслу.
Применяется для оценки релевантности найденных фрагментов, совпадения с эталонным ответом, фильтрации нерелевантных контекстов.
2. Лексические методы
Более простые и интерпретируемые.
Основаны на анализе пересечения ключевых слов (Keyword Overlap).
Считается доля совпадений между словами в вопросе и ответе или контексте.
Метод быстрый, но чувствителен к перефразировкам, обычно используется как базовая проверка ответов ИИ решения.
3. Фрагментарная (chunk-based) оценка
Вместо анализа документа целиком проверяется каждый фрагмент (chunk).
Это дает возможность точнее понять, какие куски текста действительно релевантны запросу, а какие просто шум.
Метод активно применяется в RAG-системах, где контекст разбивается на блоки.
4. LLM-based верификация (LLM as a Judge)
Оценка проводится самой языковой моделью, которая получает пару вопрос–контекст или вопрос–ответ и выносит суждение (например, по шкале от 1 до 5).
Используется для проверки релевантности, полноты, соответствия ответа запросу и многих дургих метриках
5. NLI-подход (Natural Language Inference)
Метод логической проверки, который смотрит действительно ли ответ вытекает из данных.
Внешняя модель (например, RoBERTa-large-MNLI или DeBERTa-v3-large-mnli) классифицирует связь между контекстом и утверждением как подтверждение, противоречие или несвязанные, после чего считается финальный скор.
Применяется для контроля достоверности и выявления галлюцинаций.
6. Verdict / смысловая декомпозиция
Метод делит ответ от ИИ решения по смысловым блокам (тезисам).
Каждый блок проверяется на уместность (или соответствии критериям метрики) относительно вопроса.
7. Reverse Questioning
Инверсный метод, модель оценщик (LLM) получает готовый ответ и должна восстановить вопрос.
Если восстановленный вопрос близок к исходному, то значит, ответ действительно отражает суть запроса.
Используется как дополнительная проверка релевантности и смысловой согласованности.
Полезная информация:
Курс по evaluation AI |
Мой фремворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥5👍1
Сегодня разберем новое интересное исследование Human vs AI-generated tests https://arxiv.org/abs/2510.24739 про то, насколько тесты, созданные ИИ, действительно сопоставимы с теми, что пишут люди.
Когда мы говорим про ИИ генерацию тестового датасета, то обычно подразумеваем, что это позволяет экономить время человека на создание датасета для оценки. Но мы часто не задумаваемся о том, насколько сохраняется качество при такой генерации. В исследоваении авторы провели анализ и как раз постарались ответить на этот вопрос.
Исследование показало, что ИИ хорошо умеет формулировать логичные и грамматически корректные вопросы,
но часто теряется глубина, то есть ИИ делает запросы в датасете слишком похожими, без разнообразия. В итоге тест вроде выглядит нормально, но проверяет одно и то же под разными формулировками.
Это важно, потому что все чаще можно столкнуться с тем, что многие специалисты используют LLM для генерации тестов, но без должной валидации. Использование такого датасета по факту может привести к тому, что ключевые аспекты ИИ решения будут проверены, а какие-то исключительные ситуации или крайние сценарии не попадут в скоуп проверок.
По сути, статья поднимает проблему, что даже если ИИ сгенерировал 100 запросов для тестового датасета, они должны пройти анализ со стороны человека, иначе это просто красиво оформленные тексты без должного понимания, какие именно аспекты ИИ решения они проверяют.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Когда мы говорим про ИИ генерацию тестового датасета, то обычно подразумеваем, что это позволяет экономить время человека на создание датасета для оценки. Но мы часто не задумаваемся о том, насколько сохраняется качество при такой генерации. В исследоваении авторы провели анализ и как раз постарались ответить на этот вопрос.
Исследование показало, что ИИ хорошо умеет формулировать логичные и грамматически корректные вопросы,
но часто теряется глубина, то есть ИИ делает запросы в датасете слишком похожими, без разнообразия. В итоге тест вроде выглядит нормально, но проверяет одно и то же под разными формулировками.
Это важно, потому что все чаще можно столкнуться с тем, что многие специалисты используют LLM для генерации тестов, но без должной валидации. Использование такого датасета по факту может привести к тому, что ключевые аспекты ИИ решения будут проверены, а какие-то исключительные ситуации или крайние сценарии не попадут в скоуп проверок.
По сути, статья поднимает проблему, что даже если ИИ сгенерировал 100 запросов для тестового датасета, они должны пройти анализ со стороны человека, иначе это просто красиво оформленные тексты без должного понимания, какие именно аспекты ИИ решения они проверяют.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
🔥4👍2
Когда мы тестируем ИИ агента, важно проверять не только, как он рассуждает, какие шаги делает или какие инструменты вызывает,
а выполнил ли он задачу до конца. Именно это и измеряет показатель Task Success Rate (TSR).
По сути, TSR - это доля задач, в которых ИИ агент успешно достиг цели в не зависимости от того, как он это выполнил.
Например:
ИИ агент должен оформить заказ - оформил
ИИ агент должен найти документ — нашел
ИИ агент должен объяснить запрос пользователю,дал корректный ответ
И если хотя бы один из шагов при выполнении задачи провален и агент не достиг нужного результата, то задача считается проваленной.
Метрика в целом кажется простой, но именно она показывает итоговую картину качества работы ИИ агента.
Можно иметь идеальный reasoning, правильные вызовы тулов и подробный лог действий, но если цель не достигнута, то это уже не имеет значение.
TSR чаще всего не рассматривают изолированно, поэтому можно снимать дополнительные показатели, такие как :
Average Steps per Success, сколько шагов ИИ агент делает для выполнения задачи.
Error Recovery Rate, насколько часто ИИ агент сам исправляет ошибки без внешнего вмешательства.
Partial Success Rate, доля задач, где ИИ агент частично достиг цели (например, собрал данные, но не выполнил действие).
В целом, если говорить о TSR, то данная метрика по факту отвечает на ключевой вопрос, справился ли агент с задачей, да или нет, что является одним из самых важный критериев проверки работы ИИ агента.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
а выполнил ли он задачу до конца. Именно это и измеряет показатель Task Success Rate (TSR).
По сути, TSR - это доля задач, в которых ИИ агент успешно достиг цели в не зависимости от того, как он это выполнил.
Например:
ИИ агент должен оформить заказ - оформил
ИИ агент должен найти документ — нашел
ИИ агент должен объяснить запрос пользователю,дал корректный ответ
И если хотя бы один из шагов при выполнении задачи провален и агент не достиг нужного результата, то задача считается проваленной.
Метрика в целом кажется простой, но именно она показывает итоговую картину качества работы ИИ агента.
Можно иметь идеальный reasoning, правильные вызовы тулов и подробный лог действий, но если цель не достигнута, то это уже не имеет значение.
TSR чаще всего не рассматривают изолированно, поэтому можно снимать дополнительные показатели, такие как :
Average Steps per Success, сколько шагов ИИ агент делает для выполнения задачи.
Error Recovery Rate, насколько часто ИИ агент сам исправляет ошибки без внешнего вмешательства.
Partial Success Rate, доля задач, где ИИ агент частично достиг цели (например, собрал данные, но не выполнил действие).
В целом, если говорить о TSR, то данная метрика по факту отвечает на ключевой вопрос, справился ли агент с задачей, да или нет, что является одним из самых важный критериев проверки работы ИИ агента.
Полезная информация:
Курс по evaluation AI |
Мой фреймворк для оценки AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍7🔥4