Метрики ИИ-продукта: полная система измерения точности модели, поведения пользователей и бизнес-результатов

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

Почему «ощущение» убивает ИИ-продукты

Есть такая болезнь среди команд, которые делают ИИ-продукты. Называется она «нам кажется, что модель стала умнее». Симптомы: команда показывает промпт коллеге, тот говорит «о, круто», все идут праздновать. Через неделю метрика конверсии падает на 12%. Никто не понимает почему. Все снова что-то трогают руками, снова кажется лучше - через неделю снова падает.

Начнём с простого вопроса: сколько ИИ-фич, которые вы запускали за последние два года, реально улучшили ключевые бизнес-показатели? Не «казалось, что улучшили», не «по отзывам коллег» - а по данным?

Исследования Gartner показывают, что около 85% ИИ-проектов не достигают своих заявленных целей. Это катастрофически много. И дело не в том, что модели плохие - они стали чудовищно хорошими. Дело в том, что команды не умеют измерять результат.

У ИИ-систем есть особенность, которой нет у обычного софта. Когда вы меняете алгоритм сортировки, результат детерминирован - можно написать юнит-тест, и он либо пройдёт, либо нет. Когда вы меняете промпт или версию модели, результат вероятностный. Одна и та же модель на одном и том же запросе может дать разные ответы. Это значит, что интуитивная оценка «попробовал три раза - работает» статистически бессмысленна.

Нужна система. Не сложная, не дорогая - но систематическая.

Три уровня метрик: от модели до денег

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

Уровень 1: технические метрики модели. Это то, что измеряется на уровне самой языковой модели или пайплайна. Accuracy, F1, BLEU, ROUGE, perplexity - всё это живёт здесь. Эти метрики говорят что-то про качество системы в изоляции от реального использования.

Уровень 2: продуктовые метрики. Это то, как ИИ-функциональность влияет на поведение пользователей. Время выполнения задачи, количество итераций до получения нужного результата, процент отказов, retention.

Уровень 3: бизнес-метрики. Выручка, конверсия, LTV, churn rate. Именно здесь живёт ответ на вопрос «зачем мы вообще это делаем».

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

Технические метрики: что это такое и когда какую применять

Точность и её производные

Accuracy - это доля правильных ответов. Но она коварна. Если у вас датасет, где 95% примеров одного класса, классификатор, который всегда отвечает «класс А», будет иметь accuracy 95%. Звучит хорошо - на практике катастрофа.

Поэтому для задач классификации, особенно с несбалансированными классами, нужны precision, recall и F1-score.

• Precision (точность) - сколько из тех, кого модель назвала «спамом», реально спам. Высокий precision значит: если модель говорит «это важно» - можно доверять.
• Recall (полнота) - сколько из реального спама модель поймала. Высокий recall значит: модель мало что пропускает.
• F1 - среднее гармоническое между ними. Полезен, когда нужен баланс между двумя предыдущими.

Практическое правило выбора: если пропустить плохой результат опасно (медицинская диагностика, антифрод) - приоритет recall. Если ложная тревога дорого обходится (спам-фильтр для важной почты) - приоритет precision. Если нужен баланс - F1.

Метрики для генерации текста

Здесь всё сложнее, потому что «правильного» ответа в явном виде часто нет.

BLEU (Bilingual Evaluation Understudy) - сравнивает сгенерированный текст с эталонными примерами, считая совпадающие n-граммы. Придуман для машинного перевода. Проблема: BLEU не учитывает семантику. Две фразы с одинаковым смыслом, но разными словами дадут низкий BLEU, хотя обе могут быть отличными ответами.

ROUGE - похож на BLEU, но ориентирован на recall. Чаще используется для оценки суммаризации.

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

Perplexity - мера того, насколько модель «удивлена» тестовым текстом. Низкая perplexity означает, что модель хорошо предсказывает следующий токен. Полезна для оценки языковых моделей, но почти не коррелирует с качеством конечного продукта.

Честный совет: если вы делаете генеративный ИИ-продукт - чат-бот, ассистент, summarizer - не надейтесь только на автоматические метрики. BLEU и ROUGE дадут вам число, но это число будет слабо связано с тем, доволен ли пользователь.

