📊 Оценка качества AI-систем

Главное правило зрелой AI-разработки: вы не можете улучшить то, что не измеряете. Демо выглядит блестяще — на двух примерах, которые вы сами подобрали. В production система встретит тысячи разных входов, и без систематической оценки вы не узнаете, где она ломается, пока не станет поздно. Эта статья — про то, как построить измеримую обратную связь.

Почему eval — это базовый навык

В вакансиях AI Solution Architect прямо стоит: «оценивать эффективность внедрения AI и обеспечивать качество решений». Без eval вы не защитите проект (17-strategiya-i-roadmap) и не поймёте, стало ли лучше после доработки.

---

Два слоя оценки

flowchart LR
    subgraph OFF["🔍 Offline-оценка (до релиза)"]
        GS["📋 Golden set<br/>(тестовые кейсы)"] --> METRICS["📐 Метрики"]
        METRICS --> JUDGE["🧑‍⚖ LLM-as-Judge<br/>(авто-оценка)"]
    end
    subgraph ON["📈 Online-оценка (в production)"]
        LIVE["real-time<br/>запросы"] --> MON["📊 Мониторинг<br/>(дрифт, дизлайки)"]
        LIVE --> SAMPL["🎲 Выборочная<br/>человеческая проверка"]
    end

	Offline (до релиза)	Online (в production)
Когда	При каждом изменении промпта/модели	Постоянно, на живых данных
На чём	Golden set — размеченные тестовые кейсы	Реальные запросы, метрики использования
Цель	Не пустить регресс в прод	Заметить деградацию «в поле»

Golden set — основа основ

Golden set (золотой набор / тестовая выборка) — это коллекция из ~50–500 реальных примеров «вход → правильный ответ/ожидаемое поведение», собранных из ваших данных, а не придуманных.

Как собрать

• Берите реальные входы (письма, договоры, обращения), а не выдуманные.
• Покрывайте граничные случаи: пустые поля, необычные форматы, неоднозначные ситуации.
• Размечайте эталон (правильный ответ) и/или критерии (что должно быть верно).
• Обновляйте набор: нашли ошибку в проде → добавьте этот кейс в golden set, чтобы не повторить.

Не оценивайте «на глаз»

«Я проверил пять ответов — выглядит ок» — это не оценка. Пять удачных примеров ничего не говорят о тысяче неудачных, которые вы не видели. Регресс прячется в хвосте, и ловит его только систематический прогон golden set.

Метрики — какие и зачем

Универсальных «процентов качества» для LLM почти нет — метрики зависят от задачи.

Тип задачи	Что мерить
Извлечение данных	Точность (precision) и полнота (recall) по полям; F1
Классификация	Accuracy, precision/recall по классам, confusion matrix
Summary / генерация	Релевантность, фактологичность, следование формату
RAG	Retrieval hit-rate, faithfulness, RAGAS-метрики (09-rag)
Агенты	Доля корректно завершённых задач, число шагов, стоимость (06-stoimost-i-ekonomika)

Precision и recall — на пальцах

• Precision (точность): из того, что система назвала «да», сколько реально «да». Важно, когда ложное срабатывание дорого.
• Recall (полнота): из всех реальных «да», сколько система нашла. Важно, когда пропуск дорог (например, пропустить рискованный пункт договора).
• Всегда есть trade-off: поднимая одно, опускаешь другое. Выбирайте под цену ошибки.

LLM-as-Judge

LLM-as-Judge — это оценка ответов вашей системы другой (часто более сильной) LLM по заданным критериям. Дёшево, масштабируемо, и для многих задач коррелирует с человеческой оценкой.

flowchart LR
    In["Вход"] --> Sys["🧠 Ваша система"] --> Ans1["Ответ"]
    Crit["📋 Критерии<br/>(что правильно)"] --> Judge["🧑‍⚖ Модель-судья<br/>(флагман)"]
    Ans1 --> Judge
    Judge --> Score["📊 Оценка +<br/>объяснение"]

Ловушки LLM-as-Judge

• Собственные предвзятости: судья может предпочитать длинные ответы, ответы в своём стиле и т. д.
• Не всесильна: на фактах, требующих внешней проверки, судья может ошибаться — там нужна программная валидация (08-gallyutsinatsii-i-nadezhnost).
• Лучше всего работает в связке с golden set и выборочной человеческой проверкой.

Мониторинг в production

После релиза оценка не заканчивается — она переходит в наблюдаемость:

• Доли апрутов/дизлайков от пользователей.
• Распределения входов/выходов (резкий сдвиг = сигнал тревоги).
• Дрифт: данные или поведение со временем «уплывают» от того, на чём систему проверяли.
• Трассировка: какие шаги агент делал, какие инструменты вызывал (10-agent-architecture, 11-tools-mcp) — без этого не отладить.
• Сбор «плохих» кейсов → обратно в golden set.

Что выводить на дашборд руководителя

• Доля автоматических ответов без участия человека.
• Доля потребовавших эскалации / правок.
• Стоимость на единицу результата (06-stoimost-i-ekonomika).
• Тренд качества во времени (не «уплыл» ли).

CI/CD для промптов и моделей

Зрелая команда относится к промптам как к коду (07-prompt-engineering): любое изменение проходит через автоматический прогон golden set, и регресс не попадает в прод. То же — при смене модели или обновлении версии вендора.

flowchart LR
    Change["✏ Изменение промпта/модели"] --> Eval{"Прогон<br/>golden set"}
    Eval -- регресс --> Block["❌ Не пускаем"]
    Eval -- ок --> Stage["🚀 В прод (пилот)"]
    Stage --> Mon["📊 Мониторинг"]

---

📌 Что запомнить

• Без eval нет управления качеством; «пять примеров на глаз» — не оценка.
• Основа — golden set из реальных кейсов с эталонами, обновляемый.
• Метрики зависят от задачи; для извлечения — precision/recall; для RAG — faithfulness/relevancy.
• LLM-as-Judge — дешёвая авто-оценка, но с предвзятостями; в связке с человеческой проверкой.
• В production — наблюдаемость: дизлайки, дрифт, трассировка, сбор плохих кейсов.
• Промпты как код: изменения — через eval-гейт (CI/CD).

Дальше: 🛡 Комплаенс, безопасность и AI governance → — что можно и нельзя с данными, и как управлять рисками AI на уровне компании.