Projet

Vestiaire

L'utilisateur pouvait décrire ce qu'il cherchait en langage courant. Le système traduisait ensuite cette demande en critères structurés et interrogeait des données produit réellement supportées.

Vestiaire

Workflow de recherche

Vue d'ensemble

Recherche en langage naturel sur données produit

Les filtres classiques fonctionnent quand l'utilisateur connaît déjà les bons champs. Ce workflow gérait des demandes qui démarrent par un style, une occasion, des combinaisons ou une préférence encore floue.

Problème

Le problème

Les utilisateurs ne cherchent pas toujours avec des termes déjà prêts pour des filtres. Ils décrivent souvent leur besoin d'une manière qu'il faut traduire avant de pouvoir renvoyer des produits pertinents.

Contraintes

Contraintes

Le workflow devait rester ancré dans le vrai catalogue, éviter d'inventer des attributs non supportés et garder explicite le passage entre interprétation et recherche backend.

Contribution

Mon travail

J'ai construit le workflow entre interprétation en langage naturel, services backend et données produit afin que des demandes ouvertes deviennent des critères de recherche structurés et validés.

Système

Flux de requête

Requête utilisateur
↓
Extraction d'intention et de critères
↓
Appels d'outils et d'API backend
↓
Données produit PostgreSQL et Neo4j
↓
Validation des résultats et recommandations structurées

Décisions techniques

  • Traduire le langage libre en critères que le backend peut valider
  • Garder la recherche catalogue dans les outils et services au lieu de faire confiance au texte du modèle seul
  • Renvoyer des recommandations structurées pour que l'interface reste cohérente avec les données supportées

Résultat

Ce que cela a amélioré

Le workflow transformait des demandes ouvertes en entrées de recherche réellement supportées, ce qui simplifiait la découverte sans perdre l'ancrage dans le catalogue.

FAQ

Questions fréquentes

Comment des demandes ouvertes deviennent-elles des critères produit ?

La couche d'orchestration analysait la langue utilisateur pour produire des critères structurés que les services backend pouvaient valider contre les données réellement disponibles.

Comment les recommandations restaient-elles ancrées ?

Les recommandations étaient construites à partir d'appels d'outils et d'API sur de vraies données produit, au lieu de dépendre uniquement d'un texte généré librement par le modèle.

Pourquoi ne pas s'appuyer seulement sur des filtres ?

Les filtres fonctionnent quand l'utilisateur connaît déjà les bons champs. La découverte en langage naturel aide quand la demande part d'un style, d'une occasion, de combinaisons de couleurs ou d'un langage de préférence.

Où vivaient les données produit ?

Le workflow connectait des services backend à des données produit dans PostgreSQL et Neo4j, puis renvoyait des recommandations structurées basées sur ce que le catalogue pouvait réellement supporter.