Les embeddings, expliqués à une direction

Un moteur de recherche classique cherche des mots. Si le document dit « congés payés » et que la question dit « vacances », il ne trouve rien.

Un embedding transforme chaque morceau de texte en une position dans un espace, de telle sorte que deux textes qui parlent de la même chose se retrouvent voisins, même s'ils n'emploient aucun mot commun. Chercher revient alors à regarder ce qui se trouve à proximité de la question.

C'est tout. La conséquence pratique, elle, mérite plus d'attention.

La recherche par proximité rate ce qui se cherche par le mot exact : une référence de contrat, un code article, un nom propre rare. La recherche par mots-clés, elle, rate les reformulations.

Les deux ensemble couvrent l'essentiel des cas. C'est un peu plus de travail à la mise en place, et c'est ce qui évite la classe d'erreurs la plus embarrassante : le système qui ne retrouve pas un document dont l'utilisateur vient de citer la référence exacte.

Aucun modèle d'embedding ne compense un corpus mal tenu. Si trois notes se contredisent, la recherche en trouvera une, et ce sera peut-être la mauvaise.

C'est le point que je répète le plus en cadrage, et qui ramène systématiquement au même endroit : le corpus est le projet.

Une recherche par le sens échoue systématiquement sur les références exactes : numéros d'article, codes produit, identifiants de dossier. C'est la limite à poser en même temps que le principe, faute de quoi elle est découverte en production.

Le mécanisme est direct : « 12.3 » et « 12.4 » ont un sens presque identique pour un modèle d'embarquement. La distinction qui compte pour l'utilisateur est précisément celle qu'il ne fait pas.

La correction tient en une journée de travail et consiste à ajouter un index par mots-clés à côté de l'index par le sens, comme décrit dans recherche hybride.

Changer de modèle d'embarquement impose de réindexer entièrement le corpus, ce qui en fait la décision la moins réversible de toute la chaîne. Elle mérite donc d'être instruite au cadrage.

Deux points se vérifient avant de choisir : le comportement sur vos propres paires de langues si le corpus n'est pas monolingue, et la stabilité du fournisseur, une dépréciation forçant la réindexation.

Un corpus francophone contenant des documents techniques en anglais, la norme en informatique, en pharmacie et en aéronautique, relève déjà de ce cas. La démarche de vérification est décrite dans construire un jeu de tests en une journée.

La recherche par le sens est un composant à part entière, avec son propre coût, sa propre qualité et sa propre décision de fournisseur. Ce n'est pas un détail d'implémentation.

La conséquence pratique est qu'elle doit apparaître dans le dossier au même titre que le modèle de génération : quel fournisseur, quelle version, quelle langue vérifiée, quelle date de réindexation.

Cette information a une valeur qui dépasse la technique : elle permet de diagnostiquer, deux ans plus tard, pourquoi le système répond moins bien qu'avant. Le format de cette documentation figure dans écrire la fiche d'un système d'IA.

Comprendre que la recherche par le sens est un composant distinct permet à une direction de trancher trois questions qu'elle laissait sinon à l'équipe technique. Ce sont des questions de risque, pas d'implémentation.

La première porte sur la langue : si le corpus contient des documents en anglais et que les utilisateurs interrogent en français, cela doit être vérifié avant la mise en service, pas découvert après.

La deuxième porte sur la réversibilité : un changement de fournisseur d'embarquement impose une réindexation complète, ce qui doit apparaître dans l'analyse de dépendance.

La troisième porte sur les références exactes : un corpus réglementaire ou contractuel exige un index par mots-clés en complément, faute de quoi les questions les plus précises recevront les réponses les plus approximatives. Ces trois points relèvent du dossier décrit dans ce qui doit exister avant l'échéance.