Latency и throughput: про скорость нельзя забывать

Модель может быть идеально точной, но если она отвечает 30 секунд - пользователь уйдёт. Исследования Google показывают, что задержка в 100ms уже влияет на конверсию.

• TTFT (Time to First Token) - время от отправки запроса до получения первого токена. Критично для стриминговых интерфейсов. Если TTFT больше 1-2 секунд, пользователь думает, что система зависла.
• TBT (Time Between Tokens) - скорость генерации последующих токенов. Если первый токен появился быстро, а дальше по одному символу в секунду - это тоже плохо.
• Total latency - общее время ответа. Для не-стримингового использования это единственная важная метрика.
• Throughput (tokens per second) - сколько токенов в секунду обрабатывает система. Критично для высоконагруженных систем.
• Cost per request - стоимость одного вызова модели. При масштабировании это становится ключевой операционной метрикой. Если GPT-4o стоит в 10 раз дороже GPT-4o-mini, а качество для вашей задачи одинаковое - вы просто сжигаете деньги.

Оценка качества: когда числа врут

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

Human evaluation: золотой стандарт

Человеческая оценка - дорого, медленно, субъективно. Но для многих задач это единственный надёжный способ.

Likert scale (1-5 или 1-7) - оценщик ставит балл по заданным критериям. Простой и понятный формат. Проблема: разные люди по-разному интерпретируют «3 из 5».

Pairwise comparison (A vs B) - показываем два ответа, оценщик выбирает лучший. Намного надёжнее, чем абсолютные оценки. Именно этот формат использует Anthropic для RLHF. Из него потом считается ELO-рейтинг - как в шахматах.

Direct Assessment - оценщик оценивает текст по нескольким независимым осям: fluency (грамотность), coherence (связность), relevance (релевантность), accuracy (фактологическая точность). Это позволяет понять, в чём именно проблема, а не просто «плохо».

Как организовать человеческую оценку с ограниченным бюджетом: используйте собственную команду для небольших выборок (50-100 примеров), и краудсорсинговые платформы типа Toloka или Scale AI - для больших. Обязательно калибруйте оценщиков: давайте им одинаковые примеры и смотрите на inter-annotator agreement. Kappa Коэна ниже 0.6 означает, что у вас нет консенсуса, и данные ненадёжны.

LLM-as-judge: модель оценивает модель

Последние два года популярна практика использовать мощную LLM - обычно GPT-4o или Claude - для оценки ответов другой модели. Это дешевле и быстрее, чем человеческая оценка, и при правильной настройке неплохо коррелирует с человеческими оценками.

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

Известные проблемы, о которых нужно знать:

• Position bias - LLM-judge предпочитает первый из двух предложенных вариантов.
• Length bias - длинные ответы получают более высокие оценки, даже если они хуже по содержанию.
• Self-preference - модели склонны оценивать выше ответы в своём стиле.
• Brittleness - небольшое изменение промпта судьи сильно меняет оценки.

Как с этим бороться: для pairwise comparison показывайте оба порядка (A,B) и (B,A) и усредняйте. Явно инструктируйте судью не предпочитать длинные ответы. Сравнивайте с human evaluation на репрезентативной выборке, чтобы убедиться в корреляции.

Хорошие фреймворки для LLM-as-judge: RAGAS (специально для RAG-систем), DeepEval, PromptFoo.

RAG-системы: отдельный разговор

Retrieval-Augmented Generation - это когда перед генерацией ответа система ищет релевантные документы в базе знаний. Популярная архитектура, но с ней связан целый набор специфических проблем.

Ошибки RAG-системы бывают двух типов: retrieval нашёл не то (плохой поиск) или retrieval нашёл нужное, но LLM неправильно использовала найденное (плохая генерация). Смешивать эти ошибки нельзя - иначе непонятно, что именно чинить.

Метрики для retrieval-части

