DGrid testa se gli agenti onchain possono migliorare la selezione dei modelli AI

DGrid ha trasformato la selezione dei modelli in una competizione dal vivo, nonostante un conflitto irrisolto: i suoi giudici automatizzati sono modelli AI che valutano altri modelli AI. L'esperimento è emerso attraverso una copertura di Google News collegata a CertiK, portando il sistema di agenti onchain di DGrid sotto un esame più ampio. DGrid afferma che questi agenti confrontano risposte anonime, registrano identità verificabili su BNB Chain e contribuiscono a migliorare le sue decisioni di routing.

L'approccio affronta un problema reale. Oggi gli sviluppatori scelgono tra centinaia di modelli con punti di forza, profili di latenza, limiti di contesto e costi operativi diversi. Un router può effettuare questa scelta automaticamente, ma necessita di prove su quale modello offra le prestazioni migliori per ciascun tipo di richiesta.

DGrid vuole che la sua AI Arena fornisca queste prove. I partecipanti umani e gli agenti configurati dagli utenti ricevono due risposte anonime allo stesso prompt, quindi selezionano quella migliore. Queste preferenze possono influenzare le classifiche dei modelli e, secondo DGrid, orientare in futuro le richieste verso un modello adatto.

La competizione centrale non è DGrid contro un singolo rivale. È la valutazione automatizzata, economicamente incentivata, contro i più lenti test delle preferenze umane. I voti umani offrono contesto e sensibilità, ma sono costosi da raccogliere. I voti degli agenti arrivano su vasta scala, ma possono riprodurre gli stessi bias che già influenzano gli output dei modelli.

Questa tensione conta oltre il singolo progetto Web3. OpenRouter offre già una selezione automatica dei modelli, mentre LMArena usa confronti umani crowdsourced per classificarli. DGrid sta verificando se identità onchain, ricompense e agenti-giudici possano combinare entrambi gli approcci senza corrompere il segnale di preferenza.

Google News porta l'esperimento di routing di DGrid sotto una luce più ampia

Il cambiamento importante non è che DGrid abbia registrato agenti su una blockchain. È che i loro giudizi stanno diventando input per la scoperta e il routing dei modelli.

DGrid ha lanciato Arena for Agent come estensione della sua piattaforma esistente di confronto alla cieca. Un partecipante configura un agente con un provider API, una chiave API e un modello supportato. DGrid invia quindi a quell'agente attività di valutazione che coinvolgono due risposte anonime di modelli.

L'agente restituisce una preferenza anziché produrre le risposte originali. DGrid distribuisce l'attività, registra il risultato e aggiorna il saldo delle ricompense dell'agente. Il suo sistema di valutazione degli agenti supporta modelli accessibili tramite DGrid, OpenRouter, OpenAI, Google, Anthropic e altri provider elencati.

DGrid descrive un ciclo chiuso. Un sistema AI genera una domanda, due modelli la rispondono e un altro modello AI sceglie la risposta migliore. Il giudizio risultante alimenta i dati sulle prestazioni della piattaforma.

È qui che l'inquadramento di Google News merita cautela. Google News è il canale di scoperta dell'elemento CertiK citato, non lo sviluppatore, l'operatore o lo standard tecnico alla base dell'esperimento. I soggetti sottostanti sono Arena di DGrid, le sue identità degli agenti e le sue ambizioni di routing dei modelli.

Ogni valutatore configurato riceve un'identità registrata tramite ERC-8004 su BNB Chain. ERC-8004 è uno standard proposto per agenti che definisce registri per identità, reputazione e validazione. Il record di identità può rendere un agente individuabile e collegarlo a feedback pubblici.

Lo standard non rende un agente intelligente o accurato. Registra quale agente ha agito e crea uno spazio per i dati sulla reputazione. La specifica ufficiale ERC-8004 separa identità, reputazione e validazione perché tali funzioni risolvono problemi di fiducia differenti.

DGrid collega inoltre ricompense economiche alle valutazioni completate. La sua descrizione pubblicata afferma che la qualità dell'attività influisce sull'assegnazione dei punti e impone un limite giornaliero ai guadagni di ciascun agente. Questo assetto incoraggia i proprietari a mantenere gli agenti disponibili e a inviare giudizi in modo coerente.

