Resumen Técnico: PatchOptic para Flujos de Trabajo de LLM de Estado Compartido

Declaración del Problema

En los flujos de trabajo agénticos que operan sobre un estado compartido y estructurado, existe una discrepancia fundamental entre las ventanas de contexto limitadas de los Modelos de Lenguaje de Gran Escala (LLM) y los requisitos de validez global del sistema. Para gestionar el contexto, los sistemas emplean la divulgación progresiva, exponiendo solo el fragmento de estado necesario para un paso específico (por ejemplo, mediante RAG o consultas AST). Si bien esto gestiona el lado de la lectura, el lado de la escritura sigue siendo vulnerable.

Cuando un agente propone una actualización basándose únicamente en un fragmento local, carece del contexto global requerido para validar la actualización contra el estado completo. Esto conduce a dos familias primarias de fallos:

1. Fuga de Secretos: Valores protegidos irrelevantes para el paso actual entran en la vista del agente y se divulgan inadvertidamente en la salida.
2. Fallos de Legalidad de Compromiso: Los agentes proponen parches que están mal formados, violan restricciones de fase, escriben fuera de los alcances autorizados o derivan valores de rutas de estado no autorizadas (fuentes ocultas).

Los controles existentes, como los validadores de esquema o la decodificación restringida, abordan la sintaxis o estructura local, pero no logran verificar la procedencia de los valores del estado ni la validez global de una transición. Existe una falta de un "contrato" que conecte las reescrituras locales con la validez global y se componga a través de flujos de trabajo de múltiples pasos y múltiples agentes.

Metodología: Diseño de PatchOptic

El artículo introduce PatchOptic, una interfaz inspirada en los ópticos que acopla lecturas proyectadas con actualizaciones estructuradas verificadas. El mecanismo central se basa en un contrato de paso definido por un triple de autoridad $(O_s, W_s, P_s)$:

• $O_s$ (Lectura Proyectada): Una proyección del estado compartido completo $x$ en una vista local $O_s(x)$ visible para el actor.
• $W_s$ (Región de Escritura): El conjunto de rutas de estado que el actor está autorizado a modificar.
• $P_s$ (Región de Fuente del Parche): El conjunto de rutas del estado actual que el actor está autorizado a leer durante la aplicación del parche (por ejemplo, para operaciones copy, move o test en JSON Patch).

Ejecución en Tiempo de Ejecución

La ruta de ejecución funciona de la siguiente manera:

1. Proyección: El actor recibe únicamente la vista proyectada $O_s(x)$, ocultando campos sensibles.
2. Propuesta: El actor genera una propuesta de mutación (implementada como un JSON Patch).
3. Verificación: Antes de realizar el compromiso, un verificador comprueba la propuesta contra el estado completo $x$ utilizando cuatro puertas:
   • Alcance: Asegura que los objetivos de escritura y las rutas de fuente del parche (incluyendo las rutas from para move) permanezcan dentro de $W_s$ y $P_s$.
   • Fase: Valida que el paso esté permitido en la fase actual del flujo de trabajo.
   • Esquema: Comprueba la validez estructural y los contratos de salida.
   • Invariantes: Verifica que los invariantes del flujo de trabajo se mantengan tras la mutación.
4. Compromiso/Rechazo: El estado muta solo si todas las puertas pasan; de lo contrario, la propuesta es rechazada y el estado permanece sin cambios.

Álgebra de Huella Estática

Más allá del tiempo de ejecución, la declaración del paso produce una huella estática $(R_s, W_s, P_s)$ (donde $R_s$ es la región de lectura realizada). Esto permite el análisis estático antes de que los actores se ejecuten:

• Restricción: Soporta la delegación al estrechar las huellas para sub-actores.
• Unión: Soporta la composición de pares combinando las huellas.
• Certificado de Conmutación: Permite el reordenamiento seguro de pasos independientes dentro de la misma fase. Dos pasos pueden reordenarse si sus regiones de escritura son disjuntas y ninguno lee lo que el otro escribe ($W_A \perp W_B$, $R_A \perp W_B$, $R_B \perp W_A$).