• Precision@K - сколько из K найденных документов реально релевантны запросу. Если K=5 и 3 документа релевантны, Precision@5 = 0.6.
• Recall@K - какую долю всех релевантных документов нашла система среди топ-K. Если в базе 10 релевантных документов и система нашла 7, Recall@10 = 0.7.
• MRR (Mean Reciprocal Rank) - учитывает позицию первого правильного документа. Правильный документ на первом месте даёт вклад 1, на втором - 0.5, на третьем - 0.33. Потом усредняется по всем запросам.
• NDCG (Normalized Discounted Cumulative Gain) - более сложная метрика, которая учитывает и позицию, и степень релевантности, если документы могут быть «очень релевантны», «немного релевантны» или «нерелевантны».

Метрики для generation-части с контекстом

• Faithfulness (достоверность) - насколько ответ соответствует предоставленному контексту. Галлюцинирует ли модель факты, которых нет в найденных документах? Критически важная метрика для корпоративных RAG-систем.
• Answer Relevance - насколько ответ отвечает на заданный вопрос независимо от того, правдив он или нет.
• Context Utilization - использует ли модель весь релевантный контекст или игнорирует часть найденных документов.

Всё это хорошо считает фреймворк RAGAS - рекомендуем как отправную точку для любой RAG-системы.

Продуктовые метрики: где ИИ встречается с реальностью

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

Метрики качества взаимодействия

Task Completion Rate (TCR) - процент сессий, в которых пользователь достиг своей цели. Измеряется через явную обратную связь или косвенно - через поведенческие паттерны.

Number of turns to completion - сколько итераций переписки потребовалось для выполнения задачи. Если раньше нужно было 5 сообщений, а теперь 3 - это улучшение, даже если BLEU не изменился.

Fallback rate - как часто система возвращает generic ответ или говорит «я не знаю». Высокий fallback rate может означать как хорошую калибровку (система честно признаёт незнание), так и плохое покрытие базы знаний.

Containment rate - для чат-ботов: процент вопросов, решённых без эскалации к живому оператору. Классическая метрика для колл-центров с ИИ.

Метрики удовлетворённости

CSAT (Customer Satisfaction Score) - простой вопрос после взаимодействия: «Удовлетворены ли вы этим ответом?» Обычно шкала 1-5.

Thumbs up/down - бинарная версия CSAT. Почти все чат-боты это собирают. Проблема: люди ставят лайки редко. Тапают на дизлайк только когда очень расстроены. Лайки не информативны, а дизлайки смещены в сторону самых плохих случаев.

Implicit signals - вместо явной обратной связи смотрите на поведение: копирует ли пользователь ответ, продолжает ли разговор, возвращается ли снова. Это менее шумные данные.

Correction rate - как часто пользователи исправляют или уточняют ответ системы. «Нет, я имел в виду другое» - это сигнал, который нужно считать.

Engagement и retention

DAU/MAU ratio - отношение дневной аудитории к месячной. Показывает «привязчивость» продукта. Для хорошего продукта - выше 0.2, для отличного - выше 0.4.

Session length и session depth - сколько времени проводит пользователь в сессии и сколько взаимодействий совершает. Нет однозначной интерпретации: длинная сессия может означать и «пользователь вовлечён», и «пользователь не может найти нужное».

Return rate - возвращается ли пользователь. Самый честный показатель ценности продукта. Его сложнее подделать, чем CSAT.

A/B тестирование для ИИ: как не наступить на грабли

A/B тест - стандартный инструмент для измерения влияния изменений. Но с ИИ-системами есть нюансы, которые делают его сложнее, чем тест «красная кнопка vs зелёная кнопка».

Проблема 1: нестабильность вывода. В обычном A/B тесте кнопка либо синяя, либо зелёная. В ИИ-тесте один и тот же промпт может дать разные ответы при разных обращениях. Вам нужно намного больше данных для статистически значимого результата. Правило: для ИИ A/B тестов увеличьте расчётный размер выборки минимум в 3-5 раз по сравнению с обычными тестами.

Проблема 2: novelty effect. Когда вы запускаете новую версию чат-бота, пользователи взаимодействуют с ней иначе просто потому, что она новая. Первые несколько дней показывают завышенные метрики. Дайте тесту работать минимум две недели.

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

Проблема 4: несколько переменных одновременно. Изменение промпта, версии модели, температуры, RAG-конфигурации - всё это отдельные переменные. Тестируйте одну за раз. Если вы одновременно сменили модель, переписали промпт и добавили новые документы - вы не знаете, что именно изменило результат.

