Embedding contestuale oltre il passaggio d'oro

Gli embedding contestuali catturano il significato di ciascun passaggio o blocco nel contesto dell'intero documento. Il loro addestramento e la loro valutazione presumono tipicamente un singolo blocco rilevante per query, noto come “passaggio d'oro”. Tuttavia, un passaggio d'oro spesso non è sufficiente nella pratica. Può contenere la risposta ma mancare del contesto di supporto necessario per comprenderla o verificarla, lasciandola ambigua isolatamente.

Stiamo introducendo pplx-embed-v2-context-9b-preview, il nostro nuovo modello di embedding contestuale. Il modello è addestrato con un nuovo approccio che utilizza il modello di compressione del contesto di Perplexity come insegnante. Aggreghiamo le sue previsioni a livello di token in punteggi di rilevanza a livello di blocco, insegnando al modello di embedding a recuperare sia i blocchi di risposta che il contesto di supporto anziché un singolo blocco d'oro. Il modello produce un embedding per blocco senza costi di inferenza aggiuntivi e supporta embedding a 1024 dimensioni e int8.

Ottiene risultati all'avanguardia su context-bench, un nuovo benchmark per il recupero consapevole del contesto creato e custodito privatamente da turbopuffer, e su ConTEB, un benchmark pubblico ampiamente utilizzato. Il nostro modello è stato sviluppato indipendentemente da context-bench e valutato come sottomissione cieca.

Context-bench è costituito da 2.099 query su 38.894 documenti lunghi in 21 domini e valuta tre capacità degli embedding contestuali: la disambiguazione dei documenti tra documenti quasi duplicati, il recupero di blocchi d'oro il cui significato dipende dal contesto distante e il richiamo delle prove di supporto necessarie per verificare una risposta.

Un'anteprima del modello è pubblicamente disponibile su Hugging Face. Il benchmark è custodito privatamente da turbopuffer per ridurre il rischio di contaminazione dell'addestramento e preservare il suo valore per misurare i progressi. Per richiedere una valutazione, si prega di contattare turbopuffer all'indirizzo contextbench@turbopuffer.com.

Risultati di recupero di documenti, risposte e prove su context-bench — Figura 1: Answer@K, Document@K, Evidence Recall@K e All-Evidence@10 su context-bench, che mettono a confronto Perplexity v2 preview 9B con Voyage Context 4, Voyage 4 Large e Perplexity context v1 4B.

I sistemi di recupero dividono tipicamente i documenti lunghi in blocchi più piccoli che possono essere indicizzati e cercati indipendentemente. La suddivisione in blocchi è comoda nella pratica, ma rimuove il contesto in cui ciascun blocco è originariamente apparso, creando un compromesso tra la granularità della compressione delle informazioni e il contesto utilizzato durante la codifica. Un blocco può fare riferimento a un’entità introdotta in precedenza, ereditare il suo significato da un’intestazione di sezione o basarsi su definizioni situate altrove nel documento. Una volta estratto, potrebbe non contenere più informazioni sufficienti per essere abbinato in modo affidabile a una query. La codifica dell'intero documento come un unico vettore non risolve questo problema, poiché una rappresentazione raggruppata non può catturare fedelmente ogni aspetto di un documento lungo.

I modelli di embedding contestuale affrontano questa limitazione rappresentando ciascun blocco nel contesto del suo contenuto circostante, più comunemente attraverso il late chunking: il documento viene codificato in un unico passaggio e le rappresentazioni dei blocchi vengono raggruppate in seguito, in modo che ogni vettore di blocco venga calcolato tenendo d'occhio l'intero documento. Lavoro precedente, come ConTEB e il nostro pplx-embed-context-v1, ha dimostrato che le rappresentazioni di blocchi contestualizzate migliorano notevolmente il recupero rispetto a blocchi codificati indipendentemente, in particolare su documenti lunghi.

L'addestramento di modelli di embedding contestuale richiede una supervisione che identifichi quali parti di un documento sono rilevanti per una data query. Un approccio comune sono le annotazioni dei blocchi d'oro: per ciascuna query, un annotatore, tipicamente un modello linguistico di grandi dimensioni (LLM), identifica il blocco del documento che risponde ad essa.

L'addestramento combina solitamente due perdite contrastive: una perdita inter-documento che contrappone il blocco d'oro ai blocchi di altri documenti e una perdita intra-documento che lo contrappone agli altri blocchi nello stesso documento.

Questo approccio presenta alcuni limiti:

Un solo blocco è rilevante. Tratta ogni altro blocco nel documento come un negativo, compresi quelli con utili informazioni di supporto. La supervisione a livello di documento opera all'altro estremo. Identifica il documento come rilevante senza specificare quali blocchi al suo interno siano importanti. In pratica, la rilevanza si trova spesso tra questi estremi. Il blocco portatore di risposta può dipendere da alcuni blocchi di supporto che introducono un'entità, risolvono un riferimento o forniscono un fatto complementare, mentre il resto del documento è irrilevante. Il modello deve quindi apprendere il livello corretto di selettività: più ampio di un singolo blocco d'oro, ma più mirato rispetto al documento nel suo complesso.
Supervisione grossolana. Poiché ciascuna annotazione identifica un singolo blocco d'oro anziché catturare i gradi di rilevanza in tutto il documento, fornisce segnali di addestramento limitati per la quantità di calcolo spesa per produrla.
Costoso da scalare. Ogni coppia di addestramento richiede che un LLM legga il documento e selezioni il blocco rilevante, quindi il costo di annotazione cresce linearmente con la dimensione del set di addestramento e limita la quantità e la diversità dei dati di addestramento.
Sensibile ai confini dei blocchi. Le etichette sono anche legate ai confini dei blocchi utilizzati durante l'annotazione. Un'etichetta d'oro assegnata a una finestra di token di dimensione fissa non specifica quali frasi più brevi o paragrafi più lunghi siano rilevanti. Cambiare la strategia di suddivisione in blocchi, o addestrare su più suddivisioni per migliorare la robustezza rispetto a come i documenti vengono divisi al momento dell'indicizzazione, può quindi richiedere di annotare nuovamente il corpus.

Affrontiamo i limiti della supervisione dei blocchi d'oro distillando i giudizi di rilevanza da un modello di compressione del contesto consapevole della query. Questo modello funge da insegnante: legge la query e il documento congiuntamente e assegna a ciascun token del documento un punteggio di rilevanza. Le sue previsioni offrono diversi vantaggi per l'addestramento degli embedding contestuali:

Confini dei blocchi flessibili. I punteggi di rilevanza a livello di token possono essere aggregati su qualsiasi confine di blocco scelto, consentendo alle stesse previsioni dell'insegnante di supervisionare diverse suddivisioni in blocchi senza dover rieseguire l'annotazione.
Rilevanza continua. A differenza delle etichette binarie dei blocchi d'oro, l'insegnante fornisce punteggi continui che catturano i gradi di rilevanza che distinguono naturalmente i blocchi portatori di risposta, il contesto di supporto e il contenuto irrilevante.
Minore costo di annotazione. L'insegnante è compatto e specializzato nel punteggio di rilevanza, rendendo molto meno costoso supervisionare su scala rispetto a un LLM per usi generali.

Addestriamo il nostro modello con una somma pesata di una perdita contrastiva a livello di documento e di una perdita di distillazione a livello di blocco su batch di coppie query-documento. Per ciascuna query, il documento associato funge da positivo, mentre i documenti rimanenti nello stesso batch fungono da negativi.

Per ciascun batch, selezioniamo casualmente una strategia di suddivisione in blocchi, dividiamo i documenti di conseguenza e inseriamo token separatori tra i blocchi. Elaboriamo quindi ciascun documento in un unico passaggio in avanti e facciamo la media delle rappresentazioni dei token all'interno di ciascun blocco per ottenere embedding di blocchi contestuali. Le query vengono codificate separatamente, con il pooling della media sulle loro rappresentazioni di token. Infine, calcoliamo la somiglianza del coseno tra ogni embedding di query e ogni embedding di blocco nel batch.

Mentre il nostro modello di embedding produce solo somiglianze a livello di blocco, possiamo derivare naturalmente da esse somiglianze a livello di documento. Consideriamo un documento d rilevante per una query q quanto il suo blocco più rilevante. Questa regola di punteggio si ispira all'operazione MaxSim di ColBERT, applicata qui ai blocchi anziché ai token.

In particolare, data una query q con embedding q e un documento d come elenco ordinato di blocchi c con embedding c, definiamo la somiglianza a livello di documento come:

s(q,d):=\max_{c\in d}\mathbf{q}^{\top}\mathbf{c}.

Date queste somiglianze a livello di documento, possiamo formulare un obiettivo InfoNCE a livello di documento sui negativi intra-batch.

Per una query q, sia d⁺ il suo documento rilevante e 𝒟 i documenti nel batch. La perdita contrastiva è la seguente, omettendo le temperature per leggibilità:

\mathcal{L}_{\mathrm{doc}}(q,d^{+})=-\log\frac{\exp(s(q,d^{+}))}{\sum_{d\in\mathcal{D}}\exp(s(q,d))}

