Scalare la classificazione dei documenti a oltre 100.000 etichette

In Databricks, migliaia di clienti creano carichi di lavoro di produzione che mappano testo libero in tassonomie normalizzate con oltre 100.000 etichette. Alcuni casi d'uso comuni includono:

• Collegamento di entità biomediche. Le note cliniche e gli articoli di ricerca menzionano malattie, farmaci e procedure che devono essere associati a un concetto nel Unified Medical Language System, un vocabolario con migliaia di identificatori di concetti biomedici.
• Normalizzazione dei fornitori. Per analizzare i modelli di spesa, le società finanziarie normalizzano stringhe di transazione grezze come "SBUX #4471 SEATTLE WA" rispetto a un set di oltre 100.000 commercianti.
• Normalizzazione delle aziende. Le imprese deduplicano i record dei clienti tra diversi sistemi interni confrontando le descrizioni delle aziende con un set di oltre 100.000 aziende.

Ciascuno di questi casi d'uso definisce un ampio set di etichette, chiamato anche tassonomia, e ogni input deve essere mappato su una o più delle sue etichette. In genere, i clienti valutano la loro soluzione di produzione in base a questi criteri:

1. Qualità: produrre classificazioni sufficientemente accurate da guidare le decisioni a valle.
2. Costo: mantenere basso il costo di classificazione per documento, specialmente su larga scala.
3. Throughput: elaborare flussi di lavoro di grandi dimensioni, spesso nell'ordine di centinaia di migliaia di documenti, entro tempi ragionevoli.

Soddisfare tutti e tre i requisiti rende difficile la classificazione di tassonomie di grandi dimensioni in produzione, e in Databricks diamo la priorità alla ricerca e alla creazione di soluzioni per risolverli.

Perché gli approcci esistenti non sono sufficienti

Storicamente, le organizzazioni hanno affrontato la classificazione di tassonomie di grandi dimensioni affidandosi a regole regex personalizzate, corrispondenza di parole chiave (keyword matching) e classificatori di machine learning supervisionati. Tuttavia, questi approcci presentano dei limiti sotto diversi aspetti:

Pattern matching fragile. Le regole regex e basate su parole chiave dipendono da corrispondenze esatte, quindi falliscono in presenza di formattazioni imprevedibili nei dati reali. Aziende come YipitData hanno dovuto aggiornare continuamente i propri pattern regex per gestire i casi limite e le modifiche alla tassonomia, difficili da gestire su una scala di migliaia di etichette.

Ground truth sparsa e asimmetrica. Le distribuzioni reali delle etichette sono a coda lunga: un piccolo numero di etichette copre la maggior parte dei documenti, mentre migliaia compaiono raramente. La maggior parte dei clienti non dispone di documenti di ground truth per ogni etichetta della propria tassonomia, il che rende difficili da addestrare i classificatori supervisionati. Un classificatore non può imparare a classificare etichette che non sono incluse nei dati di addestramento, e lo sbilanciamento delle classi fa sì che i classificatori sovrastimino le etichette comunemente rappresentate e sottostimino quelle rare.

Deriva della tassonomia (taxonomy drift). Le etichette e le loro descrizioni vengono costantemente aggiunte, rimosse e riscritte per tenere conto di nuovi casi d'uso aziendali e per migliorare la qualità della classificazione. A ogni nuova versione della tassonomia, i pattern regex devono essere aggiornati e i classificatori riaddestrati e distribuiti.

Di recente, abbiamo visto sempre più clienti utilizzare i modelli linguistici di grandi dimensioni (LLM) per la classificazione. Con gli LLM, i clienti non hanno più bisogno di addestrare modelli o gestire pattern regex fragili. Tuttavia, su una scala di centinaia di migliaia di etichette, gli LLM faticano a inserire e analizzare la tassonomia all'interno della loro finestra di contesto. Con migliaia di candidati in un singolo prompt, i modelli iniziano anche ad avere allucinazioni, restituendo etichette che non esistono affatto nella tassonomia. Inoltre, passare l'intera tassonomia per centinaia di migliaia di documenti a un modello di frontiera è costoso su larga scala, even when taking advantage of prompt caching.

Come affrontiamo la classificazione di un numero elevato di etichette

