Маршрутизація звернень

Рішення перед дією

Уявімо сервіс підтримки, де технічні збої йдуть до engineering, доставка — до logistics, а невідомі запити — до other. Shvydko повертає категорію; ваш застосунок вирішує, чи достатньо даних для автоматичного маршруту.

Використайте питання team з quickstart. Додайте приклади, у яких згадуються і оплата, і доставка, щоб перевірити правило основної причини звернення.

Визначте безпечний результат функції

reviewed_threshold — ваш перевірений поріг, а не універсальна константа. Спершу збирайте запропоновані маршрути й порівнюйте їх із рішеннями операторів. Автоматичне виконання ввімкніть лише після оцінювання.

def decide_route(result, reviewed_threshold):
    answer = result["answers"]["team"]
    choice = answer.get("choice")
    confidence = answer.get("confidence")
    allowed = {"engineering", "logistics"}

    if (
        choice not in allowed
        or not isinstance(confidence, (int, float))
        or confidence < reviewed_threshold
    ):
        return {"route": "manual_review", "request_id": result["request_id"]}

    return {"route": choice, "request_id": result["request_id"]}

# Pass a threshold selected on your own labelled calibration data.
# This function chooses a route; it does not create a ticket or send a message.

Коли додавати друге питання

Незалежну оцінку терміновості можна додати як Score у той самий запит. Перевірку наявності потрібного факту — як Noul. Якщо друге рішення залежить від обраної категорії, сформуйте окремий запит після першої відповіді.

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

Що перевіряти після запуску

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