Plus de 100 termes IA expliqués clairement pour les décideurs. Chaque définition répond directement à la question que vous vous posez, sans jargon inutile.
La recherche sémantique comprend le sens des requêtes au lieu de simplement matcher des mots-clés.
La recherche sémantique est une approche de recherche d'information qui comprend le sens et l'intention derrière une requête, au lieu de simplement chercher des correspondances de mots-clés. Elle utilise des embeddings pour représenter textes et requêtes dans un espace vectoriel où les concepts similaires sont proches. Ainsi, une recherche sur "comment contacter le support" trouvera un document titré "Joindre notre service client". C'est la technologie clé du RAG pour trouver les passages pertinents dans une base de connaissances.
La recherche sémantique fonctionne en 3 étapes : 1) Indexation : chaque document est converti en vecteur (embedding) capturant son sens. 2) Requête : la question utilisateur est aussi convertie en vecteur. 3) Matching : on trouve les vecteurs documents les plus proches du vecteur requête (cosine similarity). Les résultats sont des documents sémantiquement proches, même sans mots en commun.
La recherche par mots-clés (BM25, Elasticsearch classique) cherche les documents contenant les mêmes mots que la requête. Elle rate les synonymes et reformulations. La recherche sémantique comprend le sens : "véhicule automobile" matche avec "voiture". Elle gère aussi les requêtes complexes et les questions. En pratique, les meilleurs systèmes combinent les deux (hybrid search).
L'implémentation passe par : 1) Choix d'un modèle d'embedding (OpenAI ada-002, Sentence-Transformers), 2) Indexation des documents dans une base vectorielle (Pinecone, Weaviate, Qdrant, pgvector), 3) À chaque question, générer l'embedding et requêter la base, 4) Utiliser les résultats comme contexte pour le LLM. Des frameworks comme LangChain simplifient cette intégration.
L'analyse de sentiment détecte automatiquement le ton émotionnel (positif, négatif, neutre) d'un texte.
L'analyse de sentiment est une technique NLP qui identifie l'opinion ou l'émotion exprimée dans un texte : positive, négative, ou neutre. Elle peut aussi détecter des émotions plus fines (joie, colère, frustration, satisfaction). Applications : analyser les avis clients, monitorer les réseaux sociaux, prioriser les tickets support urgents, et adapter le ton du chatbot selon l'humeur détectée. Les LLM modernes excellent dans cette tâche, même sur des textes nuancés ou sarcastiques.
Les chatbots utilisent l'analyse de sentiment pour : détecter la frustration et escalader proactivement vers un humain, adapter le ton de la réponse (plus empathique si sentiment négatif), prioriser les conversations urgentes, et alimenter les analytics (évolution du sentiment au fil de la conversation). Un client qui dit "c'est n'importe quoi" déclenche un traitement différent de "merci pour l'info".
Les modèles modernes atteignent 85-95% de précision sur les sentiments basiques (positif/négatif). La précision baisse sur les textes nuancés, sarcastiques, ou multi-sentiments ("Le produit est super mais la livraison était nulle"). Le français ajoute des défis (négation, expressions idiomatiques). Les LLM modernes gèrent mieux les nuances que les classifieurs traditionnels.
Oui, l'analyse d'émotions fine-grained détecte : joie, tristesse, colère, peur, surprise, dégoût. Des modèles entraînés sur des datasets émotionnels (GoEmotions) ou les LLM en zero-shot peuvent classifier ces émotions. C'est utile pour le support client (détecter la colère vs la déception) ou l'analyse de feedback (enthousiasme vs satisfaction passive).
Le Speech-to-Text convertit la parole humaine en texte écrit exploitable par les systèmes IA.
Le Speech-to-Text (STT), aussi appelé ASR (Automatic Speech Recognition), est la technologie qui convertit la parole humaine en texte écrit. Les systèmes STT modernes utilisent le deep learning pour atteindre des taux de précision dépassant 95% en conditions optimales. Le STT est la première brique des callbots et assistants vocaux : il transcrit ce que dit l'appelant pour que le NLP puisse analyser le contenu. Les leaders incluent Whisper (OpenAI), Google Speech-to-Text, et AWS Transcribe.
Dans un callbot, le STT est la première étape du pipeline : il convertit la voix de l'appelant en texte. Ce texte est ensuite analysé par le NLP pour détecter l'intention, le LLM génère une réponse textuelle, et le TTS la vocalise. La qualité du STT impacte directement la compréhension : une transcription erronée mène à une mauvaise réponse. Le STT peut aussi être utilisé pour la transcription d'appels à des fins d'analyse.
Les meilleurs systèmes STT atteignent 95-98% de précision en français standard, audio propre. Les défis : accents régionaux, vocabulaire technique/métier, bruit de fond, qualité audio téléphonique. Whisper (OpenAI) est particulièrement performant en français. Pour les termes métier spécifiques, nous pouvons fournir un vocabulaire personnalisé pour améliorer la reconnaissance.
Pour réduire les erreurs STT : améliorer la qualité audio (bonne connexion, pas de bruit), utiliser un modèle adapté au cas d'usage (téléphonie vs podcast), fournir un vocabulaire métier personnalisé, implémenter une confirmation des informations critiques ("Vous avez dit 15 mars, c'est bien cela ?"), et combiner avec le contexte conversationnel pour corriger les ambiguïtés.
Le streaming affiche la réponse d'un LLM progressivement, token par token, au lieu d'attendre la génération complète.
Le streaming est une technique d'affichage des réponses LLM où les tokens (mots) sont envoyés et affichés au fur et à mesure de leur génération, au lieu d'attendre la réponse complète. Cela améliore drastiquement l'expérience utilisateur : au lieu d'attendre 5 secondes devant un écran vide, l'utilisateur voit la réponse se construire après 200-500ms. Le streaming est devenu standard pour les chatbots car il réduit la latence perçue sans modifier la latence réelle.
Le streaming réduit la latence perçue de plusieurs secondes à quelques centaines de millisecondes. L'utilisateur voit immédiatement que le chatbot "réfléchit" et peut commencer à lire la réponse. Psychologiquement, c'est beaucoup moins frustrant qu'un écran vide. Le streaming permet aussi à l'utilisateur d'interrompre si la réponse part dans la mauvaise direction.
Le streaming est idéal pour les réponses textuelles affichées à l'utilisateur. Il est moins adapté quand : on doit valider la réponse complète avant affichage (filtrage de sécurité), nous avons besoin du résultat complet pour une action (appel API), ou le format de sortie est structuré (JSON). Dans ces cas, nous pouvons streamer vers un buffer interne, traiter, puis afficher.
L'implémentation du streaming utilise les Server-Sent Events (SSE) ou WebSockets côté frontend. Côté backend, les APIs LLM (OpenAI, Anthropic) supportent le streaming nativement. Le serveur reçoit les tokens au fil de l'eau et les pousse vers le client. Les frameworks comme LangChain, Vercel AI SDK, ou les SDK officiels simplifient cette implémentation.
L'apprentissage supervisé entraîne un modèle sur des exemples étiquetés pour prédire les labels de nouvelles données.
L'apprentissage supervisé est une méthode de machine learning où le modèle apprend à partir d'exemples étiquetés (données + réponse attendue). On lui montre des milliers de paires (entrée, sortie attendue) et il apprend à prédire la sortie pour de nouvelles entrées. Exemples : classification de spam (emails + label spam/non-spam), prédiction de prix (caractéristiques maison + prix), détection d'intention de chatbot (phrases + intentions). C'est la forme de ML la plus utilisée en entreprise.
Les chatbots classiques utilisent l'apprentissage supervisé pour : la détection d'intention (phrases étiquetées par intention), l'extraction d'entités (textes annotés avec les entités), et la classification de sentiment. Le modèle apprend des exemples fournis par les concepteurs ou extraits des conversations réelles. Les LLM modernes réduisent ce besoin mais l'approche reste pertinente pour des classifieurs rapides et économiques.
La quantité dépend de la complexité de la tâche et du modèle. Règles générales : pour un classifieur d'intentions, 50-200 exemples par classe. Pour du fine-tuning de BERT, quelques centaines à milliers. Les LLM en few-shot fonctionnent avec 5-20 exemples. Plus les classes sont proches ("annuler" vs "modifier"), plus il faut d'exemples pour les distinguer.
Les pièges courants : données déséquilibrées (90% d'une classe, 10% de l'autre), overfitting (le modèle mémorise au lieu d'apprendre), labels incohérents (des annotateurs qui désaccordent), et distribution différente en production (les vrais utilisateurs écrivent différemment des exemples d'entraînement). La qualité des données et une validation rigoureuse sont essentielles.
Le slot filling collecte les informations nécessaires (slots) pour compléter une action dans un dialogue.
Le slot filling est une technique de dialogue qui collecte les informations nécessaires pour accomplir une tâche. Chaque "slot" est une pièce d'information requise : pour réserver un vol, les slots sont la destination, la date aller, la date retour, le nombre de passagers. Le chatbot pose des questions jusqu'à remplir tous les slots obligatoires. C'est un pattern fondamental des chatbots orientés tâche, complémentaire à la détection d'intention (qui identifie le but) et à l'extraction d'entités (qui peuple les slots).
Le slot filling suit un cycle : 1) Détecter l'intention ("réserver"), 2) Identifier les slots requis pour cette intention (date, lieu, nombre), 3) Extraire les slots déjà fournis dans la phrase ("demain à Paris"), 4) Demander les slots manquants ("Pour combien de personnes ?"), 5) Confirmer et exécuter l'action quand tous les slots sont remplis. Le dialogue manager orchestre ce processus.
Les slots optionnels ont des valeurs par défaut ou sont simplement ignorés si non fournis. Pour les modifications ("en fait, plutôt le 20 mars"), le système doit détecter qu'un slot déjà rempli est mis à jour, remplacer la valeur, et reconfirmer. Les bons systèmes gèrent aussi les annulations partielles ("finalement je ne veux plus le retour").
Les LLM peuvent faire du slot filling implicitement via leur compréhension du dialogue, mais pour les applications critiques (réservations, transactions), une gestion explicite des slots reste préférable. Elle garantit qu'aucune information obligatoire n'est oubliée, facilite la validation, et rend le système plus prédictible. L'hybride LLM + slots explicites combine flexibilité et rigueur.
Un expert Webotit analyse vos flux, identifie les quick-wins et vous propose une feuille de route personnalisee.
Un expert Webotit analyse vos flux, identifie les quick-wins et vous propose une feuille de route personnalisée.
45 min · Gratuit · Réponse sous 24h
Voir les disponibilités