Photon: побудова рушія пошуку та ранжування з нуля

Вступ

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

Щоб подолати ці труднощі, ми створили Photon — новий власний рушій пошуку та ранжування. Це продовжує наш підхід до побудови інфраструктури AI-first пошуку з нуля, як ми це зробили з CobbleDB, нашим розподіленим сховищем «ключ-значення» для обслуговування записів сторінок, та нашим Search API.

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

Тепер Photon забезпечує роботу нашого конвеєра пошуку, а також є основою нового швидкого пресету для нашого Search API із затримкою одного пошукового виклику 160 мс для p50 та 230 мс для p95. На шести публічних бенчмарках швидкий пресет зменшив орієнтовну вартість «модель плюс пошук» на одне завдання на 68%, зберігаючи загальну якість завдань, порівнянну зі стандартним пресетом. Ми випускаємо його сьогодні, щоб розробники могли отримати доступ до цих покращень.

Розгорнути

Розгорнути

Вимоги до рушія пошуку та ранжування

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

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

У чому попередня система виявилася недостатньою

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

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

2. Погана хвостова затримка. На робочому трафіку час відгуку p99 старої системи становив близько 800 мс. Набір даних перевищував доступну оперативну пам'ять, тому ми не могли використовувати mlock, щоб утримувати його повністю в пам'яті. Доступ до нерезидентних даних міг викликати серйозні збої сторінок, зупиняючи виконання запиту, поки операційна система читала дані з диска.

Рушій також періодично об'єднував свій основний дисковий індекс із меншими індексами, скинутими з пам'яті. Під час цього процесу злиття дискового індексу кількість збоїв сторінок зростала ще сильніше, а затримка p99 досягала приблизно 1,2 с протягом 10–15 хвилин. У міру прогрівання кешів частота збоїв сторінок і затримка зменшувалися, що свідчить про те, що холодне читання було основним чинником стрибків. Попереднє завантаження даних та прогрів індексу зменшили стрибки, але не вирішили належним чином проблему високої хвостової затримки.

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

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

Місце Photon у стеку пошуку

Photon розроблено для двох основних робочих процесів: обслуговування пошукових запитів та завантаження оновлень із конвеєра обробки.

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

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

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

Розгорнути

Проєктування Photon для наших робочих процесів

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

Представлення даних для пошуку та ранжування

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

Photon використовує два взаємодоповнюючі представлення для підтримки цих патернів доступу. Інвертований індекс зберігає список збіжних документів для кожного терміна, який називається списком публікацій, для підтримки вибору кандидатів. Окремі записи для кожного документа надають дані, необхідні для ранжування. Ми також оптимізуємо зберігання та обхід списків публікацій для покращення відбору в межах фіксованого бюджету роботи.

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

Інвертований індекс

Для кожного терміна інвертований індекс зберігає список публікацій. Ці списки можуть містити від кількох документів до мільйонів, тому жоден формат не підходить для кожного списку. Photon вибирає формат на основі кількості документів, що містять термін.

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

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

Розгорнути

Обхід списків у межах бюджету роботи

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

Алгоритм ділить списки на дві групи. Керуючі списки просувають обхід і пропонують документи-кандидати. Списки опитування роблять внесок в оцінки цих кандидатів, але самі не генерують кандидатів.

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

Відбір далі відбувається у три етапи:

• Обхід: Почніть із суворої вимоги до покриття запиту. Якщо знайдено занадто мало кандидатів, повторіть з послабленою вимогою.
• Збереження: Кандидати утримуються в обмеженому наборі за допомогою оцінки, яка поєднує покриття та частоту. У міру покращення зібраних найкращих кандидатів поріг допуску зростає.
• Кінцевий відбір: Кінцеві результати для проходу вибираються зі збереженого набору на основі оцінок частоти. Кожне поле виконує власний прохід, а результати об'єднуються за допомогою ваг полів.

Алгоритм створює набір кандидатів із релевантних документів для використання в подальшому ранжуванні.

Розгорнути

Docblob

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

Формат створено так, щоб уникати зайвого декодування. Усередині docblob поля згруповані за аналізатором тексту. Кожна група зберігає відсортований список термінів, закодований за допомогою Elias-Fano, тож термін запиту можна шукати безпосередньо без попереднього розгортання всього списку. Маска полів позначає, де з'явився термін, лічильник частоти відстежує, як часто, а фактичні позиції містяться в окремих блоках для кожної пари «термін-поле», закодованих як різниці позицій. Декодуються лише блоки для термінів, які дійсно збіглися, тоді як усе інше в записі залишається в стисненому форматі.

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

Розгорнути

Пакетне читання та робота з пам'яттю

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

Розгорнути

Перекриття очікування диска

