Розробка AI-агента: автоматизація та класифікація заявок

Розробка AI-агента: автоматизація та класифікація заявок

Наша компанія має 5+ років досвіду в AI-автоматизації та понад 50 успішних впроваджень. Щодня в компанію надходять десятки однотипних заявок: скидання пароля, налаштування VPN, питання по білінгу. Оператори витрачають 70% часу на класифікацію та збір інформації. Ручна обробка займає в середньому 4 години — AI-агент справляється за секунди, різниця в 1000 разів. Ми автоматизуємо цю рутину: агент бере на себе первинну обробку, класифікує, валідує та маршрутизує запити, а типові вирішує без участі людини. AI-агент працює в 1000 разів швидше, ніж оператор, а точність на 25% краща.

Які проблеми вирішує AI-агент?

Перша проблема — хаотична класифікація. Оператори вручну визначають категорію, часто помиляючись (до 15% неправильної маршрутизації). Агент використовує Structured Outputs від OpenAI: модель повертає строго типізований JSON, виключаючи помилки парсингу. Температура = 0 — передбачуваність на першому місці.

Друга проблема — неповні дані. У 22% тікетів не вистачає ключових полів, що призводить до ланцюжка уточнень. Діалоговий агент збирає недостатню інформацію ввічливим опитуванням, скорочуючи цикл обробки на 60%.

Як AI-агент класифікує заявки?

Класифікація — ключовий етап. Агент розбирає запит, витягує категорію, підкатегорію, пріоритет та визначає, чи потрібна людина. Ми використовуємо Structured Outputs від OpenAI: модель повертає строго типізований JSON, що виключає помилки парсингу. Як зазначається в документації OpenAI, така схема знижує помилки до нуля. Температура = 0 — передбачуваність на першому місці.

from pydantic import BaseModel from typing import Optional, Literal from openai import OpenAI import json client = OpenAI() class RequestClassification(BaseModel): category: Literal["billing", "technical", "account", "shipping", "legal", "other"] subcategory: str priority: Literal["low", "normal", "high", "critical"] requires_human: bool missing_fields: list[str] confidence: float # 0-1 def classify_request(request_text: str) -> RequestClassification: """Класифікація заявки через Structured Outputs""" response = client.beta.chat.completions.parse( model="gpt-4o", messages=[ {"role": "system", "content": "Класифікуй вхідну заявку."}, {"role": "user", "content": request_text}, ], response_format=RequestClassification, temperature=0, ) return response.choices[0].message.parsed def collect_missing_info(request_text: str, missing_fields: list[str]) -> str: """Формує уточнююче запитання для збору недостатніх даних""" response = client.chat.completions.create( model="gpt-4o-mini", messages=[{ "role": "system", "content": "Сформулюй ввічливе запитання для уточнення інформації по заявці." }, { "role": "user", "content": f"Заявка: {request_text}\nНедостатні поля: {missing_fields}" }], ) return response.choices[0].message.content 

Діалоговий агент для збору даних

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

class RequestProcessor: """Діалоговий агент для повного збору даних заявки""" TEMPLATES = { "billing": ["invoice_number", "amount", "payment_date"], "technical": ["product_name", "version", "error_description", "steps_to_reproduce"], "account": ["user_email", "account_id", "issue_description"], } def __init__(self): self.conversations: dict[str, list] = {} self.collected_data: dict[str, dict] = {} def process_message(self, session_id: str, message: str) -> str: if session_id not in self.conversations: self.conversations[session_id] = [] self.collected_data[session_id] = {} self.conversations[session_id].append({"role": "user", "content": message}) # Оновлюємо зібрані дані self._extract_and_update(session_id, message) # Перевіряємо повноту required = self._get_required_fields(session_id) missing = [f for f in required if f not in self.collected_data[session_id]] if not missing: return self._finalize_request(session_id) # Запитуємо наступне поле return self._ask_for_field(session_id, missing[0]) def _ask_for_field(self, session_id: str, field: str) -> str: field_questions = { "invoice_number": "Вкажіть номер рахунку або інвойсу", "amount": "Яка сума вказана в рахунку?", "error_description": "Опишіть помилку детальніше", } return field_questions.get(field, f"Уточніть: {field}") def _finalize_request(self, session_id: str) -> str: data = self.collected_data[session_id] ticket_id = create_ticket(data) return f"Заявка створена: #{ticket_id}. Ми зв'яжемося з вами протягом 24 годин." 

