Контекстне вбудовування поза золотим уривком

Контекстні вбудовування захоплюють значення кожного уривка чи фрагмента в контексті всього документа. Їхнє навчання та оцінка зазвичай припускають один релевантний фрагмент на запит, відомий як «золотий уривок». Проте на практиці золотий уривок часто є недостатнім. Він може містити відповідь, але йому бракує підтверджувального контексту, необхідного для її розуміння чи перевірки, що робить його неоднозначним ізольовано.

Ми представляємо pplx-embed-v2-context-9b-preview — нашу нову модель контекстного вбудовування. Модель навчена за допомогою нового підходу, який використовує модель контекстного стиснення Perplexity як вчителя. Ми агрегуємо її прогнози на рівні токенів в оцінки релевантності на рівні фрагментів, навчаючи модель вбудовування витягувати як фрагменти відповідей, так і підтверджувальний контекст, а не лише один золотий фрагмент. Модель створює одне вбудовування на фрагмент без додаткових витрат на виведення та підтримує 1024-вимірні вбудовування та вбудовування int8.

Вона досягає найкращих у своєму роді результатів на context-bench, новому бенчмарку для контекстно-усвідомленого пошуку, створеному та приватно утримуваному turbopuffer, а також на ConTEB, широко використовуваному публічному бенчмарку. Наша модель була розроблена незалежно від context-bench та оцінювалася як сліпе подання.

Context-bench складається з 2099 запитів по 38 894 довгих документах у 21 домені та оцінює три можливості контекстних вбудовувань: дисамбігуацію документів серед майже дубльованих документів, пошук золотих фрагментів, значення яких залежить від віддаленого контексту, та витяг підтверджувальних доказів, необхідних для перевірки відповіді.

Попередній перегляд моделі загальнодоступний на Hugging Face. Бенчмарк зберігається в таємниці компанією turbopuffer, щоб зменшити ризик забруднення навчальних даних і зберегти його цінність для вимірювання прогресу. Щоб надіслати запит на оцінку, зв'яжіться з turbopuffer за адресою contextbench@turbopuffer.com.

Результати пошуку документів, відповідей та доказів на context-bench — Рисунок 1: Answer@K, Document@K, Evidence Recall@K та All-Evidence@10 на context-bench, що порівнюють Perplexity v2 preview 9B з Voyage Context 4, Voyage 4 Large та Perplexity context v1 4B.

Системи пошуку зазвичай ділять довгі документи на менші фрагменти, які можна індексувати та шукати незалежно. Фрагментація є зручною на практиці, але вона видаляє контекст, у якому спочатку з'явився кожен фрагмент, створюючи компроміс між деталізацією стиснення інформації та контекстом, що використовується під час кодування. Фрагмент може посилатися на раніше введену сутність, успадковувати своє значення із заголовка розділу або спиратися на визначення, розміщені в інших місцях документа. Після вилучення він може більше не містити достатньо інформації для надійного зіставлення із запитом. Кодування всього документа як єдиного вектора не вирішує цю проблему, оскільки одне об'єднане представлення не може точно передати кожну грань довгого документа.

Моделі контекстного вбудовування вирішують це обмеження, представляючи кожен фрагмент у контексті його навколишнього вмісту, найчастіше за допомогою пізнього фрагментування: документ кодується за один прохід, а представлення фрагментів об'єднуються пізніше, так що кожен вектор фрагмента обчислюється за видикремлення всього документа. Попередня робота, така як ConTEB та наша власна pplx-embed-context-v1, показала, що контекстуалізовані представлення фрагментів суттєво покращують пошук порівняно з незалежно закодованими фрагментами, особливо на довгих документах.

Навчання моделей контекстного вбудовування вимагає нагляду, який визначає, які частини документа релевантні до заданого запиту. Поширеним підходом є анотації золотих фрагментів: для кожного запиту анотатор, зазвичай велика мовна модель (LLM), визначає фрагмент документа, який відповідає на нього.

Навчання зазвичай поєднує дві контрастивні втрати: міждокументну втрату, яка протиставляє золотий фрагмент фрагментам з інших документів, та внутрішньодокументну втрату, яка протиставляє його іншим фрагментам у тому ж документі.

Цей підхід має кілька обмежень:

Релевантний лише один фрагмент. Він розглядає кожен інший фрагмент у документі як негативний, включаючи ті, що містять корисну підтверджувальну інформацію. Нагляд на рівні документа діє в іншій крайності. Він визначає документ як релевантний без уточнення, які саме фрагменти в ньому мають значення. На практиці релевантність часто лежить між цими крайнощами. Фрагмент, що містить відповідь, може залежати від кількох підтверджувальних фрагментів, які вводять сутність, розв'язують посилання або надають додатковий факт, тоді як решта документа є нерелевантною. Тому модель повинна навчитися правильного рівня селективності: ширшого, ніж один золотий фрагмент, але більш сфокусованого, ніж документ у цілому.
Грубий нагляд. Оскільки кожна анотація визначає один золотий фрагмент, а не фіксує ступені релевантності по всьому документу, вона забезпечує обмежені навчальні сигнали для обсягу обчислень, витрачених на її створення.
Дорого масштабувати. Кожна навчальна пара вимагає від LLM прочитати документ і вибрати релевантний фрагмент, тому вартість анотування зростає лінійно зі збільшенням розміру навчального набору і обмежує те, наскільки великими та різноманітними можуть бути навчальні дані.
Чутливість до меж фрагментів. Мітки також прив'язані до меж фрагментів, що використовуються під час анотування. Золота мітка, призначена фіксованому вікну розміру токенів, не вказує, які коротші речення або довші абзаци є релевантними. Зміна стратегії фрагментації або навчання на кількох фрагментаціях для покращення стійкості до того, як документи розбиваються під час індексації, може вимагати повторного анотування корпусу.

Ми усуваємо обмеження нагляду за золотими фрагментами шляхом дистиляції оцінок релевантності від моделі контекстного стиснення з урахуванням запиту. Ця модель слугує вчителем: вона читає запит і документ разом і призначає кожному токену документа оцінку релевантності. Її прогнози пропонують кілька переваг для навчання контекстних вбудовувань:

Гнучкі межі фрагментів. Оцінки релевантності на рівні токенів можуть бути агреговані за будь-якими обраними межами фрагментів, що дозволяє тим самим прогнозам вчителя контролювати різне фрагментування без повторного анотування.
Безперервна релевантність. На відміну від двійкових міток золотих фрагментів, вчитель надає безперервні оцінки, які відображають ступені релевантності, що природно розрізняють фрагменти з відповідями, підтверджувальний контекст та нерелевантний вміст.
Нижча вартість анотування. Вчитель є компактним і спеціалізується на оцінці релевантності, що робить його набагато дешевшим для контролю в масштабі, ніж загальнопризначена LLM.

Ми навчаємо нашу модель за допомогою зваженої суми контрастивної втрати на рівні документа та втрати дистиляції на рівні фрагмента на батчах пар «запит — документ». Для кожного запиту парний документ слугує позитивним, тоді як решта документів у тому ж батчі слугують негативними.

Для кожного батчу ми випадковим чином вибираємо стратегію фрагментації, відповідно розбиваємо документи та вставляємо токени-роздільники між фрагментами. Потім ми обробляємо кожен документ за один прямий прохід і виконуємо середнє об'єднання (mean-pooling) представлень токенів у кожному фрагменті, щоб отримати контекстні вбудовування фрагментів. Запити кодуються окремо із середнім об'єднанням їхніх представлень токенів. Нарешті, ми обчислюємо косинусну схожість між кожним вбудовуванням запиту та кожним вбудовуванням фрагмента в батчі.

Хоча наша модель вбудовування створює лише схожості на рівні фрагментів, ми можемо природним чином вивести з них схожості на рівні документа. Ми вважаємо документ d настільки ж релевантним до запиту q, як і його найбільш релевантний фрагмент. Це правило оцінювання натхнене операцією MaxSim ColBERT, застосованою тут до фрагментів замість токенів.

Зокрема, задано запит q з вбудовуванням q та документ d як впорядкований список фрагментів c з вбудовуваннями c, ми визначаємо схожість на рівні документа як:

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

Враховуючи ці схожості на рівні документа, ми можемо сформулювати ціль InfoNCE на рівні документа щодо внутрішньопакетних негативів.

Для запиту q нехай d⁺ позначає його релевантний документ, а 𝒟 — документи в батчі. Контрастивна втрата виглядає таким чином (температури опущені для читабельності):

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

