Vai al contenuto
megapromotingParliamone

Competenza · Modelli AI personalizzati

Scegliamo il modello in base alla misurazione, non alla reputazione — e diciamo fin dall’inizio quando la risposta corretta è non addestrare nulla.

Il lavoro ha quattro parti: misuriamo i modelli candidati sui vostri dati, scegliamo tra configurazione, ricerca nei documenti e fine-tuning, verifichiamo i diritti di utilizzo dei dati, poi manteniamo il consumo entro il budget per chiave. Non abbiamo ancora addestrato alcun modello in produzione e lo diciamo prima che lo chiediate.

Già costruitoPartea de măsurare și operare este construită și rulată, cu rezultate păstrate: un banc de probă propriu care a comparat opt sisteme de recunoaștere a vorbirii pe aceleași 200 de enunțuri românești, cu interval de încredere și diferențe pe perechi, plus o descompunere a latenței vocale în șase segmente care se însumează la total cu abatere sub o milisecundă. Partea de operare este un gateway propriu cu 44 de modele configurate, chei per proiect cu listă albă de modele și buget, și o consolidare zilnică a consumului pe utilizator × cheie × model. Partea pe care NU am făcut-o — reglajul fin propriu-zis — e scrisă ca atare: conducta e pregătită și costată, dar nu a rulat niciodată pe GPU. Serviciul rămâne „livrat” pentru că lucrarea pe care o vindem este alegerea informată și operarea, nu antrenarea.

La maggior parte dei progetti di «modello personalizzato» non ha bisogno di un modello addestrato. Ha bisogno del modello giusto, con l’istruzione giusta, sui dati giusti, con un costo per chiamata che qualcuno monitora. Il lavoro inizia con la domanda che pochi fanno: come appare il successo, misurato come, su quale insieme di casi? Senza questa risposta, qualsiasi confronto tra modelli è una discussione di gusti.

Misuriamo noi, non prendiamo le cifre dei fornitori. Quando abbiamo avuto bisogno di sapere cosa riconosce meglio il romeno parlato, abbiamo eseguito otto sistemi sugli stessi 200 enunciati, con lo stesso normalizzatore, con intervallo di confidenza tramite bootstrap e con differenze calcolate a coppie. I risultati sono stati scomodi: il sistema che usavamo in produzione aveva un tasso di errore per parola del 26,26%, mentre un modello piccolo, da 110 milioni di parametri, eseguito su processore, aveva il 6,83%. Abbiamo pubblicato anche la parte spiacevole — sull’accuratezza in romeno perdiamo in modo significativo rispetto ai fornitori commerciali.

La seconda parte del lavoro è la scelta tra tre strade che si confondono spesso: configurazione del modello (istruzione, strumenti, parametri), ricerca nei tuoi documenti e fine-tuning. L’ordine in cui le proviamo non è una preferenza, è economia: le prime due sono reversibili in un pomeriggio, la terza richiede dati, diritti, GPU e una misurazione prima e dopo. Raccomandiamo il fine-tuning solo quando abbiamo la prova che le prime due non bastano.

La terza parte, quella che resta dopo il lancio: il costo per chiamata. I modelli passano attraverso un gateway proprietario, dove ogni chiave ha lista bianca di modelli, budget e periodo. Il consumo viene consolidato giornalmente per utente, chiave e modello, il che significa che la domanda «perché è aumentata la fattura questo mese» ha una risposta riga per riga, non per supposizioni.

Cosa comprende

Il lavoro, per componenti

Definiamo cosa significa «migliore», prima di confrontare qualcosa

Un insieme di casi della tua realtà, un criterio numerico e un metodo di normalizzazione fissati per iscritto. Per il parlato usiamo il tasso di errore per parola con normalizzatore proprietario; per le risposte testuali, la conformità allo schema più un controllo di buon senso più la somiglianza con una risposta di riferimento. Senza questo passaggio, il resto del lavoro non può essere verificato da nessuno.

Eseguiamo il confronto su dati identici, con intervallo di confidenza

Gli stessi enunciati, la stessa macchina, un solo modello caricato alla volta, ciascuno nel proprio processo. Riportiamo intervallo di confidenza tramite bootstrap e differenze a coppie, non solo la media — perché due modelli possono avere medie diverse e tuttavia essere statisticamente alla pari. Abbiamo avuto esattamente questo caso: due sistemi a 66 su 66 confronti a coppie, cioè pareggio, anche se la tabella delle medie suggeriva un vincitore.

Scomponiamo la latenza in segmenti che si sommano

In un percorso vocale abbiamo misurato separatamente sei segmenti — la decisione di turno, il riconoscimento vocale, il gate, il tempo fino al primo testo del modello, il primo blocco di sintesi, la coda e il trasporto. La verifica che conta: la somma dei sei dà il tempo totale fino al primo suono con uno scarto inferiore a un millisecondo per ogni turno valido. Da lì si vede dove sta il problema: nel caso misurato, il 68,7% del tempo era l’attesa del primo testo del modello, non il riconoscimento vocale, che impiegava il 2,9%.

