Як ми тестуємо якість відповідей ШІ у Greetio

О 22:47 родина пише до готелю: «Ми приїдемо після опівночі з шестирічною дитиною. Чи можна підготувати додаткове ліжко? Картка не спрацювала — притримайте, будь ласка, номер до ранку».

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

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

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

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

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

Гарна відповідь — ще не обов’язково правильна

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

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

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

Еталонний набір: готель у мініатюрі

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

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

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

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

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

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

Перед запуском: помилка ще не дійшла до гостя

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

Через мінливість відповідей одного проходу недостатньо. Та сама система може по-різному сформулювати відповідь на однаковий запит, а в складному ланцюжку рішень один невдалий крок змінює весь результат. Дослідники Anthropic у своєму практичному огляді оцінювання ШІ-помічників рекомендують повторювати спроби, відокремлювати перевірки нових можливостей від перевірок незмінності вже надійної поведінки та поєднувати кілька типів оцінювачів.

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

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

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

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

Перевіряти потрібно не тільки текст, а весь шлях

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

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

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

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

Опора на джерела: відповідь має знати, звідки взявся факт

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

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

Особливо небезпечні суперечливі джерела. Якщо на сторінці сайту вказано один час, а в робочій інструкції інший, ШІ не повинен сам вирішувати, який варіант «звучить логічніше». Правильною поведінкою може бути відмова від категоричної відповіді, позначення суперечності та передавання її відповідальному працівникові. Якість — це також уміння вчасно визнати межу знань.

Українську та англійську потрібно перевіряти окремо

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

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

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

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

Після запуску: реальні гості знаходять те, чого не було в сценаріях

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

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

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

Профіль ризиків генеративного ШІ NIST застерігає від висновків на основі вузьких, несистемних і випадкових перевірок. Документ рекомендує перевіряти джерела, відстежувати впевнено сформульовані помилки, фіксувати версії, збирати повідомлення про збої та підтримувати спостереження після запуску. Міжнародний стандарт ISO/IEC 42001 так само розглядає керування ШІ як постійний цикл оцінювання, відповідальності й удосконалення, а не одноразове випробування перед продажем.

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

Кожна помилка повинна отримати точну назву

Фраза «ШІ відповів погано» майже не допомагає команді. Потрібно відрізняти помилку джерела від помилки пошуку, неправильне розуміння дати від вигаданого твердження, порушення правила від технічної невдачі дії.

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

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

Що чесна система перевірки не може обіцяти

Навіть велика кількість перевірок не доводить, що ШІ ніколи не помилиться. Еталонний набір охоплює лише відомі сценарії. Автоматичний оцінювач теж може помилково схвалити або відхилити відповідь. Фахівці не завжди погоджуються між собою. Реальна поведінка гостей змінюється, а оновлення моделі, правил, підключення чи бази знань може створити новий збій.

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

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

Повернімося до повідомлення о 22:47

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

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

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

З чого почати готелю

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

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

Поширені запитання

Чи достатньо вручну прочитати кілька добрих відповідей?

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

Чи може інша модель повністю замінити людське оцінювання?

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

Навіщо перевіряти фактичний стан, якщо відповідь правильна?

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

Чому українські сценарії не можна просто перекласти з англійської?

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

Який показник якості найважливіший?

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