Контрастивна втрата навчає модель, який документ є релевантним до запиту. Втрата дистиляції навчає її, де саме в цьому документі лежить релевантність, що є важливим для контекстної моделі.

Під час навчання ми передаємо кожну позитивну пару «запит — документ» нашій моделі стиснення контексту, яка призначає оцінку релевантності кожному токену в документі. Як і у випадку з оцінюванням на рівні документа, ми виводимо релевантність кожного фрагмента з його найрелевантнішого вмісту. Щоб зменшити чутливість до викидів токенів, зокрема тих, що знаходяться на межах фрагментів, ми визначаємо релевантність на рівні фрагмента як середнє значення найкращих n оцінок токенів усередині фрагмента.

Для кожного запиту ми застосовуємо softmax з температурним масштабуванням до оцінок релевантності на рівні фрагментів від вчителя в позитивному документі, щоб отримати цільовий розподіл. Фрагменти в інших документах батчу отримують нульову цільову ймовірність. Ми навчаємо модель вбудовування відповідати цій цілі шляхом мінімізації прямої дивергенції Кульбаба — Лейблера між цільовим і прогнозованим розподілом за всіма фрагментами в батчі:

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

Тут верхні індекси T та S вказують на вчителя та учня, а rⱼ — це оцінка релевантності вчителя для фрагмента cⱼ в позитивному документі d⁺. Цільовий розподіл вчителя призначає нульову ймовірність фрагментам у всіх інших документах у батчі.

На відміну від однієї мітки золотого фрагмента, ця ціль фіксує ступені релевантності. Підтверджувальні фрагменти отримують вагу відповідно до оцінок вчителя, а не розглядаються як негативні, навчаючи модель витягувати як підтверджувальний контекст, так і відповідь.

Наша комбінована мета навчання є зваженою сумою контрастивної втрати на рівні документа та втрати дистиляції на рівні фрагмента. Ми усредняємо цю зважену втрату по батчу пар «запит — документ».

Рисунок 2 ілюструє наш підхід до навчання. Компресор контексту слугує вчителем лише під час навчання. Під час виведення модель вбудовування створює одне контекстне вбудовування на фрагмент без додаткового етапу стиснення чи повторного ранжування. Цей підхід покращує те, як вивчаються контекстні вбудовування, без збільшення обсягу зберігання індексу чи додавання затримки моделі-вчителя під час пошуку.

Навчальне середовище для дистиляції контекстного вбудовування — Рисунок 2: Навчальне середовище нашої моделі. Контекстний енкодер (учень, ліворуч) обробляє документи, кожен з яких складається з кількох фрагментів. Кожен фрагмент вбудовується відносно контексту навколишнього документа. Запит А є відомим збігом для Документа А і порівнюється з фрагментами всіх документів для отримання передбачуваних схожостей. Ці оцінки на рівні фрагментів об'єднуються за допомогою max-pooling в оцінки на рівні документа. Ми навчаємо прогнози на рівні фрагментів та прогнози на рівні документа відповідати цільовим розподілам (праворуч). Ціль на рівні фрагмента обчислюється під час навчання як прогноз компресора контексту в межах відомого релевантного документа і встановлюється на нуль у межах відомих нерелевантних документів. Цільовий розподіл на рівні документа встановлюється як one-hot для відомого релевантного документа.

Навчальні дані складаються приблизно з 430 публічних і внутрішніх наборів даних «запит–документ», що охоплюють понад 50 мов.

Ми створюємо внутрішні парні набори даних із відфільтрованих від PII виробничих даних і шляхом синтезу релевантних запитів до довгих документів. Для кожного прямого проходу ми вибираємо один набір даних і вибираємо з нього весь пакет, щоб збільшити складність внутрішньопакетних негативів і уникнути навчання за обхідними шляхами. Жоден із наших навчальних наборів даних не містить анотацій на рівні фрагментів: увесь нагляд у межах документа надходить від моделі стиснення, а дані ConTEB не використовуються для навчання. Крім того, жодні дані context-bench не були доступні під час розробки моделі.

