Photon: Нөлден іздеу және рейтинг қозғалтқышын құру

Кіріспе

Perplexity жасанды интеллектке негізделген іздеу стегі модельдің өз жауаптарын негіздеуі үшін ең мазмұнды мазмұнды шығара отырып, үміткер беттерді іздейді және оларға рейтинг береді. Бастапқыда бұл кезең біз жүйемізге бейімдеген ашық бастапқы кодты қозғалтқышта жұмыс істеді. Дегенмен, біздің индексіміз бен жұмыс жүктемелеріміз өскен сайын, біз қолданыстағы үшінші тарап платформасы шегінде шеше алмаған құндарға, соңғы кідіріске және түйінді қалпына келтіру уақытына қатаң шектеулерге тап болдық.

Бұл қиындықтарды жеңу үшін біз жаңа меншікті іздеу және рейтинг қозғалтқышы Photon жүйесін жасадық. Бұл бет жазбаларына қызмет көрсету үшін бөлінген кілт-мәндер қоймасы CobbleDB және Search API арқылы жасағанымыздай, жасанды интеллектке негізделген іздеу инфрақұрылымын нөлден бастап құру тәсілін жалғастырады.

Photon әрбір сұрауға қажеттіні ғана оқу және декодтау үшін ықшам деректер форматтарын пайдаланады, дискіге қатынауды азайту және күтулерді қабаттастыру үшін пакеттік кэштеу мен асинхронды оқуды қолданады. Индексті құру сұрауларға қызмет көрсетуден бөлек орындалады, бір уақытта бір қызмет көрсету тобын жаңартады және оған тікелей сұрауларды бағыттау алдында оның кэштерін қыздырады.

Photon енді біздің іздеу конвейерімізді қамтамасыз етеді және сонымен қатар p50 мәнінде 160 мс және p95 мәнінде 230 мс бір іздеу шақыруының кідірісі бар іздеу API интерфейсіне арналған жаңа жылдам пресеттің негізі болып табылады. Алты жалпыға қолжетімді бенчмарк бойынша жылдам пресет әдепкі пресетке ұқсас жиынтық тапсырма сапасын сақтай отырып, тапсырма бойынша бағаланған модель мен іздеу құнын 68%-ға төмендетті. Әзірлеушілер бұл жақсартуларды пайдалана алуы үшін біз оны бүгін шығарып жатырмыз.

Ұлғайту

Ұлғайту

Іздеу мен рейтинг қозғалтқышы не талап етеді

Әрбір сұрау үшін іздеу және рейтинг қозғалтқышы іздеу стегінің кідіріс бюджеті шегінде шағын сәйкес беттер жиынтығын таңдау және ретке келтіру үшін үлкен, бөлінген индексті іздейді. Сондай-ақ жүйе бұл жұмыс тікелей сұрауларды баяулатуға жол бермей, жаңа беттер келіп түскенде және бұрынғы беттер өзгерген кезде индексті жаңартып отыруы тиіс.

Біз бірнеше ашық бастапқы кодты опцияларды бағаладық және бастапқы қажеттіліктерімізге сай келетін жетілген, жалпы мақсаттағы іздеу және рейтинг қозғалтқышын таңдадық. Содан кейін біз оны өндірістік масштабта тұрақты кідіріс пен өткізу қабілетін сақтай отырып, архитектурамыз бен жұмыс жүктемелерімізге бейімдедік.

Алдыңғы жүйеміз қай жерде жеткіліксіз болды

Қозғалтқышты өсіп келе жатқан индексімізге бейімдеу үшін өз форгымызды сақтап қалдық, бірақ негізгі шектеулерді шешу платформаның үлкен бөліктерін қайта жобалауды көбірек талап етті. Бірнеше шектеулерді іргетастық архитектуралық өзгерістерсіз шешу қиын болып шықты:

1. Масштабтау шығындары. Біз сақтайтын құжаттар саны да, іздеу және рейтинг үшін қажет әр құжаттағы деректер көлемі де уақыт өте келе өсіп келеді. Бұл масштабтау аппараттық құралдарымызға, әсіресе қолжетімді RAM көлеміне қысым жасады. Шығындарды бақылау үшін бізге ықшам деректер көріністері және жадта не қалатыны мен сұраныс бойынша дискіден не оқылатыны туралы жақсырақ бақылау қажет болды.

