Photon: Изградња механизма за преузимање и рангирање од нуле

Захтјев из претраживачког сервиса вишег нивоа стиже до Photon брокера кроз балансер оптерећења. Брокер бира групу срхова и прослеђује захтјев сваком срху, пратећи временска ограничења и издавајући додатне захтјеве када је то потребно.

Да бисмо превазишли ове изазове, направили смо Photon, нови интерни механизам за проналажење и рангирање. Тиме настављамо наш приступ изградњи инфраструктуре за претрагу од темеља, са вјештачком интелигенцијом у средишту, као што смо урадили са CobbleDB, нашим дистрибуираним складиштем парова кључ–вриједност за испоручивање записа о страницама, и нашим Search API.

Photon користи компактне формате података да чита и декодира само оно што је сваком упиту потребно, уз кеширање које је свесно батч-обрада и асинхроно читање како би се смањио приступ диску и преклапао период чекања. Изградња индекса се изводи одвојено од сервирања упита, ажурирајући по једну групу за сервирање и загревајући њене кешеве пре него што се према њој усмере живи упити.

Photon сада покреће наш цјевовод за претрагу и такође представља основу новог брзог подешавања за нашу Search API, са латенцијом једног позива претраге од 160 ms на p50 и 230 ms на p95. Кроз шест јавних референтних мјерења (benchmark), брзо подешавање је смањило цијену модела плус претраге по задатку за 68%, уз одржавање укупног квалитета задатака упоредивог са задатим подешавањем. Објављујемо га данас како би програмери могли да приступе овим побољшањима.

Графикон латенције једног позива претраге који приказује медијане које је пријавио провајдер и доступне крајње перцентиле (tail percentiles), укључујући Exa Instant p90 умјесто p95. — Самопријављена латенција једног позива претраге. PPLX Fast пријављује p50 латенцију од 160 ms и p95 латенцију од 230 ms. Exa Instant пријављује p90, а не p95, за своју вриједност на горњем крају; Parallel-ове вриједности на горњем крају нису објављене. Пријављени перцентили и поставке мјерења нису контролисано поређење по принципу „исти са истим“.

Дијаграм расипања који упоређује резултате референтних мјерења пондерисаних задатцима са процијењеном укупном цијеном модела и претраге кроз шест конфигурација. — Укупан квалитет задатка у односу на процијењену укупну цијену модела плус претраге за истих 3.554 одабраних задатака. Резултати су пондерисани бројем задатака, а цијене покривају цијели скуп задатака. PPLX Fast постиже 64,3% на 59,73 $, у поређењу са 64,0% на 187,60 $ за подразумевано PPLX подешавање, што је приближно 68% нижа процијењена цијена за исти број задатака.

За сваки упит, моћи преузимања и рангирања претражује велики, дистрибуирани индекс како би одабрао и поређао мали скуп релевантних страница у оквиру буџета латенције стека претраге. Систем такође мора да одржава индекс ажурним како пристижу нове странице и како се постојеће мијењају, а да притом тај рад не успорава упите у реалном времену.

Кеш је дизајниран за серијска читања. Посебно:

Одржавали смо сопствено гранање да прилагодимо мотор нашем растућем индексу, али рјешавање кључних ограничења све више је захтијевало редизајнирање великих дијелова платформе. Неколико ограничења се показало тешким за рјешавање без фундаменталних архитектонских промјена:

1. Трошкови скалирања. Временом су расли и број докумената које чувамо и количина података по документу које треба да прибавимо и користимо за рангирање. Тај раст је оптерећивао наш хардвер, нарочито расположиву RAM меморију. Да бисмо контролисали трошкове, били су нам потребни компактнији прикази података и прецизнија контрола над тим шта остаје у меморији, а шта се по потреби чита са диска.

2. Лоше кашњење у репу. Са продукцијским саобраћајем, вријеме одзива p99 старог система било је око 800 ms. Скуп података је премашио доступни RAM, тако да нисмо могли користити mlock да га задржимо у потпуности у меморији. Приступ нерезидентним подацима могао је да покрене велике грешке странице, заустављајући извршавање упита док оперативни систем чита са диска.

Мотор је такође периодично спајао свој главни индекс диска са мањим индексима испражњеним из меморије. Током овог процеса спајања индекса диска, број грешака странице (page faults) је порастао још више, при чему је p99 латенција достигла приближно 1,2 s на 10–15 минута. Како су се кешови загријавали, фреквенција грешака странице и латенција су се смањивале, што сугерише да су хладни наступи били главни доприносилац скоковима. Унапријед учитавање података и загријавање индекса смањили су скокове али нису адекватно ријешили високу латенцију на крају.

