Іздеуді код генерациясы ретінде қайта қарастыру

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

Дәстүрлі іздеу құбырлары агенттер дәуірінде барған сайын ескіріп барады деп санаймыз. Дәстүрлі іздеу сұрауларға жауап береді, бірақ бүгінгі агенттер сан алуан пішіндегі тапсырмаларды орындайды. Мұндай тапсырмалар агенттерден өз harness-терінің ішінде тапсырмаға тән алу стратегияларын тікелей анықтауды талап етеді. Perplexity Computer ішінде біз бір ғана тапсырма бірнеше минуттың ішінде жүздеген, тіпті мыңдаған алу операциясын іске қосатын жағдайларды көрдік: бұл адамдар үшін мүмкін емес, бірақ агенттер үшін мүлде табиғи жұмыс процесі.

Мұндай әлемде іздеудің өзі агенттік сипатқа ие болуы керек, ал оның құрылыс блоктарына агент harness-інің ішінде тікелей SDK ретінде қол жеткізуге болуға тиіс. Біз Perplexity-дің жаңа эталондық іздеу архитектурасы ретінде Search as Code (SaC) шешімін ұсынып отырмыз.

Perplexity іздеу стегі біздің қолданбаларымыз бен API платформамыз арқылы секунд сайын мыңдаған сұрауды өңдейді. 2025 жылдың қыркүйегінде біз іздеу жүйелеріміздің бірінші архитектуралық шолуын жарияладық. Осы жүйелердегі тұрақты инновациялар Search API, Agent API және Computer сияқты жаңа ұсыныстардың іске қосылуын қолдады, ал өзін-өзі жетілдіру циклдары іздеу стегін әр күн сайын пайдаланушыларға жақсырақ қызмет көрсету үшін оңтайландырды.

Дәстүрлі түрде AI жүйелері іздеуді біртұтас жүйе ретінде қарастырды: AI моделі сұрау жібереді, іздеу жүйесі өзінің алдын ала анықталған жұмыс процесін орындайды, ал модель нәтижелерді мәнмәтін ретінде тұтынады. Көп жағдайда бұл AI-дің алғашқы пайдаланушыларының қажеттіліктерін қанағаттандыру үшін жеткілікті болды. Олардың сұрауларының салыстырмалы түрде қарапайымдылығын ескерсек, іздеу жұмыс процесінің қалай жасалғаны немесе оның архитектурасы берілген тапсырма үшін оңтайлы болып табылатыны туралы алаңдауға ешқандай себеп болмады. Әдепкі интерфейстер (функцияларды шақыру және MCP) сияқты әдепкі параметрлер де жеткілікті деп есептелді.

Дәстүрлі іздеу архитектуралары модельдер тізбекті түрде шақыратын жалғыз бекітілген жүйені ұсынады, ал Search as Code агенттер жасалған код арқылы құрастыратын атомдандырылған іздеу элементтерін ұсынады.

Дегенмен бүгін бұл тәсіл ай өткен сайын одан әрі ескіріп барады. Пайдаланушылар AI-дан бір реттік талдаудан әлдеқайда көбірек нәрсе күтеді. Олар агенттердің тапсырмаларды басынан аяғына дейін сағаттар, тіпті күндер бойы орындағанын қалайды. Мұндай тапсырмалар күрделі, ашық аяқталған және ақпаратқа деген қажеттілігі жағынан өте құбылмалы болуы мүмкін, ал монолитті архитектуралар осы талаптардың салмағына шыдамай, шайқалып тұр.

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

Дәстүрлі іздеу жүйелері осындай басқару деңгейін ескеріп жасалмаған. Өйткені, ұсынылған жағдайдың өзінде адам пайдаланушылардан іздеу жұмыс процесінің ішкі құрылымын жіті басқару күтілмейді. Ерте кезеңдегі AI модельдері іздеуді тек функция шақырулары мен MCP сызықтық траекториясы арқылы ғана басқара алды. Бірақ кодты жасай алатын агент орталарымен жұмыс істейтін бүгінгі жетілдірілген модельдер компьютерлік код арқылы елестетуге болатын кез келген есептеу элементтерін жіті басқара алады. Біздің міндетіміз – дұрыс элементтерді ұсыну.

Бұл қажеттілікті қанағаттандыру үшін біз өнімдерімізде жаңа іздеу архитектурасын енгізіп жатырмыз: Search as Code (SaC). Бұл жаңа архитектура модельдерге соңғы нәтижелерді ғана тұтынудың орнына, іздеу стегінің ішіне енуге мүмкіндік береді. Негізгі идея қарапайым: біз іздеу стегінің компоненттерін SDK ішіндегі элементтер ретінде ұсынамыз. Іздеуді қажет ететін кез келген сұрау үшін модель бұл элементтерді сол сұрауға арнайы бейімделген іздеу жұмыс процесіне сұраныс бойынша жинайды.