2. Нашар соңғы кідірыс. Өндірістік трафикте ескі жүйенің p99 жауап беру уақыты шамамен 800 мс болды. Деректер жиыны қолжетімді RAM көлемінен асып түсті, сондықтан оны толығымен жадта сақтау үшін mlock пайдалана алмадық. Резиденттік емес деректерге қол жеткізу беттің негізгі ақауларын тудыруы мүмкін, бұл операциялық жүйе дискіден оқып жатқанда сұраудың орындалуын тоқтатады.

Сондай-ақ қозғалтқыш негізгі диск индексін жадтан тазартылған кішірек индекстермен мезгіл-мезгіл біріктіріп отырды. Осы диск индексін біріктіру процесі кезінде бет ақауларының саны тіпті жоғары көтеріліп, 10-15 минут ішінде p99 кідірісі шамамен 1.2 с жетті. Кэштер қызған сайын бет ақауларының жиілігі мен кідіріс екеуі де азайды, бұл суық оқулар шыңдардың негізгі үлескері болғанын болжайды. Деректерді алдын ала жүктеу және индексті қыздыру шыңдарды азайтты, бірақ жоғары соңғы кідірісті тиісті түрде шешпеді.

3. Ұзақ қалпына келтіру және синхрондау. Алдыңғы жүйеде қосымша кластерді орналастыру және оның деректерін синхрондау аптадан астам уақыт алуы мүмкін. Синхрондау сонымен қатар қосымша деректер көшірмелерін сақтау үшін түйіндер топтарын қосқанда немесе түйін істен шыққаннан кейін қалпына келтіргенде қажет болды. Қалпына келтіру кезінде іздеу жауаптарының үлкенірек үлесі ішінара болды, бұл соңғы жауап сапасының ұпайларын төмендетті.

Нәтижесінде біз өз форгымызды бейімдеуді және қолдауды жалғастырғаннан гөрі, нөлден бастап құру қарапайым әрі арзанырақ болады деген тұжырымға келдік. Алдыңғы жүйені басқару тәжірибесіне сүйене отырып, шағын инженерлік команда Photon құру үшін тұрақты код жазу агенттерінің тобымен бірге жұмыс істеді.

Photon іздеу стегіне қалай сәйкес келеді

Photon екі негізгі жұмыс процесі үшін жасалған: іздеу сұрауларына қызмет көрсету және өңдеу конвейерінен жаңартуларды қабылдау.

Жоғары деңгейлі іздеу қызметінің сұрауы жүктемені теңгергіш арқылы Photon брокеріне жетеді. Брокер шард тобын таңдайды және сұрауды әрбір шардқа жібереді, бұл ретте уақыттың өтінін бақылайды және қажет болған жағдайда қосымша сұраулар жібереді.

Әрбір шард іздеуді, бастапқы рейтингті және екінші кезеңдегі рейтингті орындайды, содан кейін өздерінің ең жақсы үміткерлерін брокерге қайтарады. Брокер бұл үміткерлерді бір рейтингтік тізімге біріктіреді және тиісті шардтардан таңдалған беттер үшін маңызды құжат өрістерін әкеледі. Содан кейін ол бұл нәтижелерді агенттің негізделген жауап генерациялауы үшін қажетті бет мазмұнын жинайтын жоғары деңгейлі іздеу қызметіне қайтарады.

Индексті жаңарту бөлек жолмен жүреді. Жариялау қабатымыз Pillar деректерді дайындайды және оны YTsaurus кестелерінде сақтайды. Индексаторлар бұл кестелерді шардтар іздеу үшін жүктей алатын индекс құрылымдарына түрлендіреді. Контроллер деректерді дайындауды, индексті құруды және жаңа индекс нұсқаларын қызмет көрсету топтарына орналастыруды үйлестіреді. Тікелей трафикпен жұмыс істеу алдында әр шард өз кэштерін қыздыру үшін нақты іздеу сұрауларын қайта ойнатады.

Ұлғайту

Photon жүйесін жұмыс процестерімізге арналтып жобалау

Үш жобалау шешімі Photon жүйесін жұмыс жүктемемізге өте қолайлы етеді: ықшам деректер көріністері, кэштеу және асинхронды диск оқулары, және индекс жаңартуларын сұрауға қызмет көрсетуден бөлу.

Іздеу мен рейтингке арналған деректер көріністері

