Comment chercher dans vos propres documents avec des plongements, et prouver que ça fonctionne?

Un plongement est une liste de nombres qui place un bout de texte sur une carte du sens, comme l’explique cette introduction. Ce projet saute la théorie et s’attaque à la partie souvent négligée : bâtir un test étiqueté, pour savoir si votre recherche fonctionne avant de la mettre devant quiconque.

Les documents sont le guide d’un centre communautaire fictif, Harrow Bay : 24 courts passages sur les heures, les tarifs, le stationnement et ainsi de suite. Les questions forment trois ensembles, chacune avec un bon passage connu : 12 qui partagent des mots avec le document, 14 écrites exprès pour éviter ses mots et 12 en français. Le script 08_search_documents.py contient tout cela. Les modèles se téléchargent gratuitement, sous licence Apache 2.0, et tout a été exécuté sur le processeur.

La recherche en dix lignes

import numpy as np
from sentence_transformers import SentenceTransformer

model = SentenceTransformer("sentence-transformers/all-MiniLM-L6-v2", device="cpu")
passages = ["The pool closes at 21:00 on weekdays.",
            "Households with low income can apply for a reduced rate.",
            "Only service animals may enter the building."]
vectors = model.encode(passages, normalize_embeddings=True)

question = "I can't afford the yearly price, is there help?"
scores = vectors @ model.encode([question], normalize_embeddings=True)[0]
for i in np.argsort(-scores):
    print(round(float(scores[i]), 2), passages[i])

normalize_embeddings=True ramène chaque vecteur à une longueur de un, si bien qu’une simple multiplication donne la similarité cosinus, un score de proximité qui vaut 1 pour des directions identiques. C’est toute la recherche sémantique à cette échelle. Pour des millions de passages, on ajouterait un index, une structure qui trouve vite les voisins. Pour quelques milliers, une simple boucle comme celle-ci suffit.

Le script compagnon cherche aussi dans un dossier de vos propres fichiers .txt et .md :

python 08_search_documents.py --ask "how long do you keep lost items?" --folder my_notes/

La comparaison mesurée

Top 1 signifie que le bon passage est arrivé en tête. Top 3 signifie qu’il figurait parmi les trois premiers, ce qui compte si une personne ou un modèle de langage lit les résultats. BM25 est une formule classique de pointage par mots-clés, écrite dans le script en une quinzaine de lignes.

Mesuré ici : 24 passages, 38 questions, processeur Apple M5 Max, sentence-transformers 6.2. Avec si peu de questions, une seule question déplace un chiffre de 7 ou 8 points. Ne lisez que les grands écarts. Un test plus grand sur vos propres documents vous en dira plus que ce tableau.

Deux résultats pratiques ressortent pour une organisation bilingue. Le modèle anglais ne peut pas servir les francophones : il est tombé à 33 %. Et le modèle multilingue a cédé un peu de qualité en anglais en échange d’un fonctionnement dans plusieurs langues.

Deux résultats qui vont contre les attentes

On recommande souvent de combiner la recherche par mots-clés et la recherche par le sens. Ici, ça n’a pas aidé. La fusion des deux classements par rang réciproque, qui additionne des scores selon la position dans chaque liste, a obtenu 62 % en top 1 avec le premier modèle, sous les 88 % des plongements seuls. Les mots-clés étaient si faibles sur les questions reformulées qu’ils ont tiré les bons résultats vers le bas. La recherche hybride aide surtout quand les mots-clés trouvent ce que les plongements manquent, comme des numéros de pièces et des noms rares, et ce guide en contenait peu. Testez-la sur vos données avant de l’adopter.

La taille des passages a aussi donné un résultat intéressant. Le script a joint le guide en un seul long texte et l’a coupé à l’aveugle, comme le ferait un pipeline naïf.

Le « 100 % » des très grands morceaux est creux : avec deux morceaux, le top 3 est le guide entier. La dernière colonne montre le vrai coût. Les petits morceaux ont bien réussi parce que ce guide est fait de courts passages autonomes. De longs rapports dont les phrases dépendent des paragraphes précédents se comporteront autrement. Notez aussi que le modèle coupe les longues entrées : par défaut, le texte au-delà de 256 morceaux de mots est ignoré sans aucune erreur.

Comment l’empêcher de répondre quand rien ne correspond?

Une recherche renvoie toujours quelque chose, même pour une question à laquelle vos documents ne peuvent pas répondre. Dix questions hors sujet, comme la façon de réparer un robinet, montrent le problème. La solution est un score minimal, choisi à partir de vos propres chiffres.

Le modèle multilingue exige un autre réglage : à 0,4, il a traité 77 % des bonnes questions et 10 % des questions hors sujet. Les scores d’un modèle ne veulent rien dire pour un autre : refaites ce tableau chaque fois que vous changez de modèle.

La ligne à choisir dépend du coût d’une mauvaise réponse. Pour un outil de recherche destiné au personnel, trop répondre ne pose pas de problème, puisqu’une personne regarde le résultat. Pour un assistant public, préférez « Je n’ai pas trouvé » et un lien vers un être humain. Dès qu’un modèle de langage rédige des réponses à partir des passages, vous avez un deuxième système à tester, et cet article sur l’évaluation du RAG couvre la suite. Si vous hésitez entre la recherche et l’entraînement d’un modèle, le projet suivant mesure directement ce choix.