Бұл жұмыс процесін құрастыру қауіпсіз Sandbox ішінде кодты генерациялау және орындау арқылы жүзеге асырылады. Іздеудің басқа код генерациясына негізделген тәсілдерінен айырмашылығы, біз дәстүрлі іздеу API интерфейсін қабыққа немесе тілдің орындалу ортасына жай ғана орналастырмаймыз. Оның орнына біз іздеудің жеке құрылыс блоктарын мүмкіндігінше атомдық деңгейде ұсынатын Agentic Search SDK жүйесін мұқият әзірледік.

Search as Code (SaC) әртүрлі тестілеу жиынтықтары бойынша агенттік іздеудің өнімділік шекарасын кеңейтеді.

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

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

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

Нәтижесінде адамдарға арналған іздеу жүйелері енгізу сұрауы үшін алғашқы n нәтижені қамтитын адамға қолайлы іздеу жүйесінің нәтижелері беттерін (SERP) шығаруға бағытталған ортақ біртұтас архитектураға келді. Бұл үлгі тұтынушылық іздеудегі онжылдықтар бойы прогреске қолдау көрсетті. Бұл – жылдам, таныс және адамның шолуы үшін өте тиімді.

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

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

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

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

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

Ықшам емес мәнмәтін. AI модельдері мәнмәтіннің сапасы мен ықшамдылығына сезімтал. Сапа да, ықшамдылық та сұрауға өте тәуелді және біртұтас іздеу жұмыс процестері барлық сұраулар бойынша оңтайлы жұмыс істеуге арналмаған. Мысалы, егер модельге бір ғана өте нақты ақпарат қажет болса, бірақ ол тек еске түсіруге (recall) басымдық беретін аяғына дейінгі іздеу соңғы нүктесіне қол жеткізе алса, бұл соңғы нүктені пайдалану модель мәнмәтініне үлкен көлемдегі маңызсыз ақпаратты енгізеді. Екінші жағынан, егер модельге әрқайсысы әртүрлі іздеу стратегияларын қажет ететін көптеген ақпарат бөліктері қажет болса, ол барлығы үшін бірдей суб-оңтайлы жұмыс процесін тізбекті түрде шақыруға мәжбүр болуы мүмкін, бұл шығындардың өсуіне және шулы мәнмәтінге әкеледі.

Домендік білімді пайдалана алмау. Көп жағдайда модель іздеу стратегиясын бағыттауы тиіс домендік білімге (оның оқытылуынан, Agent Skill, жадынан немесе LLM траекториясындағы алдыңғы токендерден) ие болуы мүмкін. Алайда, қатаң іздеу интерфейсі модельге бұл білімді пайдалануға кедергі жасайды. Мысалы, модель белгілі бір сұрау үшін лексикалық және семантикалық сигналдарды белгілі бір жолмен біріктіру, белгілі бір көздерге басымдық беру немесе нәтижелерді арнайы кілт бойынша жинақтау керектігін түсінуі мүмкін. Егер бұл түсініктер сұрау параметрлері арқылы жүзеге асырыла алмаса, модель оларға шынымен әрекет ете алмайды.

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

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

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

AI-нативті іздеу үшін дұрыс шекара стекте төмендетілген болуы керек екенін біз бұрыннан болжағанбыз. Модельдер іздеу жүйесін жай ғана шақырмауы тиіс. Олар арнайы тапсырма талап еткендей іздеу стегінің жеке бөліктерін үйлестіре алуы керек. Бұл түбегейлі басқа архитектураны талап етеді.

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

Біздің жаңа Search as Code (SaC) архитектурамыз бұл қағиданы жүзеге асырады. SaC жүйесінде бірде-бір іздеу операциясы функцияны шақыру немесе MCP интерфейсі арқылы жіберілмейді. Барлық операциялар модель жасаған Python коды арқылы үйлестіріледі. Ең қарапайым іздеу қажеттіліктері үшін бұл код жоғары деңгейдегі іздеу соңғы нүктесіне жасалған бірнеше сұраудан тұруы мүмкін. Бірақ күрделі тапсырмалар үшін код шартты орындауды, асинхрондылықты, параллелизмді және төмен деңгейдегі элементтердің кең ауқымына қоңырауларды қамтитын қажеттілікке қарай күрделі бола алады.

Search as Code (SaC) архитектурасы модельдерден, есептеу Sandbox орталарынан және Perplexity іздеу инфраструктурасының үстінде орналасқан Agentic Search SDK жүйесінен тұратын стекке сүйенеді.

SaC өзара тығыз байланысқан үш қабатты қамтиды:

Модельдер басқару панелі ретінде қызмет етеді. Олар пайдаланушының (немесе ата-аналық агенттің) нұсқауын пайымдайды, нұсқауды тапсырмаларға бөледі, әр тапсырма үшін қандай іздеу және өңдеу жұмыс процестері қажет екенін шешеді және бұл жұмыс процестерін іске асыру үшін код жасайды.

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

Біздің Agentic Search SDK Perplexity іздеу стегін құрастырмалы элементтер ретінде ұсынады. Ол төмен деңгейдегі іздеу операцияларынан жоғары деңгейдегі семантикалық талдауға дейінгі құрылыс блоктарын қамтамасыз етеді. SDK Sandbox орталарының орындалу орталарына енгізілген, бұл модельдерге бір қорытынды жасау қадамы ішінде мыңға жуық операцияны үйлестіруге мүмкіндік береді. Төменде біз әр қабат үшін дизайн шешімдерін талқылаймыз.

Agentic Search SDK бағдарламаланатын іздеу үшін құрылыс блоктарын анықтайды. Ең бастысы, біздің SDK кітапхана ретінде топтастырылған алдын ала бар іздеу API емес. Соңғы vài айда біздің инженерлік топ іздеу стегімізді модульдік, құрастырмалы элементтерге қайта құрды. Біз модель тапсырмаға тән іздеу жұмыс процестерін үйлестіре алатын әлдеқайда қуатты кенепті қамтамасыз ету үшін Agentic Search SDK құрдық.

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

Орындалу ортасын таңдау: Біз SDK орындалу ортасы ретінде Python, Rust, TypeScript және Bash нұсқаларын қарастырдық. Оның кең таралуы мен деректерді өңдеу кітапханаларының экосистемасын ескере отырып, Python ең табиғи үйлесім болады деп болжадық. Ішкі тестілеу бұның солай екенін растады және қазір енгізіліп жатқан SDK нұсқасы Python негізінде жасалған. Ол агент тәжірибесін ең жақсы түрде қамтамасыз етуді жалғастыруын қамтамасыз ету үшін біз орындалу ортасын таңдауды мезгіл-мезгіл қайта қарастыруды жоспарлап отырмыз.

Автозерттеу арқылы үздіксіз жетілдіру: Біз сондай-ақ итеративті автозерттеу циклі арқылы SDK-ның шекті LLM тарапынан тұтынылуын оңтайландырдық. Апта бойы үздіксіз жұмыс істейтін бұл цикл кідіріс, кодты генерациялау сапасы және жалпы тапсырма өнімділігі сияқты көрсеткіштерге қарсы SDK жақсартуларын ұсынады және растайды. Автозерттеу циклі барлық өлшемдер бойынша айтарлықтай жетістіктермен SDK құрылымы мен эстетикасына көптеген өзгерістер енгізіп үлгерді. Жаңа жетілдірілген модельдер мен іздеу компоненттері пайда болған кезде біз автозерттеу арқылы SDK-ны одан әрі жетілдіруді жоспарлаймыз.

Sandbox орталары SaC жұмыс процестерін анықтау және іске қосу үшін қауіпсіз орталарды қамтамасыз етеді. Олар жеке іздеу элементтерімен әрекеттесуді жеңілдету үшін Agentic Search SDK қолжетімділігін қамтамасыз ете отырып, модель жасаған кодты орындайды.

Біз Sandbox орталарын оңтайландыру және қауіпсіздендіру бойынша айтарлықтай инвестициялар жасадық, және олардың жалпы жүйелік дизайны жеке мақалаға лайық. Мұнда біз SaC үшін ең маңызды дизайн ескерімдеріне назар аудардық: аралық күйлерді басқару.

SaC агенттерге бір қорытынды жасау қадамы ішінде күрделі жұмыс процестерін үйлестіруге мүмкіндік береді. Алайда, кейбір аралық күйлер қадамдар арасында берілуі керек. Мысалы, модель 1-қадамда кейбір құжаттарды алғысы келуі мүмкін, келесі әрекетті шешу үшін 2-қадамда сол құжаттардың іріктелген үлгісін тексеріп, содан кейін 3-қадамнан бастап сол құжаттарды қосымша зерттеу үшін төменгі ағындағы іздеу жұмыс процесін әзірлегісі келуі мүмкін. Жоғарыда талқыланғандай, аралық күйлерді токен кеңістігі арқылы беру тиімді стратегия емес.

Біз қадамдар арасындағы аралық күйлерді басқарудың екі тәсілін қарастырдық:

Тұрақты файлдық жүйе + анық serde: Sandbox орталары модельдердің қадамдар арасында пайдалануы үшін тұрақты файлдық жүйелерді ұсына алады. Аралық күйді сақтағысы келетін модельдер келесі қадамда (модельдердің өздерін тексеруі үшін немесе төменгі ағында пайдалану үшін) десериализация қадамымен бірге бір қадам үшін жасалған код ішінде сериализация қадамын қоса алады. Файлдық жүйе тәсілі модельдерге аралық күйдің қадамдар арасында қалай берілетінін тікелей және нақты басқаруға мүмкіндік береді. Сондай-ақ ол модель пайдаланатын ақпаратты нақты сәйкестендіру мен сақтауды мәжбүрлеу арқылы қадағалануын қамтамасыз етеді. Бір кемшілігі – жақсы жойылған утилита функциялары бұл шығынды азайта алса да, serde кодын генерациялаудан туындайтын кідіріс пен мәнмәтін шығыны.

REPL: Немесе, Sandbox ортасы REPL стиліндегі ортада қадамдардың өзінде орындалу ортасын тұрақты ете алады. Бұл модельдерге алдыңғы қадамдарда анықталған немесе өзгертілген айнымалыларды кейінгі қадамдарда тек аты бойынша атап өтуге болатындықтан, оларды мүлдем сериализациялаусыз аралық күйді жадта сақтауға мүмкіндік береді. REPL тәсілі serde кодын генерациялау қажеттілігін болдырмайтындықтан, токен тұрғысынан әлдеқайда тиімді. Алайда, нақты сериализация қадамының болмауы 100 ұяшықты Jupyter ноутбугімен жұмыс істеген кез келген адамға таныс себептер бойынша төменгі ағындағы өнімділікке зиян тигізуі мүмкін: айнымалы аттар кеңістігі ретсіз болған сайын, қадамдар арасында не дәл сақталғанын және не үшін екенін бақылау қиындай түседі.

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

Агент орталарын қуаттандыратын модельдер SaC басқару панелі ретінде қызмет етеді: әр тапсырманың қажеттіліктерін қанағаттандыру үшін Agentic Search SDK құрылыс блоктарынан іздеу жұмыс процестерін динамикалық түрде жинайды, содан кейін бұл жұмыс процестерін Sandbox ортасында орындау үшін код ретінде жібереді.

Perplexity біздің агент орталарымызда түрлі модельдерді пайдаланады, және соңғы жетілдірілген модельдер жалпы мақсаттағы кодты генерациялауда барлық жағынан өте тиімді екенін анықтадық. Негізгі міндет – Agentic Search SDK үшін арнайы тиімді кодты генерациялауды ынталандыру. Яғни, модельдер біздің SDK құрылыс блоктарын тапсырмаға оңтайландырылған жұмыс процестеріне қалай тиімді біріктіре аламыз?

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

Бұл қиындықты шешу үшін біз модельдерге біздің SDK-ны тиімді пайдалануды үйрету үшін жоғары деңгейде бапталған Agent Skills әзірледік. Бастапқы нұсқалары Perplexity компаниясының Skills үшін дизайн қағидаттарына сәйкес әзірленді, содан кейін SDK оңтайландыруында қолданылған сол көрсеткіштерге бағытталған арнайы автозерттеу циклі арқылы оңтайландырылды. Біз сондай-ақ мәнмәтіннің шамадан тыс өсуінен қорғау үшін skill өлшемін шектейміз, және біздің соңғы нұсқаларымыздың түбірлік SKILL.md файлдарында 2000-нан аз токен бар.

Оңтайландырылған Skills SDK-ның қолжетімді құрылыс блоктарын тізімдеуден асып түседі (оны орындалу ортасының көрсетілімі арқылы оңай алуға болады). Токендердің көп бөлігі бұл блоктарды күрделі үлгілерге құрастыру үшін қысқа, жалпыланған нұсқаулар мен few-shot мысалдарын беруге жұмсалады. Осы Skills көмегімен біз модельдердің мыңдаған жеке операцияларға дейін масштабталатын іздеу жұмыс процестерін үйлестіру үшін SDK-ны тиімді пайдаланатынын байқаймыз.

Бұл қабаттарды біріктіру арқылы SaC модельдер мен іздеу стегі арасындағы қатынасты өзгертеді. Бекітілген жұмыс процесі бар іздеу жүйелерінде модель іздеудің үстінде отырады және ол арқылы тар тізбекті шақыру интерфейсі арқылы әрекет етеді. SaC жүйесінде модель іздеу процесінің өзін үйлестіруге белсенді қатысушыға айналады. Іздеу стегінің барлық элементтері модель арқылы тікелей бағдарламаланатын болады, ал Sandbox және Agentic Search SDK сол элементтерге қажетті интерфейстерді қамтамасыз етеді.

