Kimi K3 e GLM-5.2 cambiano la corsa dell’AI open-weight

Moonshot AI e Z.ai sono approdate su google news dopo aver rilasciato, a poche settimane di distanza, due modelli open-weight insolitamente ambiziosi. Kimi K3 di Moonshot porta con sé 2,8 trilioni di parametri, comprensione visiva nativa e una finestra di contesto da un milione di token. GLM-5.2 di Z.ai punta ai task di coding e agent di lunga durata, con 753 miliardi di parametri e una capacità di contesto comparabile.

I numeri colpiscono, ma le dimensioni del modello non sono il vero terreno di scontro. Entrambe le aziende mettono in discussione l’idea che l’AI avanzata debba restare dietro un’interfaccia chiusa controllata da un fornitore americano.

Gli sviluppatori possono ispezionare e distribuire i pesi dei modelli, nel rispetto della licenza di ciascun rilascio e con requisiti hardware considerevoli. Questo offre ai team di ingegneria maggiore controllo su hosting, personalizzazione, gestione dei dati e infrastruttura di inferenza.

I rilasci esercitano inoltre pressione su OpenAI e Anthropic da una direzione inattesa. Moonshot e Z.ai non propongono semplicemente sostituti più economici per la chat generalista. Puntano invece su agent per il coding, workflow di lunga durata e analisi di contesti estesi, ambiti nei quali i modelli chiusi hanno costruito le loro posizioni commerciali più solide.

L’esito non è ancora definito. I benchmark forniti dai vendor restano difficili da confrontare, i costi reali di deployment possono annullare i vantaggi teorici e un modello scaricabile non è automaticamente pratico da gestire. Eppure, l’arrivo di due rilasci credibili cambia la domanda che devono affrontare gli acquirenti enterprise.

La vecchia domanda era se un modello aperto potesse avvicinarsi alle prestazioni di frontiera. La nuova domanda è se i fornitori chiusi possano giustificare un controllo minore per i clienti quando le alternative open-weight diventano abbastanza valide per importanti carichi di lavoro in produzione.

Cosa hanno realmente cambiato Kimi K3 e GLM-5.2

I due rilasci trasformano l’AI open-weight da opzione secondaria a decisione infrastrutturale seria.

Moonshot ha presentato Kimi K3 nel luglio 2026 come il suo più recente modello di punta. Il relativo paper su Kimi K3 descrive un modello mixture-of-experts con 2,8 trilioni di parametri totali e 104 miliardi attivi durante l’inferenza.

Un modello mixture-of-experts instrada ogni token attraverso componenti specialistici selezionati invece di usare ogni parametro. Questo approccio consente a un modello di ampliare la propria capacità complessiva senza attivare l’intera rete per ogni richiesta.

Secondo il materiale tecnico di Moonshot, Kimi K3 utilizza 896 esperti e ne seleziona 16 per ciascun token. Accetta inoltre input visivi e supporta una finestra di contesto da un milione di token.

Una finestra di contesto è la quantità di informazioni che un modello può considerare durante una singola interazione. Un milione di token può contenere un grande repository di codice, una vasta documentazione tecnica o una lunga raccolta di registri aziendali.

Queste capacità rendono Kimi K3 più di un altro rilascio chatbot. Moonshot lo posiziona per lo sviluppo software, la ricerca, l’analisi visiva e il lavoro agentico che coinvolge più strumenti e cronologie estese delle attività.

L’espressione “Kimi K3 explained” richiede quindi un’importante precisazione. La caratteristica distintiva del modello non è semplicemente il numero di parametri. La sua proposta di valore combina attivazione sparsa, contesto lungo, input multimodale e pesi scaricabili.

Moonshot ha inizialmente fornito accesso tramite le proprie applicazioni e API, per poi rilasciare i pesi del modello e il report tecnico. Questa sequenza è rilevante perché le affermazioni open-weight acquistano maggiore significato quando sviluppatori indipendenti possono esaminare il rilascio effettivo.

Z.ai, nota anche come Zhipu AI, ha rilasciato GLM-5.2 seguendo un percorso tecnico differente. La sua model card ufficiale di GLM-5.2 indica 753 miliardi di parametri e un’opzione di contesto da un milione di token.

GLM-5.2 è rivolto principalmente a task testuali, di coding e agent di lunga durata. Per lunga durata si intende un lavoro che richiede al modello di mantenere i piani, recuperare dagli errori e coordinare molti passaggi nel corso di una sessione estesa.

