Les grands modèles de langage génèrent un texte fluide. Ils ne répondent pas aux exigences de mise à la terre, de traçabilité, de fraîcheur et de contrôle d’accès. La génération augmentée par récupération résout ce problème en forçant les modèles à répondre à l'aide de preuves externes.
Les premiers RAG utilisaient un simple pipeline. Les systèmes de production utilisent désormais plusieurs modèles d'architecture. Chaque modèle cible un mode de défaillance différent. Cet article explique huit architectures RAG majeures utilisées en production aujourd'hui.
Références du projet Site NeuronDB : https://www.neurondb.ai Code source : https://github.com/neurondb/neurondb
RAG relie trois systèmes : le stockage, la récupération et la génération. La couche de stockage contient vos documents, morceaux et intégrations. La couche de récupération trouve des preuves pertinentes pour chaque requête. La couche génération produit des réponses conditionnées au contexte récupéré. Le pipeline va de la requête à la récupération de preuves, à la création de contexte, à la génération de réponses et au retour de citations. Vous bénéficiez d'une base factuelle, d'une nouvelle utilisation des données, d'une isolation des données privées et d'une prise en charge de la trace d'audit. RAG a fait évoluer l'ingénierie de l'IA du réglage rapide vers l'ingénierie des pipelines de données.
La couche de stockage prend en charge plusieurs backends, notamment des bases de données vectorielles (Pinecone, Weaviate, Milvus), des magasins de documents (Elasticsearch, OpenSearch) et des systèmes hybrides. La couche de récupération exécute des modèles d'intégration, une recherche par mot-clé ou une traversée de graphiques, en fonction de l'architecture. La couche de génération utilise généralement un modèle de langage volumineux avec un modèle d'invite. Les trois couches communiquent via une interface bien définie. Vous échangez des composants sans réécrire le pipeline complet.
Naive RAG utilise la récupération directe de similarité vectorielle sans boucle de rétroaction. Le nom vient du papier RAG original. L'architecture reste la base de comparaison.
L'ingestion de documents charge le texte brut à partir de fichiers, de bases de données ou d'API. Le prétraitement normalise les espaces, supprime le balisage et les segments selon des limites logiques. La segmentation du texte divise les documents en segments de taille fixe ou variable. Choix courants : 256 jetons, 512 jetons ou morceaux basés sur des phrases. La génération d'intégration convertit chaque morceau en vecteur à l'aide d'un modèle pré-entraîné. Le stockage vectoriel écrit les intégrations dans une base de données vectorielle avec des métadonnées (document source, index de fragments, horodatage). Au moment de la requête, l'utilisateur soumet une question. L'intégration de requête convertit la question en vecteur. La recherche vectorielle renvoie les k morceaux les plus proches par similarité cosinus ou distance euclidienne. L'injection de contexte concatène les morceaux récupérés dans une invite. La génération de réponse transmet l'invite à un LLM. Le retour de citation attache des références sources à la sortie.
La mise en œuvre prend une à deux semaines pour un ingénieur expérimenté. Le coût de l'infrastructure reste faible : un modèle d'intégration, un magasin de vecteurs, un point de terminaison LLM. L'approche fonctionne bien pour les domaines de connaissances statiques. Les corpus de FAQ, la documentation produit et les wikis internes correspondent à ce modèle. La latence reste inférieure à 2 secondes pour la plupart des déploiements. L'absence de boucles de rétroaction signifie un comportement déterministe. La même requête renvoie le même ensemble de récupération. Le débogage est simple.
Aucune boucle de vérification ne valide les preuves récupérées. Des morceaux non pertinents passent à travers lorsque l'intégration de la similarité est trompeuse. La qualité du classement dépend entièrement de la similarité d’intégration. Les requêtes ambiguës renvoient des résultats faibles. Une requête telle que « Comment corriger l'erreur » renvoie un contenu de dépannage générique plutôt qu'une documentation spécifique à l'erreur. Les requêtes à multiples facettes en souffrent. Une question sur « tarification et intégration » récupère uniquement des morceaux pour une facette. Le modèle hallucine pour combler les lacunes lorsque la récupération échoue.
La sélection de la taille des fragments a un impact sur la qualité du rappel. Les petits morceaux (128 jetons) donnent des correspondances précises mais manquent de contexte. Une section sur le « délai d'expiration de la connexion » ne parvient souvent pas à identifier la cause ou la solution. Les gros morceaux (512 jetons) capturent plus de contexte mais diluent la pertinence. La récupération top-k renvoie moins de documents distincts. Le chevauchement entre les morceaux (50 jetons) permet de préserver le contexte au-delà des frontières. Testez plusieurs tailles de fragments (128, 256, 512) par rapport à votre ensemble de requêtes. Rappel de mesure à k=5 et k=10. Choisissez la taille où rappeler les plateaux.
L’intégration du choix du modèle a un impact sur la couverture sémantique. Les modèles formés sur du texte général (OpenAI text-embedding-ada-002, phrase-transformers/all-MiniLM) sont sous-performants sur les corpus spécifiques à un domaine. Les textes médicaux, juridiques et financiers utilisent une ter...
[Courte citation de 8% de l'article original]