DiDi перевела контроль контакт-центру на Bedrock

Перевірка наміру без ефекту «знайти кращий варіант»

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

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

• Для звичайної мітки спершу перевіряйте її прийнятність, а не шукайте найкращу серед усіх.
• Мітку «Інше» ведіть окремим маршрутом: пошук серед сусідніх категорій, потім у повному дереві, а за відсутності збігу — пропозиція нової мітки.
• Зберігайте рішення, рівень упевненості та логіку вибору для аудиторського сліду.

Одна схема оцінювання для різних мов і напрямів

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

Каркас запиту: Мова: {language}. Напрям: {business_line}. Критерії: {criteria}. Правила: {rules}. Для кожного критерію поверни оцінку та обґрунтування у визначеній JSON-схемі. Новий критерій, мову або напрям додають зміною конфігурації, а не створенням нового шаблону.

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

Пошук тенденцій у масиві звернень

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

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

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

Межі довіри та людська перевірка

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

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