Бірақ жергілікті түрде жоқ мүмкіндіктер туралы не айтуға болады? Код – бұл бұрыннан бар мүмкіндіктерді үйлестіру үшін қуатты орта. Алайда кодтың күші тек үйлестірумен шектелмейді. Ол іздеу стегінде немесе SDK-да жоқ мүмкіндіктер үшін олқылықты толтырушы ретінде де қызмет ете алады. Агенттер үнемділіктен пайда көреді, және SDK үшін әрбір ықтимал операцияны арнайы функциямен қамту тиімсіз болар еді. Оның орнына SDK ең іргелі элементтерді ұсынады, ал модель код арқылы кез келген қосымша компоненттерді лезде құра алады.

Мысалы, іздеу жүйесінің өзінің сұрау синтаксисі арқылы тиімді іске асырылмайтын күрделі regex (тұрақты өрнекті) қарастырайық. Кодтау мүмкіндіктерінсіз модель өзінің ең жақсы жақындатуын жасауға, сұрау жіберуге және өте шулы нәтижелер жиынында токен кеңістігін сүзуді орындауға мәжбүр болар еді. SaC көмегімен модель оның орнына қажетті regex нәтижелер жиынының супер жиын жинау үшін параллель SDK шақыруларын жасайтын бағдарламаны жасай алады. SDK арқылы дубликаттарды жойғаннан кейін модель нәтижелерді нақты regex үшін детерминирленген түрде тарылту үшін қосымша код жаза алады. Осылайша, агенттер SDK-ны артық шағын субрутиндермен толтырмай-ақ реттелетін іздеу мүмкіндіктерін жүзеге асыра алады.

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

SaC жауабы дәлдік бойынша 100% жинады, токенді жалпы пайдалану SaC емес базалық көрсеткішке қатысты 85.1%-ға төмендеді (288.7K токеннен 42.9K токенге дейін). 4-бөлімде егжей-тегжейлі талқыланған сынақтан өткен Perplexity емес жүйелердің барлығы 25%-дан төмен балл жинады.

Біз SaC бағдарламаланатындығы модельге тиімді стратегияларды іске асыруға қалай мүмкіндік беретінін көрсету үшін траекториядан үш стилизацияланған код блогын ұсынамыз.

python

# Part 1 of 3: fan out over official advisory formats.
templates = [
    ("Mozilla",
     'site:mozilla.org/en-US/security/advisories/mfsa{year} '
     '"CVE-{year}-" "Fixed in" "Impact high"'),
    ("Jenkins",
     'site:jenkins.io/security/advisory/{year} '
     '"CVE-{year}" "Severity" "High" "Fix"'),
    ("Chrome",
     'site:chromereleases.googleblog.com/{year} '
     '"High CVE-{year}" "Stable channel has been updated"'),
    ("Android",
     'source.android.com/docs/security/bulletin/{year}-{month:02d}-01 '
     '"High" "CVE-{year}"'),
    ...
]

queries = [
    {"vendor": vendor, "query": pattern.format(year=year, month=month)}
    for year in [2023, 2024, 2025]
    for vendor, pattern in templates
    for month in ([1] if "{month" not in pattern else range(1, 13))
]

seed_hits = sdk.search.web_many(queries, limit_per_query=8, concurrency=12)

pages = [
    {"vendor": q["vendor"], "url": h.url, "text": join_result_fields(h)}
    for q, hits in zip(queries, seed_hits)
    for h in hits
    if official_vendor_advisory(h.url, q["vendor"])
]

Бұл бірінші блок – таза үйлестіру. Жасалған бағдарлама көз класының ережесін тікелей сұрау жоспарына кодтаудан басталады: тек жеткізушіге тиесілі кеңес форматтары ғана маңызды. NVD, MITRE, CVE Details, жаңалықтар мақалалары, CERT беттері және үшінші тарап дерекқорларын қоса алғанда, жеткізушіге жатпайтын көздер құрылымдық тұрғыдан ауқымнан тыс. Нақты фраза шектеулері сондай-ақ іздеуді индекстелген мәтінінде төменгі ағында қажет нақты CVE мәліметтері бар беттерге бағыттайды.

python

# Part 2 of 3: synthesize refinements for sparse vendor-years.
coverage = summarize(pages, by=["vendor", "year", "url_kind"])

prompt = """
Goal: 230+ high or critical CVEs from official vendor advisories.
Avoid aggregators, CERTs, news, NVD, MITRE, and CVE databases.
Current coverage:
{coverage}
Suggest more site-scoped exact-phrase queries for sparse vendor-years.
Prefer per-advisory pages over archive or month-index pages.
Return JSON lines with vendor and query.
""".format(coverage=coverage)

raw = query_llm(prompt)

expanded_queries = [
    row for row in parse_jsonl(raw)
    if official_scope(row["query"]) and mentions_cve_year(row["query"])
]

