Kontextové vkládání za hranicemi zlaté pasáže

Kontextová vkládání zachycují význam každé pasáže nebo chunku v kontextu celého dokumentu. Jejich trénování a vyhodnocování obvykle předpokládá jediný relevantní chunk na dotaz, známý jako „zlatá pasáž“. Zlatá pasáž však v praxi často nestačí. Může sice obsahovat odpověď, ale postrádat podpůrný kontext potřebný k jejímu pochopení nebo ověření, čímž zůstává v izolaci nejednoznačná.

Představujeme pplx-embed-v2-context-9b-preview, náš nový model kontextového vkládání. Model je trénován novým přístupem, který jako učitele využívá model komprese kontextu od Perplexity. Jeho předpovědi na úrovni tokenů agregujeme do skóre relevance na úrovni chunků a učíme model vkládání získávat jak chunky s odpovědí, tak podpůrný kontext namísto jediného zlatého chunku. Model vytvoří jedno vkládání na chunk bez dodatečných nákladů na inferenci a podporuje 1024dimenzionální a int8 vkládání.

Dosahuje špičkových výsledků na context-bench, což je nový benchmark pro kontextově uvědomělé vyhledávání vytvořený a soukromě spravovaný společností turbopuffer, a na ConTEB, což je široce používaný veřejný benchmark. Náš model byl vyvinut nezávisle na context-bench a vyhodnocen jako slepé odeslání.

Context-bench se skládá z 2 099 dotazů nad 38 894 dlouhými dokumenty ve 21 doménách a vyhodnocuje tři schopnosti kontextových vkládání: rozlišení dokumentů mezi téměř totožnými dokumenty, vyhledávání zlatých chunků, jejichž význam závisí na vzdáleném kontextu, a vybavení podpůrných důkazů nezbytných k ověření odpovědi.

Náhled modelu je veřejně dostupný na Hugging Face. Benchmark je soukromě spravován společností turbopuffer za účelem snížení rizika tréninkové kontaminace a zachování jeho hodnoty pro měření pokroku. Chcete-li požádat o vyhodnocení, kontaktujte prosím společnost turbopuffer na adrese contextbench@turbopuffer.com.

Výsledky vyhledávání dokumentů, odpovědí a důkazů v context-bench — Obrázek 1: Answer@K, Document@K, Evidence Recall@K a All-Evidence@10 na context-bench, porovnávající Perplexity v2 preview 9B s Voyage Context 4, Voyage 4 Large a Perplexity context v1 4B.

Vyhledávací systémy obvykle dělí dlouhé dokumenty na menší chunky, které lze indexovat a prohledávat nezávisle. Rozdělování na chunky je v praxi pohodlné, ale odstraňuje kontext, ve kterém se každý chunk původně objevil, čímž vytváří kompromis mezi granularitou komprese informací a kontextem použitým během kódování. Chunk může odkazovat na dříve zavedený subjekt, přebírat svůj význam z nadpisu oddílu nebo spoléhat na definice umístěné jinde v dokumentu. Po vyjmutí již nemusí obsahovat dostatek informací pro spolehlivé spárování s dotazem. Zakódování celého dokumentu jako jediného vektoru toto neřeší, protože jedna sdružená reprezentace nedokáže věrně zachytit každou stránku dlouhého dokumentu.

Modely kontextového vkládání řeší toto omezení tím, že reprezentují každý chunk v kontextu jeho okolního obsahu, nejčastěji prostřednictvím pozdního chunkování (late chunking): dokument je kódován v jediném průchodu a reprezentace chunků jsou následně seskupeny (pooled), takže každý vektor chunku se počítá tak, že je vidět celý dokument. Předchozí práce, jako například ConTEB a naše vlastní pplx-embed-context-v1, ukázaly, že kontextualizované reprezentace chunků podstatně zlepšují vyhledávání oproti nezávisle kódovaným chunkům, zejména u dlouhých dokumentů.

Trénování modelů kontextového vkládání vyžaduje dohled, který identifikuje, které části dokumentu jsou relevantní pro daný dotaz. Běžným přístupem jsou anotace zlatých chunků: pro každý dotaz anontátor, obvykle velký jazykový model (LLM), identifikuje ten chunk dokumentu, který na něj odpovídá.

Trénování obvykle kombinuje dvě kontrastní ztráty (contrastive losses): ztrátu mezi dokumenty, která staví zlatý chunk do kontrastu s chunky z jiných dokumentů, a ztrátu v rámci dokumentu, která jej staví do kontrastu s ostatními chunky ve stejném dokumentu.

Tento přístup má několik omezení:

Pouze jeden chunk je relevantní. Zachází s každým dalším chunkem v dokumentu jako s negativním, včetně těch s užitečnými podpůrnými informacemi. Dohled na úrovni dokumentu funguje na opačném extrému. Identifikuje dokument jako relevantní, aniž by specifikoval, které chunky v něm jsou důležité. V praxi relevance často leží mezi těmito extrémy. Chunk nesoucí odpověď může záviset na několika podpůrných sencích, které představují subjekt, rozřeší odkaz nebo poskytnou doplňující fakt, zatímco zbytek dokumentu je irelevantní. Model se tak musí naučit správnou úroveň selektivity: širší než jeden zlatý chunk, ale zaměřenější než dokument jako celek.
Hrubý dohled. Vzhledem k tomu, že každá anotace identifikuje jediný zlatý chunk namísto zachycení stupňů relevance napříč dokumentem, poskytuje omezené trénovací signály vzhledem k množství výpočetního výkonu vynaloženého na její vytvoření.
Nákladné škálování. Každý trénovací pár vyžaduje, aby LLM přečetl dokument a vybral relevantní chunk, takže náklady na anotaci rostou lineárně s velikostí trénovací sady a omezují to, jak velká a jak rozmanitá mohou trénovací data být.
Citlivost na hranice chunků. Štítky jsou rovněž vázány na hranice chunků použité během anotace. Zlatý štítek přiřazený pevnému oknu o velikosti tokenů nespecifikuje, které kratší věty nebo delší odstavce jsou relevantní. Změna strategie tvorby chunků nebo trénování napříč vícero způsoby chunkování pro zlepšení robustnosti vůči tomu, jak jsou dokumenty rozdělovány v době indexování, tak může vyžadovat opětovnou anotaci korpusu.

Omezení dohledu zlatého chunku řešíme destilací hodnocení relevance z modelu komprese kontextu s vědomím dotazu. Tento model slouží jako učitel: čte dotaz i dokument společně a každému tokenu dokumentu přiřazuje skóre relevance. Jeho předpovědi nabízejí několik výhod pro trénování kontextových vkládání:

Flexibilní hranice chunků. Skóre relevance na úrovni tokenů lze agregovat nad libovolnými zvolenými hranicemi chunků, což umožňuje, aby tytéž předpovědi učitele dohlížely na různé chunkování bez nutnosti opětovné anotace.
Kontinuální relevance. Na rozdíl od binárních štítků zlatých chunků poskytuje učitel kontinuální skóre, která zachycují stupně relevance přirozeně rozlišující chunky nesoucí odpověď, podpůrný kontext a irelevantní obsah.
Nižší náklady na anotaci. Učitel je kompaktní a specializuje se na bodování relevance, díky čemuž je jeho dohled ve velkém měřítku mnohem levnější než u univerzálního LLM.

Náš model trénujeme pomocí váženého součtu kontrastní ztráty na úrovni dokumentu a destilační ztráty na úrovni chunku nad dávkami párů dotaz-dokument. Pro každý dotaz slouží spárovaný dokument jako pozitivní, zatímco zbývající dokumenty ve stejné dávce slouží jako negativní.

Pro každou dávku náhodně vybereme strategii tvorby chunků, podle toho rozdělíme dokumenty a mezi chunky vložím oddělovací tokeny. Poté každý dokument zpracujeme v jediném průchodu a zprůměrujeme reprezentace tokenů v rámci každého chunku, abychom získali kontextová vkládání chunků. Dotazy jsou kódovány zvlášť, přičemž se provádí zprůměrování jejich reprezentací tokenů. Nakonec spočítáme kosinovou podobnost mezi každým vkládáním dotazu a každým vkládáním chunku v dávce.

Zatímco náš model vkládání produkuje pouze podobnosti na úrovni chunků, můžeme z nich přirozeně odvodit podobnosti na úrovni dokumentů. Považujeme dokument d za stejně relevantní pro dotaz q jako jeho nejrelevantnější chunk. Toto pravidlo bodování je inspirováno operací MaxSim modelu ColBERT, která je zde aplikována na chunky namísto tokenů.

Konkrétně pro daný dotaz q s vkládáním q a dokument d jako uspořádaný seznam chunků c s vkládáními c definujeme podobnost na úrovni dokumentu jako:

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

S ohledem na tyto podobnosti na úrovni dokumentů můžeme formulovat cíl InfoNCE na úrovni dokumentů nad vnitro-dávkovými negativy.

Pro dotaz q nechte d⁺ označovat jeho relevantní dokument a 𝒟 dokumenty v dávce. Kontrastní ztráta je následující (teploty jsou pro přehlednost vynechány):

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