Scegliamo tra configurazione, ricerca nei documenti e fine-tuning

La ricerca nei documenti è implementata e in esecuzione: ricerca ibrida, 70% semantica e 30% corrispondenza di parole, soglia di somiglianza 0,70, cinque frammenti per domanda, con log per interrogazione che conserva punteggi e tempi. Proponiamo il fine-tuning solo con la prova che le prime due non bastano — e con il budget e i diritti sul tavolo prima, non dopo.

Verifichiamo i diritti di utilizzo dei dati prima di qualsiasi addestramento

Non è una formalità, è ciò che blocca i progetti. Un corpus di 1.746 ore di romeno che avevamo preso in considerazione si è rivelato con licenza non commerciale — quindi inutilizzabile per un modello commerciale. Un set di 270.946 esempi aveva il codice sotto licenza permissiva, ma i dati senza alcuna licenza dichiarata. Inoltre, la politica di utilizzo di un fornitore vocale vieta esplicitamente l’addestramento di un modello sul suo output. Ogni fonte si verifica sulla propria pagina, non su ciò che è scritto in un articolo.

Mettiamo il consumo sotto budget per chiave, non per fattura

Gateway proprietario con 44 modelli configurati, ciascuno con costo per token e limite di contesto nella configurazione. La chiave di progetto ha una lista bianca di modelli, budget e periodo, e può essere ruotata mantenendo la cronologia. Il consumo viene consolidato giornalmente per utente × chiave × modello. Il routing usa la strategia «il meno occupato», due retry e un tempo massimo di 120 secondi.

Teniamo conto dei token che il fornitore fattura, ma il gateway non li vede

I modelli di tipo ragionamento producono passi interni che la piattaforma di monitoraggio dei costi non vede, ma che il fornitore fattura. La conseguenza pratica: il budget lordo impostato sulla chiave deve essere inferiore al tetto desiderato, diviso per un fattore di ragionamento. Se non si fa questa correzione, la chiave sembra nel budget e la fattura no.

Eseguiamo modelli in locale quando i dati non possono uscire

Abbiamo una catena locale funzionante: riconoscimento del parlato con un modello da 0,6 miliardi di parametri su processore e sintesi vocale con un modello da 99 milioni di parametri, sempre in locale. In un prodotto di monitoraggio radio, la trascrizione avviene in locale, mentre la variante tramite gateway esiste in parallelo — quindi il confronto tra locale e ospitato è stato fatto, non supposto. Ciò che esce dalla macchina è testo, non audio.

Monitoriamo la deriva dopo il lancio

Un banco di regressione settimanale su casi fissi, che confronta la conformità con lo schema, supera un test di buon senso e misura la somiglianza con le risposte di riferimento. Un modello che cambia sotto di voi — e cambia — si vede nel grafico, non nei reclami dei clienti.

Come si presenta

Il percorso, passo dopo passo.

01

Scriviamo il criterio e costruiamo il set di casi

I casi derivano dalla vostra realtà, non da un set di test generale. Si fissano il criterio numerico, il metodo di normalizzazione e la soglia da cui il risultato è accettabile. Forniamo: il set di casi, il criterio scritto e lo script che lo calcola.

02

Eseguiamo il confronto e pubblichiamo anche i risultati che ci contraddicono

I modelli candidati vengono eseguiti su dati identici, con intervallo di confidenza. Forniamo: la tabella con tutti i sistemi testati, inclusi quelli respinti e il motivo, più il comando esatto di riproduzione. Un modello che abbiamo respinto per il romeno aveva un tasso di errore del 99,69% perché scivolava in italiano — il romeno non era tra le sue lingue dichiarate. Quel risultato è nella tabella.

03

Scegliamo il percorso e lo motiviamo per iscritto

Configurazione, ricerca nei documenti o fine tuning — con il motivo, il costo e ciò che si perde scegliendo. Forniamo: la decisione motivata, più la misurazione che la supporta. Se la raccomandazione è «non addestriamo nulla», lo scriviamo con la stessa chiarezza.

04

Mettiamo in funzione con chiave, budget e lista bianca di modelli

La chiave del progetto viene emessa con budget, periodo e lista di modelli consentiti, con la correzione per i token di ragionamento applicata. Forniamo: la chiave, il pannello di consumo e la soglia da cui qualcuno riceve un avviso.

05

Misuriamo di nuovo dopo il lancio

Stessi casi, stesso criterio, sul modello in produzione. Forniamo: il confronto prima/dopo e l’elenco delle modifiche con il motivo di ciascuna. Un banco di regressione ricorrente intercetta i cambiamenti nel comportamento del modello del fornitore.