La perdita contrastiva insegna al modello quale documento è rilevante per una query. La perdita di distillazione gli insegna dove si trova la rilevanza all'interno di quel documento, il che è essenziale per un modello contestuale.

Durante l'addestramento, passiamo ogni coppia positiva query-documento al nostro modello di compressione del contesto, che assegna un punteggio di rilevanza a ogni token nel documento. Come per il punteggio a livello di documento, deriviamo la rilevanza di ciascun blocco dai suoi contenuti più rilevanti. Per ridurre la sensibilità ai token anomali, inclusi quelli ai confini dei blocchi, definiamo la rilevanza a livello di blocco come la media dei migliori n punteggi di token all'interno del blocco.

Per ciascuna query, applichiamo un softmax scalato per temperatura ai punteggi di rilevanza a livello di blocco dell'insegnante all'interno del documento positivo per ottenere una distribuzione target. I blocchi negli altri documenti del batch ricevono una probabilità target pari a zero. Addestriamo il modello di embedding a corrispondere a questo target riducendo al minimo la divergenza KL in avanti tra il target e la sua distribuzione predetta su tutti i blocchi nel batch:

\mathcal{L}_{\mathrm{dist}}(q,d^{+})=\mathrm{KL}\!\left(p^{\mathrm{T}}\parallel p^{\mathrm{S}}\right)

p^{\mathrm{T}}(c_j)=\frac{\exp(r_j)}{\sum_{c_k\in d^{+}}\exp(r_k)}

p^{\mathrm{S}}(c)=\frac{\exp(\mathbf{q}^{\top}\mathbf{c})}{\sum_{d\in\mathcal{D}}\sum_{c_k\in d}\exp(\mathbf{q}^{\top}\mathbf{c}_k)}

Qui, gli apici T e S indicano l'insegnante e lo studente, e rⱼ è il punteggio di rilevanza dell'insegnante per il blocco cⱼ nel documento positivo d⁺. La distribuzione target dell'insegnante assegna probabilità zero ai blocchi in tutti gli altri documenti del batch.

A differenza di una singola etichetta di blocco d'oro, questo target cattura i gradi di rilevanza. I blocchi di supporto ricevono un peso in base ai punteggi dell'insegnante anziché essere trattati come negativi, insegnando al modello a recuperare il contesto di supporto oltre alla risposta.

Il nostro obiettivo di addestramento combinato è una somma pesata della perdita contrastiva a livello di documento e della perdita di distillazione a livello di blocco. Facciamo la media di questa perdita pesata sul batch di coppie query-documento.

La Figura 2 illustra il nostro approccio di addestramento. Il compressore del contesto funge da insegnante solo durante l'addestramento. Al momento dell'inferenza, il modello di embedding produce un embedding contestuale per blocco, senza alcuna fase aggiuntiva di compressione o riordinamento. L'approccio migliora il modo in cui vengono appresi gli embedding contestuali senza aumentare l'archiviazione dell'indice o aggiungere latenza del modello insegnante al momento del recupero.

Configurazione dell'addestramento per la distillazione di embedding contestuali — Figura 2: La configurazione di addestramento del nostro modello. Il codificatore contestuale (studente, a sinistra) elabora i documenti, ciascuno costituito da diversi blocchi. Ciascun blocco viene incorporato rispetto al contesto del documento circostante. La query A è una corrispondenza nota per il documento A e viene valutata rispetto ai blocchi di tutti i documenti per ottenere somiglianze predette. Questi punteggi a livello di blocco vengono raggruppati tramite max-pooling in punteggi a livello di documento. Addestriamo le previsioni a livello di blocco e le previsioni a livello di documento per farle corrispondere alle distribuzioni target (destra). Il target a livello di blocco viene calcolato al momento dell'addestramento come la previsione del compressore del contesto all'interno del documento rilevante noto e viene impostato su zero all'interno dei documenti irrilevanti noti. La distribuzione target a livello di documento è impostata per essere one-hot sul documento rilevante noto.

I dati di addestramento consistono di circa 430 dataset pubblici e interni di query-documento che coprono oltre 50 lingue.

Costruiamo dataset di coppie interni da dati di produzione filtrati per PII e sintetizzando query rilevanti su documenti lunghi. Per ogni passaggio in avanti, selezioniamo un dataset e campioniamo un intero batch da esso per aumentare la difficoltà dei negativi intra-batch ed evitare l'apprendimento di scorciatoie. Nessuno dei nostri dataset di addestramento contiene annotazioni a livello di blocco: tutta la supervisione all'interno del documento proviene dal modello di compressione e nessun dato di ConTEB viene utilizzato per l'addestramento. Inoltre, nessun dato di context-bench era disponibile durante lo sviluppo del modello.