Іздеу мен рейтинг құжат деректеріне әртүрлі тәсілдермен қол жеткізеді. Лексикалық іздеу сұрау терминдерінен басталады және оларды қамтитын құжаттарды табады. Содан кейін рейтингке әрбір таңдалған құжат туралы егжей-тегжейлі ақпарат, соның ішінде термин жиіліктері мен позициялары қажет.

Photon бұл қатынау үлгілерін қолдау үшін екі өзара толықтыратын көріністі пайдаланады. Инверзделген индекс үміткерлерді таңдауды қолдау үшін орналастыру тізімі деп аталатын әр термин үшін сәйкес келетін құжаттар тізімін сақтайды. Жеке құжат жазбалары рейтинг үшін қажетті деректерді береді. Сондай-ақ біз фиксирленген жұмыс бюджеті шегінде таңдауды жақсарту үшін орналастыру тізімдерінің қалай сақталатынын және өтетінін оңтайландырамыз.

Арнайы деректер көріністері негізгі деректерді тиімдірек сақтауға мүмкіндіек береді. Анағұрлым ықшам инверзделген индекс әр сұрау үшін оқылатын немесе жылжытылатын деректер көлемін азайтады, бұл қажетсіз I/O операцияларын жою арқылы кідірісті жақсартады. Бұл пішімдер сонымен қатар сұрау тізімді бекітілген бюджет бойынша қаншалықты жұмыс істейтінін басқару үшін біздің өту логикамыз сүйенетін қасиет — толық декодтамай-ақ құжаттың тізімде бар-жоғын тексеруге мүмкіндік береді. Әр құжат жазбаларын оңтайландыру рейтинг үшін әр құжатқа көбірек деректерді сақтауға, сонымен бірге алдыңғы жүйемізбен байланысты масштабтау шығындарын азайтуға мүмкіндік береді.

Инверзделген индекс

Әр термин үшін инверзделген индекс орналастыру тізімін сақтайды. Бұл тізімдер бірнеше құжаттан бастап миллиондаған құжаттарға дейін болуы мүмкін, сондықтан бірде-бір пішім әр тізім үшін жақсы жұмыс істемейді. Photon пішімді термин бар құжаттар санына қарай таңдайды.

Қысқа тізімдер бір бетке сыятын және блок кестесін қажет етпейтін кірістірілген көріністі пайдаланады. Кірістірілген пішімге сыймайтын ұзынырақ тізімдер құжат идентификаторларының бекітілген диапазондарын қамтитын блоктарға бөлінеді. Әр блок көрінісі оның тығыздығына байланысты: сирек блоктар құжат идентификаторының ығысуларының сұрыпталған массивтерін сақтайды, ал тығыз блоктар битмаптарды пайдаланады. Сирек блоктар тізім аймақтарын өткі жіберу үшін үнемі үлкен қадамдармен алға жылжитын галлопирленген іздеуді пайдаланады. Тығыз блоктар құжатқа сәйкес келетін битті іздеу арқылы мүшелікті тексеруге мүмкіндік береді.

Терминнің сұрау жиілігі оның орналастыру тізімінің дискіде қай жерде орналасатынын анықтайды. Жиі сұралатын тізімдер бір-біріне жақын сақталып, ыстық деректерді кішірек сақтау аймағында шоғырландырады. Әр тізім ішінде құжаттар бөлек пайдалылық сигналы бойынша ретке келтіріледі, осылайша перспективалы үміткерлер ертерек кездеседі.

Ұлғайту

Жұмыс бюджеті шегінде тізімдерді өту

Үміткерді таңдау ықтимал қатысты құжаттарды табу үшін орналастыру тізімдерін өтуді талап етеді. Әр тізімді түгел сканерлеу қымбатқа түседі, сондықтан Photon басқа тізімдердегі сәйкестіктерді ескере отырып, тек кейбір тізімдерден өтетін WAND тәрізді алгоритмді пайдаланады.

Алгоритм тізімдерді екі топқа бөледі. Жетекші тізімдер өтуді алға жылжытады және үміткер құжаттарды ұсынады. Зондтау тізімдері сол үміткерлердің ұпайларына үлес қосады, бірақ өзіндік үміткерлерді тудырмайды.

