RAG et embeddings : comment fournir à un LLM les connaissances spécifiques de votre entreprise

La question revient dans presque tous les échanges avec les clients qui explorent l’IA : « Comment faire pour que le LLM réponde avec MES données, et pas avec des informations génériques trouvées sur Internet ? » La réponse courte, c’est RAG. Décortiquons ce concept ensemble.

---

Qu’est-ce que RAG ?

RAG signifie Retrieval-Augmented Generation, que l’on pourrait traduire en français par « Génération augmentée par récupération ». L’idée est on ne peut plus simple :

1. Avant d’interroger le LLM, vous recherchez dans vos documents ceux qui sont les plus pertinents par rapport à la question de l’utilisateur.
2. Vous transmettez au LLM la question plus ces documents en guise de contexte.
3. Le LLM génère une réponse en s’appuyant sur cette information.

Le LLM n’apprend pas vos données : il les lit au moment de la requête. Résultat ? Lorsque vous mettez à jour vos documents, les réponses s’actualisent automatiquement.

---

Pourquoi utiliser des embeddings ?

Imaginons que votre base de connaissances se compose de 5 documents. Dans ce cas, vous pouvez tout envoyer au LLM à chaque requête. Mais que se passe-t-il si vous en avez 500 ou 5 000 ? Ils ne tiendront pas dans le contexte du modèle et le coût exploserait.

Une recherche par mots-clés (comme dans une base de données classique) ne suffit pas : si l’utilisateur demande « Quel est le tarif de la prestation » et que votre document parle de « honoraires professionnels », une recherche textuelle classique ne fera pas le lien.

C’est là que les embeddings entrent en jeu. Chaque document (et chaque question) est converti en un vecteur numérique qui représente son sens. Les documents au sens proche ont des vecteurs proches. C’est ce qu’on appelle la « recherche sémantique ». Le système trouve ainsi les passages pertinents, même si les mots exacts ne sont pas présents.

---

Un choix technique clé : où stocker les vecteurs ?

Jusqu’à présent, cette étape nécessitait une base de données vectorielle dédiée : Pinecone, Weaviate, Qdrant ou Chroma. Ces solutions fonctionnent bien, mais elles ajoutent de la complexité : une base de données supplémentaire à maintenir, un fournisseur à payer, un nouveau point de défaillance potentiel.

Chez Tontin, nous avons opté pour une autre approche : pgvector, intégré directement à PostgreSQL avec Supabase. Cette extension ajoute des types de données vectorielles à PostgreSQL et permet d’effectuer des requêtes sémantiques en SQL classique. Les avantages sont concrets :

• Une seule base de données pour tout : données transactionnelles et embeddings.
• Cohérence transactionnelle : si vous ajoutez un document, les embeddings sont mis à jour dans la même transaction.
• Aucun coût supplémentaire lié à un service externe.
• Des performances adaptées à la plupart des cas d’usage professionnels, même avec plusieurs millions de vecteurs (à condition d’utiliser les bons index).

Les bases de données vectorielles spécialisées restent pertinentes pour les très grandes échelles (dizaines de millions de vecteurs, latence critique inférieure à 100 ms), mais pour 90 % des cas d’usage en entreprise, pgvector est largement suffisant.

---

Le workflow complet d’un système RAG en production

Une première version fonctionnelle repose sur cinq briques essentielles :

1. Ingestion : chargement des documents, découpage en chunks (paragraphes ou sections), génération des embeddings pour chaque chunk et stockage.
2. Indexation vectorielle : structure de données optimisée pour des recherches rapides par similarité (algorithmes comme HNSW ou IVFFlat).
3. Récupération (Retrieval) : à partir de la question de l’utilisateur, génération de son embedding et recherche des N chunks les plus proches.
4. Construction du prompt : assemblage de la question + des chunks récupérés + instructions pour le LLM.
5. Génération : envoi au LLM et retour de la réponse à l’utilisateur.

Chaque étape implique des choix qui impactent la qualité finale :

• Comment découper les documents ? (taille des chunks, chevauchement, etc.)
• Combien de chunks récupérer ? (trop peu = informations incomplètes ; trop = bruit et coût accru)
• Comment détecter qu’un chunk est pertinent ? (seuils de similarité, filtres par métadonnées)
• Comment éviter les hallucinations lorsque le contexte est insuffisant ?

---

Cas d’usage où RAG fait la différence

RAG s’avère particulièrement efficace dans les scénarios suivants :

• Support interne : vos équipes peuvent interroger le système et obtenir des réponses basées sur la documentation réelle de l’entreprise.
• Assistants clients : réponses sur les produits, les conditions générales ou les politiques internes, tirées de documents officiels.
• Intégration des nouveaux collaborateurs : accès en langage naturel aux processus, procédures et bonnes pratiques.
• Recherche documentaire : équipes travaillant avec des volumes importants de documents (juridiques, médicaux, financiers) peuvent effectuer des recherches sémantiques précises.

---

Conclusion : RAG, l’outil IA au meilleur ROI pour les entreprises

RAG est sans doute l’application IA offrant le meilleur retour sur investissement pour les entreprises disposant de connaissances documentées. Pourquoi ?

• Moins cher et plus stable que le fine-tuning.
• Aucun réentraînement nécessaire.
• Mise à jour automatique des réponses dès que les documents évoluent.

Si votre entreprise dispose de connaissances dispersées dans des PDF, des wikis, des e-mails ou des dossiers, et que vous souhaitez permettre à vos collaborateurs d’y accéder en langage naturel, prenons 30 minutes pour en discuter. Nous évaluerons ensemble si votre cas est adapté à une solution RAG.

---

Par Esteban Aleart, fondateur et ingénieur en chef chez Pair Programming.