Модель починається з внутрішньої моделі пошуку ColBERT із 9 мільярдами параметрів і створює 2048-вимірні вбудовування через шар лінійного проеціювання. Ми позначаємо межі фрагментів вивченим токеном <|chunk_sep|> і формуємо вбудовування кожного фрагмента шляхом усреднення вбудовувань його токенів. Запити кодуються тією самою моделлю, причому вбудовування їхніх токенів усереднюються в єдиний вектор.

Ми використовуємо навчання Матрьошка для підтримки як 1024-, так і 2048-вимірних вбудовувань, а також навчання з урахуванням квантування для підтримки рідних вбудовувань int8. Під час навчання ми поступово збільшуємо швидкість навчання, тримаємо її постійною, а потім зменшуємо.

Випущена модель є модельним супом, який усреднює ваги кількох контрольних точок з одного й того самого навчального запуску.

Публічні бенчмарки контекстного пошуку, такі як ConTEB, поділяють припущення, що лежить в основі нагляду за золотими фрагментами: кожен запит має один релевантний фрагмент, і модель винагороджується лише за те, що поставила цей фрагмент на перше місце. Вони також успадковують його обмеження.

По-перше, ConTEB тестує пошук на завданнях, де фрагмент є неоднозначним без навколишнього контексту. У цих завданнях контекстні моделі перевершили моделі, які кодують кожен фрагмент незалежно. Однак він не запитує, чи виводить модель також інші частини документа, які роблять фрагмент зрозумілим.

По-друге, він систематично не перевіряє, чи можна знайти правильний документ, коли майже ідентичні документи в тому самому корпусі відрізняються лише контекстом, що оточує в іншому випадку ідентичне речення.

Обидві можливості мають значення, коли пошуковий агент або користувач повинен зрозуміти та перевірити відповідь за кількома витягнутими реченнями, а не за весь документ. Тому ми створили context-bench — контрольований бенчмарк для пошуку по довгих документах, розроблений для того, щоб відрізнити використання контексту документа від загальної якості пошуку. Він перевіряє, чи використовують контекстні вбудовування інформацію з інших місць у документі для підтримки трьох можливостей:

Дисамбігуація документів: Визначте правильний документ серед майже ідентичних альтернатив.
Пошук відповідей: Отримайте фрагменти з відповідями, значення яких залежить від деталей в інших місцях документа.
Пошук доказів: Отримайте підтверджувальні фрагменти, які прояснюють або обґрунтовують відповідь.

Context-bench містить 2099 запитів і 38 894 документи. Використовуються фрагменти довжиною з речення, в результаті чого загальна кількість фрагментів становить 2 458 072. Запити охоплюють 21 домен, зокрема корпоративні звіти, клінічні дослідження, подорожі, розваги, освіту, урядові документи, юридичні контракти та документацію програмного забезпечення.

Кожен запит розроблений для перевірки однієї з дванадцяти контекстних можливостей. Основні цільові документи навмисно довгі: 1061 із 1197 унікальних основних цільових документів мають щонайменше 200 речень, причому медіанна довжина становить приблизно 6100 токенів. Кожен запит має рівно одну правильну відповідь у корпусі. Якщо той самий факт викладено в золотому документі кілька разів, наприклад у підсумковому реченні та рядку таблиці, будь-яке з цих речень приймається як відповідь.

Шлях відповіді — це одна дійсна комбінація фрагмента відповіді та підтверджувальних доказів, необхідних для її інтерпретації чи перевірки. У 2099 запитах шлях відповіді до основного цільового документа має одну групу доказів для 964 запитів, дві — для 735, три або більше — для 332, і жодної — для 68. Альтернативні дійсні шляхи відповіді можуть вимагати різних груп доказів.

Таблиця 1: Статистика бенчмарку.

Статистика	Значення
Запити	2 099
Документи	38 894
Фрагменти речень	2 458 072
Медіанна довжина основного цільового документа	6 100 токенів
Домени	21
Групи доказів на запит (шлях відповіді до основного цільового документа)	1: 964; 2: 735; 3+: 332; немає: 68

Таблиця 2: Дванадцять контекстних можливостей, які тестує context-bench, з ілюстративними прикладами.