Kontrastní ztráta učí model, který dokument je relevantní pro dotaz. Destilační ztráta ho učí, kde v daném dokumentu leží relevance, což je pro kontextový model zásadní.

Během trénování předáváme každý pozitivní pár dotaz-dokument našemu modelu komprese kontextu, který přiřazuje skóre relevance každému tokenu v dokumentu. Stejně jako u bodování na úrovni dokumentů odvozujeme relevanci každého chunku z jeho nejrelevantnějšího obsahu. Abychom snížili citlivost na odlehlé tokeny, včetně těch na hranicích chunků, definujeme relevanci na úrovni chunku jako průměr n nejlepších skóre tokenů v rámci chunku.

Pro každý dotaz aplikujeme softmax škálovaný teplotou na skóre relevance chunků učitele v rámci pozitivního dokumentu, abychom získali cílové rozdělení. Chunky v ostatních dokumentech v dávce obdrží nulovou cílovou pravděpodobnost. Model vkládání učíme tak, aby odpovídal tomuto cíli minimalizací dopředné Kullbackovy-Leiblerovy divergence (KL divergence) mezi cílem a jeho předpokládaným rozdělením nad všemi chunky v dávce:

\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)}

Zde horní indexy T a S označují učitele a studenta a rⱼ je skóre relevance učitele pro chunk cⱼ v pozitivním dokumentu d⁺. Cílové rozdělení učitele přiřazuje nulovou pravděpodobnost chunkům ve všech ostatních dokumentech v dávce.

Na rozdíl od jediného štítku zlatého chunku zachycuje tento cíl stupně relevance. Podpůrné chunky získávají váhu podle skóre učitele namísto toho, aby byly považovány za negativní, což model učí získávat jak podpůrný kontext, tak odpověď.

Náš kombinovaný trénovací cíl je váženým součtem kontrastní ztráty na úrovni dokumentu a destilační ztráty na úrovni chunku. Tuto váženou ztrátu zprůměrováváme přes dávku párů dotaz-dokument.

Obrázek 2 ilustruje náš trénovací přístup. Kompresor kontextu slouží jako učitel pouze během trénování. V době inference produkuje model vkládání jedno kontextové vkládání na chunk, bez dodatečné komprese nebo fázování přerovnávání. Tento přístup zlepšuje způsob, jakým se kontextová vkládání učí, aniž by se zvyšovalo úložiště indexu nebo se přidávala latence učitelského modelu v době vyhledávání.

Trénovací nastavení pro destilaci kontextového vkládání — Obrázek 2: Trénovací nastavení našeho modelu. Kontextový kodér (student, vlevo) zpracovává dokumenty, z nichž každý se skládá z několika chunků. Každý chunk je vložen s ohledem na okolní kontext dokumentu. Dotaz A je známá shoda pro dokument A a je hodnocen proti chunkům všech dokumentů za účelem získání předpokládaných podobností. Tato skóre na úrovni chunků jsou seskupena max-poolingem na skóre na úrovni dokumentů. Trénujeme předpovědi na úrovni chunků a předpovědi na úrovni dokumentů tak, aby odpovídaly cílovým rozdělením (vpravo). Cíl na úrovni chunku se vypočítá v době trénování jako předpověď kompresoru kontextu v rámci známého relevantního dokumentu a je nastaven na nulu v rámci známých irelevantních dokumentů. Cílové rozdělení na úrovni dokumentu je nastaveno jako one-hot na známém relevantním dokumentu.

Trénovací data se skládají z přibližně 430 veřejných a interních datových sad dotazů a dokumentů pokrývajících více než 50 jazyků.

Interní datové sady párů vytváříme z produkčních dat filtrovaných na osobní údaje (PII) a syntetizováním relevantních dotazů nad dlouhými dokumenty. Pro každý průchod vpřed vybereme jednu datovou sadu a vzorkujeme z ní celou dávku, abychom zvýšili obtížnost vnitro-dávkových negativů a zamezili učení zkratkami. Žádná z našich trénovacích datových sad neobsahuje anotace na úrovni chunků: veškerý dohled v rámci dokumentu pochází z kompresního modelu a pro trénování se nepoužívají žádná data ConTEB. Během vývoje modelu navíc nebyla k dispozici žádná data z benchmarku context-bench.

Model vychází z interního 9miliardového (9B) vyhledávacího modelu ColBERT a vytváří 2048dimenzionální vkládání prostřednictvím lineární projekční vrstvy. Hranice chunků označujeme naučeným tokenem <|chunk_sep|> a každé vkládání chunku tvoříme zprůměrováním jeho vkládání tokenů. Dotazy jsou kódovány stejným modelem, přičemž jejich vkládání tokenů jsou zprůměrována do jediného vektoru.

