Налаштування A/B-тестування AI-промптів під ключ

Чому A/B-тестування промптів дає хибні висновки

Один і той самий промпт, надісланий двічі, повертає різні формулювання — генерація недетермінована.

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

Нестабільність відповідей — властивість самої моделі, а не дефект налаштування, і вона закладає шум у будь-яке порівняння з першого кроку.

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

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

Третя — сам критерій оцінювання. Якщо якість розмічає людина без однозначної інструкції або модель-суддя без калібрування на спірних прикладах, шум в оцінці перекриває ефект від правки інструкції.

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

Нарешті, умови порівняння рідко фіксують повністю. Варіанти проганяють на різних наборах вхідних даних, змінюють модель або її параметри посеред експерименту, історію діалогу додають лише в одну гілку.

Будь-яка така відмінність робить варіанти непорівнюваними, і далі сперечаються вже не про інструкцію, а про те, чий набір вхідних даних виявився простішим.

Підсумок передбачуваний: у роботу йде випадковий варіант, а реальне покращення відкочують як «те, що не спрацювало». Розбираємо, як поставити A/B-тестування промптів так, щоб хибні висновки не проходили повторну перевірку.

Що дає керований контур оцінювання якості відповідей

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

Результат прогону — не «стало краще», а частка пройдених перевірок за кожним варіантом і список розбіжностей.

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

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

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

Відтворюваність — головний ефект: через місяць можна повторити той самий прогін на тій самій вибірці й зрозуміти, що саме змінило результат — нова версія інструкції, оновлення моделі або склад запитів.

Це перетворює налаштування промптів із ручного підгону на інженерний процес, де в кожної зміни є перевірюваний слід.

Режими A/B-тестування промптів: прогін, спліт, тіньовий запуск

Вибір режиму залежить від двох речей: чи є архів реальних звернень для порівняння і чи можна показувати нову відповідь частині користувачів. Звідси офлайн-прогін за збереженими діалогами й онлайн-спліт, де дві версії промпту ділять трафік.

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

Режими не замінюють, а доповнюють один одного: тіньовий запуск відсіює явно слабкі версії, офлайн-прогін рахує метрики на історії, онлайн-спліт підтверджує їх на живих зверненнях, а розкатка доводить переможця до всієї аудиторії частками — від 5% до 100%.

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

Від аудиту до передачі: етапи інженерної роботи

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

Без цього порівняння варіантів перетворюється на суперечку про смаки, а вибраний промпт розвалюється на живому трафіку.

1. Аудит прогону. Розбираємо, як формуються промпти, звідки беруться вхідні дані, що вже логується і в якому вигляді зберігаються відповіді. На виході — карта процесу й список місць, де варіанти розходяться некеровано.
2. Критерії порівняння. До запуску фіксуємо основну метрику й правило зупинки: частка відповідей, що пройшли перевірку за розміткою, частка відмов і повторів, стійкість формулювання на перефразованих входах. Інші показники йдуть контрольними.
3. Схема перевірки. Визначаємо, як варіанти ділять вхідний потік: та сама вибірка для A і B, випадковий порядок, ізоляція — за прогін змінюється строго одна частина промпту. Тоді результат відносять до зміни, а не до різниці у вхідних даних.
4. Налаштування запуску. Логуємо версію промпту разом з відповіддю й параметрами виклику, щоб будь-який результат відтворювався й пояснювався, а не залишався одиничною удачею.
5. Відкладена вибірка. Тримаємо окремий набір прикладів, який не брав участі в підборі формулювань, і перевіряємо переможця тільки на ньому. Це відсікає варіанти, що виграли за рахунок підгонки під знайомі випадки.
6. Передача команді. Віддаємо регламент прогону, шаблон звіту, опис метрик і правило відкату на попередню версію — наступний варіант ви перевіряєте самі.

Артефакти: набори тестів, правила оцінювання, регламент прогонів

Результат A/B-тестування промптів тримається не на звіті, а на файлах, які ваша команда відкриває без нас. Звіт швидко застаріває: промпт правиться, модель оновлюється, склад тестів розходиться з реальними запитами.

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

Що залишається у вас на руках:

• Набір тестів — реальні звернення користувачів з розміткою: очікувана відповідь, допустимі формулювання, клас відмови. Зберігається поряд з промптом і поповнюється під час кожного розбору інциденту.
• Правила оцінювання — чим вважаємо варіант кращим: частка коректних відповідей, частка відмов, дотримання формату, розкид на однакових входах. Узгоджені до прогонів, щоб результат не підганявся під бажаний.
• Регламент прогонів — скільки запитів потрібно для значущого висновку, скільки повторів на варіант, за якої розбіжності різниця визнається шумом. Знімає суперечку «мені здається, цей промпт кращий».
• Журнал рішень — дата, версія промпту, метрики, хто і чому вибрав варіант. Через півроку видно, звідки взявся поточний текст, а не лише який він.
• Скрипти прогону й розбору — запускаються на вашій стороні, без доступу до нашої інфраструктури й без ручної звірки відповідей.
• Внутрішня документація — схема тестового контуру, порядок версіонування промптів, точки, де потрібно перезапускати тести після зміни моделі.