Tuttavia, un record di transazione prova soltanto che un partecipante registrato ha inviato un risultato. Non dimostra che la preferenza fosse corretta, indipendente o allineata alle esigenze di un utente umano. Questo divario definisce la questione centrale dell'esperimento di DGrid.

La pagina pubblica Arena di DGrid presenta attualmente dati di partecipazione relativi a voti, giudici, modelli e agenti attivi. Questi dati sono contatori di prima parte e non sono stati sottoposti a verifica indipendente. Indicano la scala dichiarata da DGrid, ma non dovrebbero essere considerati prove verificate della qualità del routing.

L'esperimento modifica quindi la pipeline di valutazione più dei modelli sottostanti. DGrid sta cercando di convertire giudizi continui a coppie in un segnale riutilizzabile per il routing. Che tale segnale migliori la selezione dei modelli dipende da come la piattaforma filtra bias, collusione, ripetizione e partecipazione di bassa qualità.

La valutazione automatizzata mette sotto pressione i test delle preferenze umane

Gli agenti di DGrid possono produrre preferenze più rapidamente delle persone, ma la velocità conta soltanto se le etichette risultanti rappresentano ciò che gli utenti valutano realmente.

Il confronto alla cieca è diventato un metodo influente per valutare i modelli conversazionali. Due sistemi rispondono allo stesso prompt senza mostrare le proprie identità. Un votante seleziona la risposta preferita, riducendo l'influenza della reputazione del marchio.

LMArena ha contribuito a consolidare questo metodo utilizzando partecipanti umani. La sua ricerca sull'arena ha descritto oltre 240.000 voti nel dataset originale dell'articolo. I ricercatori hanno riferito che le preferenze crowdsourced mostravano una concordanza significativa con i valutatori esperti.

DGrid riprende la struttura anonima e a coppie, ma cambia chi esprime molti dei voti. Un agente può elaborare attività in modo continuo e applicare ripetutamente lo stesso prompt di valutazione. Questa coerenza è interessante quando una piattaforma copre numerosi modelli e riceve nuovi output ogni giorno.

La risposta obbligata per le piattaforme di valutazione guidate dagli esseri umani non è necessariamente mettere ogni voto onchain. Devono mostrare perché i giudizi umani forniscano informazioni che i giudici sintetici non possono riprodurre. Potrebbero inoltre aver bisogno di sistemi ibridi più rapidi che riservino le persone ai casi ambigui o ad alto impatto.

I router centralizzati subiscono pressioni da un'altra direzione. Servizi come OpenRouter analizzano già i prompt e selezionano da un pool curato di modelli. Il suo router automatico considera fattori quali il tipo di attività, la complessità del prompt e le capacità del modello.

La distinzione proposta da DGrid è il ciclo di feedback. Invece di affidarsi soltanto a benchmark interni o a una politica di routing gestita centralmente, vuole preferenze da una rete di partecipanti identificabili. Questi partecipanti possono includere esseri umani e agenti configurati in modo indipendente.

In teoria, questo amplia la copertura. Un giudice focalizzato sulla programmazione potrebbe rivelare quale candidato gestisce bene le domande sui repository. Un altro agente potrebbe specializzarsi nella scrittura multilingue o nell'estrazione strutturata. Il router potrebbe apprendere preferenze specifiche per attività invece di basarsi su un'unica classifica globale.

In pratica, la specializzazione deve essere dimostrata anziché dedotta dalla registrazione di un agente. DGrid necessita di un numero sufficiente di valutazioni ripetute e controllate per determinare se un giudice operi in modo affidabile all'interno di una categoria. Un modello che valuta bene brevi risposte fattuali potrebbe fallire nell'analisi legale, nell'umorismo o nella sintesi in forma lunga.

Anche la fonte dei prompt conta. Un router addestrato prevalentemente su domande semplici può sembrare accurato pur fallendo sul lavoro che gli sviluppatori inviano davvero. DGrid afferma che il suo sistema usa agenti che definiscono le domande, introducendo un ulteriore livello automatizzato nella pipeline dei dati.

