AI-транскрибація дзвінків: від аудіо до CRM за секунди

Проектуємо та впроваджуємо системи штучного інтелекту: від прототипу до production-ready рішення. Наша команда поєднує експертизу в машинному навчанні, дата-інжинірингу та MLOps, щоб AI працював не в лабораторії, а в реальному бізнесі.
Показано 1 з 1Усі 1564 послуг
AI-транскрибація дзвінків: від аудіо до CRM за секунди
Середній
~5 днів
Часті запитання

Напрямки AI-розробки

Етапи розробки AI-рішення

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1360
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    957
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929

AI-транскрибація дзвінків: від аудіо до CRM за секунди

Оператор витрачає 3–5 хвилин на оформлення підсумків кожного дзвінка: записує домовленості, оновлює статус, додає нотатки. При 50 дзвінках на день — це майже повний робочий день на рутину. Помилки, друкарські помилки, втрачені деталі — стандартна ціна людського фактора. У кол-центрі на 100 операторів це призводить до втрати до 30% потенційного виторгу через невиконані обіцянки. Ми пропонуємо замінити цей етап AI-пайплайном, який транскрибує запис, виділяє суть і автоматично заповнює картку контакту в CRM. Точність резюме перевищує 95%, а час обробки скорочується до 15–30 секунд на дзвінок. Економія на операторах сягає 80%, а інвестиції окупаються за 3–6 місяців. За 5+ років роботи ми реалізували понад 20 проєктів у фінансовому, медичному та телеком-секторах, гарантуючи стабільну роботу системи з першого дня.

Як улаштований pipeline транскрибації?

Система складається з трьох ланок: транскрибація з діаризацією → LLM-сумаризація → запис у CRM. Нижче — спрощена реалізація на Python.

async def process_completed_call(call_event: dict):
    """Обробляємо завершений дзвінок від до до кінця"""
    call_id = call_event["call_id"]
    recording_url = call_event["recording_url"]
    crm_contact_id = call_event.get("crm_contact_id")

    # 1. Завантажуємо запис
    audio = await download_recording(recording_url)

    # 2. Транскрибуємо з діаризацією
    transcript = await transcribe_with_diarization(audio)

    # 3. Генеруємо резюме
    summary = await generate_call_summary(transcript)

    # 4. Оновлюємо CRM
    if crm_contact_id:
        await crm.update_contact(
            contact_id=crm_contact_id,
            data={
                "last_call_summary": summary["short"],
                "last_call_transcript": transcript["full_text"],
                "last_call_outcomes": summary["outcomes"],
                "next_action": summary["next_action"],
                "call_sentiment": summary["sentiment"]
            }
        )
        await crm.log_activity(
            contact_id=crm_contact_id,
            type="call",
            description=summary["short"],
            duration=transcript["duration"]
        )

    return {"call_id": call_id, "summary": summary}

Чому діаризація критична?

Без діаризації резюме втрачає контекст: хто що обіцяв, хто ставив запитання. Ми використовуємо pyannote-audio — модель, навчену на тисячах годин діалогів. Вона стійка до шумів і перебивань. Pyannote-audio забезпечує точність розділення мовців >98% у чистих записах.

Як генерується резюме дзвінка?

Промпт для GPT-4o структурує відповідь у JSON: коротке резюме, причина звернення, ключові моменти, результат, наступна дія, тональність. Використовуємо response_format=json_object для гарантії парсингу.

SUMMARY_PROMPT = """Створи структуроване резюме дзвінка:
1. Коротке резюме (2-3 речення)
2. Причина звернення
3. Що було обговорено (ключові моменти)
4. Результат/рішення
5. Наступна дія (якщо є): що, хто, коли
6. Тональність клієнта: позитивна/нейтральна/негативна

Формат: JSON"""

async def generate_call_summary(transcript: dict) -> dict:
    dialog = "\n".join(
        f"{t['speaker']}: {t['text']}"
        for t in transcript["turns"]
    )

    response = await client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": SUMMARY_PROMPT},
            {"role": "user", "content": dialog[:5000]}
        ],
        response_format={"type": "json_object"}
    )
    data = json.loads(response.choices[0].message.content)

    return {
        "short": data.get("brief_summary", ""),
        "reason": data.get("reason", ""),
        "outcomes": data.get("key_points", []),
        "next_action": data.get("next_action", ""),
        "sentiment": data.get("sentiment", "neutral")
    }

AI-пайплайн обробляє дзвінок у 10–20 разів швидше, ніж ручне введення, і знижує кількість помилок у рази. Порівняння ефективності показує, що час обробки скорочується з 3–5 хвилин до 15–30 секунд, а точність резюме підвищується з ~70% до >95% завдяки структурованому JSON-виводу та повній транскрипції з діаризацією.

Які моделі сумаризації ми використовуємо?

Модель Підтримка української Структурований вивід Латенси P99
GPT-4o відмінно JSON mode 1.2 с
Claude 3.5 добре JSON mode 1.8 с
LLaMA 3 70B добре потребує інструкції 0.9 с

