RAG chatbot e-commerce : personnaliser son assistant IA

Un chatbot générique répond avec des formules toutes faites. Il ne connaît pas votre politique de retour à 30 jours, votre guide des tailles pour les manteaux oversized, ni le fait que vos délais de livraison sont de 5 jours ouvrés en période de soldes.

C'est précisément ce problème que le RAG (Retrieval-Augmented Generation) est conçu à résoudre. Et c'est l'architecture que Navi a testée sur son shop de développement pour enrichir les réponses de son assistant avec les documents propres à chaque marchand.

Cet article détaille comment ça fonctionne techniquement, pourquoi ça change quelque chose pour le SAV e-commerce, et où en est l'implémentation aujourd'hui.

Pourquoi un LLM seul ne suffit pas pour un SAV e-commerce

Un grand modèle de langage (LLM) a été entraîné sur des milliards de textes généraux. Il sait rédiger, reformuler, expliquer. Mais il ne sait pas ce que contient votre FAQ produit ni ce que dit votre politique de retour interne.

Quand un visiteur pose une question précise, par exemple : « Est-ce que je peux retourner un article soldé ? », le LLM a deux options mauvaises :

• Inventer une réponse plausible mais fausse (hallucination).

• Répondre de façon générique : « Cela dépend de la politique du marchand ».

Dans les deux cas, l'expérience client est dégradée. Le visiteur repart sans réponse, ou pire, avec une mauvaise information.

Le RAG apporte une troisième option : aller chercher la bonne information dans les documents du marchand avant de répondre.

authentification OTP et accès commandes temps réel

Ce qu'est le RAG, sans le jargon

RAG signifie Retrieval-Augmented Generation. Derrière ce nom technique, il y a une idée simple.

Plutôt que de demander au LLM de tout savoir par coeur, on lui donne accès à une bibliothèque de documents au moment où il répond. Il récupère les passages pertinents, les lit, et construit sa réponse à partir de ce qu'il vient de trouver.

C'est la différence entre un employé qui improvise et un employé qui a les fiches produit sous les yeux.

Les trois étapes du pipeline RAG

1. Ingestion et découpage (chunking)

Le document source (PDF, Markdown, texte brut) est découpé en petits blocs de texte appelés chunks. Chaque chunk fait typiquement 200 à 500 tokens. L'idée est de créer des unités de sens cohérentes, ni trop petites (perte de contexte), ni trop grandes (bruit dans la recherche).

2. Embedding et stockage vectoriel

Chaque chunk est transformé en vecteur numérique par un modèle d'embedding. Ce vecteur encode le sens sémantique du texte. Deux phrases qui disent la même chose avec des mots différents auront des vecteurs proches.

Ces vecteurs sont stockés dans une base de données vectorielle. Navi utilise pgvector, une extension PostgreSQL open source. Pas besoin d'une infra séparée : les vecteurs vivent dans la même base que les données marchands.

3. Retrieval et injection dans le prompt

Quand un visiteur pose une question, la question est elle aussi transformée en vecteur. Navi effectue une recherche de similarité cosinus dans pgvector pour trouver les chunks les plus proches sémantiquement. Ces chunks sont ensuite injectés dans le contexte du LLM avant qu'il génère sa réponse.

Le LLM ne devine plus. Il lit.

documentation officielle pgvector

L'architecture testée sur le shop de développement Navi

Navi a mis en place et testé cette architecture complète sur son shop de développement. Voici comment les composants s'articulent concrètement.

Ingestion des documents marchands

Depuis le dashboard Navi (app.navi.myffu.fr/dashboard), la section Knowledge Base permet d'uploader des fichiers PDF ou Markdown. Ce sont typiquement :

• La politique de retour et d'échange

• Le guide des tailles

• La FAQ produit

• Les conditions générales de livraison

• Tout document interne que le marchand veut rendre accessible à l'assistant

Le pipeline d'ingestion découpe ces fichiers en chunks, génère les embeddings, et stocke le tout dans pgvector associé au shop du marchand. Chaque shop a son propre espace vectoriel isolé.

Le tool search-knowledge

Côté agent, Navi expose un tool appelé search-knowledge. Quand l'assistant détecte qu'une question pourrait trouver sa réponse dans la base de connaissances du marchand, il appelle ce tool avec la question reformulée comme requête de recherche.

Le tool effectue la recherche vectorielle dans pgvector, récupère les N chunks les plus pertinents (typiquement 3 à 5), et les retourne à l'agent sous forme de contexte documentaire.

L'agent construit ensuite sa réponse en citant ou en paraphrasant ce qu'il vient de lire, dans le ton et la langue du visiteur.

Retrieval contextuel pendant la conversation

Un détail important : le retrieval n'est pas déclenché sur chaque message. L'agent évalue d'abord si la question relève d'une donnée transactionnelle (statut commande, suivi, retour) ou d'une question de contenu (politique, guide, FAQ).

Pour les questions transactionnelles, Navi va directement dans l'API Shopify. Pour les questions de contenu, il appelle search-knowledge. Cette logique de routage évite de polluer le contexte avec des chunks inutiles et garde les réponses précises.

flow retours automatisés et accès commandes Shopify

