Lorsque la récupération RAG déçoit, on dit aux ingénieurs d' 'ajouter un réordonnanceur'. Mais les explications restent souvent au niveau architectural—en l'appelant cross-encoder, mécanisme d'attention ou modèle entraîné sur la pertinence—sans révéler ce que le modèle a réellement appris. Ce vide importe : les équipes ne peuvent pas justifier l'utilisation d'un réordonnanceur ou repérer quand une recherche de mots clés moins chère suffirait.

La réponse honnête est que le réordonnanceur n'est pas plus intelligent que l'étape d'embeddings en dessous. Il utilise la même association statistique de tokens issue des données d'entraînement, simplement conditionnée sur la paire requête-passage plutôt que sur des textes indépendants. Une fois compris, la décision d'utiliser un réordonnanceur passe de 'parce que le tutoriel le dit' à 'uniquement quand cet échange spécifique vaut le coup'.

L'article passe en revue le mécanisme : un réordonnanceur est un transformer (cross-encoder) entraîné sur des étiquettes de pertinence, produisant un score basé sur la co-occurrence de tokens, pas sur une vraie compréhension. Il met en évidence trois conséquences architecturales pour les systèmes RAG d'entreprise. Un carnet compagnon permet aux utilisateurs de tester le réordonnanceur sur des PDFs, montrant quels mots-clés génèrent le classement.

Cet article est la Partie I de la série Enterprise Document Intelligence, aux côtés du triptyque d'embeddings (2A/2B/2C), et s'appuie sur le cadre Prompt, Context, Loop.