Signification en tant que coordonnées : des embeddings aux bases de données vectorielles et au RAG
Les embeddings, la similarité cosinus, les bases de données vectorielles et le cycle RAG expliqués en quatre courtes phrases sur les chiens, les chats et Paris, afin d’augmenter le taux de clics sur les recherches sémantiques.
Sources: Meaning as Coordinates: Semantic Search, Vector Databases, and RAG
Une boîte de recherche qui ne renvoie rien pour « un bon animal de compagnie pour une personne active », alors que la base de connaissances est pleine de conseils sur les chiens, montre précisément où la correspondance des mots-clés échoue. La solution consiste à considérer le sens comme une position dans l’espace. Cette idée est au fondement de la recherche sémantique, des bases de données vectorielles et de la génération améliorée par la récupération d’informations, et un seul petit exemple suffit pour en comprendre l’ensemble.
L’exemple utilisé tout au long
Imaginez une petite base de connaissances composée de quatre phrases :
1. Dogs are loyal and need daily walks and exercise
2. Cats are independent pets that groom themselves
3. Golden retrievers are friendly family dogs
4. The capital of France is Paris
Un utilisateur demande :
"What's a good pet for an active person who exercises a lot?"
La question ne contient jamais les mots « chien » ou « se promener ». Une recherche par mots-clés simples ne donnerait aucun résultat utile. Pourtant, une machine peut encore fournir la bonne réponse, car elle compare l’emplacement des textes dans un espace sémantique et non les mots qu’ils partagent.
Sens similaire, points proches
Un vecteur n’est rien d’autre qu’une série de nombres qui encodent le sens d’un texte. Une fois que des sens similaires génèrent des vecteurs similaires, trouver des textes liés revient à localiser des points proches. Cela transforme un problème linguistique en un problème géométrique, qui constitue la base des recherches modernes, des recommandations et de RAG, la technique qui permet à un modèle linguistique de consulter une bibliothèque externe afin de cesser d’inventer des éléments.
Lorsque le sens est représenté par un ensemble de coordonnées, travailler avec le sens signifie travailler avec la distance et la direction, des éléments que les ordinateurs maîtrisent exceptionnellement bien.
Embeddings pour des passages entiers
Les vecteurs au niveau des mots ne suffisent pas pour rechercher dans des documents. Un vecteur unique est nécessaire pour une phrase, un paragraphe ou une page. Les modèles Transformer peuvent en générer un : en entrant un morceau de texte, on obtient un vecteur, généralement appelé embedding, qui résume son sens.
"Dogs need daily walks" ──► [ 0.91, 0.08, -0.30, ... ] (e.g. 384 numbers)
"The capital is Paris" ──► [-0.05, 0.62, 0.44, ... ]
Un embedding de phrase compresse un passage en une liste de nombres de longueur fixe. Deux textes sur le même sujet produisent des listes similaires, tandis que des textes sans lien entre eux génèrent des listes très différentes. Chaque nombre en particulier n’a aucun sens pour une personne. Ce qui compte, c’est la manière dont ils se rapportent les uns aux autres, et personne ne les lit directement. On ne fait que les comparer.
L’image à garder en tête
Imaginez chaque texte comme un point dans l’espace. Les textes ayant un sens similaire se trouvent proches les uns des autres, tandis que ceux qui ne sont pas liés se situent loin les uns des autres.
(a simplified 2-D "meaning space")
dog walks • • golden retriever ← the "dogs" neighborhood
\ /
(pets)
cat grooming • • Paris ← far away, different topic
Dans cette carte simplifiée, les deux phrases concernant les chiens se trouvent regroupées, la phrase sur le chat est située à proximité car elle traite également d’un animal de compagnie, tandis que la phrase sur Paris se trouve dans une région complètement différente. Les espaces d’incorporation réels possèdent des centaines de dimensions, mais l’intuition reste identique : des significations liées correspondent à des points proches. Tout ce qui suit constitue une méthode pour trouver les points les plus proches.
Recherche par mots-clés contre recherche sémantique
La recherche par mots-clés compare les mots. En cherchant « exercice », un document mentionnant « promenades quotidiennes » sera ignoré, car aucun mot n’est commun. Cette méthode est rapide mais littérale, et elle manque de compréhension du sens.
La recherche sémantique compare les significations. La requête est transformée en vecteur, et les vecteurs des documents les plus proches de celui-ci sont retournés, quelles que soient les mots utilisés dans chacun d’eux. Voici le classement obtenu pour cet exemple, en utilisant des scores de similarité réels :
Query: "a good pet for an active person who exercises"
0.999 ############################# Golden retrievers are friendly family dogs
0.995 ############################# Dogs are loyal and need daily walks and exercise
0.398 ########### Cats are independent pets that groom themselves
0.059 # The capital of France is Paris
La requête ne partage aucun mot-clé avec les phrases concernant les chiens, pourtant toutes deux obtiennent la note la plus élevée, d’environ 1,0. La phrase concernant le chat se situe au milieu, car il s’agit toujours d’un animal de compagnie, tandis que la phrase concernant Paris est proche de zéro. Une recherche par mots-clés n’aurait rien retourné. C’est pourquoi la recherche sémantique semble intelligente : elle reconnaît qu’une personne active qui fait de l’exercice et un chien ayant besoin de promenades quotidiennes désignent à peu près la même chose. L’écart entre la recherche par mots-clés et la recherche sémantique correspond à l’écart entre l’absence de résultats et la réponse qui était réellement souhaitée.
Mesurer la proximité avec la similarité cosinus
Le outil habituel pour mesurer à quel point deux vecteurs sont proches est la similarité cosinus. Elle prend en compte l’angle entre deux flèches et ignore leur longueur.
- Des flèches pointant dans la même direction donnent une similarité proche de 1, ce qui signifie une signification très similaire.
- Des flèches perpendiculaires donnent une similarité proche de 0, ce qui signifie qu’elles ne sont pas liées.
- Les flèches pointant dans des directions opposées indiquent une similarité proche de -1, ce qui signifie un sens opposé.
Un petit angle entre la requête et un document concernant un chien se présente comme ceci :
^ query
│ /
│/ small angle → cosine ≈ 1 (similar)
└──────► dog doc
Et un aperçu général du document de Paris :
^ query
│
└──────► Paris doc big angle → cosine ≈ 0 (unrelated)
L’angle est utilisé à la place de la longueur afin que les textes longs et courts puissent être comparés équitablement. Le calcul tient en une seule ligne : il suffit de multiplier les vecteurs entre eux puis de les normaliser.
import numpy as np
def cosine(a, b):
return a @ b / (np.linalg.norm(a) * np.linalg.norm(b))
Cette petite fonction est à l’origine de chaque score dans le classement ci-dessus. Les scores vont de -1 à 1, et une valeur proche de 1 indique que les deux textes signifient la même chose.
Bases de données vectorielles pour des recherches à grande échelle
Cet exemple comprend quatre documents. Les systèmes réels en contiennent des millions ou des milliards, tels que chaque ticket de support, page de produit ou paragraphe de documentation entreprise. Comparer une requête avec un milliard de vecteurs un par un à chaque recherche est bien trop lent.
Une base de données vectorielle existe pour cela. Il s’agit d’un stockage conçu pour bien faire une seule chose : prendre un vecteur de requête et retourner rapidement les vecteurs stockés les plus proches. Elle s’appuie sur la recherche d’adjacent le plus proche approximative, une famille d’index ingénieux qui trouvent des correspondances presque identiques en sautant la plupart des comparaisons. Un léger sacrifice en termes de précision est consenti pour un gain considérable en vitesse.
documents ─► embed ─► [ vector database ]
│ stores millions of vectors
│ + a smart index (ANN)
query ─► embed ─────────► │
▼
top-k nearest matches (in milliseconds)
Les documents sont traités une seule fois par le modèle d’incorporation et sauvegardés avec un index. Lorsqu’une question arrive, elle est également incorporée, et la base de données répond en un clin d’œil avec les k éléments les plus correspondants, quel que soit le nombre de vecteurs qu’elle contient. Parmi les solutions existantes figurent FAISS, Pinecone, Weaviate, Chroma et Milvus, ainsi que pgvector, une extension qui intègre la recherche vectorielle dans PostgreSQL classique. Les détails diffèrent, mais toutes stockent des embeddings et permettent de trouver rapidement des éléments similaires. En bref, une base de données vectorielle est un moteur de recherche pour le sens.
Ce que les modèles de langage simples ont tort de faire
Les grands modèles de langage sont impressionnants, mais ils présentent trois faiblesses persistantes :
- Hallucinations. Lorsqu’ils ne sont pas certains, ils produisent des réponses fluides, convaincantes et fausses.
- Datée de fin des connaissances. Il ne connaît que ce qui se trouvait dans les données d’entraînement, figées à une date antérieure.
- Aucune connaissance de vos données. Les documents internes, les notes privées et la réunion de la semaine dernière lui sont tous inconnus.
You: "What's our refund policy?"
Plain LLM: "Typically, refunds are offered within 30 days..." ← a guess, not YOUR policy
Lorsqu’on lui pose des questions sur la politique de remboursement, un modèle simple répond de mémoire en faisant une supposition plausible, et non selon la politique réelle de l’entreprise. Cela pose des risques pour toute information factuelle ou privée. Il est nécessaire de fournir les faits exacts au moment même où le modèle répond, sans avoir recours à un reconditionnement, et RAG fait précisément cela.
Génération augmentée par la récupération d’informations
RAG combine tout ce qui a été mentionné précédemment en un seul processus itératif. Au lieu de demander au modèle de répondre de mémoire, les documents pertinents sont d’abord récupérés grâce à une recherche sémantique, puis le modèle est invité à répondre en se basant sur eux. Le nom même de cette méthode en décrit le fonctionnement : la récupération permet de trouver du texte pertinent, l’augmentation signifie l’ajout de ce texte à la demande, et la génération permet au modèle d’écrire la réponse.
1. Question ─► embed ─► search the vector DB ─► top relevant chunks
│
2. Build a prompt: "Using ONLY the context below, answer the question.
Context: [retrieved chunks]
Question: [user's question]"
│
3. LLM generates an answer grounded in the retrieved text ─► with sources
Exécution de l’exemple :
Question: "What's a good pet for an active person?"
→ retrieves docs 1 & 3 (the dog sentences, from Figure 3)
→ prompt: "Using this context: [Dogs need daily walks and exercise;
Golden retrievers are friendly family dogs] — answer the question."
→ LLM: "A dog — especially a golden retriever — is a great fit, since
they need daily walks and exercise. (Source: docs 1, 3)"
La réponse est désormais fondée sur des éléments concrets. Elle s’appuie sur des documents réels que le propriétaire contrôle, et elle permet d’indiquer l’origine d’un fait. Beaucoup moins de réponses inventées parviennent à passer inaperçues. RAG est une recherche sémantique associée à un modèle de langage : il récupère les faits appropriés, puis laisse le modèle formuler la réponse.
Le processus pratique et son principal piège
RAG comporte deux phases. La configuration s’effectue une seule fois, tandis que les requêtes sont traitées chaque fois que quelqu’un pose une question.
── SETUP (once) ── ── QUERY (every question) ──
documents user question
│ split into chunks │ embed
│ embed each chunk │ search vector DB
│ store in vector DB │ get top-k chunks
▼ │ build prompt with chunks
[ vector database ] ◄───── search ──────┤ send to LLM
▼
grounded answer
Les documents sont divisés en blocs, intégrés et stockés une seule fois. Chaque question est intégrée, comparée à la base de données, et les meilleurs blocs sont transmis au modèle pour générer la réponse finale.
Le défi réside dans la segmentation des documents en blocs avant leur intégration. Les blocs trop grands fusionnent plusieurs sujets en un seul vecteur, entraînant des correspondances floues. Les blocs trop petits perdent du contexte, ce qui peut faire que la réponse soit tronquée. Le choix de la taille des blocs fait partie des décisions les plus importantes dans un système RAG fonctionnel, et il rappelle que la préparation des données, bien que peu visible, influence tout le processus ultérieur.
La même chose en code
La partie de récupération dans RAG, une recherche sémantique de base, ne nécessite que quelques lignes de code NumPy. Elle reçoit les vecteurs de certains documents ainsi que celui de la requête, puis classe les documents en fonction de leur similarité cosinus :
import numpy as np
def cosine(a, b):
return a @ b / (np.linalg.norm(a) * np.linalg.norm(b))def search(query_vec, doc_vecs, docs, k=2):
scores = [(cosine(query_vec, v), d) for v, d in zip(doc_vecs, docs)]
return sorted(scores, reverse=True)[:k] # top-k most similar
Lorsque l’on alimente les quatre vecteurs de animaux de compagnie et de Paris ainsi que la requête concernant des personnes actives, le système renvoie d’abord les deux documents relatifs aux chiens, conformément au classement présenté précédemment. Voilà donc une recherche sémantique en quelques lignes seulement.
Dans un projet réel, on ne crée pas manuellement les vecteurs. On fait appel à un modèle d’incorporation et à un stockage de vecteurs, et le code ressemble à peu près à ceci :
# Illustrative real-world usage (libraries download a model, so not run here)
from sentence_transformers import SentenceTransformer
import chromadb
model = SentenceTransformer("all-MiniLM-L6-v2") # turns text into vectors
db = chromadb.Client().create_collection("pets")db.add(documents=my_docs, embeddings=model.encode(my_docs).tolist(),
ids=[str(i) for i in range(len(my_docs))])q = "a good pet for an active person"
hits = db.query(query_embeddings=model.encode([q]).tolist(), n_results=2)
# hits now holds the top-2 most semantically similar documents
Les bibliothèques s’occupent du travail lourd, mais au fond elles effectuent la même recherche de similarité cosinus. La recherche sémantique repose sur quelques lignes de calcul mathématique sur des vecteurs, et les outils réels encapsulent cette idée en assurant vitesse et échelle.
Tout le processus
Le texte commence par des caractères et des tokens, devient ensuite des embeddings, acquiert du contexte grâce à l’attention au sein d’un transformateur, et finit par se transformer en une carte de connaissances consultable qui rend les modèles de langage précis et utiles.
raw text
→ characters / tokens / embeddings [article 1: From Characters to Meaning]
→ attention turns them into context-aware
vectors inside a transformer [article 2: Attention, Explained Simply]
→ those vectors become coordinates we can
store, search, and retrieve [article 3: this one]
→ semantic search (find by meaning)
→ vector databases (search at scale)
→ RAG (ground an LLM in real data)
Le fil conducteur de tout cela est une idée qui se développe progressivement : le sens est un point dans l’espace. D’abord, cela s’applique aux mots, puis aux phrases dans un contexte, et enfin à des bibliothèques entières de documents qui peuvent être recherchées et analysées.
Une autre distinction mérite d’être gardée à l’esprit. RAG permet à un modèle d’accéder à des connaissances sans modifier le modèle lui-même, un peu comme lui remettre des notes à lire au moment de répondre. Le fine-tuning est une approche différente, où les poids internes du modèle sont ajustés par un entraînement sur des exemples. RAG fournit des connaissances à lire, tandis que le fine-tuning change la nature même du modèle. Savoir lequel choisir constitue une compétence pratique à part entière.
Lectures complémentaires
- Notes pratiques : Les limites de la recherche vectorielle dans RAG — Similitude cosinus et le — Guide opérationnel des Notes pratiques : Les limites de la recherche vectorielle dans RAG — Similitude cosinus et le : contrats, vérifications et espaces de code prêts à l’emploi pour les équipes qui mettent en œuvre ce modèle.
- Notes pratiques : Bases de données vectorielles pour l’indexation RAG en production : Indexation, recherche hybride — Guide opérationnel des Notes pratiques : Bases de données vectorielles pour l’indexation RAG en production : Indexation, recherche hybride : contrats, vérifications et espaces de code prêts à l’emploi pour les équipes qui mettent en œuvre ce modèle.