Cosa conta come evidenza di un AI component
Nota: Questo documento è una traduzione automatica della versione originale in inglese.
Cosa conta come evidenza di un AI component
Quando DecAIHub valuta se un progetto ha un AI component funzionante, cerca artefatti verificabili — non testi di marketing, non promesse, non associazioni di brand. Questa pagina elenca i tipi di evidenza che rafforzano l'asse AI reality del punteggio DecAI Fit, ordinati dal più forte al più debole.
In sintesi: evidenza di AI significa artefatti che puoi ispezionare, testare o verificare in modo indipendente — codice, documentazione, metriche con metodologia, demo funzionanti e valutazioni di terze parti.
Evidenza Tier-1 (la più forte)
Le fonti Tier-1 sono artefatti pubblicati o controllati dal progetto stesso. Per l'asse AI reality, l'evidenza Tier-1 più forte include:
- Repository pubblico con codice AI/ML — script di addestramento del modello, logica di inferenza, pipeline di dati, passaggi di preprocessing. Un repository con commit, release e test è molto più forte di un repo segnaposto con un README.
- Documentazione tecnica — descrizioni dell'architettura del modello, dei formati di input/output, delle versioni del modello e della cronologia degli aggiornamenti. Risponde a "quale modello, come funziona e quale versione è in esecuzione".
- Metriche di qualità con metodologia — benchmark pubblicati o risultati di valutazione che specificano cosa è stato misurato, su quali dati, quando e con quale versione del modello. Le metriche senza questo contesto non sono evidenza.
- Demo o endpoint funzionanti — un'interfaccia, un'API o una sandbox pubblicamente accessibile dove l'AI component può essere testato. Una demo che elabora input reali e restituisce output guidati dall'AI è evidenza diretta.
- Report di audit o valutazioni di terze parti — valutazioni indipendenti della qualità, dell'equità, della sicurezza o delle prestazioni del modello da parte di un'entità riconosciuta.
Schemi che rafforzano l'evidenza Tier-1
Non tutti gli artefatti Tier-1 sono ugualmente convincenti. Diversi schemi osservabili rendono l'evidenza più credibile:
- Profondità della cronologia dei commit. Un repository con mesi o anni di commit incrementali, pull request, revisioni del codice e release versionate dimostra uno sforzo ingegneristico sostenuto. Un singolo caricamento in blocco ha molto meno peso.
- Copertura dei test e pipeline CI. Test automatizzati per l'inferenza del modello, la validazione dei dati e gli endpoint di integrazione indicano un sistema di livello produttivo piuttosto che un proof-of-concept.
- Modelli versionati e changelog. Quando la documentazione traccia quale versione del modello è distribuita, cosa è cambiato tra le versioni e perché, segnala un sistema vivo con un ciclo di sviluppo attivo.
- Output riproducibili. Se una demo o un'API restituisce risultati coerenti e spiegabili per gli stessi input tra sessioni diverse, questo è più forte di una vetrina una tantum.
- Separazione della logica AI dal boilerplate. Una codebase in cui i moduli AI/ML sono chiaramente identificabili — distinti dall'impalcatura frontend, dagli script di deployment o dai contratti del token — rende più facile verificare cosa fa realmente l'AI component.
Evidenza Tier-2 (contesto, non prova)
Le fonti Tier-2 forniscono contesto ma da sole non dimostrano un AI component funzionante:
- Interviste o AMA in cui il team descrive l'approccio AI, l'architettura o il processo di addestramento.
- Descrizioni degli aggregatori (CoinGecko, DeFiLlama, ecc.) che menzionano capacità AI.
- Annunci di partnership con provider AI o laboratori di ricerca.
L'evidenza Tier-2 può supportare un riscontro Tier-1 ma non può sostituirlo. Una partnership con un'azienda AI non dimostra che il progetto abbia una propria AI funzionante.
Quando l'evidenza Tier-2 è importante
Le fonti Tier-2 diventano rilevanti quando corroborano artefatti Tier-1 o colmano lacune che il solo Tier-1 lascia ambigue:
- Un'intervista tecnica in cui il team illustra l'architettura descritta nella propria documentazione aggiunge credibilità alla documentazione Tier-1.
- Una scheda su un aggregatore che corrisponde alle capacità descritte nel whitepaper del progetto stesso segnala coerenza.
- Un intervento a una conferenza con una demo dal vivo che rispecchia il comportamento dell'API pubblica del progetto rafforza l'idea che la demo non sia preconfezionata.
Senza artefatti Tier-1 sottostanti, tuttavia, anche fonti Tier-2 convincenti restano contesto — preziose per la comprensione, insufficienti per la verifica.
Cosa non conta
Alcuni artefatti sembrano evidenza ma non dimostrano un AI component funzionante. Falsi segnali comuni includono testi di marketing, repository vuoti, metriche senza metodologia e API wrapper senza logica proprietaria. Per un elenco dettagliato, vedi Cosa non conta come evidenza di AI.
Come DecAIHub registra l'evidenza AI: flag da AI_0 a AI_4
L'asse AI reality usa cinque flag binari per catturare quale evidenza è stata trovata:
| Flag | Cosa verifica | Valore |
|---|---|---|
| AI_0 | Esiste almeno una dichiarazione Tier-1 di intento AI (roadmap, aggiornamento ufficiale) | 1 / 0 |
| AI_1 | Esiste una descrizione di cosa fa l'AI | 1 / 0 |
| AI_2 | Esistono demo o esempi funzionanti | 1 / 0 |
| AI_3 | Esistono metriche di qualità con contesto (cosa, su quali dati, quando) | 1 / 0 |
| AI_4 | Esiste una descrizione tecnica, un'architettura o le versioni del modello | 1 / 0 |
Più flag sono uguali a 1, più alto è l'ai_score e migliore è il DecAI Fit del progetto. Se nessun flag è impostato, ai_score = 0 e il DecAI Fit non può superare 0.
Come le combinazioni di flag si traducono in fiducia
I singoli flag rispondono a domande ristrette, ma la loro combinazione dipinge un quadro più completo:
| Flag impostati | Interpretazione tipica |
|---|---|
| Solo AI_0 | Intento dichiarato; nessuna AI funzionante ancora verificata |
| AI_0 + AI_1 | AI descritta a parole; nessuna demo, nessuna metrica, nessuna architettura |
| AI_0 + AI_1 + AI_2 | Esiste una demo funzionante; mancano ancora metriche e profondità tecnica |
| AI_0 + AI_1 + AI_2 + AI_4 | Demo e architettura presenti; manca la misurazione della qualità |
| Tutti e cinque (da AI_0 ad AI_4) | Il profilo di evidenza più forte: intento, descrizione, demo, metriche e architettura |
Un progetto non deve soddisfare tutti e cinque i flag per ricevere un ai_score diverso da zero. Anche il solo AI_0 (intento con una fonte Tier-1) imposta ai_score = 1. Tuttavia, i flag superiori contribuiscono a un tetto più alto per il DecAI Fit.
Perché la metodologia è importante per le metriche
Un numero isolato — "95% di accuratezza", "bassa latenza", "stato dell'arte" — non è evidenza senza contesto. DecAIHub considera le metriche significative solo quando rispondono a quattro domande: cosa è stato misurato (accuratezza, F1, latenza, perplessità), su quali dati (benchmark pubblico, test set proprietario, traffico di produzione), quando (data della valutazione) e quale versione del modello ha prodotto il risultato. Senza questi elementi, una metrica è un'affermazione, non un'evidenza.
Il test delle quattro domande
Quando valuti qualsiasi metrica pubblicata, applica questa checklist:
- Cosa — La metrica è nominata e definita? "Accuratezza" è ambiguo; "accuratezza di classificazione top-1" è specifico.
- Su quali dati — Il dataset di valutazione è identificato? Un benchmark pubblico consente la riproduzione indipendente; un test set proprietario no, ma nominarlo è meglio del silenzio.
- Quando — Esiste una data o un tag di release? I modelli cambiano nel tempo; una metrica senza marca temporale può non riflettere il sistema attuale.
- Quale versione — La versione del modello o del sistema è dichiarata? Se un progetto ha rilasciato più iterazioni del modello, la metrica deve essere legata a una specifica.
Se una qualsiasi di queste quattro manca, la metrica scende da "evidenza" ad "affermazione" nella valutazione di DecAIHub. Può comunque comparire nella scheda del progetto come affermazione annotata, ma non contribuirà a impostare il flag AI_3 a 1.
Come usare questa checklist
Quando leggi una scheda di progetto, verifica se la tabella Evidence fa riferimento ad artefatti dell'elenco Tier-1 sopra. Se la scheda mostra ai_score = 0 o segnala una preoccupazione di AI-washing, significa che questi artefatti non sono stati trovati alla data di verifica — non è un'accusa contro il progetto.
Quando compaiono nuovi artefatti Tier-1, la scheda viene aggiornata e il punteggio può cambiare.
Passi pratici per i lettori
- Inizia dalla tabella Evidence. Cerca link a repository, documentazione o demo. Se la tabella Evidence è vuota o fa riferimento solo a fonti Tier-2/3, l'affermazione di AI reality non è verificata.
- Apri gli artefatti. Un link a un repository vale solo quanto ciò che contiene. Aprilo e cerca codice AI/ML, non solo un README o script di deployment.
- Controlla la data di verifica. L'evidenza è un'istantanea. Una scheda verificata sei mesi fa può non riflettere lo stato attuale del progetto, motivo per cui DecAIHub applica una penalità di obsolescenza dopo 550 giorni.
- Confronta con l'elenco degli anti-pattern. Se vedi schemi tratti da Cosa non conta come evidenza di AI, pesa l'evidenza di conseguenza.
Cosa questa checklist da sola non dimostra
- Soddisfare tutti i criteri di evidenza non dimostra che l'AI sia di alta qualità o utile agli utenti finali. Dimostra che gli artefatti esistono e possono essere ispezionati.
- L'evidenza Tier-1 proveniente dal progetto stesso non dimostra indipendenza. I dati auto-riportati dovrebbero idealmente essere corroborati da una valutazione di terze parti.
- Un registro di evidenze completo non dimostra che il token sia necessario. AI reality è un asse del DecAI Fit; token necessity è un altro.
Domande frequenti
Cosa conta come l'evidenza più completa di AI in un progetto crypto?
Un repository pubblico contenente codice AI/ML con una cronologia di commit significativa, combinato con metriche di qualità pubblicate che includono la metodologia completa (cosa è stato misurato, su quali dati, quando e quale versione del modello). Quando entrambi esistono e sono supportati da una demo funzionante o da un endpoint API, il profilo di evidenza è al suo massimo. Nessun singolo artefatto è definitivo da solo — la combinazione di codice, metriche e output testabili è ciò che distingue l'AI verificata dalle affermazioni non verificate.
Un progetto può avere AI reale senza codice open source?
Sì. Il codice open source è la forma più trasparente di evidenza, ma non è l'unica. Un progetto può dimostrare l'AI attraverso documentazione tecnica dettagliata, benchmark pubblicati con metodologia, API funzionanti che restituiscono output verificabili guidati dall'AI o valutazioni indipendenti di terze parti. Tuttavia, senza almeno qualche artefatto ispezionabile — codice, demo o valutazione — non c'è nulla che DecAIHub (o chiunque altro) possa verificare. Più un progetto è chiuso, più fa affidamento sulla corroborazione Tier-2 (interviste, dati di aggregatori, dimostrazioni a conferenze) per costruire credibilità.
Una demo funzionante dimostra che l'AI è reale?
Una demo funzionante è un'evidenza forte, ma di per sé non è una prova conclusiva. Un frontend ben progettato può simulare un comportamento simile all'AI usando risposte codificate, risultati precalcolati o chiamate nascoste a un'API di terze parti. DecAIHub tratta le demo come evidenza più forte quando sono accompagnate da documentazione API, identificatori di versione del modello o output riproducibili con input diversi. Una demo che accetta input arbitrari dell'utente e restituisce output variati e contestualmente appropriati è più convincente di una vetrina guidata con esempi predeterminati.
Qual è l'evidenza minima necessaria per un ai_score diverso da zero?
Il minimo è una dichiarazione Tier-1 di intento AI — una voce di roadmap, un post ufficiale sul blog o una pagina di documentazione che dichiara esplicitamente piani legati all'AI. Questo imposta il flag AI_0 a 1 e produce ai_score = 1. Sebbene sia il punteggio diverso da zero più basso possibile, distingue i progetti che si sono ufficialmente impegnati in una direzione AI da quelli che non hanno menzionato affatto l'AI. Per raggiungere punteggi più alti, il progetto deve fornire artefatti aggiuntivi: descrizioni dell'AI component (AI_1), demo (AI_2), metriche con metodologia (AI_3) e dettagli sull'architettura tecnica (AI_4).
Riferimenti esterni
- Specifica CommonMark — lo standard di markup usato in tutte le pagine wiki di DecAIHub, incluse le schede di progetto e gli explainer.
- Model Cards for Model Reporting (Mitchell et al., 2019) — un framework fondativo per documentare le prestazioni, l'uso previsto e i limiti dei modelli AI; strettamente allineato ai principi di trasparenza alla base dei criteri di evidenza di DecAIHub.
- NIST AI Risk Management Framework — un framework del governo statunitense per identificare e gestire i rischi dell'AI, incluse linee guida su documentazione, test e metodologia di valutazione.
No comments to display
No comments to display