Riepilogo Tecnico: AEVAL – Dal Test Anecdotico a quello Deterministico per i Workflow di Competenze Agenti

1. Definizione del Problema

I moderni sistemi agentici si affidano sempre più a competenze (skills): pacchetti installabili che contengono specifiche in linguaggio naturale (es. SKILL.md), script e configurazioni che insegnano agli agenti LLM come eseguire compiti di dominio. Con l'espandersi dei repository di competenze, il paradigma di valutazione attuale è aneddotico: gli sviluppatori attivano manualmente una competenza, osservano un'esecuzione demo e formano un'impressione soggettiva del suo successo.

Questo approccio soffre di tre criticità fondamentali:

1. Mancanza di Riproducibilità: Due esecuzioni consecutive possono esercitare percorsi di codice differenti o produrre output diversi, portando a giudizi inconsistenti da parte dello sviluppatore.
2. Mancanza di Comparabilità: Le impressioni soggettive non possono essere confrontate tra versioni diverse o tra Merge Request (MR).
3. Problemi di Scalabilità: Nei marketplace multi-competenza, un singolo regressione può rompere silenziosamente decine di workflow a valle.

Inoltre, un fallimento tecnico specifico affligge la valutazione agentica ingenua: il Bias di Auto-Correzione (Self-Correction Bias). Quando lo stesso agente sia esegue che valuta una competenza, spesso corregge silenziosamente la competenza o la sua configurazione durante l'esecuzione per recuperare dagli errori. L'agente valuta quindi il proprio output corretto come un successo. Ciò produce un segnale sistematicamente ottimistico che misura la capacità di debugging dell'agente piuttosto che la qualità intrinseca dell'artefatto della competenza.

2. Metodologia: Il Framework AEVAL

AEVAL (Agentic Evaluation) è un framework integrato nella CI progettato per sostituire il testing aneddotico con una pipeline di test deterministica, attivata dai cambiamenti, che esegue un workflow in cinque fasi:

2.1. Contratto di Valutazione Definito dalla Competenza

Ogni competenza include un file eval.config co-localizzato con la propria specifica. Questo contratto dichiara:

• Prompt in linguaggio naturale per i casi di test.
• Risultati attesi.
• Credenziali richieste.
• Un meccanismo di fallback a tre livelli garantisce la testabilità anche in assenza di una configurazione esplicita.

2.2. La Pipeline in Cinque Fasi

1. Esamina (Examine): Il sistema rileva le competenze modificate tramite git diff.
2. Installa (Install): La competenza modificata viene installata in una sessione pulita.
3. Usa (Esecuzione - Use): Un esecutore automatizzato esegue la competenza contro il contratto.
   • Vincolo: Una regola rigida proibisce gli output simulati. Se un comando fallisce o un servizio è irraggiungibile, il fallimento viene registrato come un risultato di test reale. Gli agenti non possono fabbricare log o sintetizzare risultati per superare le asserzioni.
4. Valuta (Grading - Evaluate): Viene imposta una separazione strutturale tra l'esecutore e il valutatore (grader).
   • Esecutore: Esegue la competenza e genera una trascrizione ($\tau$) e degli output ($O$).
   • Valutatore (Grader): Un sub-agente separato, limitato a un insieme di informazioni in sola lettura: il prompt di test ($x$), la trascrizione dell'esecuzione ($\tau$), gli output ($O$) e le asserzioni pre-esecuzione ($A$).
   • Regola di Valutazione al Primo Tentativo: Il valutatore valuta le asserzioni rispetto alla traiettoria del primo tentativo. Se l'esecutore ha applicato qualsiasi modifica di auto-correzione ($\Delta(\tau) \neq \emptyset$) che era causalmente necessaria affinché un'asserzione avesse successo, quell'asserzione è contrassegnata come FALLIMENTO (FAIL), indipendentemente dallo stato finale.
5. Suggerisce (Suggest): Il sistema genera suggerimenti di correzione basati sui risultati della valutazione.

2.3. Suggerimenti di Correzione Terziarizzati e Fondati

Per evitare il churn speculativo del tipo "nice-to-have", i suggerimenti sono strettamente fondati sulle evidenze:

• Fondamento (Grounding): Ogni suggerimento deve citare una specifica asserzione fallita o una voce di auto-correzione tracciata.
• Livelli (Tiering):
  • LV1 (Causale): Correzioni causalmente implicate nel fallimento del primo tentativo. Queste bloccano la merge request.
  • LV2 (Consulenziale/Advisory): Miglioramenti di qualità o robustezza identificati dal valutatore che non hanno causato un fallimento critico.
• Consegna: I suggerimenti vengono pubblicati come commenti inline nelle MR di GitLab con diff "Applica suggerimento", consentendo agli sviluppatori di applicare patch empiricamente validate con un singolo clic.

