# ГЛАВА 13. АНТИГАЛЛЮЦИНАЦИОННЫЙ КОНТУР И ЗАЩИТА ОТ ДЕГРАДАЦИИ

---

## 13.1. Почему агенту нужен ревьюер

### Принцип разделения ролей

Представьте себе пилота и второго пилота в кабине самолёта. Пилот ведёт машину, второй пилот — контролирует показания приборов, перепроверяет высоту, сверяет курс. Никто не ожидает, что один человек будет одновременно управлять штурвалом и вычитывать чек-лист. То же самое с LLM: **Generator** — это пилот, **Verifier** — второй пилот. Два набора глаз всегда лучше одного.

Можно описать это иначе: писатель и редактор. Писатель создаёт текст — живой, богатый, иногда с ошибками. Редактор читает холодным взглядом — точно ли это? есть ли противоречия? Совмещать обе роли в одной голове тяжело человеку и ещё тяжелее модели.

Технически: генератор оптимизирован на **fluency** (гладкость текста), ревьюер — на **accuracy** (точность содержания). Совмещать обе функции в одном вызове — значит требовать от модели одновременно быть «креативной» и «критичной», что создаёт конфликт в attention-паттернах.

### Эмпирические данные

Разделение генерации и проверки почти всегда снижает hallucination rate по сравнению с одиночным вызовом, но величина выигрыша зависит от задачи, качества verifier'а и eval-протокола. CoVe (Dhuliawala et al., 2023) и последующие production-пайплайны показывают, что двухэтапная схема обычно окупается на задачах с высокой ценой ошибки.

### Архитектура: Generator + Verifier

```
┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  Generator   │ ──→ │   Output     │ ──→ │  Verifier    │
│  (high temp) │     │  (candidate) │     │  (low temp)  │
└──────────────┘     └──────────────┘     └──────┬───────┘
                                                  │
                                           ┌──────┴───────┐
                                           │              │
                                           ▼              ▼
                                      [PASS]         [FAIL]
                                        │               │
                                        ▼               ▼
                                   [Return]      [Retry / Fix]
```

**Generator**: температура 0.3–0.7, упор на полноту охвата и разнообразие.
**Verifier**: температура 0.0–0.1, упор на точность и согласованность.

Это могут быть:
- Два вызова одной модели с разными системными промптами.
- Две разные модели (generator = GPT-5.4, verifier = Claude Opus 4.6).
- Одна модель + внешние проверки (тесты, linter, schema validation).

> **Для начинающих.** Самый простой способ внедрить верификацию — добавить второй вызов модели после основного. Первый вызов генерирует ответ, второй получает промпт: «Вот ответ. Проверь каждый факт. Если найдёшь ошибку — исправь и объясни». Даже этот минимальный паттерн уже ловит часть галлюцинаций.

На уровне 2026 года архитектура Generator + Verifier стала обычным production-паттерном. Anthropic встроили эту идею в **Constitutional AI** (Bai et al., 2022) — подход, при котором модель сначала генерирует, потом сама оценивает ответ через набор принципов (constitution), и переписывает его. **RLAIF** (Reinforcement Learning from AI Feedback) обучает модель на таких самопроверках ещё на этапе тренировки — до деплоя (подробнее о post-training методах — в [Главе 19](19_fine_tuning_and_post_training.md)).

---

## 13.2. Chain-of-Verification (CoVe)

### Метод (Dhuliawala et al., 2023)

Если Generator + Verifier — это пилот и второй пилот, то **CoVe — это перекрёстный допрос в суде**. Свидетель (модель) дал показания (черновой ответ). Теперь адвокат (верификатор) разбивает показания на отдельные утверждения и задаёт по каждому точечный вопрос — причём в отдельной комнате, без подсказок от оригинальных показаний. Именно так работает снижение confirmation bias.

CoVe — четырёхэтапный протокол, специально разработанный для снижения галлюцинаций. Разберём его пошагово на конкретном примере:

**Этап 1: Draft (Черновик)**
```
Промпт: "Перечисли 5 крупнейших озёр Африки по площади."
Черновик: "1. Виктория, 2. Танганьика, 3. Малави, 4. Чад, 5. Туркана"
```

**Этап 2: Plan Verification Questions (Планирование проверки)**
```
Промпт: "Для каждого факта сформулируй проверочный вопрос."
Вопросы:
- "Виктория — одно из крупнейших озёр Африки?"
- "Танганьика — одно из крупнейших озёр Африки?"
- "Чад — одно из крупнейших озёр Африки по площади?"
- ...
```

**Этап 3: Answer Questions Independently (Независимые ответы)**

Критически важно: проверочные вопросы отвечаются **в отдельном контексте**, без видимости черновика. Это предотвращает confirmation bias.

```
"Чад — одно из крупнейших озёр Африки по площади?"
→ "Озеро Чад значительно сократилось и не входит в топ-5 по текущей площади.
   Альберт (Albert) — крупнее."
```

**Этап 4: Generate Verified Response (Финальный ответ)**
```
Исправленный ответ:
"1. Виктория, 2. Танганьика, 3. Малави, 4. Туркана, 5. Альберт"
```

### Почему CoVe работает

1. **Декомпозиция проверки**: вместо «проверь всё» — отдельные вопросы для каждого факта.
2. **Независимость**: ответы на проверочные вопросы не должны быть заражены черновиком.
3. **Итеративность**: можно запустить несколько раундов CoVe для повышения точности.

> **Промпт для генерации кода.** *«Реализуй async-функцию chain_of_verification(question, model) с четырьмя этапами CoVe: (1) черновик ответа (temp 0.3), (2) генерация проверочных вопросов для каждого факта (temp 0.1, JSON), (3) независимые ответы на вопросы без видимости черновика (temp 0.0) — критично для устранения confirmation bias, (4) финальный ответ с учётом проверок (temp 0.1). Используй актуальный SDK (OpenAI / Anthropic). Верни {draft, verifications, final_answer}.»*

---

## 13.3. Log-Driven Development (LDD)

### Принцип: данные вместо интуиции

Если CoVe — перекрёстный допрос, то **LDD — это бортовой самописец (чёрный ящик) самолёта**. После инцидента (а в LLM-системах инциденты — это галлюцинации, таймауты, некорректный JSON) вы открываете лог и видите: какой промпт был отправлен, какой ответ получен, сколько токенов стоил вызов, прошла ли валидация. Без логов диагностика невозможна — это как врач, которому описывают симптомы по телефону через неделю после болезни.

> **Отладка без логов — это диагноз без симптомов.** Вы видите, что ответ неправильный, но не знаете: проблема в промпте? в модели? в контексте, который был слишком длинным? LDD даёт вам симптомы.

Традиционный подход к промптингу: написал → попробовал → переписал → попробовал... Это метод тыка, маскирующийся под итерацию.

**LDD** — структурированный подход:

1. **Логируй всё**: промпт, параметры, output, validation, метрики.
2. **Анализируй**: где ошибки? На каком шаге? Какой тип?
3. **Формируй гипотезу**: «ошибка возникает, когда данные >5K токенов».
4. **Тестируй**: измени один параметр, проверь на тех же данных.
5. **Итерируй**: на основе данных, а не чутья.

### Что логировать

Каждый вызов LLM фиксируется в структуре `LLMCallLog` со следующими группами полей:

| Группа | Поля | Назначение |
|--------|------|------------|
| Идентификация | `call_id`, `timestamp`, `pipeline_name`, `step_name` | Привязка к конкретному шагу пайплайна |
| Вход | `system_prompt`, `user_prompt`, `model`, `temperature`, `max_tokens`, `tools` | Полный контекст запроса |
| Выход | `response`, `tool_calls`, `finish_reason` | Ответ модели и причина остановки (`stop` / `length` / `tool_calls`) |
| Метрики | `input_tokens`, `output_tokens`, `latency_ms`, `cost_usd` | Стоимость и производительность |
| Валидация | `schema_valid`, `factual_checks`, `human_rating` (1–5) | Качество ответа (автоматическое + ручное) |
| Контекст | `error`, `retry_count` | Для диагностики проблем |

