Deskhero
Українська
Спробувати безкоштовно

← Back to articles

Класифікація звернень за допомогою ШІ: практичний посібник

Класифікація звернень за допомогою ШІ: практичний посібник

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

Перш ніж виділяти бюджет на модель, перевірте основні передумови:

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

Основні висновки

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

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

Зміст

Що таке класифікація заявок за допомогою ШІ?

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

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

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

Як система обробки заявок із ШІ обробляє заявку?

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

Конвеєр, етап за етапом:

  1. Отримання даних. Система отримує текст заявки та відповідні метадані з helpdesk-системи.
  2. Попередня обробка. Вона видаляє нерелевантну розмітку або підписи та нормалізує вхідні дані. Деякі реалізації також видобувають текст із підтримуваних вкладень.
  3. Видобування ознак. Класична модель може використовувати TF-IDF-вектори, тоді як нейронна модель може використовувати ембеддинги або токени.
  4. Інференс моделі. Класифікатор прогнозує одну або кілька міток і, якщо доступно, показник упевненості.
  5. Постобробка та маршрутизація. Правила приймають, відхиляють або передають прогноз на перевірку, перш ніж оновити заявку.

Багатомовні заявки можна перекладати перед класифікацією або обробляти багатомовною моделлю. Протестуйте обидва підходи на власному мовному наборі, оскільки переклад може змінити важливі терміни. Проєкт із відкритим кодом aiticketclassifier демонструє конвеєр класифікації TF-IDF із прогнозами категорій, показниками впевненості, інформаційною панеллю, рекомендаціями та сповіщеннями Slack. Обробка в реальному часі підходить для робочих процесів, у яких мітка має впливати на активну чергу. Пакетна обробка корисна для масового заповнення даних і оцінювання.

Який підхід до моделі відповідає вашому обсягу заявок?

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

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

Порівняльна діаграма моделей класифікації заявок за допомогою ШІ

Методи класичного машинного навчання, такі як Logistic Regression, SVM і XGBoost, навчаються на маркованих прикладах. У порівняльному дослідженні 2025 року оцінювалися вісім алгоритмів на загальнодоступних та корпоративних наборах даних. Дослідження показало, що поєднання заголовка й опису заявки покращило результати в усіх протестованих сценаріях, а класичні моделі відповідали рівню або перевершували протестовані моделі глибокого навчання в кількох випадках.

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

Порада професіонала: Почніть із найменш складного підходу, який відповідає вашим критеріям прийнятності. У дослідженні 2025 року в протестованих сценаріях для класифікації пріоритетів зафіксовано точність і F1 понад 0,95, тоді як класифікація категорій на корпоративних даних виявилася складнішою.

Як інтегрувати класифікатор у робочий процес обробки заявок?

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

  1. Перевірте дані. Виберіть репрезентативний період і перевірте, наскільки послідовно маркувалися заявки.
  2. Розробіть таксономію. Почніть із категорій, які рецензенти можуть надійно розрізняти.
  3. Створіть початковий набір даних. Залучіть фахівців служби підтримки, які розуміють чергу, і фіксуйте розбіжності.
  4. Створіть базову модель. Порівняйте простий набір правил або класичну модель із поточним ручним процесом.
  5. Протестуйте повну інтеграцію. У тестовому середовищі перевірте поведінку прогнозів, помилок, повторних спроб і оновлень полів.
  6. Впроваджуйте поетапно. Почніть з однієї черги або невеликої групи міток із високою впевненістю.

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

Які метрики доводять готовність класифікатора?

Особливо корисними є чотири показники: точність (скільки передбачених міток були правильними), повнота (скільки фактичних випадків було знайдено), F1 (гармонійне середнє точності та повноти) і калібрування впевненості (наскільки передбачені ймовірності відповідають спостережуваним результатам).

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

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

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

Як зберегти точність класифікатора після запуску?

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

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

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

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

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

Руки тримають буклет із рекомендаціями та ноутбук

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

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

Порада професіонала: Мінімізуйте поля, які надсилаються класифікатору. Якщо моделі потрібні лише тема й повідомлення, не додавайте нерелевантні дані клієнта.

Як виглядає чотиритижневий пілотний проєкт із класифікації за допомогою ШІ?

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

  1. Тиждень 0, визначення меж. Виберіть одну чергу, визначте таксономію, оберіть базові метрики та задокументуйте неприйнятні помилки.
  2. Тиждень 1, маркування та базова модель. Промаркуйте репрезентативну вибірку, узгодьте розбіжності та навчіть або налаштуйте найпростішу життєздатну базову модель.
  3. Тиждень 2, інтеграція й тіньове тестування. Запускайте прогнози на активних заявках, не змінюючи їхніх полів.
  4. Тижні 3–4, обмежене розгортання та оцінювання. Увімкніть дії лише для перевірених випадків із високою впевненістю, а потім виміряйте якість моделі, навантаження черги перевірки, виправлення маршрутизації та результати роботи служби підтримки.

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

Чому Deskhero підходить командам, які пілотують класифікацію за допомогою ШІ

Deskhero перетворює поштову скриньку Gmail, Google Workspace або Microsoft 365 на helpdesk, не змінюючи адресу електронної пошти, яку бачать клієнти. Нові заявки також можуть надходити через вбудовані форми та чат-бот зі ШІ. Це забезпечує пілотному проєкту узгоджений запис заявки, поки Користувачі продовжують працювати зі спільною скринькою.

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

Нотатки щодо впровадження

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

Почніть пілотний проєкт, не очікуючи на міграцію

Deskhero може підключатися до наявної поштової скриньки Gmail, Google Workspace або Microsoft 365, зокрема до спільних поштових скриньок Microsoft. Спочатку можна протестувати вбудовані автоматизації нових заявок, які встановлюють поля маршрутизації на основі явних умов або умови, оціненої ШІ. Якщо вам потрібен окремо навчений класифікатор, використовуйте REST API для опитування заявок і оновлення прийнятих міток.

Deskhero

Зберігайте класифікацію, маршрутизацію та генерування відповідей як окремі засоби керування. Запропоновані Deskhero відповіді використовують знання робочого простору й залишаються доступними, щоб Користувач міг їх прийняти, відредагувати або відхилити. Автоматичні відповіді ШІ та чат-бот Deskhero використовують лише схвалені загальнодоступні записи FAQ, а для активації чат-бота потрібно щонайменше 100 схвалених записів FAQ. Deskhero пропонує 30-денний безкоштовний пробний період, для якого не потрібна кредитна картка.

Джерела

Наведені нижче ресурси містять порівняння досліджень, робочу еталонну реалізацію та визначення основних метрик оцінювання:

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

Що таке система обробки заявок із ШІ?

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

Що таке класифікаційні моделі у ШІ?

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

Що таке метод AI ticket?

Стандартизованого «методу AI ticket» не існує. Типовий конвеєр отримує текст заявки, готує вхідні дані, прогнозує мітку, перевіряє результат за правилами та критеріями впевненості, а потім оновлює заявку або додає її до черги.

Як ШІ точно класифікує заявки служби підтримки?

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

Чи може helpdesk на кшталт Deskhero обробляти класифікацію заявок без команди фахівців із аналізу даних?

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