Үміткерлерді бағалау салмақталған сұрау терминінің қамтылуы мен жиілік үлесін біріктіреді, құжат ұзындығын қалыпқа келтірумен және қайталанатын терминдерден түсетін өсімдерге шектеу қояды. Photon әр үміткердің мүмкін болатын ең жоғары ұпайын шектеу үшін алдымен массивтер мен битмаптардағы терминдердің бар-жоғын тексереді. Ол дәл термин жиіліктерін тек таңдау табалдырығына сәйкес келетін үміткерлер үшін ғана оқиды.

Таңдау содан кейін үш қадамнан тұрады:

• Өту: Қатаң сұрауды қамту талабынан бастаңыз. Тым аз үміткерлер табылса, жұмсартылған талаппен қайталаңыз.
• Сақтау: Үміткерлер қамту мен жиілікті біріктіретін ұпайды пайдалана отырып, шектелген жиынтықта сақталады. Жиналған үздік үміткерлер жақсарған сайын қабылдау шегі көтеріледі.
• Соңғы таңдау: Өту үшін соңғы нәтижелер жиілік ұпайлары негізінде сақталған жиынтықтан таңдалады. Әр өріс өз өтуін орындайды, ал нәтижелер өріс салмақтары арқылы біріктіріледі.

Алгоритм әрі қарайғы рейтингте пайдаланылатын тиісті құжаттардың үміткерлер жиынтығын шығарады.

Ұлғайту

Docblob

Үміткер беттер таңдалғаннан кейін рейтинг фазасына термин жиіліктері, өрістің қамтылуы және пайда болу орындары мен жақындығы қажет. Инверзделген индекс арқылы бұл деректерді алу көптеген термин-құжат жұптары бойынша шашыраңқы қатынауды қажет етеді. Photon жүйесінде біз термин жиіліктерін, термин пайда болған өрістерді және құжатта қай жерде орын алғанын қамтитын docblob деп аталатын әр құжатқа арналған ықшам жазбаны сақтаймыз. Нәтижесінде үміткерге рейтинг беру әр құжат үшін тек бір іздеуді талап етеді.

Пішім қажеттіктен артық декодтамау үшін жасалған. docblob ішінде өрістер мәтін анализаторы бойынша топтастырылған. Әрбір топ Elias-Fano көмегімен кодталған сұрыпталған термин тізімін сақтайды, осылайша сұрау терминін бірінші болып бүкіл тізімді кеңейтпей-ақ тікелей іздеуге болады. Өріс маскасы терминнің қай жерде пайда болғанын белгілейді, жиілік санағы қаншалықты жиі екенін бақылайды, ал нақты позициялар позиция айырмашылықтары ретінде кодталған термин-өріс жұбы бойынша жеке блоктарда тұрады. Тек шын мәнінде сәйкес келетін терминдерге арналған блоктар ғана декодталады, ал жазбадағы қалғандардың бәрі сығылған пішімде қалады.

Бұл таңдамалы декодтау docblob-қа бағаның пропорционалды өсуінсіз әр құжат үшін көбірек деректерді сақтауға қолдау көрсетуге мүмкіндік береді. Жазбаны ұлғайту іздеу басына келетін жұмысты көбейтпейді, өйткені рейтинг тек бүкіл жазбаны емес, сәйкес келетін терминдерге қатысты бөліктерге ғана әсер етеді.

Ұлғайту

Пакеттік оқулар және жадпен жұмыс істеу

Тиімдірек деректер көріністерімен де, жедел жад басқа ресурстарға қарағанда ертерек таусылады, сондықтан дискіде сақталған деректерге жиі қол жеткізу қажет болады. Photon бұл қатынауларды жылдамдату үшін асинхронды диск оқуларын және пакеттік оқулар үшін оңтайландырылған кэшті пайдаланады, әр сұрау бойынша күту уақытын қысқартады. Бұл алдыңғы жүйемен салыстырғанда соңғы кідірістің айтарлықтай жақсаруына ықпал етеді.

Ұлғайту

Қабаттасқан диск күтулері

Рейтинг файлдың әртүрлі бөліктерінде орналасқан жүздеген құжаттардың мүмкіндіктерін алуды талап етеді. Біздің алдыңғы жүйеміз файлды виртуалды мекенжай кеңістігіне картаға түсіру үшін mmap пайдаланды, оны жад көрсеткіштері арқылы оқуға болады. Дегенмен, жадта жоқ бетке қол жеткізу әлі де диск оқуын талап етеді. Тред есептеуді жалғастырмас бұрын деректерді күтуге мәжбүр болды және бұл күту уақыты процесс суық жазбаларды тізбекті түрде оқуы қажет болған кезде жиналды.