3. Contributi Principali

Il documento delinea quattro contributi primari:

1. Protocollo di Testing delle Competenze Deterministico: Un sistema di valutazione attivato dai cambiamenti con contratti per competenza e schemi di artefatti per ogni esecuzione, che sostituisce la valutazione manuale con una pipeline CI riproducibile.
2. Formalizzazione del Bias di Auto-Correzione: L'identificazione e la formalizzazione del bias di auto-correzione come un modo di fallimento distinto derivante dall'accoppiamento strutturale tra esecuzione e valutazione, piuttosto che da specifiche scelte del modello.
3. Separazione Strutturale e Valutazione al Primo Tentativo: Un protocollo che isola il valutatore dal ciclo di esecuzione e impone una regola di valutazione al primo tentativo. Ciò assicura che il segnale di qualità rifletta la competenza così come spedita, non la competenza come corretta dall'agente.
4. Suggerimenti Terziarizzati e Fondati: Un meccanismo per consegnare suggerimenti di correzione come commit di una riga nelle MR, strettamente legati all'evidenza causale (LV1) o al feedback consulenziale (LV2).

4. Risultati Empirici

Il framework è stato validato contro uno stack agentico di produzione e molteplici popolari SDK per agenti (inclusi agenti della famiglia Claude e GPT).

• Eliminazione del Bias: In un caso di studio riguardante una competenza di segmentazione deliberatamente degradata, un valutatore ingenuo ha riportato un tasso di successo del 100% dopo che l'agente ha silenziosamente corretto i nomi delle azioni. AEVAL ha registrato l'auto-correzione, ha contrassegnato le asserzioni rilevanti come FAIL e ha riportato un tasso di successo al primo tentativo strettamente inferiore alla CI.
• Stabilità: Prima della regola "fondato sulle evidenze", esecuzioni ripetute della stessa MR producevano set di suggerimenti disgiunti. Con la regola, le esecuzioni ripetute sono confluite sullo stesso set LV1 causalmente fondato.
• Divieto di Simulazione: Quando un cluster GPU a valle era irraggiungibile, le iterazioni precedenti producevano log sintetici. Sotto AEVAL, l'agente ha registrato il fallimento di connettività, permettendo alla CI a valle di distinguere i difetti della competenza dai fallimenti ambientali.
• Calibrazione Cross-Runtime: Il framework ha eseguito con successo la stessa competenza su diversi backend di agenti. Sebbene i tassi di successo grezzi variassero, la quota causale (la frazione di suggerimenti contrassegnati come bloccanti per la merge) ha fornito una metrica scalare riproducibile per confrontare la severità del valutatore. Il Backend A (famiglia Claude) aveva una quota causale media di 0.41, mentre il Backend B (famiglia GPT) di 0.82, rivelando differenze sistematiche nel modo in cui i diversi agenti interpretano la severità.
• Efficienza dei Costi: Con tassi di hit della cache dei prompt del 95–97%, il costo marginale dei token per riprodurre il protocollo ad ogni push è sufficientemente basso da supportare l'integrazione continua.

5. Significatività e Rivendicazioni

Il documento sostiene che AEVAL fornisce una garanzia strutturale che il segnale di valutazione è una funzione dell'esecuzione al primo tentativo piuttosto che dello stato post-correzione.

• Blocco Fondamentale: Gli autori posizionano il testing deterministico delle competenze non come una garanzia di copertura probabilistica (come la predizione conforme), ma come un componente a monte necessario che produce etichette di verità fondamentale (ground-truth) binarie e affidabili. Queste etichette sono prerequisiti affinché i metodi statistici a valle (es. predizione conforme, quantificazione dell'incertezza) possano funzionare correttamente.
• Cambio di Pratica: Il framework facilita il passaggio dal "testing manuale aneddotico" a "pipeline di test deterministiche attivate dai cambiamenti", rispecchiando l'evoluzione del software engineering tradizionale.
• Ciclo di Automazione: Convertendo i segnali di successo auto-confermato al 100% in segnali di fallimento al primo tentativo verificabili, e fornendo patch con un clic, AEVAL chiude il ciclo test-fallimento-correzione, consentendo decisioni di routing e arresto affidabili nei workflow agentici a valle.

Gli autori rimangono modesti riguardo ai limiti, riconoscendo che il divieto di output simulati è imposto tramite istruzione (non tramite sandboxing) e che complesse auto-correzioni multi-step potrebbero ancora essere erroneamente attribuite dal valutatore. Tuttavia, affermano che la separazione strutturale tra esecutore e valutatore è l'ingrediente fondamentale di affidabilità richiesto per il monitoraggio statisticamente rigoroso dei workflow agentici.