Il modello parte da un modello di recupero ColBERT interno a 9 miliardi di parametri e produce embedding a 2048 dimensioni attraverso uno strato di proiezione lineare. Segnamo i confini dei blocchi con un token <|chunk_sep|> appreso e formiamo ogni embedding di blocco mediando i suoi embedding di token. Le query sono codificate dallo stesso modello, con i loro embedding di token mediati in un unico vettore.

Usiamo l'addestramento Matryoshka per supportare sia gli embedding a 1024 che a 2048 dimensioni, e l'addestramento consapevole della quantizzazione per supportare embedding int8 nativi. Durante l'addestramento, aumentiamo gradualmente il tasso di apprendimento, lo manteniamo costante e poi lo riduciamo.

Il modello rilasciato è un model soup che media i pesi di diversi checkpoint della stessa esecuzione di addestramento.

I benchmark di recupero contestuale pubblici come ConTEB condividono l'assunzione alla base della supervisione dei blocchi d'oro: ogni query ha un singolo blocco rilevante e un modello viene premiato solo per aver posizionato quel blocco al primo posto. Ereditano anche i suoi limiti.

In primo luogo, ConTEB testa il recupero su attività in cui un blocco è ambiguo senza il suo contesto circostante. In queste attività, i modelli contestuali hanno superato i modelli che codificano ciascun blocco in modo indipendente. Tuttavia, non chiede se il modello faccia emergere anche le altre parti del documento che rendono il blocco comprensibile.

In secondo luogo, non testa sistematicamente se è possibile trovare il documento giusto quando documenti quasi identici nello stesso corpus differiscono solo per il contesto che circonda una frase altrimenti identica.

Entrambe le capacità sono importanti quando un agente di ricerca o un utente deve comprendere e verificare una risposta da poche frasi recuperate anziché da un intero documento. Abbiamo quindi creato context-bench, un benchmark controllato per il recupero su documenti lunghi, progettato per distinguere l'uso del contesto del documento dalla qualità di recupero generale. Verifica se gli embedding contestuali utilizzano informazioni provenienti da altrove in un documento per supportare tre capacità:

Disambiguazione del documento: Identifica il documento corretto tra alternative quasi identiche.
Recupero della risposta: Recupera blocchi portatori di risposta il cui significato dipende da dettagli altrove nel documento.
Recupero delle prove: Recupera i blocchi di supporto che chiariscono o comprovano la risposta.

Context-bench contiene 2.099 query e 38.894 documenti. Vengono utilizzati blocchi della lunghezza di una frase, per un totale di 2.458.072 blocchi. Le query coprono 21 domini tra cui documentazione aziendale, ricerca clinica, viaggi, intrattenimento, istruzione, governo, contratti legali e documentazione software.

Ogni query è progettata per testare una delle dodici capacità contestuali. I documenti target primari sono intenzionalmente lunghi: 1.061 dei 1.197 documenti target primari distinti hanno almeno 200 frasi, con una lunghezza mediana di circa 6.100 token. Ogni query ha esattamente una risposta corretta nel corpus. Laddove lo stesso fatto è dichiarato più di una volta in un documento d'oro, ad esempio in una frase di riepilogo e in una riga di tabella, una qualsiasi di queste frasi viene accettata come risposta.

Un percorso di risposta è una combinazione valida di un blocco di risposta e delle prove di supporto necessarie per interpretarlo o verificarlo. Tra le 2.099 query, il percorso di risposta del documento target primario ha un gruppo di prove per 964 query, due per 735, tre o più per 332 e nessuno per 68. Percorsi di risposta alternativi validi possono richiedere gruppi di prove diversi.

Tabella 1: Statistiche del benchmark.

Statistica	Valore
Query	2.099
Documenti	38.894
Blocchi di frasi	2.458.072
Lunghezza mediana del documento target primario	6.100 token
Domini	21
Gruppi di prove per query (percorso di risposta del documento target primario)	1: 964; 2: 735; 3+: 332; nessuno: 68

Tabella 2: Dodici capacità contestuali testate da context-bench, con esempi illustrativi.