Používáme Matryoshka trénování pro podporu 1024dimenzionálních i 2048dimenzionálních vkládání a trénování zohledňující kvantování pro podporu nativních int8 vkládání. Během trénování postupně zvyšujeme rychlost učení, držíme ji na konstantní hodnotě a poté ji snižujeme.

Vydaný model je model soup, který zprůměrovává váhy několika kontrolních bodů ze stejného trénovacího běhu.

Veřejné benchmarky kontextového vyhledávání, jako je ConTEB, sdílejí předpoklad na pozadí dohledu zlatého chunku: každý dotaz má jediný relevantní chunk a model je odměněn pouze za to, že tento chunk umístí na první místo. Rovněž přebírají jeho omezení.

Za prvé, ConTEB testuje vyhledávání u úloh, kde je chunk nejednoznačný bez okolního kontextu. V těchto úlohách kontextové modely překonaly modely, které kódují každý chunk nezávisle. Nezkoumá však, zda model vynese na povrch také ostatní části dokumentu, díky nimž je chunk srozumitelný.

Za druhé, systematicky netestuje, zda lze nalézt správný dokument, když se téměř identické dokumenty v témže korpusu liší pouze kontextem obklopujícím jinak totožnou větu.

Obě tyto schopnosti hrají roli, když vyhledávací agent nebo uživatel potřebuje pochopit a ověřit odpověď z několika získaných vět namísto celého dokumentu. Proto jsme vytvořili context-bench, kontrolovaný benchmark pro vyhledávání v dlouhých dokumentech, navržený tak, aby odlišil využití kontextu dokumentu od celkové kvality vyhledávání. Testuje, zda kontextová vkládání využívají informace z jiných částí dokumentu na podporu tří schopností:

Rozlišení dokumentů: Identifikace správného dokumentu mezi téměř identickými alternativami.
Vyhledání odpovědí: Vyhledání chunků obsahujících odpověď, jejichž význam závisí na detailech jinde v dokumentu.
Vyhledání důkazů: Vyhledání podpůrných chunků, které objasňují nebo podkládají odpověď.

Context-bench obsahuje 2 099 dotazů a 38 894 dokumentů. Používají se chunky o délce vět, což dává celkem 2 458 072 chunků. Dotazy pokrývají 21 domén včetně firemních dokumentů, klinického výzkumu, cestování, zábavy, vzdělávání, státní správy, právních smluv a softwarové dokumentace.

Každý dotaz je navržen tak, aby otestoval jednu z dvanácti kontextových schopností. Primární cílové dokumenty jsou záměrně dlouhé: 1 061 z 1 197 odlišných primárních cílových dokumentů má alespoň 200 vět, přičemž medián délky je přibližně 6 100 tokenů. Každý dotaz má v korpusu právě jednu správnou odpověď. Pokud je stejná skutečnost ve zlatém dokumentu uvedena více než jednou, například v souhrnné větě a řádku tabulky, kterákoli z těchto vět je akceptována jako odpověď.

Trasa odpovědi představuje platnou kombinaci chunku s odpovědí a podpůrných důkazů potřebných k její interpretaci nebo ověření. Napříč 2 099 dotazy má trasa odpovědi primárního cílového dokumentu jednu skupinu důkazů u 964 dotazů, dvě u 735, tři nebo více u 332 a žádnou u 68. Alternativní platné trasy odpovědi mohou vyžadovat jiné skupiny důkazů.

Tabulka 1: Statistika benchmarku.

Statistika	Hodnota
Dotazy	2 099
Dokumenty	38 894
Chunky vět	2 458 072
Medián délky primárního cílového dokumentu	6 100 tokenů
Domény	21
Skupiny důkazů na dotaz (trasa odpovědi primárního cílového dokumentu)	1: 964; 2: 735; 3+: 332; žádné: 68

Tabulka 2: Dvanáct kontextových schopností testovaných benchmarkem context-bench, včetně názorných příkladů.

