BM25, recherche vectorielle et reranking : quel pipeline RAG pour les documents professionnels français ?

Dossier d’architecture appliquée — sources vérifiées le 21 juillet 2026

Résumé exécutif

BM25, recherche vectorielle et reranking répondent à des erreurs différentes. BM25 valorise les termes précis, références et acronymes ; les embeddings rapprochent des formulations sémantiquement voisines ; la fusion augmente la couverture ; le reranker réordonne un pool déjà récupéré. Empiler ces composants ne garantit pas un meilleur résultat. Un reranker ne peut pas retrouver un passage absent du pool, et une fusion mal calibrée peut faire reculer une référence exacte. Pour les documents professionnels français, la bonne démarche est une campagne d’ablation sur plusieurs familles de textes et de questions.

Le problème à résoudre

Les pipelines RAG sont souvent copiés depuis un exemple sans mesurer chaque étage. L’équipe change simultanément le chunking, les embeddings, le top-k et le reranker, puis attribue le gain au dernier composant ajouté. Cette absence d’ablation empêche d’expliquer les coûts et les régressions.

Cette question doit être traitée comme une décision d’architecture et d’exploitation. Un composant impressionnant en démonstration peut rester inutilisable si les droits, la reprise, les coûts et les preuves sont implicites. À l’inverse, une première version bornée peut produire de la valeur si son périmètre est clair et si ses résultats sont mesurés.

Pour qui et pour quelle décision ?

• développeurs RAG
• équipes knowledge management
• architectes de Knowledge Base
• organisations avec corpus français

Le lecteur ne doit pas seulement comprendre la technologie. Il doit pouvoir décider s’il faut lancer un audit, établir une baseline, construire une preuve de concept, organiser un pilote ou écarter l’approche lorsque les prérequis ne sont pas réunis.

Architecture de référence

BM25

Recherche lexicale robuste pour identifiants, articles, acronymes et formulations exactes.

Vecteurs

Récupération sémantique utile lorsque la question paraphrase le document.

Fusion

Combinaison normalisée ou Reciprocal Rank Fusion des deux classements.

Pool

Top-k suffisamment large pour préserver les candidats avant reranking.

Reranker

Score croisé requête-passage plus coûteux mais plus précis sur un petit ensemble.

Contexte

Sélection finale tenant compte des doublons, droits, diversité et budget de tokens.

L’intérêt de cette décomposition est de rendre les responsabilités remplaçables et testables. Le domaine métier ne doit pas dépendre d’un fournisseur, d’un modèle ou d’une interface unique. Les adaptateurs peuvent évoluer, tandis que les règles de données, de preuve et de décision restent stables.

Fonctionnement opérationnel

1. Créer des questions lexicales, paraphrasées, multi-documents et négatives.
2. Conserver le même corpus et le même chunking pour comparer les retrievers.
3. Mesurer BM25 et vectoriel séparément avant la fusion.
4. Tester plusieurs tailles de pool pour le reranker.
5. Analyser les passages gagnés et perdus, pas uniquement le score global.
6. Choisir la configuration par famille de requêtes si un pipeline unique n’est pas optimal.

Chaque étape doit produire un état observable. Une décision sans version de politique, un appel sans identifiant de trace ou une mise à jour sans rollback ne peut pas être considérée comme une capacité maîtrisée.

Sécurité et gouvernance

Les contrôles prioritaires sont les suivants :

• filtrage ACL avant toute récupération
• suppression des contenus non autorisés avant fusion
• contrôle de provenance après reranking
• corpus de test ne contenant pas de données sensibles
• version des modèles d’embedding et reranking
• détection des documents dupliqués ou empoisonnés

La sécurité ne doit pas être résumée à une liste de fonctionnalités. Elle doit être vérifiée par des scénarios négatifs : permission absente, donnée interdite, outil indisponible, secret expiré, résultat ambigu, interruption et reprise.

État de maturité

Ce qui existe, ce qui reste à prouver

Disponible

• architecture BM25 + PGVector + reranking documentée
• Tika pour l’extraction et SearXNG pour la recherche externe
• modèles locaux possibles via Ollama ou bibliothèques dédiées

Expérimental

• benchmark français par ablation
• explorateur de classements
• calibration de la fusion

