Когда вы запустили чат-бота или AI-ассистента, то в большинстве случаев он отвечает, и по делу, но как понять, что он действительно работает?

Для диалоговых систем нужны метрики, которые ловят именно суть взаимодействия, поэтому я выделил 7 метрик, которые стоит использовать при оценке диалоговых ИИ агентов.

1. Task Success Rate
Выполнила ли AI система задачу, для которой она была создана .
2. Goal Achievement Rate
Получил ли пользователь то, что он на самом деле хотел, а не просто формальный результат.
3. Role Adherence Rate
Остается ли AI в рамках своей роли, тона и компетенции на протяжении всего диалога.
4. Knowledge Retention Rate
Помнит ли система контекст, который пользователь уже сообщил ранее в разговоре.
5. Conversational Flow Rate
Насколько естественно и связно проходит диалог, без лишних переспросов, повторов и игнорирования сигналов пользователя.
6. Repetitive Pattern Detection
Зацикливается ли агент, повторяя одни и те же действия или ответы вместо продвижения к решению.
7. Failure Rate
Как AI система ведет себя, когда не знает ответа, выдумывает, зависает или честно предлагает альтернативу.

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

Какие метрики используете вы при оценке диалогов? Есть что добавить?


⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 7 мая! 🔥

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

Команда Galileo выпустила интересный отчет по оценке ИИ систем за 1 квартал 2026 года, где они опросили около 500 компаний на предмет практик тестирования ИИ систем.

В целом, я считаю, что некоторые оценки завышены, но тем не менее интересные инсайты о данном направлении.

Чтобы вам не скачивать его, отчет во вложении)


⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 7 мая! 🔥

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

Всем привет!

Осталось всего 5 дней, чтобы оставить заявку и получить скидку 10% на курс по оценке и тестированию ИИ систем, поэтому, если вы хотели, то сейчас самое время записаться на новый поток, который стартует 7 мая!

Оставить заявку можно по ссылке eval-ai.com


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

Недавно мне показали очень интересную AI концепцию, которая меня зацепила.

В чем суть? Вместо создания ИИ агента, который решает конкретную задачу в тестировании, например, формирование тестового покрытия или написания автотестов, концепция сводится к созданию полноценного участника команды, который подключен ко всем внутренним ресурсам компании, конфлюенс, таст треккер, гитхаб, командному чату, tms системе.

И тут важна не сама реализация, а то, как мы меняем наше мышление при взаимодейтсвии с ИИ.

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

В общем, ситуация на рынке, как минимум в Европе и США уже стала сложной из-за ИИ, а так еще можно получить парочку коворкеров, которые могут решать различные задачи и помогать в процессе разработки ПО, что в целом предполагает не радужные перспективы 🥴.

⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 7 мая! 🔥

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

Всем привет!

Я провел анализ рынка тестирования AI, изучил различные отчеты Gartner, McKinsey, LangChain, Stanford, данные с Reddit и вот что я узнал.

Основной формат тестирования, который сейчас к сожалению преобладает в тестировании ИИ систем - это прогон промптов вручную, который я называют “vibe check” или “vibe testing”.

Более того из полученных данных я узнал, что:
• 29.5% команд, создающие AI-агенты, вообще их не оценивают или не понимают как (ссылка)
• 40 % компаний уже столкнулись с негативными последствиями от внедрения ИИ (ссылка)
• 90-95% проектов не доходят до стадии продакшен использования из-за проблем с данными или отсутствие понимания качества системы (ссылка)

И все что описано выше - это не проблема AI. Это проблема QA.

У нас есть десятилетия применения методологии для тестирования детерминированных систем, при этом для стохастических нет ничего.
• Нет стандартов.
• Нет общепринятых метрик.
• Нет даже консенсуса по тому, что такое хорошо работающая ИИ система.

И самое пугающее, что практика “vibe testing” в части ИИ систем по-прежнему активно распространена, то есть мы доверяем ИИ тестирование ИИ, при этом даже не понимая, насколько это правильно, то есть без возможности управлять этим процессом.

Что думаете по этому поводу?👇

⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 7 мая! 🔥

📌🔥Последний день получить скидку 10%!‼️

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

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

Компания Vectara, которая некоторое ведет публичный лидерборд по галлюцинациям LLM (ссылка тут), обновила свой бенчмарк, а именно усложнила датасет, добавила более длинные документы из области права, медицины и финансов, то есть то, с чем реально работают enterprise системы.

И вот что выявил обновленный датасет: reasoning модели, которые сейчас позиционируются как самые мощные, показывают худшие результаты на задачах суммаризации с опорой на документы или контекст. GPT-5, Claude Sonnet 4.5, Grok-4 и Gemini-3-Pro все превысили 10% галлюцинаций.

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

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

⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 7 мая! 🔥

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

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

Многие команды воспринимают автономность AI агента как цель и показатель зрелости системы, и получается, что чем меньше human-in-the-loop, тем лучше. Логика тут мне понятна, потому что мы хотим чтобы ИИ агент сам справлялся, не отвлекал людей, работал быстро. Но я думаю, что это в корне неправильная постановка вопроса.

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

Исследование Anthropic по Claude Mythos, где модель вышла за пределы изолированной среды и выложила детали своего побега в интернет — это не просто забавная история. Это хорошая иллюстрация того, что происходит когда система оптимизирует под задачу без достаточных ограничений и контроля.

На мой взгляд, правильный подход выглядит немного иначе, а именно нужно начинать с минимальной автономности и расширять её по мере того как система доказывает стабильное поведение в реальных условиях, например, сначала пробуем использовать для оценки импакт анализа, потом написания чек-листа, потом тестов с шагами и уже потом ручного тестирования. И такой процесс обучения не потому что мы не доверяем AI, а потому что это единственный способ понять где именно она работает надежно, а где еще нет и требуется донастройки
.
А как работает у вас в команде? Начали уже доверять ИИ свои задачи или пока нет? 👇


⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 7 мая! 🔥

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

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

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

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

Но при этом появился целый пласт новых задач, которых раньше просто не существовало. Как оценить качество ответа LLM, если у него нет одного правильного ответа? Как выстроить регрессионное тестирование для системы, которая по своей природе стохастична? Как обнаружить, что модель начала деградировать, если стандартный мониторинг этого не видит? Как тестировать агента, который принимает решения автономно?

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

⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 7 мая! 🔥

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

Кошмар вайбкодера😂😂😂


⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 7 мая! 🔥

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

Сегодня хочу рассказать про два интересных инструмента, которые я недавно увидел на рынке и которые закрывают нишу, про которую раньше почти никто не говорил, а именно тестирование голосовых AI агентов.

Cekura - платформа для автоматизированного тестирования и мониторинга голосовых и чат AI агентов. Она позволяет запускать симуляции разговоров с разными пользовательскими персонажами, тестировать как агент реагирует на прерывания, нестандартные сценарии и off-script поведение пользователей. Из интересного - это 25+ встроенных метрик специфичных именно для голоса, такие как gibberish detection, interruption tracking, latency, pitch, sentiment. Плюс поддержка 32 языков с учётом региональных акцентов, что важно если агент работает на глобальную аудиторию.

LambdaTest Agent-to-Agent Testing - это платформа для тестирования AI агентов. Идея в том, что один AI агент тестирует другой, генерируя разнообразные сценарии автоматически. Работает как для текстовых чат-ботов, так и для голосовых агентов. Вы загружаете требования в любом формате, например, текст, изображения, аудио, видео, и система генерирует тест-сценарии с метриками по bias, hallucinations, completeness, toxicity. Под капотом используется несколько LLM одновременно для более полного покрытия.

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

А вы сталкивались с задачей тестирования голосовых AI агентов? Как решали? 👇


⚡️⚡️Старт нового потока на курсе по тестированию ИИ - 7 мая! 🔥

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

Всем привет!

У меня хорошие новости, потому что недавно Anthropic запустил бесплатные курсы, в том числе и технические по работе с Claude Code, mcp и агентской архитектурой.