Кейс: скоротили частку невдалих відповідей і час перевірки

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

Частка невдалих відповідей трималася близько 18% — асистент упевнено називав неправильні строки доставки й пропонував умови повернення, яких не було.

Перевірка займала два дні на варіант: сорок діалогів проганяли вручну, оцінювала одна людина, спірні випадки повторно не розмічали. Порівнювати правку було ні з чим — з пам’яттю, а не з числами.

Що змінили

Зібрали регресійний набір із трьохсот реальних звернень з еталонними відповідями й рубрикою: коректність факту, повнота, тон, відсутність вигаданих умов.

Прогін іде офлайн за одним і тим самим набором, розмітка сліпа — два оцінювачі не бачать, який варіант перед ними, розбіжності розбирає третій. Версії промптів і результати прогонів трасуються в Langfuse, тому порівняння відтворюване й через місяць.

Що стало

Частка невдалих відповідей упала з 18% до 6%, ескалації на оператора — з 27% до 14%. Час перевірки варіанта скоротився з двох днів до 45 хвилин: прогін іде вночі, уранці готовий звіт з розбивкою за рубриками й списком діалогів, де варіанти розійшлися.

Підтримка асистента стала регламентом: щотижня в набір додають діалоги, де він помилився в бою, і проганяють за ними попередній варіант. Регрес видно до викатки, а не після скарг.

Чим відрізняється офлайн-оцінювання від онлайн-спліту у вашому контурі

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

Онлайн-спліт відповідає на інше питання: як промпт поводиться на реальних запитах. Частина трафіку йде на нову версію, метрики рахуються за групами.

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

На практиці це не альтернатива, а послідовність. Офлайн відсіює явні регреси й дешеві правки, онлайн підтверджує ефект на живих даних, після чого версію розкочують на весь трафік.

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

Далі додаємо онлайн-спліт і тримаємо обидві лінії на одному наборі метрик — видно, що зміна промпту покращила саме перевірювану поведінку, а не збіглася із сезонним сплеском.

Технічні сумніви: відтворюваність, розмітка, дрейф даних

Інженерні заперечення до A/B-тестування промптів стосуються не механіки, а довіри до висновків: чи відтворюється прогін, чи не тоне ефект у шумі оцінювання, що буде з метрикою через місяць. Нижче — відповіді на сумніви, які виринають до старту.

Як зрозуміти, що різниця між варіантами — не шум?

Один прогін на варіанті нічого не доводить: за ненульової температури модель відповідає по-різному. Рахуємо дисперсію за повторними прогонами на одному наборі, порівнюємо варіанти попарно на ідентичних прикладах і дивимося довірчий інтервал. Перекриваються — фіксуємо нічию, а не «переможця».

Що робити з дрейфом даних?

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

Частка незнайомих формулювань перевищила поріг — перезбираємо набір і проганяємо тест заново, інакше метрика описує минуле.

Як розмічати й не потонути в розбіжностях?

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

Що надіслати для старту і як ми повернемося з оцінкою

Щоб старт робіт не розтягнувся на листування, достатньо одного листа із вступними — решту уточнимо в розмові.

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

• Чинні промпти — усі варіанти, що зараз у роботі, включно з резервними формулюваннями для складних випадків і правилами склеювання, якщо промпт збирається з частин.
• Вивантаження реальних запитів і відповідей за період — на ньому будуємо перевірний набір: він має відображати частотні сценарії, а не лише показові приклади.
• Опис цільової поведінки — що вважаємо хорошою відповіддю, а що неприпустимим: повнота, тон, відмова від теми, обробка уточнень.
• Метрики й спосіб вимірювання — частка коректних відповідей, частка ручних правок, оцінки операторів, час відповіді; окремо — як ці числа збираються зараз.
• Точки виклику — який сервіс звертається до моделі і як результат повертається в продукт, щоб тест ішов на бойовому шляху, а не осторонь.
• Обмеження — вимоги до захисту даних, заборона на передавання персональних відомостей, допустиме навантаження й ліміти звернень.
• Доступи — тестовий контур, облікові дані, окреме сховище під розмітку, щоб прогони не змішувалися з робочим трафіком.

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