Un concierge IA qui apprend les goûts de chaque membre.
Deux agents Gemini qui recherchent et bloquent de vraies chambres d’hôtel, un fil qui apprend de chaque balayage, et une mémoire des goûts que le membre confirme et contrôle.
Construire l’intelligence d’une application de voyage : un assistant capable de vérifier et de bloquer des chambres, et un fil qui s’améliore pour chaque membre sans jamais réserver, facturer ni mémoriser quoi que ce soit de lui-même.
Un backend Python avec un agent concierge et réservations Gemini, un tagueur Gemini hors ligne et des embeddings pour chaque hôtel, un fil d’apprentissage par membre avec exploration et voisins de goût, une mémoire des goûts limitée aux éléments confirmés, et un parcours de réservation que valide toujours une personne.
Chaque fonctionnalité ci-dessous est rattachée à la partie du système qui l’exécute : Gemini, un modèle de machine learning, des règles fixes ou une personne.
Gemini 2.5 Flash sur Google ADK : un agent concierge confie les réservations à un sous-agent réservations doté d’outils pour les tarifs en direct, les disponibilités, les dates, la devise et le profil du membre. Il répond dans la langue du membre.
Gemini lit le texte du catalogue de chaque hôtel et le note sur 19 dimensions de goût et 9 faits pratiques, avec une ligne de preuve par note. Pas de signal dans le texte, pas de note : aucune supposition.
Les embeddings Gemini placent chaque hôtel dans un espace de goût, avec en plus une vue de style dont la moyenne de la ville est retirée : le fil épouse l’ambiance, pas seulement le lieu.
Chaque membre a son propre modèle bayésien, mis à jour d’après le temps passé, les balayages de photos, les sauvegardes, les réservations et le motif d’un « pas pour moi ». L’exploration teste de nouvelles options, les préférences s’estompent sur 120 jours et un changement de goût est détecté.
Le filtrage collaboratif trouve les membres aux goûts proches, un reclassement par diversité évite que le fil se répète, et chaque carte montre la chambre qui convient le mieux au membre.
Un classeur débiaisé de la position, entraîné sur les journaux du fil, tourne dans un bras A/B face à des pondérations réglées à la main, avec évaluation hors politique. Les pondérations manuelles servent par défaut, et les tests à ce jour utilisent des membres simulés.
Le modèle ne peut citer un prix qu’après qu’un outil l’a renvoyé. Ses réponses sont contrôlées pour les données personnelles et les fuites de prompt, et les critères rédhibitoires comme l’accès de plain-pied filtrent les résultats sans jamais s’estomper.
L’agent ne peut ni confirmer, ni débiter, ni annuler : une personne vérifie le blocage et le membre confirme avec son propre bouton. Un goût n’est enregistré qu’après le oui du membre, et un seul appel efface ce que le fil a appris.
Les données de carte vont uniquement dans le formulaire de carte hébergé du partenaire hôtelier via un lien signé, les téléphones sont associés par SMS Twilio Verify et les webhooks partenaires maintiennent les séjours synchronisés.
Les écrans de l’app (évaluation, archétype et Ask Loma) seront connectés à ce moteur. Aujourd’hui, c’est un front-end conçu, pas encore relié au moteur.
Des agents Gemini qui cherchent, comparent et bloquent des chambres dans la langue du membre.
Des hôtels classés par membre selon ce qu’il ouvre, sauvegarde, écarte et réserve.
Des préférences confirmées conservées par type de séjour, avec des critères rédhibitoires qui ne s’estompent jamais.
La chambre affichée sur chaque carte est choisie pour le membre, pas seulement pour l’hôtel.
Formulaire de carte hébergé par le partenaire, validation humaine et bouton de confirmation propre au membre.
Réservations synchronisées avec l’hôtel partenaire par webhook.
Sachez ce qu’elle coûtera et ce qu’elle rapportera avant de la construire.