Renvoyez des faits, pas des interprétations : pourquoi les outils LLM devraient être plus stupides que vous ne le pensez

DEV - 10/12
Cet article s'adresse à tous ceux qui ont découvert que rendre les outils « utiles » aux LLM les rendait réellement...

Cet article s'adresse à tous ceux qui ont découvert que rendre les outils « utiles » aux LLM les rendait en réalité moins utiles.

TL;DR : J'ai essayé de rendre les outils d'exploration DOM de mes serveurs MCP utiles en ajoutant des interprétations sémantiques à leur sortie. Les outils sont devenus fragiles, spécifiques à des tâches et plus difficiles à utiliser correctement pour les LLM. Supprimer toute interprétation et renvoyer uniquement des faits structurels bruts a rendu le système plus fiable, plus composable et, paradoxalement, plus utile. Cet article explique pourquoi les outils orientés LLM nécessitent des principes de conception fondamentalement différents de ceux des API orientées vers l'humain, et pourquoi les outils « plus stupides » créent des agents plus intelligents.

Feuille de route des articles

Partie 1 : Le problème (lecture de 2 min)

  • L'outil utile qui a tout aggravé
  • Pourquoi l'interprétation dépend du contexte
  • L’idée : capacité versus interprétation

Partie 2 : Pourquoi c'est important (lecture de 2 minutes)

  • Le problème de la composition
  • Le piège de l'API humaine
  • Quand l’interprétation appartient aux outils (les cas rares)

Partie 3 : Principes de conception (lecture de 2 minutes)

  • Quatre principes pour les outils factuels
  • Le test de composabilité
  • Comment la couche de connaissances gère l'interprétation

Partie 4 : Ce que cela signifie pour les constructeurs (lecture de 2 minutes)

  • Modifications pratiques pour les constructeurs d'outils
  • Le résultat contre-intuitif
  • Le principe se généralise

Partie 1 : Le problème

1.1 L'outil utile qui a tout aggravé

Quand j'ai construit pour la première foisrésoudre_conteneurpour Verdex, je voulais que ce soit utile. L'outil parcourt l'arborescence DOM à partir d'un élément cible et renvoie la chaîne ancêtre. Mais je n'ai pas seulement renvoyé des balises et des attributs, j'ai ajouté une interprétation :

{ "type": "product-card", // L'outil devine la signification sémantique "role": "list-item", // L'outil devine l'objectif structurel "confidence": 0,85, // L'outil évalue sa propre supposition "recommendation": "Utilisez ceci comme portée de votre conteneur" }
Entrer en mode plein écran Quitter le mode plein écran

Cela semblait raisonnable. J'aidais le LLM en pré-analysant la structure et en faisant des recommandations. L'outil effectuait le dur travail d'interprétation, le LLM n'avait donc pas à le faire.

Ensuite, je suis passé à la production.

Une page avec des cartes de profil utilisateur. L’outil les a étiquetés en toute confiance comme des fiches produits (confiance : 0,85). Le LLM a fait confiance à l'interprétation de l'outil. Il a généré des sélecteurs limités au mauvais modèle. Les tests ont été mystérieusement interrompus lorsque l'heuristique a échoué dans des cas extrêmes.

Le problème n’était pas que l’interprétation était généralement fausse – elle était généralement juste. Le problème était fondamental : l’interprétation dépend du contexte, et l’outil n’avait pas de contexte.

1.2 Le problème central : l’interprétation dépend du contexte

Prends undivavecdata-testid="carte-produit". Qu'est-ce que cela signifie?

Pour la création de sélecteurs : ce div est un conteneur stable. UtilisergetByTestId("carte-produit")comme votre portée.

Pour les tests visuels : il s’agit d’une limite de composant. Capture d'écran de cette carte entière.

Pour le web scraping : c’est une structure de données. Extrayez les informations sur les produits des descendants.

Pour l'audi...
[Courte citation de 8% de l'article original]