Витрати на токени мінімальні — частки цента за дзвінок. Для self-hosted LLaMA 3 витрати на інфраструктуру нижчі при високих обсягах. Ми допоможемо обрати оптимальну модель під ваш бюджет і навантаження.

Типові помилки при впровадженні та їх рішення

Помилка Рішення
Низька точність діаризації при поганій якості запису Додати шумопоглинання та нормалізацію гучності до обробки
LLM «галюцинує» в резюме Використовувати few-shot приклади та обмежити контекст
CRM API не справляється з піковим навантаженням Ввести чергу повідомлень (RabbitMQ/Kafka) і батчинг
Конфіденційність даних Розгорнути все в ізольованому VPC зі знеособленням PII

Як ми налаштовуємо систему під вашу галузь?

Для спеціалізованої лексики (медицина, юриспруденція, продажі) ми донавчаємо моделі за допомогою LoRA-адаптерів. Це підвищує точність розпізнавання мовлення та релевантність резюме. Pipeline включає ML pipeline для версіонування моделей і A/B-тестування. Також ми використовуємо RAG (Retrieval-Augmented Generation) для пошуку по архіву дзвінків: векторне зберігання на pgvector дозволяє знаходити релевантні діалоги за семантичною схожістю.

Що входить у готове рішення?

  • Pipeline транскрибації (Whisper large-v3 + діаризація pyannote-audio) та сумаризації (GPT-4o)
  • Інтеграція з однією або кількома CRM (Bitrix24, amoCRM, Salesforce з коробки; для інших — кастомні конектори через REST API або Webhook)
  • Веб-інтерфейс для перегляду транскриптів та резюме (опціонально)
  • Навчання моделей під вашу галузеву лексику (fine-tuning LoRA)
  • Документація та підтримка на етапі експлуатації

Всі записи обробляються в ізольованому середовищі: ваш VPC або on-premise. Моделі запускаються в контейнерах з обмеженим мережевим доступом. Перед транскрибацією можна знеособити персональні дані за допомогою NER-моделі. Сертифікація ISO 27001 за запитом.

Приклад конфігурації контейнера з обмеженням мережі
version: '3.8'
services:
  transcription:
    image: true/transcription:latest
    network_mode: none
    volumes:
      - audio_data:/data
    environment:
      - MODEL=whisper-large-v3
      - DEVICE=cuda

Етапи впровадження

Етап Тривалість Результат
Аналітика 3–5 днів Розібрані типи дзвінків, цільова структура резюме, вимоги до CRM
Проектування 5–7 днів Обрано стек (Whisper/GPT-4o/pgvector), спроектовано pipeline
Реалізація 10–14 днів Написано код, налаштовано моделі, інтегровано API
Тестування 7–10 днів Прогнали 500+ дзвінків, точність >90%
Деплой 3–5 днів Розгорнуто у вашому контурі, підключено CRM

Терміни: базова версія — 2–3 тижні, мультиплатформенна — до 1.5 місяця. Зв'яжіться з нами для детального розрахунку. Отримайте консультацію: оцінимо ваш проєкт і запропонуємо рішення під ключ.

Чому варто впровадити AI-транскрибацію зараз?

Ринок уже перейшов на voice analytics: компанії, які не автоматизують обробку дзвінків, втрачають до 30% потенційного виторгу через невиконані обіцянки. Наш досвід — понад 20 впроваджених проєктів — гарантує, що система запрацює з першого дня. На одному проєкті з 5000 дзвінків на день вдалося скоротити витрати на ручну обробку на 80%, окупивши інвестиції за 3 місяці. Замовте пілотний проєкт для вашого кол-центру та переконайтеся в ефективності.

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

Ми стикаємося із замовником, який має 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-модель під ваші дані?

Модель WER (українська, чистий запис) WER (PSTN, кодек G.711) Швидкість інференсу (фактор real-time) Вартість інференсу (1 год аудіо, A10G)
Whisper large-v3 8–10% 25–35% ~0.1x (55 с на 40 хв) ~$0.50
Whisper medium 12–15% 30–40% ~0.3x ~$0.15
Wav2Vec2 XLSR-53 15–18% 28–35% ~0.8x ~$0.08
Whisper large-v3 + fine-tune 4–7% 10–15% ~0.1x ~$0.50

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) Натуральність MOS Клонування Мови
XTTS v2 1.2–2.0 с 4.1–4.3 Так, 3 с референсу 17
StyleTTS2 0.3–0.6 с 4.0–4.2 Так, вимагає адаптації en, + fine-tune
Kokoro-82M 0.08–0.15 с 3.7–3.9 Ні en, ja
Silero TTS 0.05–0.1 с 3.4–3.6 Ні ru, en, de, та ін.
Edge-TTS ~0.4 с (cloud) 4.0 Ні 100+

Для інтерактивних ботів з вимогою 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 тижні.