L'espansione delle query è stata a lungo una tecnica fondamentale per potenziare i sistemi di ricerca, anche se è passata in secondo piano da quando sono comparsi gli embedding semantici. Sebbene alcuni possano considerarla obsoleta nell'attuale panorama di RAG e ricerca basata su agenti, non è ancora da escludere. In questa analisi approfondita, esploreremo come combinare l'espansione automatica delle query con jina-embeddings-v3 e LLM può migliorare il tuo sistema di ricerca e fornire risultati davvero pertinenti.
tagChe cos'è l'espansione delle query?
L'espansione delle query è stata sviluppata per sistemi di ricerca che valutano la rilevanza confrontando le parole delle query con i documenti che le contengono, come tf-idf o altri schemi a "vettori sparsi". Questo ha alcune ovvie limitazioni. Le varianti delle parole interferiscono con la corrispondenza, come "correre" e "corse", o "ottimizzare" vs "optimise". Il preprocessamento consapevole del linguaggio può mitigare alcuni di questi problemi, ma non tutti. Termini tecnici, sinonimi e parole correlate sono molto più difficili da gestire. Ad esempio, una query per ricerche mediche su "coronavirus" non identificherà automaticamente documenti che parlano di "COVID" o "SARS-CoV-2", anche se sarebbero corrispondenze molto valide.
L'espansione delle query è stata inventata come soluzione.
L'idea è di aggiungere parole e frasi aggiuntive alle query per aumentare la probabilità di identificare buone corrispondenze. In questo modo, una query per "coronavirus" potrebbe avere aggiunti i termini "COVID" e "SARS-CoV-2". Questo può migliorare drasticamente le prestazioni della ricerca.

Non è facile decidere quali termini dovrebbero essere aggiunti a una query, e c'è stato molto lavoro su come identificare i termini appropriati e come ponderarli per il recupero in stile tf-idf. Gli approcci comuni includono:
- Utilizzo di un thesaurus curato manualmente.
- Data mining di grandi corpora di testo per parole correlate.
- Identificazione di altri termini utilizzati in query simili presi da un log delle query.
- Apprendimento di quali parole e frasi costituiscono buone espansioni delle query dal feedback degli utenti.
Tuttavia, i modelli di embedding semantico dovrebbero eliminare la necessità di espansione delle query. Buoni embedding di testo per "coronavirus", "COVID" e "SARS-CoV-2" dovrebbero essere molto vicini tra loro nello spazio vettoriale degli embedding. Dovrebbero naturalmente corrispondere senza alcuna integrazione.
Ma, mentre questo dovrebbe essere vero in teoria, gli embedding reali creati da modelli reali spesso non raggiungono questo obiettivo. Le parole negli embedding possono essere ambigue e aggiungere parole a una query può spingerla verso corrispondenze migliori se si usano le parole giuste. Per esempio, un embedding per "eruzione cutanea" potrebbe identificare documenti su "agire in modo precipitoso" e "crema per la pelle" mentre manca un articolo di rivista medica che parla di "dermatite". Aggiungere termini pertinenti probabilmente spingerà l'embedding lontano dalle corrispondenze non correlate verso quelle migliori.
tagEspansione delle query con LLM
Invece di utilizzare un thesaurus o fare data mining lessicale, abbiamo esaminato l'uso di un LLM per l'espansione delle query. Gli LLM hanno alcuni potenziali vantaggi importanti:
- Ampia conoscenza lessicale: Poiché sono addestrati su dataset ampi e diversificati, c'è meno preoccupazione sulla selezione di un thesaurus appropriato o sull'ottenimento dei dati giusti.
- Capacità di giudizio: Non tutti i termini di espansione proposti sono necessariamente appropriati per una specifica query. Gli LLM potrebbero non fare giudizi perfetti sulla pertinenza, ma le alternative non possono realmente fare giudizi.
- Flessibilità: Puoi regolare il tuo prompt alle esigenze del compito di recupero, mentre altri approcci sono rigidi e potrebbero richiedere molto lavoro per adattarsi a nuovi domini o fonti di dati.
Una volta che l'LLM ha proposto una lista di termini, l'espansione delle query per gli embedding funziona allo stesso modo degli schemi tradizionali di espansione delle query: Aggiungiamo termini al testo della query e poi usiamo un modello di embedding per creare un vettore di embedding della query.

