Asystent AI do rozmów telefonicznych: od prototypu do produkcji

Rozwój głosowego asystenta AI w czasie rzeczywistym: doświadczenie zespołu backendów

Asystent głosowy "Sufle" został stworzony w celu wspierania menedżerów ds. sprzedaży podczas rozmów telefonicznych. System klasyfikuje usługi, wykrywa zastrzeżenia, wykorzystuje RAG do wyszukiwania danych i generuje tekstowe podpowiedzi. Dane wejściowe to fragmenty transkrypcji z API Voximplant. Minimalna opóźnienie wynosi 1,5–2 sekundy. Stosowany stos technologiczny: Python, FastAPI, PostgreSQL, dostosowane modele BERT oraz lokalna wersja Qwen 8B. Wdrożenie on-premise wynikało z wymagań bezpieczeństwa informacji.

Zespół składający się z 12 programistów backendowych bez doświadczenia w ML nauczył się podstaw w ciągu 6 miesięcy i uruchomił prototyp w pilotowym projekcie.

Pierwszy prototyp w trzy tygodnie

W pierwszych trzech tygodniach stworzono proof-of-concept:

• Przetwarzanie transkrypcji rozmów jako danych wejściowych.
• Dwa klasyfikatory BERT: jeden dla ponad 15 usług, drugi dla ponad 15 typów zastrzeżeń, trenowane na 1500 przykładach.
• Bazy wektorowe FAISS z opisami usług i skryptami.
• Integracja poprzez prompty z GPT.
• Interfejs na Django do wyświetlania podpowiedzi.

Prototyp miał opóźnienie 10–15 sekund, ale przekonał biznes do realnej przydatności pomysłu.

Ewolucja architektury: rezygnacja z nadmiernego skomplikowania

Początkowy monolit zawierał własny przetwarzacz dźwięku na Whisper, kilka klasyfikatorów, fine-tuning LLM, bazę wektorową z pętlą zwrotną. Szacunkowy czas realizacji: 12–18 miesięcy, wysokie ryzyko.

Rezygnacja z fine-tuningu. Zamiast dostosowywać Qwen/Llama do skryptów, wybrano RAG: model pobiera odpowiednie dane z bazy na żądanie. To zmniejsza halucynacje i oszczędza czas na etapie etykietowania danych.

Integracja gotowego transkrybera. Voximplant dostarcza fragmenty tekstowe przez REST. Uniknięto dwóch miesięcy pracy nad własnym przetwarzaczem dźwięku.

Uproszczenie klasyfikatorów. Wieloklasowy detektor zastrzeżeń zastąpiono binarnym (tak/nie). LLM analizuje szczegóły zastrzeżeń podczas generowania odpowiedzi. Uruchomienie na serwerze GPU znacznie przyspieszyło inferencję.

Wyszukiwanie w JSON zamiast bazy wektorowej. Bazy wiedzy (usługi, skrypty) są strukturalnymi plikami JSON w pamięci. Jest szybsze niż FAISS/Weaviate i nie wymaga wywołań sieciowych.

Lokalna LLM zamiast chmury. GPT/DeepSeek dawały opóźnienia 7–20 sekund i były zabronione z powodu wymogów bezpieczeństwa. Qwen 8B na serwerze GPU: ok. 2 sekundy, precyzyjne odpowiedzi.

Szybki interfejs. Strona Django z wyświetlaniem podpowiedzi zamiast integracji z migrującą CRM.

Ostateczny przepływ przetwarzania

System działa następująco:

• Pobranie tekstu z Voximplant.
• Binarna klasyfikacja BERT (usługa + zastrzeżenie).
• Wyszukiwanie RAG w bazie JSON.
• Generowanie promtu dla Qwen 8B.
• Wyświetlenie podpowiedzi w interfejsie.

Całkowite opóźnienie mieści się w 2 sekundach.

Etykietowanie danych: przejście do pragmatyzmu

Etykietowanie 200 rozmów przez zespół programistów zajęło wiele dni z powodu konieczności analizy kontekstowej. Menedżerowie byliby szybsi, ale ich liczba była niewystarczająca.

Rozwiązanie: skupienie się na binarnym wykrywaniu. LLM przetwarza szczegółowe informacje o zastrzeżeniach. Liczba iteracji danych została znacznie ograniczona.

Opóźnienie jako surowy limit

Czas rzeczywisty rozmowy wymaga opóźnienia poniżej 2 sekund. Chmury są niestabilne. Lokalna Qwen 8B (w porównaniu do wersji 32B) oferuje kompromis między szybkością a szczegółowością.

Bezpieczeństwo i granice systemu

Pełny cykl działa on-premise:

• Transkrypcja przez Voximplant (jedyny element zewnętrzny).
• Przetwarzanie i klasyfikacja na serwerach.
• Generowanie odpowiedzi lokalną modelem.

Rezygnacja z maskowania PII: +200–500 ms, ryzyko błędów, miesiąc pracy.

Co jest ważne

• RAG zamiast fine-tuningu przyspiesza wdrożenie i minimalizuje potrzebę etykietowania.
• Binarna klasyfikacja + LLM upraszcza wykrywanie zastrzeżeń bez utraty jakości.
• Lokalna Qwen 8B balansuje szybkość i dokładność w czasie rzeczywistym.
• Wyszukiwanie w JSON jest bardziej efektywne niż bazy wektorowe dla małych zbiorów wiedzy.
• Wdrożenie on-premise rozwiązuje jednocześnie problemy bezpieczeństwa i opóźnień.

— Editorial Team