AI-заповнення картки клієнта після дзвінка: розробка системи

Клієнт телефонує, називає ім'я, просить перенести зустріч, уточнює адресу. Оператор гарячково відкриває картку, перемикається між полями, щось забуває, потім перепитує. Знайома ситуація? Ми її вирішили — AI автоматично заповнює картку клієнта після дзвінка, витягуючи всі структуровані дані з транскрипту. Наша система працює з будь-якими CRM через REST API та забезпечує точність витягнення до 95% при впевненості моделі. Вона розроблена на основі 10+ років досвіду в AI та NLP, і більш ніж 50 успішних проєктів з автоматизації CRM.

Кожне ручне введення — це 2-3 хвилини часу оператора та ризик помилки: забутий email, переплутана адреса, втрачена домовленість. AI справляється за 2-3 секунди, а оператору залишається лише підтвердити дані. У результаті час обробки дзвінка скорочується на 80%, а помилки введення практично зникають. Система не затирає старі дані під час злиття — розумний merge зберігає існуючу інформацію, якщо впевненість у новому значенні низька.

Як AI витягує дані з дзвінка?

Система використовує NER (Named Entity Recognition) на базі GPT-4o. Після дзвінка транскрипт подається в модель, яка повертає JSON з полями картки та оцінкою впевненості для кожного поля. Приклад витягнення:

async def extract_entities_from_call(transcript: str) -> dict:
    """Витягуємо структуровані дані з діалогу"""
    response = await client.chat.completions.create(
        model="gpt-4o",
        messages=[{
            "role": "system",
            "content": """Витягни з тексту дзвінка наступні дані (якщо згадувалися):
            - customer_name: повне ім'я клієнта
            - address: адреса доставки/проживання
            - email: email адреса
            - phone_secondary: додатковий телефон
            - order_details: деталі замовлення/запиту
            - complaint_description: опис проблеми
            - preferred_contact_time: зручний час для зв'язку
            - product_interest: цікаві продукти/послуги
            - next_appointment: дата/час наступного контакту
            - notes: важливі нотатки

            Поверни JSON. Поля, що не згадувалися в розмові — null."""
        }, {
            "role": "user",
            "content": transcript
        }],
        response_format={"type": "json_object"}
    )
    return json.loads(response.choices[0].message.content)

Ми використовуємо Named Entity Recognition (NER) для витягнення сутностей, а confidence scoring оцінює надійність кожного поля. Детальніше про NER читайте в Wikipedia. Порогові значення налаштовуються під специфіку бізнесу.

Як налаштувати пороги впевненості?

Кожне витягнуте значення отримує оцінку впевненості на основі ймовірності, присвоєної моделлю. Для полів з впевненістю нижче 60% в UI відображається жовтий індикатор — оператор зобов'язаний перевірити значення. Поля з впевненістю вище 85% заповнюються автоматично, але завжди доступні для редагування. Промпти налаштовані так, щоб модель повертала null для відсутніх даних, виключаючи хибні заповнення. Ця система confidence scoring дозволяє уникнути помилок при неповних або неоднозначних відповідях клієнта.

Чому AI в 10 разів швидший за ручне введення?

Оператор в середньому витрачає 2–3 хвилини на заповнення картки після дзвінка. AI робить це за 2–3 секунди, а оператору залишається лише підтвердити дані — це займає 10–15 секунд. Час обробки дзвінка скорочується на 80%, а кількість помилок введення падає практично до нуля. Гарантуємо, що система не затирає старі дані під час злиття завдяки smart merge.

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

1. Аналіз та проєктування: розбір поточних полів CRM, створення промптів для LLM, визначення порогів впевненості.
2. Розробка NER-модуля: інтеграція з OpenAI GPT-4o або локальними LLM (LLaMA, Mistral), реалізація confidence scoring та smart merge.
3. Інтеграція з CRM: налаштування REST API, створення UI-віджета для оператора з кольоровою індикацією (зелений/жовтий/сірий).
4. Тестування та калібрування: перевірка на реальних дзвінках, налаштування threshold confidence, A/B тестування.
5. Документація та навчання: інструкції для операторів, опис API, керівництво з експлуатації.
6. Підтримка: супровід протягом 3 місяців після запуску, доопрацювання промптів при зміні бізнес-процесів.

Як ми гарантуємо якість?

Кожне витягнуте поле містить цитату з транскрипту — оператор бачить, звідки взялося значення. Confidence нижче 60% відправляє поле на обов'язкову перевірку. Ми також проводимо fine-tuning на ваших діалогах, щоб підвищити точність на специфічній лексиці. Замовте пілотний проєкт на 50 дзвінках — оцініть точність самі.

Терміни орієнтовно

• NER + заповнення однієї CRM: 2–3 тижні.
• Мультиплатформенна система з UI та підтримкою кількох CRM: 1,5 місяця.
• Fine-tuning під специфіку бізнесу: +1–2 тижні.

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

Розпізнавання та синтез мовлення: перша лінія проблеми

Ми стикаємося із замовником, який має 40 000 годин записів кол-центру й хоче транскрибувати їх за тиждень — це типова задача розпізнавання мови ASR. Штатний хмарний ASR (Google Speech-to-Text) видає WER 28% на галузевій лексиці, а ціна при таких обсягах стає непідйомною. Завдання — знизити WER нижче 10% і перейти на self-hosted інференс. Така ситуація повторюється в кожному другому проєкті, і ми маємо напрацьований патерн рішення.

Типові технічні проблеми та їх усунення