La distinzione crea una divisione interessante. Kimi K3 enfatizza scala, comprensione visiva e ampie capacità agentiche. GLM-5.2 concentra invece il proprio posizionamento su coding, ragionamento prolungato e grandi contesti testuali.

Entrambi i rilasci forniscono i pesi dei modelli, ma open-weight non significa che ogni elemento dello sviluppo sia aperto. Dataset di addestramento, decisioni di filtraggio e pipeline di training complete possono restare non disponibili. Gli acquirenti dovrebbero distinguere i pesi scaricabili dalla riproducibilità completa.

Anche con questo limite, l’accesso cambia ciò che i team possono fare. Un’azienda può valutare un modello nel proprio ambiente, applicare salvaguardie personalizzate, studiare i modelli di errore ed evitare di inviare ogni richiesta a un servizio esterno.

Può inoltre costruire sistemi di serving specializzati attorno a carichi di lavoro prevedibili. Questo conta per le organizzazioni che elaborano codice sorgente, documenti legali, ricerca interna o altro materiale sensibile.

Ecco perché GLM-5.2 vs Kimi K3 non è soltanto una gara di benchmark. È un confronto tra due approcci per rendere capacità su scala frontier più controllabili dagli utenti.

I rilasci creano un test di mercato più ampio. Gli sviluppatori possono ora chiedersi se accesso, controllo e adattabilità compensino la comodità operativa offerta da un modello chiuso ospitato.

Perché i fornitori di AI chiusa sono ora sotto pressione

OpenAI e Anthropic sono sotto pressione perché i clienti possono confrontare qualità dei modelli e controllo del deployment nella stessa decisione d’acquisto.

I fornitori chiusi mantengono punti di forza importanti. Gestiscono servizi maturi, dispongono di vasti strumenti per sviluppatori e assorbono il lavoro necessario per servire modelli enormi. I loro clienti non devono assemblare cluster, ottimizzare l’inferenza o gestire gli aggiornamenti dei modelli.

Questi vantaggi restano sostanziali. Tuttavia, non chiudono più la discussione.

Kimi K3 e GLM-5.2 offrono alle imprese un’altra strada. Un team può usare un endpoint ospitato durante la sperimentazione, quindi valutare un deployment privato quando privacy, latenza, personalizzazione o volume dei carichi di lavoro giustificano lo sforzo.

Questa opzione cambia le negoziazioni anche quando il cliente non esegue mai il self-hosting. Un’alternativa credibile riduce la dipendenza dal comportamento del modello di un singolo fornitore, dalle sue regole di accesso, dalla roadmap di prodotto e dalla disponibilità del servizio.

La pressione è più forte nel coding. Gli agent software consumano contesti ampi perché devono ispezionare file, comprendere dipendenze, leggere documentazione, eseguire strumenti e conservare la cronologia dei tentativi precedenti.

Un breve scambio con un chatbot è relativamente facile da spostare tra fornitori. Un workflow ingegneristico costruito attorno a un comportamento agentico proprietario diventa più difficile da migrare.

Entrambi i modelli cinesi prendono di mira questa dipendenza. Z.ai descrive GLM-5.2 come un miglioramento nel lavoro di lunga durata, mentre Moonshot presenta Kimi K3 come modello per il coding e i task agentici generali.

Le loro valutazioni riportate dalle aziende suggeriscono risultati competitivi su benchmark selezionati di coding e agent. Queste affermazioni meritano cautela, poiché impostazioni dei test, accesso agli strumenti, prompting e procedure di valutazione possono influenzare le classifiche.

I segnali indipendenti sono comunque degni di nota. Una valutazione di Associated Press ha riportato che Kimi K3 ha raggiunto il vertice di una classifica Arena per la capacità di coding front-end. Lo stesso rapporto ha rilevato un crescente interesse internazionale degli sviluppatori per GLM-5.2.

La valutazione in stile Arena si basa su confronti o giudizi di preferenza, anziché su una chiave di risposta fissa. Può catturare qualità che i test convenzionali non rilevano, ma misura anche una particolare interfaccia e popolazione di utenti.

Nessun singolo risultato stabilisce una superiorità complessiva. I modelli per il coding possono funzionare bene su task isolati ma avere difficoltà con convenzioni di repository, requisiti ambigui, errori degli strumenti o modifiche distribuite su molti file.

