Дообучення 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

Щоб розмова була предметною, а не «розкажіть у двох словах, чого ви хочете», ми починаємо з короткого брифу. Так ми одразу бачимо, де саме у вашому процесі тестування дає збій, і повертаємося з оцінкою та планом, а не із загальними міркуваннями.

Що варто тримати під рукою до першої зустрічі:

• Яка модель використовується зараз і на якій гілці — базова чи вже дообучена на ваших даних.
• Що саме оптимізуємо: точність відповідей, дотримання формату, тон, відмову від небажаних тем.
• Чи є еталонний набір запитів і відповідей, за яким можна рахувати метрику, чи його потрібно зібрати.
• Як зараз порівнюються дві версії моделі — вручну, очима кількох експертів чи автоматичними перевірками.
• Які обмеження щодо затримки відповіді та вартості інференсу критичні для продукту.
• Хто з боку замовника ухвалює рішення «ця версія краща» і за якими критеріями.
• Чи є вимоги до відтворюваності: чи потрібно повертатися до результатів тесту через місяць.

Формати роботи підбираємо під задачу. Це може бути разовий аудит методики тестування, коли ми розбираємо ваш поточний підхід і показуємо, де він дає зміщений результат.

Або повний цикл: готуємо набір тестових запитів, налаштовуємо автоматичну оцінку, проводимо порівняння версій і віддаємо звіт з метриками. Або регулярний процес — ви отримуєте конвеєр, у якому кожна нова версія моделі проходить однакову перевірку перед викаткою.

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