Recherche par image: comment elle fonctionne, et ce que font réellement les moteurs

Dans un catalogue informatique, le problème se présente ainsi. Un client tient en main un bloc d'alimentation, un adaptateur, une équerre de montage. Il n'en connaît pas la dénomination commerciale, il n'a pas la référence, et le flanc de l'appareil ne porte qu'un sigle. Dans votre fiche, ce sigle figure bien, mais le client ne sait pas le lire, et ce qu'il voit - la forme du connecteur, le nombre de vis, le type de fixation - n'est écrit nulle part dans la fiche.

La recherche textuelle, aussi bien configurée soit-elle, n'a ici aucune matière sur laquelle travailler. La question n'est pas faite de mots.

COMMENT UNE IMAGE DEVIENT UN NOMBRE

Le mécanisme est le même que celui de la recherche par le sens, appliqué à un contenu différent.
Un modèle entraîné reçoit une photographie et restitue une liste de nombres, typiquement quelques centaines ou quelques milliers. Cette liste ne décrit pas les pixels: elle décrit le contenu, en ce sens que deux images représentant des objets semblables produisent des listes proches l'une de l'autre, même si les photographies ont été prises avec un éclairage, un fond et un cadrage différents. Proches, ici, a un sens géométrique précis: on mesure la distance entre les deux listes comme on la mesurerait entre deux points.

L'étape qui rend tout cela utile est ailleurs, et c'est le point où il convient de s'arrêter. Certains modèles sont entraînés à produire des listes comparables entre types de contenu différents: la photographie d'un adaptateur et la phrase "adaptateur USB-C vers HDMI" se retrouvent proches dans le même espace. Ce sont ces modèles que l'on appelle multimodaux, où modalité désigne le type de contenu, texte ou image.

C'est une condition, non un détail. Si les photographies sont vectorisées par un modèle et les textes par un autre, les deux listes appartiennent à des espaces différents et les comparer ne produit aucune information: on peut soustraire les nombres, mais le résultat ne signifie rien. Toute installation de recherche par image fonctionne ou ne fonctionne pas selon ce critère.

DEUX QUESTIONS DIFFERENTES, QUE L'ON CONFOND TOUJOURS

Sous l'expression recherche par image se cachent deux besoins distincts, et presque toute la confusion commerciale naît de leur non-séparation.

Le premier est des produits semblables à celui-ci. Le point de départ est un article qui figure déjà dans votre catalogue, avec sa photographie déjà chargée, et le résultat attendu est constitué d'autres articles visuellement apparentés. C'est le bloc qui apparaît sous la fiche. Tout le travail se déroule à l'intérieur du catalogue, à n'importe quel moment, et rien ne provient de l'extérieur.

Le second est le client photographie et cherche. Le point de départ est une image que vous n'avez jamais vue, prise dans des conditions que vous ne maîtrisez pas, et qui doit être comparée au catalogue dans le temps d'une requête.

Ce sont deux problèmes de difficulté très inégale, et les deux moteurs qui suivent en résolvent chacun un entièrement et un seul partiellement.

LA VOIE DE MEILISEARCH

Meilisearch a introduit la recherche multimodale dans la version 1.16 et la déclare encore expérimentale, ce qui signifie qu'elle doit être activée explicitement et que son interface peut évoluer d'une version à l'autre.

Lors de l'indexation, on configure des fragments: on indique au moteur quel champ du document contient l'adresse de l'image, à côté des champs textuels qui étaient déjà vectorisés. Le moteur se charge d'envoyer les uns et les autres au modèle.

Lors de l'interrogation, la photographie voyage dans la requête elle-même, via le paramètre `media`, convertie en base64 de votre côté. Le moteur la vectorise et la compare à l'index exactement comme il le ferait d'une phrase.