Tuttavia, i laboratori chiusi devono rispondere a un quadro più ampio. I rilasci open-weight stanno raggiungendo il punto in cui i team possono testarli su carichi di lavoro interni reali, invece di liquidarli sulla base di ipotesi superate.

Questo è particolarmente importante per gli acquirenti che necessitano di verificabilità. I pesi scaricabili non rendono un modello completamente trasparente, ma i test locali offrono maggiore visibilità sul comportamento in condizioni controllate.

I team possono costruire suite di regressione attorno al proprio codice, ai propri documenti e alle proprie policy. Possono confrontare gli output tra versioni del modello prima di approvare una migrazione.

Questo processo supporta un workflow AI più disciplinato. Il modello diventa un componente sostituibile all’interno di un sistema documentato, anziché il centro permanente del sistema.

OpenAI e Anthropic possono rispondere con maggiore affidabilità, controlli di sicurezza più forti, deployment più semplice e supporto superiore. Possono inoltre continuare a migliorare i modelli proprietari più rapidamente di quanto le alternative aperte possano essere rese operative.

Il cambiamento chiave è che devono dimostrare questi vantaggi. Il riconoscimento del marchio da solo diventa meno persuasivo quando gli sviluppatori possono scaricare concorrenti credibili ed eseguire valutazioni dirette.

La copertura di Google News amplifica questa pressione perché porta il dibattito oltre le comunità specializzate nei modelli. I leader enterprise incontrano ora Kimi K3 e GLM-5.2 come opzioni strategiche, non come oscuri rilasci di ricerca.

La risposta imposta si svilupperà nell’arco di mesi, non di giorni. Occorre osservare limiti di contesto più lunghi, deployment enterprise più flessibile, migliore portabilità dei modelli e spiegazioni più solide su ciò che i servizi gestiti offrono oltre alla pura intelligenza.

GLM-5.2 vs Kimi K3 riguarda in realtà controllo vs comodità

Il compromesso centrale non riguarda quale modello vinca una classifica statica, ma chi controlli l’infrastruttura che circonda il modello.

Kimi K3 presenta il pacchetto di capacità più ampio. La sua elaborazione visiva nativa gli consente di lavorare con immagini accanto al testo, mentre il contesto da un milione di token supporta grandi raccolte di materiale correlato.

Moonshot ha inoltre progettato il modello attorno al calcolo sparso. Solo una parte dell’enorme pool di parametri è attiva per ciascun token, riducendo il lavoro richiesto rispetto all’attivazione di tutti i 2,8 trilioni di parametri.

L’attivazione ridotta non rende il modello piccolo. L’intero set di pesi resta immenso e i deployment pratici richiedono notevoli risorse di storage, memoria, rete e competenze ingegneristiche.

La quantizzazione può ridurre queste esigenze rappresentando i pesi con meno bit. Tuttavia, una compressione aggressiva può modificare accuratezza, latenza o stabilità, a seconda dell’implementazione e del carico di lavoro.

GLM-5.2 ha un numero totale di parametri inferiore, pur restando ben oltre la scala dei normali modelli locali. Il suo design più mirato a testo e coding può interessare organizzazioni che non necessitano di input visivi nativi.

La model card enfatizza un contesto utilizzabile da un milione di token e prestazioni migliorate nei task agentici estesi. Questo lo rende rilevante per l’analisi di codebase, modifiche su più file, sintesi della ricerca e uso prolungato degli strumenti.

Tuttavia, la capacità di contesto pubblicizzata non equivale a prestazioni affidabili sui contesti lunghi. Un modello può accettare un prompt enorme senza riuscire a recuperare un fatto cruciale, preservare il proprio piano o dare correttamente priorità alle istruzioni recenti.

I team dovrebbero testare il contesto effettivo, non solo quello massimo. Una buona valutazione colloca i fatti rilevanti in posizioni diverse, introduce distrazioni e misura se il modello utilizza le prove in modo coerente.

Lo stesso principio si applica ai benchmark degli agent. Le prestazioni di un agent dipendono dal framework circostante, comprese definizioni degli strumenti, logica di retry, autorizzazioni, memoria e ambiente di esecuzione.

Un modello che eccelle nell’ambiente di un fornitore può comportarsi diversamente in quello di un altro. Confrontare GLM-5.2 e Kimi K3 richiede quindi una configurazione condivisa e criteri di successo identici.

