Глава 7. AI Quality, Drift & Fairness: непрерывная оценка и устранение bias

Бизнес-цель клиента

Качество и справедливость решений «Ковчега» измеримы, отслеживаются непрерывно и являются гейтом релиза. Обещания бизнесу:

1. Апдейт модели не выходит в прод без прохождения регрессии на эталонах.
2. Деградация и дрейф ловятся мониторингом, а не жалобами.
3. Отсутствие демографической предвзятости в скоринге доказуемо.

Драйвер: угроза или регулятор

• Silent degradation: обновление модели «под капотом» проваливает качество незаметно.
• EU AI Act (high-risk): Art. 10 (data quality, недискриминация), Art. 15 (accuracy, robustness), Art. 14 (human oversight).
• Bias: систематически худшие решения для группы = иск + штраф + репутация.
• OWASP LLM: LLM09 (Misinformation) — галлюцинации как класс.

Архитектурный паттерн

Continuous Evaluation & LLM-as-a-Judge Pipeline — оценка как непрерывный процесс: регрессия на golden-датасетах в CI/CD + онлайн-метрики RAG + дрейф-мониторинг + fairness-тесты, с честной калибровкой судьи.

Инженерный стек & провайдеры

• Eval-фреймворки: Ragas (v0.2+ — уже не только RAG, но и агентные пайплайны), DeepEval, TruLens, MLflow (эксперименты/реестр).
• Drift/data-quality: Evidently AI, Great Expectations.
• Judge: LLM-as-a-judge с калибровкой на человеческой разметке.

Инженерная реализация

### Шаг 1. Golden Datasets

Эталонные наборы под регрессию промптов/моделей в CI/CD. Апдейт модели/промпта не проходит без прогона. Датасет включает «трудные» кейсы и кейсы из реальных инцидентов.

### Шаг 2. Онлайн RAG-метрики

На выборке продакшн-трафика: Faithfulness (достоверность к контексту — прямая защита от галлюцинаций из вступления), Answer Relevance, Context Recall/Precision. Стыкуется с output-guardrail (гл. 3) — там блок в реальном времени, здесь тренд.

### Шаг 3. Drift-мониторинг

Аномалии в распределении эмбеддингов входящих запросов (data drift) и в качестве ответов (concept drift). Смещение → алерт. Важно: семантический кэш (гл. 5) маскирует дрейф — мерить на некэшированной выборке.

### Шаг 4. Fairness & Bias

Регулярный прогон синтетических тестов: перестановка защищённых атрибутов (пол, возраст, регион) при прочих равных → сравнение решений. Систематическая разница = сигнал bias. Для «Ковчега» — обязательный гейт кредитного модуля.

### Шаг 5. Eval-гейт релиза

Метрики — часть пайплайна (policy-as-code, гл. 6). Падение ниже порога блокирует деплой:

eval_gate:
  faithfulness:      {min: 0.92}
  answer_relevance:  {min: 0.85}
  fairness_delta:    {max: 0.03}   # макс. разница решений при перестановке атрибута
  block_release_on_fail: true

Где ломается

• LLM-as-judge сам предвзят и недетерминирован. Документированные искажения: verbosity bias (длиннее = «лучше»), self-preference (хвалит свой стиль), position bias (порядок вариантов). Митигация: рандомизация порядка, чёткие рубрики, ensemble судей, человеческая golden-разметка. Без калибровки это «оценка оценки».
• Калибровка дрейфует. Согласие judge с людьми, солидное полгода назад, устаревает — промпты, данные, версии моделей меняются. Рекалибровка — регулярный процесс, не разовый.
• Golden-датасет устаревает. Не покрывает новые кейсы → зелёные метрики при реальной деградации. Датасет пополняется из инцидентов и продакшн-трафика.
• Fairness труднометрим. «Справедливость» контекстна; несколько формальных метрик fairness математически несовместимы одновременно — выбор метрики сам требует обоснования.
• Стоимость. Непрерывная judge-оценка дорога; сэмплирование vs полнота — компромисс.

Стандарты и маппинг

• EU AI Act: Art. 10 (data governance/quality, недискриминация), Art. 15 (accuracy/ robustness), Art. 14 (human oversight).
• ISO/IEC 42001: мониторинг производительности, непрерывное улучшение.
• NIST AI RMF: Measure (valid, reliable, fair, safe).
• OWASP LLM: LLM09 (Misinformation).

Лаба и артефакт

Собрать golden-датасет для «Ковчега» (в т.ч. кейсы-инциденты), настроить Ragas-метрики онлайн, Evidently для эмбеддинг-дрейфа на некэшированной выборке, fairness-тест перестановкой атрибутов для кредитного модуля; сделать eval-гейт в CI; откалибровать judge на человеческой разметке и замерить agreement. Артефакт: eval-suite + дашборд качества/дрейфа + fairness-отчёт + отчёт калибровки судьи (доказательство в RMS, гл. 6).

Чеклист зрелости

• L1: ручная проверка качества при апдейте.
• L2: golden-датасет + RAG-метрики онлайн, drift-алерты.
• L3: eval-гейт в CI, калиброванный judge с рекалибровкой, регулярные fairness-прогоны, дрейф на некэшированной выборке, связка с RMS (гл. 6).

Источники

• [LLM-as-a-Judge calibration: power & limits (Deepchecks)](https://deepchecks.com/llm-judge-calibration-automated-issues/)
• [RAGAS and LLM-as-Judge production evals](https://letsdatascience.com/blog/llm-evaluation-ragas-llm-as-judge-and-production-evals)
• [Case-Aware LLM-as-a-Judge for Enterprise RAG (arXiv)](https://arxiv.org/html/2602.20379v1)
• [Exploring LLM-as-a-Judge (Weights & Biases)](https://wandb.ai/site/articles/exploring-llm-as-a-judge/)

Как это устроено — инженерные разборы

Отдельные howto из практики, где плоскость контроля показана на работающем коде и артефакте.

• Eval как release-критерий: как ловить agent drift до прода, а не послеEval как release-критерий: ловить agent drift до прода, а не после.

Читать дальше

• Дальше: Supply chain — Проверенные компоненты и стоп-кран для агентов
• Все главы курса →
• Подключить эксперта как MCP →