Abbiamo addestrato e reso pubblico un modello di evidenziazione semantica bilingue per la produzione di RAG e la ricerca AI
Che si tratti di una ricerca di prodotti, di una pipeline RAG o di un agente AI, gli utenti hanno bisogno della stessa cosa: un modo rapido per capire perché un risultato è rilevante. L 'evidenziazione aiuta a contrassegnare il testo esatto che supporta la corrispondenza, in modo che gli utenti non debbano scansionare l'intero documento.
La maggior parte dei sistemi si basa ancora sull'evidenziazione basata su parole chiave. Se un utente cerca "prestazioni iPhone", il sistema evidenzia i token esatti "iPhone" e "prestazioni". Ma questo sistema si rompe non appena il testo esprime la stessa idea con parole diverse. Una descrizione come "Chip A15 Bionic, oltre un milione di benchmark, fluido senza lag" si riferisce chiaramente alle prestazioni, ma non viene evidenziato nulla perché le parole chiave non compaiono mai.
L'evidenziazione semantica risolve questo problema. Invece di corrispondere a stringhe esatte, identifica gli intervalli di testo che sono semanticamente allineati con la query. Per i sistemi RAG, la ricerca AI e gli agenti, dove la rilevanza dipende dal significato piuttosto che dalla forma superficiale, ciò consente di ottenere spiegazioni più precise e affidabili del motivo per cui un documento è stato recuperato.
Tuttavia, i metodi di evidenziazione semantica esistenti non sono progettati per i carichi di lavoro dell'IA di produzione. Dopo aver valutato tutte le soluzioni disponibili, abbiamo scoperto che nessuna offriva la precisione, la latenza, la copertura multilingue o la robustezza necessarie per le pipeline RAG, i sistemi ad agenti o la ricerca web su larga scala. Abbiamo quindi addestrato il nostro modello di evidenziazione semantica bilingue e lo abbiamo reso disponibile come open-source.
Il nostro modello di evidenziazione semantica: zilliz/semantic-highlight-bilingual-v1
Diteci cosa ne pensate: partecipate al nostro Discord, seguiteci su LinkedIn o prenotate una sessione di 20 minuti di Milvus Office Hours con noi.
Come funziona l'evidenziazione basata su parole chiave e perché fallisce nei moderni sistemi di intelligenza artificiale
I sistemi di ricerca tradizionali implementano l'evidenziazione attraverso la semplice corrispondenza delle parole chiave. Quando vengono restituiti i risultati, il motore individua le posizioni esatte dei token che corrispondono alla query e le racchiude nel markup (di solito i tag <em> ), lasciando al frontend il compito di rendere l'evidenziazione. Questo funziona bene quando i termini della query appaiono testualmente nel testo.
Il problema è che questo modello presuppone che la rilevanza sia legata alla sovrapposizione esatta delle parole chiave. Quando questo presupposto viene meno, l'affidabilità cala rapidamente. Qualsiasi risultato che esprima l'idea giusta con una formulazione diversa finisce per non essere evidenziato, anche se la fase di recupero è stata corretta.
Questa debolezza diventa evidente nelle moderne applicazioni di IA. Nelle pipeline RAG e nei flussi di lavoro degli agenti di IA, le query sono più astratte, i documenti sono più lunghi e le informazioni rilevanti potrebbero non riutilizzare le stesse parole. L'evidenziazione basata sulle parole chiave non è più in grado di mostrare agli sviluppatori, o agli utenti finali, dovesi trova effettivamente la risposta, il che fa sì che il sistema nel suo complesso risulti meno accurato anche quando il reperimento funziona come previsto.
Supponiamo che un utente chieda: "Come posso migliorare l'efficienza di esecuzione del codice Python?". Il sistema recupera un documento tecnico da un database vettoriale. L'evidenziazione tradizionale può contrassegnare solo le corrispondenze letterali come "Python", "codice", "esecuzione" ed "efficienza".
Tuttavia, le parti più utili del documento potrebbero essere:
Usare le operazioni vettoriali di NumPy invece dei loop espliciti.
Evitare di creare ripetutamente oggetti all'interno di loop
Queste frasi rispondono direttamente alla domanda, ma non contengono nessuno dei termini della query. Di conseguenza, l'evidenziazione tradizionale fallisce completamente. Il documento può essere rilevante, ma l'utente deve comunque scansionarlo riga per riga per trovare la risposta vera e propria.
Il problema diventa ancora più evidente con gli agenti di intelligenza artificiale. La domanda di ricerca di un agente spesso non è la domanda originale dell'utente, ma un'istruzione derivata prodotta attraverso il ragionamento e la scomposizione dei compiti. Ad esempio, se un utente chiede: "Puoi analizzare le recenti tendenze di mercato?", l'agente potrebbe generare una query del tipo "Recupera i dati di vendita dell'elettronica di consumo del quarto trimestre 2024, i tassi di crescita annuali, le variazioni delle quote di mercato dei principali concorrenti e le fluttuazioni dei costi della catena di fornitura".
Questa query si estende su più dimensioni e codifica un intento complesso. L'evidenziazione tradizionale basata sulle parole chiave, tuttavia, può solo contrassegnare meccanicamente le corrispondenze letterali come "2024", "dati di vendita" o "tasso di crescita".
Nel frattempo, le informazioni più preziose possono essere le seguenti:
La serie iPhone 15 ha guidato una ripresa più ampia del mercato
I vincoli di fornitura dei chip hanno fatto aumentare i costi del 15%.
Queste conclusioni potrebbero non condividere una sola parola chiave con la query, anche se sono esattamente ciò che l'agente sta cercando di estrarre. Gli agenti hanno bisogno di identificare rapidamente le informazioni veramente utili da grandi volumi di contenuti recuperati e l'evidenziazione basata sulle parole chiave non offre un vero aiuto.
Cos'è l'evidenziazione semantica e i punti deboli delle soluzioni attuali
L'evidenziazione semantica si basa sulla stessa idea alla base della ricerca semantica: la corrispondenza basata sul significato piuttosto che sulle parole esatte. Nella ricerca semantica, i modelli di embedding mappano il testo in vettori, in modo che un sistema di ricerca - tipicamente supportato da un database vettoriale come Milvus - possarecuperare i passaggi che trasmettono la stessa idea della query, anche se la formulazione è diversa. L'evidenziazione semantica applica questo principio a una granularità più fine. Invece di contrassegnare i risultati letterali delle parole chiave, evidenzia gli intervalli specifici all'interno di un documento che sono semanticamente rilevanti per l'intento dell'utente.
Questo approccio risolve un problema fondamentale dell'evidenziazione tradizionale, che funziona solo quando i termini della query appaiono alla lettera. Se un utente cerca "prestazioni dell'iPhone", l'evidenziazione basata su parole chiave ignora frasi come "chip A15 Bionic", "oltre un milione di benchmark" o "fluido senza lag", anche se queste righe rispondono chiaramente alla domanda. L'evidenziazione semantica cattura queste connessioni basate sul significato e fa emergere le parti del testo che interessano agli utenti.
In teoria, si tratta di un problema di corrispondenza semantica semplice. I moderni modelli di embedding codificano già bene la somiglianza, quindi i pezzi concettuali sono già al loro posto. La sfida deriva dai vincoli del mondo reale: l'evidenziazione avviene per ogni query, spesso su molti documenti recuperati, rendendo la latenza, il throughput e la robustezza cross-domain requisiti non negoziabili. I modelli linguistici di grandi dimensioni sono semplicemente troppo lenti e costosi per essere eseguiti in questo percorso ad alta frequenza.
Per questo motivo, l'evidenziazione semantica pratica richiede un modello leggero e specializzato, abbastanza piccolo da affiancare l'infrastruttura di ricerca e abbastanza veloce da restituire risultati in pochi millisecondi. È qui che la maggior parte delle soluzioni esistenti non funziona. I modelli pesanti offrono precisione, ma non possono essere eseguiti su scala; i modelli leggeri sono veloci, ma perdono precisione o falliscono su dati multilingue o specifici del dominio.
opensearch-semantic-highlighter
L'anno scorso OpenSearch ha rilasciato un modello dedicato all'evidenziazione semantica: opensearch-semantic-highlighter-v1. Pur essendo un tentativo significativo di risolvere il problema, presenta due limiti critici.
Finestra di contesto piccola: Il modello si basa su un'architettura BERT e supporta un massimo di 512 token - circa 300-400 caratteri cinesi o 400-500 parole inglesi. Negli scenari reali, le descrizioni dei prodotti e i documenti tecnici spesso comprendono migliaia di parole. Il contenuto oltre la prima finestra viene semplicemente troncato, costringendo il modello a identificare i punti salienti basandosi solo su una piccola parte del documento.
Scarsa generalizzazione al di fuori del dominio: Il modello funziona bene solo su distribuzioni di dati simili al suo set di addestramento. Quando viene applicato a dati esterni al dominio, come nel caso dell'utilizzo di un modello addestrato su articoli di cronaca per evidenziare contenuti di e-commerce o documentazione tecnica, le prestazioni si riducono drasticamente. Nei nostri esperimenti, il modello raggiunge un punteggio F1 di circa 0,72 sui dati interni al dominio, ma scende a circa 0,46 sui set di dati esterni al dominio. Questo livello di instabilità è problematico in produzione. Inoltre, il modello non supporta il cinese.
Provence / XProvence
Provence è un modello sviluppato da Naver ed è stato inizialmente addestrato per il context pruning, uncompito strettamente legato all'evidenziazione semantica.
Entrambi i compiti si basano sulla stessa idea di fondo: utilizzare la corrispondenza semantica per identificare i contenuti rilevanti e filtrare le parti irrilevanti. Per questo motivo, Provence può essere riutilizzato per l'evidenziazione semantica con un adattamento relativamente ridotto.
Provence è un modello per la sola lingua inglese e si comporta ragionevolmente bene in questo contesto. XProvence è la sua variante multilingue, che supporta più di una dozzina di lingue, tra cui il cinese, il giapponese e il coreano. A prima vista, XProvence sembra essere un buon candidato per scenari di evidenziazione semantica bilingue o multilingue.
In pratica, però, sia Provence che XProvence presentano diversi limiti degni di nota:
Prestazioni più deboli in inglese nel modello multilingue: XProvence non eguaglia le prestazioni di Provence nei benchmark in inglese. Si tratta di un compromesso comune nei modelli multilingue: la capacità è condivisa tra le varie lingue, il che spesso porta a prestazioni più deboli nelle lingue ad alte risorse come l'inglese. Questa limitazione è importante nei sistemi reali in cui l'inglese rimane un carico di lavoro primario o dominante.
Prestazioni limitate in cinese: XProvence supporta molte lingue. Durante l'addestramento multilingue, i dati e la capacità del modello sono distribuiti tra le varie lingue, il che limita la capacità del modello di specializzarsi in una singola lingua. Di conseguenza, le prestazioni in cinese sono solo marginalmente accettabili e spesso insufficienti per i casi d'uso di evidenziazione ad alta precisione.
Disadattamento tra gli obiettivi di potatura e di evidenziazione: Provence è ottimizzato per la potatura del contesto, in cui la priorità è il richiamo: mantenere il maggior numero possibile di contenuti potenzialmente utili per evitare di perdere informazioni critiche. L'evidenziazione semantica, al contrario, enfatizza la precisione: evidenzia solo le frasi più rilevanti, non ampie porzioni del documento. Quando i modelli di tipo provenzale vengono applicati all'evidenziazione, questa discrepanza porta spesso a evidenziazioni troppo ampie o rumorose.
Licenze restrittive: Sia Provence che XProvence sono rilasciati con licenza CC BY-NC 4.0, che non consente l'uso commerciale. Questa restrizione da sola li rende inadatti a molte implementazioni di produzione.
Provenza aperta
Open Provence è un progetto guidato dalla comunità che reimplementa la pipeline di formazione Provence in modo aperto e trasparente. Fornisce non solo script di addestramento, ma anche flussi di lavoro per l'elaborazione dei dati, strumenti di valutazione e modelli preaddestrati su più scale.
Un vantaggio fondamentale di Open Provence è la sua licenza MIT. A differenza di Provence e XProvence, può essere tranquillamente utilizzato in ambienti commerciali senza restrizioni legali, il che lo rende interessante per i team orientati alla produzione.
Detto questo, Open Provence supporta attualmente solo l'inglese e il giapponese, il che lo rende inadatto ai nostri casi d'uso bilingue.
Abbiamo addestrato e reso disponibile un modello di evidenziazione semantica bilingue
Un modello di evidenziazione semantica progettato per carichi di lavoro reali deve offrire alcune funzionalità essenziali:
Prestazioni multilingue elevate
Una finestra di contesto sufficientemente ampia da supportare documenti lunghi
Robusta generalizzazione fuori dal dominio
Elevata precisione nei compiti di evidenziazione semantica
Una licenza permissiva e adatta alla produzione (MIT o Apache 2.0).
Dopo aver valutato le soluzioni esistenti, abbiamo scoperto che nessuno dei modelli disponibili soddisfaceva i requisiti necessari per l'uso in produzione. Abbiamo quindi deciso di addestrare il nostro modello di evidenziazione semantica: zilliz/semantic-highlight-bilingual-v1.
Per ottenere tutti questi risultati, abbiamo adottato un approccio semplice: utilizzare modelli linguistici di grandi dimensioni per generare dati etichettati di alta qualità, quindi addestrare un modello di evidenziazione semantica leggero su di esso utilizzando strumenti open-source. Questo ci permette di combinare la forza di ragionamento degli LLM con l'efficienza e la bassa latenza richieste dai sistemi di produzione.
La parte più impegnativa di questo processo è la costruzione dei dati. Durante l'annotazione, chiediamo a un LLM (Qwen3 8B) di produrre non solo gli intervalli di evidenziazione, ma anche l'intero ragionamento che li sottende. Questo segnale di ragionamento aggiuntivo produce una supervisione più accurata e coerente e migliora significativamente la qualità del modello risultante.
Ad alto livello, la pipeline di annotazione funziona come segue: ragionamento LLM → etichette di evidenziazione → filtraggio → campione di addestramento finale.
Questa struttura offre tre vantaggi concreti nella pratica:
Maggiore qualità dell'etichettatura: Il modello è spinto prima a pensare e poi a rispondere. Questa fase intermedia di ragionamento funge da autoverifica integrata, riducendo la probabilità di etichette superficiali o incoerenti.
Migliore osservabilità e debuggabilità: Poiché ogni etichetta è accompagnata da una traccia di ragionamento, gli errori diventano visibili. In questo modo è più facile diagnosticare i casi di errore e regolare rapidamente i prompt, le regole o i filtri dei dati nella pipeline.
Dati riutilizzabili: Le tracce di ragionamento forniscono un contesto prezioso per le future rietichettature. Quando i requisiti cambiano, gli stessi dati possono essere rivisti e perfezionati senza ricominciare da zero.
Utilizzando questa pipeline, abbiamo generato più di un milione di campioni di formazione bilingue, suddivisi in modo approssimativo tra inglese e cinese.
Per l'addestramento del modello, siamo partiti da BGE-M3 Reranker v2 (0,6B parametri, finestra di contesto da 8.192 token), abbiamo adottato il framework di addestramento Open Provence e ci siamo addestrati per tre epoche su 8× GPU A100, completando l'addestramento in circa cinque ore.
Approfondiremo queste scelte tecniche - compreso il motivo per cui ci affidiamo alle tracce di ragionamento, come abbiamo selezionato il modello di base e come è stato costruito il set di dati - in un post successivo.
Analisi comparativa del modello di evidenziazione semantica bilingue di Zilliz
Per valutare le prestazioni nel mondo reale, abbiamo valutato diversi modelli di evidenziazione semantica su una serie di set di dati diversi. I benchmark coprono scenari sia all'interno che all'esterno del dominio, in inglese e in cinese, per riflettere la varietà di contenuti incontrati nei sistemi di produzione.
Set di dati
Per la nostra valutazione abbiamo utilizzato i seguenti set di dati:
MultiSpanQA (inglese) - un set di dati di risposta a domande multi-span nel dominio
WikiText-2 (inglese) - un corpus di Wikipedia fuori dominio
MultiSpanQA-ZH (cinese) - un set di dati cinese per la risposta a domande multi-span
WikiText-2-ZH (cinese) - un corpus di Wikipedia cinese fuori dal dominio.
Modelli a confronto
I modelli inclusi nel confronto sono:
Modelli open Provence
Provence / XProvence (rilasciato da Naver)
Evidenziatore semantico OpenSearch
Modello di evidenziazione semantica bilingue di Zilliz
Risultati e analisi
Set di dati in inglese:
Dataset cinesi:
Su tutti i benchmark bilingue, il nostro modello raggiunge punteggi medi F1 all'avanguardia, superando tutti i modelli e gli approcci precedentemente valutati. I guadagni sono particolarmente pronunciati sui dataset cinesi, dove il nostro modello supera significativamente XProvence, l'unico altro modello valutato con supporto cinese.
Inoltre, il nostro modello offre prestazioni equilibrate sia in inglese che in cinese, una proprietà che le soluzioni esistenti faticano a raggiungere:
Open Provence supporta solo l'inglese
XProvence sacrifica le prestazioni in inglese rispetto a Provence
OpenSearch Semantic Highlighter non supporta il cinese e mostra una debole generalizzazione.
Di conseguenza, il nostro modello evita i comuni compromessi tra copertura linguistica e prestazioni, rendendolo più adatto alle implementazioni bilingue del mondo reale.
Un esempio concreto nella pratica
Al di là dei punteggi dei benchmark, spesso è più rivelatore esaminare un esempio concreto. Il caso seguente mostra come si comporta il nostro modello in uno scenario reale di evidenziazione semantica e perché la precisione è importante.
Interrogazione: Chi ha scritto il film The Killing of a Sacred Deer?
Contesto (5 frasi):
The Killing of a Sacred Deer è un film thriller psicologico del 2017 diretto da Yorgos Lanthimos, con la sceneggiatura scritta da Lanthimos e Efthymis Filippou.
Il film è interpretato da Colin Farrell, Nicole Kidman, Barry Keoghan, Raffey Cassidy, Sunny Suljic, Alicia Silverstone e Bill Camp.
La storia è basata sull'antica opera greca Ifigenia in Aulis di Euripide.
Il film segue un cardiochirurgo che stringe un'amicizia segreta con un adolescente legato al suo passato.
Egli presenta il ragazzo alla sua famiglia, dopodiché iniziano a verificarsi misteriose malattie.
Evidenziazione corretta: Lafrase 1 è la risposta corretta, poiché afferma esplicitamente che la sceneggiatura è stata scritta da Yorgos Lanthimos e Efthymis Filippou.
Questo esempio contiene una sottile trappola. La frase 3 cita Euripide, l'autore dell'opera originale greca su cui la storia è vagamente basata. Tuttavia, la domanda chiede chi ha scritto il film, non il materiale di partenza antico. La risposta corretta è quindi gli sceneggiatori del film, non il drammaturgo di migliaia di anni fa.
Risultati:
La tabella seguente riassume le prestazioni dei diversi modelli su questo esempio.
| Modello | Risposta corretta identificata | Risultato |
|---|---|---|
| Il nostro (M3 bilingue) | ✓ | Selezionato la frase 1 (corretta) e la frase 3 |
| XProvence v1 | ✗ | Ha selezionato solo la frase 3, non ha trovato la risposta corretta. |
| XProvence v2 | ✗ | Ha selezionato solo la frase 3, non ha trovato la risposta corretta. |
Confronto dei punteggi a livello di frase
| Frase | Nostro (bilingue M3) | XProvence v1 | XProvence v2 |
|---|---|---|---|
| Frase 1 (sceneggiatura cinematografica, corretta) | 0.915 | 0.133 | 0.081 |
| Frase 3 (opera teatrale originale, distrattore) | 0.719 | 0.947 | 0.802 |
Dove XProvence fallisce
XProvence è fortemente attratto dalle parole chiave "Euripide" e "scritto", assegnando alla frase 3 un punteggio quasi perfetto (0,947 e 0,802).
Allo stesso tempo, ignora ampiamente la risposta corretta della frase 1, assegnando punteggi estremamente bassi (0,133 e 0,081).
Anche dopo aver abbassato la soglia decisionale da 0,5 a 0,2, il modello continua a non individuare la risposta corretta.
In altre parole, il modello è guidato principalmente dalle associazioni di parole chiave a livello superficiale piuttosto che dall'intento effettivo della domanda.
Come il nostro modello si comporta diversamente
Il nostro modello assegna un punteggio elevato (0,915) alla risposta corretta nella frase 1, identificando correttamente gli sceneggiatori del film.
Assegna anche un punteggio moderato (0,719) alla frase 3, poiché questa frase menziona un concetto legato alla sceneggiatura.
La separazione è chiara e significativa: 0,915 vs. 0,719, un divario di quasi 0,2.
Questo esempio evidenzia il punto di forza del nostro approccio: andare oltre le associazioni basate sulle parole chiave per interpretare correttamente l'intento dell'utente. Anche quando compaiono più concetti di "autore", il modello evidenzia in modo coerente quello a cui si riferisce effettivamente la domanda.
Condivideremo un rapporto di valutazione più dettagliato e altri casi di studio in un post successivo.
Provatelo e diteci cosa ne pensate
Abbiamo reso disponibile il nostro modello di evidenziazione semantica bilingue su Hugging Face, con tutti i pesi del modello disponibili pubblicamente, in modo che possiate iniziare subito a sperimentare. Ci piacerebbe sapere come funziona per voi: vi invitiamo a condividere qualsiasi feedback, problema o idea di miglioramento mentre lo provate.
Parallelamente, stiamo lavorando a un servizio di inferenza pronto per la produzione e all'integrazione del modello direttamente in Milvus come API nativa di Semantic Highlighting. Questa integrazione è già in corso e sarà presto disponibile.
L'evidenziazione semantica apre le porte a un'esperienza di RAG e AI agenziale più intuitiva. Quando Milvus recupera diversi documenti lunghi, il sistema è in grado di far emergere immediatamente le frasi più rilevanti, rendendo chiaro dove si trova la risposta. Questo non migliora solo l'esperienza dell'utente finale, ma aiuta anche gli sviluppatori a eseguire il debug delle pipeline di reperimento, mostrando esattamente su quali parti del contesto si basa il sistema.
Crediamo che l'evidenziazione semantica diventerà una funzionalità standard nei sistemi di ricerca e di RAG di prossima generazione. Se avete idee, suggerimenti o casi d'uso per l'evidenziazione semantica bilingue, iscrivetevi al nostro canale Discord e condividete i vostri pensieri. Potete anche prenotare una sessione individuale di 20 minuti per ottenere approfondimenti, indicazioni e risposte alle vostre domande attraverso Milvus Office Hours.
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word



