Small Models, Big Results : et si l’extraction d’intentions gagnait à être… découpée ?

Ou comment des modèles « mini » percent des mystères « maxi » en décomposant le problème.

Pourquoi ce papier m’a fait lever un sourcil (puis les deux)

Dans l’IA, on a pris l’habitude de penser que « plus gros = mieux ». Les modèles multi‑modaux géants avalent des images, des DOM, des mots, et régurgitent des réponses crédibles. Mais voilà qu’un papier vient bousculer cette intuition : de petits modèles, bien orchestrés, peuvent dépasser un gros modèle pour comprendre ce que l’utilisateur voulait faire en observant ses interactions avec une interface (mobile ou web).

Le papier s’intitule Small Models, Big Results: Achieving Superior Intent Extraction through Decomposition. Son idée centrale : décomposer le problème d’extraction d’intentions en deux étapes simples et complémentaires, plutôt que de lancer d’emblée toute la séquence d’écrans et d’actions à un modèle. Les auteurs revendiquent d’ailleurs sans détour :

“This method improves intent understanding in resource-constrained models, even surpassing the base performance of large MLLMs.”

Oui oui : surpasser la base d’un grand modèle, avec un plus petit. Sceptique ? Regardons comment ils s’y prennent et ce que disent les chiffres.

Le pitch, sans jargon inutile

Imaginez un détective qui ne cherche pas tout de suite « le mobile du crime », mais note d’abord proprement chaque indice : où était la victime (l’écran), quel geste a été fait (l’action), que montrait la scène alentour (le contexte). Une fois tous les mini‑rapports rédigés, il écrit la synthèse : « la personne voulait réserver un vol », « elle cherchait les détails d’une ligne Amtrak », etc.

C’est exactement la méthode proposée :

Étape 1 : Résumer chaque interaction. Pour chaque pas de la trajectoire (capture d’écran + action), on produit un résumé structuré avec deux champs : un mini‑résumé de l’écran et la description de l’action. Les auteurs autorisent même un champ « speculative intent » (ce que pourrait vouloir l’utilisateur), supprimé ensuite pour éviter les biais. Ils ajoutent une astuce : pour résumer l’étape i, on peut jeter un œil à i-1 et i+1 afin de lever des ambiguïtés (le contexte avant/après aide souvent).
Étape 2 : Extraire l’intention globale. Un second petit modèle, affiné (fine‑tuned), lit la séquence de résumés et produit une phrase courte décrivant l’objectif utilisateur. Les auteurs affinent aussi les étiquettes d’entraînement (les textes‑vérité) pour retirer les détails absents des résumés, afin de ne pas pousser le modèle à halluciner des éléments qui ne figuraient pas en entrée.

Au passage, cette stratégie réduit drastiquement le budget de tokens : plutôt que d’ingérer des images lourdes et de longs historiques, on traite des résumés concis, parfaits pour des modèles on‑device avec petite fenêtre de contexte.

Comment on évalue une “intention” ? (spoiler : ce n’est pas trivial)

Comparer « ce que le modèle pense » avec « l’intention réelle » n’est pas aussi simple que calculer une distance entre deux phrases. Les auteurs utilisent deux métriques sémantiques complémentaires :

Bi‑Fact : on casse l’intention en faits élémentaires (destination, action, contrainte temporelle, etc.), puis on mesure précision, rappel, F1 entre faits prédits et faits de la vérité terrain. Cela capte mieux la couverture réelle que des scores lexicaux. (Ils s’appuient sur un LLM évaluateur pour la factorisation.)
Bi‑NLI : on calcule une entailment (NLI) dans les deux sens entre la prédiction et la vérité, puis on moyenne. Moins précis que Bi‑Fact, mais signal utile en plus.

Petit rappel honnête des auteurs : même des humains ne sont pas toujours d’accord sur l’intention exacte ; sur des travaux antérieurs, l’accord humain plafonnait à ~80 % web et ~76 % téléphone. L’intention est intrinsèquement subjective (prix vs horaire ? détail vs synthèse ?).

Les données, les modèles, les baselines

Datasets. Deux jeux publics d’interactions UI : Mind2Web (2 350 démonstrations web, ~7,3 étapes en moyenne) et AndroidControl (15 283 trajectoires Android, ~5,5 étapes). Les captures d’écran et actions sont disponibles ; AndroidControl n’a pas de validation explicite alignant étroitement étapes et intention, d’où un bruit qu’il a fallu nettoyer.
Modèles comparés. Des petits MLLMs : Gemini 1.5 Flash 8B et Qwen2 VL 7B. Baselines : CoT (prompting avec chain-of-thought) et E2E‑FT (finetuning « tout‑en‑un » de bout en bout). Référence « grand modèle » : Gemini 1.5 Pro en CoT.

Les résultats qui piquent la curiosité

Sur Mind2Web, la version décomposée + fine‑tuning (Decomposed‑FT) avec Gemini 1.5 Flash 8B atteint Bi‑Fact F1 = 0,753, dépassant le grand Gemini 1.5 Pro en CoT (0,721). Avec Qwen2 VL 7B, même musique : 0,623 (décomposé) vs 0,563 (CoT). Côté AndroidControl (plus bruyant), le décomposé reste compétitif et souvent meilleur que l’E2E‑FT, tout en talonnant voire dépassant CoT selon le modèle.

Les auteurs font aussi un test à l’aveugle : un évaluateur humain compare 20 prédictions (Mind2Web) issues de CoT et de la méthode décomposée. Verdict : 12 préférences pour le décomposé, 4 pour CoT, 4 ex‑aequo.

