Как диагностировать сбои QA кастомных LLM за 7 шагов

Заметки из релизного цикла — часть VI

Сьют scored-QA начал помечать модель медицинского Q&A одного из клиентов. Главное число — агрегированное качество по всем срезам — упало на 6 пунктов за ночь. Команда два дня отлаживала модель. Перезапускали файн-тюны. Откатывались к предыдущему релизу. Цифры не двигались.

Утром третьего дня кто-то заметил, что сьют оценки обновили в ту же ночь, когда началась регрессия. В тестовый набор добавили три новых промпта про педиатрические дозировки, а модель никогда не видела педиатрических дозировок при обучении. «Сбой QA» был не регрессией модели. Это было событие покрытия среза: сьют начал спрашивать о том, что модель никогда и не должна была знать.

По нашим клиентским развёртываниям это доминирующий паттерн. Тревога «сбой QA» — это симптом. Модель оказывается причиной примерно в одном случае из семи. В остальных шести случаях баг находится где-то выше по конвейеру: в дизайне оценки, калибровке судьи, SHA промпта, конвейере препроцессинга, версии датасета или индексе ретривера. Каждый из этих классов багов выглядит одинаково с точки зрения тревоги — число упало — но имеет совершенно разное исправление.

Этот пост — диагностическое дерево, по которому мы идём по порядку, когда срабатывает тревога. Шесть шагов исключают немодельные причины, и только седьмой шаг рассматривает саму модель. Каждый шаг имеет конкретный API-запрос или query, который отвечает на него. К моменту, когда вы завершите эти шесть, вы либо точно знаете, что чинить, либо заслужили право посмотреть на модель.

Дерево решений

Дерево последовательное, потому что шаги идут от дешёвых к дорогим. Шаг 1 — это git diff сьюта оценки; шаг 7 — цикл файн-тюна. Вы хотите потратить десять минут на каждую из шести дешёвых проверок, прежде чем потратить неделю на дорогую.

Шаг 1 — Покрывала ли оценка этот срез?

Симптом. Агрегированное качество падает, но разбивка по срезам показывает один проваливающийся срез, в то время как остальные ровные. Или — что ещё запутаннее — каждый срез слегка падает, и все на похожую величину.

Диагностика. Сравните SHA манифеста сьюта оценки с предыдущим релизом. Если сьют оценки изменился, а модель — нет, регрессия в оценке, а не в модели.

# Сравнить SHA манифеста сьюта оценки между релизами
curl https://api.divinci.ai/v1/releases/rel_a01c66 | jq '.eval_suite_sha256'
curl https://api.divinci.ai/v1/releases/rel_8f72b1 | jq '.eval_suite_sha256'
# Разные? Ваша оценка изменилась. Проаудируйте, что было добавлено.

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

Где это прячется в нашем конвейере. Этап 1 — Регистрация привязывает SHA сьюта оценки к манифесту релиза. Диагностика выше — это просто диф двух манифестов. Причина, по которой баг занял у команды медицинского Q&A два дня, в том, что у них не было дифа на уровне манифеста — они сравнивали чекпойнты модели, а не манифесты релизов.

Шаг 2 — Откалиброван ли судья по людям на этом срезе?

Симптом. Срез, который новый для сьюта оценки, плохо оценивается, но люди, рецензирующие выходы модели на этом срезе, оценивают их как нормальные. Судья считает, что модель проваливается; люди — нет.

Диагностика. Вычислите Spearman ρ между оценками LLM-судьи и небольшой выборкой человеческих оценок (50 элементов) на проваливающемся срезе. Если ρ < 0.4, судья не измеряет то, что измеряют люди на этом срезе.

curl -X POST https://api.divinci.ai/v1/judges/<judge_id>/calibrate \
  -d '{ "slice": "pediatric-oncology-dosing", "human_ratings_csv": "..." }'
# → { "spearman_rho": 0.31, "interpretation": "judge_uncalibrated_for_slice" }

Исправление. Либо выберите другую модель-судью для этого среза, либо используйте chain-of-judges с арбитром. MT-Bench^[1] показывает, что GPT-4 как судья согласуется с людьми >80% в среднем, но с разбросом по категориям от 86% (программирование) до 36–44% (письмо/гуманитарные). Разброс — это операционно значимое число; «хорошо в среднем» скрывает срезы, где судья ошибается.

Где это прячется в нашем конвейере. Этап 2 — Гейт требует откалиброванного судью на срез. Пост Калибровка ИИ-судьи документирует процедуру. Если срез добавили в оценку без шага калибровки, у вас структурно ненадёжный гейт.

Шаг 3 — Совпадает ли SHA шаблона промпта с продакшеном?

Симптом. Качество падает, но model_ref и dataset_ref не изменились. Ничего в обучении не менялось. Модель — та же модель. И всё же.

Диагностика. Сравните SHA prompt_template_ref в манифесте проваливающегося релиза с предыдущим. Правка системного промпта в 38 символов, которая «улучшает краткость», может изменить поведение ниже по конвейеру сильнее, чем полное переобучение.

