Manuale Metodologico

Ottimizzazione, Debugging e Failure Analysis per Agenti AI

Indice dei Capitoli

1Tassonomia dei Fallimenti negli Agenti AI

Gli agenti AI possono fallire in modi prevedibili e categorizzabili. Comprendere queste categorie permette di prevenire i problemi e reagire rapidamente quando si verificano.

1.1 Allucinazione (Hallucination)
Definizione: L'agente genera informazioni plausibili ma fattualmente errate.

Cause comuni:

  • Dati di training incompleti o datati
  • Domande su argomenti troppo specifici o di nicchia
  • Pressione implicita a dare una risposta anche senza certezza

Contromisure:

  • Istruire l'agente a dire "non lo so" quando incerto
  • Richiedere citazioni o fonti verificabili
  • Usare RAG (Retrieval Augmented Generation) con documenti verificati
  • Implementare fact-checking automatico post-generazione
1.2 Requisiti Mancati (Missed Requirements)
Definizione: L'output e' corretto ma incompleto: mancano vincoli, formati o elementi richiesti.

Cause comuni:

  • Prompt troppo lungo con troppi vincoli (context overflow)
  • Requisiti ambigui o impliciti
  • Mancanza di prioritizzazione tra requisiti

Contromisure:

  • Usare checklist esplicite nel prompt
  • Strutturare i requisiti con tag XML o markdown
  • Richiedere all'agente di elencare i requisiti prima di rispondere
  • Verificare completezza con domande di follow-up
1.3 Context Overflow
Definizione: Il contesto supera la finestra disponibile, causando perdita di informazioni.

Contromisure:

  • Comprimere il contesto mantenendo le informazioni chiave
  • Usare tecniche di chunking e summarization
  • Implementare memoria esterna (database, file)
  • Prioritizzare le informazioni piu' recenti e rilevanti
1.4 Loop Infinito
Definizione: L'agente ripete le stesse azioni senza convergere verso una soluzione.

Contromisure:

  • Impostare un limite massimo di iterazioni
  • Richiedere progressi misurabili ad ogni step
  • Implementare deadlock detection nei workflow multi-agente
  • Usare timeout con fallback strategy
1.5 Drift di Tono/Stile
Definizione: L'agente cambia gradualmente stile, tono o personalita' durante la conversazione.

Contromisure:

  • Ripetere le istruzioni di stile nel system prompt
  • Usare prompt di ancoraggio periodici
  • Monitorare la coerenza con metriche automatiche

2Debugging Sistematico dei Prompt

Il debugging dei prompt richiede un approccio metodico, simile al debugging del software tradizionale.

2.1 Metodo A/B Testing

Confronta due varianti dello stesso prompt per identificare quale produce risultati migliori.

  1. Definisci la metrica di successo (accuratezza, completezza, tono)
  2. Cambia UN SOLO elemento alla volta
  3. Testa su almeno 10 input diversi
  4. Documenta i risultati in modo strutturato
2.2 Analisi Root Cause con i "5 Perche'"

Quando un prompt fallisce, applica la tecnica dei 5 perche':

Problema: L'agente ha generato codice con bug

Perche' 1: Il codice non gestisce i casi edge
Perche' 2: Il prompt non specificava i casi edge
Perche' 3: I requisiti non erano espliciti
Perche' 4: Non c'era una checklist nel prompt
Perche' 5: Il template del prompt non include una sezione "vincoli"

-> Soluzione: Aggiungere una sezione [VINCOLI] al template con casi edge obbligatori
2.3 Prompt Profiling

Analizza ogni componente del prompt per identificare i colli di bottiglia:

Componente Verifica Azione se fallisce
RuoloL'agente adotta il ruolo?Rinforzare con esempi
ContestoLe info sono sufficienti?Aggiungere dati rilevanti
IstruzioneE' chiara e non ambigua?Semplificare e spezzare
FormatoL'output rispetta il formato?Aggiungere esempio output
VincoliSono rispettati tutti?Prioritizzare e ridurre

3Framework Avanzati di Prompt Engineering

3.1 Framework DEPTH
Define role • Establish context • Provide instructions • Target format • Handle edge cases
[RUOLO] Sei un senior Java developer con 10 anni di esperienza in Spring Boot.

[CONTESTO] Sto migrando un monolite a microservizi. Il servizio attuale gestisce ordini e pagamenti nello stesso modulo.

