5 usages sous-estimés des embeddings

Les embeddings ne servent pas seulement à retrouver le bon chunk dans un RAG. Ils servent surtout à donner une géographie à vos données.

Quand on parle d’embeddings, la conversation tourne presque toujours autour du même schéma : on encode des documents, on cherche par similarité, puis on injecte les passages trouvés dans le prompt. Très bien. C’est devenu la grammaire de base du RAG.

Mais réduire les embeddings à ce rôle-là, c’est passer à côté de leur vraie puissance. Un embedding ne dit pas seulement “ce texte ressemble à un autre”. Il place un contenu dans un espace où la distance, la densité, les clusters et les trajectoires deviennent des signaux exploitables.

Autrement dit : les embeddings ne servent pas seulement à chercher. Ils servent à cartographier.

Voici cinq usages concrets, testables en un après-midi, qui exploitent cette idée.

1. Détecter la dérive thématique d’un contenu

Le problème

Vous avez un agent qui rédige un article, un rapport ou une réponse longue. Au fil des itérations, le texte reste fluide, bien écrit, parfois même plus élégant que la version initiale… mais il s’éloigne doucement du sujet demandé.

Ce type de dérive est difficile à capter avec des règles simples. Le texte peut rester “correct” lexicalement tout en quittant l’intention du brief.

L’idée

On embedde le brief initial, puis chaque version générée. Ensuite, on mesure la similarité cosinus entre le brief et chaque sortie.

Si le score baisse sous un seuil défini, on considère que le contenu sort du cadre.

brief    <- "Article technique sur l'optimisation des requêtes PostgreSQL"
version1 <- "Les index B-tree permettent d'accélérer les requêtes SELECT..."
version2 <- "PostgreSQL est un SGBD open-source créé à Berkeley..."
version3 <- "Les bases NoSQL comme MongoDB offrent une alternative..."

emb_brief <- embed(brief)

pour chaque version dans [version1, version2, version3]:
  score <- similarité_cosinus(emb_brief, embed(version))

# Exemple de resultat
# version1 -> 0.87  : reste dans le sujet
# version2 -> 0.72  : dérive légère
# version3 -> 0.54  : dérive nette

Pourquoi c’est utile

Vous ajoutez ainsi un garde-fou sémantique dans une boucle de génération. Ce n’est pas une évaluation de qualité, mais une évaluation d’alignement.

En pratique, c’est utile pour :

• surveiller un agent de rédaction
• vérifier qu’un résumé ne part pas sur le contexte au lieu du fond
• détecter qu’une chaîne multi-étapes perd le fil de l’instruction initiale

2. Cartographier des compétences sans rester prisonnier des mots-clés

Le problème

Le matching CV / fiche de poste par mots-clés fonctionne mal dès que les formulations changent. Un candidat peut avoir les bonnes compétences sans jamais employer les termes exacts attendus.

L’idée

On embedde les blocs de compétences, projets ou expériences, puis on projette les vecteurs dans un espace 2D avec UMAP ou t-SNE.

Les proximités et les clusters révèlent alors des familles de profils, même quand le vocabulaire diffère.

pour chaque cv dans candidats:
  embeddings_cv[] <- embed(cv.compétences)

emb_poste <- embed(fiche_de_poste)

tous_les_vecteurs <- embeddings_cv + [emb_poste]
projection_2D <- UMAP(tous_les_vecteurs, dimensions=2)

afficher scatter plot:
  - points bleus : candidats
  - étoile rouge : fiche de poste

Ce que cela change

Vous passez d’une logique de mot à mot à une logique de proximité de profils.

Par exemple, un profil qui parle de “pipelines de données”, “feature engineering” et “évaluation de modèles” peut remonter très près d’un poste “machine learning”, même sans utiliser cette étiquette exacte.

Ce n’est pas une décision automatique de recrutement. C’est un outil pour voir la structure d’un vivier de talents plus intelligemment.

3. Clusteriser les tickets de support sans taxonomie prédéfinie

Le problème

Les catégories manuelles comme “bug”, “question” ou “feature request” sont trop larges. Elles aident à trier, mais elles n’expliquent pas vraiment ce qui se passe.

Quand 500 tickets arrivent chaque semaine, ce qu’on veut, ce n’est pas une étiquette vague. Ce sont les thèmes répétitifs, les irritants produit et les signaux faibles.

