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

Riepilogo Tecnico: Convergenza dell'Audit Iterativo in Sistemi Multi-Agente Gestiti da LLM

Enunciato del Problema
Le specifiche dei prompt per i sistemi multi-agente basati su Modelli Linguistici di Grande Dimensione (LLM) fungono da fonte di verità del sistema, contenendo contratti di dati, logica di integrazione e regole comportamentali attraverso file interdipendenti. A differenza del codice sorgente tradizionale, queste specifiche in linguaggio naturale sono raramente sottoposte a un rigore strutturato di ispezione. In pipeline di orchestrazione complesse e multi-lane, le modifiche di progettazione in un documento spesso generano effetti a catena (ad esempio, riferimenti obsoleti, discrepanze negli schemi o contratti API non validi) negli altri. Le revisioni tradizionali su singolo file sono insufficienti per costruzione, poiché non possono rilevare incoerenze tra documenti. Questo lavoro affronta la mancanza di dati empirici sulla densità dei difetti e sul comportamento di convergenza dell'audit iterativo applicato a specifiche di prompt su scala produttiva.

Metodologia
Lo studio presenta un caso empirico su un singolo sistema, l'AEGIS (Autonomous Engineering Governance and Intelligence System), una pipeline di orchestrazione produttiva a sette lane. La superficie delle specifiche consisteva in circa 7.150 righe distribuite su otto file: sette file PROMPT.md specifici per lane e un file TICKET_CONTRACT.md condiviso.

La metodologia di audit ha seguito un approccio strutturato e iterativo, adattato dalle tradizioni di ispezione del software (nello specifico, le walkthrough di Weinberg e Freedman piuttosto che le ispezioni complete di Fagan):

• Auditor: Sottogentili Claude (la stessa famiglia di LLM che ha redatto le specifiche) hanno agito come ispettori.
• Protocollo: Sono stati condotti nove round sequenziali di audit nell'arco di cinque settimane. Il protocollo è evoluto durante lo studio: i primi round si sono concentrati su controlli strutturali per file, mentre i round successivi hanno caricato esplicitamente le specifiche di produttore e consumatore insieme per eseguire confronti tra lane.
• Checklist: Una checklist a sette dimensioni ha guidato gli agenti, coprendo la coerenza delle versioni, l'allineamento dei contratti di dati tra lane, i limiti delle autorizzazioni Jira, le convenzioni di etichettatura, la propagazione del conteggio delle lane, l'allineamento della cadenza e le contraddizioni interne.
• Criterio di Convergenza: Il ciclo si è interrotto quando un audit a scope completo (tutti gli otto file) ha restituito zero riscontri. Lo studio nota che il protocollo di audit è co-evoluto con la scoperta dei difetti, il che significa che la "funzione di audit" è cambiata tra i round.

Contributi Chiave
Il lavoro offre tre contributi delimitati derivati strettamente dal caso di studio:

1. Tassonomia dei Difetti (C1): Una tassonomia a posteriori a sette categorie di 51 difetti emersi, inclusi regole di codifica esplicite ed esempi rappresentativi. Le categorie sono: Deriva delle Versioni, Riferimenti Jira Obsoleti, Discrepanza dello Schema tra Lane, Mancata Copertura delle Estensioni Recenti (Lane 7), Lacune Etichetta/Contratto, Testo Semanticamente Fuorviante e Deriva della Formula/Timing.
2. Comportamento di Convergenza Osservato (C2): Dati empirici che mostrano una convergenza non monotona. I conteggi dei difetti per round sono stati: 15, 8, 12, 2, 8, 1, 4, 1 e 0. Il lavoro interpreta gli aumenti nei round 3 e 5 non come regressioni, ma come risultato dell'espansione dello scope dell'audit (ad esempio, il passaggio da controlli su singolo file a controlli tra lane) che ha rivelato incoerenze precedentemente mascherate.
3. Protocollo di Audit Distillato (C3): Un protocollo riproducibile, comprendente una checklist bloccata, un modello di prompt, uno schema dei riscontri e un criterio di convergenza raccomandato (due passaggi consecutivi puliti, più rigoroso della regola del passaggio singolo utilizzata nello studio).

Risultati

• Scoperta dei Difetti: Il processo iterativo ha portato alla luce 51 difetti distinti di coerenza delle specifiche dei prompt. Questo è distinto dai 51 riscontri di codice avversario categorizzati STRIDE riportati in un preprint companion; lo studio attuale si concentra sulla coerenza delle specifiche (ad esempio, deriva delle versioni, riferimenti obsoleti) piuttosto che sulle vulnerabilità di sicurezza runtime.
• Distribuzione dei Difetti: La categoria più prevalente è stata Riferimenti Jira Obsoleti (12 difetti, 23,5%), riflettendo cambiamenti architetturali in cui la creazione di ticket Jira è stata rimossa da una specifica lane. Le discrepanze degli schemi tra lane (5 difetti, 9,8%) sono state codificate come ad alta severità perché potevano causare fallimenti runtime silenziosi (ad esempio, un produttore che emette priority_score mentre un consumatore si aspetta fix_priority).
• Densità dei Difetti: Lo studio ha calcolato una densità di circa 7,1 difetti per mille righe di specifica.
• Dinamiche di Convergenza: La revisione su singolo file ha mancato completamente le discrepanze degli schemi tra lane. Questi difetti sono emersi solo nei round successivi (4–8) quando lo scope dell'audit è stato ampliato per includere la visibilità multi-file. Lo studio ha osservato che la correzione di problemi strutturali nei primi round ha talvolta rivelato incoerenze semantiche che erano precedentemente mascherate.

Significato e Affermazioni
Il lavoro avanza tre affermazioni modeste e delimitate dal caso:

1. Limitazione della Revisione su Singolo File: In questo sistema, la revisione su singolo file ha mancato per costruzione classi di difetti tra documenti.
2. Convergenza Non Monotona: Il percorso di convergenza osservato è stato non monotono, coerente con l'ipotesi che le modifiche a cascata e l'espansione degli scope di audit rivelino i difetti a ondate piuttosto che in un declino lineare.
3. Co-evoluzione del Protocollo: Il protocollo di audit stesso è co-evoluto con le correzioni; la versione "bloccata" fornita nell'appendice rappresenta lo stato raccomandato per la replicazione.

Gli autori dichiarano esplicitamente che la generalizzazione richiede la replicazione con LLM dissimili e revisori umani per escludere punti ciechi condivisi (poiché la stessa famiglia di LLM ha redatto e auditato le specifiche). Non affermano che la revisione completa su passaggio singolo sia universalmente insufficiente, ma solo che non è stata eseguita come controllo in questo studio e che la terminazione su un singolo passaggio avrebbe lasciato irrisolti i difetti scoperti in seguito sotto il loro protocollo specifico. Lo studio posiziona le specifiche dei prompt come artefatti software che richiedono metodi di ciclo di vita e audit iterativi, distinti dai test tradizionali o dall'autoraffinamento in un singolo contesto.