Оцінювання якості донавченої моделі: чому метрики брешуть
Відкладена вибірка та живий трафік розходяться майже завжди. На фіксованому наборі модель відповідає за шаблоном, який ми самі заклали в нього під час розмітки, а в продакшені надходять короткі запити без контексту, одруки, змішані мови та багатоходові діалоги.
Метрика на відкладеному наборі показує, наскільки модель повторила розмітника, а не наскільки вона корисна користувачу.
Після донавчання розходження посилюється. Модель перенавчається на формат відповіді з навчальних прикладів і втрачає частину базових умінь: падає якість на рідкісних сценаріях, зростають відмови й обриви генерації, ламається дотримання системної інструкції.
У звіті при цьому все зелене — набір той самий, шаблон той самий, а ціна помилки — відкат релізу та втрачена довіра до звітності.
Ми дивимося на якість за шарами: автоматичні метрики на відкладеному наборі, оцінювання LLM-as-judge з розміченими еталонами, ручна експертиза на спірних прикладах.
Додатково ганяємо модель у тіньовому режимі на реальному потоці та порівнюємо з поточним релізом за сегментами — за сценаріями, довжиною діалогу, часткою відмов та обривів.
Приймання релізу моделі будується як набір порогів, а не як одне число. Реліз не проходить, якщо деградація після донавчання зачіпає захищені сценарії, навіть коли середня метрика зросла.
Такий підхід описаний у відкритих наборах метрик на кшталт Ragas і доповнюється нашими еталонами під задачу.
Що змінюється, коли оцінювання відбувається на кожному релізі
Термін перевірки перед випуском — дні замість тижнів
Коли набір перевірок і метрик зафіксовано, він не збирається заново під кожен реліз. Прогін відбувається за одним сценарієм на одних даних, а розходження з попередньою версією видно у звіті одразу.
Термін перевірки перед випуском скорочується з тижнів до одного-двох днів — однаково для донавченої моделі та для правки інструкцій до неї.
Частка хибних випусків падає
Метрика на відкладеній вибірці, оцінювання моделлю-суддею та сліпа перевірка експертами дають три незалежні сигнали. Якщо хоч один не проходить поріг, реліз не йде до користувачів — рішення стає числовим, а не «ніби стало краще».
Відкатів після викату стає в рази менше: регресії ловляться до випуску, а не за скаргами в підтримку.
Єдині правила приймання замість домовленостей на словах
Поріг приймання фіксується заздалегідь: яка метрика, на якій вибірці, з яким допуском. Єдині правила приймання знімають залежність від того, хто сьогодні перевіряє і наскільки оптимістичний його звіт. Спір про смаки замінюється розбором відхилень за цифрами.
Регулярне оцінювання релізів накопичує історію
Кожен прогін залишає зріз: версія моделі, склад даних, значення метрик. Через кілька релізів видно, які правки реально рухають якість, а які — шум. Наступний цикл оцінювання відбувається швидше, бо перевіряємо те, що вже показало ефект.
Варіанти перевірки релізу: автотести, еталонний набір, експерти
Три способи перевірки відповідають на різні питання й не замінюють одне одного. Автоматичні метрики ловлять регресії там, де відповідь перевіряється формально, але сліпі до смислових зсувів при правильній формі.
Суддя-контур закриває вільні відповіді, зате успадковує зміщення тієї самої моделі. Експертна розмітка дає еталон, але її ресурс обмежений і не масштабується на кожен прогін.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Автоматичні метрики (точний збіг, формат, F1) | Вилучення полів, класифікація, виклик інструментів, перевірка схеми відповіді | Не бачить смислових помилок при коректній формі; на відкритих відповідях майже неінформативні |
| Суддя-контур на мовній моделі | Вільні відповіді: тон, повнота, дотримання інструкції; прогін на сотнях кейсів | Успадковує зміщення й сліпі зони моделі; потребує калібрування за експертними оцінками |
| Експертна розмітка | Еталон для спірних випадків, калібрування судді, відповіді з високою ціною помилки | Повільно, залежить від згоди між експертами, важко покрити весь обсяг |
| Комбінація шарів | Релізний контроль: дешевий шар на кожну зміну, дорогий — на межах | Потрібні зберігання еталонів, інфраструктура прогонів і розбір розходжень |
Як шари поєднуються
Розділяємо їх за частотою запуску: формальні перевірки йдуть на кожну зміну й відсікають явні поломки; суддя-контур — на розширеній вибірці перед релізом, де важливо побачити деградацію смислу; експерти підключаються на пограничних кейсах і для калібрування судді.
Такий порядок дає швидкий зворотний зв'язок і при цьому спирається на людський еталон там, де він дійсно потрібен.
Від аудиту до передачі: як будується контур перевірки
Контур перевірки збирається так, щоб рішення про приймання спиралося на повторюване вимірювання, а не на враження від вдалого демо.
Порядок робіт однаковий для будь-якої задачі — змінюються метрики, рубрики й пороги, але послідовність зберігається: спочатку описуємо, як якість оцінюють зараз, потім фіксуємо еталон і тільки потім автоматизуємо.
- Аудит процесу. Розбираємо, як ухвалюються рішення про якість сьогодні: де оцінювання йде очима, де за одним показаним прикладом, які дефекти не фіксуються взагалі. На виході — карта місць, де вердикт не відтворюється.
- Еталонний набір. Збираємо вибірку, що покриває часті сценарії, рідкісні та пограничні випадки. Набір версіонується разом із моделлю — без нього порівняння релізів між собою неможливе.
- Розмітка та узгодження експертів. Два-три профільних фахівці розмічають приклади незалежно, спірні випадки розбираються окремо, частка збігів рахується до старту робіт. Якщо експерти не сходяться між собою, автоматичне оцінювання не дасть опори.
- Автоматична перевірка. Додаємо детерміновані правила та перевірку другою моделлю: суддя отримує еталон відповіді, рубрику й вимоги до формату. Суддя калібрується на розмітці експертів, і при розходженні вище заданого рівня рубрика переписується, а не підганяється результат.
- Калібрування порогів. Для кожного класу помилок задаємо межу окремо: пропуск критичного дефекту не компенсується зростанням середньої оцінки. Пороги фіксуються до прогону.
- Регресійний прогін. Донавчена й базова моделі проганяються на одному наборі, різниця рахується за кожною метрикою окремо. Поліпшенням вважається тільки те, що підтверджено на еталоні.
- Регламент приймання й передача. Віддаємо документ зі складом набору, рубриками, порогами та процедурою їх перегляду, а також права на прогони.
Після передачі замовник запускає перевірку сам і бачить відхилення до викату. Обсяг еталона й пороги переглядаються в міру появи нових сценаріїв.
Набір метрик, еталонні дані та регламент приймання
Ми здаємо не лише донавчену модель, а й контур її оцінювання: після передачі команда замовника може прогнати нову версію на своїх даних і отримати той самий вердикт, що й ми.
Усі визначення, конфігурації та правила доступу фіксуються в документах, які не потрібно відновлювати з листування — їх достатньо відкрити й виконати.
- Реєстр метрик — таблиця, де для кожної метрики вказано визначення, спосіб розрахунку, зріз даних, поріг приймання та власник. Розходження в трактуванні закриваються до старту оцінювання, а не після спірного релізу.
- Розмічений еталонний набір — стратифікована відкладена вибірка: рідкісні класи та пограничні випадки представлені явно, кожен приклад розмічено двома експертами, спірні розібрані арбітром, згода розмітників зафіксована числом.
- Звіт про калібрування автоматичного судді — наскільки машинна оцінка збігається з експертною: згода за класами, частка розходжень, систематичне зміщення на користь довгих або впевнених відповідей.
- Політика доступу до даних — хто і на якій підставі бачить еталон, що знеособлюється, як ведеться журнал звернень. Окремо закриваємо ризик навчання на перевірочній вибірці.
- Регламент приймання — які метрики і на яких порогах мають зійтися, що робимо при провалі однієї з них і в яких випадках версія відхиляється цілком.
- Документація контуру — схема прогону, словник метрик, інструкція розмітника та чек-лист запуску: оцінку відтворює інженер, який не брав участі в розробці.
- Конфігурації та запуск оцінювання — єдиний прогін на знеособленому зрізі дає звіт у фіксованому форматі, тому результати двох версій порівнюються построково.
Кейс: метрики релізу до та після впровадження
Клієнт — служба підтримки з базою знань на кілька тисяч статей, поверх якої працює донавчена модель. Відповідає вона не «загалом», а за конкретними документами, і кожен реліз — нова гілка донавчання. Оцінювати якість доводилося вибірково й уже після викату: відтворюваного набору перевірок не було.
До впровадження експерт розбирав вручну близько двохсот діалогів на реліз — це два робочі дні й менше п'яти відсотків покриття.
Решту перевіряли за відчуттям, спірні відповіді оцінювали «на око», і чотири релізи з десяти поверталися на доопрацювання вже після запуску, коли помилку бачили користувачі.
Як побудували заміри
Зібрали еталонний набір із шести сотень розмічених діалогів: питання, правильна відповідь за базою, чого у відповіді бути не повинно. На ньому рахуємо три речі — влучання у факт з документа, відсутність вигаданих деталей, повноту відповіді.
Прогін автоматизували через Ragas, а первинну розмітку спірних випадків віддали LLM-as-judge: експерт розбирає не весь реліз, а тільки розходження з оцінкою моделі, їх залишається близько десяти відсотків.
Що стало: перевірка релізу займає три-чотири години замість двох днів, покриття — усі сто відсотків діалогів з еталонного набору. Повернення на доопрацювання скоротилися з чотирьох релізів до одного з десяти, а регрес за минулими сценаріями видно ще до викату.
Набір версіонується разом із моделлю, тому дві гілки донавчання порівнюються на одних і тих самих прикладах.
Чим відрізняється онлайн-контроль від перевірки на еталонному наборі?
Еталонний набір — це зафіксований зріз запитів із розміткою, який проганяють до викатки. Він відповідає на питання «чи не зламали те, що вже працювало», і дає змогу порівнювати версії моделі між собою на незмінних даних.
Онлайн-контроль відповідає на інше питання: після релізу і поведінка користувачів, і вхідні дані вже не ті, що були під час підготовки донавчання.
| Контур | На що відповідає | Чого не ловить |
|---|---|---|
| Еталонний набір | Регрес: чи зламалося те, що працювало | Зсув вхідних даних після викатки |
| Онлайн-контроль | Дрейф: розподіл запитів, відмови, формат відповіді | Причинність — сигнал є, причина неясна |
Онлайн-контроль рахує частку відмов, повноту й довжину відповідей, звернення до зовнішніх джерел і розподіл оцінок судді. Коли метрика виходить за заданий коридор, вмикається відстеження дрейфу, а спірні відповіді йдуть у ручний розбір вибірки.
Далі контури стикуються: розібрані випадки після експертної розмітки поповнюють еталонний набір, тому він зростає разом із продуктом, а не застаріває.
Першу лінію оцінювання тримає LLM-as-judge на попарному порівнянні версій, другу — експерти на вибірці; розрахунок метрик і зберігання прогонів закриває Ragas.
Якщо залишити лише один контур, отримуємо два передбачувані збої: набір непомітно перетворюється на музей минулого продукту, а онлайн-сигнал — на потік скарг, який нема до чого прив'язати.
Часті технічні питання про контур перевірки
Контур перевірки збираємо до запуску донавчання — інакше метрики мимоволі підганяються під уже отриманий результат.
На узгодженні зазвичай спливають одні й ті самі питання: обсяг еталонного набору, розмітка без профільних експертів, шум у вибірці та перенесення метрик між ітераціями.
Який обсяг еталонного набору вважаємо достатнім?
Орієнтир — від 30-50 прикладів на кожен значущий сценарій, рідкісні класи добираємо окремо, інакше метрика за ними стрибає від ітерації до ітерації. Набір версіонуємо й фіксуємо контрольною сумою, щоб порівняння прогонів залишалося коректним.
Чи можна розмітити вибірку без профільних експертів?
Формальні критерії — так: письмова інструкція, два розмітники і третій голос при розходженні. Предметні вимоги так не закрити — невелике експертне калібрування задає еталон, далі обсяг добирає модель-суддя під контролем згоди з експертом.
Що робити з шумом у вибірці?
Стратифікуємо набір за сценаріями й прибираємо майже однакові приклади — вони перекошують частку успіху. Пограничні випадки виносимо в окремий шар: усереднена метрика без розкиду за підгрупами не показує, де модель ламається.
Чи можна перевикористати метрики з інших проєктів?
Каркас переноситься: перевірки формату, повноти відповіді та відмов від предметної області не залежать. Перезбираємо еталонні приклади, критерії та поріг спрацювання під конкретну задачу.
Як у перевірці бере участь замовник?
Власник продукту узгоджує критерії та приймає результат на закритому еталонному наборі. Потрібні кілька годин профільного експерта на калібрування — далі прогони йдуть без його участі.
Обговоримо задачу: що надіслати, щоб ми повернулися з планом
Щоб обговорити задачу предметно й повернутися з планом робіт, а не із загальними міркуваннями, потрібен мінімум вхідних даних для оцінки — те, що вже є у вас на руках.
За логами пілота видно, де модель помиляється найчастіше, а за еталонними відповідями — який рівень якості вважається прийнятним. Опишіть задачу у вільній формі: цього достатньо, щоб почати.
- еталонний набір: 200–500 реальних запитів з відповідями та розміткою «правильно / неправильно» — на ньому калібруємо автоматичне оцінювання другою моделлю й міряємо точність донавчання;
- логи пілота: сирі діалоги, версії підказок і відповіді моделі в тому вигляді, у якому їх бачили користувачі;
- критерії приймання: які помилки критичні, які допустимі та в якій частці випадків;
- опис домену й сценаріїв: кому відповідає модель, на які питання і що у відповідях заборонено;
- орієнтир для порівняння: метрики базової моделі або попередньої версії донавчання;
- обмеження щодо даних і доступів: де лежать дані, чи потрібне знеособлення, чи можна залучати зовнішніх експертів-розмітників;
- приклади спірних відповідей: 10–20 випадків без одностайної думки — вони задають межу розмітки.
Далі надсилаємо план робіт: склад етапів від збору еталонного набору до приймання, точки контролю на кожному кроці, ролі в команді. Якщо чогось із переліку немає під рукою — скажіть прямо: частину вхідних даних ми збираємо й розмічаємо самі, окремим етапом.
