Construire un pipeline RAG pour exploiter les données ouvertes avec un LLM
Les portails de données ouvertes comme CKAN regorgent de jeux de données précieux — CSV, JSON, PDF, métadonnées descriptives. Mais interroger ces données reste souvent fastidieux : il faut connaître le bon jeu de données, le bon champ, le bon filtre. Et si un assistant IA pouvait répondre directement à vos questions en s’appuyant sur ces données ? C’est exactement ce que permet un pipeline RAG (Retrieval-Augmented Generation).
Qu’est-ce que le RAG ?
Le RAG est une architecture qui enrichit les réponses d’un modèle de langage (LLM) en lui fournissant du contexte issu de documents externes au moment de la requête. Plutôt que de se fier uniquement à ce que le modèle a appris lors de son entraînement, le RAG va chercher les passages les plus pertinents dans une base documentaire, puis les injecte dans le prompt envoyé au LLM. Le résultat : des réponses factuelles, sourcées et à jour.
Cette approche résout deux problèmes majeurs des LLM : les hallucinations (le modèle invente des faits) et l’obsolescence (le modèle ne connaît pas les données récentes). En connectant un LLM à un portail de données ouvertes, on obtient un assistant capable de répondre avec les chiffres réels, les dernières mises à jour, et les sources vérifiables.
Architecture d’un pipeline RAG pour l’open data
Un pipeline RAG typique pour des données ouvertes se compose de quatre étapes principales.
1. Ingestion des données. Les jeux de données sont récupérés depuis l’API CKAN (action package_search, datastore_search) ou téléchargés directement. Les fichiers CSV sont parsés, les PDF sont extraits via OCR si nécessaire, et les métadonnées (titre, description, organisation, date de mise à jour) sont conservées comme contexte additionnel.
2. Découpage et vectorisation. Les documents sont découpés en chunks (fragments) de taille contrôlée — typiquement 500 à 1000 tokens avec un chevauchement de 100 à 200 tokens. Chaque chunk est ensuite transformé en vecteur (embedding) à l’aide d’un modèle comme sentence-transformers/all-MiniLM-L6-v2 ou, pour le français, camembert-base. Ces vecteurs capturent le sens sémantique du texte.
3. Stockage dans une base vectorielle. Les embeddings sont indexés dans une base vectorielle comme ChromaDB, Qdrant ou pgvector (extension PostgreSQL). Le choix de pgvector est particulièrement intéressant si votre infrastructure utilise déjà PostgreSQL pour CKAN — un seul moteur de base de données pour tout gérer.
4. Requête et génération. Lorsqu’un utilisateur pose une question, celle-ci est vectorisée avec le même modèle d’embedding, puis comparée aux vecteurs stockés pour retrouver les chunks les plus proches (recherche par similarité cosinus). Ces chunks sont injectés dans le prompt du LLM, qui génère une réponse contextualisée et sourcée.
Exemple concret : un assistant pour les données territoriales
Imaginons un portail open data régional contenant des jeux de données sur les transports, la qualité de l’air, les équipements publics et le budget des collectivités. Avec un pipeline RAG, un citoyen pourrait poser des questions comme :
« Quel est le budget d’investissement de la métropole pour 2025 ? »
« Quelles sont les lignes de bus les plus fréquentées ? »
« Comment a évolué la qualité de l’air dans le centre-ville ces trois dernières années ? »
L’assistant irait chercher les données pertinentes dans la base vectorielle, les transmettrait au LLM, et fournirait une réponse claire avec la source exacte (nom du jeu de données, date de dernière mise à jour, lien vers le portail).
Stack technique recommandée
Pour un déploiement auto-hébergé et souverain, voici une stack cohérente : CKAN comme source de données, Python avec LangChain ou LlamaIndex pour l’orchestration du pipeline, pgvector pour le stockage vectoriel (réutilisant le PostgreSQL existant), Ollama pour exécuter un LLM en local (Mistral, Llama 3 ou un modèle fine-tuné pour le français), et un modèle d’embedding open source hébergé localement.
L’avantage de cette approche : aucune donnée ne quitte votre infrastructure. Les données ouvertes restent sur vos serveurs, le LLM tourne en local, et les embeddings sont stockés dans votre propre base PostgreSQL. C’est un point crucial pour les collectivités et organisations publiques soumises à des contraintes de souveraineté numérique.
Bonnes pratiques pour un RAG efficace
La qualité d’un pipeline RAG dépend largement de la qualité de l’ingestion. Quelques recommandations : nettoyer les données avant l’indexation (supprimer les lignes vides, normaliser les encodages), enrichir chaque chunk avec ses métadonnées (source, date, organisation productrice), mettre en place une synchronisation régulière avec l’API CKAN pour refléter les mises à jour des jeux de données, et tester la pertinence des résultats avec un jeu de questions-réponses de référence.
Il est également important de gérer les cas limites : que faire quand aucun document pertinent n’est trouvé ? Le LLM doit être instruit de répondre honnêtement qu’il n’a pas trouvé l’information plutôt que d’inventer une réponse. Un seuil de similarité minimum (par exemple 0.7) permet de filtrer les résultats trop éloignés de la question.
Perspectives
Le RAG appliqué aux données ouvertes ouvre des perspectives considérables pour la démocratie numérique : rendre les données publiques véritablement accessibles à tous, sans compétence technique préalable. Couplé à un MCP server (Model Context Protocol), ce pipeline peut être exposé comme un outil pour des agents IA, permettant à des systèmes multi-agents d’interroger automatiquement les données publiques dans le cadre de workflows plus complexes.
L’enjeu n’est plus de publier des données ouvertes, mais de les rendre réellement utilisables. Le RAG est une des clés pour y parvenir.