Per far funzionare questo, hai bisogno di:
- Accesso a un LLM.
- Un template di prompt per sollecitare termini di espansione dall'LLM.
- Un modello di embedding del testo.
tagProvando sul campo
Abbiamo fatto alcuni esperimenti per vedere se questo approccio aggiunge valore al recupero di informazioni testuali. I nostri test hanno utilizzato:
- Un LLM: Gemini 2.0 Flash di Google.
- Due modelli di embedding per vedere se l'espansione delle query LLM si generalizza tra i modelli: jina-embeddings-v3 e
all-MiniLM-L6-v2
. - Un sottoinsieme dei benchmark BEIR per il recupero di informazioni.
Abbiamo eseguito i nostri esperimenti in due condizioni di prompt:
- Utilizzando un template di prompt generale per sollecitare termini di espansione.
- Utilizzando template di prompt specifici per il compito.
Infine, abbiamo scritto i nostri prompt per sollecitare diversi numeri di termini da aggiungere: 100, 150 e 250.
Il nostro codice e i risultati sono disponibili su GitHub per la riproduzione.
tagRisultati
tagUsando un prompt generale
Dopo alcune prove ed errori, abbiamo scoperto che il seguente prompt funzionava abbastanza bene con Gemini 2.0 Flash:
Please provide additional search keywords and phrases for each of the key aspects of the following queries that make it easier to find the relevant documents (about {size} words per query): {query} Please respond in the following JSON schema: Expansion = {"qid": str, "additional_info": str} Return: list [Expansion]
Questo prompt ci permette di raggruppare le nostre query in gruppi di 20-50, assegnando un ID a ciascuna, e ottenendo una stringa JSON che collega ogni query a una lista di termini di espansione. Se usi un LLM diverso, potresti dover sperimentare per trovare un prompt che funzioni per esso.
Abbiamo applicato questa configurazione con jina-embeddings-v3 utilizzando l'adattatore di recupero asimmetrico. Usando questo approccio, query e documenti vengono codificati in modo diverso — usando lo stesso modello ma diverse estensioni LoRA — per ottimizzare gli embedding risultanti per il recupero di informazioni.
I nostri risultati su vari benchmark BEIR sono nella tabella sottostante. I punteggi sono nDCG@10 (normalized Discounted Cumulative Gain sui primi dieci elementi recuperati).
Benchmark | No Expansion | 100 terms | 150 terms | 250 terms |
---|---|---|---|---|
SciFact (Compito di verifica dei fatti) |
72.74 | 73.39 | 74.16 | 74.33 |
TRECCOVID (Compito di recupero medico) |
77.55 | 76.74 | 77.12 | 79.28 |
FiQA (Recupero di opzioni finanziarie) |
47.34 | 47.76 | 46.03 | 47.34 |
NFCorpus (Recupero di informazioni mediche) |
36.46 | 40.62 | 39.63 | 39.20 |
Touche2020 (Compito di recupero di argomentazioni) |
26.24 | 26.91 | 27.15 | 27.54 |
Vediamo qui che l'espansione delle query ha portato a un miglioramento nel recupero in quasi tutti i casi.
Per testare la robustezza di questo approccio, abbiamo ripetuto gli stessi test con all-MiniLM-L6-v2
, un modello molto più piccolo che produce vettori di embedding più ridotti.

