Creare un modello di embedding specifico per dominio in meno di un giorno

Se state costruendo un sistema RAG (Retrieval-Augmented Generation), probabilmente avete incontrato questo ostacolo: tutto funziona... finché non lo fa più. I modelli di embedding per scopi generali sono addestrati per comprendere internet; non i vostri contratti, i registri di produzione, le formulazioni chimiche proprietarie o la tassonomia interna. Catturano una vasta similarità semantica, ma non comprendono le distinzioni a grana fine che contano nel vostro dominio. La messa a punto (fine-tuning) di un modello di embedding può migliorare le prestazioni della vostra pipeline di recupero quando i modelli pronti all'uso non riescono a catturare efficacemente le sfumature specifiche del dominio.

Nonostante l'importanza critica degli embedding per le prestazioni RAG, il processo rimane sorprendentemente frammentato, le competenze richieste sono specializzate e l'investimento di tempo è scoraggiante. Con una singola GPU e meno di un giorno di tempo di addestramento, potete trasformare un modello di embedding per scopi generali in uno che comprende veramente il vostro dominio, senza alcuna etichettatura manuale. Per aiutarvi a partire subito, stiamo anche rilasciando un dataset di addestramento sintetico pronto all'uso, generato dalla documentazione pubblica di NVIDIA utilizzando esattamente questa pipeline. Utilizzando questi dati e la "ricetta" descritta, abbiamo riscontrato un miglioramento di oltre il 10% sia in Recall@10 che in NDCG@10. Atlassian ha applicato questa ricetta per la messa a punto sul loro dataset JIRA, aumentando il Recall@60 da 0,751 a 0,951, un miglioramento del 26% — il tutto su una singola GPU.

Entro la fine di questo articolo, saprete come:

• 📄 Generare dati di addestramento da documenti di dominio senza dati etichettati
• 🎯 Usare l'estrazione di negativi difficili (hard negative mining) per un addestramento contrastivo efficace
• 🔗 Migliorare la qualità degli embedding con query multi-salto (multi-hop queries)
• ⚙️ Effettuare il fine-tuning di un modello di embedding bi-encoder
• 📊 Valutare se il fine-tuning migliora il recupero
• 🚀 Distribuire il modello ottimizzato nella vostra pipeline

Preparazione: il modello di base e la configurazione iniziale

In questo tutorial, ottimizzeremo il modello base Llama-Nemotron-Embed-1B-v2 — un modello di embedding da 1 miliardo di parametri che bilancia qualità e costo di inferenza. Per iniziare, seguite questa guida di configurazione.

Generazione di dati di addestramento sintetici: la chiave senza etichette

La messa a punto di un modello di embedding richiede migliaia di coppie (query, documento rilevante). La maggior parte dei casi d'uso non dispone di questi dati prontamente disponibili. Crearli manualmente è costoso, lento e spesso distorto dall'interpretazione personale dell'annotatore su cosa sia "rilevante". Invece di etichettare i dati a mano, potete usare un LLM (specificamente, nvidia/nemotron-3-nano-30b-a3b) per leggere i vostri documenti e generare automaticamente coppie domanda-risposta sintetiche di alta qualità.

Dietro le quinte, questo processo esegue una pipeline di generazione di dati sintetici (SDG) a quattro stadi, alimentata da NeMo Data Designer:

Considerate il seguente esempio di testo:

Il thermal design power (TDP) della GPU H100 è di 700W nel fattore di forma SXM. La soluzione di raffreddamento deve mantenere la temperatura di giunzione al di sotto di 83°C sotto carichi sostenuti. Il raffreddamento a liquido è raccomandato per implementazioni dense che superano 4 GPU per nodo, poiché il raffreddamento ad aria non può dissipare calore sufficiente nelle configurazioni chassis 2U standard.

La pipeline genera sia domande fattuali semplici che domande che richiedono ragionamento multi-salto e causale. Ad esempio:

• Domanda Fattuale: Qual è il TDP della GPU H100 nel fattore di forma SXM?
• Domanda Multi-Salto: In che modo il TDP della GPU H100 influisce sulle raccomandazioni per il raffreddamento in implementazioni dense?