Per un team software, tali criteri potrebbero includere i test superati, i file errati modificati, il tempo di revisione, il recupero dopo errori degli strumenti e la percentuale di attività completate senza intervento.

Per un team di ricerca, i criteri potrebbero includere l’accuratezza delle citazioni, la copertura delle evidenze, la gestione delle contraddizioni e la capacità di ricondurre le conclusioni al materiale di origine.

È qui che il controllo diventa prezioso. I pesi aperti consentono alle organizzazioni più evolute di modificare il comportamento di serving e decidere dove transitano i dati. Permettono inoltre un accesso di lungo periodo a una specifica versione del modello.

Un modello proprietario ospitato può cambiare tramite un aggiornamento. Anche quando il fornitore migliora la qualità media, il nuovo comportamento può influenzare prompt, valutazioni o processi automatizzati.

L’esecuzione di una versione fissa a pesi aperti offre ai clienti maggiore controllo su questo ciclo di cambiamento. Possono qualificare gli aggiornamenti prima della distribuzione in produzione e conservare una versione di riserva.

La convenienza spinge nella direzione opposta. Le API gestite offrono configurazione rapida, capacità elastica, monitoraggio e supporto senza richiedere un team specializzato nell’inferenza.

La maggior parte delle organizzazioni non dovrebbe presumere che l’hosting autonomo sia automaticamente più economico o più sicuro. Un’infrastruttura gestita male può creare rischi propri in termini di disponibilità, privacy e controllo degli accessi.

La domanda migliore è quale livello un’organizzazione debba controllare. Alcuni team necessitano solo di protezioni contrattuali dei dati da un fornitore gestito. Altri richiedono reti private, logging personalizzato, versioni fisse del modello o distribuzione in una giurisdizione definita.

Kimi K3, osservato attraverso questa lente, diventa una scelta di distribuzione, non uno spettacolo sui trilioni di parametri. GLM-5.2 porta la stessa implicazione attraverso una progettazione più incentrata sulla programmazione.

Nessuno dei due modelli elimina l’AI chiusa. Entrambi rendono invece più visibile il premio richiesto per la comodità delle soluzioni chiuse.

I benchmark non risolvono la sfida

Le affermazioni più forti restano affermazioni dei fornitori finché test indipendenti non le riproducono su carichi di lavoro realistici.

Moonshot riferisce che Kimi K3 offre prestazioni competitive nelle valutazioni su programmazione, agenti e capacità generali. Z.ai riferisce miglioramenti rispetto a GLM-5.1, in particolare per attività lunghe e contesto esteso.

Questi risultati forniscono punti di partenza utili, ma non garantiscono esiti in produzione. Contaminazione dei benchmark, selezione dei prompt, configurazione degli strumenti e metodi di valutazione possono tutti influenzare le prestazioni riportate.

I nuovi modelli tendono inoltre a ricevere test concentrati da parte degli appassionati. Le prime storie di successo possono sovrarappresentare carichi di lavoro che corrispondono ai punti di forza del modello, mentre i fallimenti ricevono una documentazione meno sistematica.

La domanda stessa introduce un’ulteriore incertezza. Moonshot ha temporaneamente sospeso i nuovi abbonamenti Kimi dopo che l’interesse ha superato la capacità disponibile, secondo un separato report sulla capacità.

Quella risposta sostiene l’affermazione che l’attenzione fosse insolitamente elevata. Rivela anche la sfida infrastrutturale che circonda un modello di queste dimensioni.

Un fornitore può rilasciare i pesi pur continuando a faticare nel garantire un accesso ospitato coerente. Gli operatori indipendenti affrontano vincoli simili quando cercano di servire il modello con una latenza utile.

L’architettura sparsa di Kimi K3 riduce il calcolo attivo, ma le prestazioni di serving dipendono da più del conteggio dei parametri attivi. Il routing degli esperti può creare esigenze di comunicazione tra acceleratori, specialmente quando un deployment distribuisce i pesi su molte macchine.

I contesti lunghi aggiungono un altro onere. Il sistema deve memorizzare e gestire le informazioni associate ai token precedenti mentre ne genera di nuovi.

Moonshot ha già esplorato il serving disaggregato, che separa le fasi dell’inferenza tra risorse diverse. La sua ricerca Mooncake descrive un’architettura incentrata sulla gestione della cache chiave-valore utilizzata durante l’inferenza a contesto lungo.

