Системна перевірка якості відповідей ШІ спирається на фіксований еталонний набір: від 15 до 30 типових і крайових запитів одного процесу, для кожного з яких заздалегідь записано правильну відповідь або обовʼязкові критерії. Кожну відповідь моделі оцінюють за кількома критеріями на шкалі від 0 до 2 і складають бали в загальну суму. Той самий набір проганяють повторно після кожної зміни інструкції для моделі, самої моделі, бази знань чи підключених інструментів і порівнюють суму з попереднім прогоном. Якщо бали впали, зміну відкочують або допрацьовують, доки результат не повернеться до попереднього рівня.
Коротко
- Еталонний набір вимірює стабільність усієї системи, тоді як перегляд окремої відповіді показує лише один випадок.
- Для одного процесу робочим вважають набір із 15-30 знеособлених реальних звернень із позначкою типовий або крайовий.
- Кожну відповідь оцінюють за кількома критеріями на шкалі від 0 до 2, де 0 означає невідповідність, 1 часткову відповідність, а 2 повну.
- Повторний прогін потрібен після кожної зміни інструкції, моделі, бази знань чи інструментів, і падіння суми балів є сигналом до відкату або виправлення.
- Набір веде один власник процесу, який поповнює його після інцидентів і зберігає версії набору разом із версіями інструкції.
Чому разової перевірки однієї відповіді ШІ перед клієнтом недостатньо для контролю якості?
Коли працівник переглядає відповідь чат-бота перед відправкою, він бачить один результат на одне звернення. Цей результат може бути бездоганним сьогодні й нічого не говорити про те, як поведеться модель завтра на трохи іншому запиті. Мовна модель щоразу формує відповідь заново, і навіть незначна правка в інструкції для моделі здатна змінити тон, обсяг або набір фактів у відповідях на всі типові питання одночасно.
Другий ризик стосується сліпих зон. Типові питання трапляються щодня, працівники бачать їх часто і добре знають, як має виглядати якісна відповідь. Крайові випадки, наприклад розгніваний клієнт або замовлення, якого немає в базі, трапляються рідко, і на таких зверненнях модель частіше вигадує факти або обіцяє те, чого компанія не може виконати. Якщо такий запит не надходив цього тижня, ніхто не дізнається, що після останньої зміни модель із ним більше не справляється.
Третя відмінність полягає в самому питанні, на яке відповідає перевірка. Перегляд сьогоднішнього листа відповідає, чи можна відправити цей конкретний лист. Системний набір відповідає, чи не погіршилась система загалом після зміни. Погіршення якості на тих завданнях, з якими модель раніше справлялась, називають регресією якості, і виявити її можна лише порівнянням однакових запитів до зміни і після неї.
Що входить в один елемент еталонного набору і скільки таких елементів потрібно для одного процесу?
Один елемент набору складається з трьох частин. Перша частина містить сам запит клієнта в тому вигляді, в якому він надходить, з помилками, скороченнями й емоціями. Друга містить еталонну відповідь або перелік критеріїв правильності, тобто фактів, які обовʼязково мають прозвучати, і речей, яких у відповіді бути не може. Третя частина є позначкою, чи це типовий випадок, чи крайовий. Крайовим випадком називають рідкісне звернення, яке виходить за межі звичного сценарію: клієнт погрожує скаргою, у базі немає потрібних даних або запит стосується теми, на яку модель не має права відповідати.
Типова ситуація відділу підтримки інтернет-магазину виглядає так. Більшість звернень стосується статусу замовлення, умов повернення та робочих годин, а невелика частка припадає на крайові випадки. Власник процесу переглядає знеособлені звернення за кілька тижнів, відбирає з них від 15 до 30 і прибирає імена, телефони, адреси та номери замовлень. Для питання про повернення він записує обовʼязкові факти, які має містити відповідь, а для звернення розгніваного клієнта фіксує, що модель має визнати проблему, утриматися від обіцянок компенсації і передати розмову людині.
Діапазон 15-30 для одного процесу склався як робоча практика і не є вимогою закону чи галузевого стандарту. Меншого набору замало, щоб охопити і типові, і крайові випадки, а більший важко оцінювати вручну після кожної зміни. Брати запити варто з реального потоку звернень. Вигадані ідеальні діалоги зручно оцінювати, але в них немає тих помилок, обірваних речень і змішаних тем, на яких модель помиляється найчастіше.
Які критерії оцінки відповідей ШІ обрати і як працює шкала від нуля до двох?
Для більшості процесів обслуговування клієнтів вистачає чотирьох критеріїв. Фактична точність показує, чи збігаються названі дати, умови й статуси з еталоном і базою даних та чи немає у відповіді вигаданих фактів. Дотримання заборон перевіряє, чи не розкрила модель персональні дані і чи не пообіцяла знижку, строк або компенсацію, яких компанія не надає. Тон і формат оцінюють, чи відповідає лист прийнятій у компанії манері. Четвертий критерій стосується застережень і передачі людині: якщо звернення потребує рішення працівника, модель має повідомити про це клієнта і позначити розмову для ескалації.
Шкала за кожним критерієм має три значення. Оцінку 0 ставлять, коли відповідь не відповідає критерію: наприклад, модель назвала строк повернення, якого немає в правилах компанії. Оцінка 1 означає часткову відповідність: факти правильні, але одного обовʼязкового бракує, або тон загалом прийнятний, але надто сухий для розгніваного клієнта. Оцінка 2 означає повну відповідність еталону. Три рівні зручні тим, що детальніша шкала змушує сперечатися про відтінки, а оцінка лише з двома варіантами стирає різницю між частковою і повною відповідністю.
Окремі критерії має сенс позначити як критичні. Якщо модель отримала 0 за дотримання заборон хоча б в одному запиті, зміну не приймають навіть за високої загальної суми, бо витік даних чи хибна обіцянка коштують компанії дорожче, ніж кілька вдалих листів. Щоб оцінки лишались порівнянними, для кожного критерію письмово описують, що означає 1, і ставлять бали за цим описом.
Коли повторювати прогін еталонного набору і що робити, якщо бали впали?
Прогін означає, що кожен запит набору по черзі подають моделі з поточною інструкцією, зберігають відповіді та виставляють бали. Повторювати його потрібно після будь-якої зміни, яка впливає на відповіді: правки інструкції для моделі, переходу на іншу модель або її нову версію, оновлення бази знань, підключення чи відключення інструментів, наприклад доступу до системи замовлень. Результат кожного прогону зберігають на окремому аркуші разом із датою, версією інструкції та загальною сумою балів.
У типовій ситуації з відділом підтримки власник процесу вирішує зробити тон відповідей теплішим і змінює відповідний абзац інструкції. Він проганяє ті самі запити і порівнює результат із попереднім аркушем. Загальна сума може навіть зрости завдяки тону, але порівняння по рядках покаже, чи не почала модель у теплішій манері обіцяти клієнтам те, чого компанія не надає. Тому порівнюють і загальну суму, і зміни за окремими критеріями, з окремою увагою до крайових випадків.
Якщо бали впали, є два шляхи. Перший шлях полягає у відкаті зміни, тобто поверненні до попередньої версії інструкції, після якого прогін має показати колишній результат. Другий шлях полягає в точковому виправленні, коли зрозуміло, який саме фрагмент інструкції спричинив погіршення, і його можна переписати без втрати досягнутого. Після виправлення набір проганяють знову. Окреме правило стосується темпу змін: великі зміни вносять по одній. Якщо одночасно замінити модель, переписати інструкцію й оновити базу знань, то при падінні балів неможливо встановити причину, і доведеться відкочувати все разом.
Хто в компанії веде еталонний набір і як його оновлювати?
Набір потребує одного відповідального. Ним стає власник процесу: людина, яка відповідає за результат роботи відділу підтримки і має право погоджувати зміни в інструкції. Коли набір доручають усьому відділу, кожен додає запити на свій смак, критерії тлумачать по-різному, і за кілька місяців результати прогонів уже неможливо порівняти між собою.
Набір оновлюють за подіями. Після кожного інциденту, коли модель відповіла клієнту неправильно або пропустила потрібну передачу людині, цей запит у знеособленому вигляді додають до набору, щоб помилка не повторилась непомітно. Застарілі запити, наприклад про умови доставки, які компанія вже скасувала, прибирають або переписують під чинні правила. Для кожного типу крайових випадків корисно тримати кілька запитів, щоб один вдалий збіг не створював хибного відчуття надійності.
Кожна зміна набору створює його нову версію. Версію набору зберігають поруч із версією інструкції для моделі, з якою його проганяли, і датою прогону. Без цього звʼязку легко сплутати падіння якості системи зі зміною самого набору: якщо до нього додали кілька складних крайових випадків, сума балів може знизитися і без жодної зміни в роботі моделі. Тому порівнюють лише прогони на однаковій версії набору, а після кожного оновлення одразу проганяють на ньому чинну інструкцію і фіксують нову точку відліку.
Чим еталонний набір відрізняється від щоденної перевірки чернеток перед відправкою клієнту?
Два шари контролю розвʼязують різні завдання. Системний набір вимірює інструкцію, модель і підключені інструменти разом: він показує, чи справляються вони з відомим колом запитів і чи не погіршилось щось після зміни. Щоденна перевірка чернетки захищає конкретне звернення: працівник читає відповідь перед відправкою, виправляє неточність і бере на себе рішення про відправку.
Жоден із цих шарів не замінює інший. Набір із 15-30 запитів не охопить усіх формулювань, з якими приходять клієнти, тому окремий лист завжди може містити помилку, якої набір не передбачив. Щоденна перевірка, своєю чергою, не помітить поступового погіршення, бо працівник бачить кожну відповідь окремо і не порівнює її з тим, як модель відповідала на такий самий запит місяць тому. Між шарами є звʼязок: помилки з щоденних чернеток стають кандидатами до набору, а результати прогонів підказують, на які типи звернень дивитися уважніше.
Цей матеріал є загальною навчальною інформацією. Умови конкретних сервісів, обробку персональних даних у зверненнях клієнтів і вимоги закону варто звіряти в договорі з постачальником та на офіційних сторінках відповідних установ.
Що робити далі
- Призначте власника процесу, для якого першим збиратимете еталонний набір, наприклад відповідей клієнтам у підтримці.
- Відберіть із реальних звернень за кілька останніх тижнів від 15 до 30 запитів, знеособте їх і позначте кожен як типовий або крайовий.
- Запишіть для кожного запиту еталонну відповідь або обовʼязкові факти й заборони, а також опишіть, що означають оцінки 0, 1 і 2 за кожним критерієм.
- Проженіть поточну інструкцію для моделі через увесь набір, виставте бали й збережіть аркуш результатів із датою та версією інструкції.
- Домовтеся в команді, що жодна зміна інструкції, моделі, бази знань чи інструментів не потрапляє в роботу без повторного прогону і порівняння з попереднім аркушем.