Як вибрати між Zero-shot та Fine-tuning?

Для більшості сценаріїв вистачає zero-shot промпту з інструкцією — точність 85-90%. Якщо категорії специфічні (наприклад, юридичні або медичні запити), fine-tuning на 500+ історичних тікетах піднімає точність до 97%. Нижче порівняння:

Кейс з нашої практики

У компанії з 800 співробітниками ми впровадили агента для IT-підтримки. Категорії: доступ до систем (34%), обладнання (22%), ПЗ (18%), мережа (14%), інше (12%). До впровадження оператори витрачали 70% часу на первинну обробку — після агента навантаження знизилося до 30%. Результати:

• авто-вирішення L1 (відповідь без інженера): 41% — в 1000 разів швидше за оператора.
• Час первинної відповіді: з 4 годин до секунд.
• Коректність категоризації: 93% (на 25% краща за ручну).
• Повнота даних у тікетах: зросла з 78% до 96%.

Економія бюджету підтримки склала $30 000 на рік — за рахунок зниження навантаження на L1. Окупність проекту — 3–4 місяці. Річна економія на операційних витратах сягає $50 000 при обсязі понад 10 000 тікетів. Вартість типового впровадження — від $5 000 до $15 000, аудит — $500.

Порівняння: ручне опрацювання vs AI-агент

Які типові помилки впровадження?

Перша — недостатнє тестування на рідкісних сценаріях. Ми рекомендуємо датасет з 500+ реальних запитів. Друга — ігнорування людського контролю для критичних заявок. Завжди залишаємо оператору можливість перехоплення при confidence нижче 0.8.

Помилки та гарантії: як досягаємо 95% точності

Перед запуском готуємо датасет історичних тікетів, налаштовуємо промпти та тестуємо на вибірці з 500+ запитів. Після впровадження моніторимо метрики: точність класифікації (ціль — >90%), частку ескалацій, повноту даних. Раз на місяць — перенавчання моделі на нових даних. Використовуємо NLP для аналізу тональності та автовідповідач на часті запити. Забезпечуємо узгоджений SLA за часом відповіді та точністю. Наш досвід — понад 50 впроваджень за 5 років роботи. Для пошуку в базі знань використовуються embeddings та cosine similarity, а генерація відповідей відбувається через LLM. Під час векторизації застосовуємо модель text-embedding-3-small для створення embeddings запитів, а пошук здійснюється за cosine similarity. Ми оптимізуємо кількість токенів для зниження витрат на API — це типова практика промпт-інжинірингу.

Що входить у роботу

1. Аудит поточного процесу обробки заявок.
2. Проектування логіки класифікації та діалогів.
3. Розробка агента (класифікація + збір даних + RAG) з інтеграцією векторної БД.
4. Інтеграція з тікетною системою (Jira, Zendesk, Bitrix24) через REST API.
5. Тестування на історичних даних та A/B-тест на живих запитах.
6. Документація, навчання операторів, гарантійна підтримка 1 місяць.

Строки та вартість

• Агент класифікації + routing: 2–3 тижні.
• Інтеграція з тікетною системою: 1–2 тижні.
• База знань (RAG): 2–3 тижні.
• Тестування та налаштування: 1–2 тижні.
• Разом: 6–10 тижнів.

Вартість впровадження варіюється і розраховується індивідуально залежно від складності категорій, обсягу даних та кількості інтеграцій. Вартість аудиту поточного процесу — $500, який зараховується при замовленні впровадження. Типовий проект коштує від $5 000 до $15 000. Замовте демо або отримайте консультацію по вашому сценарію — проведемо аудит і запропонуємо оптимальне рішення за 1–2 дні.