Iterative Audit Convergence in LLM-Managed Multi-Agent Systems: A Case Study in Prompt Engineering Quality Assurance

Resumen Técnico: Convergencia de Auditoría Iterativa en Sistemas Multiagente Gestionados por LLM

Enunciado del Problema
Las especificaciones de prompts para sistemas de Grandes Modelos de Lenguaje (LLM) multiagente funcionan como la fuente de verdad del sistema, conteniendo contratos de datos, lógica de integración y reglas de comportamiento a través de archivos interdependientes. A diferencia del código fuente tradicional, estas especificaciones en lenguaje natural rara vez se someten a un rigor de inspección estructurada. En pipelines de orquestación complejos y de múltiples carriles, los cambios de diseño en un documento a menudo crean efectos dominó (por ejemplo, referencias obsoletas, incompatibilidades de esquema o contratos de API inválidos) en otros. Las revisiones tradicionales de un solo archivo son insuficientes por construcción, ya que no pueden detectar inconsistencias entre documentos. Este artículo aborda la falta de datos empíricos sobre la densidad de defectos y el comportamiento de convergencia de la auditoría iterativa aplicada a especificaciones de prompts a escala de producción.

Metodología
El estudio presenta un caso de estudio empírico de un solo sistema del AEGIS (Sistema Autónomo de Gobernanza e Inteligencia de Ingeniería), un pipeline de orquestación de producción de siete carriles. La superficie de especificación consistió en aproximadamente 7.150 líneas distribuidas en ocho archivos: siete archivos PROMPT.md específicos por carril y un TICKET_CONTRACT.md compartido.

La metodología de auditoría siguió un enfoque estructurado e iterativo adaptado de las tradiciones de inspección de software (específicamente las revisiones de Weinberg y Freedman en lugar de inspecciones completas de Fagan):

• Auditor: Subagentes de Claude (la misma familia de LLM que redactó las especificaciones) actuaron como inspectores.
• Protocolo: Se realizaron nueve rondas de auditoría secuenciales durante cinco semanas. El protocolo evolucionó durante el estudio: las rondas iniciales se centraron en verificaciones estructurales por archivo, mientras que las rondas posteriores cargaron explícitamente las especificaciones de productores y consumidores juntos para realizar comparaciones entre carriles.
• Lista de verificación: Una lista de verificación de siete dimensiones guió a los agentes, abarcando consistencia de versiones, alineación de contratos de datos entre carriles, límites de permisos de Jira, convenciones de etiquetas, propagación de conteo de carriles, alineación de cadencia y contradicciones internas.
• Criterio de convergencia: El bucle terminó cuando una auditoría de alcance completo (los ocho archivos) devolvió cero hallazgos. El estudio señala que el protocolo de auditoría co-evolucionó con el descubrimiento de defectos, lo que significa que la "función de auditoría" cambió a lo largo de las rondas.

Contribuciones Clave
El artículo ofrece tres contribuciones acotadas derivadas estrictamente del caso de estudio:

1. Taxonomía de Defectos (C1): Una taxonomía posterior de siete categorías de 51 defectos detectados, incluyendo reglas de codificación explícitas y ejemplos representativos. Las categorías son: Deriva de Versión, Referencias de Jira Obsoletas, Incompatibilidad de Esquema entre Carriles, Cobertura Faltante de Extensión Reciente (Carril 7), Brechas de Etiqueta/Contrato, Texto Semánticamente Engañoso y Deriva de Fórmula/Horarios.
2. Comportamiento de Convergencia Observado (C2): Datos empíricos que muestran una convergencia no monótona. Los conteos de defectos por ronda fueron 15, 8, 12, 2, 8, 1, 4, 1 y 0. El artículo interpreta los aumentos en las rondas 3 y 5 no como regresiones, sino como el resultado de la expansión del alcance de la auditoría (por ejemplo, pasar de verificaciones de un solo archivo a verificaciones entre carriles), lo que reveló inconsistencias previamente enmascaradas.
3. Protocolo de Auditoría Destilado (C3): Un protocolo reproducible, que incluye una lista de verificación bloqueada, una plantilla de prompt, un esquema de hallazgos y un criterio de convergencia recomendado (dos pases limpios consecutivos, más estricto que la regla de un solo pase utilizada en el estudio).

Resultados

• Descubrimiento de Defectos: El proceso iterativo puso al descubierto 51 defectos distintos de consistencia en las especificaciones de prompts. Esto es distinto de los 51 hallazgos de código adversarial categorizados por STRIDE reportados en un preprint complementario; el estudio actual se centra en la consistencia de la especificación (por ejemplo, deriva de versiones, referencias obsoletas) en lugar de vulnerabilidades de seguridad en tiempo de ejecución.
• Distribución de Defectos: La categoría más prevalente fue Referencias de Jira obsoletas (12 defectos, 23,5%), lo que refleja cambios arquitectónicos donde se eliminó la creación de tickets de Jira de un carril específico. Las incompatibilidades de esquema entre carriles (5 defectos, 9,8%) se codificaron como de alta severidad porque podían causar fallos silenciosos en tiempo de ejecución (por ejemplo, un productor emitiendo priority_score mientras un consumidor espera fix_priority).
• Densidad de Defectos: El estudio calculó una densidad de aproximadamente 7,1 defectos por mil líneas de especificación.
• Dinámica de Convergencia: La revisión de un solo archivo pasó por alto completamente las incompatibilidades de esquema entre carriles. Estos defectos solo surgieron en rondas posteriores (4–8) cuando el alcance de la auditoría se expandió para incluir visibilidad multiarchivo. El estudio observó que la corrección de problemas estructurales en las rondas iniciales a veces revelaba inconsistencias semánticas que previamente estaban enmascaradas.

Significado y Afirmaciones
El artículo hace tres afirmaciones modestas y acotadas al caso:

1. Limitación de la Revisión de un Solo Archivo: En este sistema, la revisión de un solo archivo pasó por alto clases de defectos entre documentos por construcción.
2. Convergencia No Monótona: La trayectoria de convergencia observada fue no monótona, consistente con la hipótesis de que las ediciones en cascada y la expansión de los alcances de auditoría revelan defectos en oleadas en lugar de una disminución lineal.
3. Co-evolución del Protocolo: El propio protocolo de auditoría co-evolucionó con las correcciones; la versión "bloqueada" proporcionada en el apéndice es el estado recomendado para la replicación.

Los autores declaran explícitamente que la generalización requiere replicación con LLMs disímiles y revisores humanos para descartar puntos ciegos compartidos (ya que la misma familia de LLM redactó y auditó las especificaciones). No afirman que la revisión de alcance completo de un solo pase sea universalmente insuficiente, solo que no se ejecutó como control en este estudio y que una terminación de un solo pase habría dejado sin resolver los defectos descubiertos posteriormente bajo su protocolo específico. El estudio posiciona las especificaciones de prompts como artefactos de software que requieren métodos de ciclo de vida y auditoría iterativa, distintos de las pruebas tradicionales o la auto-refinación de un solo contexto.