Côté robustesse, l’analyse d’erreurs montre que chaque étape (résumé d’interaction, puis extraction d’intention) introduit une part similaire d’erreur : les résumés font perdre ~16 % de faits, et l’extraction en reperd ~18 % des restants. Bonne nouvelle : seule 8 % des prédictions sont des hallucinations, grâce au traitement des étiquettes et au formatage.

Et ce mea culpa utile :

“We observe that fine-tuning alone does not surpass Chain-of-Thought, especially in noisy data scenarios.”

En clair : le découpage + un peu de fine‑tuning bien pensé bat généralement CoT et E2E‑FT pris séparément, surtout quand les données sont imparfaites (ce qui, soyons honnêtes, arrive souvent hors labo).

Pourquoi la décomposition marche (et pourquoi c’est malin)

Trois bénéfices ressortent.

1) Hygiène informationnelle. On oblige le système à séparer collecte et interprétation. La première étape crée une mémoire propre des interactions, sans broder. La seconde ne peut inventer que ce qui est présent dans cette mémoire (et comme on a purgé les étiquettes d’entraînement des détails absents des résumés, on coupe l’herbe sous le pied des hallucinations).

2) Tolérance au bruit. AndroidControl contient des décalages entre objectif et actions réelles. Les approches « monolithe » (E2E‑FT) apprennent à combler ces trous en inventant, tandis que la méthode décomposée filtre au maximum dans les résumés, puis réconcilie sobrement. Les ablations confirment l’utilité du contexte proche (voir/avant après), du format structuré des résumés et de la séance de fine‑tuning sur l’étape 2 : retirer un seul de ces éléments fait baisser la F1 (ex. No context : 0,710 vs 0,753 ; No fine‑tuning : précision 0,699 mais rappel 0,809, signe d’un modèle verbeux).

3) Parcimonie de tokens (et donc on‑device). Résumer chaque écran/interaction réduit le coût et élargit la longueur de trajectoire qu’un petit modèle peut avaler, sans serveur ni latence réseau. Pour des assistants embarqués dans un téléphone, c’est précieux : discrétion, coût réduit, réactivité.

“Effectively, each stage introduces a similar magnitude of error.”

Cette observation invite à optimiser les deux étages (mieux résumer et mieux extraire), plutôt qu’à chercher un graal monolithique.

Et pour nous, concret : devs, data, et même jeux vidéo

Côté IA/produit, l’approche est un patron d’architecture : décomposer une tâche multi‑modale complexe en résumés structurés (faciles à stocker et auditer), puis raisonner sur ces résumés avec un modèle plus petit, éventuellement spécialisé. Ça se transpose aisément à d’autres domaines : parcours d’achat e‑commerce, navigation dans une app bancaire, assistance administrative, etc.

Côté data science, le message clé n’est pas « 8B > 70B », mais « 8B bien instrumenté > 70B mal instrumenté ». La qualité des étiquettes est cruciale ; ici, la réécriture des labels pour aligner les cibles avec ce que voient vraiment les modèles change la donne (moins d’hallucinations, meilleure précision). Et les auteurs montrent que les métriques comptent : préférer des comparaisons factorielles (Bi‑Fact) à des proxys lexicaux trop grossiers.

Côté créateur·rice de jeux, pensez télémétrie de gameplay : chaque action du joueur (ouvrir l’inventaire, consulter la carte, parler à un PNJ) est un indice. Résumer chaque interaction en deux champs (« écran » / « action ») puis inférer l’intention (« cherche une quête pour gagner de l’or », « essaie d’optimiser son build ») peut alimenter des conseils contextuels, un mode assistant, ou des PNJ plus réactifs. Et comme tout tient dans des résumés texte, ça peut tourner in‑engine avec un petit modèle local, sans sacrifier la vie privée des joueurs.

Quelques limites (avouées) et implications éthiques

Les auteurs reconnaissent un biais de distribution : Mind2Web se concentre sur des sites anglophones, AndroidControl et Mind2Web ne couvrent pas toutes les plates‑formes ni tous les usages réels. La généralisation hors de ces contextes demande du soin.

Ils notent aussi que comprendre l’intention touche à la vie privée. L’avantage de petits modèles on‑device est justement de garder les données sur l’appareil ; mais si l’on confie ensuite des actions à un agent autonome, il faut des garde‑fous solides.

Ce qu’il faut retenir

On peut gagner face à un gros modèle en décomposant bien le problème.
Le duo résumés structurés → extraction limite les hallucinations, augmente la F1 et réduit les tokens.
CoT seul ou finetuning seul ne suffisent pas ; c’est leur combinaison orchestrée (avec de bons labels) qui change la donne.

En somme, l’article est une belle leçon d’ingénierie de la tâche. On n’a pas besoin de mettre un moteur de fusée sur une trottinette : mieux vaut la graisser, bien gonfler les pneus, et choisir le bon itinéraire. Et si demain vos agents UI ou vos NPCs devinent plus finement vos intentions, il y a de bonnes chances qu’ils aient appris à prendre des notes d’abord, réfléchir ensuite.

Pour creuser

Le papier détaille les prompts, les ablations et une analyse des erreurs (par exemple, quand le résumé d’écran manque une info clé, ou quand l’étape 2 omet un détail pourtant présent). Si vous aimez les figures et les tableaux (nous aussi), regardez les Table 1–3 pour les scores et l’ablation, et la Figure 2 pour la propagation des erreurs.

“This method improves intent understanding in resource-constrained models, even surpassing the base performance of large MLLMs.” (résumé)

“We observe that fine-tuning alone does not surpass Chain-of-Thought…” (discussion)

— Et maintenant, à vos détectives miniatures !