Quel lavoro fornisce un contesto tecnico pertinente, ma non significa che ogni deployment indipendente di Kimi K3 erediti l’efficienza di produzione di Moonshot. Gli operatori devono costruire o adottare il proprio stack di serving.

GLM-5.2 affronta una questione correlata. La capacità di un milione di token potrebbe richiedere una configurazione specifica del modello, anziché funzionare come percorso predefinito su ogni host.

Gli sviluppatori dovrebbero confermare le impostazioni di contesto, i limiti di output, i requisiti di memoria e le restrizioni specifiche del fornitore prima di confrontare i risultati. Il solo nome di un modello non garantisce un comportamento identico tra piattaforme.

Anche la sicurezza necessita di una valutazione equilibrata. Il deployment locale può ridurre l’esposizione a un’API esterna, ma trasferisce al cliente la responsabilità di patching, gestione degli accessi, logging e isolamento del modello.

I pesi aperti possono aiutare i ricercatori a esaminare il comportamento del modello. Non rivelano automaticamente la provenienza di ogni esempio di addestramento né eliminano la possibilità di output non sicuri.

Le questioni normative e geopolitiche aggiungono ulteriore incertezza per le imprese multinazionali. Le aziende potrebbero dover esaminare licenze software, governance dei dati, regole di esportazione, politiche di approvvigionamento e requisiti specifici del settore.

Tali verifiche dovrebbero concentrarsi su obblighi documentati, anziché su presupposti basati sulla nazionalità. Le domande rilevanti riguardano dove si muovono i dati, chi gestisce il servizio, cosa consente la licenza e come viene sottoposto ad audit il deployment.

Un altro rischio riguarda l’inseguimento dei benchmark. Se i team scelgono un modello perché primeggia in un singolo test pubblico, potrebbero trascurare i tassi di fallimento nel proprio lavoro ripetitivo e poco appariscente.

Un agente di assistenza clienti deve rispettare le policy con coerenza. Un agente di programmazione deve evitare di danneggiare file non correlati. Un modello di ricerca deve separare le evidenze da invenzioni plausibili.

Queste qualità contano spesso più della vittoria in un punteggio da titolo. Richiedono inoltre valutazioni condotte nel tempo, con più categorie di attività e standard chiari di revisione umana.

I rilasci di Kimi K3 e GLM-5.2 meritano attenzione perché rendono possibili tali test. Non meritano una fiducia incondizionata solo perché i loro pesi sono disponibili.

La conclusione più responsabile è condizionale. Entrambi i modelli dispongono di capacità sufficientemente documentate da giustificare una valutazione, mentre nessuno dei due possiede abbastanza evidenze indipendenti in produzione per risolvere il dibattito tra aperto e chiuso.

Cosa dovrebbero osservare i lettori di Google News

Tre segnali mostreranno se questi rilasci rappresentano una concorrenza duratura o un breve ciclo di benchmark.

Il primo segnale è l’evidenza di deployment indipendenti. Gli sviluppatori dovrebbero cercare test riproducibili che coprano agenti di programmazione, recupero di documenti lunghi, analisi multimodale e uso degli strumenti.

I report utili indicheranno la versione del modello, la configurazione di inferenza, il metodo di quantizzazione, i prompt, gli strumenti e i criteri di successo. Le classifiche prive di questi dettagli offrono meno valore decisionale.

I test di programmazione a livello di repository saranno particolarmente rivelatori. Una valutazione credibile dovrebbe misurare le attività completate, le regressioni introdotte, lo sforzo di revisione e il recupero da comandi non riusciti.

Se Kimi K3 e GLM-5.2 avranno prestazioni coerenti in queste configurazioni, si rafforzerà il caso delle alternative frontier a pesi aperti. Se i risultati varieranno nettamente in base all’host o alla configurazione, i sistemi chiusi gestiti manterranno un vantaggio significativo.

Il secondo segnale è l’accessibilità del deployment. Il rilascio dei pesi è solo l’inizio, perché poche organizzazioni possono gestire modelli di questa scala senza infrastrutture specializzate.

Occorre osservare framework di inferenza stabili, versioni quantizzate supportate, compatibilità più ampia con gli acceleratori e hosting affidabile da più fornitori. Questi sviluppi determinano se l’accesso aperto diventa accesso pratico.

