Le RAG a une réputation de sujet réglé. On découpe des documents, on calcule des embeddings, on stocke, on cherche, on injecte dans le prompt. En démonstration, ça marche presque toujours.
En production sur un catalogue marchand, ça casse à des endroits précis et reproductibles. Voici lesquels, et ce qui tient à la place.
Deux sources, deux natures
L'erreur de départ consiste à traiter le catalogue et le métier comme un seul corpus. Ce sont deux choses différentes.
Le catalogue est volatile, structuré, propre au marchand. Il change tous les jours. Il contient des identifiants, des nombres, des variantes.
La connaissance métier est stable, discursive, partagée par tout un secteur. Elle contient des règles, des seuils, des exceptions. Elle ne change pas quand un stock bouge.
Les mélanger produit deux dégâts. Le métier se retrouve périmé à chaque resynchronisation, et le produit se retrouve noyé dans de la prose qui dilue la recherche.
| Catalogue marchand | Connaissance métier | |
|---|---|---|
| Fréquence de changement | Quotidienne | Rare |
| Structure | Champs typés | Texte structuré |
| Portée | Un marchand | Un secteur entier |
| Découpage | Par référence | Par règle |
| Source de vérité | La boutique | L'expert |
Le découpage : là où presque tout se joue
Un découpage naïf en tranches de mille caractères fonctionne sur de la documentation. Sur un catalogue, il détruit l'information.
Il coupe au milieu d'un tableau de variantes. Il sépare un produit de sa compatibilité. Il crée des morceaux qui contiennent trois demi-produits et aucun entier.
Pour un catalogue, le découpage utile est une référence, un document, avec ses variantes attachées et ses attributs préservés comme métadonnées plutôt que noyés dans le texte. Cela permet ensuite de filtrer avant de chercher, ce qui change tout.
Pour la connaissance métier, l'unité n'est pas la page, c'est la règle. Une règle de compatibilité doit rester entière, avec ses conditions et ses exceptions, sinon la moitié qui survit devient dangereuse. Une exception coupée de sa règle produit exactement le type de réponse qui fait vendre un produit inadapté.
La fraîcheur : ne jamais lire un prix dans un index
C'est le piège le plus coûteux, parce qu'il ne se voit pas en recette.
Si le prix et le stock sont stockés dans l'index vectoriel, votre assistant annonce des prix périmés à chaque décalage de synchronisation. Le client voit un prix dans la conversation, un autre sur la fiche, et vous perdez la vente et la confiance.
La règle est simple : l'index sert à trouver un produit, pas à en lire l'état. Une fois la référence identifiée, prix et disponibilité se lisent au plus près de la réponse, depuis la source qui fait autorité.
La recherche : le vectoriel seul ne suffit pas
La recherche vectorielle est bonne pour rapprocher des formulations différentes du même besoin. Elle est mauvaise sur trois choses que le e-commerce produit en permanence.
- Les références exactes. Un client qui tape une référence attend cette référence, pas quelque chose de sémantiquement voisin.
- Les nombres. « 800 L/h » et « 400 L/h » sont très proches vectoriellement et très différents en pratique.
- La négation. « sans BPA » et « avec BPA » se ressemblent beaucoup pour un modèle d'embedding.
D'où la recherche hybride : une composante lexicale qui attrape l'exact, une composante vectorielle qui attrape l'intention, et une fusion des deux. Ajoutez un filtrage sur les métadonnées avant la recherche, pour ne chercher que dans le sous-ensemble pertinent, et la qualité monte nettement.
L'abstention : la partie que personne n'implémente
Le vrai différenciateur d'un système de production n'est pas ce qu'il répond, c'est ce qu'il refuse de répondre.
Trois situations imposent l'abstention.
- La recherche ne remonte rien de pertinent. Le réflexe du modèle est de combler avec ce qu'il « sait ». C'est là que naissent les références inventées.
- La question sort du périmètre. Un conseil médical, juridique ou de sécurité doit être décliné, quelle que soit la confiance apparente.
- Les informations manquent pour trancher. La bonne réponse est alors une question, pas une recommandation.
Techniquement, cela demande un seuil de pertinence explicite sous lequel on ne génère pas, et une instruction qui autorise le refus. Ce sont quelques lignes. Presque personne ne les écrit, parce qu'elles font baisser le taux de réponse, qui est la métrique que tout le monde regarde en premier.
C'est une erreur de mesure. Un taux de réponse de 100 % sur un catalogue technique signifie que le système invente.
Ce qu'il faut mesurer
Quatre indicateurs suffisent pour savoir si votre RAG tient.
- Le taux d'abstention. Trop bas, il invente. Trop haut, la connaissance manque.
- Le taux de citation. Quelle proportion de réponses s'appuie sur un document réellement récupéré.
- La fraîcheur du prix affiché, comparée à la source de vérité.
- Les erreurs critiques : les cas où l'assistant a recommandé quelque chose d'inadapté. Rares, mais chacune coûte cher.
Aucun de ces quatre ne figure dans les tableaux de bord des outils grand public, qui affichent surtout un volume de conversations.
L'architecture qui tient
Résumée en une phrase : deux corpus séparés, un découpage propre à chaque nature, un index qui trouve mais ne fait pas autorité sur l'état, une recherche hybride filtrée, et un droit explicite de ne pas répondre.
Rien là-dedans n'est exotique. Ce qui est rare, c'est de tenir les cinq à la fois, parce que chacun coûte du travail et qu'aucun ne se voit en démonstration.
Si vous voulez le versant amont, pourquoi un assistant limité à vos pages plafonne quoi qu'on fasse, c'est dans cet article. Pour le versant aval, l'intégration réelle sur une boutique, voyez le guide PrestaShop.
Questions fréquentes
Qu'est-ce que le RAG appliqué au e-commerce ?
Une architecture où l'assistant récupère des documents pertinents avant de répondre, plutôt que de s'appuyer sur la mémoire du modèle. En e-commerce, ces documents sont le catalogue du marchand et la connaissance du métier, deux sources de nature très différente.
Pourquoi un chatbot invente-t-il des références produit ?
Le plus souvent parce que la recherche n'a rien remonté de pertinent et que rien n'oblige le modèle à s'abstenir. Un système correct détecte l'absence de résultat et refuse de répondre plutôt que de combler le vide.
Faut-il une base vectorielle pour faire du RAG produit ?
Elle aide sur la reformulation, mais elle est mauvaise sur les références exactes et les nombres. Une recherche hybride, lexicale et vectorielle, donne de bien meilleurs résultats sur un catalogue.
À quelle fréquence resynchroniser le catalogue ?
Les prix et les stocks doivent être lus au plus près de la réponse, pas depuis un index daté. Les descriptions et catégories tolèrent une synchronisation périodique. Traiter les deux au même rythme est l'erreur classique.