Schopnost	Příklad dotazu	Část s odpovědí	Požadovaný kontext dokumentu
1. Identita subjektu	Kolik utratila společnost Northlake za zpětný odkup akcií?	Společnost zpětně odkoupila akcie v hodnotě 12,8 miliardy dolarů.	Úvod identifikuje společnost Northlake jako „společnost“. Podobná zpráva týkající se společnosti Southlake není relevantní.
2. Období nebo verze	Která cartridge pasuje do revize B modelu M40?	Nainstalujte cartridge KC-42.	Oddíl o použitelnosti uvádí, že tyto pokyny se týkají revize B, nikoli revize C.
3. Definice a aliasy	Jakou míru vysazení měla 15mg skupina?	Skupina Zeta měla míru vysazení 12,7 %.	Zpráva definuje skupinu Zeta jako 15mg skupinu. Bez této definice část požadovanou skupinu neidentifikuje.
4. Struktura tabulky	Jakou kapacitu baterie má model Max?	Typická kapacita: 4 250 \| 4 700 \| 5 150.	Záhlaví tabulky stanovuje Mini \| Base \| Max v mAh. Odpověď je proto 5 150 mAh.
5. Podmínky a výjimky	Jak dlouho trvá záruka na baterii pro komerční použití?	Záruka na baterii trvá 18 měsíců.	Úvod oddílu omezuje tuto záruku na komerční instalace; domácí instalace mají jinou záruku.
6. Odkazy a zájmena	Kdy se Mara stala zástupkyní starosty?	Únory se ujala v roce 2021.	Předchozí vyprávění uvádí, že „ona“ označuje Maru, nikoli Elin, o níž se rovněž hovoří.
7. Pořadí v seznamu a pozice	Která písnička zahájila přídavek?	14. Lantern Road.	Poznámka jinde uvádí, že přídavek tvořily skladby 14–16. Skladba 14 je proto úvodní písní přídavku.
8. Rozsah oddílu	Který objektivem byl natočen film?	Celou dobu byl používán pevný objektiv 35 mm.	Tato pasáž spadá do oddílu „Hlavní natáčení“, nikoli do samostatné části věnované propagačním fotografiím.
9. Přisouzení mluvčímu	Jaké datum znovuotevření starosta slíbil?	Znovu otevřeme 12. června.	Přepis identifikuje mluvčího jako starostu. Stejná slova od dodavatele by starostův slib nedokládala.
10. Změny v čase	Jaká výpovědní lhůta platila po květnovém dodatku?	Výpovědní lhůta nyní činí 45 dní.	Historie dodatků dokládá, že tato změna vstoupila v platnost v květnu a nahradila dřívější 30denní pravidlo.
11. Příčinné souvislosti	Proč se západní čerpadlo zastavilo?	Odstávku způsobila tato závada.	Vyšetřování označuje „tuto závadu“ za zadřené ložisko v západním čerpadle a odlišuje ji od nesouvisející překážky na vstupu.
12. Přenášený nebo mezijazykový význam	Přenášený význam: Co symbolizuje „zimní místnost“ v básni? Mezijazykový význam: Kterou součástku má technik podle francouzského pokynu demontovat?	Přenášený význam: Představuje exil, nikoli fyzickou místnost. Mezijazykový význam: Retirez le capot. (Sejměte kryt.)	Přenášený význam: Komentář označuje „to“ za opakující se obraz „zimní místnosti“ v básni. Mezijazykový význam: Glosář v příručce upřesňuje, že „capot“ znamená ochranný kryt motoru, nikoli přepravní kryt.

Dotazy, dokumenty a testované schopnosti jsou inspirovány rozhovory se zákazníky společnosti turbopuffer.

Jako příklad uveďme potřeby vyhledávání správcovské společnosti. Tyto společnosti mají stovky, někdy tisíce nájemních smluv, které se liší pouze jmény nájemců, daty a několika dalšími klíčovými detaily. Běžným dotazem pro tuto datovou sadu může být „kdy končí nájem pro 5 Park Avenue a jaké je aktuální nájemné?“. Nájemní smlouvy mohou být také dlouhé a kritické rozlišující složky, které by potvrdily, že jste nalezli správný dokument (jako je datum, adresa, jméno nájemce atd.), se často mohou nacházet velmi daleko od věty s klíčovou odpovědí obsahující výši měsíčního nájemného. V praxi se identické věty typu „Měsíční nájemné činí X XXX USD.“ mohou objevovat v mnoha dokumentech v korpusu.

Kvalitní model kontextového vkládání by měl využívat kontext z celého dokumentu k identifikaci správného dokumentu a získání jak odpovědi, tak jejích podpůrných vět. To umožňuje uživateli nebo vyhledávacímu agentovi rychle ověřit odpověď a potvrdit, že pochází ze správného dokumentu.

Pro každý dotaz označíme věty s „odpovědí“ a „důkazem“ v cílovém dokumentu. Model projde naším testem „dostatečnosti pro čtenáře“, pokud získá větu s odpovědí společně s alespoň jednou větou z každé skupiny důkazů. Tyto věty společně poskytují dostatečný kontext, aby čtenář mohl ověřit odpověď s podporou důkazů.

