Чому оцінка якості LLM ламається після релізу
Офлайн-набори прикладів і реальний трафік розходяться майже завжди. На закритій вибірці метрики виглядають рівно, але в проді розподіл запитів інший: короткі уточнення, змішані мови, уривки контексту, вкладення.
Оцінка якості LLM за середнім балом цього не ловить — модель впевнено відповідає там, де раніше чесно говорила «не знаю».
Найгірше те, що зміни приходять по одній. Правка формулювання в системному промпті, зміна версії моделі, новий інструмент у ланцюжку викликів — і регресії після оновлення промптів проявляються не в тому сценарії, який чіпали, а в сусідньому.
Усю матрицю сценаріїв після кожної такої правки ніхто не перевіряє, тому галюцинації в проді спливають через дні.
Дрейф відповідей моделі накопичується повільніше, але так само непомітно: зовнішній постачальник оновлює модель на своєму боці, і формулювання, формат відповіді, готовність слідувати інструкції змінюються без жодної правки на нашому боці.
Ручні вибіркові перевірки тут не рятують — інженер фізично переглядає десятки діалогів, тоді як за добу їх тисячі, і вибірка зміщена до тих звернень, про які вже написали в підтримку.
У підсумку перший, хто помічає збій, — клієнт. Він отримує неправильне посилання, вигадану цифру або відмову там, де раніше була відповідь, і втрачає довіру до продукту загалом, а не до одного сценарію.
Розбираємо, як це закривається: безперервним оцінюванням, яке ловить розбіжності до того, як вони дійдуть до користувача.
Автоматичне оцінювання відповідей замість ручних прогонів
Ручні прогони масштабуються лінійно: перевірити нову версію промпту на двох сотнях діалогів — це день роботи експерта, а на момент розбору частина відповідей уже не відповідає поточній конфігурації.
Регулярний контур перевірок знімає цю лінійність: частину рішень бере на себе автоматика, людина розбирає лише спірні випадки.
Скільки ручної роботи йде з процесу
Автоматизація перевірок відповідей будується на однозначних критеріях: відповідь спирається на джерело, не вигадує факти, тримає заданий тон, не розкриває внутрішні інструкції.
Сформульовані один раз, вони застосовуються до кожного прогону однаково — різні експерти перестають тлумачити правильність по-своєму.
Скорочення ручної розмітки відбувається за рахунок відсікання очевидних випадків: автоматика сама позначає відповіді з високою схожістю до еталону й піднімає нагору ті, де розбіжність значуща. Людині залишається десята частина вибірки — пограничні та конфліктні діалоги.
За який час ловиться регресія
Braintrust зберігає історію прогонів, тому новий набір відповідей порівнюється з попереднім одразу після збірки: метрики за єдиними критеріями правильності рахуються автоматично, просідання видно у звіті без ручного зіставлення.
Швидкість виявлення регресій вимірюється хвилинами: правка промпту або зміна моделі проганяються на історичних діалогах і дають відповідь до викату, а не через тиждень експлуатації.
Розбіжності зафіксовані за конкретними діалогами — причина відкату видна без повторного розслідування.
Варіанти контуру перевірок: порівняння підходів
Контур перевірок — це метрики, набори даних і правила розмітки, які відповідають на питання, чи стало якість відповідей кращою після правки моделі або формулювання запиту.
Збирають його трьома способами, і вибір залежить не від розміру команди, а від того, як часто змінюються сценарії та хто бере участь у розмітці.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Самописний контур на відкритих бібліотеках оцінювання | Стандартні метрики, розмітка силами команди | Порівняння прогонів і версій наборів живе в службових скриптах, підтримка зростає |
| Зовнішня платформа оцінювання відповідей | Потрібні історія прогонів, відтворюваність, спільна робота | Частина даних іде в зовнішній контур, потрібен експорт метрик назад |
| Гібридна схема перевірок | Автоматика масово, експертна розмітка точково | Потребує єдиного формату наборів даних і версії правил |
Коли достатньо відкритих бібліотек
Якщо задачі однотипні — класифікація, вилучення полів, перевірка формату відповіді — достатньо відкритих бібліотек. Метрики рахуються локально, набір даних лежить поруч із кодом, прогон запускається на кожну зміну. Контур прозорий: видно, яка функція рахує яку метрику.
Межа настає на другій розміченій вибірці, коли порівнювати висновки двох прогонів вручну вже незручно.
Коли потрібен окремий зовнішній контур
Окремий контур потрібен, коли важливі відтворюваність і розмітка силами кількох людей. Braintrust зберігає версії наборів даних і метрик, тому спір «стало гірше чи здалося» закривається посиланням на конкретний прогон, а не повторним запуском скриптів.
Гібрид знімає компроміс: автоматичні перевірки залишаються в репозиторії, а експертні оцінки та порівняння версій — у зовнішньому контурі.
Етапи впровадження: від аудиту сценаріїв до регламенту
Контур перевірок будуємо так, щоб кожна правка промпту або моделі проходила один і той самий набір перевірок і результат був порівнюваний із попереднім прогоном. Нижче — порядок робіт: від розбору сценаріїв до регламенту, за яким замовник працює далі сам.
Аудит і постановка критеріїв
Починаємо з аудиту сценаріїв асистента: вивантажуємо реальні діалоги та розмічаємо, де відповідь пішла не туди — втрата контексту, вигадані факти, неправильний тон.
З цього переліку виростають критерії правильності відповіді: для кожного сценарію фіксуємо, що вважаємо правильним, що — допустимим відхиленням, а що — дефектом.
- Розбираємо сценарії та класифікуємо помилки за типами — отримуємо список того, що взагалі потрібно перевіряти.
- Формулюємо критерії правильності: обов’язкові факти, допустимі формулювання, заборони у відповіді.
- Збираємо набір перевірок — питання з еталонними відповідями та автоматичні перевірки на формат і обов’язкові блоки.
Перевірка на історичних даних і викат
Набір перевірок не можна приймати на віру, тому проганяємо його на історичних даних і звіряємо з ручною розміткою. Якщо автоматичне оцінювання розходиться з оцінкою експерта частіше за обумовлену частку випадків, правило переписуємо.
- Проганяємо контур на накопичених діалогах і звіряємо з ручною розміткою.
- Налаштовуємо регулярні прогони на Braintrust на кожну зміну промпту або моделі; у звіті — динаміка за кожним критерієм.
- Викочуємо контур перевірок у робочий режим і передаємо регламент: як додавати перевірки, як читати звіт, за якого просідання відкочувати зміну.
Що передаємо на руки: тести, схеми, регламенти
Передаємо не папку з налаштуваннями, а працюючий контур оцінювання якості: інженер запускає прогон і читає звіт, не розбираючись у чужій логіці. До комплекту входить:
- Набори перевірок за сценаріями — діалог підтримки, сумаризація, вилучення полів; для кожного свій набір еталонних прикладів і метрика, за якою рахується якість.
- Схема контуру перевірок: де лежать еталони, як проходить прогон, як результати потрапляють у звіти й які дані для цього потрібні.
- Правила розмітки спірних випадків: що вважаємо правильним за неоднозначної відповіді, хто вирішує конфлікт розмітників і як рішення фіксується.
- Звіти та оповіщення про падіння метрик: пороги, канал повідомлення, порядок дій чергового та ознака хибної тривоги.
- Регламент оновлення моделей: обов’язковий прогон на закріпленому наборі перед зміною версії, критерії приймання та умови відкату.
- Матриця доступів і ролей: хто править еталони, хто — правила розмітки, хто бачить лише звіти.
Документація і правила розмітки
Описуємо контур так, щоб новий інженер зібрав прогон за інструкцією: призначення кожного набору, формат еталонів, розбір типових помилок розмітника.
Спірні випадки зводимо в таблицю «ситуація — рішення — обґрунтування»: вона знімає більшу частину питань, не вимагаючи звернення до нас.
Що вже налаштовано у вашому контурі
Контур зібрано на Braintrust і пов’язано з вашим репозиторієм: прогон запускається з гілки, результат порівнюється з попереднім релізом, падіння метрики нижче порога йде в канал команди.
Новий сценарій додається одним файлом еталонів і одним записом у конфігурації — без правок коду перевірок.
Кейс: скорочення помилок в асистенті підтримки
Асистент першої лінії відповідав на типові звернення за базою знань і передавав складні випадки оператору. Інструкції для моделі та сама модель оновлювалися кожні кілька тижнів, а якість перевіряли вручну: оператори читали вибірку діалогів і виносили вердикт.
На обсязі звернень це перестало працювати — вибірка покривала малу частину сценаріїв, а спірні відповіді різні перевіряльники оцінювали по-різному.
Що було до впровадження
Частка некоректних відповідей трималася близько 12%: асистент плутав умови повернення, посилався на застарілі розділи бази знань і впевнено відповідав там, де потрібна була передача оператору.
Ручна перевірка релізу займала 3-4 дні — еталонні діалоги проганяли очима, і оновлення чекало вердикту. За квартал дві регресії пішли в продакшн: їх помітили за скаргами, коли зросла частка ескалацій на операторів.
Що змінилося після
Ми зібрали контур перевірок на Braintrust: еталонний набір діалогів із розміткою, автоматичні оцінки за критеріями — повнота відповіді, опора на джерело, коректність ескалації, відсутність вигаданих умов.
Прогон запускається на кожній зміні інструкцій або моделі, а поріг якості блокує реліз, якщо оцінка за критерієм просіла; на ручний розбір ідуть лише випадки, де автоматика не впевнена.
Частка некоректних відповідей знизилася з 12% до 3%, перевірка релізу скоротилася з 3-4 днів до 40 хвилин, пропущених регресій за квартал — нуль.
У підтримці це дало менше ескалацій і розвантажило операторів на складних зверненнях: типові питання асистент закриває сам, а команда бачить, який саме критерій тягне якість униз після чергової зміни.
Чим відрізняється офлайн-розмітка від перевірок у проді
Офлайн-розмітка та перевірки в проді відповідають на різні питання. Набір на історичних даних показує, чи стала модель кращою на відомих випадках; живий трафік — чи не ламається вона на тому, чого в наборі не було.
Підготовлений набір на історичних діалогах
Тут збирають реальні звернення, фіксують еталонну відповідь або шкалу оцінювання та проганяють через кожну версію моделі.
Властивість набору — повторюваність: ті самі входи, та сама методика, тому результати порівнювані між збірками й видно, що дало приріст, а що відкотило якість.
Платформа на кшталт Braintrust тримає такі набори разом з оцінками й автоматично порівнює прогони, показуючи розбіжності за кожним прикладом.
Сліпа зона рівно одна: набір відображає минулий розподіл запитів. Нові формулювання, теми та крайові випадки до нього не потрапляють, поки їх не додадуть вручну.
Контроль на живому трафіку
Онлайн-контроль якості відповідей працює на тому, що приходить зараз: частка відмов і повторних питань, розбір діалогів, де користувач пішов, збір зворотного зв’язку користувачів прямо в інтерфейсі. Це єдиний спосіб побачити зсув тематики та рідкісні сценарії.
Але еталона тут немає — оцінка шумна, залежить від поведінки аудиторії, а частина зворотного зв’язку просто не надходить.
Різниця методів перевірки в тому, що офлайн відповідає за регресію, а онлайн — за виявлення. Робоча схема: набір на історичних діалогах стоїть воротами перед випуском, а аномалії з проду розбираються й перетворюються на нові приклади набору.
Часті технічні питання перед інтеграцією
Перед інтеграцією інженерні команди задають майже одні й ті самі питання — і всі вони про те, як перевірки уживаються з уже працюючим продуктом.
Нижче — відповіді на типові сумніви: від розбіжностей у розмітці до вибору між своїм контуром перевірок і зовнішньою платформою. Загальний принцип один: перевірки вбудовуються в поточний процес випуску, без зупинки сервісу, і починаються з офлайн-прогону на історичних запитах.
Розмітники розходяться в оцінках — перевіркам можна вірити?
Вважаємо узгодженість на пересіченій частині вибірки: спірні приклади йдуть в арбітраж до старшого розмітника, правило фіксується в інструкції. Метрика узгодженості йде у звіт поруч із якістю моделі — інакше шум розмітки приймають за деградацію.
Модель уже в проді — її доведеться зупиняти?
Ні. Спочатку тіньовий прогон на історичних запитах, без впливу на живі відповіді. Зміни в перевірках і правилах викочуємо за перемикачем, який знімається однією дією, — відкат займає хвилини.
Скільки історичних даних потрібно для старту?
Зазвичай кількох сотень розмічених прикладів на сценарій, зібраних із реального потоку запитів, — тоді пороги не випадкові. Якщо даних мало, стартуємо на синтетичних прикладах і активно добираємо спірні випадки.
Як підключати нові сценарії до перевірок?
Новий сценарій отримує свої еталонні відповіді та пороги, загальні перевірки (формат, повнота, безпека) перевикористовуються. Перед викатом обов’язковий прогон на старих наборах — регресії видно до релізу.
Свій контур перевірок чи зовнішня платформа?
Свій контур залишає чутливі запити всередині периметра, але потребує підтримки сховища та версіонування наборів. Зовнішня платформа швидша на старті: на Braintrust розмітка та прогони збираються швидко. Часто беруть гібрид — чутливе локально, решта зовні.
Обговоримо задачу: які дані потрібні для старту
Точність оцінювання залежить не від інструмента, а від того, наскільки перевірочний набір відображає ваші реальні сценарії. Щоб запропонувати працюючий контур перевірок на Braintrust, а не абстрактну схему, нам потрібно побачити, як система поводиться зараз і де саме помиляється.
- Опис сценаріїв: які задачі вирішує модель, хто користувач і що вважається правильною відповіддю.
- 30–50 прикладів вдалих відповідей — з них збирається еталон і база для повторних прогонів.
- Приклади невдалих відповідей, зокрема пограничні випадки: вигадані факти, відмова, зламаний формат.
- Поточні метрики та логи звернень: частка помилок, час відповіді, розмітка від користувачів, якщо вона ведеться.
- Обмеження за строками: коли потрібен перший результат і які релізи не можна зупиняти.
- Правила роботи з даними: де допустимо обробляти запити, що знеособлювати, чи потрібен ізольований контур.
- Хто з боку замовника затверджує критерії якості та розбирає спірні приклади.
На цих даних ми зберемо план впровадження контуру перевірок: набори тестів із фіксованими еталонами, автоматичні прогони за кожної зміни промпту або моделі, пороги, за яких реліз блокується, і звітність щодо динаміки якості від версії до версії.
Опишіть задачу й надішліть те, що вже є, — повернемося з оцінкою строків, складом робіт і планом впровадження.