WER не сходиться до потрібної метрики. Найчастіше винна не архітектура, а дані: шумні аудіо без нормалізації рівня (–23 LUFS замість стандарту), змішані мови в одному каналі, акцент, специфічна доменна лексика. Whisper large-v3 з коробки дає WER 8–12% на чистій українській і провалюється до 25–35% на записах з PSTN-артефактами та вузькосмуговим кодеком G.711.

Діаризація ламається при більш ніж двох спікерах. pyannote/speaker-diarization-3.1 працює стабільно при 2–3 мовцях, але DER (Diarization Error Rate) зростає з 6% до 18–22% при 5+ учасниках конференції. Проблема посилюється перехресними репліками: за замовчуванням min_duration_on=0.1 обрізає короткі вставки. Рішення — збільшити min_duration_on до 0.3 та додати overlap detection через pyannote-overlap-detection.

Клонування голосу — латентність чи якість. XTTS v2 (Coqui) дає натуральний голос, але при потоковій генерації stream_chunk_size=20 перший аудіочанк прилітає через 1.4–2.0 с — неприйнятно для інтерактивних сценаріїв. StyleTTS2 та Kokoro швидші, але вимагають точного підготовки референсного аудіо. Ми навчилися вирішувати цю дилему за допомогою гібридного підходу: на старті використовуємо Silero TTS (50–100 мс TTFB), а після отримання перших 3 секунд аудіо перемикаємо на XTTS для кращої натуральності.

Як вибрати ASR-модель під ваші дані?

faster-whisper (CTranslate2) швидший за оригінальний Whisper у 4 рази при однаковому WER. Для продакшену ми завжди використовуємо його.

Практичний приклад: fine-tuning Whisper на доменній лексиці

Фінтех-компанія з 12 000 дзвінків/день. Початковий WER на українській з банківською лексикою — 22% (Google STT). Після fine-tuning whisper-medium на 200 годинах розмічених записів через Hugging Face transformers + Seq2SeqTrainer з learning_rate=1e-5, warmup_steps=500 — WER впав до 7.3%. Інференс на одній A10G через faster-whisper з compute_type=float16 обробляє 40-хвилинний дзвінок за 55 секунд. Підсумкова вартість інференсу — $0.50 за годину аудіо, що в 6 разів дешевше за хмарне рішення. Проєкт виконано за 6 тижнів, включаючи підготовку даних і валідацію.

Техніка fine-tuning описана в офіційній документації Whisper на Hugging Face.

Як донавчити Whisper на доменних даних?

Коли загальна модель не справляється, fine-tuning — перший інструмент. Мінімальний датасет для помітного покращення — 20–30 годин розміченого аудіо в цільовому домені. Розмітку можна отримати через ітеративний процес: прогнати через базову модель → вручну виправити 10–15% помилок → перенавчити → повторити.

training_args = Seq2SeqTrainingArguments(
    per_device_train_batch_size=16,
    gradient_accumulation_steps=2,
    learning_rate=1e-5,
    warmup_steps=500,
    max_steps=5000,
    fp16=True,
    predict_with_generate=True,
    generation_max_length=225,
)

При fine-tuning обов’язково заморожуйте encoder перші 1000 кроків (model.freeze_encoder()), інакше акустичні ознаки роз’їдуться раніше, ніж decoder адаптується до нової лексики.

Синтез мовлення: що обрати для вашого сценарію?

Для інтерактивних ботів з вимогою TTFB < 300 мс — Silero або Kokoro. Для озвучення контенту, де важлива натуральність — XTTS v2 з потоковою віддачею через WebSocket. Ми гарантуємо, що підібрана модель відповідатиме вашим вимогам до латентності та якості — це підтверджено на 50+ реалізованих проєктах.

Наш досвід та гарантії

10+ років досвіду в NLP та speech processing. 50+ успішних проєктів для fintech, telecom, медицини. Сертифіковані моделі (Model Card + bias audit). Ми гарантуємо зниження WER до цільового рівня, інакше повертаємо кошти.

Що входить у роботу з нами?

Клієнт отримує:

• Документацію: model card, інструкцію з розгортання, API-специфікацію (OpenAPI 3.0)
• Код: готові скрипти для інференсу, пайплайни обробки (Docker Compose + Kubernetes маніфести за потреби)
• Доступи: до self-hosted інстансів, графіки моніторингу (Grafana + Prometheus)
• Навчання: 2 сесії для вашої команди (налаштування, експлуатація, troubleshooting)

Ми також надаємо сертифікат відповідності моделі (Model Card + bias report), що підсилює довіру до рішення.

Процес роботи та терміни

1. Аудит-сесія – беремо 2–4 години ваших записів, проганяємо через кілька моделей, вимірюємо WER/CER, дивимося на розподіл помилок (лексичні, акустичні, мова). Займає 1–2 дні.
2. Вибір архітектури – під ваш throughput: один GPU для 1000 хв/день або кластер з балансувальником для 100 000+ хв/день.
3. Реалізація – Docker-контейнер з FastAPI або Triton Inference Server для батчованого інференсу. Інтеграція з чергою Kafka.
4. Тестування – A/B тест на продакшн-даних, порівняння з baseline (Google/Azure STT).
5. Деплой – CI/CD (GitHub Actions + ArgoCD), моніторинг (Grafana + WER/CER алерти).

Терміни:

• Базова інтеграція готової моделі – 1–2 тижні.
• Fine-tuning з підготовкою даних та валідацією – 4–8 тижнів.
• Повна розробка голосового пайплайну (ASR + діаризація + TTS + моніторинг) – 2–4 місяці.

Зв'яжіться з нами для безкоштовної консультації — оцінимо ваш проєкт за 2 дні. Або замовте пілотний fine-tuning на 20 годинах ваших даних і отримайте перші результати вже за 2 тижні.