Retour aux projets

RAG / LEGAL · ANALYSE DOCUMENTAIRE

RAG juridique auditable

Moteur de retrieval et de question-réponse sur corpus juridique, conçu pour associer recherche reproductible, réponses sourcées, temporalité et observabilité.

  • Python
  • PySpark
  • BM25
  • Embeddings
  • FastAPI
  • LangChain
  • Langfuse
Période
2025–2026
Type
Architecture RAG & benchmark IR
Rôle
Conception & développement
Corpus
Juridique · structure type Légifrance

VUE D’ENSEMBLE

Comprendre le projet

Contexte

Les corpus juridiques associent texte, versions, statuts et dates. Une recherche utile doit donc retrouver le bon contenu tout en conservant la provenance et le contexte juridique de chaque extrait.

Objectif

Construire une chaîne RAG dont le retrieval peut être mesuré et comparé, puis servir un contexte ou une réponse avec sources, scores et informations de diagnostic.

Notre rôle

Concevoir le pipeline de données Bronze → Silver → Gold, les benchmarks sparse/dense/hybride, le runtime FastAPI, l’orchestration LangChain et l’observabilité Langfuse.

Résultat

Une architecture modulaire permettant de comparer les stratégies de retrieval et de produire des réponses traçables, avec une politique de non-réponse lorsque le contexte est insuffisant.

ARCHITECTURE

Du corpus brut au RAG servi par API

Le schéma synthétise les trois couches de données Bronze / Silver / Gold, la construction des index, l’évaluation du retrieval et le runtime RAG.

Vue d’architecture simplifiée du pipeline RAG juridique. Les blocs distinguent les composants réalisés, les composants prévus et les flux de données.

REPÈRES TECHNIQUES

Les éléments structurants

Bronze → Silver → Gold Pipeline de données déterministe et traçable.
3 stratégies BM25, retrieval dense et fusion hybride RRF.
3 métriques IR Recall@k, MRR et nDCG@k pour comparer les runs.
API + traces FastAPI, request_id, timings et spans Langfuse.

DÉTAILS TECHNIQUES

Architecture et mise en œuvre

Cette partie s’adresse aux visiteurs souhaitant examiner plus précisément la conception Data/IR, le runtime et les mécanismes de qualité du projet.

OFFLINE · DATA / IR

Datalake & Gold data

  • Pipeline déterministe Bronze → Silver → Gold sur corpus juridique XML : catalogage, parsing, normalisation et extraction des identifiants, dates et statuts.
  • Chunking contrôlé avec propagation complète des métadonnées afin de préserver la relation entre les extraits et leurs sources.
  • Production de Parquet pour les benchmarks et analyses, ainsi que de JSONL shardé pour l’indexation et les benchmarks externes.
  • Mapping dédié pour assurer la traçabilité chunk ↔ source.
  • Socle Gold orienté évaluation avec qrels versionnés en YAML et workflow de génération / validation.

RETRIEVAL · ÉVALUATION

Benchmarks sparse, dense & hybride

  • Comparaison reproductible d’un BM25 in-memory, d’un retrieval dense par embeddings et d’une approche hybride utilisant une fusion RRF.
  • Gestion de caches pour les embeddings et les artefacts afin de limiter les recalculs.
  • Analyse de la sensibilité à la volumétrie et à l’empreinte mémoire.
  • Calcul de Recall@k, MRR et nDCG@k, complété par des outils de validation et de diagnostic des runs.
  • Benchmarks Elasticsearch pour comparer une solution indexée externe aux approches in-memory.

ONLINE · RUNTIME

FastAPI, LangChain & observabilité

  • Service FastAPI exposant notamment POST /rag/invoke pour la chaîne complète et POST /rag/context pour le retrieval et la construction du contexte.
  • Endpoints complémentaires de diagnostic : /health, /corpora et documentation API.
  • Orchestration LangChain LCEL : retrieve → déduplication / context builder → politique no-answer → génération LLM optionnelle → post-traitement des sources et timings.
  • Configuration par YAML et variables d’environnement : corpus, paramètres k, type de retriever et filtres peuvent être adaptés sans modifier la chaîne.
  • Cache en mémoire des chaînes et retrievers pour limiter les rechargements Parquet, reconstructions BM25 et cold starts.

QUALITÉ · SÛRETÉ

Temporalité, sources & politique de non-réponse

  • Gestion de la temporalité avec filtre as_of et des statuts juridiques via status_in.
  • Cohérence des versions servies et règles de comparabilité entre les benchmarks.
  • Politique no-answer lorsqu’un contexte est jugé insuffisant afin de limiter les réponses non étayées.
  • Réponses structurées conservant les sources, les chunks et leurs scores.
  • Observabilité Langfuse avec traces/spans retrieve, dedup, no-answer et LLM, corrélées par request_id et complétées par les temps d’exécution.

STACK

Technologies utilisées

  • Python
  • PySpark
  • Parquet
  • JSONL
  • BM25
  • Sentence-Transformers
  • RRF
  • Elasticsearch
  • FastAPI
  • LangChain LCEL
  • Langfuse
  • YAML / ENV