Photon жазбалардың ығысуы алдын ала белгілі екендігін пайдаланады, сондықтан біз бірнеше оқуды бірден жібере аламыз. Бұны реактор басқарады: арнайы жұмыс тректері пакеттерді io_uring арқылы жібереді және оқыған деректерін шақырушы кодқа береді. Әр тред өзінің io_uring жүйесін сақтайды; пакеттер ең аз жүктелген реакторға жіберіледі. Алдын ала тіркелген файл дескрипторлары мен буфер пулдары қайталанатын оқулардың шығынын азайтады. Бұл асинхронды орындау бірнеше операцияны күтуге қабаттасуға мүмкіндік береді, бұл соңғы кідірісті азайтады.

Диск қатынауларының санын азайту

Оқуларды жіберу алдында Photon жадтағы кэште барлық пакетті тексереді. Дискіге тек жоқ жазбалардың сұраулары ғана келеді; содан кейін оқылған деректер кэшті толтырады.

Кэш топтастырылған оқу үшін жасалған. Атап айтқанда:

• Табыс кезінде бөлек бөлу жоқ. Оның орнына деректер шақырушы кодпен алдын ала дайындалған буферге көшіріледі.
• Оқушы тарапынан құлыпты алу жоқ. Оның орнына ол деректер нұсқасын тексереді және егер ол жазумен қақтығысса, қайта әрекеттейді.
• Ол әр оқуда ортақ LRU тізімін жаңартуды талап етудің орнына CLOCK эвикциясын пайдаланады.
• Ол алдағы жазбаларға арналған метадеректер мен деректер алдын ала сұралатын CPU кэшін алдын ала алуды пайдаланады.

Бұл оңтайландырулар біз маңызды деп санайтын жұмыс жүктемелеріндегі өнімділікке зиян келтірместен кідірісті азайтады.

Индексті қызмет көрсетуден бөлек құру және жаңарту

Photon жүйесінде индексті құру және сұрауларға қызмет көрсету әртүрлі түйіндерде жұмыс істейді. Индексаторлар деректерді дайын сақтау құрылымдарына түрлендіреді, ал қызмет көрсету түйіндері оларды оқиды және іздеу мен рейтингті орындайды. Нәтижесінде индексті құру іздеу сұрауларымен процессор үшін бәсекелеспейді және бұл тапсырмаларға арналған ресурстар дербес масштабталуы мүмкін.

Бұл бөлу алдыңғы іске асыруда бар қалпына келтіру және синхрондау кедергілерін шешеді. Индексті құру сұрауларға қызмет көрсеткен кластердің ішінде жұмыс істегендіктен, істен шыққан түйінді қалпына келтіру немесе деректердің жаңа көшірмесін қосу құжаттарды орнында қайта индекстеуді білдіруі мүмкін еді, бұл процесс бірнеше күнді алды және қалпына келтіру кезінде ішінара жауаптарды көбейтті. Photon бұл байланысты жояды; индексаторлар қызмет көрсету түйіндерінен тәуелсіз нұсқаланған, қызмет көрсетуге дайын индекс құрылымдарын шығаратын бөлінген жұмыстар ретінде жұмыс істейді.

Ұлғайту

Дайындық және бөлінген құрастыру

Құрастыру белсенді индекс үшін құжаттарды таңдаудан және бастапқы экспортты шығарудан басталады. Контроллер бастапқы нұсқаны, кіріс кестелерін және шардтардың күтілетін санын жазады. YTsaurus жүйесіндегі MapReduce жұмыстары мәтінді, метадеректерді, фрагменттерді, мүмкіндіктерді және алдын ала есептелген эмбеддингтерді шард бойынша бөлінген нұсқалы кестелерге дайындайды. Әрбір индексатор дайындалған кестені ағынмен жібереді, өз шард құрылымдарын құрастырады және мәтіндік сегменттерді біріктіреді. Дайын индекс оның компоненттерінің сипаттамасымен бірге нысандық сақтау орнына жүктеледі.

Шардтар саны мен бір уақытта жұмыс істейтін индексаторлар саны дербес конфигурацияланады, сондықтан құрастыру бірнеше толқынмен жұмыс істей алады немесе параллель жұмыс істеу үшін көбірек машиналар бөлінуі мүмкін. Бөлінген дайындық пен параллель индексаторлар прецедентсіз жылдамдықпен толық веб-индексті бір сағат ішінде құруға мүмкіндік береді.