expanded_hits = sdk.search.web_many(
    unique(expanded_queries),
    limit_per_query=8,
    concurrency=12,
)

Екінші блок аралық жоспарлау субрутинасы ретінде LLM пайдаланады. Код қай жеткізуші-жыл жұптары жеткілікті кандидат беттерін шығарып жатқанын қорытындылайды, мақсатты түзетулерді сұрайды және орындау алдында ұсынылған әрбір сұрауды тексереді. Бұл SDK-ға арнайы CVE кеңес беруші 크롤러 (скрейперді) қатты кодтамай-ақ, сайт ауқымындағы нақты фразалық зондтар және бейімделмеген толықтыру сияқты траекториядағы пайдалы үлгілерді сақтайды.

python

# Part 3 of 3: verify CVE-to-version binding.
all_hits = dedupe_by_url(flatten(seed_hits) + flatten(expanded_hits))

items = [
    {"url": h.url, "vendor_hint": infer_vendor(h.url),
     "text": join_result_fields(h)}
    for h in all_hits
    if official_vendor_advisory(h.url, infer_vendor(h.url))
]

verified = sdk.llm.extract_many(
    items,
    instruction=(
        "Keep only vendor advisories where the page ties a high or critical "
        "CVE to a specific fixed version, build, patch, or security level."
    ),
    schema={
        "matches": bool,
        "cve": str,
        "vendor": str,
        "product": str,
        "fix_version": str,
        "severity": str,
        "source_url": str,
        "evidence": str,
        "version_bound_to_cve": bool,
        "confidence": float,
    },
)

records = [
    to_cve_record(x) for x in verified
    if x.matches and x.version_bound_to_cve
    if high_or_critical(x.severity) and x.confidence > 0.75
]
records = dedupe_by(records, key="cve")

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

Біз абсолютті өнімділікке де, шығын-өнімділік шекарасына да назар аудара отырып, жан-жақты тестілеу жиынтығында SaC тиімділігін бағалаймыз.

Біздің тестілеу жиынтығымыз іздеуге тәуелді AI жұмыс процестерін әртүрлі домендер, тапсырма форматтары және күрделілік деңгейлері бойынша кернеулі тестілеу үшін жасалған барлығы бес тестілеу жиынтығын қамтиды. Біз төрт бұрыннан бар тестілеу жиынтығын пайдаланамыз: DeepSearchQA (DSQA), BrowseComp, Humanity's Last Exam (HLE) және WideSearch. Алғашқы үш тестілеу жиынтығы үшін (DSQA, BrowseComp және HLE) біз дәлдікті негізгі көрсеткіш ретінде хабарлаймыз. WideSearch үшін біз жол бойынша F1 ұпайын хабарлаймыз.

Біз сондай-ақ іздеуді, есептеуді және модель пайымын мұқият үйлестіруді талап ететін қиын «кең зерттеу» тапсырмаларына бағытталған жаңадан әзірленген WANDR тестілеу жиынтығын пайдаланамыз. WANDR Perplexity Computer пайдаланушылар үшін өңдейтін білімді қажет ететін кәсіби тапсырмалардан шабыт алған. Ол WideSearch және ұқсас тестілеу жиынтықтарын қайталайды, бірақ күрделірек тапсырмалар мен тапсырма құрылымдарын ерекше атап өтеді. Біз WANDR тестілеу жиынтығын алдағы апталарда жариялаймыз.

Біз бес агентке негізделген жүйені бағалаймыз. Параллелизация артықшылықтарынан гөрі негізгі архитектураның өнімділігін оқшаулау үшін біз «ең жақсы N» ұпайларының орнына жеке жұмыстарды қарастырамыз. Әр жүйенің конфигурациясы төменде сипатталған:

Perplexity (SaC): Біз SaC архитектурасын Perplexity өндірістік Agent API ішінде бағалаймыз. Негізгі модель ретінде GPT 5.5 (жоғары пайымдау) қызмет етеді.

OpenAI: Біз іздеу (web_search) және Python орындалу ортасы (code_interpreter) қосылған OpenAI Responses API интерфейсін бағалаймыз. Негізгі модель ретінде GPT 5.5 (жоғары пайымдау) қызмет етеді.

Anthropic: Біз 20260401 агент құралдар жиынтығы және автоматты түрде рұқсат етілген командалары бар Anthropic Managed Agents жүйесін бағалаймыз. Негізгі модель ретінде Opus 4.7 (жоғары пайымдау) қызмет етеді.

Exa: Біз Exa Agent өндірістік API арқылы, күш салу жоғары етіп орнатылған күйде бағалаймыз.

Parallel: Біз Parallel Tasks өндірістік API арқылы, процессоры ultra4x етіп орнатылған күйде бағалаймыз.

