Machine Learning Mastery montre comment monter un RAG avec scikit-learn, sans base vectorielle

Le 13 octobre 2026, Machine Learning Mastery a publié un guide pratique pour construire un pipeline RAG de bout en bout avec une pile minimale. La recherche vectorielle est confiée à scikit-learn, et les embeddings comme le traitement du texte reposent sur des modèles open source. Au stade du prototype, il n'y a besoin ni de serveurs de base vectorielle, ni d'infrastructure dédiée, ni d'API payantes. Le contenu est pédagogique et ne correspond pas à une release, mais il montre bien le peu qu'il faut pour faire tourner un schéma fonctionnel du type « trouver le contexte, puis répondre ».

L'annonce n'en décrit que les grandes lignes ; nous détaillons donc ci-dessous le schéma selon les étapes classiques d'un RAG. Les paramètres précis figurant dans le texte complet du guide ne sont pas repris ici.

Les composants du pipeline

Un RAG classique repose sur quatre opérations. On découpe les documents en fragments, on transforme ces fragments en vecteurs, on retrouve les plus proches à la requête, puis on injecte le texte retrouvé dans le prompt du modèle de langage. Le tout peut tenir dans un seul fichier.

Dans le guide, la vectorisation est assurée par des modèles d'embeddings open source, et la recherche des plus proches voisins par scikit-learn. La bibliothèque propose pour ce scénario des outils prêts à l'emploi : la similarité cosinus et la classe NearestNeighbors. La matrice de vecteurs reste en mémoire, la requête est convertie en un vecteur de même dimension, puis on sélectionne les top-k.

Profil type d'une telle pile :

• Recherche : scikit-learn, similarité cosinus ou NearestNeighbors, parcours exhaustif exact, sans approximation.
• Embeddings : un modèle open source. À titre d'exemple, le populaire all-MiniLM-L6-v2 produit des vecteurs de 384 dimensions.
• Stockage : un tableau NumPy en mémoire vive.
• Volume : 100 mille fragments en 384 dimensions et en float32 occupent environ 150 Mo.
• Dépendances : Python, scikit-learn et une bibliothèque pour charger le modèle d'embeddings.

Les chiffres de volume sont calculés à partir de la dimension du vecteur et ne proviennent pas de l'article. Ils donnent un ordre de grandeur : 384 nombres de 4 octets représentent 1,5 Ko par fragment.

Pourquoi se passer d'une base vectorielle

Premier avantage : la transparence. Quand la recherche se résume à une multiplication de matrices et à un tri, on voit ce qui se passe à chaque étape. On peut afficher les scores de similarité, voir quel fragment l'emporte et pourquoi, et repérer immédiatement un mauvais découpage en chunks. Dans les systèmes spécialisés, une partie de cette mécanique est masquée derrière une API.

Deuxième avantage : le faible coût d'entrée. Le prototype n'exige ni compte, ni clé, ni appel réseau. Pour une base de connaissances interne de quelques milliers de pages ou pour la formation d'une équipe, cela suffit. À ces volumes, le parcours exhaustif s'exécute en une fraction de seconde, si bien que les index approximatifs de type HNSW n'apportent rien.

Troisième avantage : la reproductibilité. Si vous figez les versions des bibliothèques et du modèle, votre collègue obtiendra le même résultat que vous.

Où ce schéma atteint ses limites

Le parcours exhaustif évolue de façon linéaire. Quand le corpus atteindra des millions de fragments, le temps de réponse et la mémoire deviendront gênants, et il faudra passer à FAISS, pgvector, Qdrant ou à des équivalents. Les contraintes supplémentaires retombent aussi sur le développeur : filtres sur les métadonnées, droits d'accès, mise à jour incrémentale de l'index. Avec scikit-learn, il faut tout cela l'écrire à la main.

La qualité des réponses ne dépend pas de la bibliothèque de recherche, mais de trois facteurs : le découpage du texte, le modèle d'embeddings retenu et la construction du prompt. Remplacer le stockage par un système plus puissant ne résoudra pas ces problèmes.

Comment l'utiliser en pratique

Commencez par un petit corpus, par exemple votre documentation ou votre FAQ, et montez le pipeline dans un seul script. Préparez 20–30 questions de contrôle dont les réponses sont connues, et mesurez la proportion de cas où le fragment attendu figure dans le top-3. Cette métrique, le hit rate, montrera la qualité de la recherche avant même que vous ne branchiez la génération.

Modifiez ensuite une seule variable à la fois : la taille des chunks, le modèle d'embeddings, la valeur de k. Si la métrique progresse, le schéma fonctionne. Lorsque le corpus ou la charge dépasseront la mémoire d'une seule machine, remplacez le bloc de recherche par une base vectorielle de production. Le reste du code ne changera pas, car l'interface « vecteur de requête en entrée, liste de fragments en sortie » est la même dans les deux cas.