curl https://api.divinci.ai/v1/releases/rel_a01c66 | jq '.prompt_template_ref'
curl https://api.divinci.ai/v1/releases/rel_8f72b1 | jq '.prompt_template_ref'
# Разные? Вытащите диф. Посмотрите внимательно.

Исправление. Относитесь к промптам как к коду. Пост о 10 сбоях релизов разбирает режим сбоя «правка через дашборд» — постмортем Semver Lie от Tianpan^[2] называет это доминирующим паттерном сбоев 2026 года. Если вы можете доказать, что промпт изменился, вы нашли свой баг.

Шаг 4 — Совпадает ли конвейер препроцессинга с продакшеном?

Симптом. Модель проходит оценку локально. Та же модель проваливает ту же оценку в продакшене. Тот же model_ref, тот же промпт, тот же датасет.

Диагностика. Вытащите SHA preprocessing_ref из продакшен-манифеста и убедитесь, что оценка прогонялась с тем же. Классический случай: обучение нормализует пробелы и приводит к нижнему регистру; продакшен — нет. Оценка прошла через продакшен-препроцессинг; всё совпало. Пока кто-то не обновил препроцессинг только с одной стороны.

curl https://api.divinci.ai/v1/releases/rel_a01c66 | jq '.preprocessing_ref'
# Сравните с препроцессингом, который реально использовал ваш training/eval-харнесс.

Исправление. Контейнеризуйте препроцессинг как версионированный артефакт. Ссылайтесь на него из манифеста. Откажитесь от деплоя, если SHA препроцессинга гейта отличается от продакшеновского.

Шаг 5 — Совпадает ли SHA датасета с продакшеном?

Симптом. Оценки gate-eval проваливающегося релиза отличаются от оценок gate-eval той же модели накануне.

Диагностика. Сравните поле dataset_version между двумя релизами. Сьют оценки остался с тем же именем, но содержимое датасета обновили и переразметили. То же имя, другой SHA, другие оценки.

diff <(curl .../rel_a01c66 | jq '.dataset_version') \
     <(curl .../rel_8f72b1 | jq '.dataset_version')

Исправление. Хешируйте содержимое ваших датасетов. Имя датасета — не версия; SHA — да.

Шаг 6 — Совпадает ли SHA индекса ретривера с продакшеном?

Симптом. Только для RAG-нагрузок. Качество падает на вопросах, зависящих от извлечённого контекста. Вопросы прямого ответа без изменений.

Диагностика. Вытащите SHA retrieval_index_ref из манифеста. Сравните с retrieval-индексом gate-оценки. RAG-индекс обновили за ночь (свежий прогон ingestion); gate-оценка кешировала более старый retrieval; продакшен-канарейка использовала новый.

curl https://api.divinci.ai/v1/releases/rel_a01c66 | jq '.retrieval_index_ref'

Исправление. Привяжите SHA индекса ретривера к манифесту, ровно так же, как привязываем препроцессинг. Каденция автоматической ротации индекса AutoRAG делает эту проверку особенно ценной — индекс обновится у вас сам, авторизовали вы это или нет, если вы его не пиннингуете.

Шаг 7 — Сама модель, наконец

Шесть шагов позади. Оценка покрывает срез. Судья откалиброван. SHA промпта совпадает. Препроцессинг совпадает. Датасет совпадает. Индекс ретривера совпадает.

Теперь — и только теперь — вы заслужили право посмотреть на модель.

Диагностика этого шага — сравнение Spearman на срез против предыдущего релиза, при этом оба релиза оцениваются по одному и тому же привязанному к манифесту датасету, препроцессингу и retrieval. Число, которое вы получаете, — чистый сигнал: настоящая регрессия на срезе без вышестоящих конфаундеров.

curl -X POST https://api.divinci.ai/v1/releases/<failing_id>/diff-eval \
  -d '{ "baseline_release_id": "<prior_id>", "slices": ["legal-IP-licensing"] }'
# → { "spearman_rho_failing": 0.41, "spearman_rho_baseline": 0.68, "delta": -0.27 }

Если дельта подтверждает настоящую регрессию: автооткат срабатывает (если вы уже не вызвали его вручную), и проваливающаяся модель переобучается на расширенном корпусе покрытия срезов. Если гейт, продвинувший этот релиз, изначально пропустил срез, гейт — это тоже баг — возможности 4 не хватает в вашем релизном конвейере.

Как на самом деле выглядит распределение

Формулировка «1 из 7» выше не была риторическим приёмом. Это примерно то распределение, которое мы видим по клиентским развёртываниям. Из каждых семи тревог QA:

Два крупнейших среза — пробел покрытия оценки и некалиброванный судья. Вместе они дают половину QA-тревог. Ни то ни другое — не проблема модели. Обе — проблемы того, как вы измеряете модель.

Чего это не решает

Три честных ограничения:

Распределение — наше, не ваше. Проценты выше получены из нашей клиентской когорты и инструментария нашего конвейера. Если у вас другая нагрузка — тяжёлая мультимодальная, агентно-оркестрированная, одношотово-генеративная — распределение будет другим. Порядок диагностики должен оставаться; цифры за каждым шагом — нет.

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

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

