Les LLM locaux surpassent les modèles cloud dans un test d'achat Amazon

📋

Points Clés

Un LLM local d'environ 3 milliards de paramètres a réussi à effectuer un flux d'achat complet sur Amazon avec un taux de succès de 7/7 en utilisant uniquement des données structurées de page.
La pile de modèles locaux fonctionnait avec un coût marginal nul et ne nécessitait aucune capacité de vision, contrairement aux appels d'API cloud coûteux.
Le système a réduit la complexité des entrées en élaguant environ 95 % des nœuds DOM, créant un instantané sémantique compact pour le modèle.
Le modèle local a utilisé 11 114 jetons contre 19 956 pour le modèle cloud, démontrant une plus grande efficacité dans l'utilisation des jetons.
La couche de vérification a implémenté des assertions de style Jest après chaque action, garantissant que l'agent ne pouvait procéder qu'après avoir prouvé les changements d'état.
L'expérience a conclu que contraindre l'espace d'état et rendre le succès explicite par la vérification est plus efficace que de simplement augmenter la taille du modèle.

Le Paradoxe de la Fiabilité

La quête d'une IA plus puissante conduit souvent à des modèles cloud plus grands et plus coûteux. Cependant, une expérience récente remet en cause cette sagesse conventionnelle en démontrant que des modèles locaux plus petits peuvent atteindre une fiabilité supérieure dans des tâches complexes d'automatisation web.

Les chercheurs ont testé un scénario d'automatisation courant : effectuer un flux d'achat complet sur Amazon. L'objectif était de naviguer de la recherche jusqu'à la caisse, une séquence impliquant plusieurs étapes et des éléments de page dynamiques. Les résultats ont révélé une contradiction surprenante par rapport à l'approche dominante de l'industrie.

L'étude a comparé un modèle cloud à haute capacité contre un modèle local compact, mesurant les taux de succès, l'utilisation des jetons et le coût. Les découvertes suggèrent que l'innovation architecturale peut l'emporter sur la puissance de calcul brute lors de la construction d'agents IA fiables.

Le Défi Amazon

L'expérience s'est concentrée sur une tâche standardisée : recherche → premier produit → ajouter au panier → caisse. Ce flux teste la capacité d'une IA à interpréter des pages web dynamiques, prendre des décisions et exécuter des actions précises sans entrée visuelle.

Deux systèmes principaux ont été comparés. Le référence cloud utilisait un grand modèle capable de vision (GLM‑4.6). La pile d'autonomie locale reposait sur une combinaison d'un planificateur de raisonnement (DeepSeek R1) et d'un modèle d'exécution plus petit (Qwen ~3B), tous deux fonctionnant sur du matériel local.

Les métriques de performance ont révélé des différences marquantes :

Modèle Cloud : A réussi 1 succès en 1 exécution, utilisant 19 956 jetons à un coût d'API non spécifié.
Modèle Local : A réussi 7 succès en 7 exécutions, utilisant 11 114 jetons avec un coût marginal nul.

Alors que la pile locale était nettement plus lente (405 740 ms contre 60 000 ms), son taux de succès parfait et son efficacité en coûts ont mis en évidence un compromis critique entre rapidité et fiabilité.

« La fiabilité des agents provient de la vérification (assertions sur des instantanés structurés), et non simplement de l'augmentation de la taille du modèle. »
— Conclusions de l'étude

Innovation Architecturale

Le succès du modèle local n'était pas accidentel ; il résultait d'un plan de contrôle repensé. Le système a employé trois stratégies clés pour contraindre le problème et garantir des résultats déterministes.

Premièrement, il a élagué le DOM pour réduire la complexité. Au lieu de fournir la page entière ou des captures d'écran, le système a généré un « instantané sémantique » compact contenant uniquement les rôles, le texte et la géométrie, élaguant environ 95 % des nœuds.

Deuxièmement, il a séparé le raisonnement de l'action. Un modèle planificateur déterminait l'intention et les résultats attendus, tandis qu'un modèle d'exécution séparé sélectionnait des actions DOM concrètes comme CLIQUER ou TAPER. Cette séparation des préoccupations a amélioré la précision.

Troisièmement, chaque étape était contrôlée par une vérification de style Jest. Après chaque action, le système affirmait les changements d'état—comme les mises à jour d'URL ou la visibilité des éléments. Si une assertion échouait, l'étape échouait et déclenchait des tentatives de récupération bornées, garantissant que l'agent ne procédait jamais sur une fausse hypothèse.

De l'Intelligent au Fonctionnel

Les journaux ont révélé comment cette couche de vérification a transformé le comportement de l'agent. Dans un cas, le système a utilisé une surcharge déterministe pour imposer l'intention « premier résultat », garantissant que le bon lien de produit était cliqué.

Un autre exemple impliquait la gestion d'un tiroir dynamique. Le système a vérifié l'apparition du tiroir et a forcé la branche correcte, enregistrant un résultat clair « PASS | add_to_cart_verified_after_drawer ».

Ces éléments n'étaient pas des analyses a posteriori ; c'étaient des contrôles en ligne. Le système soit prouvait qu'il faisait des progrès, soit s'arrêtait pour se rétablir. Cette approche va au-delà des suppositions probabilistes vers une exécution prouvable.