Capacità	Query di esempio	Blocco di risposta	Contesto di documento richiesto
1. Identità dell'entità	Quanto ha speso Northlake per il riacquisto di azioni?	La società ha riacquistato azioni per 12,8 miliardi di dollari.	L'introduzione identifica Northlake come “la società”. Un analogo rapporto su Southlake non è rilevante.
2. Periodo o versione	Quale cartuccia si adatta alla revisione B di M40?	Installa la cartuccia KC-42.	La sezione di applicabilità afferma che queste istruzioni coprono la revisione B, non la revisione C.
3. Definizioni e alias	Qual è stato il tasso di abbandono per il gruppo da 15 mg?	Zeta ha registrato un tasso di abbandono del 12,7%.	Il rapporto definisce Zeta come il gruppo da 15 mg. Senza tale definizione, il blocco non identifica il gruppo richiesto.
4. Struttura della tabella	Qual è la capacità della batteria del modello Max?	Capacità tipica: 4.250 \| 4.700 \| 5.150.	L'intestazione della tabella stabilisce Mini \| Base \| Max, misurata in mAh. La risposta è quindi 5.150 mAh.
5. Condizioni ed eccezioni	Quanto dura la copertura della batteria per uso commerciale?	La copertura della batteria dura 18 mesi.	Un'introduzione alla sezione limita questa copertura alle installazioni commerciali; le installazioni domestiche hanno una garanzia diversa.
6. Riferimenti e pronomi	Quando è diventata vicesindaco Mara?	Ha assunto l'incarico nel 2021.	La narrazione precedente stabilisce che “lei” si riferisce a Mara, non a Elin, anch'essa menzionata.
7. Ordine e posizione della lista	Quale brano ha aperto il bis?	14. Lantern Road.	Una nota altrove indica che i brani 14–16 costituivano il bis. Il brano 14 è quindi la sua canzone di apertura.
8. Ambito della sezione	Quale obiettivo è stato usato per la cinematografia del film?	È stato usato un obiettivo fisso da 35 mm per tutto il tempo.	Questo passaggio appartiene a “Fotografia principale”, non alla sezione separata sulle fotografie pubblicitarie.
9. Attribuzione del parlante	Quale data di riapertura ha promesso il sindaco?	Riapriremo il 12 giugno.	La trascrizione identifica il sindaco come il parlante. Le stesse parole pronunciate da un appaltatore non stabilirebbero la promessa del sindaco.
10. Modifiche nel tempo	Quale periodo di preavviso si applicava dopo la modifica di maggio?	Il periodo di preavviso è ora di 45 giorni.	La cronologia delle modifiche stabilisce che questo cambiamento è entrato in vigore a maggio, sostituendo la precedente regola di 30 giorni.
11. Relazioni causali	Perché la pompa ovest si è fermata?	Quel guasto ha causato l'arresto.	L'indagine identifica “quel guasto” come un cuscinetto grippato nella pompa ovest e lo distingue da un'ostruzione dell'ingresso non correlata.
12. Significato figurato o interlinguistico	Figurato: Cosa simboleggia “la stanza d'inverno” nella poesia? Interlinguistico: Quale componente l'istruzione in francese dice al tecnico di rimuovere?	Figurato: Rappresenta l'esilio, piuttosto che una stanza fisica. Interlinguistico: Retirez le capot. (Rimuovi il coperchio.)	Figurato: Il commento identifica “esso” come l'immagine ricorrente della “stanza d'inverno” della poesia. Interlinguistico: Il glossario della guida specifica che “capot” indica il cofano protettivo del motore, non il coperchio di spedizione.

Le query, i documenti e le capacità testate sono ispirati da conversazioni con i clienti di turbopuffer.

Per fare un esempio, consideriamo le esigenze di ricerca di una società di gestione immobiliare. Queste società hanno centinaia, a volte migliaia di contratti di locazione che differiscono solo per i nomi degli inquilini, le date e pochi altri dettagli chiave. Una query comune per quel dataset potrebbe essere “quando scade il contratto di affitto di 5 Park Avenue e qual è l'affitto corrente?”. I contratti di locazione possono anche essere lunghi e i componenti critici di disambiguazione che confermerebbero di aver recuperato il documento giusto (come la data, l'indirizzo, il nome dell'inquilino, ecc.) possono spesso essere molto distanti dalla frase di risposta chiave contenente l'importo del pagamento mensile dell'affitto. In pratica, frasi identiche come “L'affitto mensile è di $X,XXX.” possono comparire in molti documenti del corpus.

Un buon modello di embedding contestuale dovrebbe utilizzare il contesto proveniente da tutto il documento per identificare il documento corretto e recuperare sia la risposta che le sue frasi di supporto. Ciò consente a un utente o a un agente di ricerca di verificare rapidamente la risposta e confermare che proviene dal documento giusto.

Per ogni query, etichettiamo le frasi di “risposta” e “prove” nel documento target. Un modello supera il nostro test di “sufficienza per il lettore” se recupera una frase di risposta insieme ad almeno una frase da ciascun gruppo di prove. Insieme, queste frasi forniscono un contesto sufficiente affinché un lettore possa verificare la risposta con le prove di supporto.