I risultati sono nella tabella seguente:
Benchmark | No Expansion | 100 terms | 150 terms | 250 terms |
---|---|---|---|---|
SciFact (Fact Checking Task) |
64.51 | 68.72 | 66.27 | 68.50 |
TRECCOVID (Medical Retrieval Task) |
47.25 | 67.90 | 70.18 | 69.60 |
FiQA (Financial Option Retrieval) |
36.87 | 33.96 | 32.60 | 31.84 |
NFCorpus (Medical Information Retrieval) |
31.59 | 33.76 | 33.76 | 33.35 |
Touche2020 (Argument Retrieval Task) |
16.90 | 25.31 | 23.52 | 23.23 |
Qui vediamo un miglioramento ancora maggiore nei punteggi di recupero. Nel complesso, il modello più piccolo ha beneficiato maggiormente dell'espansione delle query. Il miglioramento medio su tutti i task è riassunto nella tabella seguente:
Model | 100 terms | 150 terms | 250 terms |
---|---|---|---|
jina-embeddings-v3 | +1.02 | +0.75 | +1.48 |
all-MiniLM-L6-v2 |
+6.51 | +5.84 | +5.88 |
La grande differenza nel miglioramento netto tra i due modelli è probabilmente dovuta al fatto che all-MiniLM-L6-v2
partiva da un livello di prestazioni inferiore. Gli embedding delle query prodotti da jina-embeddings-v3 in modalità di recupero asimmetrico sono più capaci di catturare le relazioni semantiche chiave, e quindi c'è meno spazio per l'espansione delle query per aggiungere informazioni. Ma questo risultato mostra quanto l'espansione delle query possa migliorare le prestazioni di modelli più compatti che potrebbero essere preferibili in alcuni casi d'uso rispetto ai modelli grandi.
Tuttavia, l'espansione delle query ha portato un miglioramento significativo nel recupero anche per modelli ad alte prestazioni come jina-embeddings-v3, ma questo risultato non è perfettamente coerente in tutti i task e le condizioni.
Per jina-embeddings-v3, aggiungere più di 100 termini a una query è stato controproducente per i benchmark FiQA e NFCorpus. Non possiamo dire che più termini siano sempre meglio, ma i risultati sugli altri benchmark indicano che più termini sono almeno talvolta migliori.
Per all-MiniLM-L6-v2
, aggiungere più di 150 termini è stato sempre controproducente, e in tre test, aggiungere più di 100 non ha migliorato i punteggi. In un test (FiQA) aggiungere anche solo 100 termini ha prodotto risultati significativamente inferiori. Crediamo che questo sia dovuto al fatto che jina-embeddings-v3 faccia un lavoro migliore nel catturare le informazioni semantiche nei testi lunghi delle query.
Entrambi i modelli hanno mostrato una minore risposta all'espansione delle query sui benchmark FiQA e NFCorpus.
tagUtilizzo di Prompt Specifici per Task
Il pattern dei risultati riportati sopra suggerisce che mentre l'espansione delle query è utile, l'uso di LLM rischia di aggiungere termini di query non utili che riducono le prestazioni. Questo potrebbe essere causato dalla natura generica del prompt.
Abbiamo preso due benchmark — SciFact e FiQA — e creato prompt più specifici per il dominio, come quello qui sotto:
Please provide additional search keywords and phrases for each of the key aspects of the following queries that make it easier to find the relevant documents scientific document that supports or rejects the scientific fact in the query field (about {size} words per query): {query} Please respond in the following JSON schema: Expansion = {"qid": str, "additional_info": str} Return: list [Expansion]
Questo approccio ha migliorato le prestazioni di recupero quasi in tutti i casi:
Benchmark | Model | No Expansion | 100 terms |
150 terms |
250 terms |
---|---|---|---|---|---|
SciFact | jina-embeddings-v3 | 72.74 | 75.85 (+2.46) | 75.07 (+0.91) | 75.13 (+0.80) |
SciFact | all-MiniLM-L6-v2 |
64.51 | 69.12 (+0.40) | 68.10 (+1.83) | 67.83 (-0.67) |
FiQA | jina-embeddings-v3 | 47.34 | 47.77 (+0.01) | 48.20 (+1.99) | 47.75 (+0.41) |
FiQA | all-MiniLM-L6-v2 |
36.87 | 34.71 (+0.75) | 34.68 (+2.08) | 34.50 (+2.66) |
I punteggi sono migliorati in tutte le condizioni tranne quando si aggiungevano 250 termini alle query SciFact con all-MiniLM-L6-v2
. Inoltre, questo miglioramento non è stato sufficiente per far superare a all-MiniLM-L6-v2
il proprio baseline su FiQA.
Per jina-embeddings-v3, vediamo che i migliori risultati sono arrivati con 100 o 150 termini aggiunti. Aggiungere 250 termini è stato controproducente. Questo supporta la nostra intuizione che si possano aggiungere troppi termini alla query, specialmente se il loro significato inizia a deviare dall'obiettivo.
tagConsiderazioni Chiave nell'Espansione delle Query
L'espansione delle query può chiaramente portare vantaggi alla ricerca basata su embedding, ma presenta alcune avvertenze:
tagCosto
L'interazione con un LLM aggiunge latenza e costi computazionali al recupero delle informazioni, e può aggiungere costi effettivi se si utilizza un LLM commerciale. Il moderato miglioramento che porta potrebbe non giustificare la spesa.
tagIngegneria dei Prompt
Progettare buoni template di prompt è un'arte empirica e sperimentale. Non affermiamo che quelli che abbiamo usato per questo lavoro siano ottimali o portabili ad altri LLM. I nostri esperimenti con i prompt specifici per task mostrano che cambiare i prompt può avere effetti molto significativi sulla qualità del risultato. I risultati variano anche considerevolmente tra i domini.
Queste incertezze aumentano il costo di sviluppo e minano la manutenibilità. Qualsiasi cambiamento al sistema — cambiare LLM, modelli di embedding o dominio informativo — significa ricontrollare e possibilmente reimplementare l'intero processo.
tagAlternative
Vediamo qui che l'espansione delle query ha aggiunto il maggior miglioramento al modello di embedding con le prestazioni iniziali più basse. L'espansione delle query, almeno in questo esperimento, non è stata in grado di colmare il divario di prestazioni tra all-MiniLM-L6-v2
e jina-embeddings-v3, mentre jina-embeddings-v3 ha visto miglioramenti più modesti dall'espansione delle query.
In queste circostanze, un utente di all-MiniLM-L6-v2
otterrebbe risultati migliori a un costo inferiore adottando jina-embeddings-v3 piuttosto che perseguendo l'espansione delle query.
tagDirezioni Future
Abbiamo mostrato qui che l'espansione delle query può migliorare gli embedding delle query, e che gli LLM offrono un mezzo semplice e flessibile per ottenere buoni termini di espansione delle query. Ma i guadagni relativamente modesti suggeriscono che c'è ancora del lavoro da fare. Stiamo esaminando diverse direzioni per la ricerca futura:
- Testare il valore del potenziamento terminologico nella generazione degli embedding dei documenti.
- Esaminare le possibilità di miglioramento delle query in altre tecniche di ricerca AI come il reranking.
- Confrontare l'espansione delle query basata su LLM con fonti di termini più vecchie e computazionalmente meno costose, come un thesaurus.
- Addestrare modelli linguistici specificamente per essere migliori nell'espansione delle query e fornire loro un addestramento più specifico per il dominio.
- Limitare il numero di termini aggiunti. 100 potrebbero essere troppi per iniziare.
- Trovare modi per identificare i termini di espansione utili e non utili. Qualsiasi numero fisso che imponiamo all'espansione delle query non sarà perfettamente adatto e se potessimo valutare dinamicamente i termini suggeriti e mantenere solo quelli buoni, il risultato sarebbe probabilmente un miglioramento delle prestazioni.
Questa è una ricerca molto preliminare, e siamo ottimisti che tecniche come questa porteranno ulteriori miglioramenti ai prodotti di base per la ricerca di Jina AI.