Osservatorio sull'ecosistema Jev (parte 3): quattro giorni di fallimenti e quando non fidarsi

I due articoli precedenti hanno descritto gli elementi di successo sviluppati dall'ecosistema nei suoi primi quattro giorni. Questo articolo si concentra sull'altra faccia della medaglia: i log dei fallimenti. I criteri di evidenza restano identici: tutto proviene dalla nostra scansione in dieci round condotta tra il 2026-09-15 e il 09-19, con tutti i dati di terze parti dichiarati dagli autori e classificati secondo i livelli A/B/C; in più, abbiamo letto parola per parola il testo originale delle principali valutazioni qui citate.

Una prova rigorosa da 1,43 $

La valutazione indipendente agentjournal ha condotto uno degli esperimenti controllati più solidi dell'ecosistema: tre task di classificazione, 5.477 righe di test, 34,1 milioni di token e un costo totale di 1,43 $, per confrontare una «singola domanda diretta» con una «scomposizione in 12-14 dimensioni con punteggio, seguita da un fitting locale». Cinque risultati vanno ricordati uno per uno:

1. Evita di scomporre in dimensioni i task semplici. Su 200 campioni sintetici con trappole, le domande dirette hanno raggiunto il 100% di accuratezza (ancora 100% dopo lo scambio delle etichette, senza bias di posizione); la pipeline con scomposizione in 12 dimensioni si è invece fermata al 98,0%. Spendere più token ha prodotto risultati peggiori.
2. Uno split di valutazione sbagliato fa mentire i numeri. La cross-validation casuale riportava il 98,0%, ma raggruppando per famiglia di template ed escludendo le feature corrispondenti si scendeva al 90,0%: 8 punti di template leakage. Con lo stesso split, una baseline gratuita su bigrammi di caratteri arrivava al 93,5%, superandola. Vale la pena adottare due abitudini dell'autore: stampare sempre per prima la baseline della classe maggioritaria e progettare lo split prima di guardare il dataset.
3. La scomposizione in dimensioni porta vantaggi solo sui task difficili. Su un task di 300 righe in cui le etichette erano determinate aggregando più segnali deboli, le domande dirette hanno ottenuto il 64,7% e la scomposizione il 74,0% (9 punti in più, p=0,0050), ma anche la baseline gratuita su bigrammi di caratteri ha raggiunto il 74,0%. Prima scrivi la baseline gratuita, poi parla di modelli.
4. Con troppe opzioni il modello cede inevitabilmente. Su dati contabili reali, 12 scelte in un unico prompt Choice hanno dato un'accuratezza di appena 0,3998: «ogni parola è stata capita, ma sceglierne 1 su 12 non è riuscito», segno che il collo di bottiglia è il formato della decisione e non la comprensione. La scomposizione in 14 dimensioni con pesi ha riportato l'accuratezza a 0,9105, che sale a 0,9695 combinandola con n-grammi.
5. Negli scenari sensibili ai falsi positivi, la scomposizione in dimensioni è disastrosa. Su 339 campioni benigni difficili (che «parlano di metodi di attacco ma restano innocui», come documentazione di sicurezza, note di red team e articoli come questo), le domande dirette hanno prodotto un tasso di falsi positivi dell'1,5%, mentre la scomposizione in 12 dimensioni ha prodotto il 37,2%: circa 25 volte tanto, e tutti e quattro i tentativi di correzione sono falliti. La conclusione dell'autore: è un problema di progettazione delle dimensioni, non di tuning dei parametri; le chiamate dirette formulate correttamente vanno affiancate ai modelli come giudici indipendenti, invece di essere inserite nei modelli come feature.

Nemmeno le risorse ufficiali sono state risparmiate

La community ha documentato il problema nella issue #2 sulla guida rapida dell'SDK Python ufficiale: il commento del ticket di esempio indicava che andava classificato come technical, ma chi l'ha segnalato ha misurato che restituiva billing (0,67), con un risultato stabile su 100 cicli. Quando un ticket dell'assistenza clienti contiene sia errori di pagamento sia errori di integrazione, il confine di una classificazione a tre vie è per sua natura ambiguo; eppure vedere fallire l'esempio ufficiale secondo i suoi stessi criteri è un colpo concreto alla fiducia dei principianti.

Esempi trasparenti dal mondo dei prodotti

Più preziosi dei fallimenti ufficiali sono i difetti dichiarati dai prodotti stessi. Il prodotto di verifica delle affermazioni Attest ha reso noti due numeri: ha eliminato il campo della confidenza perché 22 controlli reali su 24 ricadevano tra 0,95 e 0,99 («un numero sempre uguale non è un'informazione»), e invertire l'ordine delle prove cambia il 5,8% dei giudizi. Il valutatore di idee per startup killmyidea è stato testato da utenti che hanno scoperto che togliere tre caratteri faceva variare sensibilmente i punteggi, e l'autore ha ammesso che è solo «un controllo d'intuito coerente, non un oracolo». Sul fronte gaming, l'autore di un'AI per combattimenti aerei ha valutato da solo che «è piuttosto scarsa»; sul fronte trading, qualcuno ha pubblicato dati non filtrati con un win rate del 41,1% su 375 operazioni simulate. In un ecosistema in cui tutti riportano buone notizie, i numeri non gonfiati meritano di essere segnalati uno per uno.

C'è anche un avvertimento di metodo: il noto sviluppatore steve8708 ha denunciato pubblicamente che alcune demo virali di Jev su X mescolavano contenuti accelerati e inventati. La nostra risposta è entrata nei criteri di inclusione: le demo di «velocità sovrumana» vengono riconosciute solo se includono una metodologia completa e le tracce di esecuzione.

Quando non fidarsi

Mettendo insieme le lezioni di questo articolo e dell'articolo precedente si ottiene una checklist in negativo:

• Confidenza ≥0,9 non significa risposta corretta: su quel 42% di righe ad alta confidenza l'accuratezza era solo del 72,2%.
• Scomporre in dimensioni non significa essere più rigorosi: negli scenari sensibili ai falsi positivi va 25 volte peggio.
• Proporre più di dieci opzioni alla volta fa crollare l'accuratezza fino alla baseline casuale.
• Se l'ordine e la formulazione dell'input cambiano, i giudizi possono spostarsi di conseguenza.
• Finché non hai eseguito baseline gratuite (n-grammi, Naive Bayes, regole), prendi con cautela qualsiasi dato di accuratezza.
• Se gli split non sono progettati sulle distribuzioni reali, il template leakage può far comparire 8 punti dal nulla.

La checklist di autodifesa corrispondente ha sei voci: privilegia le domande dirette, usa poche opzioni, fissa l'ordine degli input, esegui prima le baseline, mantieni set di valutazione indipendenti e tratta le chiamate dirette come giudici indipendenti. Il punto di forza delle primitive decisionali resta valido (problema ristretto × alta frequenza × azioni limitate), ma fuori da quel perimetro può fare danni sul serio.

Nel prossimo articolo della serie lasciamo i singoli casi per esaminare il livello infrastrutturale che questo ecosistema ha già sviluppato. Se il tuo livello di giudizio ha bisogno in input di dati affidabili su commenti, reputazione e prezzi, parti dalla guida all'integrazione dell'API unificata per i dati.