Shadow deployment как альтернатива

Вместо классического A/B можно использовать shadow testing: новая версия работает параллельно, получает те же запросы, но её ответы пользователям не показываются. Вы сравниваете ответы двух версий по автоматическим метрикам и LLM-judge. Это позволяет оценить изменение без риска для пользовательского опыта.

Мониторинг в продакшне: ИИ не статичен

Запустили, проверили - и думаете, что готово? Нет. ИИ-системы деградируют. Это называется model drift или data drift, и это реальная проблема.

Concept drift - реальность, которую описывает модель, изменилась. Если вы обучили антифрод-модель в 2022 году, а мошенники придумали новые схемы в 2024 - модель устарела, хотя данные те же.

Data drift - распределение входных данных изменилось. Пользователи начали задавать другие вопросы, появились новые темы. Модель видит запросы, на которых не обучалась.

Версионирование моделей у провайдеров. gpt-4-turbo сегодня - это не gpt-4-turbo через три месяца. Azure OpenAI даёт фиксированные snapshots версий, что помогает, но и там бывают обновления, которые меняют поведение.

Что мониторить в продакшне:

• Distribution shift детекторы - сравниваете текущее распределение входных данных (длина, тематика, язык) с базовым. Резкое изменение - сигнал тревоги.
• Automated quality sampling - случайная выборка 1-5% запросов проходит через LLM-judge каждый день. Если средняя оценка падает - что-то сломалось.
• Error pattern monitoring - кластеры похожих плохих ответов. Если система начала ошибаться на определённом типе запросов, это видно в кластеризации.
• Latency percentiles, не среднее - p50, p95, p99. Среднее скрывает хвостовые случаи. Если p99 latency 30 секунд, у 1% пользователей ужасный опыт, но среднее в 2 секунды выглядит нормально.
• Cost monitoring - стоимость на запрос и общий бюджет. Неудачное изменение промпта может внезапно удвоить количество токенов в запросе, и стоимость улетит в небо.

Eval-driven development: как это работает на практике

Eval-driven development - это методология, при которой все решения об изменении ИИ-системы принимаются на основе заранее определённых автоматических тестов, а не ручной проверки.

Принцип прост: прежде чем менять что-то в системе, определите, как вы поймёте, что стало лучше. Напишите тест. Измерьте baseline. Внесите изменение. Запустите тест. Сравните. Это звучит очевидно, но на практике большинство команд делают наоборот: сначала меняют, потом смотрят «ну как, лучше?».

Как собрать хороший eval-датасет

Золотой датасет (golden dataset) - набор пар «запрос - эталонный ответ», по которым вы проверяете систему. Несколько правил:

• Покрывайте все важные use cases, включая edge cases.
• Включайте примеры, на которых система раньше ошибалась - это regression tests.
• Датасет должен быть стабильным. Если менять его часто, не будет baseline для сравнения.
• Размер: для начала хватит 100-200 примеров, для серьёзной системы - от 1000.

Adversarial examples - примеры, специально созданные, чтобы сломать систему: jailbreak попытки, запросы с опечатками, запросы на других языках, запросы с противоречивыми условиями.

Real production queries - лучший источник для eval-датасета. Возьмите реальные запросы пользователей, разметьте качество ответов - и у вас будет наиболее репрезентативный набор, без академических допущений.

CI/CD для ИИ-систем

Да, это возможно и нужно. Каждое изменение промпта, модели или RAG-конфигурации запускает автоматический eval на золотом датасете. Если метрики падают ниже порога - деплой блокируется.

Инструменты: PromptFoo умеет запускаться в CI, Braintrust интегрируется с GitHub Actions, DeepEval тоже. Это не rocket science - это стандартная разработка, просто применённая к ИИ-системам.

Hallucination detection: отдельная проблема

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

Groundedness - насколько каждое утверждение в ответе подтверждается предоставленными источниками. В RAG-системах это основная метрика достоверности.

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