Я советую изучать сразу как работать Claude Code, например, Claude Code in Action, Claude Code 101, Introduction to Model Context Protocol, Introduction to agent skills.

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

ссылка на обучения


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

Недавно наткнулся на несколько исследований про over-reliance (чрезмерную зависимость) на AI, и хочу поделиться своим взглядом на эту тему, потому что она в последнее время активно обсуждается, но часто с неправильным углом.

Типичная позиция звучит так, что люди слишком доверяют AI, перестают думать сами, деградируют как специалисты. В этом есть доля правды, но я думаю, что сама постановка вопроса немного неверная.
Over-reliance - это не проблема использования AI, это проблема отсутствия понимания того, как AI принимает решения и где он ошибается.

Приведу пример из тестирования. Если тестировщик принимает все тест-кейсы, которые сгенерировал AI агент, без проверки - это over-reliance, но не потому что он использует AI, а потому что он не понимает, что агент оптимизирует под паттерны и систематически пропускает edge cases, которые в этих данных не встречались. Как только ты это понимаешь, ты начинаешь проверять именно эти места, и AI из источника риска превращается в инструмент, который реально ускоряет работу.

Поэтому мой взгляд такой, что да, over-reliance - это реальная проблема, но решается она не ограничением использования AI, а повышением экспертизы у тех, кто с ним работает. Нужно понимать не только как использовать инструмент, но и где он врет, где галлюцинирует, где уверенно ошибается.


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

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

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

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

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

Третья сложность - это сами провайдеры моделей, которые обновляют их без уведомления. То есть ваша AI система может начать вести себя иначе в продакшене даже если вы не меняли ничего со своей стороны. Стандартный CI/CD пайплайн это не поймает, потому что он запускается только при изменениях в вашем коде.

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

Как вы у себя решаете задачу регрессии для AI систем? Или пока это открытый вопрос? 👇


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

Галлюцинации в AI системах - это одна из тех тем, про которые все слышали, но мало кто понимает насколько по-разному они проявляются в зависимости от типа системы и насколько сложно их реально обнаружить.

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

В чистой LLM галлюцинация - это когда модель генерирует информацию, которой нет в реальности, но делает это уверенно и правдоподобно. Детектировать это сложно, потому что нет внешнего источника правды с которым можно сравнить ответ. Самый распространенный подход - это бенчмарки. TruthfulQA проверяет склонность модели воспроизводить распространённые заблуждения, HaluEval оценивает галлюцинации на задачах вопрос-ответ, диалогов и суммаризации, SimpleQA от OpenAI фокусируется на коротких фактических вопросах с однозначным ответом. Суть в том, что у нас есть размеченный датасет с правильными ответами, и мы можем измерить насколько часто модель отклоняется от них. Это воспроизводимо и сравнимо между моделями.

В RAG системе задача детекции теоретически проще, потому что есть контекст, а именно набор документов, которые были переданы модели. Галлюцинация здесь это когда модель генерирует что-то, что не поддерживается этим контекстом. Это можно проверить автоматически через faithfulness/groundness метрики. Но на практике есть нюанс: около 80% сбоев RAG систем происходят не на уровне генерации, а на уровне retrieval, то есть модель получает неправильный контекст и галлюцинирует уже на его основе. И тут faithfulness/groundness метрика покажет зеленый результат, потому что ответ формально соответствует переданному контексту, просто контекст был неправильный.

В агентных системах это становится еще сложнее. Агент может галлюцинировать на уровне выбора инструмента, на уровне аргументов которые он передаёт в tool call, на уровне интерпретации результата инструмента и на уровне финального ответа пользователю. Каждый из этих уровней нужно проверять отдельно, и каскадная ошибка на первом шаге может привести к уверенному неправильному ответу в конце, который очень сложно отследить до источника.

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

Сталкивались с галлюцинациями в своих AI системах? На каком уровне было сложнее всего их обнаружить? 👇


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

Сегодня я хотел вам напомнить о моей опенсорсной библиотеки по оценке систем на базе ИИ.

