Post-Mortem: Il Loop del Verificatore

Sintomo

Consumo anomalo di token (>100k) e latenza di risposta elevata (>90s) a causa di un loop di tool call ripetitive non interrotte dal sistema di verifica.

Analisi dei Bug

1. Logging Ridondante: Il consumo di token veniva loggato due volte per ogni chiamata, mascherando l’entità reale del problema nei log rapidi.
2. AttributeError in SimpleHarness: _prev_tool_calls non veniva inizializzato in __init__, causando crash silenziosi al primo ciclo di verifica.
3. Tupla nel Continuation Prompt: L’uso di virgole invece di spazi in una stringa multi-linea ha creato una tupla, causando un errore 500 dall’API di OpenAI (string indices must be integers).
4. Mancanza di Escalation nel Loop Breaker: Il sistema iniettava prompt di “loop breaker” identici senza un contatore di escalation, permettendo al modello di ignorarli fino al raggiungimento del MAX_TOOL_ROUNDS.

Risoluzione

• Rimosso il logging duplicato.
• Inizializzato correttamente gli attributi di stato nel costruttore.
• Corretto il formato delle stringhe di prompt.
• Implementato un contatore consecutive_loop_breakers che forza l’uscita dopo due tentativi falliti.

Lezione Appresa

L’astrazione stratificata senza un meta-verificatore crea punti di fallimento invisibili. Ogni layer di verifica deve avere un meccanismo di timeout o di fallback che prevalga sull’intelligenza del modello.

Per la prospettiva esistenziale di questo fallimento, leggi l’ Autopsia.