3. Дуготрајни опоравак и синхронизација. У претходном систему, постављање додатног кластера и синхронизација његових података могли су да трају дуже од недјеље. Синхронизација је такође била потребна при додавању група чворова за чување додатних копија података или опоравку од кварова чворова. Током опоравка, већи удјели одговора на претрагу су били дјелимични, што је смањивало резултате квалитета коначног одговора.

На крају смо закључили да би било једноставније и јефтиније да се изгради од нуле него да наставимо да прилагођавамо и одржавамо наше гранање. Ослањајући се на наше искуство у раду са претходним системом, мали инжењерски тим је радио заједно са ројем перзистентних агента за кодирање како би изградио Photon.

Photon је дизајниран за два примарна тока рада: опслуживање захтјева за претрагу и узимање ажурирања из цјевовода за обраду.

Захтјев из услужног сервиса вишег нивоа стиже до Photon брокера кроз балансер оптерећења. Брокер бира групу сљемова и просљеђује захтјев сваком сљему, пратећи временска ограничења (timeouts) и издајући додатне захтјеве када је то потребно.

Селекција затим наставља у три корака:

Ажурирања индекса слиједе посебан пут. Pillar, наш слој за објављивање, припрема податке и чува их у YTsaurus табелама. Индесери претварају ове табеле у индексне структуре које сљемови могу да учитају за претрагу. Контролер координира припрему података, изградњу индекса и примену нових верзија индекса на услужне групе. Прије руковања саобраћајем у реалном времену, сваки сљем репродукује стварне упите претраге како би загријао своје кешове.

Слијед Photon упита са пуним стрелицама захтјева и испрекиданим стрелицама повратка између претраге вишег нивоа, балансера оптерећења, брокера и сљемова; наслови фаза селекције кандидата и читања резимеа налазе се са лијеве стране. — Упит се креће од сервиса претраге вишег нивоа преко балансера оптерећења и брокера до изабране групе сљемова. Сваки сљем преузима и рангира кандидате; брокер спаја резултате, преузима поља документа за изабране странице и враћа их сервису претраге вишег нивоа. Нумерисани кораци показују редослед. Пуне стрелице носе захтјеве, а испрекидане стрелице враћају резултате назад. Натписи фаза са лијеве стране разликују селекцију кандидата од читања резимеа.

Број срхова и број истовремено покренутих индесера су конфигурисани независно, тако да се изградња може извршити у неколико таласа, или се више машина може додијелити за паралелни рад. Дистрибуирана припрема и паралелни индесери омогућавају да се цијели веб индекс изгради за једноцифрен број сати, што је значајно побољшање у односу на претходни систем.

Проналажење и рангирање приступају подацима документа другачије. Лексичко проналажење почиње са упитним тредовима и проналази документе који их садрже. Рангирању су затим потребне детаљне информације о сваком изабраном документу, укључујући фреквенције тредова и позиције.

Photon користи двије комплементарне репрезентације за подршку ових образаца приступа. Обрнути индекс чува листу докумената који се подударају за сваки термин, која се назива листа објављивања, за подршку селекцији кандидата. Одвојени записи по документу пружају податке потребне за рангирање. Такође оптимизујемо како се листе објављивања чувају и како се кроз њих крећемо како бисмо побољшали селекцију у оквиру фиксног буџета рада.

Специјализоване репрезентације података омогућавају нам да ефикасније складиштимо кључне податке. Компактнији обрнути индекс смањује количину прочитаних или помјерених података по упита, побољшавајући латенцију елиминисањем непотребних I/O операција. Ови формати такође омогућавају провјеру да ли се документ појављује на листи без његовог потпуног декодирања, што је својство на које се наша логика кретања ослања како би контролисала колико посла упит обавља под фиксним буџетом. Оптимизација записа по документу омогућава нам да складиштимо више података по документу за рангирање, а истовремено смањује трошкове скалирања повезане са нашим претходним системом.

Формат је направљен да избјегне декодирање више него што је потребно. Унутар docblob-a, поља су груписана по анализатору текста. Свака група чува сортирану листу тредова кодирану са Elias-Fano, тако да се упитни тред може директно потражити без првог ширења цијеле листе. Маска поља означује гдје се тред појавио, бројач фреквенције прати колико често, а стварне позиције живе у одвојеним блоковима по пару тред-поље кодираним као разлике позиција. Само блокови за тредове који су стварно одговарали бивају декодирани, док све остало у запису остаје у компримованом формату.