I prompt sintetici possono ampliare rapidamente i test, ma potrebbero riflettere le abitudini dei modelli che li generano. Formulazioni simili, schemi di benchmark familiari o una copertura tematica ristretta possono far apparire i modelli candidati più capaci di quanto non siano in produzione.

I prompt umani contengono contesto incompleto, vincoli insoliti, errori di battitura, intenzioni mutevoli e conoscenze locali. Queste imperfezioni non sono rumore da eliminare. Fanno parte dell'ambiente che un router utile deve saper gestire.

La versione più solida dell'approccio di DGrid è quindi ibrida. Gli agenti forniscono una copertura ampia e ripetibile, mentre gli esseri umani offrono calibrazione per i casi soggettivi e difficili. L'Arena di DGrid include entrambe le modalità di partecipazione, offrendole una possibile strada verso questo equilibrio.

Per gli sviluppatori, il vantaggio sarebbe concreto. Un'applicazione potrebbe inviare una richiesta di classificazione ordinaria a un modello piccolo, instradare altrove un'attività di pianificazione complessa e mantenere un fallback in caso di errore di un provider. I team dedicherebbero meno tempo alla manutenzione di regole specifiche per ciascun modello.

Tuttavia, la selezione dei modelli non può dipendere soltanto dalla qualità delle risposte. I sistemi di produzione considerano anche latenza, disponibilità, lunghezza del contesto, politiche sui dati, supporto agli strumenti e comportamento prevedibile. Il segnale di routing di DGrid deve collegare i dati sulle preferenze a questi vincoli operativi.

L'identità onchain non può verificare il ragionamento di un giudice AI

DGrid può rendere tracciabile un valutatore senza rendere affidabile il suo giudizio: è questo il compromesso che definisce l'esperimento.

ERC-8004 offre a DGrid un modo strutturato per identificare gli agenti. Lo standard utilizza un registro delle identità e supporta record associati di reputazione o validazione. Questo può aiutare a distinguere i partecipanti persistenti dagli account anonimi usa e getta.

Ciò è utile per l'accountability. Se un agente è ripetutamente in disaccordo con giudizi di riferimento affidabili, il sistema può ridurne l'influenza. Se ottiene buoni risultati in attività controllate, la sua reputazione può acquisire maggiore valore.

Tuttavia, l'identità è soltanto il primo livello. Un proprietario può registrare un agente e poi modificare il modello, il prompt, la configurazione API o la logica circostante. La descrizione di DGrid consente agli utenti di aggiornare le impostazioni API dopo la creazione, mentre l'identità onchain rimane invariata.

Questo crea un problema di continuità. Un punteggio di reputazione può descrivere diverse configurazioni di valutatore che operano sotto un unico nome. A meno che ogni modifica significativa della configurazione non venga registrata e incorporata nel punteggio, gli utenti non possono sapere quale versione abbia ottenuto la reputazione.

Esiste inoltre un confine di verifica tra la chain e il provider del modello. La maggior parte delle chiamate ai modelli commerciali avviene offchain tramite API private. Un record blockchain non può stabilire in modo indipendente quale modello abbia elaborato un'attività, quale system prompt abbia ricevuto o se il giudizio restituito sia stato modificato prima dell'invio.

I metodi di validazione possono ridurre questo divario. Ambienti di esecuzione affidabili, prove crittografiche, ricevute firmate dai provider o inferenza riproducibile di modelli aperti possono offrire prove più solide. Ogni metodo aggiunge costi, complessità o requisiti hardware.

I materiali tecnici più ampi di DGrid descrivono Proof of Quality, o PoQ, come un framework per valutare gli output di inferenza attraverso allineamento dell'accuratezza, coerenza delle risposte, conformità al formato e segnali correlati. Il suo litepaper della rete descrive inoltre il caricamento di log e punteggi di qualità per record verificabili.

Si tratta di affermazioni progettuali di DGrid, non di una conferma indipendente che ogni giudizio di Arena riceva una verifica crittografica completa. La documentazione pubblica non fornisce ancora dettagli sufficienti per riprodurre l'intero metodo di punteggio o misurarne il tasso di errore tra i modelli giudice.

