Всем привет!
Недавно в десктоп-приложении от Anthropic для моделей Claude появилась возможность напрямую подключать различные MCP-коннекторы для получения информации из разных источников. В пятницу я решил посмотреть, насколько хорошо они работают.
Моя цель заключалась в том, чтобы Claude AI с нуля написал проект автоматизации тестирования для моего проекта Store Manager (на базе Pytest и Playwright) на основе документации и описания ручных регрессионных тестов.
Вот что получилось.
За пару часов Claude полностью создал структуру проекта и не просто базовую, а модульную: с вынесенной core-функциональностью, расширенным логированием, клиентами для работы с API и базой данных. Также были реализованы утилиты, хелперы, генератор тестовых данных, интеграция с CI/CD и динамическая настройка переменных окружения.
Уже через 2 часа, после 3–4 итераций небольших правок (например, улучшение логирования, пара багфиксов, переработка общих шагов для переиспользования в тестах и другие мелочи), у меня были полностью готовые автоматизированные тесты по моим ручным регрессионным сценариям - всего получилось 29 API-тестов, которые я успешно запустил и получил корректный результат выполнения.
Что я использовал:
- Подключил MCP-коннектор к Google Docs, откуда подтянулись требования к релизу и ручные регрессионные тесты.
- Подключил MCP-коннектор Filesystem для полного доступа Claude AI к проекту автоматизации. Я не написал ни одной строки кода — код писался прямо в проект автоматически.
- В контексте проекта я указал, как должна выглядеть структура проекта по автоматизации тестирования.
- Также планировал автоматизировать UI-тесты, но коннектор подключения к Google Chrome работал нестабильно, как итог не удалось получить селекторы. Скорее всего, проблема была на стороне самого коннектора, надеюсь, это скоро поправят.
Итог:
Работу, которую раньше выполнял синьор-автоматизатор примерно за неделю, Claude сделал за 2 часа, пусть и без UI-тестов. В целом я мог бы выполнить JS для сбора селекторов с HTML-страницы и Claude сам бы разобрался и написал UI-тесты, но это потребовало бы моего прямого вмешательства, чего я хотел избежать.
Поэтому, как я уже говорил не раз: будущее точно за AI в ИТ-профессиях. Те, кто готов меняться и интегрировать ИИ в свою работу, добьются больших успехов. Если вы еще не пробовали использовать AI как ассистента в своей работе, то настоятельно рекомендую начать. Уже сейчас AI способен решать довольно сложные задачи за пару часов, на что раньше уходила неделя.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
Недавно в десктоп-приложении от Anthropic для моделей Claude появилась возможность напрямую подключать различные MCP-коннекторы для получения информации из разных источников. В пятницу я решил посмотреть, насколько хорошо они работают.
Моя цель заключалась в том, чтобы Claude AI с нуля написал проект автоматизации тестирования для моего проекта Store Manager (на базе Pytest и Playwright) на основе документации и описания ручных регрессионных тестов.
Вот что получилось.
За пару часов Claude полностью создал структуру проекта и не просто базовую, а модульную: с вынесенной core-функциональностью, расширенным логированием, клиентами для работы с API и базой данных. Также были реализованы утилиты, хелперы, генератор тестовых данных, интеграция с CI/CD и динамическая настройка переменных окружения.
Уже через 2 часа, после 3–4 итераций небольших правок (например, улучшение логирования, пара багфиксов, переработка общих шагов для переиспользования в тестах и другие мелочи), у меня были полностью готовые автоматизированные тесты по моим ручным регрессионным сценариям - всего получилось 29 API-тестов, которые я успешно запустил и получил корректный результат выполнения.
Что я использовал:
- Подключил MCP-коннектор к Google Docs, откуда подтянулись требования к релизу и ручные регрессионные тесты.
- Подключил MCP-коннектор Filesystem для полного доступа Claude AI к проекту автоматизации. Я не написал ни одной строки кода — код писался прямо в проект автоматически.
- В контексте проекта я указал, как должна выглядеть структура проекта по автоматизации тестирования.
- Также планировал автоматизировать UI-тесты, но коннектор подключения к Google Chrome работал нестабильно, как итог не удалось получить селекторы. Скорее всего, проблема была на стороне самого коннектора, надеюсь, это скоро поправят.
Итог:
Работу, которую раньше выполнял синьор-автоматизатор примерно за неделю, Claude сделал за 2 часа, пусть и без UI-тестов. В целом я мог бы выполнить JS для сбора селекторов с HTML-страницы и Claude сам бы разобрался и написал UI-тесты, но это потребовало бы моего прямого вмешательства, чего я хотел избежать.
Поэтому, как я уже говорил не раз: будущее точно за AI в ИТ-профессиях. Те, кто готов меняться и интегрировать ИИ в свою работу, добьются больших успехов. Если вы еще не пробовали использовать AI как ассистента в своей работе, то настоятельно рекомендую начать. Уже сейчас AI способен решать довольно сложные задачи за пару часов, на что раньше уходила неделя.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
👍5🔥3
Сегодня разберем одну из важнейших практик в области безопасности ИИ — red teaming. Термин пришел из кибербезопасности, но в контексте ИИ приобрел новое значение и критическую важность.
Red teaming в AI - это процесс тестирования, где команда специалистов пытается заставить ИИ-модель вести себя нежелательным образом: генерировать токсичный контент, выдавать конфиденциальную информацию, проявлять предвзятость или нарушать политики безопасности.
Основные направления red teaming:
Jailbreak атаки - попытки обойти фильтры безопасности модели через хитрые промпты. Например, попросить ИИ "сыграть роль злодея" или использовать метафоры для получения запрещенного контента.
Prompt injection - внедрение скрытых инструкций в пользовательский запрос, чтобы модель выполнила нежелательные действия. Особенно критично для ИИ-агентов с доступом к внешним системам.
Data poisoning - проверка, как модель реагирует на потенциально вредоносные данные в обучающем наборе или контексте.
Bias (предвзятость) - поиск предвзятости по отношению к определенным группам, профессиям, национальностям, религиям.
Из материалов для обучения я советую посмотреть эти видео, в которых достаточно поднятно разбирается данный вид тестирования AI систем:
Мини курс по RedTeaming с deeplearning.ai
Мини курс по RedTeaming от Microsoft
С точки зрения фреймворков, в своей работе я использую следующие в зависимости от типов задач:
PyRIT - фремворка от microsoft, который возволяет автоматически находить разные уязвимости в системе, содержит большое количество атак и промптов и регулярно обновляется разработчиками.
DeepEval RedTeaming - достаточно простое использование, нужно указать, что вы хотите получить (например, финансовую информацию о компании), и фреймворк сам сгегенирует промпты для различных типы атак и выполнит эти атаки на вашу AI систему.
GuardrailsAI - эффективен для мониторинга атак на продуктиве, может выявлять разные типы атак.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
Red teaming в AI - это процесс тестирования, где команда специалистов пытается заставить ИИ-модель вести себя нежелательным образом: генерировать токсичный контент, выдавать конфиденциальную информацию, проявлять предвзятость или нарушать политики безопасности.
Основные направления red teaming:
Jailbreak атаки - попытки обойти фильтры безопасности модели через хитрые промпты. Например, попросить ИИ "сыграть роль злодея" или использовать метафоры для получения запрещенного контента.
Prompt injection - внедрение скрытых инструкций в пользовательский запрос, чтобы модель выполнила нежелательные действия. Особенно критично для ИИ-агентов с доступом к внешним системам.
Data poisoning - проверка, как модель реагирует на потенциально вредоносные данные в обучающем наборе или контексте.
Bias (предвзятость) - поиск предвзятости по отношению к определенным группам, профессиям, национальностям, религиям.
Из материалов для обучения я советую посмотреть эти видео, в которых достаточно поднятно разбирается данный вид тестирования AI систем:
Мини курс по RedTeaming с deeplearning.ai
Мини курс по RedTeaming от Microsoft
С точки зрения фреймворков, в своей работе я использую следующие в зависимости от типов задач:
PyRIT - фремворка от microsoft, который возволяет автоматически находить разные уязвимости в системе, содержит большое количество атак и промптов и регулярно обновляется разработчиками.
DeepEval RedTeaming - достаточно простое использование, нужно указать, что вы хотите получить (например, финансовую информацию о компании), и фреймворк сам сгегенирует промпты для различных типы атак и выполнит эти атаки на вашу AI систему.
GuardrailsAI - эффективен для мониторинга атак на продуктиве, может выявлять разные типы атак.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
🔥5👍1
Последний месяц провел в подготовке нового курса по тестированию и оценки работы ИИ.
В целом курс получается достаточно интересным, сейчас уже готово 4 полноценных лекции с большим количеством практики:
- Для оценки Machine Learning и Deep Learning подготовил готовые алгоритмы для обучения своих моделей, которые мы будем использовать в обучении, будем учить модели и потом их оценивать.
- Подготовил готовые фреймворки для оценки базовых LLM, будем работать с моделями от OpenAI, DeepSeek и Anthropic, запускать бенчмарки и анализировать результаты.
- Ну и также написал свой RAG для обучения, в который будем загружать документы и оценивать качество его работы с помощью DeepEval и Ragas.
За август планирую добить вторую часть обучения, а именно подготовить как AI системы (агенты, чат боты, мультимодальные системы), так и готовые алгоритмы и фреймворки для их оценки, также обязательно разберем red teaming и варианты выполнения различных атак на AI.
Если все пойдет по плану, то в сентябре уже начну обучение первой группы, поэтому если еще не оставили заявку, то самое время сейчас это сделать тут:
Eval-ai.com
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
В целом курс получается достаточно интересным, сейчас уже готово 4 полноценных лекции с большим количеством практики:
- Для оценки Machine Learning и Deep Learning подготовил готовые алгоритмы для обучения своих моделей, которые мы будем использовать в обучении, будем учить модели и потом их оценивать.
- Подготовил готовые фреймворки для оценки базовых LLM, будем работать с моделями от OpenAI, DeepSeek и Anthropic, запускать бенчмарки и анализировать результаты.
- Ну и также написал свой RAG для обучения, в который будем загружать документы и оценивать качество его работы с помощью DeepEval и Ragas.
За август планирую добить вторую часть обучения, а именно подготовить как AI системы (агенты, чат боты, мультимодальные системы), так и готовые алгоритмы и фреймворки для их оценки, также обязательно разберем red teaming и варианты выполнения различных атак на AI.
Если все пойдет по плану, то в сентябре уже начну обучение первой группы, поэтому если еще не оставили заявку, то самое время сейчас это сделать тут:
Eval-ai.com
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
👍7🔥2
Всем привет!
Сегодня разберем различные виды RAG-архитектур. RAG - это одна технология, но существует несколько принципиально разных подходов. Архитектура системы кардинально влияет на качество ответов и сложность реализации.
Naive RAG: Базовая схема запрос → поиск → генерация. Находит 3-10 похожих фрагментов по cosine similarity, передает в LLM с исходным вопросом для генерации.
Advanced RAG: Включает предобработку запросов (Query rewriting) и гибридный поиск. Query rewriting техника расширяет фразу запроса, например, "проблемы сервера" расширит до "медленная работа веб-сервера" и "оптимизация производительности".
Гибридный поиск комбинирует semantic + fulltext. При запросе "настройка max_connections PostgreSQL" semantic поиск найдет общую инфу про БД, а fulltext точные упоминания параметра.
Agentic RAG: Самая продвинутая архитектура с AI-агентами. Разбивает сложные запросы на подзадачи, планирует последовательность действий.
Запрос "Влияние цифровизации на рынок труда 2020-2024" декомпозируется на: статистика рынка, процессы цифровизации, COVID-19, санкции, синтез результатов.
Evaluation для разных типов RAG:
- Naive RAG - это простые метрики: accuracy, ROUGE для сравнения с эталонными ответами. Оценка Context Relevancy также критична.
- Advanced RAG - нужна RAG-триада: Answer Relevancy, Faithfulness, Context Relevancy. Дополнительно оценивайте качество перефразирования запросов и качество гибридного поиска.
- Agentic RAG — самый сложный evaluation. Помимо триады нужны метрики для планирования: правильность декомпозиции задач, качество синтеза информации из подзадач, coherence финального ответа.
Начинайте с базовых метрик для Naive, добавляйте сложность постепенно. Для Agentic обязателен human evaluation, так как автоматические метрики не всегда улавливают качество комплексного анализа.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
Сегодня разберем различные виды RAG-архитектур. RAG - это одна технология, но существует несколько принципиально разных подходов. Архитектура системы кардинально влияет на качество ответов и сложность реализации.
Naive RAG: Базовая схема запрос → поиск → генерация. Находит 3-10 похожих фрагментов по cosine similarity, передает в LLM с исходным вопросом для генерации.
Advanced RAG: Включает предобработку запросов (Query rewriting) и гибридный поиск. Query rewriting техника расширяет фразу запроса, например, "проблемы сервера" расширит до "медленная работа веб-сервера" и "оптимизация производительности".
Гибридный поиск комбинирует semantic + fulltext. При запросе "настройка max_connections PostgreSQL" semantic поиск найдет общую инфу про БД, а fulltext точные упоминания параметра.
Agentic RAG: Самая продвинутая архитектура с AI-агентами. Разбивает сложные запросы на подзадачи, планирует последовательность действий.
Запрос "Влияние цифровизации на рынок труда 2020-2024" декомпозируется на: статистика рынка, процессы цифровизации, COVID-19, санкции, синтез результатов.
Evaluation для разных типов RAG:
- Naive RAG - это простые метрики: accuracy, ROUGE для сравнения с эталонными ответами. Оценка Context Relevancy также критична.
- Advanced RAG - нужна RAG-триада: Answer Relevancy, Faithfulness, Context Relevancy. Дополнительно оценивайте качество перефразирования запросов и качество гибридного поиска.
- Agentic RAG — самый сложный evaluation. Помимо триады нужны метрики для планирования: правильность декомпозиции задач, качество синтеза информации из подзадач, coherence финального ответа.
Начинайте с базовых метрик для Naive, добавляйте сложность постепенно. Для Agentic обязателен human evaluation, так как автоматические метрики не всегда улавливают качество комплексного анализа.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
🔥3👍2❤1
Всем привет!
Сегодня разберем реранкинг, технику, которая может улучшить качество RAG-систем. Именно он часто решает проблему "нашли много, но не то".
Реранкинг - это двухэтапный процесс поиска данных. Сначала система находит большое количество потенциально релевантных документов (обычно 50-100) с помощью быстрого, но не очень точного метода. Затем более сложная модель переранжирует эти результаты, оставляя только самые релевантные (5-10 документов).
Представьте: вы ищете "настройка безопасности веб-сервера". Первичный поиск может вернуть 50 документов обо всем, что связано с серверами и безопасностью. Реранкер анализирует каждый документ детальнее и выбирает только те, которые действительно про настройку безопасности именно веб-серверов.
Типы реранкинга:
Cross-encoder реранкинг использует модели типа BERT, которые обрабатывают запрос и документ совместно. Качество высокое, но медленно — нужно обработать каждую пару запрос-документ отдельно.
Bi-encoder + Cross-encoder pipeline - сначала быстрый bi-encoder находит кандидатов, потом медленный cross-encoder их переранжирует. Компромисс между скоростью и качеством.
LLM-based реранкинг использует большие языковые модели для оценки релевантности. Модель получает запрос и документ, возвращает score от 0 до 1.
Метрики для evaluation реранкинга:
Precision@K: сколько из топ-K результатов действительно релевантны.
NDCG: учитывает не только релевантность, но и позицию в рейтинге.
MRR (Mean Reciprocal Rank): на какой позиции в среднем находится первый релевантный результат.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
Сегодня разберем реранкинг, технику, которая может улучшить качество RAG-систем. Именно он часто решает проблему "нашли много, но не то".
Реранкинг - это двухэтапный процесс поиска данных. Сначала система находит большое количество потенциально релевантных документов (обычно 50-100) с помощью быстрого, но не очень точного метода. Затем более сложная модель переранжирует эти результаты, оставляя только самые релевантные (5-10 документов).
Представьте: вы ищете "настройка безопасности веб-сервера". Первичный поиск может вернуть 50 документов обо всем, что связано с серверами и безопасностью. Реранкер анализирует каждый документ детальнее и выбирает только те, которые действительно про настройку безопасности именно веб-серверов.
Типы реранкинга:
Cross-encoder реранкинг использует модели типа BERT, которые обрабатывают запрос и документ совместно. Качество высокое, но медленно — нужно обработать каждую пару запрос-документ отдельно.
Bi-encoder + Cross-encoder pipeline - сначала быстрый bi-encoder находит кандидатов, потом медленный cross-encoder их переранжирует. Компромисс между скоростью и качеством.
LLM-based реранкинг использует большие языковые модели для оценки релевантности. Модель получает запрос и документ, возвращает score от 0 до 1.
Метрики для evaluation реранкинга:
Precision@K: сколько из топ-K результатов действительно релевантны.
NDCG: учитывает не только релевантность, но и позицию в рейтинге.
MRR (Mean Reciprocal Rank): на какой позиции в среднем находится первый релевантный результат.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
🔥4👍2
Всем привет!
Сегодня разберем LLM-as-a-Judge evaluation подход, который позволяет автоматизировать оценку качества AI-систем.
LLM-as-a-Judge - это когда одна AI-модель оценивает качество ответов другой модели.
LLM-as-a-Judge получает исходный вопрос, ответ вашей системы и критерии оценки. Возвращает структурированную оценку с обоснованием: "Ответ релевантен (8/10), фактически точен (7/10), хорошо структурирован (9/10)".
Представьте: вам нужно оценить качество тысяч ответов чат-бота ежедневно. Человеческая оценка займет недели, автоматические математические метрики могут упустить нюансы или завышать/занижать оценку. LLM-судья дает почти человеческое понимание за секунды.
Продвинутые подходы:
Декомпозиция на атомарные утверждения, когда вместо оценки всего ответа система разбивает его на отдельные проверяемые факты. Каждое утверждение оценивается независимо по шкале: fully (1.0), mostly (0.9), partial (0.6), minor (0.3), none (0.0). Далее высчитывается среднее по всем баллам утвержений, что и является финальной оценкой.
Парные сравнения, когда модель сравнивает два ответа и определяет лучший. Часто надежнее абсолютных оценок.
Основные преимущества такого подхода, это близость к человеческому суждению, объяснимость результатов, гибкость настройки под домены.
Но есть важные нюансы, о которых стоит помнить:
Bias полезности: у AI есть склонность завышать оценки любых связных ответов.
Стоимость: каждая оценка требует вызов API к мощной модели, который чаще всего стоит денег. Но я бы не сказал, что это какие-то большие суммы, например, на моих проекта стоимость одного раунда evlaution из датасета 200-300 вопросов стоит 1-2 $.
Поэтому важно использовать AI модели не в лоб, предоставляя им в одном промпте и задачу оценить ту или иную метрику и исходные данные для оценки, а стараться, что AI косвенно оценивал результаты, например, через декомпозицию на атомарные утверждения.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
Сегодня разберем LLM-as-a-Judge evaluation подход, который позволяет автоматизировать оценку качества AI-систем.
LLM-as-a-Judge - это когда одна AI-модель оценивает качество ответов другой модели.
LLM-as-a-Judge получает исходный вопрос, ответ вашей системы и критерии оценки. Возвращает структурированную оценку с обоснованием: "Ответ релевантен (8/10), фактически точен (7/10), хорошо структурирован (9/10)".
Представьте: вам нужно оценить качество тысяч ответов чат-бота ежедневно. Человеческая оценка займет недели, автоматические математические метрики могут упустить нюансы или завышать/занижать оценку. LLM-судья дает почти человеческое понимание за секунды.
Продвинутые подходы:
Декомпозиция на атомарные утверждения, когда вместо оценки всего ответа система разбивает его на отдельные проверяемые факты. Каждое утверждение оценивается независимо по шкале: fully (1.0), mostly (0.9), partial (0.6), minor (0.3), none (0.0). Далее высчитывается среднее по всем баллам утвержений, что и является финальной оценкой.
Парные сравнения, когда модель сравнивает два ответа и определяет лучший. Часто надежнее абсолютных оценок.
Основные преимущества такого подхода, это близость к человеческому суждению, объяснимость результатов, гибкость настройки под домены.
Но есть важные нюансы, о которых стоит помнить:
Bias полезности: у AI есть склонность завышать оценки любых связных ответов.
Стоимость: каждая оценка требует вызов API к мощной модели, который чаще всего стоит денег. Но я бы не сказал, что это какие-то большие суммы, например, на моих проекта стоимость одного раунда evlaution из датасета 200-300 вопросов стоит 1-2 $.
Поэтому важно использовать AI модели не в лоб, предоставляя им в одном промпте и задачу оценить ту или иную метрику и исходные данные для оценки, а стараться, что AI косвенно оценивал результаты, например, через декомпозицию на атомарные утверждения.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
👍3🔥1
Сегодня хочу рассказать про важное исследование "A Survey on Evaluation of Large Language Models”, комплексный обзор методов оценки LLM, который должен знать каждый, кто работает с AI.
Исследование структурировано по трем ключевым вопросам:
Что оценивать: авторы проанализировали evaluation в 8 областях: от классических NLP задач до медицины, этики и AI-агентов. Особенно интересны выводы о том, где LLM показывают хорошие результаты (sentiment analysis, логические рассуждения, генерация текста), а где проваливаются (abstract reasoning, работа с не латинскими языками, устойчивость к атакам через промпты).
Где оценивать: обзор 46 популярных бенчмарков от общих (MMLU, HELM, BIG-bench) до специализированных (MATH для математики, TrustGPT для этики, MME для мультимодальных задач).
Как оценивать: сравнение автоматических метрик (accuracy, calibration, fairness, robustness) и human evaluation. Авторы отмечают растущую важность человеческой оценки для творческих задач, где базовые метрики не работают.
Ключевые тренды в evaluation:
- Переход от статических к динамическим бенчмаркам
- Рост краудсорсинг тестирования (DynaBench, DynaBoard)
- Фокус на безопасность (PromptBench показал уязвимость LLM к adversarial промптам)
- Постепенный сдвиг в сторону Human-in-the-loop подходов
Главные выводы исследования: LLM отлично справляются с пониманием языка и генерацией, но проваливаются в abstract reasoning и robustness. Существующие протоколы evaluation недостаточны для полной оценки возможностей современных LLM.
Если занимаетесь evaluation AI, это обязательно к прочтению. 45 страниц систематизированного знания с GitHub репозиторием для практического применения.
И финально, исследование показывает, что evaluation должен стать отдельной дисциплиной для успешного развития LLM.
Ссылка на исследование
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
Исследование структурировано по трем ключевым вопросам:
Что оценивать: авторы проанализировали evaluation в 8 областях: от классических NLP задач до медицины, этики и AI-агентов. Особенно интересны выводы о том, где LLM показывают хорошие результаты (sentiment analysis, логические рассуждения, генерация текста), а где проваливаются (abstract reasoning, работа с не латинскими языками, устойчивость к атакам через промпты).
Где оценивать: обзор 46 популярных бенчмарков от общих (MMLU, HELM, BIG-bench) до специализированных (MATH для математики, TrustGPT для этики, MME для мультимодальных задач).
Как оценивать: сравнение автоматических метрик (accuracy, calibration, fairness, robustness) и human evaluation. Авторы отмечают растущую важность человеческой оценки для творческих задач, где базовые метрики не работают.
Ключевые тренды в evaluation:
- Переход от статических к динамическим бенчмаркам
- Рост краудсорсинг тестирования (DynaBench, DynaBoard)
- Фокус на безопасность (PromptBench показал уязвимость LLM к adversarial промптам)
- Постепенный сдвиг в сторону Human-in-the-loop подходов
Главные выводы исследования: LLM отлично справляются с пониманием языка и генерацией, но проваливаются в abstract reasoning и robustness. Существующие протоколы evaluation недостаточны для полной оценки возможностей современных LLM.
Если занимаетесь evaluation AI, это обязательно к прочтению. 45 страниц систематизированного знания с GitHub репозиторием для практического применения.
И финально, исследование показывает, что evaluation должен стать отдельной дисциплиной для успешного развития LLM.
Ссылка на исследование
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
👍4❤1🔥1
ТОП-10 ЧАСТЫХ ОШИБОК В РАБОТЕ AI АГЕНТОВ
Сегодня разберем топ-10 частых ошибок в работе AI агентов, которые критически важно проверять при тестировании агентских систем. Если тестируете AI агентов, то этот список поможет сфокусироваться на ключевых проблемах.
1. Зацикливание (Infinite Loops). Агент повторяет одни и те же действия бесконечно, например, агент пытается получить информацию, но получает ошибку или считает, что информации недостаточно для продолжения работы и повторяет запрос снова и снова.
2. Неправильная декомпозиция задач. Агент разбивает сложную задачу на неправильные подзадачи или слишком мелко дробит простые задачи. Например, для "забронировать отель" создает 15 подзадач вместо 3-4 логичных шагов. Тестируйте планирование выполнения AI агентами на задачах разной сложности.
3. Потеря контекста между действиями. AI Агент "забывает" результаты предыдущих шагов и принимает решения без учета контекста. Особенно критично в задачах с длинной логикой. Проверяйте сохранение состояний между шагами.
4. Неэффективное использование инструментов. Агент вызывает API или сервис с неправильными параметрами, использует медленные инструменты вместо быстрых, или вызывает один инструмент несколько раз подряд. Мониторьте вызовы и ищите паттерны неэффективности.
5. Плохая обработка ошибок. При получении ошибки AI агент либо останавливается, либо игнорирует ошибку и продолжает с некорректными данными. Тестируйте поведение при различных типах ошибок, как вариант, использовать мокирование сервисов.
6. Неточная интерпретация результатов. Агент неправильно понимает ответы от инструментов. Например, API возвращает "no results found", а агент интерпретирует это как успешный результат. Проверяйте обработку граничных ответов.
7. Избыточная детализация планов. AI агент создает слишком подробные планы для простых задач, тратя время на планирование вместо выполнения. Оценивайте соотношение времени планирования к выполнению.
8. Неправильные приоритеты. Агент фокусируется на неважных деталях, игнорируя ключевые аспекты задачи. Например, при анализе проблемы тратит время на форматирование отчета вместо поиска решения. Проверяйте согласованность агента с целями задачи.
9. Отсутствие валидации финального результата. AI агент не проверяет, действительно ли задача выполнена. Может "завершить" задачу с частичным результатом. Тестируйте завершенность финальных результатов.
10. Галлюцинации в промежуточных шагах. AI агент "придумывает" результаты действий, которые не были выполнены, или неправильно интерпретирует внешние данные. Сравнивайте заявленные результаты с фактическими данными.
Практические советы для тестирования:
- Анализируйте все действия агента для анализа паттернов ошибок
- Создавайте тест кейсы для каждого типа ошибок
- Тестируйте крайние случаи и сценарии отказов
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
Сегодня разберем топ-10 частых ошибок в работе AI агентов, которые критически важно проверять при тестировании агентских систем. Если тестируете AI агентов, то этот список поможет сфокусироваться на ключевых проблемах.
1. Зацикливание (Infinite Loops). Агент повторяет одни и те же действия бесконечно, например, агент пытается получить информацию, но получает ошибку или считает, что информации недостаточно для продолжения работы и повторяет запрос снова и снова.
2. Неправильная декомпозиция задач. Агент разбивает сложную задачу на неправильные подзадачи или слишком мелко дробит простые задачи. Например, для "забронировать отель" создает 15 подзадач вместо 3-4 логичных шагов. Тестируйте планирование выполнения AI агентами на задачах разной сложности.
3. Потеря контекста между действиями. AI Агент "забывает" результаты предыдущих шагов и принимает решения без учета контекста. Особенно критично в задачах с длинной логикой. Проверяйте сохранение состояний между шагами.
4. Неэффективное использование инструментов. Агент вызывает API или сервис с неправильными параметрами, использует медленные инструменты вместо быстрых, или вызывает один инструмент несколько раз подряд. Мониторьте вызовы и ищите паттерны неэффективности.
5. Плохая обработка ошибок. При получении ошибки AI агент либо останавливается, либо игнорирует ошибку и продолжает с некорректными данными. Тестируйте поведение при различных типах ошибок, как вариант, использовать мокирование сервисов.
6. Неточная интерпретация результатов. Агент неправильно понимает ответы от инструментов. Например, API возвращает "no results found", а агент интерпретирует это как успешный результат. Проверяйте обработку граничных ответов.
7. Избыточная детализация планов. AI агент создает слишком подробные планы для простых задач, тратя время на планирование вместо выполнения. Оценивайте соотношение времени планирования к выполнению.
8. Неправильные приоритеты. Агент фокусируется на неважных деталях, игнорируя ключевые аспекты задачи. Например, при анализе проблемы тратит время на форматирование отчета вместо поиска решения. Проверяйте согласованность агента с целями задачи.
9. Отсутствие валидации финального результата. AI агент не проверяет, действительно ли задача выполнена. Может "завершить" задачу с частичным результатом. Тестируйте завершенность финальных результатов.
10. Галлюцинации в промежуточных шагах. AI агент "придумывает" результаты действий, которые не были выполнены, или неправильно интерпретирует внешние данные. Сравнивайте заявленные результаты с фактическими данными.
Практические советы для тестирования:
- Анализируйте все действия агента для анализа паттернов ошибок
- Создавайте тест кейсы для каждого типа ошибок
- Тестируйте крайние случаи и сценарии отказов
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
👍6🔥3❤1
Сегодня разберем тему, которую многие недооценивают, а именно важность человеческой оценки. Да, метрики с оценкой от LLM-судьи или математические удобны, но они не заменяют человеческую оценку полностью.
Автоматические метрики дают объективную оценку качества ИИ. На практике они часто промахиваются мимо того, что действительно важно пользователям.
Где автоматические метрики подводят:
Творческие задачи. Автоматические метрики дают низкую оценку хорошему переводу, если он отличается от эталона.
Понимание контекста. Метрики не оценивают уместность тона ответа в конкретной ситуации.
Эмпатия и эмоциональный интеллект. Никакая метрика не измеряет способность проявить эмпатию к пользователю.
Культурные нюансы. Автоматика не улавливает сарказм, культурные отсылки и контекстную уместность.
Практическая полезность. Метрики не показывают, действительно ли ответ помогает решить проблему пользователя.
Оптимальный подход:
Этап 1: Автоматическая предварительная фильтрация Используйте автоматические метрики для первичной фильтрации. Это позволяет быстро отсеять явно плохие результаты и сфокусировать человеческую оценку на спорных случаях.
Этап 2: Человеческая проверка отфильтрованных данных
Люди оценивают результаты, прошедшие автоматический фильтр, по критериям, которые машины не могут измерить: релевантность, полезность, уместность, пользовательский опыт.
Этап 3: Калибровка метрик Используйте обратную связь людей для калибровки автоматических метрик. Если люди систематически не согласны с автоматическими оценками по определенным типам задач, то это сигнал пересмотреть метрики.
Автоматические метрики - это отличный инструмент предварительной проверки, но окончательную оценку качества должен делать человек. Лучший подход — гибридный конвейер оценки, где автоматика делает основную работу, а человек принимает финальные решения.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
Автоматические метрики дают объективную оценку качества ИИ. На практике они часто промахиваются мимо того, что действительно важно пользователям.
Где автоматические метрики подводят:
Творческие задачи. Автоматические метрики дают низкую оценку хорошему переводу, если он отличается от эталона.
Понимание контекста. Метрики не оценивают уместность тона ответа в конкретной ситуации.
Эмпатия и эмоциональный интеллект. Никакая метрика не измеряет способность проявить эмпатию к пользователю.
Культурные нюансы. Автоматика не улавливает сарказм, культурные отсылки и контекстную уместность.
Практическая полезность. Метрики не показывают, действительно ли ответ помогает решить проблему пользователя.
Оптимальный подход:
Этап 1: Автоматическая предварительная фильтрация Используйте автоматические метрики для первичной фильтрации. Это позволяет быстро отсеять явно плохие результаты и сфокусировать человеческую оценку на спорных случаях.
Этап 2: Человеческая проверка отфильтрованных данных
Люди оценивают результаты, прошедшие автоматический фильтр, по критериям, которые машины не могут измерить: релевантность, полезность, уместность, пользовательский опыт.
Этап 3: Калибровка метрик Используйте обратную связь людей для калибровки автоматических метрик. Если люди систематически не согласны с автоматическими оценками по определенным типам задач, то это сигнал пересмотреть метрики.
Автоматические метрики - это отличный инструмент предварительной проверки, но окончательную оценку качества должен делать человек. Лучший подход — гибридный конвейер оценки, где автоматика делает основную работу, а человек принимает финальные решения.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
👍5🔥3
Сегодня разберем метрики регрессии для ML моделей, а именно как правильно оценивать качество предсказания непрерывных значений, например, цены, температура, продажи в моделях машинного обучения.
RMSE (Root Mean Square Error):
Показывает среднеквадратичную ошибку модели. Ключевая особенность, она возводит ошибки в квадрат, поэтому большие ошибки в предсказаниях "штрафуются" сильнее маленьких.
Пример: предсказываем время доставки. Четыре заказа с ошибкой по 2 минуты, один с ошибкой 20 минут. RMSE = 9.1 минуты. Один выброс "испортил" всю оценку, хотя 80% предсказаний точные.
MAE (Mean Absolute Error):
Берет среднее от всех ошибок по модулю. В том же примере MAE = 5.6 минуты, что честнее отражает реальность.
MAE устойчив к выбросам, легко интерпретируется и не штрафует большие ошибки. Но когда большие разборы критичны для работы модели, то используем оценку RMSE.
R² (Coefficient of Determination):
Показывает, какую долю изменений в данных объясняет модель.
Пример с ценами домов: дома стоят 300K, 450K, 700K. Если модель всегда предсказывает среднюю цену 483K, то ошибки получаются огромные (например, 483K и 700к).
Умная модель учитывает, например, площадь, район, год постройки и предсказывает уже $320K, $470K, $680K и ошибок тут уже намного меньше. R² = 0.75 означает "наша модель объясняет 75% различий в ценах домов" определенными параметрами.
Quantile Regression:
Вместо "доставка займет 30 минут" дает "с 90% вероятностью от 20 до 45 минут". Критически важно для медицины, финансов, автопилотов — везде, где нужны гарантии.
Как выбрать:
RMSE - когда большие ошибки в предсказаниях критичны
MAE - когда есть выбросы, но все ошибки равноважны
R² - для сравнения моделей, обученных по разным технологиям
Quantile - когда нужно понимать, в каком диапазоне неопределенности работает модель
Важно понимать, что каждая метрик освещает разные аспекты модели и помогает принимать решения о качестве предсказаний.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
RMSE (Root Mean Square Error):
Показывает среднеквадратичную ошибку модели. Ключевая особенность, она возводит ошибки в квадрат, поэтому большие ошибки в предсказаниях "штрафуются" сильнее маленьких.
Пример: предсказываем время доставки. Четыре заказа с ошибкой по 2 минуты, один с ошибкой 20 минут. RMSE = 9.1 минуты. Один выброс "испортил" всю оценку, хотя 80% предсказаний точные.
MAE (Mean Absolute Error):
Берет среднее от всех ошибок по модулю. В том же примере MAE = 5.6 минуты, что честнее отражает реальность.
MAE устойчив к выбросам, легко интерпретируется и не штрафует большие ошибки. Но когда большие разборы критичны для работы модели, то используем оценку RMSE.
R² (Coefficient of Determination):
Показывает, какую долю изменений в данных объясняет модель.
Пример с ценами домов: дома стоят 300K, 450K, 700K. Если модель всегда предсказывает среднюю цену 483K, то ошибки получаются огромные (например, 483K и 700к).
Умная модель учитывает, например, площадь, район, год постройки и предсказывает уже $320K, $470K, $680K и ошибок тут уже намного меньше. R² = 0.75 означает "наша модель объясняет 75% различий в ценах домов" определенными параметрами.
Quantile Regression:
Вместо "доставка займет 30 минут" дает "с 90% вероятностью от 20 до 45 минут". Критически важно для медицины, финансов, автопилотов — везде, где нужны гарантии.
Как выбрать:
RMSE - когда большие ошибки в предсказаниях критичны
MAE - когда есть выбросы, но все ошибки равноважны
R² - для сравнения моделей, обученных по разным технологиям
Quantile - когда нужно понимать, в каком диапазоне неопределенности работает модель
Важно понимать, что каждая метрик освещает разные аспекты модели и помогает принимать решения о качестве предсказаний.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
👍3🔥1
Всем привет!
Сегодня разберем почему знания 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
Сегодня разберем почему знания 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
👍4❤1🔥1
Сегодня разберем различные архитектуры 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
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
👍5🔥1
Сегодня поговорим о том, почему оценка качества AI-систем стала критически важной.
Современный AI переживает революцию: от простых классификаторов мы дошли до моделей, которые пишут код, создают изображения, управляют роботами. Но вместе с этим пришли и новые вызовы.
1. Масштаб.
Модели обучаются на терабайтах данных, и классические методы вроде cross-validation уже не работают, потому что это слишком дорого и сложно.
2. Черный ящик.
Почему GPT-4 или 5 дает именно такой ответ или как Stable Diffusion выбирает детали изображения, нам понять практически невозможно. Поэтому оценка современных генеративный AI решений фокусируется на оценке результата.
3. Ответственность.
AI всё чаще работает в критичных сферах: медицина, финансы, автономное вождение. Ошибка в диагнозе - это уже вопрос жизни.
Еще 5 лет назад все было проще. Для классификация, перевод, распознавание речи были стандартные метрики, например, accuracy, BLEU, WER. Сегодня этого стало недостаточно.
Что изменилось:
- Появились LLM и генеративный AI, в которых нужно оценить креативность картинки или полезность ответа.
- Модели стали мультизадачными: пишут код, пишут тексты, создают картинки и видео. Одной метрики для их оценки теперь мало.
- На первый план вышли новые типы проблем, которых раньше не было, а именно предвзятость, справедливость, галлюцинации, безопасность и согласованность.
Именно поэтому сегодня evaluation - это уже не просто подбор метрик, а отдельная дисциплина, которая определяет, насколько безопасно и надежно мы можем доверять современным AI-системам.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
Современный AI переживает революцию: от простых классификаторов мы дошли до моделей, которые пишут код, создают изображения, управляют роботами. Но вместе с этим пришли и новые вызовы.
1. Масштаб.
Модели обучаются на терабайтах данных, и классические методы вроде cross-validation уже не работают, потому что это слишком дорого и сложно.
2. Черный ящик.
Почему GPT-4 или 5 дает именно такой ответ или как Stable Diffusion выбирает детали изображения, нам понять практически невозможно. Поэтому оценка современных генеративный AI решений фокусируется на оценке результата.
3. Ответственность.
AI всё чаще работает в критичных сферах: медицина, финансы, автономное вождение. Ошибка в диагнозе - это уже вопрос жизни.
Еще 5 лет назад все было проще. Для классификация, перевод, распознавание речи были стандартные метрики, например, accuracy, BLEU, WER. Сегодня этого стало недостаточно.
Что изменилось:
- Появились LLM и генеративный AI, в которых нужно оценить креативность картинки или полезность ответа.
- Модели стали мультизадачными: пишут код, пишут тексты, создают картинки и видео. Одной метрики для их оценки теперь мало.
- На первый план вышли новые типы проблем, которых раньше не было, а именно предвзятость, справедливость, галлюцинации, безопасность и согласованность.
Именно поэтому сегодня evaluation - это уже не просто подбор метрик, а отдельная дисциплина, которая определяет, насколько безопасно и надежно мы можем доверять современным AI-системам.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
👍5🔥1
Сегодня хочу с вами разобрать классификацию 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:
Машинное обучение (ML)
Алгоритмы, которые учатся на данных: классификация, регрессия, деревья решений, ансамбли. Применяются в прогнозах, рекомендациях, анализе рисков.
Глубокое обучение (DL)
Нейросети, которые сделали возможным компьютерное зрение, распознавание речи и большие языковые модели.
Компьютерное зрение (CV)
Системы, которые «видят» и понимают изображения: от распознавания лиц до диагностики по снимкам.
Обработка естественного языка (NLP)
Переводчики, чат-боты, поиск, анализ тональности текста, все, что связано с пониманием и генерацией языка.
Генеративный AI
Модели, создающие тексты, картинки, музыку, видео и код. ChatGPT, MidJourney, Stable Diffusion относятся сюда.
AI в робототехнике
Алгоритмы для автономных дронов, автомобилей и промышленных роботов, которые принимают решения в реальном мире.
Важно понимать, что AI не равно только ChatGPT. Это целый спектр технологий от аналитических моделей до автономных систем, которые меняют наше взаимодействие с цифровым и физическим миром.
И на моем курсе по тестированию и оценке AI, который стартует уже 08.09, мы будем разибрать, как выполнять оценку практически всех направлений. кроме робототехники. Так что если вы еще не успели записаться на курс, то сейчас самое время это сделать по ссылке https://eval-ai.com
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
👍5🔥2
Сегодня разберем, как оценивают AI-системы для генерации изображений.
Если с текстовыми моделями все более менее понятно, можно замерить точность ответа, проанализировать набор слов во фразе, изучить семантику и так далее, то вот с картинками всё сложнее, потому что не всегда понятно как измерить «красоту», «реализм» или «креативность»?
Представим, что мы дали промпт: «Кот в космическом скафандре на Марсе» и получили картинку.
Ключевые подходы:
Автоматические метрики
⁃ FID (Fréchet Inception Distance). Мы сравниваем распределение признаков изображения с реальными фото. Если картинка выглядит «живой» и не содержит серьезных искажений, FID будет низким. Это значит, картинка приближена к реальности.
⁃ IS (Inception Score). Модель ИИ «смотрит» на изображение и решает, насколько оно четкое и однозначно распознается.
Пример: если на картинке действительно виден кот в скафандре, и нейросеть уверенно определяет это как «кошка», а не путает с «собака» или «инопланетянин», то IS будет высоким. Если же изображение размытое и непонятно, что балл ниже.
⁃ CLIPScore. Сравнивает текст запроса с изображением. Если «кот в скафандре» реально совпадает с тем, что видим, то метрика высокая. Если скафандра нет, а модель нарисовала просто кота на красном фоне, то CLIPScore будет низким.
Human evaluation
Часто метрики так или иначе не отражают субъективное восприятие. Поэтому экспертная оценка по прежнему остается важной при оценкие генерации картинок по критериям:
⁃ реализм
⁃ креативность
⁃ соответствие запросу.
Специализированные тесты
Например, проверка на bias (гендерные или культурные стереотипы), устойчивость к токсичным промптам и способность работать с редкими объектами.
Главная проблема: автоматические метрики не всегда совпадают с человеческим восприятием.
Поэтому сегодня активно развивается гибридный подход FID/CLIPScore + human evaluation, который позволяет более точно оценить работу ИИ для генерации картинок.
Полезная информация:
Курс по evaluation 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
👍4🔥1
Я часто упониманию 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
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
👍5🔥2
Сегодня поговорим о Robustness testing через призму метаморфического тестирования.
Немного разберем, что такое метаморфическое тестирование. Это метод тестирования программного обеспечения, при котором проверка корректности основана не на самих результатах, а на метаморфических отношениях - ожидаемых зависимостях между входами и выходами программы.
Проще говоря:
Мы задаём системе вход X и получаем результат Y.
Затем трансформируем вход (например, перефразируем запрос, добавляем шум, изменяем порядок элементов) и получаем новый результат Y1.
Вместо того чтобы знать точное значение Y1, мы проверяем, что оно связано с Y через заранее определённое правило (метаморфизм).
Теперь вернемся к проверке устойчивости AI к перефразировкам и шуму.
Смысл простой:
Если модель правильно отвечает на вопрос «Какая столица у Франции?», то и на все перефразировки («Франция столица какого города?», «Столичный город Франции?») она должна давать тот же корректный ответ — «Париж».
Это и есть метаморфизм: изменяя входные данные (перефраз, шум, опечатка), мы ожидаем, что результат должен остаться инвариантным или близко похожим к оригинальному (наш Y1).
Как формировать датасеты для такого тестирования:
⁃ Берем базовый набор запросов с известным правильным ответом.
⁃ Автоматически генерируем перефразировки (через LLM, шаблоны или вручную).
⁃ Добавляем «шумные» варианты: опечатки, случайные символы, жаргон.
Что это дает?
Мы строим не просто тестовый набор, а семейства запросов, которые проверяют:
1. Сохраняет ли модель правильность при изменении формы вопроса?
2. Насколько она устойчива к «грязным» данным?
3. Есть ли случаи, где она внезапно «ломается» и начинает галлюцинировать?
По сути, Robustness testing - это частный случай метаморфического тестирования. Мы заранее знаем правильный ответ и проверяем, что он не изменяется серьезно при трансформации запроса.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
Немного разберем, что такое метаморфическое тестирование. Это метод тестирования программного обеспечения, при котором проверка корректности основана не на самих результатах, а на метаморфических отношениях - ожидаемых зависимостях между входами и выходами программы.
Проще говоря:
Мы задаём системе вход X и получаем результат Y.
Затем трансформируем вход (например, перефразируем запрос, добавляем шум, изменяем порядок элементов) и получаем новый результат Y1.
Вместо того чтобы знать точное значение Y1, мы проверяем, что оно связано с Y через заранее определённое правило (метаморфизм).
Теперь вернемся к проверке устойчивости AI к перефразировкам и шуму.
Смысл простой:
Если модель правильно отвечает на вопрос «Какая столица у Франции?», то и на все перефразировки («Франция столица какого города?», «Столичный город Франции?») она должна давать тот же корректный ответ — «Париж».
Это и есть метаморфизм: изменяя входные данные (перефраз, шум, опечатка), мы ожидаем, что результат должен остаться инвариантным или близко похожим к оригинальному (наш Y1).
Как формировать датасеты для такого тестирования:
⁃ Берем базовый набор запросов с известным правильным ответом.
⁃ Автоматически генерируем перефразировки (через LLM, шаблоны или вручную).
⁃ Добавляем «шумные» варианты: опечатки, случайные символы, жаргон.
Что это дает?
Мы строим не просто тестовый набор, а семейства запросов, которые проверяют:
1. Сохраняет ли модель правильность при изменении формы вопроса?
2. Насколько она устойчива к «грязным» данным?
3. Есть ли случаи, где она внезапно «ломается» и начинает галлюцинировать?
По сути, Robustness testing - это частный случай метаморфического тестирования. Мы заранее знаем правильный ответ и проверяем, что он не изменяется серьезно при трансформации запроса.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
👍4🔥1
Когда мы говорим об оценке 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
Современные модели умеют выдавать ответы, которые выглядят правильно. Проблема в том, что иногда они (модели) угадывают, а иногда придумывают объяснения постфактум. Для критичных областей этого мало, потому что нужен не только правильный ответ, но и понятная логика за ним.
Немного по терминам:
Explainability - насколько прозрачно и понятно человеку решение модели.
Correctness of Reasoning - насколько корректна сама логическая цепочка рассуждений.
Что именно мы оцениваем?
⁃ Насколько объяснение модели прозрачно и понятно человеку.
⁃ Насколько reasoning действительно отражает внутренние шаги, а не случайный текст «для красоты».
Как это оценивать:
⁃ Сравнивать объяснения на близких примерах: если ответы одинаковые, логика тоже должна совпадать (вспоминаем прошлый пост про Метаморфические тесты).
⁃ Проверять, действительно ли объяснение модели опирается на внутренние признаки модели, а не выдумано постфактум (Faithfulness tests).
⁃ Использовать датасеты, где вместе с ответами зафиксированы правильные рассуждения, например, Chain-of-Thought Hub или XAI datasets
⁃ Подключать экспертов, потому что человек быстро замечает, если объяснение звучит убедительно, но не имеет отношения к задаче.
Простой пример:
AI рекомендует фильм и поясняет: «Мы выбрали его, потому что вы смотрели комедии с этим актёром». Если объяснение совпадает с логикой работы алгоритма — reasoning корректен. Но если в реальности рекомендация основана на рекламных приоритетах, а «актёр» просто добавлен для убедительности — reasoning рушится.
По сути, explainability evaluation - это проверка доверия, можно ли положиться на логику модели так же, как на её финальный ответ.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
👍5❤1🔥1
Сегодня про 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
Представьте запрос: “Посчитай счёт 860 ₽ + 15% чаевых”. Сильное ИИ решение планирует шаги, вызывает калькулятор, получает 989 и возвращает итог. Слабое ИИ решение считает в голове, складывает 860 + 15, пишет 875, что выглядит уверенно, но выбор инструмента и интерпретация задачи провалены.
Оценка здесь - это не просто сверка числа. Мы смотрим, приняла ли модель правильное решение звать инструмент, корректно ли передала аргументы, не исказила ли результат и не потеряла ли шаги по дороге. Тот же запрос, переформулированный как “начисли 15% на 860” или “добавь 15% чаевых к 860”, должен приводить к той же последовательности действий и тому же результату - это проверка устойчивости и согласованности.
Где всё это видно на практике? В системах, которые собирают трейсы. Там по шагам фиксируются: намерение (например, нужен такой-то инструмент для ответа), сам вызов (имя инструмента и аргументы), ответ инструмента (сырой результат), интерпретация ответа моделью и финальный вывод. По таким трейсам легко заметить типовые сбои, например, инструмент не вызван, вызван не тот, аргументы перепутаны, ответ пришёл верный, но модель неверно его округлила или подставила не туда.
Для работы с трейсами используются трейсинг/обсервабилити-решения уровня приложения (например, LangSmith, Langfuse, Arize Phoenix, OpenLLMetry на базе OpenTelemetry): они как раз дают полный лог цепочки внутри ИИ агента, какие шаги были, в каком порядке, с какими параметрами и что на каждом шаге вернулось. Именно по таким следам и оценивается зрелость ИИ решения: планирование, выбор, корректное применение и честная интерпретация результата.
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI
👍5🔥2
Сегодня хочу поделиться мыслями о недавнем исследовании по оценке reasoning у LLM через Bayesian inference.
Авторы предлагают рассматривать работу модели через призму байесовского подхода: модель должна аккуратно обновлять свои вероятности, используемые для генерации ответа, при изменении входного контекста. Идея в том, что LLM может галлюцинировать и менять результаты в зависимости от порядка примеров или кусков текста (chunks).
По сути, это ещё один угол зрения на процесс генерации: насколько модель устойчива к изменению порядка фактов и насколько предсказуемо обновляет свои ответы.
Но есть нюанс: такая метрика оценивает не качество финального результата, а сам процесс рассуждений. Чтобы проверить её на практике, нужно уметь вручную менять порядок контекста и отслеживать, насколько сильно меняется ответ. В большинстве случаев итоговая релевантность останется прежней, поэтому ценность метрики может быть ограниченной, особенно если у нас уже используется reranking и порядок chunk’ов фиксирован.
Кстати, исследование проводилось на GPT-3, и пока не очевидно, насколько та же проблема проявляется в более современных моделях.
Как можно тестировать в таком духе:
1. Задаем один и тот же вопрос, но меняем порядок документов. Смотрим, насколько стабилен ответ. Байесовский агент должен выдавать одинаковый результат.
2. Добавляем документы по одному: сначала А документы → спрашиваем, потом А+B документы → спрашиваем, потом А+B+C документы. Байесовский ИИ агент в этом случае будет аккуратно накапливать знания, а не перескакивать между разными интерпретациями.
В итоге скажу, что это не метрика качества ответа, а скорее инструмент для проверки предсказуемости reasoning. Полезно для исследований, но в реальных проектах нужно взвешивать трудозатраты и реальную пользу.
Ссылка на исследование
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
Авторы предлагают рассматривать работу модели через призму байесовского подхода: модель должна аккуратно обновлять свои вероятности, используемые для генерации ответа, при изменении входного контекста. Идея в том, что LLM может галлюцинировать и менять результаты в зависимости от порядка примеров или кусков текста (chunks).
По сути, это ещё один угол зрения на процесс генерации: насколько модель устойчива к изменению порядка фактов и насколько предсказуемо обновляет свои ответы.
Но есть нюанс: такая метрика оценивает не качество финального результата, а сам процесс рассуждений. Чтобы проверить её на практике, нужно уметь вручную менять порядок контекста и отслеживать, насколько сильно меняется ответ. В большинстве случаев итоговая релевантность останется прежней, поэтому ценность метрики может быть ограниченной, особенно если у нас уже используется reranking и порядок chunk’ов фиксирован.
Кстати, исследование проводилось на GPT-3, и пока не очевидно, насколько та же проблема проявляется в более современных моделях.
Как можно тестировать в таком духе:
1. Задаем один и тот же вопрос, но меняем порядок документов. Смотрим, насколько стабилен ответ. Байесовский агент должен выдавать одинаковый результат.
2. Добавляем документы по одному: сначала А документы → спрашиваем, потом А+B документы → спрашиваем, потом А+B+C документы. Байесовский ИИ агент в этом случае будет аккуратно накапливать знания, а не перескакивать между разными интерпретациями.
В итоге скажу, что это не метрика качества ответа, а скорее инструмент для проверки предсказуемости reasoning. Полезно для исследований, но в реальных проектах нужно взвешивать трудозатраты и реальную пользу.
Ссылка на исследование
Полезная информация:
Курс по evaluation AI |
С чего начать изучение AI | Инструменты для оценки AI |
Инструменты для оценки AI (ч.2)
👍6🔥1
Сегодня хочу обсудить интересную тему: 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)
Обычно мы говорим о внешней оценке, например, метрики, бенчмарки, 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)
👍6