Metriche auto-riparanti: quando un eval verde nasconde una vera regressione
Nel nostro eval di profondità multi-documento (2026-06-04, GLM-4.7), una metrica di mappatura delle clausole ha ottenuto un quasi perfetto 1.0 mentre l'analisi per-documento del modello è scesa a circa un terzo della sua profondità standalone. La metrica ovvia era quella che mentiva.
Il numero più pericoloso in un'evaluazione è quello che rimane verde mentre il prodotto si rompe. Ne abbiamo uno. Nel test in cui l'output per-documento del nostro modello è sceso a circa un terzo della sua profondità standalone, una metrica di parità ha ottenuto un quasi perfetto 1.0. La metrica non era rumorosa o mal calibrata. Stava misurando la cosa sbagliata, in un modo che il modello poteva soddisfare senza fare il lavoro richiesto. Lo chiamiamo metrica auto-riparante, e trovarla è stata la cosa più utile che la nostra suite di eval ha fatto quella settimana.
Cosa stavamo testando
Un compito comune nel nostro prodotto è l'analisi multi-documento: un utente carica diversi documenti di policy contemporaneamente e chiede all'assistente di mappare ciascuno rispetto alle clausole di un framework, ad esempio i controlli dell'Allegato A della ISO/IEC 27001:2022. Un cliente ci ha segnalato che analizzare diversi documenti in una singola richiesta produceva risultati più sintetici rispetto all'analisi di ogni documento singolarmente. Prima di apportare modifiche, abbiamo costruito un eval per riprodurre e misurare quel divario (ticket interno ISM-549, baseline del 2026-06-04).
La configurazione era deliberatamente fedele alla produzione. Modello: GLM-4.7, servito tramite OpenRouter, corrispondente al percorso di richiesta valutato. Fixtures: sette policy sintetiche e anonimizzate (nessun contenuto di clienti), strutturate come lo scenario reale che ha scatenato il reclamo. La domanda a cui l'eval doveva rispondere era semplice: ogni documento riceve la stessa profondità analitica quando vengono analizzati sette insieme rispetto a quando ciascuno viene analizzato singolarmente?
La prima metrica, e perché si è auto-riparata
Il modo ovvio per valutare "ogni documento è stato analizzato" è contare le righe di mappatura delle clausole. L'analisi standalone produce una tabella con una riga per clausola, quindi anche l'analisi raggruppata dovrebbe farlo. Abbiamo provato esattamente questo per primo.
La parità delle righe è risultata intorno a 1.0. Dato clausole numerate esplicite e un'istruzione di "mappare ogni clausola", GLM-4.7 ha diligentemente mantenuto una riga per clausola anche quando gli venivano forniti sette documenti contemporaneamente. Secondo quella metrica, non c'era nulla di sbagliato. L'eval era pronto per essere approvato.
Il prodotto era visibilmente peggiore. Le righe erano presenti; l'analisi intorno a esse era scomparsa. Singolarmente, ogni riga di clausola conteneva una spiegazione, i punti di forza, le lacune e un breve riassunto. In gruppo, il modello ha mantenuto lo scheletro e ha eliminato i muscoli: la stessa forma della tabella, ma molta meno analisi per clausola. La metrica si era auto-riparata. L'output soddisfaceva "una riga per clausola" mentre riduceva gran parte dell'analisi per clausola, e un conteggio di righe non può distinguere un'analisi completa da una vuota.
Cosa ha mostrato una metrica migliore
Quindi abbiamo smesso di valutare la struttura e abbiamo iniziato a valutare la sostanza. La metrica principale è diventata la parità del volume di contenuto: caratteri dell'output raggruppato divisi per la somma dei caratteri degli output standalone, con un limite di superamento a 0.6. Nel baseline del 2026-06-04 (GLM-4.7, due campioni):
| Misura | Campione 1 | Campione 2 |
|---|---|---|
| Parità volume di contenuto | 0.34 | 0.35 |
| Caratteri standalone | 48.263 | 47.651 |
| Caratteri raggruppati | 16.201 | 16.609 |
| Parità righe mappatura clausole | 1.00 | 0.98 |
| Giudice LLM: documenti valutati non diluiti | 0 su 7 | 0 su 7 |
Nello stesso baseline del 2026-06-04, un proxy di profondità a livello di token raccontava la stessa storia: circa 2.747 token di output per un singolo documento, contro circa 595 token per documento quando i sette venivano raggruppati, un rapporto per-documento di 0.22.
Tre dettagli contano qui. La parità del volume di contenuto era a 0.34, ben al di sotto del limite di 0.6. Un giudice LLM indipendente, incaricato solo di valutare se l'analisi di ogni documento fosse diluita o meno, ha valutato 0 documenti su 7 non diluiti in entrambi i campioni. La parità delle righe, la metrica che stavamo quasi per implementare, ha registrato una media di 0.99 nei due campioni (da 0.98 a 1.00). I tre segnali di sostanza puntavano tutti nella stessa direzione: parità del volume di contenuto a circa un terzo, il proxy token ancora più basso a 0.22 per documento, e il giudice che ha valutato ogni documento raggruppato come diluito. L'unico strumento che dissentiva era il conteggio strutturale delle righe.
Perché succede, e i limiti di ciò che sappiamo
La nostra interpretazione dei dati è che GLM-4.7 si auto-assegna uno sforzo fisso da distribuire tra i documenti in un'unica decodifica: quando gli viene chiesto di fare sette analisi in una singola risposta, distribuisce un budget pressoché fisso in modo sottile piuttosto che produrre sette analisi complete. Non abbiamo strumentato gli interni del modello, quindi questa è una descrizione del comportamento misurato, non un meccanismo provato, ed è specifica di questo modello e di questa forma di richiesta. Due fatti di ambito sono fondamentali. La regressione appare a scala di produzione: si manifesta con sette documenti, non con due, quindi un test smoke su un input piccolo sarebbe passato senza problemi. E non si è riprodotta quando abbiamo eseguito le stesse fixtures su un modello di frontiera tramite un'API diretta. La regressione è apparsa solo sul modello e sul percorso di richiesta esatti che valutiamo e distribuiamo, ed è proprio questo l'argomento a favore di valutare il percorso che si utilizza effettivamente invece di un sostituto conveniente.
Perché questo è peggiore nella compliance rispetto ad altri ambiti
Nella maggior parte dei prodotti, un "output più sintetico" è un difetto di qualità. Nei nostri flussi di lavoro di compliance non lo è: una tabella di mappatura dei controlli con ogni riga presente e nessuna analisi sembra completa in una schermata, ma non fornisce agli auditor alcuna delle argomentazioni per-clausola di cui avrebbero bisogno per fare affidamento su di essa. È questo che rende una metrica auto-riparante genuinamente pericolosa in questo dominio. Non era solo imprecisa. Era verde proprio sul tipo di fallimento che conta di più nel nostro settore: un deliverable che sembra sicuro ma ha la sostanza silenziosamente rimossa.
La soluzione che ne consegue è assegnare a ogni documento un passaggio a piena profondità invece di includere tutti e sette in una singola decodifica, e l'eval passa una volta fatto ciò. Ma la soluzione è la parte facile. Non avremmo potuto costruirla mentre la nostra metrica principale insisteva sul fatto che nulla fosse rotto. Il cambiamento della metrica doveva venire per primo, perché non si può riparare ciò che non si riesce a vedere.
Come catturare una metrica auto-riparante
Una metrica auto-riparante è qualsiasi metrica che un modello può soddisfare senza fare il lavoro sottostante. Le metriche strutturali sono le più inclini a questo fenomeno: conteggi di righe, conteggi di elementi, "JSON valido", "tutti i campi richiesti presenti", intestazioni di sezione. Sono economiche da calcolare e facili da manipolare, spesso direttamente dal modello piuttosto che da noi. Prima di fidarvi di una di queste, eseguite questi controlli:
- Valutate la sostanza, non solo la forma. Se una metrica verifica solo la struttura (righe, campi, intestazioni), abbinatela a una che verifica il contenuto (caratteri, token o un giudice che valuta la completezza). La forma è necessaria, ma mai sufficiente.
- Aggiungete uno strumento indipendente. Un giudice LLM economico che valuta la qualità e non concorda con la vostra metrica principale è il segnale che cercate. La concordanza è una corroborazione; una divergenza significa che la vostra metrica strutturale probabilmente si sta auto-riparando.
- Testate a scala di produzione. Una regressione che appare solo con sette documenti passerà con due. Dimensionate le vostre fixtures come l'input reale, non come un test unitario.
- Testate il modello e il percorso che distribuite. La nostra diluizione non si è riprodotta su un modello diverso o tramite un'API diretta. Un proxy più semplice da eseguire è un proxy che può perdere il bug che solo il vostro percorso di produzione ha.
- Chiedetevi quale sia l'output più economico per passare. Se un modello può soddisfare la vostra metrica facendo quasi nessuno del lavoro reale, assumete che lo farà prima o poi. Progettate la metrica in modo che il modo più economico per passare sia fare effettivamente il lavoro.
L'eval ha fatto il suo lavoro alla fine, ma solo dopo aver smesso di fidarci del numero lusinghiero. Quando una metrica è verde, la domanda più utile non è "stiamo passando", ma "il modello potrebbe passare questa metrica senza fare il lavoro richiesto". Se la risposta è sì, la metrica si sta auto-riparando, e continuerà a farlo finché sarà un cliente a notarlo.