Embeddings et recherche vectorielle

Comment "chercher par sens" plutôt que par mots-clés

Une recherche par mots-clés classique échoue si l'utilisateur pose une question avec des mots différents de ceux du document ("réinitialiser mon accès" vs "changer le mot de passe"). Le RAG utilise généralement une recherche sémantique, capable de trouver des passages pertinents même sans correspondance exacte de mots.

L'embedding : transformer du texte en nombres

Un embedding est une représentation numérique (un vecteur de plusieurs centaines de dimensions) d'un texte, générée par un modèle spécialisé, telle que des textes de sens proche produisent des vecteurs numériquement proches.

"Comment réinitialiser mon mot de passe ?"  →  [0.12, -0.45, 0.78, ...]
"Procédure de changement d'accès utilisateur" →  [0.14, -0.42, 0.81, ...]
                                                    (vecteurs numériquement proches)

"Quelle est la météo aujourd'hui ?"  →  [0.91, 0.03, -0.67, ...]
                                          (vecteur très différent)

La base de données vectorielle

Une base de données vectorielle (Pinecone, Weaviate, Chroma, ou des extensions vectorielles de bases classiques comme PostgreSQL avec pgvector) stocke ces vecteurs et permet de trouver rapidement les plus proches d'une requête donnée, parmi potentiellement des millions de documents.

flowchart TD
    A[Documents source] --> B[Découpage en\npassages chunks]
    B --> C[Modèle d'embedding\ngénère un vecteur par chunk]
    C --> D[(Base vectorielle)]
    E[Question utilisateur] --> F[Modèle d'embedding\ngénère un vecteur]
    F --> G[Recherche des vecteurs\nles plus proches]
    D --> G
    G --> H[Passages pertinents\nretournés]

Le découpage en chunks : un choix qui compte

Les documents sont découpés en fragments (chunks) avant d'être transformés en embeddings, car un document entier trop long perd en précision de recherche. La taille de ce découpage est un paramètre de conception important : trop petit, on perd le contexte ; trop grand, on dilue la pertinence.

Cas concret

Un système RAG interne indexe la documentation technique d'une entreprise. Un utilisateur pose la question "comment débloquer mon compte verrouillé ?", alors que la documentation utilise le terme "réinitialisation de session utilisateur". Grâce à la recherche par embeddings (recherche par sens, pas par mots-clés exacts), le système retrouve tout de même le bon passage, malgré l'absence de correspondance textuelle directe entre la question et le document source.

Erreurs fréquentes

• Utiliser uniquement une recherche par mots-clés classique pour un système censé répondre à des questions formulées naturellement, ratant des correspondances évidentes pour un humain mais absentes textuellement.
• Découper les documents en chunks trop petits ou trop grands sans tester l'impact réel sur la qualité de recherche, un paramètre souvent sous-estimé dans la conception d'un système RAG.
• Ne jamais réévaluer la pertinence des résultats de recherche avant de les envoyer au modèle générateur, propageant des passages non pertinents dans la réponse finale.

À retenir

• Un embedding transforme un texte en représentation numérique, permettant une recherche par sens plutôt que par correspondance exacte de mots.
• Une base de données vectorielle stocke ces embeddings et retrouve rapidement les plus proches d'une requête.
• Le découpage des documents en chunks est un paramètre de conception important, avec un compromis entre contexte préservé et précision de recherche.

Mini-exercice

Un utilisateur pose une question avec des mots différents de ceux utilisés dans le document source, mais de sens équivalent. Une recherche par mots-clés classique échouerait probablement à trouver ce document. Quel mécanisme du RAG résout ce problème ?

Réponse : la recherche par embeddings (recherche sémantique), qui compare le sens des textes via leur représentation vectorielle plutôt que la correspondance exacte des mots, retrouvant des passages pertinents même sans chevauchement textuel direct.