Ранжування вимагає отримання ознак сотні документів, розташованих у різних частинах файлу. Наша попередня система використовувала mmap для відображення файлу у віртуальний адресний Простір, щоб його можна було читати через вказівники пам'яті. Однак доступ до сторінки, якої не було в пам'яті, все одно вимагав читання з диска. Тред повинен був чекати на дані перед продовженням обчислень, і цей час очікування накопичувався, коли процесу потрібно було послідовно читати холодні записи.

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

Зменшення кількості звернень до дисків

Перед надсиланням запитів на читання Photon перевіряє весь пакет у кеші в оперативній пам'яті. Тільки запити на відсутні записи надходять на диск; прочитані дані потім заповнюють кеш.

Кеш розроблено для пакетного читання. Зокрема:

• При влучанні немає окремого виділення пам'яті. Натомість дані копіюються в буфер, заздалегідь підготовлений кодом, що викликає.
• Читач не отримує блокування. Натомість він перевіряє версію даних і повторює спробу в разі конфлікту із записом.
• Він використовує витіснення CLOCK замість того, щоб вимагати оновлень спільного списку LRU при кожному читанні.
• Він використовує попереднє завантаження кешу процесора, під час якого метадані та дані для наступних запитів запитуються заздалегідь.

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

Побудова та оновлення індексу окремо від обслуговування

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

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

Розгорнути

Підготовка та розподілена збірка

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

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

Розгортання нової версії

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

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

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

Розгорнути

Міграція та валідація в нашому пошуковому стеку

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

Навантажувальне тестування та оцінювання

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

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

Виміряні покращення у виробництві

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

Photon використовує приблизно на 20% менше еквівалентних машин обслуговування, ніж вузли вмісту старої системи, зберігаючи водночас приблизно у 2,5 раза більше даних на документ. Після міграції ми використали ці додаткові дані для покращення якості ранжування порівняно зі старою системою.

Photon також зменшує обсяг даних, які мають залишатися в пам'яті. Закріплення того самого набору даних Photon в оперативній пам'яті за допомогою mlock потребувало б приблизно в 4,6 раза більше резидентної пам'яті, ніж Photon використовує зараз.

Оцінка швидкого пресету Search API

Ми також використали Photon як основу для нового швидкого пресету для нашого Search API, розробленого для чутливих до затримки робочих навантажень. Згідно з нашими вимірюваннями, затримка одного пошукового виклику для швидкого пресету становить 160 мс для p50 та 230 мс для p95, що нижче або порівняно із самостійно заявленими показниками інших провайдерів Search API, хоча заявлені хвостові перцентилі відрізняються.

Ми оцінили швидкий пресет на шести бенчмарках для агентів: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 та SEAL-Hard. У цих оцінках він мав найнижчу орієнтовну загальну вартість «модель плюс пошук» та найвищу загальну оцінку завдань серед перевірених конфігурацій.

Швидкий пресет поєднує Photon із ранжуванням, оптимізованим для робочих процесів агентів, забезпечуючи порівнянну зі стандартним пресетом продуктивність за суттєво нижчої вартості. Проте він має компроміс у ширшій якості пошуку. Швидкий пресет використовує менше обчислень для ранжування, ніж стандартний пресет. На внутрішніх бенчмарках, що охоплюють довгохвості запити, широке покриття та різноманітність результатів, він отримує на 0,24 пункту нижчу оцінку релевантності та приблизно на 3 відсоткові пункти нижчу доступність відповідей. Ми вважаємо це розумним компромісом для робочих процесів агентів, оскільки власні міркування та знання моделі можуть допомогти компенсувати цю різницю.

Розгорнути

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

Висновок

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

Photon забезпечив швидший пошук у продуктах Perplexity та є основою для нашого нового швидкого пресету в Search API. Після міграції затримка пошуку та ранжування p99 впала приблизно з 800 мс до 65 мс. Наші компактні формати даних також дозволяють зберігати у 2,5 раза більше даних на документ, надаючи пошуку та ранжуванню доступ до багатшої інформації про документи.

Швидкий пресет забезпечує затримку одного пошукового виклику 160 мс для p50 і 230 мс для p95. Протягом шести оцінених бенчмарків для агентів він зменшив орієнтовну вартість «модель плюс пошук» на одне завдання на 68% порівняно зі стандартним пресетом, зберігаючи при цьому порівнянну загальну якість виконання завдань. Ці результати демонструють практичні переваги інфраструктури, розробленої навколо наших робочих навантажень пошуку, як для продуктів Perplexity, так і для розробників, які створюють рішення за допомогою нашого API.

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

Цитата

@online{perplexity2026Photon,
  author = {{Perplexity} and Maksim Morozov and Bogdan Savko and Ruslan Kovalev and Aleksei Bykov and Artur Zayats and Denis Bykov and Nikita Kireev and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Photon: Building a retrieval and ranking engine from scratch}},
  date = {2026-09-24},
  url = {https://www.perplexity.ai/hub/blog/photon}
}