Assistant IA pour les appels : du prototype à la production

Construire un assistant vocal IA en temps réel : le parcours de l'équipe backend

L'assistant vocal IA 'Suffler' accompagne les managers commerciaux pendant les appels en direct. Le système classe les services, détecte les objections, utilise le RAG pour récupérer des données pertinentes et génère des suggestions textuelles en temps réel. Les entrées proviennent de segments de texte fournis par le service de transcription Voximplant. Une fenêtre de latence obligatoire de 1,5 à 2 secondes est imposée. Stack technique : Python, FastAPI, PostgreSQL, modèles BERT ajustés, et Qwen 8B local. Un déploiement sur site était requis pour respecter les exigences de sécurité.

Une équipe de 12 développeurs backend, sans expérience préalable en apprentissage automatique, a maîtrisé les bases en six mois et a lancé avec succès une version pilote.

Preuve de concept en trois semaines

En moins de trois semaines, l’équipe a livré un prototype fonctionnel :

• Traitement des transcriptions d’appels comme données d’entrée.
• Deux classificateurs BERT : l’un pour plus de 15 services, l’autre pour plus de 15 types d’objections, entraînés sur 1 500 exemples annotés.
• Base de données vectorielle FAISS contenant les descriptions de services et les scripts.
• Intégration via des prompts utilisant GPT.
• Interface basée sur Django pour afficher les suggestions en temps réel.

Le prototype présentait un délai de 10 à 15 secondes, mais a convaincu les parties prenantes de la faisabilité de l’idée.

Évolution architecturale : réduire la complexité

La conception initiale monolithique incluait une pipeline audio personnalisée basée sur Whisper, plusieurs classificateurs, un ajustement fin des LLM, une base vectorielle avec boucles de retour, et un délai estimé de 12 à 18 mois, avec un risque élevé.

Abandon de l’ajustement fin. Au lieu de re-entraîner Qwen ou Llama sur des scripts commerciaux, l’équipe a adopté le RAG : le modèle extrait directement le contexte pertinent depuis une base de connaissances à la demande. Cela réduit les hallucinations et élimine les efforts d’annotation intensifs.

Utilisation d’un transcribeur prêt à l’emploi. Voximplant fournit les segments de texte via REST, évitant deux mois de développement d’une pipeline audio interne.

Simplification des classificateurs. Un détecteur d’objections multi-catégories a été remplacé par un classificateur binaire (objection présente/absente). L’LLM prend en charge l’analyse détaillée lors de la génération. L’exécution sur serveur GPU a considérablement amélioré la vitesse.

Recherche JSON au lieu de bases vectorielles. Les bases de connaissances (services, scripts) sont stockées sous forme de JSON structuré en mémoire. Plus rapide que FAISS ou Weaviate, sans latence réseau.

LLM local plutôt que cloud. Les API cloud comme GPT ou DeepSeek introduisaient des délais de 7 à 20 secondes et étaient bloquées par les politiques de sécurité. Exécuter Qwen 8B localement sur un serveur GPU a permis des réponses en ~2 secondes avec des sorties concises.

Interface légère. Une page Django simple affichant les suggestions a remplacé une intégration complexe avec un CRM.

Pipeline de traitement en temps réel final

Le système fonctionne ainsi :

• Réception du texte depuis Voximplant.
• Classification BERT binaire (service + objection).
• Recherche RAG dans une base JSON en mémoire.
• Génération d’un prompt pour Qwen 8B.
• Affichage de la suggestion dans l’interface.

La latence totale reste inférieure à 2 secondes.

Annotation des données : opter pour le pragmatisme

L’annotation de 200 dialogues a pris des semaines en raison de la nécessité de compréhension contextuelle. Les managers commerciaux annotaient plus vite, mais n’étaient pas disponibles à grande échelle.

Solution : se concentrer sur la détection binaire. L’LLM gère les détails des objections lors de la génération. Les cycles d’itération ont été drastiquement raccourcis.

Latence comme contrainte absolue

Les conversations en direct exigent des réponses en moins de 2 secondes. Les APIs cloud se sont révélées peu fiables. Qwen 8B local (contre 32B) sacrifie un peu de détail pour gagner en rapidité — un compromis nécessaire.

Sécurité et isolation

Workflow entièrement sur site :

• Transcription par Voximplant (seul composant externe).
• Traitement et classification internes.
• Réponses générées par LLM local.

Pas de masquage de PII : évite un surcoût de 200 à 500 ms, réduit le risque de distortion des données et économise un mois de travail de développement.

Points clés à retenir

• Le RAG bat l’ajustement fin en accélérant le lancement et en minimisant les efforts d’annotation.
• La classification binaire + LLM simplifie la détection des objections sans perte de qualité.
• Qwen 8B local établit le bon équilibre entre vitesse et précision pour une utilisation en temps réel.
• La recherche JSON surpasse les bases vectorielles pour les petites bases de connaissances structurées.
• Le déploiement sur site résout simultanément les problèmes de sécurité et de latence.

— Editorial Team