Reclassement : la couche que la plupart des systèmes RAG ignorent (et pourquoi cela détruit la précision)

La plupart des implémentations RAG d'entreprise s'arrêtent à la similarité cosinus. Encodez la requête, encodez les documents, trouvez les plus proches voisins, transmettez les k meilleurs au modèle. C'est rapide, simple, et sous-performe systématiquement par rapport à ce qui est possible. La couche manquante est le reclassement — et la différence n'est pas marginale.

Comment fonctionne le RAG de base (et où il accroche)

La récupération RAG standard est un processus en deux étapes : encoder tout dans un espace vectoriel, puis récupérer par proximité. Au moment de la requête, la question de l'utilisateur est encodée à l'aide d'un modèle bi-encodeur. Le système trouve les fragments de documents dont les vecteurs sont les plus proches du vecteur de requête — généralement mesuré par la similarité cosinus — et retourne les k meilleurs résultats comme contexte pour la génération.

Les bi-encodeurs sont rapides parce que les embeddings de requête et de document sont calculés indépendamment. Un index pré-construit de millions de fragments peut être parcouru en millisecondes. Le problème réside dans ce que « le plus proche » signifie réellement dans l'espace d'embedding.

Les embeddings encodent la similarité sémantique — sujets, concepts, vocabulaire. Une requête sur les « clauses de résiliation de contrat » récupérera des documents sur le droit des contrats, les accords juridiques et les procédures de résiliation. Tous sont sémantiquement proches. Aucun ne répond nécessairement à la question. La stratégie de découpage des documents affecte les passages disponibles à la récupération — mais une fois indexés, le classement des résultats est entièrement déterminé par la similarité cosinus, qui est un instrument rudimentaire pour la pertinence.

Pourquoi la similarité cosinus récupère du connexe, pas du pertinent

La similarité sémantique et la pertinence ne sont pas la même chose. Un document sur la formation des contrats est sémantiquement similaire à une requête sur la résiliation des contrats. Ils partagent des concepts, du vocabulaire et un domaine. Un score de similarité cosinus ne les distinguera pas de manière fiable.

Cela compte davantage dans les bases de connaissances d'entreprise qu'il pourrait sembler. Les collections de documents réels contiennent des quasi-doublons, des historiques de versions, des vues d'ensemble générales et des références techniques spécifiques — tous avec des embeddings similaires. Une question sur une révision de politique spécifique récupère souvent la vue d'ensemble générale de la politique parce que leurs embeddings sont plus proches que l'amendement spécifique qui répond réellement à la question.

Résultat : le modèle génère une réponse à partir de documents connexes à la question mais qui ne la traitent pas vraiment. La réponse semble plausible. Elle cite de vrais documents. Elle est fausse.

Ce que fait le reclassement : le scoring par encodeur croisé

Le reclassement est une étape de scoring en second passage qui s'exécute après la récupération initiale. Au lieu de calculer les embeddings de requête et de document indépendamment, un modèle d'encodeur croisé prend la requête et un document candidat en entrée conjointe et évalue leur pertinence ensemble.

C'est cet encodage conjoint qui rend les encodeurs croisés plus précis. Le modèle peut prêter attention à la relation entre des termes de requête spécifiques et des passages de document spécifiques — pas seulement à leur proximité dans l'espace d'embedding. Un encodeur croisé peut distinguer entre « ce document parle de droit des contrats » (haute similarité cosinus) et « ce document répond à la question sur les délais de préavis de résiliation » (score de pertinence élevé de l'encodeur croisé).

Le pipeline devient : encoder → récupérer les 50 meilleurs par similarité cosinus → reclasser les 50 → transmettre les 5 meilleurs au modèle. L'étape de récupération jette un large filet. L'étape de reclassement sélectionne pour la pertinence réelle. Le modèle génère à partir d'un contexte véritablement pertinent.

Les études sur les benchmarks standard de récupération d'information montrent systématiquement que le reclassement améliore le NDCG (Normalized Discounted Cumulative Gain) et le MRR (Mean Reciprocal Rank) de 10 à 30 % par rapport à la récupération bi-encodeur seule. Dans les systèmes RAG d'entreprise avec des bases de connaissances hétérogènes, l'amélioration est souvent plus importante car le bruit de récupération initial est plus élevé.

Le panorama des reclasseurs : API vs. local

Plusieurs solutions de reclassement se sont imposées comme options de production. Cohere Rerank est le reclasseur basé sur API le plus souvent cité — précis, bien benchmarké et facile à intégrer. Voyage AI et Jina AI proposent des services de reclassement similaires basés sur API. Pour les équipes utilisant déjà une infrastructure cloud, ils apportent une précision significative avec une complexité d'intégration minimale.

Le problème pour les déploiements en air-gap est évident : les reclasseurs basés sur API nécessitent un appel sortant. Chaque fragment de document reclassé quitte votre périmètre réseau. Pour les secteurs réglementés, cela annule l'intérêt du déploiement local. Le RAG privé exige que l'ensemble du pipeline — y compris le reclassement — s'exécute dans votre infrastructure.

La solution : un moteur de reclassement local par encodeur croisé fonctionnant entièrement sur site, sans appels API externes. La latence est plus élevée qu'un bi-encodeur seul mais acceptable pour les pipelines de récupération d'entreprise. Les améliorations de précision par rapport à la similarité cosinus pure sont comparables aux reclasseurs basés sur le cloud pour la plupart des cas d'usage.

L'approche Scabera : le reclassement local comme composant de premier plan

Scabera utilise le reclassement local par encodeur croisé comme composant central du pipeline de récupération — pas comme un module optionnel. Chaque requête passe par une récupération vectorielle initiale suivie d'un reclassement par encodeur croisé avant que les meilleurs résultats ne soient transmis au modèle.

Cela compte pour la précision. Cela compte aussi pour la conformité. Le reclassement se produit sur site, dans votre infrastructure, sans dépendance réseau externe. Les documents évalués ne quittent jamais votre environnement. Pour les déploiements RAG d'entreprise dans les secteurs réglementés, c'est la seule architecture qui maintient l'ensemble du pipeline de récupération sous votre contrôle.

Les systèmes RAG de base qui ignorent le reclassement ne laissent pas seulement de la précision sur la table. Ils construisent des pipelines de citations sur une base qui récupère avec assurance mais de manière incorrecte. Dans un contexte d'entreprise où les sorties guident les décisions, ce n'est pas une inefficacité mineure. C'est un problème de fiabilité.