La fiabilité des agents provient de la vérification (assertions sur des instantanés structurés), et non simplement de l'augmentation de la taille du modèle.

La conclusion est claire : le mouvement à plus fort levier pour des agents de navigateur fiables n'est pas un modèle plus grand. C'est contraindre l'espace d'état et rendre le succès explicite avec des assertions par étape.

L'Impératif de la Vérification

Cette étude de cas démontre que la vérification est la pierre angulaire de l'automatisation IA fiable. En implémentant une couche d'assertion rigoureuse, un modèle local modeste a atteint un taux de succès parfait là où un modèle cloud plus puissant a échoué.

Les implications vont au-delà du e-commerce. Tout domaine nécessitant des actions précises et répétibles—comme la saisie de données, le traitement de formulaires ou l'administration système—peut bénéficier de ce changement architectural. L'attention se déplace de la taille du modèle vers la conception du système.

Alors que les agents IA s'intègrent davantage dans les flux de travail quotidiens, la demande pour la dépendabilité plutôt que la puissance brute ne fera que croître. Cette expérience fournit un plan directeur pour construire des agents qui fonctionnent, et non seulement ceux qui paraissent intelligents.

Questions Fréquemment Posées

Quel était le principal résultat du test d'automatisation d'achat Amazon ?

L'étude a découvert qu'un modèle de langage local plus petit (~3 milliards de paramètres) a atteint un taux de succès parfait de 7/7 pour effectuer un flux d'achat complexe sur Amazon, surpassant un modèle cloud plus grand qui n'a réussi qu'une seule fois. Le modèle local a également utilisé moins de jetons et n'a engagé aucun coût marginal, démontrant que la conception architecturale peut l'emporter sur la puissance de calcul brute.

Comment le modèle local a-t-il atteint une fiabilité aussi élevée ?

Le système a utilisé une architecture en trois parties : il a élagué le DOM pour réduire la complexité, séparé le raisonnement de l'action entre deux modèles spécialisés, et implémenté une boucle de vérification avec des assertions par étape. Cela a garanti que l'agent ne pouvait procéder qu'après avoir prouvé que chaque action était réussie, éliminant les suppositions.

Quelles sont les implications pour le développement d'agents IA ?

Key Facts: 1. Un LLM local d'environ 3 milliards de paramètres a réussi à effectuer un flux d'achat complet sur Amazon avec un taux de succès de 7/7 en utilisant uniquement des données structurées de page. 2. La pile de modèles locaux fonctionnait avec un coût marginal nul et ne nécessitait aucune capacité de vision, contrairement aux appels d'API cloud coûteux. 3. Le système a réduit la complexité des entrées en élaguant environ 95 % des nœuds DOM, créant un instantané sémantique compact pour le modèle. 4. Le modèle local a utilisé 11 114 jetons contre 19 956 pour le modèle cloud, démontrant une plus grande efficacité dans l'utilisation des jetons. 5. La couche de vérification a implémenté des assertions de style Jest après chaque action, garantissant que l'agent ne pouvait procéder qu'après avoir prouvé les changements d'état. 6. L'expérience a conclu que contraindre l'espace d'état et rendre le succès explicite par la vérification est plus efficace que de simplement augmenter la taille du modèle. FAQ: Q1: Quel était le principal résultat du test d'automatisation d'achat Amazon ? A1: L'étude a découvert qu'un modèle de langage local plus petit (~3 milliards de paramètres) a atteint un taux de succès parfait de 7/7 pour effectuer un flux d'achat complexe sur Amazon, surpassant un modèle cloud plus grand qui n'a réussi qu'une seule fois. Le modèle local a également utilisé moins de jetons et n'a engagé aucun coût marginal, démontrant que la conception architecturale peut l'emporter sur la puissance de calcul brute. Q2: Comment le modèle local a-t-il atteint une fiabilité aussi élevée ? A2: Le système a utilisé une architecture en trois parties : il a élagué le DOM pour réduire la complexité, séparé le raisonnement de l'action entre deux modèles spécialisés, et implémenté une boucle de vérification avec des assertions par étape. Cela a garanti que l'agent ne pouvait procéder qu'après avoir prouvé que chaque action était réussie, éliminant les suppositions. Q3: Quelles sont les implications pour le développement d'agents IA ? A3: Les résultats suggèrent que pour une automatisation fiable, les développeurs devraient se concentrer sur la contrainte de l'espace du problème et l'implémentation de contrôles de vérification rigoureux plutôt que d'utiliser simplement des modèles plus grands. Cette approche réduit les coûts, améliore les taux de succès et rend le comportement de l'agent plus prévisible et digne de confiance. Q4: Y a-t-il eu un compromis en performance ? A4: Oui, la pile de modèles locaux était nettement plus lente, prenant environ 405 secondes contre 60 secondes pour le modèle cloud. Cependant, le taux de succès parfait du modèle local et son coût nul le rendaient plus pratique pour les scénarios où la fiabilité est prioritaire par rapport à la rapidité.

Continue scrolling for more