Quand je conçois des assistants basés sur des modèles GPT pour recommander des produits, une préoccupation revient systématiquement : les hallucinations. Ces réponses inventées ou inexactes peuvent nuire à la confiance des utilisateurs et provoquer des erreurs opérationnelles — recommandations de produits en rupture de stock, descriptions incorrectes, ou pires, suggestions incompatibles avec des contraintes réglementaires. Au fil de mes expérimentations, j'ai développé une approche pragmatique : définir des prompts systématiques (templates, règles et checks) qui réduisent sensiblement ces hallucinations tout en restant flexibles et productifs.

Pourquoi les prompts systématiques aident

Les hallucinations surviennent quand le modèle "devine" au lieu de se reposer sur des données fiables. En uniformisant la manière dont on lui demande des informations — structure, niveau de précision, sources attendues, format de sortie — on réduit la marge d'interprétation libre. C'est un peu comme donner à un collaborateur humain un brief clair : il y a moins de place à l'interprétation créative non désirée.

Les principes qui guident mes prompts

  • Contrainte sur la source : toujours préciser si le modèle doit se baser sur une base interne (catalogue produit, API) ou sur des connaissances générales.
  • Exiger l'incertitude : demander explicitement au modèle d'indiquer le niveau de confiance pour chaque recommandation.
  • Format structuré : demander une sortie normalisée (JSON, tableau) facilite la validation automatique.
  • Checks et fallback : intégrer des étapes pour vérifier la disponibilité et la compatibilité avant d'afficher la recommandation.
  • Limiter la génération libre : préférer des réponses factuelles et éviter les formulations vagues ou hyperboliques.

    • Un template de prompt que j'utilise

    Voici un template générique que je décline selon le contexte (e‑commerce B2C, SaaS, marketplace, etc.). Vous pouvez le transformer en requête API ou en instruction pour un agent de dialogue.

    ContexteVous êtes un assistant produit connecté à [nom de la source] (API produit, base interne).
    ObjectifFournir jusqu'à 3 recommandations de produits correspondant aux critères utilisateur.
    Contraintes1) Ne proposer que des produits présents dans la source. 2) Vérifier la disponibilité et l'état du stock. 3) Respecter les filtres (prix, matériau, taille). 4) Indiquer le niveau de confiance pour chaque recommandation.
    Format de sortieJSON array : [{id, nom, score_confiance, raisons, sources_verifiees, actions_recommandees}].
    FallbackSi aucune correspondance directe, retourner 'aucune_recommandation' et suggérer alternatives (filtre, délai, produit similaire) avec niveau de confiance faible.

    Exemple concret (prompt adapté à un site e‑commerce)

    Prompt (à envoyer au modèle) :

    "Contexte : tu as accès à l'API produit interne (product_api). Utilisateur : 'Je cherche un sac à dos étanche pour la randonnée, budget max 150 CHF, volume 30–40 L.' Contraintes : ne proposer que des produits confirmés disponibles via product_api. Actions : 1) interroger product_api avec les filtres; 2) pour chaque produit, vérifier stock et délai d'expédition; 3) retourner au maximum 3 recommandations triées par score de pertinence. Format : JSON array [{id, nom, score_confiance (0-1), raisons (2-3 points), sources_verifiees (liste des endpoints), disponibilité}]. Si aucune correspondance : renvoyer { 'aucune_recommandation': true, 'suggestions': ['Agrandir budget','Réduire volume','S'abonner à la notification'], 'niveau_confiance': 0.2 }."

    Checks automatiques que j'implémente ensuite

  • Validation de source : le flux doit consommer d'abord un endpoint d'inventaire. Si le modèle génère un produit absent de la liste d'IDs renvoyée, on rejette automatiquement la réponse.
  • Contrôle de cohérence : vérification que les attributs retournés (taille, prix) correspondent aux valeurs de la base. Toute divergence déclenche un flag "à vérifier".
  • Score de confiance : j'agrège signaux (correspondance filtre, fraîcheur du stock, similarité produit) pour recalculer le score. Si le modèle donne 0.9 mais l'API montre rupture, je rabaisse la note et modifie le message final.
  • Audit trail : conserver la requête, réponse du modèle et requêtes API associées pour traçabilité et apprentissage continu.

    • Techniques pour réduire les hallucinations dans les réponses textuelles

  • Demander des justifications courtes et sourcées : "Donne 2 raisons factuelles et cite la source (ID produit, endpoint)". Les modèles sont moins enclins à inventer quand on exige une source vérifiable.
  • Limiter la génération créative : utiliser des instructions comme "Réponds uniquement par des faits repris de la base" ou "N'utilise pas de superlatifs sans preuve".
  • Utiliser des prompts de vérification : après la réponse, réexécuter un prompt "Vérifie pour chaque recommandation que le produit est en stock et que le prix n'a pas changé dans les dernières 24h". Si échec, demander au modèle de corriger.

    • Intégration dans un flux produit (workflow)

  • 1. Récupération des filtres et intent utilisateur.
  • 2. Requête au catalogue pour obtenir IDs candidats (backend).
  • 3. Prompt systématique vers GPT en fournissant uniquement ces IDs (plus métadonnées minimales), pas la totalité du catalogue.
  • 4. Validation automatique (checks ci‑dessus).
  • 5. Si tout est validé, affichage ; sinon, triggering d'un fallback (suggestions ou intervention humaine).

    • Mes retours d'expérience et pièges courants

    Dans mes premiers prototypes, je laissais le modèle choisir librement des produits à partir d'une brève description utilisateur. Résultat : des recommandations séduisantes mais souvent fausses — caractéristiques inventées, disponibilité erronée. En limitant le droit de "parcourir" à la seule liste d'IDs extraite de l'API, j'ai réduit drastiquement ces erreurs.

    Un autre piège : la tentation d'utiliser le modèle pour tout faire. GPT est excellent pour synthétiser et prioriser, moins pour vérifier des états dynamiques (stock, prix). Pour ces éléments, déléguez toujours la vérité au système source et utilisez le modèle en couche interprétative, pas encyclopédique.

    Prompts d'exemple prêts à l'emploi

  • Recommandation stricte : "Utilise uniquement ces 5 IDs passés en input. Classe-les par adéquation aux critères utilisateur, donne score et 2 raisons tirées des métadonnées. Ne suggère rien de non listé."
  • Vérification : "Pour chaque produit listé, vérifie la disponibilité via endpoint_stock/{id} et indique 'stock_confirmé' ou 'rupture'."
  • Fallback informatif : "Si aucune correspondance, propose 3 alternatives d'action et un message transparent sur l'incertitude."

    • Élaborer des prompts systématiques demande un peu de discipline initiale, mais le gain en fiabilité et en expérience utilisateur est réel. En combinant contraintes de sources, formats structurés et validations automatiques, on transforme GPT d'un orateur créatif en un assistant produit responsable.