Quando i modelli di embedding contestuale fanno questo bene, possono ridurre drasticamente il numero di token che gli agenti di ricerca devono esaminare, oltre a rendere molto più facile per una persona confermare rapidamente di aver individuato la risposta corretta alla sua query originale senza dover leggere l'intero documento.

Ogni gruppo di prove deve essere recuperato, ma una qualsiasi delle alternative di un gruppo è sufficiente per recuperarlo. È comune vedere lo stesso fatto dichiarato in diversi punti di questi lunghi documenti. Il recupero di una sola frase da ciascun gruppo di prove soddisfa i criteri di sufficienza per il lettore e come tale verrebbe accettato come perfetto richiamo delle prove.

Ogni documento è suddiviso in frasi e gli stessi confini vengono utilizzati per tutti i modelli. Vengono testate due condizioni per i modelli di embedding non contestuale: una in cui ciascuna frase viene incorporata in modo indipendente e un'altra in cui l'intero documento viene incorporato come un unico blocco.

Utilizziamo la condizione a livello di frase per misurare il richiamo delle risposte e il richiamo delle prove. Verifica se un modello non contestuale è in grado di identificare la risposta corretta e le prove di supporto quando ciascuna frase viene incorporata senza accesso al documento circostante. Questo è intenzionalmente impegnativo. In molte query, la sola frase di risposta manca dei dettagli necessari per distinguerla da frasi simili altrove nel corpus.

Utilizziamo la condizione a livello di documento come base di riferimento per il richiamo dei documenti. Verifica se gli embedding di frasi granulari forniscono un beneficio di recupero sufficiente a giustificare il loro costo di archiviazione aggiuntivo rispetto all'archiviazione di un vettore per documento. Un indice a livello di frase crea molti più vettori rispetto a un indice a livello di documento, quindi dovrebbe superare la base di riferimento di un vettore per documento per giustificare tale costo.

Tutte le valutazioni utilizzano classificazioni esaustive rispetto a tutti i 2.458.072 blocchi. Le differenze tra i modelli riflettono pertanto le rappresentazioni, non la configurazione dell'indice. Ci concentriamo su tre metriche chiave:

Document@K è definito come:

\text{Document@K}=1[\operatorname{rank}(d^{*})\le K]

dove $d^{*}$ è il documento con il rango più alto in $D_q$ .

Answer@K è definito come:

\text{Answer@K}=1[A_q\cap C_K(q)\ne\varnothing]

dove $C_K(q)$ è il top di $K$ blocchi nell'intero corpus e $A_{q}$ è l'insieme dei blocchi di risposta accettati.

Evidence Recall@K viene misurato all'interno di $d^{*}$ come segue: classifica le frasi di $d^{*}$ per somiglianza, rimuovi la frase di risposta con il rango più alto e sia $R_K(q)$ il top $K$ rimanente. Per i gruppi di prove $G_q=\{g_1,\ldots,g_m\}$ , il gruppo $g_j$ viene recuperato se qualche alternativa $E\in g_j$ soddisfa $E\subseteq R_K(q)$ , e

\text{EvidenceRecall@K}=1[\operatorname{rank}(d^{*})\le10]\cdot\frac{1}{m}\sum_{j=1}^{m}1[g_j\ \text{recovered}].

Document@K chiede se la contestualizzazione consente al documento corretto di superare i fratelli e i distrattori che condividono il suo vocabolario.

Answer@K chiede se la frase di risposta stessa si classifica tra i primi blocchi.

Evidence Recall@K chiede quanto del contesto di supporto viene recuperato tra i primi K blocchi del documento corretto, dopo aver escluso il blocco di risposta con il rango più alto. La rimozione della risposta impedisce al richiamo delle prove di contare due volte ciò che Answer@K misura già e lascia tutti gli slot $K$ per il contesto di supporto. Richiedere che il documento d'oro sia nei primi 10 documenti recuperati significa che nessun modello riceve crediti di prova per un documento che non avrebbe fatto emergere. Riportiamo anche All-Evidence@K, la frazione di query con ogni gruppo recuperato.

Insieme, queste metriche scompongono le sfide affrontate dai modelli di embedding contestuale: trovare il documento giusto, trovare la risposta giusta e recuperare il contesto minimo che dimostra perché la risposta è corretta.

La Figura 3 illustra le metriche con l'esempio della gestione immobiliare.

