Дообучение LLM: как провести A/B-тест и не ошибиться

A/B-тестирование LLM: где ломается дообучение

A/B-тестирование LLM ломается не на этапе запуска, а раньше — когда команда выбирает метрику, которая не отражает задачу. Классический сбой: дообучение модели оценивают по средней длине ответа или по оценке «нравится/не нравится», хотя бизнес-цель — доля корректно закрытых обращений. Метрика начинает расти, а качество ответов в проде падает: модель научилась писать длиннее и увереннее, но не точнее.

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

Третий сбой — отсутствие контроля версий промптов. Когда системная инструкция, шаблон и параметры генерации меняются между прогонами, вы сравниваете не модели, а случайный набор условий. Разница в ответах списывается на дообучение, хотя её дал новый промпт. Без фиксации версий промпта, набора данных и конфигурации запуска результат A/B-тестирования LLM невозможно воспроизвести — а значит, и принять по нему решение.

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

Что даёт корректный тест модели: эффект в цифрах

Корректно поставленный A/B-тест превращает дообучение из спора о вкусах в измеримый инженерный результат. Мы сравниваем две версии модели на одном потоке реальных запросов, фиксируем метрики качества до и после и видим, где именно новая версия выигрывает, а где деградирует. Без такого сравнения любое «стало лучше» остаётся мнением, а не фактом, на который можно опереться при выкатке.

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

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

Скорость оценки тоже входит в результат. Когда прогон сравнения автоматизирован и повторяем, следующая итерация дообучения проверяется за часы, а не за недели ручного разбора. Это меняет темп работы: команда успевает проверить больше гипотез и быстрее отказывается от тупиковых, не тратя на них ресурс.

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

Метрики оценки: точность, полнота, стабильность

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

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

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

Сравнивать версии корректно на одном и том же наборе, с одинаковыми настройками генерации и единой рубрикой оценки. Тогда дообучение даёт сопоставимый результат: видно, где прирост реальный, а где — эффект другого промпта или случайного разброса.

Способы проведения A/B-теста: сравнение подходов

Выбор схемы сравнения зависит от того, насколько дорого ошибка модели в проде и есть ли у вас трафик для статистики. Офлайн-тест прогоняет обе версии на фиксированном наборе запросов с эталонными ответами — это быстро и повторяемо, но не покажет, как модель ведёт себя на живых формулировках пользователей. Онлайн-тест делит реальный трафик между вариантами и меряет целевую метрику, зато требует достаточного объёма запросов, иначе разница утонет в шуме.

Гибридная схема снимает ограничения обоих: сначала офлайн отсеивает заведомо слабые варианты, затем победитель проверяется на живом трафике. Ниже — сравнение по применимости и ограничениям.

Как выбрать под задачу

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

На практике мы чаще идём гибридно: офлайн-контур отсеивает варианты, онлайн подтверждает победителя на ограниченной доле трафика. Так решение опирается на фактические данные, а не на одну метрику.

Этапы внедрения тестирования LLM

Процесс строится вокруг одного принципа: A/B-тестирование LLM имеет смысл только тогда, когда зафиксированы метрики, корпус запросов и правила приёмки. Иначе сравнение двух версий превращается в спор о вкусах на десяти примерах. Ниже — последовательность, которую проходим на каждом проекте дообучения.

Как устроена работа

1. Аудит текущей модели. Собираем реальные запросы из логов продукта, размечаем их по типам задач и выделяем долю отказов: где модель галлюцинирует, где уходит от формата, где теряет контекст. На выходе — базовая линия, с которой будем сравнивать всё дальнейшее.
2. Схема теста. Определяем контрольную и тестовую группы, долю трафика на каждую, набор метрик (точность ответа, следование формату, полнота, устойчивость к перефразировкам) и порог, при котором новая версия считается лучше. Порог фиксируем до запуска — иначе результат подгоняется под желаемый.
3. Подготовка данных. Чистим корпус, убираем дубли и утечки между обучающей и проверочной выборками, балансируем редкие сценарии. Отдельно держим отложенный набор, который не участвует в дообучении ни на одном шаге.
4. Настройка и запуск. Обучаем модель, прогоняем оба варианта на одном и том же наборе запросов, считаем метрики и разбираем расхождения вручную — автоматическая оценка пропускает смысловые ошибки, которые видит человек.
5. Проверка на устойчивость. Смотрим поведение на граничных формулировках, длинных диалогах и запросах вне темы. Проверяем, что рост качества не куплен деградацией на редких, но важных сценариях.
6. Передача регламента. Отдаём документ: как запускать тест, какие метрики считать, где хранить разметку, при каких условиях откатывать версию. Команда заказчика повторяет цикл без нас.
7. Повторный прогон. После каждого изменения промптов, данных или базовой модели тест запускается заново — иначе накопленные правки снова превращаются в непроверенные гипотезы.

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