1-кесте әр жүйе үшін тестілеу жиынтығының ұпайларын хабарлайды. SaC бес тестілеу жиынтығының төртеуінде басқа барлық жүйелерден асып түседі. Қалған тестілеу жиынтығында (HLE) SaC OpenAI Responses жүйесімен бірінші орын үшін негізінен тең түсті. Кіріспеден 2-сурет бұл ұпайларды графикалық түрде көрсетеді.

Тестілеу жиынтығы	Perplexity (SaC)	OpenAI	Anthropic	Exa	Parallel
DSQA	0.871	0.733	0.815	0.530	0.810
BrowseComp	0.805	0.720	0.598	0.380	0.560
HLE	0.612	0.614	0.566	0.387	0.515
WideSearch	0.651	0.522	0.590	0.471	0.584
WANDR	0.386	0.130	0.152	0.057	0.126

1-кесте | Бағаланған әр жүйе үшін тестілеу жиынтығының ұпайлары. Әр жол бойынша ең жақсы ұпай қалың қаріппен көрсетілген.

SaC тестілеу жиынтығы бойынша заманауи өнімділікке қол жеткізсе де, оның артықшылығы әсіресе WANDR бойынша ерекше айқын көрінеді. 5-сурет Perplexity компаниясының SaC іске асырылуы келесі ең жақсы жүйеден 2.5× есе асып түсетінін көрсетіп, WANDR ұпайларын бөліп көрсетеді. Бұл үлкен айырмашылыққа қарамастан, WANDR қанықпаған күйінде қалады және тіпті SaC үшін де күрделі екенін дәлелдейді. Біз WANDR тапсырмалары талап ететін күрделі, жоғары көлденең іздеу жұмыс процестері тұрақты түрде жоғары өнімділікке қол жеткізу үшін зерттеу мен іздеу инженерлігінде қосымша жетістіктерді талап етеді деп есептейміз.

Бағаланған жүйелер бойынша WANDR ұпайлары. Perplexity Agent API келесі ең жақсы жүйеден 2.5× есе озып тұр.

Соңында біз SaC және сол Perplexity іздеу инфраструктурасын пайдаланатын дәстүрлі іздеу жұмыс процесінің салыстырмалы өсімін өлшейміз. 6-сурет әр тестілеу жиынтығы бойынша SaC және SaC емес архитектуралар арасындағы ұпай айырмашылығын хабарлайды. Барлық жағынан SaC өнімділіктің айтарлықтай өсуін қамтамасыз етеді, DSQA бойынша ең үлкен абсолютті өсім (+19.77 pp, 29%) және WANDR бойынша ең үлкен салыстырмалы өсім (+12.00 pp, 45%).

Абсолютті және салыстырмалы дельталар көрсетілген әр тестілеу жиынтығындағы Perplexity базалық сызығы мен SaC ұпайы.

Іс жүзінде пайдаланушыларды шығынға қатысты өнімділік қызықтырады. Сондықтан біз DSQA және WideSearch бойынша шығын-өнімділік шекарасын бағалаймыз. Біз басқа жүйелермен қатар төмен, орташа және жоғары модель пайымдау деңгейлері бойынша SaC шығындары мен өнімділігін өлшейміз. 7 және 8-суреттер тестілеу жиынтығының ұпайын бір тапсырманың бағасына қарсы графикке түсіреді, x осі кері бұрылған, сондықтан оңға қарай нүктелер арзан және жоғары нүктелер жақсы өнімділікті білдіреді.

DSQA ұпайы бір тапсырманың бағасына қарсы. Үзілген сызық SaC моделінің пайымдау конфигурацияларын байланыстырады.

DSQA бойынша барлық үш SaC параметрлері жоғарғы оң жақ шекарада орналасқан. Төмен пайымдау параметрі екі жүйеден жақсы жұмыс істей отырып, барлық басқа жүйелерге қарағанда арзанырақ. Орташа пайымдау параметрі бір тапсырма үшін $1-ден аз бағамен SaC емес барлық жүйелерден асып түседі. Жоғары пайымдау параметрі бәсекеге қабілетті құны бар ең жоғары өнімділікке қол жеткізеді.

WideSearch ұпайы бір тапсырманың бағасына қарсы. Үзілген сызық SaC моделінің пайымдау конфигурацияларын байланыстырады.

WideSearch ұқсас пішінді шекараны көрсетеді. DSQA сияқты, төмен пайымдау параметрі барлық SaC емес жүйелерге қарағанда төмен құнымен бәсекеге қабілетті өнімділікке қол жеткізеді, ал орташа және жоғары пайымдаулар да тапсырма өнімділігінде SaC емес жүйелерден асып түседі.