Contribuciones Clave

1. Mecanismo de Tiempo de Ejecución: Un sistema que acopla vistas proyectadas con escrituras de parches JSON verificadas sobre un estado compartido, produciendo trazas estructuradas de vistas, propuestas y decisiones del verificador.
2. Álgebra de Huella: Un formalismo para las regiones declaradas de lectura, escritura y fuente de parche que permite la delegación, la composición y los certificados estáticos para el reordenamiento de pasos independientes.
3. PatchBench: Un benchmark de 46 casos creados a mano en seis dominios (finanzas, marketing, medicina, ciencia, software, soporte). Evalúa el diseño separando las ejecuciones de actores vivos de las pruebas "sin modelo" utilizando artefactos comprometidos.

Resultados Empíricos

La evaluación se realizó utilizando un actor fuerte (GPT-5-mini) y un actor débil (Mistral 7B) a través de seis configuraciones (Sin Restricciones, Solo Esquema, FSM+ACL, Solo Vista, Solo Verificación, PatchOptic).

• Reducción de Fugas: Las lecturas proyectadas redujeron significativamente las fugas reportadas. Bajo GPT-5-mini, las configuraciones de estado completo tuvieron una tasa de fuga de ~31.5%, mientras que PatchOptic redujo esto a 0.2% (la media de ejecuciones con fugas cayó de ~14.5 a 0.1 por ronda).
• Eficiencia de Tokens: Las configuraciones de lectura proyectada utilizaron entre un 11% y un 13% menos de tokens por ejecución en comparación con las configuraciones de estado completo.
• Calidad de Salida: Bajo el actor fuerte, las lecturas proyectadas no degradaron la calidad de la salida aceptada (el Puntaje de Contenido se mantuvo en ~0.927). En consecuencia, la tasa de Paso Semántico (calidad + sin fugas) aumentó de ~0.61 (Sin Restricciones) a 0.78–0.80 (PatchOptic).
• Eficacia de la Verificación: La verificación en tiempo de ejecución bloqueó con éxito las violaciones de contrato declaradas (errores de fase y alcance) antes del compromiso. En la prueba de estrés "sin modelo", PatchOptic y Solo Verificación rechazaron el 100% de los artefactos comprometidos que intentaban citar rutas de origen ocultas, mientras que las configuraciones sin comprobaciones de fuente de parche (por ejemplo, FSM+ACL) aceptaron 8 de 9 de tales artefactos.
• Comportamiento del Actor Débil: Para el actor más débil, Mistral, PatchOptic logró la mayor Tasa de Paso Semántico (0.690) al combinar la proyección (que evitó la fuga) con la verificación (que bloqueó parches inválidos), compensando la menor calidad intrínseca del modelo.

Significancia y Reivindicaciones

El artículo afirma que PatchOptic proporciona un "contrato" necesario entre las acciones locales del modelo y la validez global del sistema. Su importancia radica en:

• Desacoplamiento de la Observación del Compromiso: Separa explícitamente lo que el actor puede observar (vista proyectada) de lo que el tiempo de ejecución comprometerá (parche verificado), evitando que el modelo tenga que portar obligaciones de seguridad globales.
• Componibilidad: El álgebra de huella permite la verificación estática de la delegación, la composición y el reordenamiento, permitiendo un escalado más seguro de los flujos de trabajo de múltiples agentes.
• Defensa en Profundidad: Al combinar la proyección (que evita que el actor vea secretos) con la aplicación de la fuente del parche (que evita que el parche lea secretos incluso si el actor está comprometido o el artefacto es inyectado), el sistema aborda tanto los riesgos de inyección de prompts como los riesgos de artefactos comprometidos.

Los autores reconocen las limitaciones, señalando que el sistema confía en el autor de la política (si el contrato es erróneo, el sistema aplica el contrato erróneo) y no previene errores semánticos o divulgaciones autorizadas por la política. Sin embargo, postulan que PatchOptic establece una capa de control fundamental para el despliegue seguro de agentes de LLM en sistemas de gran escala con estado compartido.