Notizia
Modelli
Prodotti
keyboard_arrow_down
Lettore
Leggi gli URL e cerca sul web per ottenere LLM più approfonditi.
Incorporamenti
Incorporamenti multilingue multimodali di livello mondiale.
Riclassificazione
Recupero neurale di livello mondiale per massimizzare la pertinenza della ricerca.
Ricerca profonda
Cerca, leggi e ragiona finché non trovi la risposta migliore.
Di più
keyboard_arrow_down
Classificatore
Classificazione zero-shot e few-shot per immagini e testo.
Segmentatore
Tagliare il testo lungo in blocchi ed effettuare la tokenizzazione.

Documentazione API
Generazione automatica di codice per il tuo IDE o LLM di Copilot
open_in_new


Azienda
keyboard_arrow_down
Chi siamo
Contatta le vendite
Programma di stagista
Unisciti a noi
open_in_new
Scarica il logo
open_in_new
Termini & Condizioni


Login
login
Che cos'è l'espansione delle query?
Espansione delle query con LLM
Provando sul campo
Risultati
Utilizzo di Prompt Specifici per Task
Considerazioni Chiave nell'Espansione delle Query
Direzioni Future
Blog tecnico
febbraio 18, 2025

Espansione delle Query con i LLM: Ricercare Meglio Dicendo di Più

La ricerca è cambiata molto da quando sono stati introdotti i modelli di embedding. C'è ancora spazio per le tecniche lessicali come l'espansione delle query nell'AI? Noi pensiamo di sì.
Michael Günther
Scott Martens
Michael Günther, Scott Martens • 9 minuti letti

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.

Figura 1: Diagramma di flusso dell'espansione delle query con thesaurus

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.

Figura 2: Espansione delle query di embedding con un LLM

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.

GitHub - jina-ai/llm-query-expansion: Query Expension for Better Query Embedding using LLMs
Query Expension for Better Query Embedding using LLMs - jina-ai/llm-query-expansion
GitHubjina-ai

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.

sentence-transformers/all-MiniLM-L6-v2 · Hugging Face
We're on a journey to advance and democratize artificial intelligence through open source and open science.

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.

Categorie:
Blog tecnico
rss_feed
Uffici
location_on
Sunnyvale, California
710 Lakeway Dr, Ste 200, Sunnyvale, CA 94085, Stati Uniti
location_on
Berlino, Germania (sede centrale)
Prinzessinnenstraße 19-20, 10969 Berlino, Germania
location_on
Pechino, Cina
Livello 5, Edificio 6, No.48 Haidian West St. Pechino, Cina
location_on
Shenzen, Cina
402 Piano 4, Fu'an Technology Building, Shenzhen, Cina
Fondazione di ricerca
Lettore
Incorporamenti
Riclassificazione
Ricerca profonda
Classificatore
Segmentatore
Documentazione API
Ottieni la chiave API Jina
Limite di velocità
Stato dell'API
Azienda
Chi siamo
Contatta le vendite
Sala stampa
Programma di stagista
Unisciti a noi
open_in_new
Scarica il logo
open_in_new
Termini
Sicurezza
Termini & Condizioni
Privacy
Gestisci i cookie
email
Jina AI © 2020-2025.