> For the complete documentation index, see [llms.txt](https://guides.ia.numerique.gouv.fr/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guides.ia.numerique.gouv.fr/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/prototypage.md). # Prototypage {% hint style="info" icon="arrows-to-circle" %} **Comprendre les premières étapes de construction et le fonctionnement d'une architecture RAG simple** {% endhint %} Un système RAG (Retrieval-Augmented Generation) repose sur quatre piliers : **les connaissances (sources)**, **la transformation des sources**, **le modèle de langage** et **l’interface utilisateur**. Pour en garantir l’efficacité, son déploiement doit suivre une démarche structurée, alliant rigueur technique et collaboration avec les métiers. **Cette démarche ne s'applique qu'une fois les données répertoriées, priorisées, disponibles et accessibles** (section [​Investigation métier](/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/investigation-metier.md)). L’IA générative est souvent perçue comme un agent conversationnel. Démarrer par une brique simple sous forme de *chat* permet d’expérimenter rapidement, de comprendre les usages réels et de préparer une version plus adaptée dans un second temps. \ Lors de cette première itération, l’équipe se concentre sur un enjeu central : **la qualité de l’information et la robustesse technique du *****pipeline***** RAG.** L’interface reste volontairement simple et générique. ## Objectif de la première itération **Avant d’engager les travaux, il est indispensable de (re)clarifier le cadre** sur la base des apprentissages de la phase de l'[​Investigation métier](/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/investigation-metier.md) : * À quoi doit servir l'assistant conversationnel IA ? À qui ? * Sur quel périmètre, les expérimentateurs testeront la première version ? * Quel est le niveau de précision attendu selon les usages ? * Quelles sont les erreurs critiques à éviter absolument (juridiques, métiers, éthiques, réputationnelles) ? **Un prototype ne doit pas être généraliste. Il doit tester un cas d’usage prioritaire et priorisé.** Ce périmètre conditionne les dimensions techniques : sélection des sources, le volume de données à indexer, la taille du stockage nécessaire (vector store), le choix du modèle (LLM et embeddings). Un périmètre mal défini rend l’évaluation impossible. Lors de cette première itération, **l'effort repose principalement sur les profils techniques**. Les profils métier interviennent ponctuellement pour qualifier la pertinence des réponses. **Cette première itération permet de :** * assembler les composants techniques d’un système RAG fonctionnel (sections suivantes); * tester la qualité des réponses sur les sources prioritaires (section [Evaluations référents métier](/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/evaluations-referents-metier.md)); * identifier rapidement les premiers points de friction ; * préparer les itérations suivantes. ## Architecture minimale du prototype La construction d’un prototype d’assistant conversationnel basé sur une architecture RAG repose sur une succession d’étapes techniques. L’objectif est de **transformer un corpus documentaire brut en un système capable de retrouver les informations pertinentes et de générer une réponse contextualisée** pour l'utilisateur. Schématiquement, l'architecture d'un assistant conversationnel basé sur une architecture RAG repose sur quatre briques principales : * **Base de connaissances** : données sources qui alimentent les réponses du RAG * **Moteur de recherche** (retrieval) : composant chargé d’identifier les documents ou passages les plus pertinents par rapport à la question de l’utilisateur. * **Modèle de génération** (LLM) : modèle qui génère les réponses à partir des données récupérées * **Interface** : interface utilisateur conversationnelle simple permettant de poser une question, de consulter la réponse et d'évaluer

Vue d’ensemble de l’architecture

Cette architecture se construit de manière progressive. Les différentes étapes de mise en œuvre sont détaillées dans les sections suivantes. **Sources → Parsing → Chunking → Embedding → Stockage → Recherche → Génération** 💡 Le but n’est pas d’être innovant. Le but est d’être **fiable, maintenable et mesurable.** {% columns %} {% column %} {% hint style="success" %} **À privilégier** * composants standards et maintenus * comparaison rapide de variantes * évaluation dès le début * simplicité technique {% endhint %} {% endcolumn %} {% column %} {% hint style="warning" %} **À éviter** * entraîner son propre modèle * choisir une base vectorielle exotique * construire un chatbot généraliste * complexifier l’interface * ignorer les métriques {% endhint %} {% endcolumn %} {% endcolumns %} ### Sources : alimenter le système avec des sources fiables La première étape consiste à **rassembler les sources documentaires** qui constitueront la base de connaissance de l’assistant : documents PDF (textes ou images), fichiers bureautiques (Word, Excel, etc.), pages web ou intranet, bases documentaires internes, API. La collecte des données requiert une connaissance métier des sources disponibles et pertinentes pour le système. Elle donc prise en charge par les profils métier de l'équipe. Cette phase implique des enjeux de gouvernance des données (qualité, versionning, fréquence de mise à jour, droits d’accès) et d’hébergement (où sont stockées les données, avec quelles garanties de sécurité). Une base pauvre ou obsolète dégradera immédiatement la qualité des réponses. ### Base de connaissance : transformer les documents en données exploitables Avant de pouvoir interroger les documents en langage naturel, il est nécessaire de les **transformer en données techniquement exploitables** par le système RAG. Cette préparation constitue en plusieurs étapes fondamentales : elle conditionne directement la qualité de la recherche documentaire et, par conséquent, la fiabilité des réponses générées. 1. **Parsing : ****transformer les documents en texte exploitable** Les modèles de langage travaillent sur du texte brut. Il est donc nécessaire de convertir tous les documents dans un format homogène (généralement `.txt`). Cette étape inclut : * l’extraction du texte depuis des PDF ou fichiers bureautiques ; * l’OCR (reconnaissance optique de caractères) pour les documents scannés ou les images ; * la suppression d’éléments parasites (pieds de page, numéros de page, artefacts). Cette phase permet **d'obtenir un corpus textuel propre et exploitable.** 2. **Chunking : ****découper les textes** Les modèles de langage ont une limite de contexte : ils ne peuvent pas traiter des documents trop longs en une seule fois.\ \ Il est donc nécessaire de découper les textes en segments (“chunks”). Plusieurs paramètres peuvent être ajustés : * taille des chunks ; * chevauchement entre chunks ; * segmentation par structure (titres, sections). Le chunking est stratégique : un **mauvais découpage peut dégrader** fortement la qualité de la récupération (retrieval). 3. **Embedding : ****transformer et stocker le texte en représentation vectorielle** Chaque chunk est ensuite transformé en vecteur numérique (embedding), c’est-à-dire une représentation mathématique du contenu sémantique. Deux textes proches en sens auront des vecteurs proches dans l’espace vectoriel. * Un modèle d’embedding est utilisé. * Le choix du modèle peut influencer significativement la qualité de la récupération (retrieval). Chaque chunk est stocké sous la forme : texte original + vecteur associé Ces paires sont enregistrées dans une **base appelée vector store**, optimisée pour les recherches par similarité. Cette étape est une étape cœur du mécanisme de recherche documentaire. À l'issue de ces trois étapes, les données sont exploitables par le système de recherche. {% hint style="info" %} L'ensemble des étapes de transformation de la donnée peut être effectué via [Albert API](https://albert.sites.beta.gouv.fr/access/), plateforme interministérielle d'inférence. Pour le modèle d'embedding, Albert API propose un seul modèle par défaut. \ \ Des outils comme *chunk visualizer* (Hugging Face) permettent de comprendre les différents paramètres de chunking et d’analyser l’impact de ces choix.\ \ [Mediatech](https://huggingface.co/collections/AgentPublic/mediatech) propose des jeux de données du service public français vectorisées, prêt à l'emploi pour l'IA. {% endhint %} ### Recherche : récupérer les contenus pertinents L'étape de recherche (retriever) vise à **identifier, dans le corpus vectorisé, les segments de texte les plus pertinents par rapport à la question de l’utilisateur**. Lorsqu’un utilisateur pose une question : * La question est transformée en vecteur (embedding) à l’aide du même modèle utilisé pour les documents. * Le vecteur de la question est comparé à l’ensemble des vecteurs du corpus stockés dans le vector store, via une métrique de similarité. * Les chunks les plus proches, selon la métrique de similarité, sont sélectionnés. 🚧 C’est une étape critique : si les bons documents ne sont pas retrouvés, le modèle de génération ne pourra pas produire une réponse fiable, lors de l'étape suivante. {% hint style="info" %} Cette étape peut également être effectuée via [Albert API](https://albert.sites.beta.gouv.fr/access/) qui propose plusieurs méthode de recherche [Techniques avancées de RAG dans Albert API](/guides/albert-api-rag-techniques-avancees-rerank.md). {% endhint %} ### Réponse : générer la réponse en langage naturel Une fois les documents pertinents identifiés, **la phase de génération consiste à produire une réponse pertinente** : la génération se doit de rester fidèle au corpus sélectionné. La génération de la réponse ne doit pas inventer ce que la recherche n’a pas trouvé. Cette étape repose sur un modèle de langage (LLM), mais son comportement dépend fortement de la manière dont le contexte lui est présenté, contexte qui comprend : * la question utilisateur * le prompt * les chunks récupérés (contexte documentaire) Il n'est pas nécessairement pertinent d'utiliser un "gros" modèle (LLM), plus consommateur d'énergie. Le choix du LLM et de ses paramètres (prompts, températures, et limites de tokens) est à effectuer en perspective du cas d'usage. {% hint style="info" %} Pour la sélection du modèle, le [classement Compar:IA](https://comparia.beta.gouv.fr/ranking) permet de comparer des grands modèles de langage (LLM) sur différents critères d'évaluation. \ \ [Albert API](https://albert.sites.beta.gouv.fr/access/) permet d'accéder à des LLM en SecNumCloud. {% endhint %} ### Interface minimale À ce stade du prototype, une interface minimale suffit généralement, comprenant : * un champ de saisie permettant à l’utilisateur de poser une question en langage naturel ; * l’affichage clair de la réponse générée par le modèle ; * l’affichage des sources utilisées, afin de renforcer la transparence et faciliter la vérification ; * un mécanisme simple de feedback utilisateur (pertinent / non pertinent ou notation, commentaire libre, etc.), indispensable pour alimenter les itérations. L’enjeu est de tester le fonctionnement du système RAG, pas l’expérience utilisateur finale.\ \ Une interface complexe ou trop intégrée peut ralentir l’itération technique et détourner l’attention du véritable enjeu : la qualité de la recherche et de la génération. Il est important de ne pas sur-investir le front-end à cette étape. **Le prototype doit être simple, testable et évolutif. L’optimisation de l’expérience utilisateur viendra dans un second temps, une fois la qualité informationnelle stabilisée.** {% hint style="info" %} Pour cette première version, des solutions simples et rapides à mettre en œuvre sont généralement privilégiées :
\- **Streamlit**, pour créer rapidement une interface web légère. Streamlit est notamment prisé des ingénieurs IA, habitués à l'outil. \ \ \- une **interface sur mesure minimale**, développée rapidement par l’équipe technique si les compétences sont présentes. {% endhint %} ## Infrastructure et hébergement La mise en place d’un prototype RAG ne se limite pas aux briques fonctionnelles (base vectorielle, retrieval, génération, interface). Elle suppose également de **définir un cadre d’infrastructure clair, garantissant la sécurité, la performance et la pérennité du système**. Même si nous préconisons une solution simple lors de la première itération, selon le type d'information que vous traitez, certaines réflexions doivent être anticipées. Plusieurs dimensions doivent être analysées dès le départ : * **Type d’hébergement** : * Cloud public, cloud privé, infrastructure interne (on-premise). * Le choix dépend des contraintes réglementaires, du niveau de sensibilité des données et des pratiques de l’organisation. * **Sécurité et conformité** : * Protection des données (RGPD), gestion des accès, chiffrement des échanges et des données stockées. * Dans certains contextes (administration, secteur réglementé), des exigences spécifiques peuvent s’appliquer dès le démarrage (ex. : SecNumCloud, HDS). * **Latence et performance** : * Le temps de réponse est un facteur clé de l’expérience utilisateur. * Une architecture mal dimensionnée peut dégrader la fluidité des échanges. * **Scalabilité** : * Même si le prototype cible un nombre limité d’utilisateurs, il est utile d’anticiper une montée en charge future. * Les évolutions d’architecture doivent être réfléchies pour éviter de tout reconstruire ou pour avoir une première version temporaire volontairement. * **Coût** : * Les coûts peuvent provenir de plusieurs éléments : * appels API au LLM, * stockage des données, * puissance de calcul, * Un suivi dès le prototype permet d’éviter les mauvaises surprises lors du passage à l’échelle. En phase prototype, l’objectif est de trouver un équilibre entre simplicité et conformité.\ Il ne s’agit pas de construire une architecture définitive, mais de poser des bases suffisamment solides pour tester le système sans compromettre la sécurité ou la conformité réglementaire.
{% hint style="info" %} Selon les contraintes et le niveau de maturité de l’équipe, plusieurs solutions peuvent être mobilisées :
\- **Albert API** : pour accéder à des modèles de langage dans un cadre sécurisé (notamment en environnement SecNumCloud).
\- **Hébergement interne - dans l'environnement de DSI** : pertinent lorsque les données sont sensibles ou que l’organisation impose un hébergement maîtrisé.
\- **Scalingo ou autres PaaS** : solutions simples pour déployer rapidement un prototype web.
\- **Kubernetes** : adapté à des environnements plus structurés ou à des projets visant une montée en charge progressive.\ \ [Portail de l'UGAP](https://www.ugap.fr/cloud-services-d-informatique-en-nuage-c4544324) pour sélectionner un hébergement cloud pertinent {% endhint %} ## Quelques pistes de travail pour l'amélioration Les premières implémentations "naïves" d’un assistant RAG donnent rarement des résultats parfaitement satisfaisants. Un système RAG est une chaîne de traitement composée de plusieurs briques interdépendantes, et chacune d’elles peut être optimisée. Chaque étape du pipeline peut alors faire l’objet d’optimisations ciblées, dont nous donnons quelques exemples de manière non exhaustive pour démarrer. * **Améliorer le traitement des sources** * parsing : convertir les images dans les documents en texte en amont du traitement * chunking : ajouter, grâce à un LLM, du contenu dans les chunks afin d'améliorer leur retrouvabilité * embedding : si l'équipe a accès à des GPU, tester différents modèles d'embedding * **Améliorer le traitement de la question** * "query enhancement" : mécanisme qui retraduit la question de l'utilisateur pour qu'elle devienne plus claire pour la recherche * **Améliorer la recherche** * recherche hybride : combiner recherche vectorielle avec d'autres méthodes de recherche * reranker : mécanisme qui appelle un modèle de rerank pour reclasser les résultats de la recherche dans l'optique d'affiner la pertinence. Cela peut être perçu comme un second filtre sur les données. Ce mécanisme n'est pas applicable sur l'ensemble des données pour des raisons de charge / temps. * **Améliorer la génération de la réponse** * "Fact checking" : mécanisme de vérification de la réponse envoyée avec un modèle LLM. Un second LLM vérifie la qualité de la réponse générée. Le besoin d'amélioration provient d'une analyse des réponses via notamment la mise en place de l'évaluation des composants. Ces évaluations vont aiguiller les travaux nécessaires à l'amélioration du système. ## Dès la première itération : penser évaluations La qualité de l'expérience utilisateur dépend directement de la **capacité à générer une réponse pertinente, fiable, adéquate** aux questions des utilisateurs. Après avoir démarré sur une approche "naïve", c'est à dire après avoir assemblé naïvement les différents composants techniques nécessaires, la conception d’un assistant RAG performant repose sur un **cycle structuré d'évaluations**, couvrant à la fois ces composants techniques et les usages métiers. Il existe des métriques statistiques "classiques" qui permettent d'évaluer la qualité d'une réponse grâce à la distance sémantique de deux réponses. Hors ces métriques peuvent montrer des limites sur l'évaluation des réponses issues d'un système RAG comme le montre l'exemple ci-dessous. **Question : Je dois refaire ma carte d'identité après une perte. Combien cela va-t-il me coûter ?** {% columns %} {% column %} ***Réponse A***\ *En cas de perte, le renouvellement de la carte nationale d’identité coûte **25**** ****€**, à payer sous forme de timbre fiscal (achat possible en ligne ou chez certains buralistes).* *Cas où c’est gratuit :* * *Première demande ou renouvellement avec l’ancienne carte présentée : gratuit.* * *Le paiement est dû uniquement parce que la carte est perdue (ou volée) et donc non restituée.* *Il est également nécessaire de faire la déclaration de perte (en mairie, commissariat ou gendarmerie selon le cas) avant ou pendant la demande de nouvelle carte.* {% endcolumn %} {% column %} ***Réponse B***\ *En cas de perte, le renouvellement de la carte nationale d’identité coûte **250**** ****€**, à payer sous forme de timbre fiscal (achat possible en ligne ou chez certains buralistes).* *Cas où c’est gratuit :* * *Première demande ou renouvellement avec l’ancienne carte présentée : gratuit.* * *Le paiement est dû uniquement parce que la carte est perdue (ou volée) et donc non restituée.* *Il est également nécessaire de faire la déclaration de perte (en mairie, commissariat ou gendarmerie selon le cas) avant ou pendant la demande de nouvelle carte.* {% endcolumn %} {% endcolumns %} Dans cet exemple, les réponses sont sémantiquement très proches, quasiment identiques. Les métriques statistiques dites "classiques" évalueraient ces réponses comme similaires et potentiellement pertinentes. Hors un caractère essentiel impacte la pertinence de la réponse : le coût est indiqué à 25€ dans la première réponse (vérité), 250€ dans la seconde (erreur). Pour parvenir à une évaluation efficace de la qualité des réponses, deux méthodes, développées dans les pages suivantes, doivent donc être combinées : * [Évaluations référents métiers](/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/evaluations-referents-metier.md): les référents métier évaluent les critères de qualité (la pertinence, la clarté, fidélité, sources,...) * [​Évaluations automatisées](/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/evaluations-automatisees.md) (LLM-as-a-judge) : Un juge LLM évalue la qualité des réponse selon les critères définis. En parallèle, lors de la mise en production, d'autres métriques permettront d'évaluer en temps réel les tendances d'usage des utilisateurs (notation, clics, adoption,...) et les performances de l'outil (latence, consommation énergétique, sécurité...). **🚧 ****Sans une évaluation rigoureuse et continue, l'assistant conversationnel peut:** * répondre à côté (documents non pertinents ou mal récupérés) ; * ou halluciner (génération incorrecte ou non sourcée) ; * ou produire des réponses incohérentes, sensibles ou dangereuses, posant des problèmes de confiance, de sécurité ou de conformité. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://guides.ia.numerique.gouv.fr/guides/guide-de-construction-dun-assistant-conversationnel-base-sur-du-rag/prototypage.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.