Kimi K3 è un test insolitamente impegnativo. I suoi 2,8 trilioni di parametri totali creano requisiti sostanziali di archiviazione e distribuzione, anche se solo un sottoinsieme si attiva per ogni token.

Anche GLM-5.2 richiede un’infrastruttura seria, ma la sua impronta complessiva più ridotta potrebbe produrre un diverso percorso di adozione. Le organizzazioni potrebbero preferirlo per carichi di lavoro testuali e di programmazione se dimostrerà di essere più facile da gestire.

Un mercato di hosting diversificato rafforzerebbe il caso dei pesi aperti. La dipendenza da un unico endpoint ufficiale indebolirebbe l’affermazione che gli utenti abbiano acquisito una scelta infrastrutturale significativa.

Il terzo segnale è la risposta dei fornitori di modelli chiusi. OpenAI e Anthropic non devono rilasciare i pesi per rispondere alla sfida.

Possono rispondere con maggiore affidabilità, strumenti per agenti migliori, controlli enterprise più solidi, una migliore gestione del contesto e impegni più chiari sulla governance dei dati. Possono anche ridurre lo sforzo necessario per passare da un modello all’altro.

L’indicatore importante sarà se i servizi chiusi diventeranno più flessibili. Funzionalità come l’accesso a versioni fisse, opzioni di deployment privato, strumenti di valutazione più solidi e stato dei flussi di lavoro esportabile affronterebbero direttamente il divario di controllo.

Un’altra ondata di rilasci cinesi potrebbe intensificare la pressione. Alibaba e DeepSeek hanno già contribuito a consolidare la Cina come importante fonte di sviluppo di modelli aperti e a pesi aperti.

Anche la concorrenza tra i laboratori cinesi conta. Moonshot e Z.ai devono difendere i propri rilasci dai rivali nazionali, non solo da OpenAI e Anthropic.

Questa dinamica può accelerare la disponibilità dei modelli, ma può anche accorciare i cicli di prodotto. I team enterprise hanno bisogno di versioni stabili e supporto affidabile, non di una pressione costante a ricostruire attorno al checkpoint più recente.

L’attenzione di Google News passerà inevitabilmente a un altro modello. La domanda duratura è se gli sviluppatori continueranno a usare Kimi K3 e GLM-5.2 dopo che la copertura del lancio svanirà.

I soli conteggi dei download non risponderanno alla domanda. Un’adozione significativa emerge nelle integrazioni, nelle valutazioni ripetibili, negli strumenti di serving mantenuti e nei casi di studio in produzione con vincoli chiari.

Gli acquirenti dovrebbero resistere alla tentazione di assumere un ampio impegno di piattaforma sulla base dei risultati della settimana di lancio. Dovrebbero invece costruire un insieme di valutazione rappresentativo e confrontare i modelli all’interno del flusso di lavoro che conta.

Iniziate con un’attività delimitata. Registrate il contesto necessario, le chiamate agli strumenti, gli interventi umani, la latenza, le modalità di fallimento e la qualità dell’output finale. Poi ripetete l’attività abbastanza volte da far emergere l’incoerenza.

I team dovrebbero anche testare la portabilità. Prompt, sistemi di recupero e strumenti per agenti dovrebbero evitare una dipendenza non necessaria da comportamenti unici di un singolo modello.

Questa preparazione è utile indipendentemente da quale fornitore guiderà il prossimo benchmark. La concorrenza tra modelli si muove troppo rapidamente per fare supposizioni permanenti.

Kimi K3 e GLM-5.2 contano perché ampliano l’insieme delle scelte credibili. Espongono anche il lavoro necessario per trasformare l’accesso ai modelli in valore operativo.

I prossimi uno-tre mesi dovrebbero mostrare se gli operatori indipendenti possono servire questi modelli in modo affidabile, se gli sviluppatori riproducono i risultati da titolo e se i fornitori chiusi adeguano le loro condizioni enterprise.

Per i lettori che seguono google news, questo è il compito pratico: ignorare il punteggio più rumoroso, identificare il carico di lavoro di cui avete realmente bisogno e pretendere evidenze dall’ambiente in cui il modello verrà eseguito. La vostra prossima valutazione dell’AI misurerà il prestigio del modello oppure il controllo, l’affidabilità e la portabilità che la vostra organizzazione può verificare?