Можливість	Приклад запиту	Фрагмент відповіді	Потрібний контекст документа
1. Ідентичність сутності	Скільки Northlake витратила на викуп акцій?	Компанія викупила акцій на 12,8 мільярда доларів.	У вступі Northlake ідентифікується як «компанія». Подібний звіт Southlake не є актуальним.
2. Період або версія	Який картридж підходить для M40 версії B?	Встановіть картридж KC-42.	У розділі щодо застосовності зазначено, що ці інструкції стосуються версії B, а не версії C.
3. Визначення та псевдоніми	Який показник виходу був у групі 15 мг?	У Zeta показник виходу становив 12,7%.	У звіті Zeta визначається як група 15 мг. Без цього визначення фрагмент не ідентифікує запитувану групу.
4. Структура таблиці	Яка ємність акумулятора моделі Max?	Типова ємність: 4250 \| 4700 \| 5150.	Заголовок таблиці встановлює Mini \| Base \| Max у мА·год. Отже, відповідь — 5150 мА·год.
5. Умови та винятки	Скільки часу триває гарантія на акумулятор для комерційного використання?	Гарантія на акумулятор триває 18 місяців.	Вступ до розділу обмежує це покриття комерційними інсталяціями; побутові інсталяції мають іншу гарантію.
6. Посилання та займенники	Коли Мара стала заступницею мера?	Вона обійняла посаду у 2021 році.	Попередній оповідний текст встановлює, що «вона» стосується Мари, а не Елін, про яку також йдеться.
7. Порядок і позиція в списку	Яка пісня відкривала біс?	14. Lantern Road.	В іншій примітці зазначено, що біс складався з пісень 14–16. Отже, трек 14 є його вступною піснею.
8. Область дії розділу	Який об'єктив використовувався для операторської роботи у фільмі?	Протягом усього часу використовувався об'єктив 35 мм з фіксованою фокусною відстанню.	Цей уривок належить до «Основних зйомок», а не до окремого розділу про рекламні фотографії.
9. Приписування слів мовцю	Яку дату повторного відкриття пообецяв мер?	Ми відкриємося знову 12 червня.	Розшифровка ідентифікує мера як мовця. Ті самі слова від підрядника не підтверджували б обіцянку мера.
10. Зміни з часом	Який строк повідомлення застосовувався після травневої поправки?	Строк повідомлення тепер становить 45 днів.	Історія поправок встановлює, що ця зміна набула чинності в травні, замінивши попереднє правило 30 днів.
11. Причинно-наслідкові зв'язки	Чому зупинився західний насос?	Ця несправність спричинила зупинку.	Розслідування визначає «цю несправність» як заклинений підшипник у західному насосі та відрізняє її від непов'язаного засмічення на вході.
12. Фігуральне або міжмовне значення	Фігуральне: Що символізує «зимова кімната» у вірші? Міжмовне: Який компонент французька інструкція наказує техніка зняти?	Фігуральне: Вона уособлює вигнання, а не фізичну кімнату. Міжмовне: Retirez le capot. (Зніміть кришку.)	Фігуральне: У коментарі «вона» визначається як повторюваний образ «зимової кімнати» у вірші. Міжмовне: Глосарій у путівнику уточнює, що «capot» означає захисний кожух двигуна, а не транспортну кришку.

Запити, документи та можливості, що тестуються, натхненні розмовами з клієнтами turbopuffer.

