Il settore AI ha abbracciato gli evals collettivamente — evitando però la vera domanda
Nel 2026, una delle pratiche ingegneristiche più in voga nell’ecosistema AI è costruire «sistemi di valutazione» (evals) per modelli e agent.
Il copione è ormai rodato: si raccoglie un dataset gold-standard dai veri casi di fallimento, si addestra uno scorer di cui fidarsi, si usa un LLM «allineato ai revisori umani» come giudice, e infine si pianta un gate CI che blocca ogni regressione di qualità. Anthropic ha pubblicato articoli su come fare eval; un’indagine cita che per il 32% dei team la qualità è il principale ostacolo al lancio di prodotti AI. Gli evals vengono presentati come una disciplina ingegneristica capace di rendere l’AI affidabile.
Il meccanismo funziona. Ma quello che osservo è questo: il settore sta impacchettando un problema organizzativo come problema ingegneristico — e quel problema organizzativo gli evals non lo risolvono.
Togli la scorza ingegneristica: cos’è davvero un eval
Un sistema di evals, stripped down — niente dataset, niente scorer, niente CI — è fondamentalmente composto da due cose: una definizione scritta di «cosa consideriamo buono e cosa è inaccettabile», più un meccanismo che la esegue.
Costruire la pipeline, far girare la CI: questa parte è gestibile e si automatizza in fretta. La parte difficile è la prima — cosa diavolo significa «buono»? Non è un problema ingegneristico, è un problema di giudizio. E il giudizio è esattamente ciò che gli evals cercano di aggirare — senza riuscirci.
«Usare un LLM come giudice» sposta il problema di un livello, non lo elimina
Va di moda usare un LLM come giudice e dichiarare che è «allineato ai revisori umani». Suona scientifico, ma basta una domanda per smontarlo: allineato a quali umani? Al gusto di chi?
Il modello-giudice non produce standard — li replica. Quello che hai nascosto nel tuo dataset gold-standard è il giudizio di qualcuno, e il tuo eval avrà esattamente quel livello di giudizio. L’idea di «raccogliere dati dai fallimenti reali» è in sostanza un documento di valori travestito da dati di test — registra ciò che il tuo team non è disposto a tollerare.
Detto altrimenti: gli evals amplificano il gusto che hai già, ma non te ne danno uno. Un team con pessima capacità di giudizio dotato di una bella pipeline di eval non ottiene un prodotto migliore — ottiene mediocrità prodotta più velocemente e in modo più stabile.
Cosa rivela davvero la febbre degli evals
La narrativa «l’AI può fare tutto» prometteva di dissolvere la figura del guardiano della qualità. La corsa agli evals è il settore che silenziosamente reintroduce quella figura — con un nome ingegneristico.
Il sottotesto è scomodo: l’AI non ha eliminato la persona con capacità di giudizio; l’ha trasformata nel collo di bottiglia. Più l’esecuzione costa meno, più «definire cosa è buono» diventa scarso. Tutta questa attività frenetica intorno agli evals è un’ammissione tardiva di questa realtà.
Quindi la mia previsione sul prossimo periodo è questa: a vincere non sarà il team con la pipeline di eval più sofisticata, ma quello che ha le idee più chiare e nette su cosa significa «buono». Perché la pipeline eseguirà fedelmente qualsiasi standard gli dai — e lo standard della maggior parte dei team è un blob informe.
Gli evals non sono mai stati un problema di misurazione. Sono il settore che ammette lentamente che qualcuno deve pur decidere cosa è buono — e che questo è esattamente ciò che non si scala.
Discussione