Come vengono valutati il documento, la risposta e il recupero delle prove di context-bench — Figura 3: Metriche di context-bench illustrate con una query di locazione. Document@K testa il recupero del documento corretto; Answer@K testa il recupero del suo blocco di risposta; Evidence Recall@K misura il recupero dei gruppi di prove di supporto all'interno del documento target. In questo esempio, la verifica dell'affitto richiede le prove sia dell'indirizzo che dell'anno di locazione. Il richiamo delle prove esclude il blocco di risposta principale e richiede che il documento target si collochi tra i primi 10.

Valutiamo il nostro modello rispetto a modelli di embedding contestuali e non contestuali su quattro fronti.

I nostri benchmark di riferimento contestuali sono pplx-embed-context-v1-4B e voyage-context-4. I nostri benchmark di riferimento non contestuali sono voyage-4-large e Nemotron-3-Embed-8B-BF16 di NVIDIA, che codificano i blocchi in modo indipendente. Il set di riferimento varia a seconda dell'esperimento, come indicato in ciascuna figura.

Iniziamo con context-bench, che testa direttamente le capacità che motivano questo lavoro, e poi riportiamo i risultati su ConTEB, il benchmark pubblico standard per gli embedding contestuali. Per verificare che questi guadagni non vadano a scapito della qualità di recupero generale, valutiamo anche benchmark di recupero di documenti e blocchi specifici del dominio che abbiamo costruito da dataset pubblici. Infine, esaminiamo due proprietà pratiche per il deployment: la qualità del recupero rispetto ai costi di archiviazione per vettore e la sensibilità alla dimensione del blocco utilizzata al momento dell'indicizzazione. Tutte le valutazioni codificano documenti fino a 32.768 token in un unico passaggio.

Come mostrato nella Figura 1 nell'introduzione, la nostra anteprima è in testa su Answer@K ed Evidence Recall@K a ogni soglia riportata, così come su All-Evidence@10. A K = 10, raggiunge il 45,5% di richiamo delle risposte, il 40,6% di richiamo delle prove e il 31,1% di richiamo di tutte le prove. È anche in testa su Document@1 e Document@10, raggiungendo rispettivamente il 15,2% e il 61,6%. A K = 10, la nostra anteprima supera voyage-context-4 di 14,4 punti percentuali nel richiamo delle risposte e di 5,0 punti nel richiamo delle prove.

Il nostro modello in anteprima ottiene l'nDCG@10 medio più alto tra i modelli mostrati su ConTEB nella Figura 4. Non è in testa in ogni attività: pplx-context-v1-4B ottiene un punteggio più alto su NarrativeQA, mentre Nemotron-3-8B ottiene il punteggio più alto su COVID-QA. Come hanno sottolineato anche gli autori principali nel documento di ConTEB, COVID-QA include principalmente accoppiamenti query-blocco che sono altamente estrattivi e possono essere soddisfatti con un semplice abbinamento lessicale di superficie su termini medici tecnici. Di conseguenza, la comprensione del contesto è meno utile per questa attività e i modelli non contestuali solitamente superano quelli contestuali.

nDCG a 10 a livello di attività su ConTEB — Figura 4: nDCG@10 a livello di attività su ConTEB nell'impostazione da query a blocco. La media è la media non ponderata tra le otto attività.

Al di là dei benchmark progettati per gli embedding contestuali, valutiamo le prestazioni specifiche del dominio del nostro modello.

La nostra suite da query a blocco (Q2C) utilizza attività MTEB come LegalBench e FinanceBench insieme ad attività di recupero aggiuntive che abbiamo curato da dataset pubblici. All'interno di ciascun documento rilevante, un blocco viene etichettato come rilevante se contiene l'intervallo di risposta esatto quando l'attività ne fornisce uno, e altrimenti tramite un LLM che giudica la sua rilevanza rispetto alla query. La suite da query a documento (Q2D) utilizza le stesse attività e valuta se il documento rilevante viene recuperato.

Il nostro modello ottiene il punteggio medio più alto sul recupero dei blocchi nella Figura 5 e guida nei domini legale, tecnico e sanitario. Non è in testa in ogni dominio: voyage-context-4 ottiene un punteggio più alto nella finanza e nel recupero multilingue, e Nemotron-3-8B ottiene il punteggio più alto nel recupero di conversazioni. Sul recupero dei documenti nella Figura 6, il nostro modello ottiene un punteggio leggermente inferiore a voyage-context-4 in media, pur essendo in testa nel dominio tecnico. Il benchmark di riferimento pplx-context-v1-4B ottiene un punteggio medio inferiore in entrambe le suite, il che è coerente con il fatto di essere stato addestrato solo sul set di addestramento di ConTEB, dimostrando che la supervisione legata ai blocchi d'oro di un benchmark si trasferisce male ad altri domini.