За последнее время библиотека несколько преобразилась, а именно:
• теперь есть поддержка более 50 различных AI провайдеров в качестве оценщика, включая готовую интеграцию для кастомных моделей, ollama self-hosted и MLX моделей
• расширилось количество агентских метрик до 9
• подключить свою ИИ систему можно просто как в Postman, просто указав параметры API запроса
• и много мелких правок дефектов!

Кроме того, мой фремворк запускается локально, и вы можете запускать оценки через нативный UI интерфейс.

Если вы еше не пробовали, как это работает, то полная документация доступна тут по ссылке library.eval-ai.com, установить можно простой командой

pip install eval-ai-library

после чего достаточно ввести к командной строке

eval-ai dashboard

Буду отдельно благодарен за звезды ⭐️ на github https://github.com/meshkovQA/Eval-ai-library, а также поддержку в развитии данного фреймворка!

Кроме того, если вас интересует подход, который я использую для вычисления метрик, то данную информацию вы также можете найти в моей работе на arxiv https://arxiv.org/abs/2604.08595


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

Всем привет!

Вчера с Сергеем провели совместный эфир на тему работы с Claude Code, в том числе в части создания агентов по тестированию.

Много говорили на эту тему, поэтому если вас интересует особенности работы с claude code в части тестирования, да и в целом про работу с ИИ моделями, то советую посмотреть!

Ссылка
https://www.youtube.com/watch?v=7tSGtTraWFs


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

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

Первый вопрос, который мне обычно задают - это какой инструмент использовать (или еще на курсе спрашивают, а будет ли мы изучать то-то). В итоге идет выбор инструмента, DeepEval, Promptfoo, Ragas, Opik Comet, дальше начинается обсуждение фич, интеграций, лицензий, получают какие-то цифры, и на этом часто все заканчивается, потому что что с этими цифрами делать дальше непонятно.

И вот в чём проблема.

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

Все это по факту методологические решения, которые остаются за человеком независимо от того, какой инструмент вы выбрали.

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

Сталкивались с такой ситуацией?


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

Периодически вижу в разных обсуждениях тему AI-assisted exploratory testing, и мнения, где одни говорят что это революция в тестировании, другие что очередной хайп. Хочу поделиться своим взглядом на эту тему.

Для начала стоит разделить два разных сценария, которые часто смешивают в одно.

Первый - это когда AI помогает тестировщику в процессе исследовательского тестирования. Генерирует идеи для тест-сценариев, предлагает edge cases на основе требований, помогает быстро разобраться в незнакомой части системы. Здесь AI реально полезен, потому что он расширяет охват того, о чем тестировщик может подумать, особенно в условиях ограниченного времени. Это работает, и я это вижу на практике.

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

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

Так что я бы сказал, что AI-assisted exploratory testing реально работает как усилитель тестировщика, но пока не как полноценная его замена. Если воспринимать его как инструмент, который помогает думать шире и быстрее, это ценно. Если ожидать что он заменит человеческое исследование системы, то пока это все лишь хайп.

А вы используете AI в exploratory testing? Что реально помогает, а что не оправдало ожиданий? 👇


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

5 выводов, которые я сделал за 3 года работы с ИИ проектами:

1. Не сильно важно, какой фреймворк вы используете, гораздо важнее какая методология лежит в основе оценки ИИ систем.
2. При все популярности базовых метрик, таких как Task Compliteness, Answer Relevancy, и так далее, вам все равно нужны будут ваша кастомные метрики под специфику ваших проектов.
3. Датасеты для позитивного, негативного, edge cases, метаморфического тестирования и прочего стоит делать и запускать отдельно.
4. Неважно насколько сильный или популярный фреймворк, вам все равно нужно будет делать ручной анализ результатов и трейсов.
5. Все говорят о том, что ИИ системам нельзя доверять, при этом еще не разу не видел выстроенного процесса оценки ИИ систем


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

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

Поэтому хотел узнать,если тут кто-то кто уже зававался этим вопросом и находил какие-то решения в части оптимизации?

То что знаю, это:
• промпт оптимизация
• кеширование
• легкие модели для простых задач
• управление моделями
• оптимизация памяти агента
• сокращение размера контекста


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