Valutiamo tre metodi diversi per trovare il miglior equilibrio tra costi e qualità per tassonomie di grandi dimensioni:

Metodo 1: Ricerca vettoriale

Il primo metodo che testiamo consiste nell'utilizzare la ricerca vettoriale per recuperare l'etichetta migliore dato l'input. Generiamo gli embedding per ogni etichetta, con la relativa descrizione se presente, e per il documento di input utilizzando il modello Qwen3-Embedding-8B, un modello di embedding open-weight tra i primi in classifica a luglio 2026. Successivamente, valutiamo la rilevanza di ciascuna etichetta rispetto al documento con un punteggio ibrido che pesa sia la somiglianza semantica che quella lessicale.

Il punteggio semantico viene determinato calcolando la somiglianza del coseno (cosine similarity) tra gli embedding del documento e dell'etichetta; una somiglianza del coseno più elevata significa che l'etichetta corrisponde strettamente al documento nel significato, anche se il testo non coincide esattamente. Il punteggio lessicale viene calcolato con l'algoritmo BM25, che pesa ogni termine condiviso in base alla sua frequenza inversa nei documenti (inverse document frequency) all'interno del set di etichette, in modo che un verbo generico come "use" che compare in migliaia di etichette riceva un peso basso, mentre un token raro come "ETL" riceva un peso elevato.

Ciascun metodo di ricerca restituisce la propria lista ordinata di etichette. Uniamo le due liste con la Reciprocal Rank Fusion, che assegna un punteggio a ciascuna etichetta in base alla sua posizione in ogni lista. Selezioniamo le prime k, facendo variare k tra 1, 5, 10, 20, 50, 100 e 200 per trovare il valore con la migliore accuratezza media e utilizziamo l'etichetta con il punteggio più alto come previsione.

Su una scala di centinaia di migliaia di etichette, generare l'embedding della tassonomia una sola volta e creare un indice in memoria è più conveniente rispetto alla creazione di un indice di ricerca vettoriale ospitato (hosted). L'embedding di 100.000 etichette utilizza circa 1,6 GB di spazio di archiviazione, ipotizzando embedding float32 a 4096 dimensioni di Qwen3-8B, e richiede circa 1-3 minuti utilizzando la funzione AI Query di Databricks. All'inizio di un carico di lavoro, creiamo un'istanza di ricerca vettoriale in memoria, inseriamo gli embedding persistenti e utilizziamo l'indice per tutti i documenti per l'intera durata del carico di lavoro. È possibile trovare un codice di esempio per la nostra implementazione della ricerca vettoriale in questo notebook tutorial.

Metodo 2: Ricerca vettoriale + AI Classify

Il secondo metodo che testiamo è un flusso di lavoro in due passaggi che combina l'approccio di ricerca vettoriale e la funzione AI Classify di Databricks. AI Classify è una funzione Databricks AI che accetta un documento e una mappa di etichette con descrizioni e restituisce l'etichetta o il set di etichette che corrisponde meglio. La funzione AI Classify utilizza una combinazione di tecniche per gestire documenti e tassonomie di grandi dimensioni mantenendo al contempo la qualità della classificazione.

La funzione AI Classify può essere eseguita con SQL come segue:

Creiamo un flusso di lavoro in due passaggi utilizzando lo stesso recupero tramite ricerca vettoriale descritto nel metodo 1 per selezionare le k etichette più simili per documento, quindi passiamo solo questa selezione ad AI Classify. Ottimizziamo k impostandolo sul valore più piccolo oltre il quale l'accuratezza smette di migliorare e consideriamo il risultato di AI Classify come previsione.

Metodo 3: Chiamata diretta al modello di frontiera

L'ultimo metodo che testiamo chiama direttamente un LLM di frontiera con il documento di input e l'elenco delle etichette, incluse le descrizioni ove presenti, quindi richiede al modello di restituire l'etichetta corretta. I modelli testati sono GPT-5.6 Luna, GPT-5.4 mini, Gemini 3.5 Flash e Claude Sonnet 5, ovvero i modelli più recenti alla portata dei tipici budget di classificazione in produzione dei nostri clienti. I modelli di punta come Claude Opus 4.8, Claude Fable 5 e GPT-5.6 Sol costano da tre a dieci volte di più per token e sono in genere fuori budget per i clienti che eseguono flussi di lavoro di classificazione con migliaia di documenti al giorno.