Punteggi di recupero da query a blocco per dominio — Figura 5: nDCG@10 medio sulle attività da query a blocco (Q2C), raggruppate per dominio. Le barre di dominio sono medie non ponderate dei punteggi a livello di attività in quel dominio; la media complessiva è una media non ponderata tra tutte le attività visualizzate.

Punteggi di recupero da query a documento per dominio — Figura 6: Punteggio medio di recupero sulle attività da query a documento (Q2D), raggruppate per dominio. Ogni barra in un dominio è la media non ponderata dei suoi punteggi principali a livello di attività; la media complessiva è una media non ponderata tra tutte le attività visualizzate.

Un modello di embedding contestuale produce un vettore per blocco, quindi un indice costruito con il nostro modello contiene esattamente tanti vettori quanti un indice convenzionale a livello di blocco con la stessa strategia di suddivisione. La contestualizzazione cambia ciò che ciascun vettore codifica, non quanti vettori vengono memorizzati. L'ingombro di archiviazione è quindi governato dalla dimensione di ciascun vettore. Il modello offre due modi per ridurlo: il troncamento dell'embedding da 2048 a 1024 dimensioni e la sua quantizzazione in int8.

La Figura 7 mostra un compromesso favorevole tra la qualità di recupero e l'archiviazione dei vettori. A 1024 dimensioni, i nostri embedding int8 utilizzano 1 KB per vettore superando leggermente il punteggio di recupero dei blocchi di voyage-context-4 a 2048 dimensioni in float32, che utilizza 8 KB per vettore. Aumentare la dimensione del nostro embedding a 2048 dimensioni migliora ulteriormente la qualità di recupero a 2 KB per vettore. Questi dati di archiviazione si riferiscono ai soli vettori, non al resto dell'indice.

Qualità di recupero dei blocchi rispetto all'archiviazione per vettore — Figura 7: Qualità di recupero dei blocchi (nDCG@10 medio) in funzione dell'archiviazione per vettore. Le linee continue denotano float32 e le linee tratteggiate denotano int8; le etichette indicano la dimensione dell'embedding.

La Figura 8 mostra solo una modesta variazione nella qualità di recupero all'aumentare della dimensione del blocco da 64 a 512 token: il punteggio medio scende dall'81,0% al 79,9%, una diminuzione di 1,1 punti percentuali. Ciò suggerisce che il modello rimane efficace attraverso le dimensioni dei blocchi testate, offrendo alle pipeline di indicizzazione flessibilità nel modo in cui i documenti vengono suddivisi.

Sensibilità alla dimensione del blocco: punteggi di recupero per blocchi da 64 a 512 token — Figura 8: Sensibilità alla dimensione del blocco del nostro modello. Ogni punto è l'nDCG@10 medio non ponderato su 74 attività MTEB, con documenti indicizzati alla data dimensione del blocco.

turbopuffer mantiene l'intero corpus, le query e le etichette di context-bench private e riporta i risultati per i modelli inviati. Un benchmark pubblico di questo tipo invita all'addestramento diretto sulle sue query e sui suoi documenti, il che lo saturerebbe gradualmente e ne ridurrebbe il valore per monitorare i progressi nel tempo. Se desideri che il tuo modello venga valutato sul benchmark, contatta turbopuffer all'indirizzo contextbench@turbopuffer.com.

Un'anteprima del nostro modello è disponibile su Hugging Face e tutti i risultati in questo post sono riportati per questa anteprima. Stiamo lavorando per rendere il modello disponibile tramite l'API di Perplexity e per migliorare ulteriormente il recupero su documenti lunghi insieme a turbopuffer.

BibTeX

@online{perplexity2026ContextualEmbeddingBeyondTheGoldPassage,
  author = {{Perplexity} and Sarah Eslami and William Barber and Markus Krimmel and Antoine Chaffin and Bo Wang and Louis Milliken and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Contextual embedding beyond the gold passage}},
  date = {2026-09-30},
  url = {https://www.perplexity.ai/hub/blog/contextual-embedding-beyond-the-gold-passage}
}

Introduzione

Perché il contesto è importante per il recupero

I limiti della supervisione dei blocchi d'oro

Un nuovo approccio all'apprendimento contestuale

Funzione di perdita

Perdita contrastiva a livello di documento

Perdita di distillazione a livello di blocco

Perdita combinata

Dati di addestramento

Configurazione dell'addestramento

Un nuovo benchmark per il recupero a livello di blocco

Documenti e query

Etichette di risposta e prove

Metriche

Risultati della valutazione

Context-bench

ConTEB

Qualità di recupero generale tra i domini

Qualità di recupero e costi di archiviazione

Sensibilità alla dimensione del blocco

Rilascio

Citazione