🤖 machine learning

PatchOptic for Shared-State LLM Workflows with Projected Views and Verified Structured Updates

Cet article introduit PatchOptic, une interface inspirée de l'optique pour les flux de travail de LLM à état partagé qui assure la validité globale des mises à jour locales grâce à des lectures projetées et des correctifs structurés vérifiés, tout en permettant des garanties statiques pour la composition de flux de travail et en réduisant les coûts de jetons sans compromettre la qualité de la sortie.

Auteurs originaux : Zhaoyu Bai, Jiaqi Cai

Publié 2026-07-08

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Zhaoyu Bai, Jiaqi Cai

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes le gestionnaire d'une immense bibliothèque numérique partagée. Cette bibliothèque contient tout : des plans secrets, des fichiers privés d'utilisateurs, des dossiers financiers et des actualités publiques. Vous engagez une équipe d'assistants IA très intelligents, mais parfois distraits ou malicieux (les « acteurs ») pour vous aider à organiser cette bibliothèque.

Le problème est que la bibliothèque est trop grande pour qu'un seul assistant puisse tout voir d'un coup. Si vous leur montrez toute la bibliothèque, ils pourraient accidentellement (ou volontairement) divulguer un plan secret dans un rapport public. Si vous ne leur montrez qu'une petite page, ils pourraient essayer de déplacer un livre vers une étagère qu'ils n'ont pas le droit de toucher, ou tenter de copier une page secrète dans leur rapport sans que vous ne vous en rendiez compte.

PatchOptic est un nouveau système conçu pour résoudre ce désordre. Il agit comme un garde de sécurité strict et invisible, doublé d'un bibliothécaire intelligent. Voici comment il fonctionne, en utilisant des analogies simples :

1. Le « Projecteur » (Lectures Projetées)

Imaginez que vous avez un projecteur qui éclaire uniquement la page spécifique du livre de la bibliothèque sur laquelle l'assistant doit travailler en ce moment.

Sans PatchOptic : Vous donnez le livre entier à l'assistant. Il pourrait voir une note secrète dans la marge et l'ajouter accidentellement dans son résumé.
Avec PatchOptic : Le projecteur ne montre à l'assistant que le paragraphe dont il a besoin. Le reste du livre est invisible pour lui. C'est ce qu'on appelle la Lecture Projetée (Projected Read). Cela empêche l'assistant de même voir les secrets, afin qu'il ne puisse pas les divulguer. Cela permet aussi de gagner du temps (des jetons/tokens) car l'assistant n'a pas besoin de lire tout le livre.

2. Le « Garde de Sécurité » (Mises à jour structurées vérifiées)

Une fois que l'assistant a terminé sa tâche, il ne se contente pas de s'approcher de l'étagère pour commencer à déplacer des choses. Au lieu de cela, il rédige une demande formelle sur un formulaire spécial (un « Patch »).

