The feedback loop: traces → eval sets → fixes

Линейная модель «написал промпт → потестировал руками → задеплоил → перешёл к следующей задаче» перестаёт работать в первый же месяц продакшена: система живёт в меняющемся мире — трафик дрейфует, провайдер обновляет модели, продукт добавляет фичи. Единственная устойчивая форма — замкнутый цикл: продакшен-трейсы → отбор проблемных и показательных кейсов → пополнение датасетов → эвалы → фикс → деплой → новые трейсы. Каждый оборот делает систему прочнее, потому что выученные ошибки не забываются, а оседают в eval-сете.

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

Всё, что построено в предыдущих уроках, оказывается инфраструктурой этого цикла: инструментирование (урок 2) создаёт сырьё — трейсы; дашборды (урок 3) и фильтры паттернов (урок 4) показывают, где копать; алёрты (урок 5) запускают оборот не по расписанию, а по событию. Этот урок — про сам оборот: как кейс попадает из трейса в датасет, как датасет охраняет релизы и кто крутит колесо, чтобы оно не остановилось. Скорость оборота — от инцидента до защищающего кейса — и есть реальная метрика зрелости LLMOps в команде.

Источники кейсов, в порядке ценности: трейсы с негативным фидбэком и провалом судьи; находки еженедельного разбора (урок 4); трейсы из новых кластеров дрейфа (урок 5); пограничные успешные прогоны — случаи, где система справилась еле-еле. Механика проста: в Langfuse трейс добавляется в dataset как пара input/expected output, в LangSmith — «add to dataset» прямо из run-а.

Правила, которые отличают рабочий датасет от свалки:

• Expected output пишет человек. Скопировать плохой продакшен-ответ как эталон — классическая ошибка; из трейса берётся вход и контекст, а ожидание формулируется заново: каким ответ должен был быть;
• Стратификация против фикс-оверфита. Датасет только из фейлов заставляет оптимизировать промпт под ошибки и терять обычные сценарии; держите 30–50% нормальных кейсов как якорь;
• Анонимизация до сохранения. Продакшен-вход содержит PII — имена, адреса, номера заказов заменяются реалистичными синтетическими до записи в датасет, который живёт дольше и доступнее трейсов;
• Метаданные происхождения. У кейса — ссылка на исходный trace_id, категория отказа и дата: без этого через полгода никто не вспомнит, зачем кейс существует и можно ли его менять.

Ориентир темпа: 5–10 осмысленных кейсов в неделю. Через квартал это 100+ кейсов, выросших из реальных отказов вашей системы — такой датасет бьёт любой синтетический бенчмарк по релевантности.

Датасет полезен ровно настолько, насколько регулярно он прогоняется. Контур из трёх частей:

Промпт — это код. Версия в git или в prompt management платформы, code review на изменения, changelog. Главное — метка версии прошивается в атрибуты каждого трейса (prompt_version, release): без неё невозможно связать сдвиг метрик с релизом, и разборы превращаются в гадание «что мы меняли во вторник?».

CI-гейт. PR, меняющий промпт или модель, автоматически гоняет эвал против датасета: быстрый smoke-набор (20–30 кейсов) на каждый PR, полный прогон — ночью. Гейт держит два условия: абсолютный порог (pass rate не ниже X%) и отсутствие регрессии (не хуже текущего main). Инструменты — promptfoo в GitHub Actions, эвалы LangSmith, dataset runs в Langfuse; выбор вторичен, обязательность гейта первична.

Канарейка. Эвал на фиксированном датасете не покрывает живое распределение, поэтому новая версия промпта раскатывается на 5–10% трафика, и online-скоры канарейки (судья, refusal rate, фидбэк из урока 5) сравниваются с контролем несколько часов или дней — в зависимости от объёма. Только после этого 100%.

Так замыкается защита: кейс из инцидента попадает в датасет, датасет охраняет каждый PR, канарейка страхует то, чего в датасете ещё нет. Инцидент, прошедший весь путь, больше не повторяется молча.

Техника без процесса останавливается за месяц: датасет перестают пополнять, алёрты мьютят, разбор трейсов «переносится». Минимальный работающий ритуал для команды любого размера состоит из трёх элементов.

Еженедельный час трейсов. Вся команда — включая продакта — читает 20–30 трейсов из подготовленной выборки: негативный фидбэк, провалы судьи, новые кластеры, немного случайных. Формат: каждый читает свою пачку, записывает категории, последние 15 минут — сведение находок в таблицу и решения: какие кейсы — в датасет, какие фиксы — в бэклог. Этот час даёт больше общего понимания системы, чем любые отчёты.

Дежурный по качеству. Ротируемая роль на неделю: триаж алёртов качества, разметка аннотационной очереди, доведение кейсов до датасета. Без явного владельца петля — «общая ответственность», то есть ничья.

Метрики самой петли. Петля тоже нуждается в наблюдаемости: время от инцидента до кейса в eval-сете (цель — дни, не недели); доля фиксов, закрытых с регрессионным кейсом (цель — 100%); прирост датасета за неделю; возраст последнего полного прогона эвалов.

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