Confidence calibration - насколько уверенность модели соответствует её точности. Хорошо откалиброванная модель: когда говорит «я уверен на 90%» - ошибается примерно в 10% случаев. Плохо откалиброванная: говорит «я уверен» и при этом ошибается в половине случаев.

Автоматические инструменты для детекции галлюцинаций: RAGAS (faithfulness score), Lynx от Patronus AI, Guardrails AI. Ни один не идеален, но в комбинации дают приемлемое покрытие.

Измерение безопасности и соответствия

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

Toxicity rate - как часто система генерирует вредоносный, оскорбительный или небезопасный контент. Измеряется через специальные классификаторы: Perspective API от Google, OpenAI Moderation API, Llama Guard.

Refusal rate - как часто система отказывает в ответе. Слишком высокий refusal rate означает, что система перестраховывается и становится бесполезной. Слишком низкий - потенциальные safety проблемы. Нужен баланс, который определяется вашим конкретным контекстом.

Policy compliance - соответствует ли вывод вашим корпоративным политикам. Например, не рекомендует ли конкурентов, не раскрывает ли конфиденциальную информацию.

Jailbreak success rate - процент успешных попыток обойти защиту. Тестируется регулярно по актуальным техникам. Для enterprise-продуктов это обязательная метрика, а не опциональная.

Практический чеклист: с чего начать прямо сейчас

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

Шаг 1: определите цель продукта в измеримых терминах. Не «улучшить качество ответов», а «увеличить Task Completion Rate с 60% до 75%» или «снизить среднее количество итераций с 4 до 2.5».

Шаг 2: соберите golden dataset. Возьмите 100 реальных запросов из логов или придумайте, если продукт новый. Разметьте правильные ответы вручную. Это ваш baseline, от которого всё отсчитывается.

Шаг 3: настройте автоматический eval. Используйте LLM-judge для оценки ответов на golden dataset. Запускайте при каждом изменении системы. Это занимает полдня на настройку и экономит недели на ручной проверке.

Шаг 4: добавьте продуктовые метрики. Thumbs up/down - минимум. Лучше - явный вопрос «решила ли система вашу задачу?» в конце сессии.

Шаг 5: настройте мониторинг качества в продакшне. Автоматическая выборка 1% запросов с LLM-judge оценкой. Дашборд с трендом. Алерт при падении ниже порога.

Шаг 6: проводите регулярные ретроспективы по метрикам. Раз в неделю - 15 минут команды смотрит на цифры. Не «кажется, что стало лучше», а «метрика X выросла на Y% после изменения Z».

Метрики для агентных систем: новый уровень сложности

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

Task Success Rate для агентов - выполнил ли агент конечную цель, а не просто «дал ответ». Разница принципиальная: агент может красиво описать процесс заказа товара и при этом не оформить заказ. Успех - это результат, а не процесс.

Step accuracy - на каком шаге многоступенчатой задачи агент ошибается чаще всего. Если агент из 10 шагов проваливает шаг 7 в 60% случаев - это конкретная точка для улучшения, а не расплывчатое «работает плохо».

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

Unnecessary steps rate - делает ли агент лишние действия. Если для выполнения задачи нужно 4 шага, а агент делает 11 - это плохо с точки зрения и стоимости, и надёжности. Каждый лишний шаг - дополнительная точка отказа.

Recovery rate - умеет ли агент самостоятельно восстановиться после ошибки. Хороший агент понимает, что инструмент вернул ошибку, и корректирует стратегию. Плохой - зацикливается или сдаётся.

Сравнение популярных инструментов для оценки ИИ-систем

Выбор инструмента зависит от архитектуры вашей системы и зрелости процессов. Вот практическое сравнение наиболее распространённых решений:

Инструмент	Лучше всего подходит для	Интеграция с CI/CD	LLM-as-judge	RAG-метрики	Цена
RAGAS	RAG-системы	Через Python	Да	Да (нативно)	Open source
PromptFoo	Тестирование промптов	Да (CLI)	Да	Частично	Open source / платный
DeepEval	Комплексные eval-пайплайны	Да (pytest)	Да	Да	Open source / платный
Braintrust	Командная работа, эксперименты	Да (GitHub Actions)	Да	Частично	Платный (есть free tier)
LangSmith	LangChain-проекты	Да	Да	Связь технических метрик с бизнес-результатами: как построить мост Самая сложная задача в измерении ИИ-систем - не собрать метрики, а понять, как они связаны между собой. Команды часто оптимизируют то, что легко измерить, а не то, что важно. В итоге BLEU растёт, faithfulness улучшается, а выручка стоит на месте. Чтобы избежать этого, нужно построить явную цепочку причинности: какая техническая метрика влияет на какую продуктовую, и та - на какую бизнесовую. Пример для чат-бота службы поддержки: Снижение hallucination rate → рост faithfulness → рост CSAT → снижение churn Снижение TTFT с 3 секунд до 0.8 секунды → рост session depth → рост containment rate → снижение стоимости на обращение Рост Precision@5 в retrieval → меньше turns to completion → рост Task Completion Rate → рост конверсии в повторную покупку Такую карту метрик полезно нарисовать один раз для вашего конкретного продукта. Это не академическое упражнение - это рабочий инструмент, который позволяет командам договориться о том, что они оптимизируют и почему. Типичные ошибки при построении системы метрик Ошибка 1: слишком много метрик Парадокс измерения: чем больше метрик вы отслеживаете, тем меньше по факту управляете продуктом. Если на дашборде 40 графиков, никто не знает, на какой смотреть, когда что-то идёт не так. Выберите 3-5 ключевых метрик - North Star метрику и несколько сигнальных. Остальное мониторьте в фоне, но не в еженедельном отчёте. Ошибка 2: метрики без владельца «Команда смотрит на метрики» - не значит, что кто-то за них отвечает. У каждой ключевой метрики должен быть конкретный человек, который объясняет изменения и принимает решения. Без этого цифры просто висят на дашборде и никого ни к чему не обязывают. Ошибка 3: оптимизация метрики вместо результата Закон Гудхарта: когда метрика становится целью, она перестаёт быть хорошей метрикой. Классический пример - оптимизировать CSAT через выбор коротких понятных ответов, которые нравятся пользователям, но не решают их задачи. CSAT растёт, реальная полезность падает. Всегда держите в голове, что метрика - это прокси для реального результата, а не сам результат. Ошибка 4: игнорирование отрицательных сигналов Команды охотно смотрят на рост положительных метрик и не замечают слабые отрицательные сигналы. Если correction rate вырос на 15% при одновременном росте CSAT - это противоречие, которое нужно расследовать. Пользователи могут быть довольны взаимодействием, но при этом систематически уточнять и переформулировать запросы - значит, система не понимает их с первого раза. Ошибка 5: тестирование только на хороших примерах Golden dataset, собранный на «типичных» запросах, не покажет деградацию на edge cases. Ваш eval должен намеренно включать неудобные случаи: запросы с опечатками, запросы на смешанных языках, запросы, где пользователь явно заблуждается. Именно на них обычно видна разница между моделями и версиями промптов. Инструменты: короткий практический обзор Не нужно строить всё с нуля. Вот что реально используется в командах прямо сейчас. Задача Инструмент Подходит для Стоимость Eval и LLM-as-judge PromptFoo Тестирование промптов, CI/CD интеграция Open source RAG-метрики RAGAS Faithfulness, Answer Relevance, Context Utilization Open source Комплексный eval DeepEval Широкий набор метрик, hallucination detection Freemium Эксперименты и трекинг Braintrust Versioning, A/B тесты, логирование Freemium Observability Langfuse Трейсинг, мониторинг, аналитика Open source / Cloud Safety / Toxicity Llama Guard, OpenAI Moderation API Фильтрация небезопасного контента Open source / Pay-per-use Hallucination detection Patronus AI Lynx Фактологическая проверка вывода Коммерческий Минимальный стек для большинства продуктов: Langfuse для observability и логирования, RAGAS или DeepEval для автоматических eval, PromptFoo для CI/CD. Этого достаточно, чтобы перейти от «нам кажется» к «вот данные». Когда метрики указывают на разные направления Бывает, что метрики конфликтуют. CSAT вырос, а Task Completion Rate упал. Latency снизилась, но faithfulness ухудшилась. Это не баг системы измерений - это ценная информация о компромиссах в вашем продукте. Практический подход к разрешению конфликтов метрик: Иерархия приоритетов. Заранее договоритесь с командой, что важнее. Для медицинского ассистента safety и faithfulness всегда выше convenience. Для развлекательного чат-бота engagement может быть важнее точности. Сегментация. Метрики могут расходиться на разных сегментах пользователей. Что хорошо для новичков, может раздражать экспертов. Смотрите на метрики по когортам, а не только агрегированно. Временной горизонт. Краткосрочные и долгосрочные метрики часто конфликтуют. Ответ, который нравится пользователю прямо сейчас, может создавать зависимость, которая снижает его реальную компетентность. Для обучающих продуктов это особенно важно. Итог Система измерений для ИИ-продукта - это не разовый проект, а постоянная инфраструктура. Начните с минимального набора: golden dataset из 100 реальных запросов, LLM-judge для автоматических оценок, одна продуктовая метрика (TCR или containment rate), мониторинг latency и стоимости. Добавляйте слои по мере роста продукта и команды. Главное правило: любое изменение ИИ-системы должно иметь гипотезу в формате «это изменение улучшит метрику X на Y%» - и проверку этой гипотезы по данным после деплоя. Если ваша команда пока не дошла до построения такой инфраструктуры, или нужна помощь с запуском ИИ-продукта с правильной аналитикой с первого дня - агентство Nedigital строит продуктовую аналитику, сайты и маркетинговую инфраструктуру под ключ. Если у вас уже есть ИИ-инструмент, но нет понимания, как он влияет на бизнес-показатели - оставьте заявку, разберём вашу ситуацию конкретно. Частые вопросы С каких метрик начать, если ИИ-продукт только запускается? На старте достаточно трёх уровней: один технический (faithfulness или accuracy в зависимости от типа системы), один продуктовый (Task Completion Rate или thumbs down rate) и один бизнесовый (конверсия или retention). Не пытайтесь сразу измерять всё - сначала научитесь работать с тремя цифрами и принимать решения на их основе. Как часто нужно пересматривать golden dataset для eval? Раз в квартал - минимум. Добавляйте новые примеры из реальных запросов, которые показали проблемы, и фиксируйте регрессионные случаи после каждого инцидента. При этом старые примеры не удаляйте без явной причины - иначе потеряете возможность сравнивать результаты во времени. Можно ли доверять LLM-as-judge как основному методу оценки? Как единственному - нет. LLM-judge хорошо работает для относительного сравнения (A vs B), но плохо калиброван для абсолютных оценок. Используйте его в связке с периодической human evaluation на выборке 50-100 примеров - это позволит убедиться, что оценки судьи коррелируют с реальным восприятием пользователей. Если расхождение больше 20% - пересмотрите промпт судьи. Как бороться с деградацией модели после обновления у провайдера? Зафиксируйте snapshot автоматического eval на текущей версии как baseline и запускайте его при каждом обновлении. Если вы используете OpenAI или Azure, подпишитесь на уведомления об изменениях версий и держите в запасе предыдущую версию как fallback. Для критических систем рассмотрите собственный деплой open-source модели - это даёт полный контроль над версионированием. Нужны ли метрики безопасности для B2B-продукта с закрытым доступом? Да, даже если аудитория - только сотрудники компании. Корпоративные ИИ-ассистенты часто имеют доступ к конфиденциальным данным, и утечка через некорректный вывод модели - реальный риск. Минимум: policy compliance мониторинг и регулярное тестирование на prompt injection, особенно если система принимает данные из внешних источников. Антон · Nedigital Telegram-канал В Telegram-канале разбираю нейросети и контент-заводы изнутри: что реально приносит заявки бизнесу, сколько это стоит и какие фейлы случаются по дороге. Только проверенное на своих и клиентских проектах. Подписаться на канал Нужны заявки, а не просто статьи? Оставьте заявку - обсудим задачу и предложим план: сайт под ключ, контент-завод на ИИ, SEO или реклама в Яндекс Директ. → Оставить заявку на бесплатную консультацию Наши работы | SEO продвижение | Реклама в Яндекс Директ | Контент и соцсети