Pokud modely kontextového vkládání odvádějí tuto práci dobře, mohou dramaticky snížit počet tokenů, které vyhledávací agenti potřebují zkontrolovat, a také výrazně usnadnit člověku rychlé potvrzení, že nalezl správnou odpověď na svůj původní dotaz, aniž by musel číst celý dokument.

Každá skupina důkazů musí být získána, ale k jejímu získání stačí kterákoli z alternativ skupiny. V těchto dlouhých dokumentech je běžné, že je tatáž skutečnost uvedena na několika místech. Získání jediné věty z každé skupiny důkazů splňuje kritéria dostatečnosti pro čtenáře, a proto by bylo akceptováno jako dokonalé vybavení důkazů.

Každý dokument je rozdělen na věty (chunky) a pro všechny modely se používají stejné hranice. U nekontextových modelů vkládání se testují dvě podmínky: jedna, kde je každá věta vložena nezávisle, a druhá, kde je celý dokument vložen jako jeden chunk.

Podmínku na úrovni vět používáme k měření vybavení odpovědí a vybavení důkazů. Testuje, zda nekontextový model dokáže identifikovat správnou odpověď a podpůrné důkazy, když je každá věta vložena bez přístupu k okolnímu dokumentu. To je záměrně náročné. U mnoha dotazů samotná věta s odpovědí postrádá detaily potřebné k jejímu odlišení od podobných vět jinde v korpusu.

Podmínku na úrovni dokumentů používáme jako výchozí hodnotu (baseline) pro vybavení dokumentů. Testuje, zda jemnozrnná vkládání vět poskytují dostatečnou přidanou hodnotu při vyhledávání, která by odůvodnila jejich dodatečné náklady na úložiště oproti uložení jednoho vektoru na dokument. Index na úrovni vět vytvoří podstatně více vektorů než index na úrovni dokumentů, takže by měl překonat výchozí hodnotu jednoho vektoru na dokument, aby tyto náklady obhájil.

Všechna vyhodnocení využívají vyčerpávající řazení (exhaustive rankings) proti všem 2 458 072 chunkům. Rozdíly mezi modely tak odrážejí reprezentace, nikoli konfiguraci indexu. Zaměřujeme se na tři klíčové metriky:

Document@K je definováno jako:

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

kde $d^{*}$ je dokument s nejvyšším hodnocením v $D_q$ .

Answer@K je definováno jako:

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

kde $C_K(q)$ představuje $K$ nejlepších chunků v celém korpusu a $A_{q}$ je množina přijatých chunků s odpovědí.

Evidence Recall@K se měří v rámci $d^{*}$ následovně: Seřaďte věty z $d^{*}$ podle podobnosti, odstraňte větu s odpovědí s nejvyšším hodnocením a nechte $R_K(q)$ představovat $K$ nejlepších ze zbývajících. Pro skupiny důkazů $G_q=\{g_1,\ldots,g_m\}$ je skupina $g_j$ získána, pokud nějaká alternativa $E\in g_j$ splňuje $E\subseteq R_K(q)$ a

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

Document@K zjišťuje, zda kontextualizace umožňuje správnému dokumentu předčit sourozence a distraktory, které sdílejí jeho slovní zásobu.

Answer@K zjišťuje, zda se samotná věta s odpovědí řadí mezi nejlepší chunky.

Evidence Recall@K se ptá, kolik z podpůrného kontextu je získáno mezi K nejlepšími chunky správného dokumentu po vyloučení chunku s odpovědí s nejvyšším hodnocením. Odstranění odpovědi brání tomu, aby vybavení důkazů započítávalo dvakrát to, co již měří Answer@K, a ponechává všechny pozice $K$ pro podpůrný kontext. Požadavek, aby se zlatý dokument nacházel mezi 10 nejlépe vyhledanými dokumenty, znamená, že žádný model nezíská kredity za důkazy u dokumentu, který by jinak nevynesl na povrch. Rovněž uvádíme All-Evidence@K, což je podíl dotazů se všemi získanými skupinami.

Tyto metriky dohromady rozkládají výzvy, kterým čelí modely kontextových vkládání: nalézt správný dokument, nalézt správnou odpověď a obnovit minimální kontext, který ukazuje, proč je odpověď správná.

Obrázek 3 ilustruje metriky na příkladu správy nemovitostí.