L’idée

On embedde les tickets, puis on applique un clustering non supervisé, par exemple HDBSCAN. Ensuite, on prend quelques exemples représentatifs de chaque cluster et on demande à un LLM de proposer un nom court.

pour chaque ticket dans tickets_support:
  embeddings[] <- embed(ticket.contenu)

clusters <- HDBSCAN(embeddings, taille_min=10)

pour chaque cluster:
  échantillons <- prendre_5_tickets_representatifs(cluster)
  thème <- LLM("Propose un nom court pour ce groupe", échantillons)

Résultat attendu

Au lieu de trois classes génériques, vous voyez apparaître des thèmes opérationnels du type :

• “problème de synchronisation mobile après mise à jour”
• “erreur de paiement sur Safari iOS”
• “confusion UX sur le bouton d’annulation”

La différence est importante : ces thèmes sont directement actionnables par une équipe produit ou support.

4. Repérer les doublons sémantiques dans une base de connaissance

Le problème

Dans une base de connaissance qui grossit depuis des mois ou des années, les doublons ne sont presque jamais strictement identiques. Ils disent la même chose avec des formulations différentes, parfois avec des détails contradictoires.

Une recherche plein texte retrouve les doublons évidents. Elle rate souvent ceux qui se recouvrent fortement sans partager exactement les mêmes mots.

L’idée

On embedde chaque article, puis on construit une matrice de similarité pour extraire les paires qui dépassent un seuil.

articles <- charger_base_de_connaissances()

pour chaque article:
  embeddings[article.titre] <- embed(article.contenu)

doublons <- []
pour chaque paire (article_A, article_B):
  sim <- similarité_cosinus(embeddings[A], embeddings[B])
  si sim > 0.85:
    doublons.ajouter(article_A, article_B, sim)

Pourquoi c’est efficace

Vous obtenez une liste priorisée de contenus à fusionner ou à nettoyer :

• deux guides qui expliquent le même onboarding
• deux procédures VPN rédigées pour des audiences différentes
• deux articles de runbook qui décrivent le même incident sous des titres différents

Ensuite, un LLM peut aider à produire une version fusionnée, mais l’étape clé, c’est d’abord d’identifier les recouvrements.

5. Faire émerger des familles d’incidents dans les logs

Le problème

Les outils classiques de logs sont bons pour retrouver ce qu’on connaît déjà : une regex, un code d’erreur, un pattern attendu.

Mais les incidents nouveaux, rares ou diffus passent facilement sous le radar. Ils n’ont pas encore de signature stable.

L’idée

On embedde les messages d’erreur, puis on les clusterise pour faire apparaître des groupes sémantiquement proches, même si leur formulation exacte varie.

logs <- charger_logs_erreur("app.log", niveau="ERROR", dernières_24h)

pour chaque log:
  embeddings[] <- embed(log.message)

clusters <- HDBSCAN(embeddings, taille_min=5)

pour chaque cluster:
  échantillons <- prendre_5_logs_representatifs(cluster)
  cause <- LLM("Résume la cause racine probable", échantillons)

Ce que cela apporte

On ne cherche plus seulement à compter des erreurs connues. On cherche à faire apparaître des familles d’incidents.

Typiquement :

• “saturation du pool Redis sous charge”
• “accès à un profil null après suppression de compte”
• “timeouts intermittents vers le service de paiement”

Le gain est double : on détecte plus vite les nouveaux problèmes, et on gagne du temps dans la qualification des incidents.

Le fil rouge : un embedding est une géographie

Si vous ne devez retenir qu’une idée, c’est celle-ci : un embedding transforme un contenu en coordonnées dans un espace de sens.

Dès lors, les opérations géométriques deviennent des opérations analytiques :

• une distance mesure une proximité sémantique
• un cluster révèle un thème récurrent
• une projection montre la structure cachée d’un corpus
• une trajectoire expose une dérive ou une évolution
• un voisinage dense signale une famille de cas similaires

La recherche sémantique n’est qu’un usage parmi d’autres. Un usage important, mais seulement un parmi d’autres.

Le vrai changement de perspective, c’est de cesser de voir les embeddings comme une simple API de retrieval. Il faut les voir comme une couche d’observation de vos données.

Quand vous faites ce pas, vous arrêtez seulement de chercher le bon texte. Vous commencez à comprendre la forme de votre corpus.