La recherche hybride : pgvector + FTS + trigram + RRF

Le problème : « BOUL. INOX 50MM x100 » → quel produit ?

Une ligne de commande arrive salie : abréviations, fautes, références partielles. Le retrouver dans un catalogue de dizaines de milliers de variants est un problème de recherche, pas de classification. Aucune technique seule ne suffit — le projet en fusionne quatre, toutes dans PostgreSQL :

Les embeddings : Cohere embed-multilingual (1024 dim), une colonne vector(1024) par variant, avec le bon input_type (search_document à l'indexation, search_query à la requête — l'asymétrie compte).

La fusion : Reciprocal Rank Fusion

Comment combiner quatre listes aux scores incomparables (un ts_rank_cd et un cosinus ne se comparent pas) ? RRF ne regarde que les rangs :

score(candidat) = Σ sur chaque source :  1 / (60 + rang_dans_la_source)

Un candidat bien classé dans plusieurs sources monte — robuste, sans normalisation de scores, sans réglage. C'est la même fusion que tu as croisée au cours ML (recherche d'entreprise) — ici en pur SQL applicatif.

Après le retrieval : scoring métier et deep match

Les candidats passent ensuite un scoring 5 dimensions (id, marque, texte, catégorie, spécifications) pondéré, avec deux règles dures : le golden match (référence exacte → score 1, on ne discute pas) et le brand veto (mauvaise marque explicite → éliminé). Si le meilleur score reste sous le seuil, le deep match s'enclenche : un petit LLM (Haiku) réécrit la requête en ~3 variantes → nouveaux candidats → re-rank Cohere (cross-encoder) → décision. Le LLM n'intervient qu'en dernier recours : la voie rapide est du pur PostgreSQL à quelques millisecondes.