Traseul unei alegeri de model1criteriu scris și setde cazuri2comparație pe dateidentice, cu intervalde încredere3decizia întreconfigurare, căutareîn documente șireglaj fin4punere în funcțiunecu cheie, buget șilistă albă5remăsurare periodică
Traseul unei alegeri de model

I dati

Cosa tocchiamo, dove risiedono e quanto rimangono

Le domande che pone chiunque abbia un responsabile della protezione dei dati — poste qui prima che le ponga lui.

Quali dati tocchiamo e dove si trovano
Il set di valutazione resta vostro e si conserva separatamente dal set usato per istruzioni o esempi. Quando la valutazione può essere fatta su dati pubblici — il caso del nostro benchmark per il romeno — la facciamo lì e non tocchiamo affatto i dati del cliente.
La separazione dei set, affinché la misurazione significhi qualcosa
Il set su cui regoliamo e il set su cui misuriamo non si toccano. Se un esempio è stato usato per scrivere l’istruzione, non ha più il diritto di essere nel set di valutazione. È l’unica regola che fa la differenza tra un numero e un numero che significa qualcosa.
Provenienza e licenza di ogni fonte
Per qualsiasi dato di addestramento si annotano la fonte, l’ora del materiale, la licenza esatta e la pagina da cui è stato letto. Segnaliamo distintamente ciò che abbiamo misurato noi e ciò che abbiamo stimato, con la base del calcolo scritta accanto. Questa convenzione ha già intercettato tre errori di licenza che sarebbero finiti in un progetto.
Il registro delle interrogazioni
Per la ricerca nei documenti si conservano, per ogni interrogazione, i frammenti restituiti, i loro punteggi e i tempi — di ricerca e totali. Senza questo registro, «perché ha risposto così» non ha risposta. Con esso, la regolazione si fa sui dati.
Consumul
Una riga al giorno per ogni combinazione utente × chiave × modello, più lo stato della chiave: budget massimo, speso in 24 ore, 7, 14 e 30 giorni, percentuale utilizzata, numero di richieste e l’elenco dei modelli effettivamente toccati.

Un caso

Un banco di prova che ha contraddetto la scelta in produzione

La situazione

Avevamo un sistema di riconoscimento vocale operativo per il romeno e una domanda aperta: è il migliore disponibile o solo il primo che abbiamo integrato? Non esisteva alcuna misurazione propria, solo cifre pubblicate dai fornitori, misurate su altre lingue e altri set.

Cosa abbiamo costruito

Abbiamo costruito un banco: 200 enunciati romeni da un set pubblico, lo stesso seme per la selezione, 35,1 minuti di audio, lo stesso normalizzatore per tutti i sistemi, intervallo di confidenza tramite bootstrap, differenze calcolate a coppie. Otto sistemi, ciascuno caricato singolarmente, in un processo proprio, sulla stessa macchina. Abbiamo scritto nel rapporto sia la configurazione della macchina sia il comando esatto di riproduzione.

Cosa è emerso

Il sistema in produzione aveva un tasso di errore per parola del 26,26%. Un modello da 110 milioni di parametri, eseguito su processore con un modello linguistico accanto, aveva il 6,83%. Un modello molto lodato è arrivato al 99,69%, perché scivolava nell’italiano — il romeno non era tra le sue lingue dichiarate. E due sistemi che sembravano diversi per media sono risultati statisticamente alla pari nel confronto a coppie. Abbiamo pubblicato tutta la tabella, inclusa la riga che contraddiceva la nostra scelta.

Cosa non dice il caso

La misurazione è stata fatta su un set pubblico di lettura, non su conversazioni telefoniche reali, con rumore e sovrapposizioni. Un buon risultato su questo set non garantisce lo stesso risultato al telefono. Per questo, per un cliente, il banco si ricostruisce sulle sue registrazioni — altrimenti misuriamo qualcosa di diverso da ciò che gli interessa.

Domande

Cosa ci chiedono le persone prima di chiamare

Avete mai addestrato un vostro modello?

No. Nessun modello da noi regolato finemente o addestrato è in produzione e non esiste alcun checkpoint salvato nei nostri repository. Quello che abbiamo: la pipeline di addestramento scritta fino al comando esatto di avvio della macchina GPU, il budget calcolato su tre scenari, i dati preparati e le licenze verificate — e un elenco scritto di ciò che va deciso prima della prima esecuzione. Preferiamo dirlo piuttosto che vendere una competenza che non abbiamo esercitato.

Allora perché chiedereste a qualcuno denaro per «modelli personalizzati»?