Жаңа нұсқаны орналастыру

Орналастыру алдында контроллер жаңа индекстің дайын екенін тексереді. Егер деректер толық болмаса, орналастыру автоматты түрде бұғатталады.

Бірнеше қызмет көрсету топтары болған кезде контроллер оларды бір-бірден жаңартады. Ол алдымен топты брокерді бағыттаудан шығарады және оны жаңа индекс нұсқасына қосады. Сұрауларға қызмет көрсету алдында шардтар бастапқы күйді алдын ала толтыратын және нақты трафикке ауысуды тегістейтін іздеу журналдарына негізделген бөлек қыздыру кезеңінен өтеді. Қыздырудан кейін контроллер индекс күйі мен дайындығын тексереді, содан кейін топты бағыттауға қайтарады. Басқа топтар бұл уақытта сұрауларға қызмет көрсетуді жалғастырады. Операция күйі сақталатындықтан, қайта іске қосу құрастыруды қайта бастауға мәжбүр етпейді; контроллер дайындыққа қайта қосыла алады.

Деректерді жаңарту уақыты іздеу вертикалдары бойынша өзгереді. Жоғары балғындық талаптары бар вертикалдар үшін құжатты жеткізу бір минутты алады. Деректердің қосымша көшірмесін жарты сағат ішінде орналастыруға болады; дайын индекстер бастапқы құжаттарды қайта индекстеусіз жүктеледі және шардтарға қосылады.

Ұлғайту

Іздеу стегіміздегі миграция және тексеру

Біздің бірінші мақсатымыз ескі жүйені жауап беру уақытын қысқарта отырып, функционалдылық пен іздеу сапасын сақтайтын қозғалтқышпен алмастыру болды. Біз Photon жүйесін тікелей трафикке ауысу алдында қайталанатын жүктеме сынақтарынан және офлайн сапаны бағалаудан бастап кезең-кезеңімен растадық. Photon қазір ескі жүйеге қарағанда едәуір төмен жауап беру уақытымен өндірістік іздеу стегімізде іздеу мен рейтингті қамтамасыз етеді.

Жүктеме сынағы және бағалаулар

Өнімділікті сынау үшін біз іздеу журналдарымыздағы сұрауларды конфегурацияланатын келу жылдамдығымен қайта ойнататын жүктемені сынау құралын жасадық. Ол іске қосулар арасындағы нәтижелерді салыстырады және байқалған өнімділік айырмашылықтарының тұрақты екенін бағалау үшін статистикалық сынақтарды қолданады. Бөлек, сапа регрессияларын тексеру үшін біз Photon пен ескі жүйені ішкі офлайн бағалау жүйелеріміздегі бірдей деректер жиынында бағаладық.

Осы тексерулерден кейін біз көлеңкелі трафикті пайдалана отырып, екі қозғалтқышқа бір уақытта тікелей сұраулар жібердік. Бұл пайдаланушыларға қызмет көрсететін қозғалтқышты өзгертпес бұрын олардың өнімділігі мен өндірістік жұмыс жүктемелеріндегі нәтижелерін салыстыруға мүмкіндік берді. Содан кейін біз пайдаланушылардың шағын топтары үшін Photon мүмкіндігін қостық және сапа мен өнімділікті бақылай отырып, біртіндеп кеңейттік. Бірінші нұсқа сапаның нашарлауынсыз қабылдау сынағынан өтті және біз Photon барлық өндірістік трафикке қызмет көрсеткенше таратуды жалғастырдық.

Өндірісте өлшенген жақсартулар

Өндірістік жұмыс процесімізде p99 жауап беру уақыты ескі жүйедегі шамамен 800 мс-тен Photon жүйесіндегі шамамен 65 мс-ке дейін төмендеді. Бұл өлшеу Photon ішіндегі барлық кезеңдерді қамтиды, бірақ жоғары деңгейлі іздеу стегіндегі кейінгі кезеңдерді қамтымайды. Сондай-ақ біз бұрын индекс нұсқаларын ауыстырумен байланысты болған кідіріс шыңдарын байқамаймыз.