Notate la differenza: la prima domanda è una semplice ricerca di fatti. La seconda richiede un ragionamento multi-salto e causale. La pipeline genera entrambi i tipi, con livelli di complessità configurabili (da 2 a 5) e conteggi di salti (da 1 a 3). Ogni coppia QA viene quindi sottoposta a valutazione della qualità, ricevendo punteggi parziali per rilevanza, accuratezza, supporto al contesto e chiarezza, insieme a un punteggio complessivo. Solo le coppie che soddisfano la soglia vengono incluse nell'addestramento.

Estrazione di negativi difficili: insegnare le sottili distinzioni

Se addestrate un modello di embedding solo con coppie positive (query + documento corretto), esso impara a distinguere documenti ovviamente diversi ma fallisce sui casi difficili — passaggi che sembrano rilevanti ma non sono la risposta giusta. In un sistema di recupero reale, questi "quasi-mancati" sono esattamente i documenti che causano risposte errate. L'estrazione di negativi difficili (hard negative mining) trova questi passaggi confusi in modo che il modello possa imparare a distinguerli.

Il comando per l'estrazione di negativi difficili esegue automaticamente tre sotto-passaggi:

• Calcola gli embedding per tutti i passaggi nel corpus.
• Identifica i K passaggi non positivi più simili per ogni query.
• Filtra i passaggi che sono troppo vicini al positivo (utilizzando un margine del 95%).

I negativi difficili sono i passaggi non positivi più simili che rientrano comunque in modo sicuro al di sotto del "soffitto" del punteggio positivo. Sono passaggi che il modello attuale considera altamente rilevanti ma che non sono la risposta etichettata.

Perché questo funziona: l'addestramento su negativi facili (passaggi completamente non correlati) non insegna nulla di nuovo al modello. L'addestramento su negativi difficili lo costringe a imparare le sottili distinzioni che contano nel vostro dominio. Ad esempio, in un corpus medico, una domanda sul "dosaggio di metformina per il diabete di tipo 2" potrebbe avere negativi difficili su "effetti collaterali della metformina" o "dosaggio di insulina per il diabete di tipo 1" — simili ma criticamente diversi. Il margine del 95% impedisce all'estrattore di selezionare passaggi troppo vicini al positivo, che potrebbero essere risposte corrette che semplicemente non sono state etichettate durante la generazione di dati sintetici (SDG).

Le coppie QA generate vengono divise in set di addestramento (80%) e test (20%). Il set di test è formattato come un benchmark compatibile con BEIR per una valutazione standardizzata nella Fase 5.

Migliorare la qualità degli embedding con le query multi-salto

Le domande multi-salto fanno riferimento a più documenti positivi. Ad esempio, una domanda come "Come si collega il sistema di gestione termica nella Sezione 3.2 ai vincoli di potenza descritti nella Sezione 5.1?" ha due passaggi positivi.

L'“unrolling” (srotolamento) crea un esempio di addestramento per ogni coppia (query, documento positivo), in modo che la funzione di costo contrastiva veda ogni positivo indipendentemente. Una domanda con 2 documenti positivi diventa 2 esempi di addestramento, ciascuno con gli stessi negativi difficili ma un positivo diverso.

La messa a punto standard degli embedding genera una domanda per passaggio e addestra il modello a farli corrispondere. Questo funziona per semplici ricerche fattuali, ma gli utenti reali pongono domande complesse che si estendono su più documenti o sezioni. Se il modello ha visto solo dati di addestramento a singolo salto, farà fatica a recuperare tutti i passaggi rilevanti per queste query complesse.

La pipeline SDG genera domande da 1 a 3 salti per impostazione predefinita:

• 1-hop: domande che possono essere risolte con un singolo passaggio.
• 2-hop: domande che richiedono l'integrazione di informazioni da due passaggi.
• 3-hop: domande che richiedono l'integrazione di informazioni da tre o più passaggi.

Ogni salto è tracciato con il proprio riepilogo di contesto e ID di segmento, in modo che i dati di addestramento preservino l'intera catena di ragionamento. Dopo l'unrolling (Fase 2c), ogni coppia (domanda, passaggio rilevante) diventa un segnale di addestramento indipendente, insegnando al modello che tutti questi passaggi sono rilevanti per la query multi-salto.