Planifié

• corpus technique, administratif et métier public
• mesures CPU/GPU
• tests de dérive lors des mises à jour

Non couvert

• meilleure configuration universelle
• gain public chiffré
• preuve sur tous les formats français

Preuves et prudence

Registre de preuves

Élément	Statut	Interprétation
Pipeline hybride	partiel	Le dépôt privé confirme l’infrastructure RAG et les composants associés ; la chaîne active BM25-vecteurs-reranking et la valeur de chaque étage doivent encore être vérifiées par ablation.
Reranking	à mesurer	Le gain dépend de la couverture du pool et du type de requête.
Corpus français	cible	Il doit couvrir plusieurs vocabulaires, structures et tailles de documents.
Performance	à mesurer	Latence, mémoire et débit doivent accompagner les métriques de pertinence.

Cas d’usage pertinents

• retrouver une référence réglementaire exacte
• rapprocher une question métier d’une formulation différente
• chercher un incident dans une documentation technique
• combiner notes internes et sources publiques
• expliquer au lecteur pourquoi un chunk a changé de rang

Ces cas d’usage ne constituent pas des promesses de résultat. Ils indiquent où un atelier ou un pilote peut produire une preuve utile sans engager immédiatement une transformation globale.

Protocole d’évaluation proposé

1. figer corpus, chunks et golden passages
2. exécuter BM25 seul et vectoriel seul
3. tester plusieurs méthodes de fusion
4. faire varier top-k avant reranking
5. calculer recall@k, MRR et nDCG
6. mesurer latence et mémoire
7. publier les requêtes où chaque méthode gagne ou échoue

Les résultats doivent inclure les échecs et les régressions. Une configuration ne doit pas être promue parce qu’elle améliore une moyenne si elle dégrade un scénario critique ou contourne une contrainte de données.

De la preuve au pilote

Le passage à un pilote ne devrait intervenir qu’après la production d’une baseline et d’un registre des hypothèses encore ouvertes. Le premier périmètre doit rester assez petit pour que chaque entrée, décision et sortie puisse être inspectée. Il est préférable de couvrir un cas d’usage réel avec quelques utilisateurs et des critères d’acceptation explicites plutôt que d’ouvrir immédiatement la solution à toute l’organisation.

Le pilote doit produire des actifs réutilisables : jeu de tests, architecture observée, matrice de permissions, dictionnaire de métriques, runbook d’incident et procédure de retour arrière. Ces livrables permettent de décider si le système doit être étendu, corrigé, suspendu ou abandonné. Ils évitent aussi de dépendre d’une démonstration ponctuelle difficile à reproduire.

La valeur commerciale se construit donc autour d’un engagement progressif : audit, atelier, benchmark, preuve de concept puis pilote borné. Les prestations proposées dans cet article ne supposent pas que toutes les capacités sont déjà industrialisées ; elles organisent précisément le travail nécessaire pour transformer une architecture en résultat vérifiable.

Limites et risques résiduels

• Les scores BM25 et vectoriels ne sont pas directement comparables sans normalisation.
• Le reranker augmente la latence et peut déplacer un passage correct.
• Les embeddings multilingues ne garantissent pas la meilleure qualité sur un domaine français précis.
• Le chunking peut dominer les résultats du retrieval.
• Une source web fraîche peut être moins fiable qu’un document interne validé.

Cette transparence protège le lecteur et le projet. Elle évite de confondre une architecture cible, un composant disponible et une capacité démontrée dans des conditions reproductibles.

Questions fréquentes

Sources et méthode

Les sources ci-dessous sont officielles ou primaires. Elles soutiennent le cadre d’architecture et d’évaluation ; elles ne prouvent pas à elles seules la maturité des projets présentés.

• Microsoft GraphRAG — basic search
• PostgreSQL text search
• Ollama API

Le dépôt privé GitHub TheWatcher01/knowledge_base_v2, branche main, a été vérifié le 21 juillet 2026. Son README et son arborescence confirment l’architecture Next.js/FastAPI, PostgreSQL/PGVector, MongoDB, Tika, SearXNG, Ollama et Docker Compose. Les métriques de qualité, l’isolation et les flux end-to-end restent soumis aux protocoles décrits.