Search as Code бағдарламалық жасақтама дизайнындағы кеңірек өзгерісті көрсетеді. Онжылдықтар бойы бағдарламалық жүйелер процессорлардағы дәстүрлі орындалу орталары арқылы орындалатын детерминирленген нұсқаулар төңірегінде ұйымдастырылды. Жетілдірілген модельдер есептеудің жаңа түрін енгізеді: нұсқауларды орындай да, жасай да алатын токен кеңістігіндегі пайымдау. Ең қуатты есептеу жүйелері олардың арасынан таңдаудың орнына осы екі есептеу түрін біріктіреді.

Іздеу – бұл гибридті архитектура үшін табиғи сынақ алаңы. Модельдер қандай дәлелдер қажет екенін және белсіздіктің қалай шешілуі тиіс екенін шешуге өте қолайлы. Детерминирленген орындалу орталары топтама жасауға, параллелизмге, сүзуге, рейтингке және жинақтауға өте қолайлы. Іздеу инфраструктурасы әмбебап I/O қабаты ретінде қызмет етіп, орындалу ортасына әлемнің ақпаратына минут сайын мыңдаған операцияны қолдай алатын пайдалы тұтқалар береді. Бұл бөліктер біріктірілген кезде нәтижелі жүйе шынайы тапсырмаларды орындауда әлдеқайда қуатты және тиімді болады.

Бұл мүмкіндіктерді ашу үшін осы архитектураның әрбір бөлігі қажет. Зияткерлік модельдерсіз жүйе іздеу стратегиясы бойынша пайымдай алмайды. Sandbox орталарынсыз модельдер тізбекті I/O және тиімсіз токен кеңістігін өңдеуге мәжбүр болады. Ал атомдандырылған іздеу стегінсіз модельдің үйлестіретін ештеңесі жоқ. SaC жұмыс істейді, өйткені пайымдау, детерминирленген есептеу және I/O әр қабаттың күшті жақтарын көрсету үшін бірлесіп жобаланған.

Бұл бірлескен дизайн үздіксіз жетілдіру циклдарын дамыту арқылы тіпті әрі қарай қабылдануы мүмкін. Мысалы, Agentic Search SDK және SaC Agent Skills ортақ автозерттеу циклінде бірлесіп оңтайландырылуы мүмкін. Өршілігірек айтқанда, модельдер SDK ретінде ұсынылған төмен деңгейдегі іздеу элементтерін пайдалану үшін оқытылуы мүмкін. Модельді оқыту процесі кезінде SDK дизайнын бірлесіп дамытуға тырысуға да болады. Біз болашақ жұмыста агрессивті бірлескен дизайн стратегияларын ұстанғымыз келеді.

Біз SaC жүйесін модельдерге нәтижелерін жай ғана тұтынудың орнына іздеу процесін басқаруға мүмкіндік беру үшін құрдық. Біздің нәтижелеріміз бұл басқарудың күшін дәлелдейді: SaC білімді қажет ететін агенттік тестілеу жиынтықтары бойынша абсолютті өнімділікті де, шығын-өнімділік шекарасын да жақсартады. Бүгінгі күннен бастап Perplexity Computer және Agent API көмегімен біз SaC мүмкіндіктерін пайдаланушыларымызға жеткізуге қуаныштымыз. Пайдаланушыларымыздың (және оларға қызмет көрсететін агенттердің) мүмкіндігінше қуатты әрі тиімді іздеу мүмкіндіктеріне ие болуын қамтамасыз ету үшін біз стектің барлық қабаттары бойынша SaC архитектурасын оңтайландыруды жалғастырамыз.

BibTeX

@online{perplexity2026RethinkingSearchAsCodeGeneration,
  author = {{Perplexity} and Denis Bykov and Aleksandr Nikolenko and Artur Zayats and Maksim Gaiduk and Vitalii Polshkov and Akshay Nair and James Liounis and Kirill Priemko and Ryan Buchmayer and Phi Hoang and Jerry Ma},
  title = {{Rethinking search as code generation}},
  date = {2026-06-01},
  url = {https://perplexity.coolkeypoint.com/hub/blog/rethinking-search-as-code-generation}
}

Кіріспе

Дәстүрлі іздеудің қатаңдығы

Қатаңдықтың сәтсіздік режимдері

Бағдарламаланатын іздеу архитектурасын жобалау

Agentic Search SDK

Sandbox орталары

Модельдер

Үйлестіруші және олқылықты толтырушы ретіндегі код

Мысал ретінде зерттеу: CVE жеткізуші кеңестері

Бағалау нәтижелері

Тестілеу жиынтықтары және жүйелер

Салыстырмалы өнімділік

Шығын-өнімділік шекарасы

Есептеудің жаңа архитектурасына қарай

Дәйексөз