Traiter les SOP comme du code : un nouveau runtime à pagination par pile sépare les agents forts des faibles

Un agent de centre d'appels bancaire doit suivre une procédure opérationnelle standard : vérifier l'identité du client, vérifier l'état du compte, évaluer l'éligibilité, puis traiter la demande ou refuser. Chaque agent d'entreprise est confronté à cette tâche. L'approche dominante déverse l'intégralité de la SOP dans le prompt sous forme de texte, ce qui présente des modes de défaillance bien connus : une prose résidente d'environ 10 000 caractères par tour concurrence le dialogue pour l'attention, et la verbalisation supprime la structure exécutable telle que l'ordre alternatif et les court-circuits de portes.

Un nouvel article de l'Université polytechnique de Hong Kong, de l'Université de Hong Kong et de l'Université normale du Zhejiang, intitulé "Compile, Then Page: Executable SOP Programs and a Capability-Gated Runtime for Procedural LLM Agents", adopte une approche différente. Les auteurs traitent la SOP comme un programme plutôt que comme du texte. Un compilateur déterministe hors ligne traduit les contraintes de dépendance lisibles par machine du benchmark en un programme pseudo-code à deux couches : des fonctions de processus pour chaque objectif utilisateur et des sous-routines de règles qui associent chaque contrainte à une recette de vérification et à un retour porteur de preuve. Un runtime en ligne guidé par programme (PG) exécute ceci comme une machine virtuelle à deux couches, où une machine à pile symbolique gère la comptabilité (pile, curseur, variables, récupération) et ne pagine que le cadre actif dans le contexte, tandis que le LLM converse, appelle des outils et juge des preuves.

La conception à trois bras

L'étude utilise une conception à trois bras sur SOPBench, un benchmark qui traite la conformité aux SOP comme des tâches d'utilisation d'outils sur des simulateurs de domaine. Les trois bras (texte officiel, texte compilé et programme compilé plus runtime) séparent la représentation du runtime sur des tâches identiques à travers six modèles couvrant les niveaux de capacité.

• offtext : le texte de contrainte verbalisé officiel du benchmark, résident à chaque tour (la référence SOP comme prompt).
• flat : le texte complet du programme compilé, résident à chaque tour (représentation compilée sans le runtime).
• pg : le même programme compilé exécuté par le runtime PG avec pagination d'instructions juste-à-temps.

Les résultats sur Bank, le principal domaine d'attribution (125 tâches propres), montrent que remplacer le texte SOP officiel par le texte du programme compilé élève le taux de réussite de DeepSeek-V4-Flash de 70,4 % à 86,4 % (+16,0 points ; 26:6, p < 0,001). Activer le runtime PG sur le même programme ajoute 6,4 points supplémentaires, atteignant 92,8 % sur le sous-ensemble propre, avec une exactitude de refus de 100 % (86/86). La décomposition révèle que la compilation et la pagination achètent principalement un comportement de refus correct pour un modèle fort : l'exécution bouge peu (74,4 % à 71,8 % à 76,9 %), tandis que le refus passe de 68,6 % à 93,0 % à 100 %.

Une porte de capacité émerge

À travers six modèles, l'effet du runtime n'est pas un bruit autour de zéro. Il couvre une plage signée allant de +6,4 (DeepSeek-V4-Flash, p = 0,021) et +3,2 (n.s.) pour les modèles forts, via une paire de sondes du même fournisseur de part et d'autre de zéro, jusqu'à -14,4 (p = 0,011) pour Qwen2.5-7B et -26,4 (GPT-4o-mini, p < 0,001). En regroupant les deux modèles forts, on obtient 15:3 discordants (p = 0,016) ; les deux modèles faibles sont indépendamment significativement négatifs. Des réexécutions de configuration identique maintiennent chaque modèle du même côté de zéro.

Le schéma s'étend à tous les sept domaines. Pour les modèles forts V4 et Plus, les discordants regroupés atteignent 58:19 (p environ 10^-5) et 75:31 (p = 2,3 x 10^-5), sans aucun domaine inversant significativement son signe. Les modèles faibles sont pénalisés partout, regroupés à 59:237 pour le 7B (p environ 10^-26).

Découpler la compilation : contenu vs. format

La compilation ajoute du contenu (recettes de vérification, fermeture de porte-vérificateur, discipline de preuve) et reformate la politique sous forme de code. Une conception 2x2 (contenu officiel ou compilé x prose ou code) sépare les deux. L'effet du format change de signe : reformater la prose officielle en code gagne +14,4 points pour le modèle fort mais coûte -12,8 points au modèle faible. L'effet du contenu à format de prose fixe est de +17,6 pour le modèle fort mais non détecté pour le faible (+2,4, n.s.). Une fois le contenu compilé, le format cesse d'importer (flat vs. c-prose : -1,6 et +0,8, tous deux n.s.). Pour les praticiens : la représentation compilée ne nuit jamais significativement ; le contenu isolé paie au-dessus d'une ligne de capacité basse ; la syntaxe de code doit être réservée aux modèles qu'elle aide démontrablement.

Pourquoi le runtime est une porte : discipline, pas reconstruction

Des sondes de reconstruction d'état dirigées marquent les quatre modèles sondés près du plafond (0,91 à 0,99), y compris les deux perdants du runtime. La porte n'est pas une incapacité à reconstruire l'état quand on le demande. Un audit non sollicité, mesurant le nombre moyen d'appels de domaine émis après que l'action but a déjà réussi, sépare les pénalisés des non pénalisés avec une règle de signe unique : les deux modèles significativement pénalisés sont exactement ceux avec des signatures positives (+0,37, +0,57) ; les quatre non pénalisés portent des valeurs négatives (-0,14 à -0,49). La capacité de reconstruction est présente partout où elle est sondée ; la discipline d'état spontanée est ce que la porte du runtime suit.

Des mesures au niveau de l'attention confirment l'écart. DeepSeek-V4-Flash accorde spontanément à son cadre de 2,1 % du contexte une part à parité (1,05 contre 0,96 pour flat), et l'ablation de tout l'historique de dialogue augmente la log-probabilité de l'action d'or de 1,9 nats. Qwen2.5-7B donne au cadre seulement 0,15x de parité sur ses propres trajectoires mais 0,87 lorsqu'il est présenté proprement. C'est un écart de déploiement de capacité au niveau de l'attention.

Conseils de déploiement

Les résultats rejettent l'idée que plus d'échafaudage est toujours meilleur. Compilez lorsque la prose officielle est sous-performante ; utilisez la syntaxe de code seulement après une vérification au niveau du modèle, et la pagination seulement après une vérification de discipline. Les modèles forts bénéficient de la saillance du cadre actif (la plupart du gain de refus est récupérable en plaçant le cadre actif en premier tout en conservant le programme complet), avec un gain plus petit centré sur le refus provenant de la visibilité sélective. Pour les modèles faibles, utilisez le harnais d'exécution fort sans guidage de cadre actif. La pagination est douce et vérifiable, donc les actions irréversibles nécessitent toujours des protections dures au niveau de l'outil.