Кратке листе користе уметнуту репрезентацију која стаје у једну страницу и не захтијева табелу блокова. Дуже листе које не стају у уметнути формат подељене су на блокове који покривају фиксне опсеге идентификатора докумената. Репрезентација сваког блока зависи од његове густине: ријетки блокови чувају сортиране низове помака ID-јева докумената, док густи блокови користе битмапе. Ријетки блокови користе галопирајућу претрагу, која напредује у све већим корацима како би прескочила регије листе. Густи блокови омогућавају провјере припадности тражењем бита који одговара документу.

Фреквенција упита неког термина одређује гдје је његова листа објављивања смјештена на диску. Листе које се често претражују чувају се близу једна другој, концентришући вруће податке у мањем региону складиштења. Унутар сваке листе, документи су поређани по одвојеном сигналу корисности тако да се на перспективније кандидате наилази раније.

Листе објављивања се гранају у кратке уграђене записе или дуже блокиране листе, са ријетким низовима и густим битмапама одабраним независно за сваки блок. — Photon бира репрезентацију листе објављивања према дужини и густини блока. Кратке листе се уклапају унутар странице. Дуже листе су подијељене у фиксне опсеге ИД-ова докумената, са сортираним низовима одстојања за ријетке блокове и битмапама за густе блокове.

Укупан квалитет задатака у односу на процијењени укупан трошак модела плус претраге за истих 3.554 изабраних задатака. Скорови су пондерисани бројем задатака, а трошкови покривају цијели скуп задатака. PPLX Fast има скор 64,3% на 59,73 $, у поређењу са 64,0% на 187,60 $ за подразумевана PPLX подешавања, што је отприлике 68% нижи процијењени трошак за исти број задатака.

Алгоритам дијели листе у двије групе. Водеће листе унапређују кретање и предлажу документе кандидате. Листе проба доприносе резултатима тих кандидата, али саме не генеришу кандидате.

Бодовање кандидата комбинује пондерисану покривеност упита и допринос фреквенције, уз нормализацију дужине документа и ограничење добитака од поновљених термина. Photon прво провјерава присуство термина у низовима и битмапама како би ограничио максималн могући скор сваког кандидата. Он чита тачне фреквенције термина само за кандидате који и даље могу испунити праг селекције.

Селекција затим наставља у три корака:

Обилазак: Почните са строгим захтјевом за покривеност упита. Ако се пронађе премало кандидата, поновите поступак са блажим захтјевом.
Задржавање: Кандидати се чувају у ограниченој групи користећи скор који комбинује покривеност и фреквенцију. Како прикупљени најбољи кандидати напредују, праг пријема расте.
Коначна селекција: Коначни резултати за пролаз се бирају из задржаног скупа на основу резултата фреквенције. Свако поље покреће сопствени пролаз, а резултати се спајају помоћу пондера поља.

Алгоритам производи скуп кандидата релевантних докумената који ће се користити у даљем рангирању.

Шест илустративних кандидата докумената приказује одсијецање горње границе и растући праг пријема како се ограничени скуп кандидата побољшава. — Илустративно претраживање ограниченог скупа кандидата. Водеће листе предлажу документе, док горње границе омогућавају да се кандидати испод тренутног прага пријема одсијеку без читања листи сонде или тачних фреквенција. Праг расте како се задржани скуп побољшава. Резултати су измишљени ради илустрације, а задржани кандидати нису загарантовани тачни top-k.

Након што су кандидаткиње странице одабране, фази рангирања су потребне фреквенције термина, покривеност поља и локације и близина појављивања. Добијање ових података кроз обрнути индекс захтијевало би разбацане приступе кроз многе паре термин-документ. У Photon-у чувамо компактан запис по документу који се зове docblob и који садржи фреквенције термина, у којим пољима се термин појавио и гдје се у документу појавио. Као резултат тога, рангирање кандидата захтијева само једну претрагу по документу.

Формат је направљен тако да се избјегне декодирање више него што је потребно. У оквиру docblob-а, поља су груписана по анализатору текста. Свака група чува сортирану листу термина енкодовану помоћу Elias-Fano, тако да се термин упита може директно потражити без претходног ширења цијеле листе. Маска поља означује гдје се термин појавио, бројач фреквенције прати колико често, а стварне позиције се налазе у одвојеним блоковима по пару термин-поље енкодованим као разлике позиција. Само се блокови за термине који су заиста одговарали декодирају, док све остало у запису остаје у компримованом формату.