Jak se hodnotí vyhledávání dokumentů, odpovědí a důkazů v context-bench — Obrázek 3: Metriky context-bench ilustrované na dotazu k nájemní smlouvě. Document@K testuje vyhledávání správného dokumentu; Answer@K testuje vyhledávání jeho chunku s odpovědí; Evidence Recall@K měří obnovení skupin podpůrných důkazů v rámci cílového dokumentu. V tomto příkladu vyžaduje ověření nájemného důkazy o adrese i roce nájmu. Vybavení důkazů vylučuje špičkový chunk s odpovědí a vyžaduje, aby se cílový dokument umístil v top 10.

Náš model vyhodnocujeme v porovnání s kontextovými a nekontextovými modely vkládání na čtyřech frontách.

Naše kontextové modely (baselines) jsou pplx-embed-context-v1-4B a voyage-context-4. Naše nekontextové modely jsou voyage-4-large a Nemotron-3-Embed-8B-BF16 od společnosti NVIDIA, které kódují chunky nezávisle. Sada modelů pro porovnání se liší podle experimentu, jak je naznačeno v každém obrázku.

Začínáme s benchmarkem context-bench, který přímo testuje schopnosti motivující tuto práci, a poté uvádíme výsledky na ConTEB, což je standardní veřejný benchmark pro kontextová vkládání. Abychom ověřili, že tyto přínosy nejsou vykoupeny úkor celkové kvality vyhledávání, vyhodnocujeme také doménově specifické benchmarky vyhledávání dokumentů a chunků, které jsme sestavili z veřejných datových sad. Nakonec zkoumáme dvě praktické vlastnosti pro nasazení: kvalitu vyhledávání oproti nákladům na úložiště na jeden vektor a citlivost na velikost chunku použitou v době indexování. Všechna vyhodnocení kódují dokumenty o délce až 32 768 tokenů v jediném průchodu.

Jak ukazuje obrázek 1 v úvodu, náš náhled vede v metrikách Answer@K a Evidence Recall@K při každém uváděném řezu (cutoff) a rovněž v All-Evidence@10. Při K = 10 dosahuje 45,5% úspěšnosti vybavení odpovědí, 40,6% vybavení důkazů a 31,1% vybavení všech důkazů. Vede také v Document@1 a Document@10, kde dosahuje 15,2 %, resp. 61,6 %. Při K = 10 náš náhled překonává model voyage-context-4 o 14,4 procentního bodu ve vybavení odpovědí a o 5,0 bodů ve vybavení důkazů.

Náš náhledový model dosahuje nejvyššího průměrného nDCG@10 mezi modely zobrazenými na ConTEB na obrázku 4. Nevede v každém úkolu: pplx-context-v1-4B skóruje lépe v NarrativeQA, zatímco Nemotron-3-8B skóruje nejlépe v COVID-QA. Jak hlavní autoři rovněž poukázali v článku o ConTEB, COVID-QA zahrnuje převážně párování dotazů a chunků, které je vysoce extraktivní a lze jej uspokojit jednoduchým povrchovým lexikálním srovnáním technických lékařských termínů. V důsledku toho je pochopení kontextu pro tento úkol méně užitečné a nekontextové modely obvykle ty kontextové překonávají.

nDCG na úrovni úkolů při 10 na ConTEB — Obrázek 4: nDCG@10 na úrovni úkolů na ConTEB v nastavení dotazu na chunk. Průměr je nevážený průměr napříč osmi úkoly.

Nad rámec benchmarků určených pro kontextová vkládání posuzujeme doménově specifický výkon našeho modelu.

Naše sada dotazů na chunk (Q2C) využívá úlohy MTEB, jako jsou LegalBench a FinanceBench, spolu s dalšími vyhledávacími úoly, které jsme vybrali z veřejných datových sad. V rámci každého relevantního dokumentu je chunk označen jako relevantní, pokud obsahuje přesný rozsah odpovědi, pokud jej úloha poskytuje, jinak je označen LLM posuzujícím jeho relevanci k dotazu. Sada dotazů na dokument (Q2D) využívá stejné úkoly a hodnotí, zda je získán relevantní dokument.

Náš model dosahuje nejvyššího průměrného skóre při vyhledávání chunků na obrázku 5 a vede v právní, technické a zdravotnické doméně. Nevede v každé doméně: voyage-context-4 skóruje lépe ve financích a multilingvním vyhledávání a Nemotron-3-8B skóruje nejlépe ve vyhledávání konverzací. Při vyhledávání dokumentů na obrázku 6 skóruje náš model v průměru mírně pod voyage-context-4, přičemž vede v technické doméně. Výchozí model pplx-context-v1-4B skóruje v průměru hůře v obou sadách, což odpovídá tomu, že byl trénován pouze na trénovací sadě ConTEB, což ukazuje, že dohled vázaný na zlaté chunky jednoho benchmarku se do jiných domén přenáší špatně.