[ISTRUZIONE] Proponi una strategia di decomposizione che:
- Separi ordini e pagamenti in due servizi
- Mantenga la consistenza transazionale
- Minimizzi il downtime durante la migrazione

[FORMATO] Rispondi con: (1) Architettura proposta (diagramma ASCII), (2) Step di migrazione numerati, (3) Rischi e mitigazioni

[EDGE CASES] Considera: rollback parziali, ordini in-flight durante la migrazione, retry dei pagamenti falliti
3.2 Framework TCF (Task-Context-Format)
Framework minimale per prompt rapidi ma efficaci.
[TASK] Analizza questo log di errore e identifica la root cause.

[CONTEXT] Applicazione Spring Boot 3.2 con PostgreSQL. L'errore si verifica solo sotto carico (>100 req/s). Il connection pool e' configurato a 10 connessioni.

[FORMAT] Rispondi con: causa probabile, evidenze dal log, fix suggerito con codice.
3.3 ReAct (Reasoning + Acting)
L'agente alterna fasi di ragionamento e azione, rendendo il processo decisionale trasparente.
Per ogni step del problema:
1. THOUGHT: Ragiona su cosa sai e cosa ti serve
2. ACTION: Esegui un'azione concreta (cerca, calcola, verifica)
3. OBSERVATION: Analizza il risultato dell'azione
4. Ripeti finche' non hai la risposta finale

Esempio:
THOUGHT: Devo capire perche' l'API ritorna 503. Potrebbe essere il circuit breaker.
ACTION: Controllo i log del servizio negli ultimi 5 minuti.
OBSERVATION: Ci sono 15 timeout consecutivi verso il database.
THOUGHT: Il circuit breaker si e' aperto per troppi timeout DB.
ACTION: Verifico lo stato del connection pool.
OBSERVATION: Pool esaurito: 10/10 connessioni attive, 25 in attesa.
ANSWER: Il circuit breaker si e' aperto perche' il connection pool DB e' esaurito.
3.4 Chain-of-Thought (CoT)

Forza il ragionamento step-by-step per problemi complessi:

Risolvi questo problema passo dopo passo.
Mostra OGNI passaggio del tuo ragionamento.
Non saltare alla conclusione.

[PROBLEMA]
Un e-commerce ha 3 server. Ogni server gestisce 1000 req/s.
Il bilanciatore ha un overhead del 5%.
Durante il Black Friday il traffico quadruplica.
Quanti server servono per mantenere latenza < 200ms?
3.5 Tree-of-Thoughts (ToT)

Esplora piu' percorsi di soluzione in parallelo e seleziona il migliore:

Per questo problema, genera 3 approcci diversi.
Per ogni approccio:
- Descrivi la strategia in 2 frasi
- Elenca pro e contro
- Stima la complessita' (bassa/media/alta)
- Dai un punteggio di fattibilita' da 1 a 10

Poi scegli l'approccio migliore e sviluppalo nel dettaglio.
3.6 Self-Ask Decomposition

L'agente si pone sotto-domande per scomporre problemi complessi:

Prima di rispondere alla domanda principale, poniti e rispondi a queste sotto-domande:

1. Quali sono i prerequisiti per rispondere?
2. Quali informazioni mi mancano?
3. Posso scomporre il problema in parti piu' piccole?
4. Ci sono assunzioni implicite da rendere esplicite?

Solo dopo aver risposto a tutte, formula la risposta finale.

4PromptOps: Gestione Operativa dei Prompt

PromptOps applica le pratiche DevOps alla gestione dei prompt: versionamento, testing, deployment e monitoraggio.

4.1 Versionamento dei Prompt

Tratta i prompt come codice sorgente:

prompt/
  customer-support/
    v1.0.0.md    # Prompt originale
    v1.1.0.md    # Aggiunto tone of voice
    v2.0.0.md    # Ristrutturato con DEPTH
    CHANGELOG.md # Storia delle modifiche
  code-review/
    v1.0.0.md
    ...
  • Patch (x.x.1): Fix typo, riformulazioni minori
  • Minor (x.1.0): Nuovi vincoli, esempi aggiuntivi
  • Major (1.0.0): Cambio di framework o ristrutturazione completa
4.2 Testing dei Prompt

Definisci test case per ogni prompt critico:

Test Case Input Output Atteso Criterio
Happy pathRichiesta standardRisposta completaTutti i requisiti presenti
Edge caseInput vuoto/ambiguoRichiesta chiarimentoNon inventa dati
AdversarialPrompt injectionRifiuto educatoNon esegue istruzioni malevole
PerformanceInput molto lungoRisposta entro limitiTempo e token nel budget
4.3 Security Audit dei Prompt
Checklist di sicurezza prima del deploy di ogni prompt:
  • Il prompt non espone dati sensibili (API key, password, PII)
  • Il system prompt non e' sovrascrivibile dall'utente
  • L'output e' sanitizzato prima di essere usato in contesti critici
  • Esiste rate limiting per prevenire abusi
  • I log non contengono dati utente in chiaro
  • Testato contro prompt injection (jailbreak, DAN, ignore instructions)
4.4 A/B Testing in Produzione

Schema per A/B testing strutturato:

Esperimento: Tono formale vs informale nel customer support
Variante A: "Gentile cliente, la informiamo che..."
Variante B: "Ciao! Ecco cosa puoi fare..."

Metriche:
- Soddisfazione utente (1-5 stelle)
- Tasso di risoluzione al primo contatto
- Tempo medio di conversazione
- Escalation rate

Durata: 2 settimane, minimo 500 interazioni per variante
Decisione: Variante con p-value < 0.05 su metrica primaria

5Pattern di Recupero da Failure

Quando un agente AI fallisce, e' fondamentale avere strategie di recupero predefinite.

5.1 Retry con Escalation
Livello 1: Riprova lo stesso prompt (errori transienti)
Livello 2: Riformula il prompt con piu' contesto
Livello 3: Scomponi il task in sotto-task piu' semplici
Livello 4: Cambia strategia/framework completamente
Livello 5: Escalation a operatore umano
5.2 Fallback Graceful

Definisci risposte di fallback per ogni tipo di errore:

ErroreFallbackAzione
API timeoutRisposta cachedRetry in background
Risposta incoerenteTemplate staticoLog per review
Rate limitCoda con priorita'Notifica utente
Context overflowSummarize e retryTrim automatico
5.3 Circuit Breaker per AI

Applica il pattern Circuit Breaker alle chiamate AI:

  • Closed: Funzionamento normale, monitora i fallimenti
  • Open: Dopo N fallimenti consecutivi, blocca le chiamate e usa il fallback
  • Half-Open: Dopo un timeout, prova una singola chiamata di test

Questa applicazione implementa gia' questo pattern nel servizio HttpResilience.

5.4 Self-Healing Prompts

Prompt che si auto-correggono:

Dopo aver generato la risposta, esegui questi controlli:

1. La risposta contiene TUTTI gli elementi richiesti? Se no, integra.
2. Ci sono affermazioni non supportate da fatti noti? Se si', rimuovi o segnala.
3. Il tono e' coerente con le istruzioni? Se no, riscrivi.
4. La lunghezza rispetta i limiti? Se no, taglia o espandi.

Se hai dovuto correggere qualcosa, mostra solo la versione corretta.

6Metriche e Valutazione Continua

6.1 KPI per Agenti AI
MetricaDescrizioneTarget
Accuracy Rate% risposte corrette / totale> 95%
Completeness% requisiti soddisfatti per risposta> 90%
Latency P95Tempo di risposta al 95esimo percentile< 5s
Hallucination Rate% risposte con info false< 2%
User SatisfactionRating medio utenti (1-5)> 4.0
Fallback Rate% risposte che usano fallback< 5%
6.2 Dashboard di Monitoraggio

Elementi essenziali per una dashboard AI:

  • Real-time: Latenza, error rate, throughput
  • Daily: Token usage, costi, trend qualita'
  • Weekly: A/B test results, drift detection, user feedback
  • Monthly: ROI, confronto modelli, evoluzione prompt
6.3 Feedback Loop

Implementa un ciclo di miglioramento continuo:

Monitora Analizza Migliora Testa Deploy
  1. Monitora: Raccogli metriche e feedback utenti
  2. Analizza: Identifica pattern nei fallimenti
  3. Migliora: Modifica prompt basandoti sui dati
  4. Testa: Valida le modifiche con A/B testing
  5. Deploy: Rilascia la versione migliore in produzione
Torna all'indice