Les contraintes déclarées sont au nombre de trois. Le paramètre `media` ne se combine pas avec la transmission directe de vecteurs. Il doit correspondre à un seul fragment de recherche, faute de quoi la requête est rejetée. Et les images doivent être redimensionnées à 1024 pixels de côté au maximum, car au-delà de ce seuil le poids de la requête et le temps de réponse augmentent sans gain de qualité.

Reste une exigence qui pèse sur le projet plus que toutes les précédentes: le modèle multimodal n'est pas inclus. Il faut le prendre chez un fournisseur extérieur, avec son contrat et sa grille tarifaire - la documentation mentionne voyage-multimodal-3 de Voyage AI et Marengo de TwelveLabs - et les modèles textuels d'usage courant ne conviennent pas, puisqu'ils ne lisent que du texte.

LA VOIE D'ALGOLIA

Algolia aborde les deux questions séparément, avec deux produits de maturité inégale.

À la première répond Looking Similar, au sein d'Algolia Recommend, qui n'est pas expérimental. On indique quel champ contient les images, jusqu'à trois, et le service les vectorise pour son propre compte: aucun modèle à se procurer, aucun fournisseur supplémentaire, aucun événement à collecter avant de pouvoir l'utiliser. La limite déclarée est de 500 000 images par entraînement, ce qui pour la plupart des catalogues n'en est pas une. Dès lors, le système sait dire quels produits se ressemblent.

À la seconde question, Algolia ne répond pas par un point d'entrée auquel envoyer une photographie. Le parcours documenté prévoit que l'image du client soit transmise à un service de reconnaissance extérieur, typiquement Google Cloud Vision, qui restitue des étiquettes textuelles; ces étiquettes deviennent ensuite une interrogation textuelle ordinaire. Dans Algolia, l'image, en tant qu'image, n'entre jamais.

CE QUI CHANGE EN PRATIQUE

La différence se mesure à ce qui survit au passage.

Lorsqu'une photographie est traduite en mots, survit ce que le service de reconnaissance dispose d'une étiquette pour nommer. Un adaptateur devient "adapter, cable, electronics": trois mots exacts et insuffisants, qui dans votre catalogue correspondent à quelques milliers d'articles. La forme du connecteur, qui était la seule information discriminante de l'image, n'a pas d'étiquette et cesse donc d'exister. L'avantage est que le résultat est lisible, vérifiable et corrigible: vous pouvez voir quels mots ont été extraits et intervenir.

Lorsque la photographie reste des nombres jusqu'à la comparaison, ces caractéristiques survivent, parce qu'elles n'ont jamais été réduites à un vocabulaire. Le coût est que le parcours devient opaque: un résultat erroné n'a pas de mot à corriger, il a une distance à remesurer, et le diagnostic exige d'autres instruments.

Il existe par ailleurs un poste de coût qui ne figure pas dans les présentations et qu'il faut porter au budget dès la phase de projet. Introduire la recherche par image sur un catalogue existant signifie vectoriser toutes les photographies, et non seulement celles des nouveaux produits, puis recommencer depuis le début à chaque changement de modèle, car des listes produites par des modèles différents ne sont pas comparables entre elles. Sur un catalogue de taille moyenne, c'est une opération de quelques heures et un coût ponctuel modéré; sur un catalogue comptant dix photographies par article, cela devient un poste qu'il vaut mieux estimer avant de signer.
À cela s'ajoute le décompte des pièces. La première voie exige un fournisseur supplémentaire et une fonction que le projet lui-même déclare encore instable. La seconde exige un fournisseur supplémentaire uniquement pour la recherche à partir d'une photographie, tandis que pour les produits semblables elle est incluse et immédiate.

La question à se poser avant de choisir ne porte pas sur le moteur. Elle porte sur celui des deux besoins que votre catalogue doit réellement satisfaire, et sur la capacité de vos photographies à le soutenir: prises de vue homogènes, sujet isolé, un seul cadrage par article. Une installation de recherche par image bâtie sur un fonds photographique hétérogène restitue des résultats hétérogènes, et aucune des deux voies ne corrige cela.