Наведемо один приклад: розглянемо пошукові потреби компанії з управління нерухомістю. Ці компанії мають сотні, іноді тисячі договорів оренди, які відрізняються лише іменами орендарів, датами та кількома іншими ключовими деталями. Поширеним запитом для цього набору даних може бути «коли закінчується оренда 5 Park Avenue та яка поточна орендна плата?». Договори оренди також можуть бути довгими, а критичні компоненти дисамбігуації, які підтверджують, що ви знайшли правильний документ (як-от дата, адреса, ім'я орендаря тощо), часто можуть знаходитися дуже далеко від ключового речення відповіді, що містить суму щомісячної орендної плати. На практиці ідентичні речення на кшталт «Місячна орендна плата становить $X,XXX.» можуть з'являтися в багатьох документах у корпусі.

Хороша модель контекстного вбудовування повинна використовувати контекст з усього документа, щоб ідентифікувати правильний документ і отримати як відповідь, так і речення, що її підтверджують. Це дозволяє користувачеві або пошуковому агенту швидко перевірити відповідь і підтвердити, що вона походить із правильного документа.

Для кожного запиту ми позначаємо речення «відповіді» та «доказів» у цільовому документі. Модель проходить наш тест «достатності читача», якщо вона отримує речення відповіді разом із щонайменше одним реченням з кожної групи доказів. Разом ці речення забезпечують достатньо контексту для читача, щоб перевірити відповідь за допомогою підтверджувальних доказів.

Коли моделі контекстного вбудовування роблять це добре, вони можуть драматично зменшити кількість токенів, які потрібно переглянути пошуковим агентам, а також значно полегшити людині швидке підтвердження того, що вона знайшла правильну відповідь на свій початковий запит, без необхідності читати весь документ.

Кожна група доказів має бути відновлена, але будь-яка з альтернатив групи є достатньою для її відновлення. Часто можна побачити той самий факт, викладений у кількох місцях у цих довгих документах. Отримання лише одного речення з кожної групи доказів відповідає критеріям достатності читача і як таке буде прийняте як ідеальне відновлення доказів.

Кожен документ розбивається на фрагменти у вигляді речень, і ті самі межі використовуються для всіх моделей. Для моделей неконтекстного вбудовування перевіряються дві умови: одна, де кожне речення вбудовується незалежно, а інша, де весь документ вбудовується як єдиний фрагмент.

Ми використовуємо умову на рівні речень для вимірювання повноти відповідей та повноти доказів. Вона перевіряє, чи може неконтекстна модель ідентифікувати правильну відповідь і підтверджувальні докази, коли кожне речення вбудовується без доступу до навколишнього документа. Це навмисно складно. У багатьох запитах реченню-відповіді самій по собі бракує деталей, необхідних для відмінності його від подібних речень в інших місцях корпусу.

Ми використовуємо умову на рівні документа як базову лінію повноти документа. Вона перевіряє, чи дають деталізовані вбудовування речень достатню перевагу в пошуку, щоб виправдати додаткові витрати на зберігання порівняно зі зберіганням одного вектора на документ. Індекс на рівні речень створює значно більше векторів, ніж індекс на рівні документа, тому він повинен перевершувати базову лінію «один вектор на документ», щоб виправдати ці витрати.

Усі оцінки використовують вичерпні ранжування проти всіх 2 458 072 фрагментів. Тому відмінності між моделями відображають представлення, а не конфігурацію індексу. Ми зосереджуємося на трьох ключових метриках:

Document@K визначається як:

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

де $d^{*}$ — це документ із найвищим рангом у $D_q$ .

Answer@K визначається як:

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

де $C_K(q)$ — це перші $K$ фрагментів у всьому корпусі, а $A_{q}$ — набір прийнятих фрагментів відповідей.

Evidence Recall@K вимірюється в межах $d^{*}$ таким чином: ранжуйте речення $d^{*}$ за схожістю, видаліть речення відповіді з найвищим рангом і нехай $R_K(q)$ будуть топ $K$ , що залишилися. Для груп доказів $G_q=\{g_1,\ldots,g_m\}$ група $g_j$ вважається відновленою, якщо якась альтернатива $E\in g_j$ задовольняє $E\subseteq R_K(q)$ , і

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

Document@K запитує, чи дозволяє контекстуалізація правильному документу перевершити сусідні документи та дистрактори, які поділяють його лексику.

Answer@K запитує, чи входить саме речення відповіді до топ-фрагментів.

Evidence Recall@K запитує, яка частина підтверджувального контексту відновлюється серед перших K фрагментів правильного документа після виключення фрагмента відповіді з найвищим рангом. Видалення відповіді запобігає подвійному зарахуванню того, що вже вимірює Answer@K, і залишає всі слоти $K$ для підтверджувального контексту. Вимога щодо наявності золотого документа в перших 10 отриманих документах означає, що жодна модель не отримує кредити за докази для документа, який вона б не виявила. Ми також повідомляємо All-Evidence@K — частку запитів із відновленою кожною групою.

Разом ці метрики декомпонують виклики, з якими стикаються моделі контекстного вбудовування: знайти правильний документ, знайти правильну відповідь і відновити мінімальний контекст, який показує, чому відповідь є правильною.

На рисунку 3 проілюстровано метрики на прикладі управління нерухомістю.

Як оцінюється пошук документів, відповідей та доказів у context-bench — Рисунок 3: Метрики Context-bench, проілюстровані на запиті щодо оренди. Document@K перевіряє пошук правильного документа; Answer@K перевіряє пошук фрагмента його відповіді; Evidence Recall@K вимірює відновлення груп підтверджувальних доказів у цільовому документі. У цьому прикладі перевірка орендної плати вимагає доказів як щодо адреси, так і щодо року оренди. Повнота доказів виключає топ-фрагмент відповіді та вимагає, щоб цільовий документ потрапив у першу десятку.

Ми оцінюємо нашу модель порівняно з контекстними та неконтекстними моделями вбудовування за чотирма напрямками.

Нашими контекстними базовими лініями є pplx-embed-context-v1-4B та voyage-context-4. Нашими неконтекстними базовими лініями є voyage-4-large та Nemotron-3-Embed-8B-BF16 від NVIDIA, які кодують фрагменти незалежно. Набір базових ліній змінюється залежно від експерименту, як зазначено на кожному рисунку.

Ми починаємо з context-bench, який безпосередньо тестує можливості, що мотивують цю роботу, а потім повідомляємо результати на ConTEB — стандартному публічному бенчмарку для контекстних вбудовувань. Щоб перевірити, чи не досягається цей приріст за рахунок загальної якості пошуку, ми також оцінюємо специфічні для доменів бенчмарки пошуку документів і фрагментів, які ми створили на основі публічних наборів даних. Нарешті, ми досліджуємо дві практичні властивості для розгортання: якість пошуку порівняно з витратами на зберігання на один вектор і чутливість до розміру фрагмента, що використовується під час інндексації. Усі оцінки кодують документи обсягом до 32 768 токенів за один прохід.

Як показано на рисунку 1 у вступі, наш попередній перегляд лідирує за показниками Answer@K та Evidence Recall@K на кожному звітній межі відсікання, а також за All-Evidence@10. При K = 10 він досягає 45,5% повноти відповідей, 40,6% повноти доказів і 31,1% повноти всіх доказів. Він також лідирує за Document@1 та Document@10, досягаючи відповідно 15,2% та 61,6%. При K = 10 наш попередній перегляд перевищує voyage-context-4 на 14,4 відсоткового пункту за повнотою відповідей і на 5,0 пунктів за повнотою доказів.

Наша модель попереднього перегляду досягає найвищого середнього значення nDCG@10 серед моделей, показаних на ConTEB на рисунку 4. Вона лідирує не в кожному завданні: pplx-context-v1-4B набирає вищий бал на NarrativeQA, тоді як Nemotron-3-8B набирає найвищий бал на COVID-QA. Як зазначали основні автори в документі ConTEB, COVID-QA здебільшого містить пари запит-фрагмент, які є дуже екстрактивними й можуть бути задоволені простим поверхневим лексичним зіставленням за технічними медичними термінами. У результаті розуміння контексту є менш корисним для цього завдання, і неконтекстні моделі зазвичай перевершують контекстні.

nDCG на рівні завдань на 10 на ConTEB — Рисунок 4: nDCG@10 на рівні завдань на ConTEB в умовах «запит — фрагмент». Середнє значення — це незважене середнє за вісьмома завданнями.

Окрім бенчмарків, розроблених для контекстних вбудовувань, ми оцінюємо продуктивність нашої моделі в окремих доменах.

Наш набір завдань «запит — фрагмент» (Q2C) використовує завдання MTEB, такі як LegalBench та FinanceBench, разом із додатковими завданнями пошуку, які ми створили з публічних наборів даних. У межах кожного релевантного документа фрагмент вважається релевантним, якщо він містить точний діапазон відповіді, коли завдання його надає, або ж визначається за допомогою LLM щодо його релевантності запиту. Набір завдань «запит — документ» (Q2D) використовує ті самі завдання та оцінює, чи знайдено релевантний документ.

Наша модель досягає найвищого середнього бала з пошуку фрагментів на рисунку 5 і лідирує в юридичному, технічному та медичному доменах. Вона лідирує не в кожному домені: voyage-context-4 набирає вищий бал у фінансах та багатомовному пошуку, а Nemotron-3-8B набирає найвищий бал у пошуку розмов. Під час пошуку документів на рисунку 6 наша модель набирає трохи нижчий бал за voyage-context-4 в середньому, лідируючи при цьому в технічному домені. Базова лінія pplx-context-v1-4B набирає нижчий бал у середньому в обох наборах завдань, що узгоджується з тим, що вона навчалася лише на навчальному наборі ConTEB, демонструючи, що нагляд, прив'язаний до золотих фрагментів одного бенчмарку, погано переноситься на інші домени.

Оцінки пошуку «запит — фрагмент» за доменами — Рисунок 5: Середнє nDCG@10 в завданнях «запит — фрагмент» (Q2C), згруповане за доменами. Стовпчики доменів є незваженими середніми оцінок на рівні завдань у цьому домені; загальне середнє — це незважене середнє за всіма відображеними завданнями.

Оцінки пошуку «запит — документ» за доменами — Рисунок 6: Середня оцінка пошуку в завданнях «запит — документ» (Q2D), згрупована за доменами. Кожен стовпчик у домені є незваженим середнім основних оцінок на рівні завдань; загальне середнє — це незважене середнє за всіма відображеними завданнями.

Модель контекстного вбудовування створює один вектор на фрагмент, тому індекс, побудований за допомогою нашої моделі, містить стільки ж векторів, скільки й звичайний індекс на рівні фрагментів із такою самою стратегією фрагментації. Контекстуалізація змінює те, що кодує кожен вектор, а не кількість збережених векторів. Тому обсяг пам'яті для зберігання визначається розміром кожного вектора. Модель пропонує два способи його зменшення: обрізання вбудовування з 2048 до 1024 вимірів та його квантування до int8.

На рисунку 7 показано сприятливий компроміс між якістю пошуку та сховищем векторів. При 1024 вимірах наші вбудовування int8 використовують 1 КБ на вектор, трохи перевищуючи оцінку пошуку фрагментів voyage-context-4 при 2048 вимірах у float32, яка використовує 8 КБ на вектор. Збільшення розміру нашого вбудовування до 2048 вимірів ще більше підвищує якість пошуку при 2 КБ на вектор. Ці цифри зберігання стосуються лише векторів, а не решти індексу.

Якість пошуку фрагментів проти зберігання на вектор — Рисунок 7: Якість пошуку фрагментів (середнє nDCG@10) як функція зберігання на вектор. Суцільні лінії позначають float32, а штрихові — int8; мітки вказують вимірність вбудовування.

На рисунку 8 показано лише скромну зміну якості пошуку при збільшенні розміру фрагмента з 64 до 512 токенів: середня оцінка падає з 81,0% до 79,9%, що становить зменшення на 1,1 відсоткового пункту. Це свідчить про те, що модель залишається ефективною для тестованих розмірів фрагментів, надаючи конвеєрам індексації гнучкість у розбитті документів.

Чутливість до розміру фрагмента: оцінки пошуку для фрагментів від 64 до 512 токенів — Рисунок 8: Чутливість нашої моделі до розміру фрагмента. Кожна точка — це незважене середнє nDCG@10 за 74 завданнями MTEB з документами, проіндексованими із заданим розміром фрагмента.

turbopuffer зберігає весь корпус, запити та мітки контекст-бенчу конфіденційними та повідомляє результати для поданих моделей. Публічний бенчмарк такого роду заохочує до прямого навчання на його запитах і документах, що поступово насичуватиме його й зменшуватиме його цінність для відстеження прогресу з часом. Якщо ви хочете, щоб вашу модель оцінили на бенчмарку, зв'яжіться з turbopuffer за адресою contextbench@turbopuffer.com.

Попередній перегляд нашої моделі доступний на Hugging Face, і всі результати в цій публікації повідомляються для цього попереднього перегляду. Ми працюємо над тим, щоб зробити модель доступною через Perplexity API, а також над подальшим покращенням пошуку по довгих документах спільно з 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}
}

Вступ

Чому контекст важливий для пошуку

Межі нагляду за золотими фрагментами

Новий підхід до контекстного навчання

Функція втрат

Контрастивна втрата на рівні документа

Втрата дистиляції на рівні фрагмента

Комбінована втрата

Навчальні дані

Навчальне середовище

Новий бенчмарк для пошуку на рівні фрагментів

Документи та запити

Мітки відповідей та доказів

Метрики

Результати оцінки

Context-bench

ConTEB

Загальна якість пошуку за доменами

Якість пошуку та витрати на зберігання

Чутливість до розміру фрагмента

Випуск

Цитування