Perché il lavoro che porta il risultato nella maggior parte dei casi non è l'addestramento. È sapere quale modello fa il lavoro sui vostri dati, con quale latenza e a quale costo per chiamata — e questo richiede una misurazione che quasi nessuno fa. Un esempio dal nostro lavoro: un solo valore predefinito errato in una configurazione del modello (una penalizzazione della ripetizione impostata a 1,2 invece di 1,0) è costato 4,3 punti percentuali di errore. Non è stato necessario addestrare, ma misurare.

Fine-tuning o ricerca nei documenti?

Si comincia quasi sempre con la ricerca nei documenti. È reversibile, si aggiorna cambiando un file e può mostrare la fonte della risposta. Il fine-tuning cambia il comportamento del modello in modi che non si possono ispezionare, richiede dati etichettati, diritti d'uso e una misurazione prima e dopo. Raccomandiamo il fine-tuning quando abbiamo la prova che la prima variante non basta — ad esempio, quando abbiamo mostrato che un modello offline non diventa un modello in flusso solo tramite configurazione: restringendo la finestra di attenzione senza riaddestramento, l'errore è aumentato dall'8,81% al 22,26% e poi al 48,95%.

Mi garantite una certa accuratezza?

No, e nessun fornitore onesto può farlo, perché l'accuratezza dipende dai vostri dati. Quello che garantiamo è il metodo: misuriamo sui vostri casi, mostriamo l'intervallo di confidenza e diciamo quando la differenza tra due opzioni non è statisticamente significativa. Abbiamo avuto un caso in cui un risultato pubblicato dagli autori di un modello non si è riprodotto da noi — loro riportavano 20,70%, noi abbiamo misurato 26,68% sullo stesso modello. Abbiamo scritto che non sappiamo perché, invece di scegliere la cifra conveniente.

I miei dati arrivano ai fornitori di modelli?

Dipende dal percorso scelto ed è una decisione, non un incidente. Tramite gateway, la richiesta arriva al fornitore del modello. Se ciò non è accettabile, abbiamo funzionale la catena locale: riconoscimento vocale e sintesi vocale eseguiti sulla vostra macchina, dove dalla macchina parte solo testo, mai audio. In un prodotto di monitoraggio radio, la trascrizione locale e quella tramite gateway sono entrambe implementate, quindi il compromesso tra le due lo possiamo mostrare con i numeri.

Cosa succede se il fornitore cambia il modello sotto di noi?

Succede. Per questo il lavoro include un banco di regressione su casi fissi, eseguito periodicamente, che confronta la conformità allo schema, supera un test di buon senso e misura la somiglianza con le risposte di riferimento. E per questo l'integrazione passa tramite gateway: il modello si cambia da un campo, non riscrivendo il codice.

Come controllo il costo, concretamente?

La chiave del progetto ha una lista bianca di modelli, budget e periodo, e si può ruotare mantenendo la cronologia. Il consumo si consolida quotidianamente per utente, chiave e modello. Una trappola che correggiamo fin dall'inizio: i modelli di ragionamento producono passaggi interni che il sistema di tracciamento non vede, ma che il fornitore fattura — quindi il budget lordo sulla chiave si imposta più basso del tetto desiderato, diviso per un fattore di ragionamento. Chi non fa la correzione vede la chiave nel budget e la fattura oltre.

Perché conta la licenza dei dati, se sono comunque pubblici?

Perché «pubblico» e «utilizzabile commercialmente» sono cose diverse, e la differenza si scopre tardi e a caro prezzo. Tre esempi dalle nostre verifiche: un grande corpus di romeno, con licenza non commerciale, quindi escluso per un prodotto commerciale; un insieme di centinaia di migliaia di esempi di codice sotto licenza permissiva ma con dati senza alcuna licenza dichiarata; e la policy di utilizzo di un fornitore di voce, che vieta esplicitamente l'addestramento di un modello sul suo output. La verifica si fa sulla pagina della fonte, non su ciò che ripete un articolo.

Cosa non fa questo servizio?

Non addestra oggi modelli fondamentali e non promette un modello proprio in produzione. Non garantisce percentuali di miglioramento. Non confronta un modello con la concorrenza sulla base delle cifre pubblicate dalla concorrenza — se non abbiamo eseguito noi il confronto, diciamo che è una cifra dichiarata da loro, non una misurata da noi.

Su cosa si basano le affermazioni sopra (26 fonti)

26 di esse sono codice e file dei nostri repository. Non ne pubblichiamo il nome né la riga: insieme, in un'unica pagina, descriverebbero con troppa precisione come sono costruiti sistemi che non sono solo nostri. Le esaminiamo con te, nel repository, su richiesta — la verifica resta possibile, solo che avviene in una discussione.

Cosa vorresti che funzionasse meglio?

Raccontaci il tuo processo. Insieme stabiliamo cosa vale la pena costruire, cosa possiamo collegare e come verifichiamo il risultato.

Parliamone