Ce que ça change concrètement pour le SAV

Prenons quelques exemples de questions que reçoit régulièrement un service client e-commerce, et voyons ce que le RAG change.

Exemple 1 : la politique de retour

Sans RAG, la question « Puis-je retourner un article après 30 jours ? » obtient une réponse générique ou une redirection vers la page de politique.

Avec RAG, Navi récupère le chunk exact de la politique de retour du marchand, lit que la fenêtre est de 14 jours pour les articles soldés et 30 jours pour le plein tarif, et répond avec précision. Le visiteur n'a pas besoin de chercher la page.

Exemple 2 : le guide des tailles

Un visiteur hésite entre un M et un L pour une veste. Il pose la question dans le chat. Sans knowledge base, l'assistant ne peut que renvoyer vers la page produit.

Avec le guide des tailles uploadé en PDF, Navi retrouve les mesures correspondantes, les compare à la description que le visiteur donne de son gabarit, et donne une recommandation argumentée. C'est ce qui transforme une conversation en aide à l'achat réelle.

Exemple 3 : les délais de livraison spécifiques

Les délais varient selon les transporteurs, les zones géographiques, les périodes. Un LLM générique ne peut pas connaître ces spécificités. Un document Markdown uploadé par le marchand avec un tableau des délais par zone, oui.

Le RAG permet à l'assistant de répondre avec les délais réels de la boutique, pas une estimation générique.

Ce que ça ne fait pas (honnêteté sur l'état actuel)

L'infrastructure RAG de Navi est en place et testée côté développement. Les composants fonctionnent : ingestion, chunking, embedding, stockage pgvector, tool search-knowledge, retrieval contextuel.

Mais il faut être précis sur un point : aucun marchand n'a encore alimenté sa knowledge base en production. L'infra est prête à recevoir des documents. La fonctionnalité d'upload est disponible dans le dashboard. Les tests sur le shop de développement confirment que le pipeline fonctionne de bout en bout.

Ce n'est pas une feature promise pour demain. C'est une infrastructure validée techniquement, qui attend ses premiers contenus marchands réels pour démontrer son impact en conditions de production.

Cette transparence est importante. Le RAG n'est pas magique. Sa qualité dépend directement de la qualité des documents fournis. Un PDF mal structuré, une FAQ trop vague, ou des informations contradictoires entre documents produiront des réponses médiocres, même avec la meilleure architecture vectorielle.

Pourquoi pgvector plutôt qu'une base vectorielle dédiée

Le choix de pgvector mérite une explication. Il existe des bases vectorielles dédiées (Pinecone, Weaviate, Qdrant) qui offrent des performances de recherche parfois supérieures à grande échelle.

Mais pour un assistant e-commerce comme Navi, pgvector dans PostgreSQL présente des avantages concrets :

• Simplicité opérationnelle : une seule base de données à gérer, pas d'infra supplémentaire à maintenir.

• Transactions ACID : les vecteurs et les données marchands vivent dans le même système transactionnel. Un shop supprimé (webhook shop/redact) efface aussi ses vecteurs dans la même transaction.

• Isolation par shop : chaque marchand a ses propres embeddings, sans risque de contamination croisée.

• Coût : pas de service tiers facturé à l'usage pour la recherche vectorielle.

Pour les volumes qu'un assistant SAV e-commerce traite (quelques centaines de chunks par marchand), pgvector est plus que suffisant. La recherche de similarité cosinus sur ces volumes est rapide et ne représente pas un goulot d'étranglement.

étude de performance pgvector vs bases vectorielles dédiées

La voix de marque : au-delà des faits, le ton

Le RAG résout le problème de l'information factuelle. Mais la voix de marque, c'est aussi un ton, un registre, des formulations caractéristiques.

Navi adresse ce point différemment : le marchand configure son ton de communication dans les settings (formel, décontracté, premium). Le welcome message dynamique est généré en tenant compte de ce paramètre. Les réponses de l'agent respectent cette consigne de ton.

La combinaison des deux, knowledge base pour les faits et paramétrage du ton pour la forme, permet à un assistant Navi de sonner comme une extension naturelle du service client de la boutique, pas comme un bot générique.

Ce qu'il faut retenir

Le RAG n'est pas une buzzword de plus dans l'IA. C'est une architecture concrète qui résout un problème réel : comment faire en sorte qu'un assistant IA réponde avec les informations spécifiques d'une boutique, pas avec des généralités.

Les composants clés sont simples à comprendre :

• Les documents du marchand sont découpés et transformés en vecteurs (embeddings).

• Ces vecteurs sont stockés dans pgvector.

• Quand un visiteur pose une question, l'assistant cherche les passages pertinents et répond à partir de ce qu'il trouve.

Navi a testé et validé cette architecture sur son shop de développement. L'infrastructure est opérationnelle. La prochaine étape est l'alimentation par les premiers documents marchands en production.

Si vous êtes marchand Shopify et que vous vous demandez ce que ça changerait concrètement pour votre SAV, la réponse est simple : vos visiteurs obtiendraient des réponses précises sur votre politique de retour, vos guides produit et vos délais de livraison, directement dans la conversation, sans jamais chercher la bonne page.