Bases de données vectorielles : KPI et valeur

Un modèle d’embedding, comme ceux d’OpenAI, Google, Cohere ou des options open-source comme la famille sentence-transformers, transforme un morceau de texte en une liste de nombres. Les textes ayant un sens similaire finissent proches les uns des autres. La base de données vectorielle répond alors à des questions comme « quels sont les dix articles d’aide les plus proches de cette question client ? » en quelques millisecondes.

Deux choix déterminent la qualité : le modèle d’embedding et la façon dont le contenu est divisé en morceaux avant l’embedding. Un modèle qui gère mal le français récupérera des correspondances faibles pour des requêtes en français. Des morceaux trop longs mélangent plusieurs sujets ; des morceaux trop courts perdent le contexte. Aucun des problèmes n’apparaît comme un message d’erreur. Seule la mesure le révèle.

Créez d’abord un ensemble de test : une liste de requêtes réelles, chacune associée aux documents ou produits qu’un humain reconnaît comme étant des réponses correctes. Cinquante à deux cents requêtes constituent un début raisonnable pour la plupart des cas d’utilisation marketing. Mesurez ensuite le système par rapport à cela.

• Recall at k : part des requêtes où un élément correct apparaît dans les k premiers résultats, souvent k est égal à 5 ou 10.
• Mean reciprocal rank : à quelle hauteur le premier résultat correct apparaît, en moyenne.
• Precision at k : part des k premiers résultats qui sont réellement pertinents.
• Latence au 95e percentile : combien de temps prennent les requêtes lentes, pas seulement la moyenne.
• Coût par millier de requêtes : appels d’embedding, utilisation de la base de données et tout modèle de re-classement.

Relancez l’ensemble de test à chaque fois que vous modifiez le modèle d’embedding, la taille des morceaux ou les paramètres d’index. Un changement qui semble petit dans la configuration peut déplacer le rappel de manière notable dans les deux sens.

Compromis de recherche approximative

La plupart des bases de données vectorielles utilisent des index de voisins les plus proches approximatifs comme HNSW, qui échangent un peu de précision contre de grands gains de vitesse. Des paramètres comme ef_search dans HNSW contrôlent cet équilibre. Mesurez le rappel et la latence ensemble lors du réglage ; maximiser l’un seul nuit généralement à l’autre.

Les métriques techniques convainquent les ingénieurs. Les budgets sont approuvés sur la base de métriques métier. Choisissez celles qui correspondent au cas d’utilisation.

• Recherche sur site : taux de sortie de recherche, taux de zéro résultat, taux de conversion des sessions utilisant la recherche, revenu par session de recherche.
• Assistant RAG : taux de résolution, part des réponses avec une source citée correcte, taux de transfert, taux de contact répété.
• Recommandations : taux de clic sur les articles recommandés, ajout au panier depuis les recommandations, revenu par visiteur par rapport à un groupe témoin.
• Découverte de contenu : pages par session depuis des modules de contenu associé, visites répétées.

Le taux de zéro résultat est une victoire rapide à surveiller. La recherche par mots-clés ne renvoie souvent rien pour les synonymes ou les fautes de frappe. La recherche sémantique devrait réduire cela radicalement. Si ce n’est pas le cas, vérifiez la prise en charge de la langue et si les données produit ont bien été intégrées.

Utilisez deux couches. La couche technique suit le rappel, la latence, le taux d’erreur et le coût, idéalement à partir de la propre surveillance de la base de données plus une exécution planifiée de l’ensemble de test. La couche métier, dans GA4 et Looker Studio ou votre outil BI, suit les métriques de résultats ci-dessus.

Connectez-les avec un événement partagé. Pour la recherche sur site, envoyez un événement GA4 avec la requête, le nombre de résultats et le type de recherche, sémantique ou mot-clé. Cela vous permet de comparer les résultats par type de recherche et de repérer les requêtes où les résultats sémantiques sont moins performants.

Tester uniquement sur des requêtes faciles est le plus courant. Si l’ensemble de test a été écrit par la personne qui a construit le système, il a tendance à refléter le propre libellé du contenu. Extrayez plutôt des requêtes réelles des journaux de recherche et des tickets de support, y compris les fautes de frappe et les langues mélangées.

La deuxième est d’ignorer la fraîcheur. Lorsque les produits sont en rupture de stock ou que les articles sont mis à jour, les embeddings doivent être rafraîchis. Suivez le retard d’index : le temps entre un changement de contenu et son vecteur mis à jour. Un module de recommandation suggérant des produits abandonnés nuit rapidement à la confiance.

La troisième est de sauter une base de référence par mots-clés. La recherche hybride, qui combine la correspondance par mots-clés comme BM25 avec la similarité vectorielle, bat souvent la recherche vectorielle pure pour les noms et codes de produits. Mesurez les deux avant de décider.

Les coûts proviennent de trois endroits : la génération d’embeddings lorsque du contenu est ajouté ou modifié, le stockage des vecteurs et l’exécution des requêtes. Les services gérés comme Pinecone facturent à l’utilisation ou à la capacité ; les options auto-hébergées comme Qdrant ou pgvector transfèrent le coût sur vos propres serveurs et le temps du personnel. À petite échelle, pgvector au sein d’une base de données PostgreSQL existante est souvent la voie la moins chère.

La dimension d’embedding affecte le stockage et la vitesse. Certains modèles actuels permettent de raccourcir les embeddings avec une perte de qualité limitée. Testez une dimension plus petite par rapport à votre ensemble de test avant de payer pour stocker des vecteurs pleine taille pour des millions d’éléments.