La distinzione è importante perché un giudice AI può presentare un errore perfettamente tracciabile. Può favorire una risposta più lunga, ripetere le preferenze stilistiche di un provider, non cogliere un sottile errore fattuale o selezionare una risposta non sicura che suona sicura di sé.

Gli incentivi economici possono aggravare il problema se la piattaforma premia l’accordo in modo troppo diretto. Il proprietario di un agente potrebbe ottimizzare per la risposta di consenso anziché per la risposta migliore. Quando i partecipanti imparano quali stili tendono a vincere, possono produrre voti prevedibili senza svolgere una valutazione accurata.

Questo ricorda il problema affrontato dai sistemi di reputazione online. I registri pubblici scoraggiano alcuni abusi, ma i partecipanti possono comunque coordinarsi, imitare comportamenti di successo o creare identità multiple quando le ricompense attese superano i costi di registrazione.

Il design onchain di DGrid può aiutare gli investigatori a individuare schemi che un database privato potrebbe nascondere. Gli analisti potrebbero esaminare relazioni di voto ripetute, concentrazioni di ricompense o gruppi sospetti. La trasparenza supporta gli audit, ma non li esegue automaticamente.

La privacy introduce un’altra preoccupazione. Le richieste ai modelli spesso contengono codice proprietario, dati personali, documenti aziendali o istruzioni interne. Registrare prompt e output completi su una chain pubblica sarebbe inadatto a molti utilizzi aziendali.

Un sistema pratico dovrebbe registrare commitment, hash, prove di pagamento o metadati limitati, mantenendo i contenuti sensibili offchain. Deve inoltre prevedere politiche chiare di conservazione per i dati di valutazione offchain. La permanenza onchain non elimina i tradizionali obblighi di sicurezza.

Per gli acquirenti, la questione non è se la blockchain compaia nell’architettura. È se il sistema sia in grado di mostrare una catena affidabile dalla classificazione del compito alla selezione dei candidati, alla valutazione, alla decisione di routing e al risultato osservato in produzione.

Queste prove devono restare comprensibili agli operatori. Un team che esegue il debug di una risposta scadente deve sapere perché il router ha selezionato un modello. Un identificatore immutabile dell’agente offre poco aiuto se la policy decisionale rimane opaca.

Il vero rischio è che i giudici AI rafforzino i bias dell’AI

L’esperimento fallisce se i voti degli agenti diventano un segnale auto-confermante che premia comportamenti familiari dei modelli invece dei risultati per gli utenti.

La valutazione LLM-as-a-judge è utile perché modelli capaci possono confrontare le risposte con una frazione dell’impegno richiesto ai revisori esperti. I ricercatori sanno però anche che questi giudici manifestano preferenze sistematiche.

Un problema documentato è il bias di posizione. Un giudice può favorire la risposta che appare per prima o per seconda, anche quando il contenuto rimane invariato. I ricercatori che hanno studiato 12 modelli giudice su oltre 100.000 istanze di valutazione hanno rilevato che gli effetti di posizione variavano in base al compito e al giudice.

La stessa ricerca ha rilevato che il divario qualitativo tra le risposte influenzava l’entità dell’effetto. Le differenze evidenti sono più facili da giudicare. I confronti ravvicinati lasciano più spazio a caratteristiche di presentazione irrilevanti per influenzare il risultato.

Un altro problema è il bias stilistico. Un giudice può premiare linguaggio sicuro di sé, formattazione rigida, lunghezza o dettaglio esplicativo anche quando tali caratteristiche non migliorano l’accuratezza fattuale. I modelli candidati possono quindi ottimizzare per le preferenze visibili dei valutatori.

L’auto-preferenza rappresenta un rischio particolarmente rilevante per DGrid. Un agente alimentato da una famiglia di modelli può favorire risposte che assomigliano allo stile o al ragionamento di quella famiglia. Se molti partecipanti configurano lo stesso giudice popolare, le classifiche risultanti possono ereditare una prospettiva concentrata.

DGrid può ridurre questi effetti randomizzando l’ordine delle risposte e valutando coppie invertite. Può usare più famiglie di giudici, misurare il disaccordo tra valutatori, inserire compiti di controllo verificati e separare le categorie oggettive da quelle soggettive.

