Cohere conserve 98,4 % de la qualité de recherche avec des requêtes rapides

Les systèmes RAG présentent un problème d’ingénierie bien connu : la recherche vectorielle rapide rassemble efficacement des candidats, mais fait régulièrement remonter des passages similaires par les mots plutôt que par le sens de la question. S’ils sont immédiatement transmis au modèle de langage, celui-ci reçoit du contexte superflu, consomme davantage de tokens et risque plus fortement de produire une réponse assurée, mais incorrecte.

Cohere a lancé Embed 5 et Rerank 5 sur OpenRouter. L’intérêt pratique de cette sortie ne réside pas simplement dans l’ajout de deux noms au catalogue de modèles. Il devient possible de construire, à travers une seule API, un pipeline de recherche complet : créer un index vectoriel, trouver des candidats, les reclasser avec davantage de précision, puis seulement appeler le LLM. Aucun compte ni SDK Cohere distinct n’est nécessaire.

Comment le travail est réparti

L’indexation est effectuée une seule fois pour l’ensemble du corpus documentaire. Le texte est découpé en passages, puis Embed 5 Pro convertit chacun d’eux en vecteur. Le mode search_document est indiqué pour les documents, et les vecteurs sont normalisés afin que leur proximité puisse être calculée avec un simple produit scalaire.

Lorsqu’un utilisateur envoie une requête, Embed 5 Fast fonctionne en mode search_query. Pro et Fast partagent le même espace vectoriel, il n’est donc pas nécessaire de reconstruire l’index. Selon Cohere, les requêtes Fast exécutées sur un index créé avec Pro ont conservé 98,4 % de la qualité d’une configuration entièrement fondée sur Pro, sur 40 jeux de données. Lorsque Fast est utilisé à la fois pour l’indexation et pour la recherche, ce taux descend à 96,6 %.

Imaginons une base documentaire contenant des instructions sur la création, la révocation et le remplacement de clés API. Un utilisateur demande comment remplacer une clé sans interrompre le service. La recherche vectorielle trouve la bonne procédure, mais peut aussi ramener des pages sur la création de clés, les secrets de webhooks et la rotation des journaux. Elles sont proches sur le plan sémantique, sans pour autant répondre à la question.

Pourquoi une deuxième étape est nécessaire

Rerank 5 reçoit la question ainsi qu’environ 10 à 20 passages trouvés, lit intégralement chaque paire et renvoie un classement plus précis. Dans l’exemple de Cohere, la bonne procédure a obtenu un score de 0,808, tandis que deux résultats proches mais inutiles n’ont pas franchi le seuil de 0,3. Seule une sélection nettoyée de trois à cinq passages est envoyée au modèle de langage.

Cette répartition est logique : la recherche initiale vise le rappel, tandis que le reranker vise la précision. Exécuter une comparaison lourde sur l’intégralité de l’index coûterait trop cher, mais relire une courte liste de candidats reste tout à fait réaliste. Si le filtrage ne laisse aucun résultat, l’appel au LLM peut être entièrement évité et le système peut indiquer honnêtement que la réponse ne figure pas dans les documents.

Cohere affirme également que les scores de Rerank 5 sont calibrés entre les requêtes et les domaines. Cela permet d’utiliser un seuil de pertinence unique. Il ne faut toutefois pas considérer 0,3 comme un réglage universel : le seuil présenté dans la démonstration doit être vérifié sur vos propres données.

Points à prendre en compte avant le déploiement

La démonstration utilise NumPy comme stockage ; elle convient donc à un prototype, pas à une charge de production. Un système opérationnel nécessitera pgvector, Qdrant, Pinecone, Weaviate ou une autre base vectorielle, ainsi qu’un contrôle des versions de l’index et une observabilité portant sur la latence, le coût et la qualité des résultats.

La taille des passages influe également sur le résultat. Des passages trop courts perdent leur contexte ; des passages trop longs augmentent le coût du reclassement. Les 1 500 caractères indiqués dans l’exemple ne constituent qu’un point de départ. Rerank 5 prend en charge jusqu’à 32 000 tokens pour une paire composée de la requête et du passage, mais une grande fenêtre contextuelle ne rend pas automatiquement utiles les grands passages.

L’étape pratique suivante consiste à recueillir plusieurs dizaines de questions réelles d’utilisateurs, à annoter manuellement les documents corrects et à comparer la proportion de résultats pertinents dans les cinq premières positions avant et après le reclassement. Il faut simultanément mesurer la latence et le coût supplémentaires. Si la qualité progresse sensiblement, la combinaison de Pro pour l’index, Fast pour les requêtes et Rerank pour la sélection finale offre une méthode claire pour accélérer le RAG sans reconstruire entièrement le système.