LLM en pipeline draft-verify-revise : une étude met en lumière le risque d’ambiguïté déictique

Les pipelines draft-verify-revise sont devenus un schéma courant pour améliorer les performances des grands modèles de langage en répartissant la tâche entre plusieurs étapes : un modèle rédige, un autre critique, puis un troisième révise. Mais selon cette étude déposée sur arXiv, ce découpage peut introduire un problème discret mais important : le glissement déictique, c’est-à-dire un changement de référent pour des expressions dépendantes du contexte comme « précédent ».

Les auteurs ont étudié ce phénomène à partir d’un jeu de données synthétique composé de 10 exemples de base, chacun décliné en trois conditions. L’objectif était d’observer dans quels cas le modèle de rédaction, le modèle de vérification ou le modèle de révision interprétaient correctement — ou non — l’expression ambiguë. L’expérience a porté sur six modèles issus de trois fournisseurs, testés dans 21 configurations d’effort de raisonnement, avec une expérience principale et une variante supprimant certains labels de classification d’erreur dans le retour du vérificateur.

Les performances mesurées en balanced accuracy varient fortement, de 0,156, soit en dessous du hasard, à des niveaux proches de la perfection. L’étude souligne notamment que GPT-5.2 passe de 0,156 sans raisonnement explicite à 0,942 à son niveau d’effort le plus élevé. De son côté, Gemini 3 Pro reste au-dessus de 0,94 à tous les niveaux testés. Les auteurs indiquent aussi que Gemini 3 Pro, à faible effort de raisonnement, surpasse GPT-5.2 à effort maximal pour environ 5 % du coût par essai.

Autre enseignement : lorsque le modèle chargé de la révision se trompe, il s’appuie souvent sur des indices de surface plutôt que sur un raisonnement opérationnel. Pour les équipes qui conçoivent des chaînes d’orchestration LLM, la recommandation est claire : rendre explicite le référent visé à chaque étape afin de limiter les erreurs liées au contexte. L’étude reste fondée sur un corpus synthétique et ciblé, mais elle met en évidence un point de vigilance concret pour l’ingénierie de contexte.