Il modello ottimizzato impara a recuperare documenti contestualmente correlati, non solo quelli lessicalmente simili.

Messa a punto del modello di embedding bi-encoder

L'addestramento utilizza un'architettura bi-encoder con funzione di costo contrastiva. La temperatura di 0,02 è volutamente aggressiva; produce una distribuzione di probabilità molto netta. Questo funziona bene perché i negativi difficili dalla Fase 2 sono di alta qualità: sono passaggi realmente confusi che il modello necessita di forti gradienti per imparare a distinguere.

Se ckpt_every_steps viene omesso dalla configurazione, la frequenza di checkpoint viene impostata automaticamente:

• Per corpus di dimensioni ridotte (50-100 documenti), i checkpoint possono essere molto frequenti.
• Per corpus di dimensioni maggiori (migliaia di documenti), la frequenza si riduce per bilanciare il tempo di addestramento e la granularità del checkpoint.

Questo significa che potete iniziare con un corpus piccolo (50-100 documenti) per una rapida prova di concetto e scalare successivamente senza dover regolare manualmente le impostazioni dei checkpoint.

Valutazione delle prestazioni: misurare il successo

Il fine-tuning ha effettivamente aiutato? Scopriamolo eseguendo una valutazione standardizzata che confronta il modello di base con il checkpoint ottimizzato sul set di test riservato:

(comando di valutazione)

La valutazione utilizza il framework BEIR e calcola quattro metriche standard di recupero delle informazioni a k = 1, 5, 10 e 100:

• nDCG@k (normalized Discounted Cumulative Gain): Misura la qualità del ranking, considerando la rilevanza posizionale.
• Recall@k: La percentuale di documenti rilevanti recuperati tra i primi k risultati.
• MRR@k (Mean Reciprocal Rank): Il reciproco del rango del primo documento rilevante.
• MAP@k (Mean Average Precision): Una media delle precisioni medie per ogni query.

Una messa a punto di successo si traduce tipicamente in un miglioramento del 10% in nDCG@10 e Recall@10 entro <1 giorno.

Validazione sul campo: il caso Atlassian

Questa ricetta è stata validata su dati aziendali reali da Atlassian. Hanno applicato questa pipeline per ottimizzare Llama-Nemotron-Embed-1B-v2 su un dataset Jira pubblico utilizzando una singola GPU NVIDIA A100 da 80GB, seguendo le stesse fasi descritte sopra. Il Recall@60 è passato da 0,751 a 0,951 — un guadagno del 26,7%. Il modello ottimizzato recupera il documento corretto tra i primi 60 risultati per il 95,1% delle query, rispetto al 75,1% con il modello di base. Per un sistema di recupero che supporta la ricerca Jira, questo si traduce direttamente in risultati più rilevanti per milioni di utenti. Maggiori dettagli sono disponibili nel loro blog post Advancing semantic search for millions of Rovo users.

Deployment: dal prototipo alla produzione

Un checkpoint PyTorch è ottimo per la valutazione ma troppo lento per la produzione. Le ultime due fasi convertono il modello e lo servono dietro un'API.

(comando di esportazione e deployment)

Questo esporta il checkpoint ottimizzato in ONNX (opset 17). Opzionalmente, compila un motore TensorRT per il massimo throughput di inferenza, con profili di ottimizzazione configurabili per dimensione del batch (da 1 a 64) e lunghezza della sequenza.

Conclusione

La capacità di costruire un modello di embedding specifico per dominio in meno di un giorno rappresenta un notevole passo avanti per lo sviluppo di sistemi RAG. Affrontando le limitazioni dei modelli generici e la complessità dell'etichettatura manuale, questa metodologia offre un percorso chiaro e dimostrato per migliorare significativamente la pertinenza e la precisione dei sistemi di ricerca e recupero basati sull'IA. L'integrazione della generazione di dati sintetici con l'estrazione di negativi difficili e l'addestramento multi-salto crea un processo robusto che consente alle organizzazioni di sbloccare il vero potenziale dei propri dati proprietari. I risultati ottenuti da NVIDIA e Atlassian testimoniano l'efficacia di questo approccio, rendendolo una "ricetta" essenziale per chiunque miri a costruire sistemi RAG performanti e contestualmente intelligenti.