> **Промпт для генерации кода.** *«Создай Python dataclass (или Pydantic BaseModel) LLMCallLog с полями из таблицы выше. Добавь to_json() для сериализации и from_dict() для десериализации.»*

### Метрики для отслеживания

| Метрика | Формула | Цель |
|---------|---------|------|
| **Schema compliance rate** | Valid outputs / Total outputs | >99% |
| **Hallucination rate** | Verified false claims / Total claims | <5% |
| **Retry rate** | Retries / Total calls | <10% |
| **Latency P95** | 95-й перцентиль response time | <3s |
| **Cost per task** | Σ(tokens × price) / tasks | Зависит от задачи |
| **Success rate** | Tasks completed / Tasks attempted | >90% |

### Инструменты для LDD

| Инструмент | Назначение | Тип |
|-----------|------------|-----|
| **LangSmith** (LangChain) | Tracing, debugging, evaluation | SaaS |
| **Weights & Biases (Prompts)** | Tracking, versioning | SaaS |
| **Braintrust** | Evaluation, logging | SaaS |
| **Phoenix (Arize)** | Observability, traces | Open-source |
| **OpenLLMetry** | OTel-инструментация LLM-вызовов | Open-source |
| **OpenTelemetry + custom** | DIY tracing | Open-source |
| **SQLite + JSON logs** | Минимальный локальный | DIY |

### 13.3.1. Выбор платформы

Таблица выше даёт обзор инструментов. Подробное сравнение платформ (LangSmith, Arize Phoenix, W&B Weave, OpenLLMetry), setup и рекомендации по выбору для разных сценариев — в [Главе 17, раздел 17.2](17_observability_and_operations.md).

Для минимального старта достаточно SQLite + JSON-логов с полями `LLMCallLog` (см. выше): записывайте каждый вызов и анализируйте SQL-запросами.

---

## 13.4. Anti-Loop Protocol: детекция зацикливания

### Паттерны зацикливания

**1. Вербальные петли**: модель повторяет одну и ту же фразу или абзац.

```
"Для решения этой задачи необходимо рассмотреть все аспекты. 
Рассмотрев все аспекты, мы можем заключить, что для решения 
необходимо рассмотреть все аспекты..."
```

**2. Tool-call петли**: агент вызывает одни и те же инструменты с одинаковыми аргументами.

```
Action: search_files("config.json")
Observation: Not found
Action: search_files("config.json")  ← повтор!
Observation: Not found
Action: search_files("config.json")  ← повтор!
```

**3. State oscillation**: агент переключается между двумя состояниями без прогресса.

```
State: "needs_fix" → fix_code() → test_fails → "needs_fix" → fix_code() → test_fails → ...
```

**4. Output inflation**: модель генерирует всё более длинные ответы, разбавляя содержание.

### Детекция

Детектор зацикливания (`LoopDetector`) хранит историю output'ов и tool-вызовов и проверяет три условия:

1. **Verbal loop**: разбивает output на предложения и считает повторы. Если одно предложение встречается ≥ N раз — срабатывание.
2. **Tool-call loop**: если последние N tool-вызовов идентичны (одинаковые имя и аргументы) — срабатывание.
3. **State stagnation**: если состояние агента не менялось N шагов подряд (сравнение через сериализацию) — срабатывание.

Порог N (обычно 3) и threshold схожести — настраиваемые параметры.

> **Промпт для генерации кода.** *«Реализуй класс LoopDetector с тремя методами: check_verbal_loop(output) — детекция повторяющихся предложений, check_tool_loop(tool_name, tool_args) — детекция повторяющихся tool-вызовов, check_progress(state_dict) — детекция застоя через сравнение сериализованных состояний. Параметры: max_repeats=3, similarity_threshold=0.9. Каждый метод возвращает bool.»*

### Реакция на зацикливание

| Тип петли | Действие |
|-----------|----------|
| Вербальная | Прервать генерацию, вернуть частичный результат |
| Tool-call | Изменить стратегию (другой tool, другие аргументы) |
| State oscillation | Откат к предыдущему стабильному состоянию + переформулировка |
| Output inflation | Установить жёсткий max_tokens |
| Все типы (после retry) | **Human-in-the-loop**: запросить помощь оператора |

---

## 13.5. Guardrails: защитные барьеры

Guardrails — это **отбойники на горной дороге**. Они не крутят руль за водителя и не выбирают маршрут. Но когда машина (модель) случайно уходит к краю пропасти — токсичный контент, утечка персональных данных, prompt injection — отбойники не дают ей упасть. Без них каждый поворот — русская рулетка.

К 2026 году guardrails-фреймворки — Guardrails AI, NVIDIA NeMo Guardrails, LLM Guard — стали зрелыми инструментами. Guardrails делятся на два класса:

- **Guardrails качества**: schema validation, PII-маскирование, content policy, детекция low-confidence ответов. Разбираем ниже.
- **Guardrails безопасности**: детекция prompt injection (трёхуровневая защита — regex, ML-классификатор, архитектурная изоляция), jailbreak-фильтры, dual-LLM pattern, secrets scanning, toxicity filtering. Подробно — в [Главе 15, §15.9](15_llm_system_security.md).

### Входные guardrails

На входе проверяйте: **длину** (лимит токенов), **PII** (маскирование до передачи модели), **формат** (если ожидается структурированный вход — валидируйте схему).

> **Промпт для генерации кода.** *«Напиши функцию validate_input(user_input) → (pass: bool, reason: str, sanitized_input: str): (1) ограничение по токенам, (2) маскирование PII (email, телефон, номер карты), (3) базовая schema-валидация. Логируй обнаруженные типы PII.»*

### 13.5.1. PII-маскирование

В enterprise-деплоях маскирование персональных данных — обязательный компонент. Пользователь может случайно отправить паспортные данные, номер карты, email коллеги. Маскирование применяется как на входе (до передачи модели), так и на выходе (модель может воспроизвести PII из контекста).

> **Промпт для генерации кода.** *«Напиши функцию mask_pii(text) → (masked_text, found_types): найди и замаскируй email → [EMAIL], российский телефон (+7...) → [PHONE], номер карты (16 цифр) → [CARD], SSN → [SSN], российский паспорт → [PASSPORT]. Используй regex. Верни маскированный текст и список типов.»*

### 13.5.2. Выходные guardrails

На выходе проверяйте:

1. **Schema validation**: JSON Schema проверка для structured outputs — 100% гарантия формата.
2. **PII leak detection**: сканируйте выход теми же regex-паттернами — модель может воспроизвести PII из контекста.
3. **Content policy**: запрещённые темы, упоминания конкурентов, медицинские/финансовые рекомендации — по конфигурируемому набору правил.
4. **Confidence check**: избыточное количество hedging-фраз («я не уверен», «возможно») сигнализирует о низкой уверенности.
5. **Hallucination markers**: фразы «as of my knowledge cutoff» указывают на параметрические знания вместо контекста.

> **Промпт для генерации кода.** *«Напиши функцию validate_output(output, schema=None, content_policy=None) → (is_valid: bool, issues: list[str]): (1) JSON Schema validation, (2) PII leak scan, (3) content policy (словарь regex-паттернов), (4) hedging phrase count > 3 → warning, (5) hallucination markers. Верни список обнаруженных проблем.»*

---

## 13.6. Цена верификации: баланс точности, задержки и стоимости

Каждый уровень защиты стоит денег и времени. Верификация — не бесплатная:

| Метод | Дополнительная задержка | Дополнительная стоимость | Типичный эффект |
|-------|------------------------|-------------------------|----------------|
| Второй LLM-вызов (Verifier) | +1–3 сек | около ×2 стоимости | Часто заметно снижает factual/runtime errors |
| Полный CoVe (4 этапа) | +5–15 сек | около ×3–5 стоимости | Даёт лучший контроль на high-risk задачах |
| Regex guardrails | <10 мс | ~бесплатно | Ловят только очевидное |
| LLM-классификатор injection | +0.5–1 сек | +$0.001–0.01 за запрос | Высокая для injection |
| Schema validation | <10 мс | ~бесплатно | 100% для формата |

**Стратегия: дифференцированная верификация.** Не нужно прогонять полный CoVe на каждый чат-ответ. Определите уровень риска задачи:

- **Низкий риск** (чат-бот отвечает на FAQ) → regex guardrails + schema validation.
- **Средний риск** (генерация контента для клиентов) → Verifier + content policy + PII check.
- **Высокий риск** (медицина, юриспруденция, финансы) → полный CoVe + human-in-the-loop + аудит-лог.

Функция `select_verification_level(task_metadata)` проверяет домен задачи (`medical`, `legal`, `financial` → full CoVe), флаг `external_facing` (→ Verifier + guardrails) или возвращает `lightweight` (только schema + regex).

---

## 13.7. Продакшн-мониторинг: дашборд на каждый день

Логи бесполезны, если их никто не смотрит. Настройте дашборд, который команда видит ежедневно:

### Рекомендуемые панели дашборда

| Панель | Что показывает | Алерт при |
|--------|---------------|----------|
| **Hallucination rate** (скользящее окно 24ч) | % ответов с подтверждёнными ошибками | Выше вашего SLO |
| **Latency P50 / P95** | Время ответа | P95 > 5 сек |
| **Error rate** | % вызовов с ошибками (timeout, 429, invalid JSON) | >2% |
| **Cost per task** (скользящее окно) | Средняя стоимость одного завершённого задания | Рост >20% за неделю |
| **Retry rate** | Доля запросов, потребовавших повтора | >15% |
| **Guardrail triggers** | Срабатывания по типу (injection, PII, toxicity) | Всплеск injection |
| **User satisfaction** (если есть thumbs up/down) | % положительных оценок | <80% |

### Минимальный стек мониторинга

Подробнее об observability-стеке, SLO, инструментах мониторинга и incident response — в [Главе 17](17_observability_and_operations.md).

---

## 13.8. Hallucination incident response: что делать, когда продакшн-система нагаллюцинировала

Галлюцинация в чат-боте — неприятно. Галлюцинация в агенте, который отправил письмо клиенту или выполнил SQL-запрос — инцидент. Этот playbook — протокол действий от обнаружения до предотвращения повторения.

### Фаза 0: Детекция

Галлюцинация обнаружена. Источники детекции:
- **Автоматическая** — Verifier (CoVe, schema validation, NLI) пометил ответ как недостоверный.
- **Пользовательская** — жалоба клиента, тикет в поддержку.
- **Мониторинг** — hallucination rate в дашборде превысил SLO (§13.7).
- **Ручная проверка** — инженер заметил при аудите логов.

### Фаза 1: Остановка ущерба (первые 15 минут)

Действия в порядке приоритета:

1. **Оцените масштаб.** Сколько пользователей затронуто? Ответ уже доставлен клиенту (email, SMS, публикация) или только в интерфейсе чата?
2. **Остановите распространение.** Если галлюцинация воспроизводится систематически — переключите трафик на fallback-модель или rule-based ответ. Если модель продолжает галлюцинировать на однотипных запросах — временно включите блокировку темы (content filter).
3. **Отзовите неверную информацию.** Если письмо отправлено — отправьте коррекцию. Если данные записаны в БД — пометьте как «требует верификации».
4. **Зафиксируйте инцидент.** Создайте запись: время, затронутые пользователи, тип галлюцинации, предположительная причина.

### Фаза 2: Диагностика (первые 2 часа)

1. **Восстановите контекст.** Какой промпт был отправлен? Какой ответ получен? Какие документы были в контексте (для RAG)? Какие tool calls предшествовали?
2. **Классифицируйте галлюцинацию** по таксономии из Главы 3:
   - **Factual fabrication** — модель выдумала факт (несуществующий API, вымышленное имя).
   - **Context contradiction** — модель проигнорировала контекст и выдала параметрические знания.
   - **Logical inconsistency** — внутреннее противоречие в ответе.
   - **Overgeneralization** — модель применила общее правило к частному случаю, где оно не работает.
3. **Проверьте воспроизводимость.** Запустите тот же промпт 5 раз с temp=0. Воспроизводится? Если да — проблема детерминированная (промпт, данные). Если нет — стохастическая (нужен verifier).
4. **Проверьте промпт и данные.** Есть ли в промпте неоднозначности? Есть ли в контексте (RAG) противоречивые или устаревшие данные?
5. **Проверьте модель.** Не было ли моделью апдейта в день инцидента? Нет ли known issues в changelog провайдера?

### Фаза 3: Исправление (первые 24 часа)

В зависимости от классификации:

| Тип галлюцинации | Краткосрочное исправление | Долгосрочное |
|-----------------|--------------------------|-------------|
| Factual fabrication | Добавить Verifier (CoVe) + citation grounding | Улучшить RAG-покрытие домена |
| Context contradiction | Усилить промпт ("Answer ONLY from context") + structured output с source_doc_id | Пересмотреть conflict cases в eval-наборе |
| Logical inconsistency | Добавить Self-Consistency (3+ сэмпла, голосование) | Улучшить chain-of-thought промпт |
| Overgeneralization | Добавить few-shot примеры с контрпримерами в промпт | Fine-tune на доменных данных |

### Фаза 4: Предотвращение повторения

1. **Добавьте тест-кейс в eval-набор.** Инцидент → тест-кейс → regression gate. Это главный механизм обучения системы на ошибках.
2. **Обновите guardrails.** Если галлюцинация могла быть поймана автоматически — добавьте правило (regex, content filter, confidence threshold).
3. **Проведите post-mortem.** Встреча команды: что произошло, почему не поймали, что изменим в процессе.
4. **Обновите runbook.** Добавьте данный тип инцидента в operational runbook команды.

### Чек-лист incident response

| # | Шаг | Тайминг | Статус |
|---|-----|---------|--------|
| 1 | Оценён масштаб (пользователи, доставка) | 5 мин | ☐ |
| 2 | Остановлено распространение (fallback/блокировка) | 15 мин | ☐ |
| 3 | Отозвана неверная информация (коррекция) | 30 мин | ☐ |
| 4 | Восстановлен контекст инцидента (логи) | 1 час | ☐ |
| 5 | Определён тип галлюцинации | 1 час | ☐ |
| 6 | Проверена воспроизводимость | 2 часа | ☐ |
| 7 | Применено краткосрочное исправление | 4 часа | ☐ |
| 8 | Тест-кейс добавлен в eval-набор | 24 часа | ☐ |
| 9 | Проведён post-mortem | 72 часа | ☐ |
| 10 | Runbook обновлён | 1 неделя | ☐ |

### Инструменты

> **Промпт для ИИ:** «Напиши Python-скрипт для автоматической классификации галлюцинаций в ответах LLM. Скрипт принимает запрос, ответ модели, retrieved context (опционально), ground truth (опционально). Классифицирует по четырём типам: factual_fabrication, context_contradiction, logical_inconsistency, overgeneralization. Для factual_fabrication — проверяет claims через верификацию (второй LLM-вызов или NLI). Для context_contradiction — сверяет claims с retrieved context. Для logical_inconsistency — ищет внутренние противоречия в ответе. Возвращает JSON с типом галлюцинации, confidence и affected claims. Используй OpenAI API или Anthropic API.»

---

## Практический вывод

### Минимальный антигаллюцинационный контур

```
Input → [Input Guardrails] → [Generator] → [Output Guardrails] →
   → [Verifier (CoVe / tests / schema)] → Output / Retry
```

