LLMs et Python : optimiser les recommandations sans coûts excessifs

Modèles de Langage de Grande Taille

Les Modèles de Langage de Grande Taille, ou LLMs, représentent le sommet actuel des capacités de l'intelligence artificielle. Ces modèles sont formés sur un vaste ensemble de données qui couvre l'ensemble des connaissances disponibles dans le monde. Cependant, leur taille et leur complexité signifient qu'ils ne sont pas souvent hébergés en interne par les entreprises. Au lieu de cela, ils sont généralement accessibles via des API, ce qui implique une consommation de tokens à chaque requête, entraînant des coûts non négligeables.

Prenons un exemple concret pour illustrer ce point : si vous souhaitez obtenir une recommandation pour un restaurant italien qui soit à la fois romantique, bien situé et abordable, vous pourriez interroger un modèle comme ChatGPT. Cependant, si ce modèle devait évaluer chaque restaurant possible pour vérifier s'il répond à vos critères, cela consommerait une quantité énorme de tokens. Ce processus serait non seulement coûteux, mais également lent, au point que vous pourriez être déjà au lit avant d'obtenir une réponse.

Pourtant, il est essentiel de ne pas renoncer à la capacité des LLMs à interpréter et à extraire des informations pertinentes. La clé réside dans l'utilisation stratégique de ces modèles, en évitant de recourir à leur puissance maximale à chaque étape du processus.

1. Conception du Système

Dans le domaine de l'ingénierie, le concept de triangle Précision-Échelle-Délai est bien connu. Il décrit les compromis nécessaires entre ces trois éléments :

• Un système peut être très précis et capable de traiter de grandes quantités de données, mais cela se fera au détriment de la rapidité.
• Il peut être à la fois précis et rapide, mais il ne sera pas capable de s'adapter à des ensembles de données très volumineux.
• Enfin, il peut être rapide et évolutif, mais il manquera alors de précision.

Pour obtenir des résultats qui soient à la fois précis et efficaces, il est possible de combiner ces approches. Ainsi, un système rapide et évolutif peut d'abord fournir une liste de candidats potentiels, qui sera ensuite affinée par un LLM pour obtenir des recommandations plus précises.

La stratégie consiste donc à :

• Effectuer une recherche rapide et simple pour identifier les K restaurants les plus proches, en se basant sur des règles simples qui garantissent une haute récupération mais une faible précision.
• Utiliser ensuite un LLM pour affiner cette liste et choisir le meilleur restaurant selon les critères de l'utilisateur, en se basant sur l'intelligence artificielle pour obtenir une haute précision.

Cette méthode permet de bénéficier de l'intelligence des LLMs sans engager des coûts élevés, en l'appliquant uniquement sur une sélection restreinte de candidats.

2. Génération des Données

Pour recommander des restaurants, il est d'abord nécessaire de disposer d'une base de données pertinente. Dans un système réel, cela se ferait via une base de données stockée dans un emplacement S3. Pour cet article, nous utilisons une base de données synthétique, permettant de reproduire le processus sans frais.

La classe RestaurantDataGenerator dans datagenerator.py génère une table de 10 000 restaurants répartis dans huit villes américaines. Chaque restaurant est caractérisé par :

• un nom généré aléatoirement
• une localisation géographique (latitude/longitude) échantillonnée autour du centre de chaque ville, dans un rayon d'environ 13 km
• un type de cuisine (italienne, japonaise, mexicaine, thaïlandaise, française, etc.)
• un profil diététique (omnivore, végétarien, végétalien)
• une note moyenne attribuée par les clients
• un nombre de votes exprimés
• une fourchette de prix (10, 100, 1000, représentant une moyenne de ticket par personne).

Ce générateur est conçu pour être exécuté une seule fois, et les données sont enregistrées dans data/restaurants.csv.

2.3 Génération des Candidats

La première étape du processus consiste à créer une liste de candidats basée sur des règles simples et peu coûteuses. L'utilisateur indique sa ville, et le système conserve uniquement les restaurants les plus proches géographiquement. Le code filtre la table selon la ville, calcule la distance directe entre l'utilisateur et chaque restaurant, et identifie les N_DISTANCE_CANDIDATES (50 par défaut).

Cette approche privilégie une haute récupération avec une précision moindre, permettant de parcourir l'ensemble des 10 000 restaurants sans appel API ni coût en tokens. Bien que cette méthode ne soit pas sophistiquée, elle élimine les options non viables pour l'utilisateur, constituant ainsi une première étape cruciale.

Par exemple, si vous cherchez des "tacos végan pas chers avec une ambiance animée" dans plusieurs villes, cette étape vous permettra de filtrer rapidement les restaurants qui ne répondent pas à ces critères de base.

2.4 Sélection des Candidats

La seconde étape, plus intelligente et précise, repose sur le LLM. Elle s'appuie sur la liste de 50 restaurants obtenue précédemment. Le LLM ne traite jamais l'ensemble des 10 000 restaurants, mais uniquement cette sélection restreinte.

Le modèle est interrogé via un client OpenAI, avec une clé API lue depuis OPENAI_API_KEY. Le recommandateur, défini comme RestaurantRecommender, fonctionne en traitant la requête et la ville via RestaurantRecommender.recommender(query, city).

Quelques points clés :

• La précision augmente considérablement. L'étape initiale proposait 50 restaurants proches, sans distinction. L'étape suivante lit la requête spécifique (par exemple, "tacos végan pas chers avec une ambiance animée"), élimine les options non pertinentes, et ne conserve que les 5 à 10 meilleurs choix avec un fit_score précis.

• Sortie structurée avec Pydantic. Le modèle répond sous forme structurée, garantissant que chaque réponse respecte un schéma prédéfini.

Le schéma de sortie inclut l'id et le nom du restaurant, un fit_score entre 0 et 100, et une justification succincte. Par exemple, pour nos trois villes, le modèle a réorganisé les 50 candidats en fonction des critères demandés, mettant en avant les restaurants végan et mexicains avec des scores élevés.

Conclusion

Le processus en deux étapes a démontré son efficacité pour répondre à la demande "tacos végan pas chers avec une ambiance animée" dans trois villes :

• L'étape initiale a fourni une liste de candidats à haute récupération mais faible précision.
• L'étape suivante, en utilisant le LLM, a affiné ces candidats pour fournir des recommandations précises.

Les choix finaux incluent :

• New York : Golden Spoon (végan, 4.9) et Maison Fork (mexicain, abordable) avec des scores de 90 et 85.
• Miami : Royal Tavern & Co. (végan, mexicain, abordable) avec un score de 85.
• Boston : Urban Spoon et Little House, deux options mexicaines à petit budget.