La piattaforma deve inoltre spiegare come risolve i conflitti. Un voto di maggioranza è facile da comprendere, ma una maggioranza di giudici correlati non equivale a prove indipendenti. Dieci agenti che usano lo stesso modello sottostante possono contribuire meno informazioni di tre valutatori realmente diversi.

Il design delle ricompense richiede un’analoga attenzione. DGrid afferma che i punti legati alla qualità incoraggiano giudizi migliori, ma la qualità necessita di un riferimento esterno. Se la piattaforma definisce la qualità principalmente come accordo con i pari, agenti coordinati o omogenei possono dominare il segnale.

La calibrazione umana può fornire quel riferimento. Gli esperti possono esaminare un campione di confronti contestati, mentre gli utenti comuni possono esprimere preferenze sulla utilità conversazionale. Queste etichette possono rivelare dove il consenso automatizzato si discosta dalle aspettative umane.

Tuttavia, anche i voti umani contengono bias e standard incoerenti. Un sistema di valutazione utile non dovrebbe idealizzare nessuna delle due parti. Dovrebbe misurare il disaccordo e associare la popolazione dei giudici all’applicazione.

Un router per la sintesi medica, ad esempio, necessita di valutazioni fattuali e di sicurezza da parte di revisori qualificati. Un router per la scrittura creativa necessita delle preferenze del pubblico, anziché di una risposta presuntamente corretta. Un router per il coding necessita di test eseguibili accanto alla valutazione stilistica.

Per questo una singola classifica globale dei modelli non può risolvere la selezione automatica. Il routing richiede prove condizionali: quale modello funziona per questo compito, con questi vincoli, per questa popolazione di utenti? L’Arena di DGrid può contribuire con dati, ma solo se preserva queste distinzioni.

L’interfaccia pubblica della piattaforma enfatizza voti e classifiche aggregate. L’attività aggregata può attirare partecipazione, ma rivela poco su intervalli di confidenza, copertura delle categorie, diversità dei giudici o resistenza alla manipolazione.

Gli sviluppatori che valutano il servizio dovrebbero chiedere questi dettagli prima di affidarsi al routing automatico. Dovrebbero inoltre mantenere allowlist di modelli, controlli di spesa, logging e fallback deterministici. Un router dovrebbe rimanere un componente di policy, non un’autorità non revisionata.

I team che raccolgono le proprie valutazioni necessitano di una disciplina comparabile. Una knowledge base AI ricercabile può aiutare a conservare prompt, decisioni e note dei revisori, ma i criteri di valutazione richiedono comunque una progettazione deliberata.

Il risultato più prezioso di DGrid potrebbe non essere una classifica universale. Potrebbe essere un dataset trasparente che mostra quando gli agenti non sono d’accordo, quali giudici rimangono affidabili e come cambiano le preferenze tra i diversi compiti.

Questo risultato renderebbe il sistema più utile anche se una valutazione pienamente autonoma si rivelasse irrealistica. Il disaccordo è informazione. Nasconderlo dietro un unico punteggio di routing sprecherebbe il più forte contributo potenziale dell’esperimento.

Tre segnali mostreranno se DGrid migliora la selezione dei modelli

DGrid ora necessita di prove riproducibili, utilizzo reale diversificato e miglioramenti misurabili del routing, anziché contatori di partecipazione più alti.

Il primo segnale è una metodologia di valutazione pubblica con dettagli sufficienti per test indipendenti. DGrid dovrebbe definire il campionamento dei prompt, la randomizzazione delle risposte, la ponderazione dei giudici, i compiti di controllo, la gestione del disaccordo e la resistenza agli agenti duplicati.

Un benchmark riproducibile rafforzerebbe l’affermazione centrale. Ricercatori indipendenti potrebbero confrontare le classifiche derivate dagli agenti di DGrid con etichette di esperti e voti umani dell’Arena. Un forte accordo in diverse categorie di compiti sosterrebbe l’approccio automatizzato.

Un ampio disaccordo non lo screditerebbe automaticamente. La domanda importante sarebbe se DGrid identifichi tale incertezza e impedisca a segnali deboli di controllare il routing in produzione. L’astensione consapevole della confidenza può essere più utile di una risposta forzata.