### Чек-лист

| # | Компонент | Внедрено? |
|---|-----------|-----------|
| 1 | **Ревьюер отделён от генератора** | Generator ≠ Verifier (пилот + второй пилот) |
| 2 | **CoVe для фактуальных задач** | 4-step protocol (перекрёстный допрос) |
| 3 | **Логи всех вызовов** | Промпт, output, метрики, validation (чёрный ящик) |
| 4 | **Observability-платформа** | LangSmith / Phoenix / W&B (подробнее — [Глава 17](17_observability_and_operations.md)) |
| 5 | **Детекторы петель** | Verbal, tool-call, state oscillation |
| 6 | **Input guardrails** | Длина, PII-маскирование, injection detection (подробнее — [Глава 15](15_llm_system_security.md)) |
| 7 | **Output guardrails** | Schema, toxicity, content policy, PII leak |
| 8 | **Дифференцированная верификация** | Уровень проверки зависит от риска задачи |
| 9 | **Продакшн-дашборд** | Hallucination rate, latency, cost, alerts |
| 10 | **Human-in-the-loop** | Есть fallback к человеку для высокого риска? |

### Задания

1. **Внедрите Generator + Verifier для одного пайплайна.** Выберите задачу с высокой ценой ошибки (генерация ответов для клиентов, суммаризация документов). Добавьте второй LLM-вызов (Verifier) с промптом «Проверь каждый факт. Если найдёшь ошибку — исправь и объясни». Измерьте hallucination rate до и после на 20+ примерах. **Ожидаемый результат:** количественная оценка снижения галлюцинаций и понимание trade-off по латенси и стоимости.

2. **Настройте LDD-логирование.** Реализуйте `LLMCallLog` (таблица из §13.3) и начните писать логи всех LLM-вызовов в SQLite. Через неделю проанализируйте: какой retry rate? какие ошибки чаще всего? в каких шагах пайплайна? **Ожидаемый результат:** первый дашборд с метриками schema compliance rate, retry rate, latency P95.

3. **Проведите CoVe-сессию вручную.** Возьмите 5 фактуальных вопросов из вашей области. Для каждого: попросите модель ответить (черновик), сформулируйте проверочные вопросы, задайте их в отдельном контексте, сравните. **Ожидаемый результат:** понимание, какие типы ошибок ловит CoVe, а какие нет; оценка cost/benefit для вашей задачи.

4. **Проведите учебную тревогу (fire drill).** Сымитируйте инцидент: намеренно внесите галлюцинирующий промпт или уберите Verifier из пайплайна. Пройдите все 4 фазы playbook: детекция → остановка → диагностика → предотвращение. Замерьте время от обнаружения до исправления. **Ожидаемый результат:** заполненный incident response checklist + время реакции команды < 4 часов.

---

## Источники
- Dhuliawala, S., et al. (2023). "Chain-of-Verification Reduces Hallucination in Large Language Models."
- Rebedea, T., et al. (2023). "NeMo Guardrails: A Toolkit for Controllable and Safe LLM Applications with Programmable Rails." NVIDIA.
- Anthropic. "Reducing Hallucination." Claude Best Practices (2024–2026).
- Bai, Y., et al. (2022). "Constitutional AI: Harmlessness from AI Feedback." Anthropic.
- Guardrails AI. Documentation. https://www.guardrailsai.com/docs (2025–2026).
- LangSmith. "Tracing and Evaluation." https://docs.smith.langchain.com/
- Arize AI. "Phoenix: Open-Source LLM Observability." https://docs.arize.com/phoenix (2025–2026).
- Weights & Biases. "W&B Weave: LLM Monitoring." https://docs.wandb.ai/guides/weave (2025–2026).

---

**Навигация:**
- Назад: [Глава 12. RAG: когда модели не хватает собственных знаний](12_rag.md)
- Далее: [Глава 14. Оценка качества LLM-систем](14_llm_system_quality_evaluation.md)