Что заказчик получает на руки

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

• Конфигурации эксперимента — файлы с параметрами обучения и инференса, зафиксированные версии базовой модели и адаптеров, зерно генерации. Один и тот же запуск воспроизводится у вас и у нас.
• Схемы тестов — разбиение трафика на контрольную и тестовые группы, доля трафика на вариант, критерии остановки, набор метрик и порог, при котором вариант признаётся лучше или хуже.
• Политики доступа — кто из сотрудников видит промпты и логи, где хранятся данные, что маскируется до записи, как разграничены права на выгрузку.
• Документация по данным — происхождение обучающей и проверочной выборок, правила разметки, доля отбракованных примеров, известные смещения.
• Регламент выката — порядок переключения трафика, условия автоматического отката на предыдущую версию, ответственный за решение.
• Регламент мониторинга — какие метрики качества и стоимости снимаются постоянно, с какой периодичностью пересматривается модель, кто реагирует на деградацию.
• Отчёт по эксперименту — результат A/B-теста с доверительными интервалами, разбором расхождений между группами и явным списком того, что тест не доказал.

Каждый артефакт живёт в вашем репозитории и обновляется вместе с моделью. Если завтра вы меняете поставщика или собираете контур на своих мощностях, документация и регламенты переносятся как есть — переписывать логику эксперимента не придётся.

Чем отличается офлайн-тест от онлайн-теста LLM?

Офлайн-тест — это прогон модели на заранее собранном наборе запросов с известными эталонными ответами. Вы фиксируете датасет, считаете метрики по каждой паре «вопрос-ответ» и сравниваете базовую модель с дообученной на одних и тех же данных. Скорость здесь определяется размером набора: тысяча диалогов проходит за минуты, повторный прогон после правки гиперпараметров стоит столько же. Риск — в отрыве от реальности: датасет быстро устаревает, а метрики не ловят то, что важно пользователю.

Онлайн-тест запускает обе версии на живом трафике и раскидывает запросы между ними. Здесь вы видите не оценку судьи, а поведение: долю принятых ответов, повторы, длину диалога, отказы. Скорость получения сигнала ниже — нужно накопить статистически значимый объём на каждой ветке, иначе разница окажется случайной. Стоимость выше: работают две модели, растёт нагрузка на инференс, часть запросов уходит на ручную разметку.

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

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

Кейс: как мы снизили долю ошибочных ответов

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

Мы начали с того, что зафиксировали базовую линию: прогнали через ассистента набор реальных вопросов с эталонными ответами и разметили, где именно модель ошибается — подмена источника, потеря условия, неверная трактовка формулировки. Оказалось, что большая часть ошибок приходится на несколько типов вопросов, а не размазана равномерно.

Что меняли

Дообучение шло на парах «вопрос — корректный ответ с указанием источника», собранных из тех же регламентов, что и в рабочем контуре. Отдельно добавили примеры, где модель должна была распознать устаревшую редакцию и не использовать её. Настройки подбирали не на глаз: сравнение версий шло через A/B-тест на одной и той же выборке вопросов, с одинаковыми условиями и фиксированным набором метрик — доля ошибочных ответов, доля ответов со ссылкой на неверный источник, доля отказов от ответа.

Результат в метриках

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

Обсудим вашу задачу по тестированию LLM

Чтобы разговор был предметным, а не «расскажите в двух словах, что хотите», мы начинаем с короткого брифа. Так мы сразу видим, где именно в вашем процессе тестирование даёт сбой, и возвращаемся с оценкой и планом, а не с общими соображениями.

Что стоит держать под рукой к первой встрече:

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

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

Опишите задачу в свободной форме: что за продукт, какая модель, что не устраивает в текущем тестировании. Мы вернёмся с оценкой сроков, планом работ и тем, какие данные понадобятся от вас на старте.