Skóre vyhledávání dotazů na chunk podle domény — Obrázek 5: Průměrné nDCG@10 v úlohách dotazu na chunk (Q2C), seskupené podle domény. Sloupce domén jsou nevážené průměry skóre na úrovni úkolů v dané doméně; celkový průměr je nevážený průměr napříč všemi zobrazenými úkoly.

Skóre vyhledávání dotazů na dokument podle domény — Obrázek 6: Průměrné skóre vyhledávání v úlohách dotazu na dokument (Q2D), seskupené podle domény. Každý sloupec v doméně představuje nevážený průměr jeho hlavních skóre na úrovni úkolů; celkový průměr je nevážený průměr napříč všemi zobrazenými úkoly.

Model kontextového vkládání vytváří jeden vektor na chunk, takže index vytvořený s naším modelem obsahuje přesně tolik vektorů jako konvenční index na úrovni chunků se stejnou strategií tvorby chunků. Kontextualizace mění to, co každý vektor kóduje, nikoliv kolik vektorů je uloženo. Velikost úložiště se proto řídí velikostí každého vektoru. Model nabízí dva způsoby, jak ji snížit: oříznutí vkládání z 2048 na 1024 dimenzí a jeho kvantování do int8.

Obrázek 7 ukazuje příznivý kompromis mezi kvalitou vyhledávání a úložištěm vektorů. Při 1024 dimenzích využívají naše int8 vkládání 1 KB na vektor, přičemž mírně překonávají skóre vyhledávání chunků u voyage-context-4 při 2048 dimenzích ve float32, což zabírá 8 KB na vektor. Zvětšení velikosti našeho vkládání na 2048 dimenzí dále zvyšuje kvalitu vyhledávání při 2 KB na vektor. Tyto údaje o úložišti se týkají pouze samotných vektorů, nikoli zbytku indexu.

Kvalita vyhledávání chunků oproti úložišti na jeden vektor — Obrázek 7: Kvalita vyhledávání chunků (průměrné nDCG@10) jako funkce úložiště na jeden vektor. Plné čáry označují float32 a čárkované čáry označují int8; popisky udávají dimenzi vkládání.

Obrázek 8 ukazuje jen mírnou změnu v kvalitě vyhledávání při zvětšení velikosti chunku ze 64 na 512 tokenů: průměrné skóre klesá z 81,0 % na 79,9 %, což představuje pokles o 1,1 procentního bodu. To naznačuje, že model zůstává účinný napříč testovanými velikostmi chunků, což indexovacím kanálům poskytuje flexibilitu v tom, jak jsou dokumenty rozdělovány.

Citlivost na velikost chunku: skóre vyhledávání pro chunky od 64 do 512 tokenů — Obrázek 8: Citlivost našeho modelu na velikost chunku. Každý bod představuje nevážený průměr nDCG@10 napříč 74 úlohami MTEB, přičemž dokumenty jsou indexovány při dané velikosti chunku.

turbopuffer uchovává plný korpus, dotazy a štítky sady context-bench v soukromí a zveřejňuje výsledky pro odeslané modely. Veřejný benchmark tohoto druhu vybízí k přímému trénování na jeho dotazech a dokumentech, což by jej postupně nasycovalo a snižovalo jeho hodnotu pro sledování pokroku v čase. Pokud si přejete, aby byl váš model vyhodnocen v rámci benchmarku, kontaktujte prosím společnost turbopuffer na adrese contextbench@turbopuffer.com.

Náhled našeho modelu je k dispozici na Hugging Face a všechny výsledky v tomto příspěvku jsou uváděny pro tento náhled. Pracujeme na zpřístupnění modelu prostřednictvím Perplexity API a na dalším vylepšování vyhledávání nad dlouhými dokumenty ve spolupráci se společností 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}
}

Úvod

Proč na kontextu pro vyhledávání záleží

Omezení dohledu zlatého chunku

Nový přístup ke kontextovému učení

Ztrátová funkce

Kontrastní ztráta na úrovni dokumentu

Destilační ztráta na úrovni chunku

Kombinovaná ztráta

Trénovací data

Trénovací nastavení

Nový benchmark pro vyhledávání na úrovni chunků

Dokumenty a dotazy

Štítky odpovědí a důkazů

Metriky

Výsledky vyhodnocení

Context-bench

ConTEB

Celková kvalita vyhledávání napříč doménami

Kvalita vyhledávání a náklady na úložiště

Citlivost na velikost chunku

Vydání

Citace