То селективно декодирање омогућава docblob-у да подржи чување више података по документу без пропорционалног повећања трошкова. Раст записа не намеће више посла по претрази зато што рангирање увијек додирује само дјелове релевантне за подударане тредове умјесто цијелог записа.

Претрага docblob-а декодира маске поља, фреквенције и позиције за упарене термине упита док остале термине оставља компримованим. — Docblob групише податке рангирања у компактан запис по документу. Термини упита се траже у листи термина енкодованој са Elias–Fano; маске поља, фреквенције и блокови позиција обезбеђују податке потребне за упарене термине док неповзани термини остају компримовани. ИД-ови и позиције термина су илустративни.

Гдје је наш претходни систем заказао

Серија читања се дијели на поготке и промашаје кеша, уз асинхрона читања са диска која се преклапају са чекањима на недостајуће записе. — Photon провјерава серију познатих одстојања записа у свом кешу прије издавања читања са диска. Погоци кеша се копирају у припремљени бафер; промашаји се прослеђују кроз io_uring тако да чекања на диск могу да се преклапају, а враћени подаци попуњавају кеш. Записи и временске траке су шематски, а не мјерене латенције.

Рангирање захтијева прибављање карактеристика стотину докумената који се налазе у различитим дјеловима датотеке. Наш претходни систем користио је mmap за мапирање датотеке у виртуелни адресни простор, како би се могла читати преко меморијских показивача. Међутим, приступ страници која није била у меморији и даље је захтијевао читање са диска. Нит је морала да сачека податке прије него што настави израчунавање, а то вријеме чекања се сабирало када је процес морао редом да чита записе који нијесу били у меморији.

Photon користи чињеницу да су помаци записа унапријед познати, тако да можемо да пошаљемо више читања одједном. Овим управља реактор: намјенски радни тредови шаљу серије преко io_uring-а и прослеђују прочитане податке код који их позива. Сваки тред одржава сопствени io_uring; серије се шаљу најмање оптерећеном реактору. Унапријед регистровани описи датотека и базен бафера смањују режијски трошак поновљених читања. Ово асинхроно извршавање омогућава да се чекања на неколико операција преклапају, што смањује кашњење у репу.

Photon сада покреће наш цевовод за претрагу и такође је основа нових брзих подешавања за наш Search API, са кашњењем једног позива за претрагу од 160 ms на p50 и 230 ms на p95. Преко шест јавних референтних мјерења, брза подешавања су смањила процијењени трошак модела плус претраге по задатку за 68% уз одржавање укупног квалитета задатака упоредивог са подразумеваним подешавањима. Данас га објављујемо како би програмери могли да приступе овим побољшањима.

Кеш је дизајниран за серијска читања. Конкретно:

Када дође до поготка, нема засебне алокације меморије. Умјесто тога, подаци се копирају у бафер који је позивајући код унапријед припремио.
Алгоритам производи скуп кандидата релевантних докумената који ће се користити у даљем рангирању.
Photon је дизајниран за два примарна тока рада: опслуживање захтјева за претрагу и преузимање ажурирања из цевовода за обраду.
Он користи учитавање унапријед у CPU кеш, при чему се метаподаци и подаци за предстојеће записе траже унапријед.

Ове оптимизације смањују латенцију без нарушавања перформанси на оптерећењима до којих нам је стало.

Дијаграм расуђивања који упоређује скорове референтних мјерења пондерисане задацима са процијењеним укупним трошком модела и претраге кроз шест конфигурација.

Ова раздвајања рјешавају уско грло опоравка и синхронизације присутне у претходној имплементацији. Пошто се изградња индекса одвијала унутар истог кластера који је опслуживао упите, опоравак неуспјелог чвора или додавање нове копије података могло је значити поновно индексирање докумената на лицу мјеста, процес који је трајао данима и повећавао дјелимичне одговоре током опоравка. Photon уклања ту повезаност; индесери раде као дистрибуирани послови који производи верзионисане индексне структуре спремне за опслуживање независно од услужних чворова, тако да изградња сљедеће верзије индекса више не конкурише са саобраћајем у реалном времену.

