Sviluppo di agent guidato dalle valutazioni: come ho smesso di ottimizzare i prompt a sensazione
Ho cambiato un prompt. L'esecuzione successiva sembrava migliore. Il cambiamento ha aiutato o sono stato solo fortunato?
Per molto tempo, la mia risposta è stata "Penso di sì". Modificavo un comando, avviavo la pipeline, guardavo il successo e rilasciavo il codice. Questa è l'ingegneria basata sulle sensazioni. Quasi tutti coloro che costruiscono agent lo fanno perché l'alternativa sembra difficile.
Ma gli agent di coding sono non deterministici. Puoi eseguire lo stesso compito due volte e ottenere due risultati diversi. Una singola esecuzione riuscita non ti dice nulla. Non puoi sapere se il tuo cambiamento ha funzionato o se i dadi hanno semplicemente girato bene.
Ho risolto il problema applicando la disciplina del machine learning. Ho costruito un framework di valutazione per avvolgere l'intero sistema.
Ecco come funziona il framework:
• Target: Un codebase congelato. Rimane invariato affinché i punteggi restino confrontabili. • Task: Un elemento specifico del benchmark con un prompt e un oracolo. • Oracolo: Un controllo deterministico. Si tratta di comandi shell che devono superare il test. • Variante: Il cambiamento specifico che stai testando, come un nuovo planner. • Trial: Una singola esecuzione. Eseguo ogni task più volte per tenere conto della casualità.
Utilizzo due tipi di punteggio per individuare diversi tipi di fallimento:
- Code Grader (Deterministici): Verificano i tassi di superamento dei test, i costi, i tempi e le modifiche ai file.
- LLM Judge (Probabilistico): Un modello separato e fisso valuta la qualità delle specifiche e la fedeltà dell'implementazione.
I code grader ti dicono se il codice funziona. Il judge ti dice se il codice è buono. Hai bisogno di entrambi.
Ho smesso anche di usare le medie. Le medie mentono sugli agent. Se un task ha successo 2 volte su 3, sembra accettabile. Ma non è affidabile. Invece, uso due metriche:
- pass@k: L'agent ha avuto successo almeno una volta? (Capacità)
- pass^k: L'agent ha avuto successo ogni singola volta? (Affidabilità)
Un salto in pass^k è la vera vittoria. Significa che hai reso l'agent coerente, non solo fortunato.
Per mantenere il sistema efficiente, aggiungo task difficili che richiedono una comprensione profonda. Quando un agent fallisce su un bug reale, trasformo quel fallimento in un task permanente. Questo crea un ciclo chiuso. Il benchmark diventa più difficile man mano che l'agent migliora.
Questa infrastruttura richiede molto lavoro, ma è l'elemento con il maggior impatto che io abbia mai costruito. Ha trasformato "Penso che questo sia migliore" in "questo è il 20% più affidabile a un costo inferiore".
Gli agent di coding sono facili da mostrare in una demo, ma difficili da cui fidarsi. Se vuoi andare oltre le demo, devi decidere di misurare.
Fonte: https://dev.to/rickjms/eval-driven-agent-development-how-i-stopped-tuning-prompts-on-vibes-1189
Community di apprendimento opzionale: https://t.me/GyaanSetuAi