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à costruitoLa parte di misurazione e operazione è costruita ed eseguita, con risultati conservati: un banco di prova proprio che ha confrontato otto sistemi di riconoscimento vocale sugli stessi 200 enunciati rumeni, con intervallo di confidenza e differenze a coppie, più una scomposizione della latenza vocale in sei segmenti che si sommano al totale con scarto inferiore a un millisecondo. La parte operativa è un gateway proprio con 44 modelli configurati, chiavi per progetto con allowlist di modelli e budget, e una consolidazione giornaliera del consumo per utente × chiave × modello. La parte che NON abbiamo fatto — il fine-tuning vero e proprio — è scritta come tale: la pipeline è pronta e preventivata, ma non è mai stata eseguita su GPU. Il servizio resta “consegnato” perché il lavoro che vendiamo è la scelta informata e l’operatività, non l’addestramento.
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.