L’esperimento perderebbe credibilità se la metodologia rimanesse opaca mentre i contatori di attività proprietari continuano a salire. Più voti non risolvono il bias correlato. Possono amplificarlo.

Il secondo segnale è la composizione della partecipazione all’Arena. DGrid dovrebbe divulgare la distribuzione di modelli giudice, provider, categorie di compiti, regioni e partecipanti ricorrenti senza esporre informazioni private.

Un bacino di giudici diversificato rafforzerebbe l’idea che gli agenti onchain aggiungano prospettive indipendenti. Una concentrazione attorno a un provider o a una strategia di ricompensa la indebolirebbe. Lo stesso vale per prompt generati da una ristretta famiglia di modelli che impostano le domande.

La partecipazione umana resta rilevante in questo contesto. La AI Arena pubblica di DGrid consente alle persone di confrontare risposte anonime accanto ai valutatori agenti. La relazione tra questi due flussi di voto conta più del loro totale combinato.

La piattaforma dovrebbe riportare dove umani e agenti concordano, dove divergono e quale lato predice la successiva soddisfazione degli utenti. Questo trasformerebbe il suo design ibrido in un vantaggio empirico.

Il terzo segnale è la performance del routing in produzione. DGrid deve dimostrare che i dati sulle preferenze migliorano le richieste reali rispetto a baseline più semplici. Tali baseline dovrebbero includere selezione manuale del modello, regole statiche, scelta casuale tra modelli qualificati e un router automatico centralizzato.

Misure utili includono successo del compito, tasso di correzione, latenza, frequenza di fallback e override degli utenti. Il costo può far parte del confronto senza ridurre la qualità alla risposta disponibile più economica.

Uno studio controllato potrebbe instradare richieste simili attraverso policy diverse, quindi valutare gli esiti usando sia test oggettivi sia revisori in cieco. Il risultato dovrebbe identificare quali carichi di lavoro ne traggono vantaggio, anziché presentare un unico numero di miglioramento universale.

È qui che il gateway e l’Arena di DGrid si connettono oppure rimangono prodotti separati. Il gateway pubblicizza l’accesso a più di 200 modelli e il routing intelligente. L’Arena sostiene che i voti addestrino decisioni di routing più intelligenti.

DGrid non ha ancora pubblicato prove indipendenti sufficienti per stabilire quanto tali voti migliorino la selezione in tempo reale. L’anello mancante è un confronto misurato prima-e-dopo che utilizzi carichi di lavoro divulgati.

La visibilità di CertiK può aggiungere controllo, ma non dovrebbe essere scambiata per un audit del metodo di valutazione. Il profilo DGrid di CertiK ha elencato informazioni su sicurezza e maturità, indicando al contempo che un audit del codice CertiK non era disponibile nel profilo indicizzato. Il monitoraggio della sicurezza e la validazione della qualità del modello sono valutazioni separate.

Anche il mercato più ampio fornirà un test. I servizi di routing centralizzati possono aggiornarsi rapidamente, utilizzare dati di produzione privati ed evitare l’overhead della blockchain. DGrid deve dimostrare che la partecipazione aperta e l’identità tracciabile creino informazioni che tali sistemi non riescono a raccogliere con la stessa efficacia.

Se DGrid pubblicherà miglioramenti riproducibili, dimostrerà diversità dei giudici e collegherà le preferenze dell’Arena a risultati di produzione migliori, il suo esperimento sosterrà un nuovo modello di routing. Gli agenti onchain servirebbero allora come contributori responsabili anziché come identità blockchain decorative.

Se questi segnali non appariranno, il progetto potrebbe comunque gestire una piattaforma di ricompense molto attiva. Non avrà però dimostrato che i voti degli agenti selezionano modelli migliori.

I lettori che arrivano tramite google news dovrebbero osservare la catena delle prove, non il titolo sulla partecipazione. DGrid può mostrare chi ha giudicato, come è stato controllato il bias e se le applicazioni hanno ricevuto risposte migliori? Queste tre domande stabiliranno se diventerà un’infrastruttura AI utile o un altro ciclo di valutazione autoreferenziale.