Одвојена путања изградње припрема и чува верзионисане индексе сљемова док услужни чворови обрађују захтјеве за претрагу у реалном времену. — Изградња индекса се одвија одвојено од опслуживања упита у реалном времену. Pillar извози изворне податке, YTsaurus припрема верзионисане табеле по сљему, а паралелни индесери уписују структуре индекса спремне за опслуживање у објектну меморију. Услужни чворови учитавају те структуре за преузимање и рангирање; истовременост индесера и број сљемова се конфигуришу независно.

Изградња почиње одабиром докумената за активни индекс и креирањем изворног извоза. Контролер бележи изворну верзију, улазне табеле и очекивани број шарди. MapReduce задаци у YTsaurus-у припремају текст, метаподатке, фрагменте, карактеристике и унапред израчунате угњежђене репрезентације у верзионисаним табелама подељеним по шарди. Сваки индексер стримује припремљену табелу, гради структуре за свој шард и спаја текстуалне сегменте. Спреман индекс, заједно са описом његових компоненти, отпрема се у object storage.

Број сљемова и број истовремено покренутих индесера конфигуришу се независно, тако да се изградња може извршити у неколико таласа, или се више машина може додијелити за паралелни рад. Дистрибуирана припрема и паралелни индесери омогућавају да се цијели веб индекс изгради за неколико сати, што представља значајно побољшање у односу на претходни систем.

Серија читања се дијели на поготке и промашаје кеша, уз асинхрона читања диска која се преклапају са чекањима за недостајуће записе.

Када постоји више услужних група, контролер их ажурира једну по једну. Он прво уклања групу из рутирања брокера и покреће је на новој верзији индекса. Прије опслуживања захтјева, сљемови пролазе кроз посебну фазу загријавања на основу дневника претраге, која унапријед попуњава почетно стање и чини прелазак на стварни саобраћај глађим. Након загријавања, контролер провјерава стање индекса и спремност, затим враћа групу у рутирање. Остале групе настављају да опслужују захтјеве за то вријеме. Пошто је стање операције сачувано, поновно покретање не приморава изградњу да почне испочетка; контролер може поново да закачи припрему која је већ у току, поново користи спреман резултат или настави прекинуту ротацију од сачуваног корака.

Вријемена ажурирања података се разликују међу вертикалама претраге. За вертикале са високим захтјевима за свјежином, испорука документа траје неколико минута. Додатна копија података може се поставити за око пола сата; готови индекси се учитавају и прикачују на сљемове без поновног индексирања изворних докумената.

Једна група за опслуживање учитава и загријава нову верзију индекса изван рутирања брокера док друга група наставља да опслужује упите уживо. — Контролер провјерава да ли је нови индекс потпун, а затим ротира једну по једну групу за опслуживање. Група напушта рутирање брокера, учитава нову верзију, загријава своје кешове упитима дневника претраге и пролази провјере спремности прије враћања на саобраћај. Друге групе настављају са опслуживањем, а сачувано стање контролера омогућава да се прекинута ротација настави.

Ажурирања индекса слиједе одвојеном путањом. Pillar, наш слој за објављивање, припрема податке и чува их у YTsaurus табелама. Индесери претварају ове табеле у индексне структуре које срхови могу да учитају за претрагу. Контролер координира припрему података, изградњу индекса и примену нових верзија индекса на групе за опслуживање. Прије руковања саобраћајем уживо, сваки срх поново извршава праве упите претраге како би загријао своје кешове.

Тестирање оптерећења и евалуације

Након ових провјера, послали смо упите уживо на оба мотора истовремено користећи сенковити саобраћај. Ово нам је омогућило да упоредимо њихове перформансе и резултате на продукцијским радним оптерећењима прије промјене мотора који је опслуживао кориснике. Затим смо омогућили Photon за мале подскупове корисника и постепено проширили увођење, пратећи квалитет и перформансе све вријеме. Прва верзија је прошла тестирање прихватања без регресије квалитета, а ми смо наставили увођење све док Photon није опслуживао сав продукцијски саобраћај.

Специјализоване репрезентације података нам омогућавају да ефикасније складиштимо кључне податке. Компактнији инвертовани индекс смањује количину прочитаних или помјерених података по упиту, побољшавајући кашњење елиминисањем непотребних I/O операција. Ови формати такође омогућавају провјеру да ли се документ појављује на листи без његовог потпуног декодирања, што је својство на које се наша логика пролаза ослања како би контролисала колико посла упит обавља под фиксним буџетом. Оптимизација записа по документу нам омогућава да складиштимо више података по документу за рангирање, а истовремено смањује трошкове скалирања повезане са нашим претходним системом.

