Чи можна довірити AI маршрутизацію звернень? Приклад Perplexity Decider

Графіка: Perplexity. Оформлення офіційної документації, а не знімок екрана протестованої системи маршрутизації звернень.

У зверненні до підтримки клієнт пише, що з нього двічі списали гроші, посилка не прибула, а допомога потрібна до події. Надіслати звернення до категорії «доставка» здається логічним. Але так можна втратити з уваги проблему з оплатою та терміновість. AI-маршрутизація корисна, коли робить цю неоднозначність явною, а не просто замінює людину назвою категорії.

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

Модель допомагає обґрунтувати вибір маршруту

16 жовтня Vercel анонсувала Perplexity Decider V1.2 і Decider Flash V1.2 в AI Gateway. За описом Vercel, моделі відповідають на задані питання типів Boolean, Choice і Score, опрацьовуючи, зокрема, текст, записи й зображення. Це можливості за описом постачальника, а не доказ точності чи безпеки конкретного процесу підтримки.

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

Маршрутизація (Routing) — правило вибору наступного пункту призначення. Запропонована моделлю категорія — лише один із його вхідних чинників. Статус клієнта, уже відкрита справа або обов’язкова політика ескалації можуть обґрунтовано мати перевагу.

Імовірність — не дозвіл

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

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

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

Передбачте корисний шлях для «не впевнений»

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

Етап участі людини в робочому процесі (Human in the loop) має сенс лише тоді, коли людина може зрозуміти та змінити рішення. Визначте відповідального за чергу ескалації, спосіб доведення до нього термінових завдань і порядок дій, коли нікого немає на місці. Інакше «передати на перевірку» може стати ввічливою назвою втрати звернення.

Відокремлюйте сортування від бізнес-дій

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

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

Вимірюйте користь, а не лише класифікацію

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

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