La Demande : L'assistant dit : « Je veux déplacer le livre de l'Étagère A vers l'Étagère B. »
Le Rôle du Garde : Avant que le livre ne soit réellement déplacé, un garde de sécurité (le Vérificateur) vérifie la demande par rapport aux règles de toute la bibliothèque, et non pas seulement par rapport à ce que l'assistant a vu.
- A-t-il essayé de déplacer un livre vers une étagère interdite ? (Vérification de la portée / Write Scope Check)
- A-t-il essayé de déplacer un livre provenant d'une section secrète qu'il n'était pas autorisé à toucher ? (Vérification de la source du patch / Patch-Source Check)
- Est-ce le bon moment de la journée pour déplacer des livres ? (Vérification de phase / Phase Check)
- Le nouvel arrangement enfreint-il les règles de la bibliothèque ? (Vérification d'invariant / Invariant Check)

Si la demande enfreint une règle, le garde dit « Non », et le livre reste exactement là où il était. L'assistant n'a jamais accès à la vraie bibliothèque tant qu'il n'a pas passé tous les contrôles.

3. Le « Plan » (Empreintes)

Avant même que les assistants ne commencent à travailler, le système dessine un « plan » (appelé Empreinte ou Footprint) pour chaque tâche. Ce plan liste précisément :

Ce que l'assistant est autorisé à lire.
Ce qu'il est autorisé à écrire.
Ce qu'il est autorisé à copier à partir de.

Cette empreinte permet au gestionnaire de faire deux choses géniales :

Délégation : Si vous voulez embaucher un nouvel assistant moins expérimenté, vous pouvez lui donner une version « plus petite » du plan. Il ne pourra accomplir qu'une infime partie du travail, et le système saura exactement ce qu'il peut toucher ou non.
Réordonnancement : Si deux assistants travaillent sur des parties différentes de la bibliothèque qui ne se chevauchent pas (comme l'un qui répare la section fiction et l'autre la section science), le système sait qu'ils peuvent travailler dans n'importe quel ordre sans créer de désordre. C'est comme savoir que deux peintres peuvent peindre des murs différents en même temps sans se cogner.

Ce que l'étude a révélé

Les auteurs ont testé ce système (appelé PatchOptic) par rapport à une méthode standard en utilisant une suite de tests appelée PatchBench (46 scénarios différents couvrant la finance, la médecine, le logiciel, etc.).

Voici ce qui s'est passé :

Moins de fuites : Lorsque les assistants ne pouvaient voir que la partie « projetée » de la bibliothèque, ils ont divulgué des secrets presque 100 % de moins que lorsqu'ils voyaient l'ensemble.
Moins coûteux : Comme ils n'avaient pas besoin de lire toute la bibliothèque, le système a utilisé moins de puissance de calcul (moins de « jetons/tokens »).
Meilleure sécurité : Lorsque les assistants tentaient des mouvements illégaux (comme copier un fichier secret), le « Garde de Sécurité » les a arrêtés à chaque fois avant que le changement ne soit effectué.
Qualité : Les assistants ont tout de même bien accompli leurs tâches. Ils n'ont pas été perturbés par le fait de voir moins de choses ; ils se sont simplement concentrés sur ce qu'ils étaient autorisés à voir.

L'essentiel

PatchOptic est un moyen de laisser des assistants IA travailler sur de grandes bases de données partagées sans avoir à leur faire une confiance aveugle. Cela stipule que :

Montrez-leur uniquement ce dont ils ont besoin (pour qu'ils ne puissent pas voler de secrets).
Vérifiez leur travail par rapport à l'ensemble du système avant de permettre des changements (pour qu'ils ne puissent pas enfreindre les règles).
Gardez une trace écrite de tout ce qu'ils ont été autorisés à faire (pour pouvoir les auditer plus tard).

Cela transforme la tâche risquée de « demander à une IA de réparer une base de données partagée » en un processus sûr et contrôlé où l'IA est l'ouvrier, mais le système est le patron.

Résumé Technique : PatchOptic pour les flux de travail LLM à état partagé

Problématique

Dans les flux de travail agentiques opérant sur un état partagé et structuré, il existe un décalage fondamental entre les fenêtres de contexte limitées des grands modèles de langage (LLM) et les exigences de validité globale du système. Pour gérer le contexte, les systèmes emploient la divulgation progressive, n'exposant que le fragment d'état nécessaire à une étape spécifique (par exemple, via RAG ou des requêtes AST). Si cela gère le côté lecture, le côté écriture reste vulnérable.

Lorsqu'un agent propose une mise à jour basée uniquement sur un fragment local, il manque du contexte global requis pour valider la mise à jour par rapport à l'état complet. Cela conduit à deux familles de défaillances primaires :

Fuite de secrets : Des valeurs protégées non pertinentes pour l'étape actuelle entrent dans le champ de vision de l'agent et sont divulguées par inadvertance dans la sortie.
Échecs de légalité de commit : Les agents proposent des correctifs (patches) qui sont malformés, violent les contraintes de phase, écrivent en dehors des périmètres autorisés ou dérivent des valeurs de chemins d'état non autorisés (sources cachées).

Les contrôles existants comme les validateurs de schéma ou le décodage contraint traitent la syntaxe ou la structure locale, mais échouent à vérifier la provenance des valeurs d'état ou la validité globale d'une transition. Il manque un « contrat » qui relie les réécritures locales à la validité globale et qui se compose à travers des flux de travail multi-étapes et multi-agents.

Méthodologie : Conception de PatchOptic

Le document introduit PatchOptic, une interface inspirée des optiques qui couple les lectures projetées avec des mises à jour structurées vérifiées. Le mécanisme central repose sur un contrat d'étape défini par un triple d'autorité $(O_s, W_s, P_s)$ :

$O_s$ (Lecture Projetée) : Une projection de l'état partagé complet $x$ en une vue locale $O_s(x)$ visible par l'acteur.
$W_s$ (Région d'Écriture) : L'ensemble des chemins d'état que l'acteur est autorisé à modifier.
$P_s$ (Région de Source du Patch) : L'ensemble des chemins de l'état actuel que l'acteur est autorisé à lire lors de l'application du patch (par exemple, pour les opérations copy, move ou test dans JSON Patch).

Application au Runtime

Le chemin d'exécution du runtime fonctionne comme suit :

Projection : L'acteur reçoit uniquement la vue projetée $O_s(x)$ , masquant les champs sensibles.
Proposition : L'acteur génère une proposition de mutation (implémentée sous forme de JSON Patch).
Vérification : Avant le commit, un vérificateur contrôle la proposition par rapport à l'état complet $x$ $x$ via quatre portes :
- Périmètre (Scope) : S'assure que les cibles d'écriture et les chemins sources du patch (y compris les chemins from pour move) restent dans $W_s$ et $P_s$ .
- Phase : Valide que l'étape est autorisée dans la phase actuelle du flux de travail.
- Schéma : Vérifie la validité structurelle et les contrats de sortie.
- Invariants : Vérifie que les invariants du flux de travail sont respectés après la mutation.
Commit/Rejet : L'état ne mute que si toutes les portes passent ; sinon, la proposition est rejetée et l'état reste inchangé.

Algèbre de l'Empreinte Statique

Au-delà du runtime, la déclaration de l'étape produit une empreinte statique $(R_s, W_s, P_s)$ (où $R_s$ est la région de lecture réalisée). Cela permet une analyse statique avant l'exécution des acteurs :

Restriction : Permet la délégation en rétrécissant les empreintes pour les sous-acteurs.
Union : Permet la composition par pairs en combinant les empreintes.
Certificat de Commutation : Permet le réordonnancement sûr d'étapes indépendantes au sein d'une même phase. Deux étapes peuvent être réordonnées si leurs régions d'écriture sont disjointes et qu'aucune ne lit ce que l'autre écrit ( $W_A \perp W_B$ , $R_A \perp W_B$ , $R_B \perp W_A$ ).

Contributions Clés

Mécanisme de Runtime : Un système couplant des vues projetées avec des écritures JSON Patch vérifiées sur un état partagé, produisant des traces structurées des vues, des propositions et des décisions du vérificateur.
Algèbre d'Empreinte : Un formalisme de régions déclarées de lecture, d'écriture et de source de patch qui supporte la délégation, la composition et les certificats statiques pour le réordonnancement.
PatchBench : Un benchmark de 46 cas conçus à la main à travers six domaines (finance, marketing, médical, science, logiciel, support). Il évalue la conception en séparant les exécutions d'acteurs réels des tests « sans modèle » utilisant des artefacts compromis.

Résultats Empiriques

L'évaluation a été menée avec un acteur fort (GPT-5-mini) et un acteur plus faible (Mistral 7B) à travers six configurations (Unconstrained, Schema Only, FSM+ACL, View Only, Verify Only, PatchOptic).

Réduction de la Fuite : Les lectures projetées ont considérablement réduit la fuite signalée. Sous GPT-5-mini, les configurations à état complet présentaient un taux de fuite d'environ 31,5 %, tandis que PatchOptic a réduit ce taux à 0,2 % (la moyenne des fuites par tour est passée d'environ 14,5 à 0,1).
Efficacité des Tokens : Les configurations de lecture projetée ont utilisé 11 à 13 % de tokens en moins par exécution par rapport aux configurations à état complet.
Qualité de Sortie : Sous l'acteur fort, les lectures projetées n'ont pas dégradé la qualité des sorties acceptées (le score de contenu est resté à ~0,927). Par conséquent, le taux de réussite sémantique (qualité + absence de fuite) est passé d'environ 0,61 (Unconstrained) à 0,78–0,80 (PatchOptic).
Efficacité de la Vérification : La vérification au runtime a bloqué avec succès les violations de contrat déclarées (erreurs de phase et de périmètre) avant le commit. Dans le test de stress « sans modèle », PatchOptic et Verify Only ont rejeté 100 % des artefacts compromis tentant de citer des chemins sources cachés, alors que les configurations sans vérification de source de patch (ex: FSM+ACL) en ont accepté 8 sur 9.
Comportement de l'Acteur Faible : Pour l'acteur plus faible Mistral, PatchOptic a obtenu le taux de réussite sémantique le plus élevé (0,690) en combinant la projection (qui empêche la fuite) avec la vérification (qui bloque les correctifs invalides), compensant ainsi la qualité intrinsèque moindre du modèle.

Signification et Revendications

L'article affirme que PatchOptic fournit un « contrat » nécessaire entre les actions locales du modèle et la validité globale du système. Sa signification réside dans :

Découplage de l'Observation et de l'Engagement : Il sépare explicitement ce que l'acteur peut observer (vue projetée) de ce que le runtime va valider (patch vérifié), évitant ainsi au modèle de porter des obligations de sécurité globales.
Composabilité : L'algèbre d'empreinte permet la vérification statique de la délégation, de la composition et du réordonnancement, permettant une mise à l'échelle plus sûre des flux de travail multi-agents.
Défense en Profondeur : En combinant la projection (empêchant l'acteur de voir les secrets) avec l'application du périmètre de source du patch (empêchant le patch de lire des secrets même si l'acteur est compromis ou si l'artefact est injecté), le système traite à la fois les risques d'injection de prompt et les risques d'artefacts compromis.

Les auteurs reconnaissent des limites, notant que le système fait confiance à l'auteur de la politique (si le contrat est erroné, le système applique le mauvais contrat) et ne prévient pas les erreurs sémantiques ou les divulgations autorisées par la politique. Cependant, ils postulent que PatchOptic établit une couche de contrôle fondamentale pour le déploiement sécurisé d'agents LLM dans de grands systèmes à état partagé.