Le RAG (Retrieval-Augmented Generation) est une architecture qui combine un LLM avec une base de connaissances externe. Le LLM ne repose plus uniquement sur ses données d'entraînement — il peut récupérer des informations en temps réel pour répondre avec précision. Cela réduit les hallucinations de 40 à 60% et permet des réponses factuelles à jour.
Le RAG répond à la principale limite des LLM : leur ignorance des données privées ou récentes. L'architecture fonctionne en deux temps : (1) le retrieval — une requête utilisateur est convertie en vecteur via un embedding model, puis les k documents les plus similaires sont récupérés dans la vector database ; (2) la génération — le LLM reçoit à la fois la requête originale ET les documents retrieved, et génère une réponse contextualisée. Le RAG est indispensable pour les applications métier : FAQ interne, support client, analyse de documents. Les vecteurs ont typiquement 768 à 1536 dimensions selon le modèle d'embedding utilisé.
Le RAG, c'est comme un étudiant qui passe un examen à livre ouvert. Au lieu de compter uniquement sur sa mémoire (données d'entraînement du LLM), il a le droit d'ouvrir son manuel (vector database) pour trouver la réponse exacte. Il comprend la question, cherche la réponse dans le manuel, puis répond de manière cohérente. Sans livre, il hallucinerait des dates et des chiffres. Avec le manuel, il cite des faits vérifiables.
La requête utilisateur et les documents sont convertis en vecteurs numériques via un modèle d'embedding (OpenAI text-embedding-3-large, Mistral Embed, ou BGE). Chaque texte devient un point dans un espace à N dimensions — les textes similaires sont géométriquement proches. Le choix du modèle d'embedding impacte directement la qualité du retrieval : un bon modèle maintient la nuance sémantique (distinguant "banque" l'institution de "banque" la rive). Coût d'embedding : $0.02-0.13 par million de tokens selon le modèle.
Les vecteurs des documents sont stockés dans une vector database (Pinecone, Weaviate, Milvus, Qdrant) qui effectue des recherches de plus proches voisins (kNN) via similarité cosinus. Une vector database de qualité répond en 10 à 50ms sur des index de 10M+ vecteurs. Les métadonnées attachées à chaque vecteur (date, catégorie, auteur) permettent un filtrage hybride : "retriever les documents sur la politique de retour ET publiés en 2024".
Le LLM reçoit un prompt structuré combinant la question, les documents retrieved, et des instructions de réponse. Le system prompt définit le rôle ("tu es un assistant客服 interne") et les contraintes ("cite toujours tes sources", "si l'information est absente, dis-le"). La qualité du prompt détermine 60% de la performance finale. Les techniques avancées incluent le query expansion (décomposer une question vague en sous-questions) et le reranking (réordonner les résultats retrieved par pertinence avec un modèle cross-encoder).
Une entreprise SaaS B2B (200 employés, logiciel RH) avait 50 000 documents internes (politiques, procédures, FAQ, contrats). Les employés passaient 45 minutes/jour à chercher des informations. Implémentation RAG : (1) chunking des documents en segments de 512 tokens avec overlap de 64 tokens, (2) indexation dans Pinecone avec le modèle text-embedding-3-large, (3) interface chat basée sur GPT-4o avec retrieval des 5 documents les plus similaires. Résultat : temps de recherche 3 minutes (-93%), satisfaction employés +4.2/5, appels au support interne -60%. Coût : $2 800/mois (API + infrastructure) pour un ROI estimé à $180 000/an en productivité récupérée.
| Métrique | Valeur |
|---|---|
| Réduction hallucinations | -40 à -60% |
| Temps de réponse retrieval | 10-50ms (10M+ vecteurs) |
| Coût embedding | $0.02-0.13 / 1M tokens |
| Chunk size optimal | 512-1024 tokens |
| Documents retrieved (k) | 5-10 par requête |
| Score similarité minimum | > 0.7 (filtrage) |