FAQ

Почему моя LLM выдаёт разные ответы на похожие промпты?

Чувствительность к промпту реальна, но это не всегда причина QA-тревоги — иногда это симптом вышестоящего бага. Пройдите диагностику. Если SHA шаблона промпта совпадает, препроцессинг совпадает и датасет совпадает, тогда да — у модели широкий разброс на этом срезе, и нужен более детерминированный путь декодирования или другой судья. Если что-то выше по конвейеру изменилось, чините сначала это.

Как часто следует переоценивать ваши бенчмарки LLM?

Переоценивайте содержание бенчмарка каждый раз, когда форма трафика на продакшен-срез значимо меняется. Переоценивайте калибровку судьи бенчмарка не реже раза в квартал — модели-судьи дрейфуют быстрее, чем вы думаете. Главный источник ложных QA-тревог — бенчмарк, валидированный последний раз 18 месяцев назад и измеряющий то, чего ваш продакшен больше не делает.

Что вызывает галлюцинации в кастомных языковых моделях?

У галлюцинаций несколько вышестоящих причин — сбои retrieval (шаг 6 в дереве выше), пробелы покрытия обучения (шаг 1, опосредованно) и проблемы пути декодирования (настоящая модельная задача в шаге 7). AutoRAG адресует причины со стороны retrieval, привязывая индекс ретривера к манифесту релиза и перепиннингуя его при каждом релизе. Остальные две требуют исправлений на уровне конвейера выше модели.

Как понять, что проблема в обучающих данных?

Если SHA датасета в проваливающемся релизе совпадает с SHA датасета в предыдущем хорошем релизе (шаг 5 дерева), данные — не непосредственная причина. Если они отличаются, вы её нашли. Более сложный вопрос — «полон ли датасет для покрытия наших продакшен-срезов?» — это то, что проверяет шаг 1. Датасет, полный для оценки, но неполный для продакшен-трафика, — это проблема покрытия среза.

Можно ли исправить сбои QA без переобучения всей модели?

Да — в шести случаях из семи исправление — это не переобучение. У шагов 1–6 в дереве есть исправления, не касающиеся модели: обновить оценку, перекалибровать судью, перерегистрировать SHA промпта, починить препроцессинг, перепиннинговать датасет или перепиннинговать индекс ретривера. Переобучение — это шаг 7, самое дорогое исправление, зарезервированное для настоящих регрессий модели. Аудит-трейл релизного конвейера позволяет делать эти вышестоящие исправления с той же дисциплиной происхождения, что и для изменения модели.

References

1. Разброс LLM-as-judge по категориям. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023). >80% общего согласия GPT-4 с людьми при разбросе по категориям от программирования (86%) до письма (36–44%). Опора для шага 2 — почему калибровку судьи нужно измерять на срезе, а не предполагать по опубликованной средней цифре.
2. The Semver Lie. Tianpan — The Semver Lie: how an LLM minor update breaks production (апрель 2026). Доминирующий разбор паттернов сбоев 2026 года. Называет дрейф промптов через правки в дашборде самой цитируемой причиной продакшен-инцидентов LLM. Опора для шага 3.
3. NIST AI RMF — функция Measure. NIST AI Risk Management Framework. Функция «Measure» явно охватывает валидность бенчмарков и покрытие оценки как часть управления, а не отдельную инженерную задачу. Цитируется как институциональная опора для отношения к дизайну оценки как к первому диагностическому шагу.
4. RAGAS — оценка retrieval-augmented generation. Es et al., RAGAS: Automated Evaluation of Retrieval Augmented Generation (arXiv:2309.15217). Эталонный фреймворк для оценки со стороны RAG. Опора для шага 6 — отделение сбоев retrieval от сбоев генерации требует RAG-осведомлённой дисциплины оценки.
5. Внутреннее — распределение первопричин по клиентским развёртываниям. Проценты в круговой диаграмме — наше внутреннее наблюдение по развёртываниям клиентов Divinci, а не из контролируемого бенчмарка. Ваше распределение будет варьироваться в зависимости от типа нагрузки, каденции файн-тюна и дисциплины команды. Относительный порядок (доминирование шагов 1–2) стабилен по когорте, которую мы измеряли; точные проценты не переносимы в вашу среду без ваших собственных данных.
6. Четырёхэтапный релизный конвейер. Как построить CI/CD-конвейер LLM с Divinci AI. Каждый диагностический шаг в этом посте соответствует полю манифеста, привязанному на этапе 1 — Регистрация. Без дисциплины манифеста выше по конвейеру диагностика теряет хватку; нельзя дифать то, что вы не привязали.

Следующее в этой серии: Автоматизированное регрессионное тестирование кастомных LLM в 2026 году. Этот пост — о диагностике после срабатывания QA-тревоги. Следующий — о дисциплине регрессионного тестирования, которая запустила тревогу в первую очередь: что класть в оценку, как держать её честной и что делать, когда регрессионный тест начинает не соглашаться с вашим судьёй.