Quando la tassonomia supera la lunghezza del contesto di un modello, ritagliamo l'elenco delle etichette per adattarlo alla finestra di contesto. Passiamo la tassonomia in modo coerente tra le chiamate per ciascun documento per sfruttare il caching dei prompt.

Come effettuiamo la valutazione

Valutiamo le prestazioni di ciascun metodo su tre dataset che coprono i casi d'uso più comuni dei clienti menzionati sopra. Vengono generati gli embedding delle etichette con le relative descrizioni, se non diversamente specificato:

• Transazioni (100.000 etichette, 200 documenti di valutazione): stringhe di transazione generate sinteticamente in base a 100.000 nomi delle principali aziende di Crunchbase.
• Aziende (100.000 etichette, 200 documenti di valutazione): descrizioni aziendali mappate sullo stesso catalogo di nomi di aziende di Crunchbase delle Transazioni. Le etichette sono costituite solo da nomi.
• MedMentions (35.000 etichette, 200 documenti di valutazione): collegamento di menzioni biomediche agli identificatori di concetti dello Unified Medical Language System dal corpus MedMentions.

Ogni dataset viene valutato in base all'accuratezza: la frazione di documenti la cui etichetta prevista corrisponde alla ground truth. Abilitiamo l'opzione di caching dei prompt del fornitore del modello per tutte le chiamate dirette ai modelli di frontiera.

Risultati

Tracciamo l'accuratezza rispetto al costo per documento, calcolato come media sui tre dataset, per ciascun approccio. Il costo include l'embedding dei documenti e i token LLM con l'applicazione degli sconti per il caching dei prompt del fornitore. Escludiamo l'embedding della tassonomia, un costo una tantum che non varia con le dimensioni del carico di lavoro (vedere le stime di archiviazione per la nostra configurazione di ricerca vettoriale alla sezione "Come affrontiamo la classificazione di etichette di grandi dimensioni").

Su tutti i dataset, l'AI Classify Workflow ottiene un punteggio superiore a qualsiasi modello di frontiera diretto, con un'accuratezza media di 0,81 rispetto a 0,76 dell'opzione successiva migliore, Gemini 3.5 Flash, a un centesimo del costo per documento. La qualità dell'AI Classify Workflow, in media, è ottimale quando selezioniamo le prime venti etichette dalla ricerca vettoriale da passare alla funzione AI Classify.

La sola ricerca vettoriale è quasi cento volte più economica rispetto all'AI Classify Workflow, poiché è necessario solo l'embedding del documento e il costo della CPU per il ranking è trascurabile. Tuttavia, anche dopo aver ottimizzato k, ottiene un punteggio inferiore di oltre venti punti rispetto all'AI Classify Workflow.

Per le tassonomie più grandi, la chiamata diretta al modello di frontiera non consente di inserire l'intero set di etichette nella finestra di contesto del modello. Su MedMentions, solo GPT-5.6 Luna conteneva l'intera tassonomia all'interno del suo contesto da 1 milione di token; dopo la tokenizzazione, nessun altro modello è stato in grado di inserire il set di etichette entro il proprio limite. A questo punto, i team possono scegliere di valutare strategie batch, multi-step e agentiche per gestire il contesto, funzionalità che il nostro team ha sviluppato e continua a perfezionare nella funzione AI Classify.

Conclusione

Su tre benchmark che spaziano da 35.000 a 100.000 etichette, il workflow AI Classify che combina la ricerca vettoriale e la funzione Databricks AI Classify ha offerto il miglior equilibrio tra costi e qualità. Supera di cinque punti il modello di frontiera diretto più forte, Gemini 3.5 Flash, a circa un centesimo del costo per documento. Quando la tassonomia cambia, le etichette ritirate possono essere rimosse e le nuove etichette possono essere sottoposte a embedding e inserite all'inizio del workflow, senza necessità di riaddestramento o ridistribuzione.

Per i team che si trovano ad affrontare la classificazione su questa scala, la creazione di un workflow con AI Classify e la ricerca vettoriale è un ottimo punto di partenza. Questo tutorial passo-passo illustra l'intero workflow su Databricks, dall'embedding del set di etichette alla selezione di K.

Prova l'AI Classify Workflow

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale