Gains :
- Conception des composants et du flux de données d'un assistant RAG d'entreprise de bout en bout
- Combiner des données multi-sources (wiki, ticket, PDF, base de données) dans un seul assistant
- Prendre des décisions architecturales en matière d'évolutivité, de mise en cache et de latence
Dans les unités précédentes, nous avons appris les parties une par une : intégration, base de données vectorielles, segmentation, récupération. Combinons maintenant ces éléments et construisons une architecture de bout en bout d'un assistant qui communique avec les données de votre propre entreprise. L'objectif est d'amener un employé à demander : « Quelle est notre politique en matière de congés ? » Un système où les gens peuvent poser des questions, les réponses sont basées sur de vrais documents internes, des citations et combinent plusieurs sources de données. Cette unité traite l’ensemble des décisions relatives à l’architecture, au flux de données et au niveau de la production.
Composants de bout en bout
Un assistant RAG d'entreprise se compose de deux lignes distinctes. La ligne d'indexation (hors ligne) prépare les données ; La ligne de requête (en ligne) répond à la question.
Composants de la ligne d'indexation :
- Connecteurs : connecteurs qui extraient des données de sources : wiki, système de tickets, magasin de fichiers, base de données, courrier électronique.
- Normalisation : Conversion de différents formats (PDF, HTML, DOCX) en texte propre ; nettoyage des en-têtes et pieds de page.
- Chunking + métadonnées : Chunking et marquage (source, date, autorité).
- Incorporation + chargement : écriture de vecteurs et de métadonnées dans la base de données de vecteurs.
Composants du pipeline de requête :
- Prétraitement des requêtes : Réécriture, décentralisation.
- Récupération : recherche hybride + filtre de métadonnées + reclassement.
- Création d'invite : placer le contexte + la question + les instructions dans le modèle.
- Génération : réponse fondée (contextuelle) à partir du modèle + sources.
- Post-traitement : formatage des citations, contrôle de sécurité, journalisation.
Astuce : Séparez physiquement la ligne d’indexation de la ligne de requête. L'indexation est lente et périodique (s'exécute par lots pendant la nuit) ; La ligne d’enquête doit être légère et immédiate. Le mélange des deux lignes force un traitement lourd pendant que l'utilisateur attend.
Visualisation du flux de données
[INDEXATION - hors ligne]Ressources → Normaliser → Morceau+Métadonnées → Intégrer → Base de données vectorielle (wiki, ticket, PDF, DB)[REQUÊTE - en ligne]Question utilisateur → Prétraitement → Récupération (hybride+filtre+reclassement) → Invite (contexte+question+instruction) → Modèle → Réponse+Source → Utilisateur
Combinaison de données multi-sources
Dans les vraies entreprises, la réponse ne s’arrête pas à un seul endroit. « Comment émettre un remboursement à un client ? » La réponse à la question se trouve à la fois dans l'article d'aide (procédure), dans l'historique du ticket (exemples réels) et dans le PDF de la politique (règles). L'assistant doit tous les rechercher dans un seul pool.
Point critique : lors de la combinaison de ressources dans un seul magasin de vecteurs, chaque fragment doit transporter les métadonnées `source_tour`. Vous pouvez donc tous les rechercher et les filtrer si nécessaire, par exemple « n'apporter que les politiques officielles ». De plus, différentes sources ont différents niveaux de fiabilité : politique officielle > article d'aide > note de ticket d'un employé. Vous pouvez spécifier cette priorité dans le reclassement ou dans l'invite.
Source
Type de contenu
confiance
Fréquence de mise à jour
Politique PDF
règle officielle
haut
mensuellement
Article d'aide
Procédure
moyen-élevé
hebdomadaire
Historique des billets
échantillon réel
moyen
Continu
wiki
Note mixte/actuelle
Variable
Continu
Évolutivité, cache et latence
Trois problèmes ressortent en production. Latence : L'expérience se détériore lorsque l'utilisateur attend plus de 2 secondes. Solution : affichez la réponse sous forme de streaming – elle est diffusée sur l'écran au fur et à mesure que le modèle écrit. Cache : pour les questions fréquemment posées et les contextes répétitifs, le cache augmente la vitesse et réduit les coûts. Échelle : à mesure que le nombre d'utilisateurs augmente, il est nécessaire de pouvoir mettre à l'échelle la récupération et la modélisation des appels horizontalement.
Règle générale du côté des coûts : l'étape la plus coûteuse est généralement le nombre de jetons allant au plus grand modèle. Par conséquent, réduire le contexte à 4 bonnes parties en reclassant améliore à la fois la qualité et le coût. Une conception courante consiste à utiliser un modèle plus petit/plus rapide pour une classification ou un routage simple, et un modèle plus puissant pour la réponse finale (par exemple claude-opus-4-8).
Attention : Ne configurez pas l'indexation comme "faites-le une fois, oubliez-le". Les documents sont modifiés, supprimés, ajoutés. Établir une stratégie de réindexation : détecter les documents modifiés et retraiter uniquement ceux-ci. L'index périmé produit une réponse qui semble actuelle mais qui est fausse.
Architecture faible / Architecture forte
Faible (scénario unique, tout mélangé) :
Lorsque l'utilisateur demande : lire les documents à ce moment-là, les détruire, les intégrer, les rechercher, y répondre.# Problème : toute l'indexation est répétée pour chaque question ; secondes de retard, # pas de séparation des sources, pas de filtre, pas de rafraîchissement.
Puissant (pipes fractionnées + métadonnées + cache + streaming) :
Indexation : exécution par lots la nuit, actualisation des documents modifiés. Requête : ligne légère — prétraitement → récupération hybride + filtre → reclassement → invite → modèle (streaming) → citation → journal. Les questions fréquemment posées et la source sont mises en cache.
Trois mini-étuis
Cas 1 — Ligne confuse, retard important. Une startup a écrit un script qui retraite les PDF à chaque question ; Chaque réponse prenait en moyenne 11 secondes. Lorsque la ligne d'indexation a été séparée et que les données ont été préalablement transférées vers le magasin vectoriel, le temps de requête a été réduit à 1,3 seconde et avec le streaming, le « premier mot » est apparu en 400 ms.
Cas 2 — Trop de ressources, mauvaise priorité. Un assistant d'assistance a accordé un poids égal au PDF de la politique et aux anciennes notes de ticket ; Le modèle présentait parfois comme règle officielle l'évaluation incorrecte d'un employé d'il y a deux ans. Lorsque les métadonnées source_tour et l'instruction « Considérer la politique officielle en cas de conflit » ont été ajoutées à l'invite, les erreurs de fausse priorité ont été réduites de 89 %.
Cas 3 — Index périmé. Une assistante RH travaillait avec un index qui n'était pas mis à jour depuis 3 mois ; La politique de congé a changé, mais l'assistant parlait du bon vieux temps. Lorsque l'actualisation quotidienne a été installée, qui détecte les fichiers modifiés, le taux de réponse actuel est passé de 70 % à 99 %.
Erreurs courantes
- Mélange de lignes d'indexation et de requête : un traitement lourd est effectué pendant que l'utilisateur attend ; le retard explose.
- Ne pas mettre le type de source dans les métadonnées : Pas de priorisation ni de filtrage ; La source non fiable semble être officielle.
- Ne pas établir de stratégie de rafraîchissement : l'index devient obsolète ; De fausses réponses qui semblent actuelles sont produites.
- Ignorer le streaming : l'utilisateur regarde un écran vide ; Le retard perçu devient élevé.
- Utiliser le modèle le plus grand à chaque étape : le coût augmente inutilement ; Laissez la direction au plus petit modèle.
En résumé
- L'assistant RAG d'entreprise se compose de deux lignes distinctes : l'indexation hors ligne et la requête en ligne ; séparez-les physiquement.
- Indexation = connecteur + normaliser + bloc/métadonnées + intégration/téléchargement ; requête = pré-traitement + récupération + invite + génération + post-traitement.
- Les données multi-sources sont combinées dans un seul référentiel, mais les métadonnées source_type et la priorité de confiance sont préservées.
- Le streaming et le cache pour la latence, la limitation du contexte et la sélection du modèle en fonction du coût sont essentiels.
- Sans réindexation, l'index devient obsolète ; Retraitez régulièrement les documents modifiés.
Tâche de candidature
Dessinez un schéma architectural d'un assistant pour votre propre équipe. (1) Identifiez au moins trois sources de données réelles et notez un besoin de connecteur, une fréquence de mise à jour et un niveau de confiance pour chacune. (2) Dessinez les lignes d'indexation et de requête séparément avec un diagramme en forme de boîte et de flèche. (3) « Où puis-je réduire la latence et les coûts dans cet assistant ? » Écrivez au moins deux décisions concrètes à la question. (4) Décrivez votre stratégie de rafraîchissement en une phrase : quelle ressource sera réindexée et à quelle fréquence ?
liste de contrôle
- [ ] Je peux dessiner les lignes d'indexation et de requête séparément et avec les composants corrects.
- [ ] Je peux combiner des données multi-sources avec source_type et trust priorité.
- [ ] Je peux prendre des décisions de streaming/cache pour la latence et la sélection de modèles en fonction du coût.
- [ ] Je sais pourquoi une stratégie de réindexation est essentielle.
- [ ] Je garde à l'esprit que l'étape la plus coûteuse de mon architecture est généralement le jeton qui va au modèle plus grand.