Графикон кашњења једног позива за претрагу који приказује медијане које пријављује добављач и доступне процентиле репа, укључујући Exa Instant p90 умјесто p95.

Photon такође смањује количину података која мора остати у меморији. Фиксирање истог Photon скупа података у RAM-у са mlock-ом захтијевало би отприлике 4,6 пута више резидентне меморије него што Photon тренутно користи.

Коначна селекција: Коначни резултати за пролаз бирају се из задржаног скупа на основу скорова фреквенције. Свако поље извршава сопствени пролаз, а резултати се спајају коришћењем пондера поља.

Процијенили смо брзо подешавање на шест референтних мјерења агента: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 и SEAL-Hard. Кроз ове евалуације, имало је најнижу процијењену укупну цијену модела плус претраге и највиши укупни скор задатка међу тестираним конфигурацијама.

Брзо подешавање упарује Photon са рангирањем оптимизованим за токове рада агента, пружајући упоредиве перформансе са подразумеваним подешавањем уз знатно нижу цијену. Међутим, оно долази са компромисом у ширем квалитету претраге. Брзо подешавање користи мање рачунарских ресурса за рангирање него подразумевано подешавање. На интерним референтним мјерењима која покривају упите са дугим репом (long-tail), широку покривеност и разноврсност резултата, постиже 0.24 поена нижи резултат релевантности и приближно 3 процентна поена нижу доступност одговора. Вјерујемо да је ово разуман компромис за токове рада агента, јер сопствено расуђивање и знање модела могу помоћи у компензацији разлике.

Квалитет подразумеваног у односу на брзо преузимање: резултати релевантности 2,45 и 2,21, и доступност одговора 0,596 и 0,567, на скраћеним осама. — Интерно поређење квалитета преузимања између подразумеваног PPLX подешавања и PPLX Fast-а. Релевантност (DCG) пада са 2,45 на 2,21, што је смањење од 0,24 поена; доступност одговора пада са 0,596 на 0,567, што је смањење од 2,9 процентних поена. Два панела користе различите, ненулте основе оса, тако да висине стубова наглашавају празнине, а не пропорционалне разлике.

Препоручујемо брза подешавања за свакодневне агенсне задатке. За изазовнија или двосмислена питања која су мање осјетљива на вријеме, подразумевана подешавања нуде робуснији квалитет, оправдавајући своје веће кашњење и цијену.

Времена ажурирања података се разликују међу вертикалама претраге. За вертикале са високим захтјевима за свјежином, испорука документа траје једноцифрен број минута. додатна копија података може се поставити за око пола сата; спремни индекси се учитавају и прикаче на срхове без поновног индексирања изворних докумената.

Photon је омогућио бржу претрагу кроз Perplexity производе и пружа основу за наше ново брзо подешавање у Search API-ју. Након миграције, p99 латенција преузимања и рангирања пала је са отприлике 800 ms на 65 ms. Наши компактни формати података нам такође омогућавају да складиштимо 2,5 пута више података по документу, дајући преузимању и рангирању приступ богатијим информацијама о документу.

Брза подешавања испоручују кашњење једног позива за претрагу од 160 ms на p50 и 230 ms на p95. Преко шест евалуираних агенсних референтних мјерења, смањио је процијењени трошак модела плус претраге по задатку за 68% у односу на подразумевана подешавања уз одржавање упоредивог укупног квалитета задатака. Ови резултати демонстрирају практичне предности инфраструктуре дизајниране око наших радних оптерећења претраге, како за Perplexity-јеве производе тако и за програмере који граде са нашим API-јем.

Настављамо да побољшавамо перформансе и ефикасност складиштења Photon-а. Наш циљ је да подржимо већи индекс и богатије податке докумената на истом хардверу, уз задржавање брзине претраге како наша оптерећења расту.

BibTeX

@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}
}

Увод

Гдје је наш претходни систем заказао

Гдје се Photon уклапа у претраживачки стек

Дизајнирање Photon-а за наше токове рада

Представе података за проналажење и рангирање

Инвертовани индекс

Кретање кроз листе у оквиру буџета рада

Docblob

Преклапање чекања диска

Смањење броја приступа диску

Миграција и валидација унутар нашег претраживачког стека

Тестирање оптерећења и евалуације

Закључак

Цитат