Photon әр құжат үшін шамамен 2.5 есе көп деректерді сақтай отырып, ескі жүйенің контент түйіндеріне қарағанда шамамен 20%-ға аз эквивалентті қызмет көрсету машиналарын пайдаланады. Миграциядан кейін біз бұл қосымша деректерді рейтинг сапасын ескі жүйеден асырып жақсарту үшін пайдаландық.

Сонымен қатар Photon жадта қалуы тиіс деректер көлемін де азайтады. Дәл сол Photon деректер жинағын mlock көмегімен RAM жадында бекіту Photon қазір пайдаланып жатқан тұрақты жад көлемінен шамамен 4,6 есе көп орынды қажет етер еді.

Жылдам Search API пресетін бағалау

Сондай-ақ біз Photon жүйесін кідіріске сезімтал жұмыс процестеріне арналған Іздеу API интерфейсіне арналған жаңа жылдам пресеттің негізі ретінде пайдаландық. Біздің өлшеулеріміз бойынша, жылдам пресет үшін бір іздеу шақыруының кідірісі p50 мәнінде 160 мс және p95 мәнінде 230 мс, бұл хабарланған соңғы перцентильдер әртүрлі болғанымен, басқа Іздеу API провайдерлерінің өздері хабарлаған сандарынан төмен немесе соған салыстырмалы.

Біз жылдам пресетті алты агенттік бенчмарк бойынша бағаладық: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 және SEAL-Hard. Осы бағалаулар бойынша ол сыналған конфигурациялар арасында ең төменгі болжалды жалпы модель-плюс-іздеу құнына және ең жоғары жиынтық тапсырма ұпайына ие болды.

Жылдам пресет Photon жүйесін агенттік жұмыс процестері үшін оңтайландырылған рейтингпен жұптастырып, едәуір төмен құнымен әдепкі пресетке салыстырмалы өнімділікті қамтамасыз етеді. Дегенмен, ол кеңірек іздеу сапасында ымыраға келумен келеді. Жылдам пресет рейтинг үшін әдепкі пресетке қарағанда аз есептеулерді пайдаланады. Ұзақ созылатын сұрауларды, кең қамтуды және нәтижелердің әртүрлілігін қамтитын ішкі бенчмарктарда ол сәйкестік бойынша 0.24 тармаққа төмен және жауап қолжетімділігі бойынша шамамен 3 пайыздық тармаққа төмен нәтиже көрсетеді. Біз бұл модельдің өзіндік пайымдауы мен білімі айырмашылықтың орнын толтыруға көмектесетіндіктен, агенттік жұмыс процестері үшін қолайлы ымыра деп есептейміз.

Ұлғайту

Күнделікті агенттік тапсырмалар үшін жылдам пресетті ұсынамыз. Уақытты аз талап ететін күрделірек немесе түсініксіз сұрақтар үшін әдепкі пресет жоғары кідіріс пен құнын ақтайтын сенімдірек сапаны ұсынады.

Қорытынды

Біз іздеу стегімізді Rust негізіндегі меншікті инфраструктураға тұрақты түрде көшіріп жатырмыз. Ашық бастапқы кодты қозғалтқышты біздің реттелетін іздеу және рейтинг қозғалтқышымыз Photon жүйесімен алмастыру — соңғы қадам. Photon бізге әр қабатты жұмыс жүктемелеріміз үшін оңтайландыруға мүмкіндік бере отырып, деректер көріністерін, оқулардың қалай ұйымдастырылатынын және жаңа индекстердің қалай орналастырылатынын толық бақылауға мүмкіндік береді.

Photon Perplexity өнімдері арқылы жылдамырақ іздеуге мүмкіндік берді және Іздеу API интерфейсіндегі жаңа жылдам пресетіміздің негізін қамтамасыз етеді. Миграциядан кейін p99 іздеу және рейтинг кідірісі шамамен 800 мс-тен 65 мс-ке дейін төмендеді. Біздің ықшам деректер форматтарымыз сонымен қатар іздеу және рейтингке бай құжат ақпаратына қол жеткізуге мүмкіндік бере отырып, әр құжат үшін 2.5 есе көп деректерді сақтауға мүмкіндік береді.

Жылдам пресет p50 мәнінде 160 мс және p95 мәнінде 230 мс бір іздеу шақыруының кідірісін қамтамасыз етеді. Бағаланған алты агенттік тесттер бойынша ол әдепкі пресетпен салыстырғанда тапсырма бойынша бағаланған модель мен іздеу құнын 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}
}