Meklēšanas pārdomāšana kā koda ģenerēšana

Meklēšana ir mākslīgā intelekta sistēmu pamatelements. Uzlabotie modeļi kļūst jaudīgāki ar katru mēnesi, taču tiem joprojām ir nepieciešama piekļuve jaunām, precīzām un rūpīgi atlasītām zināšanām no plašākās pasaules. Meklēšana ir galvenais veids, kā mākslīgā intelekta sistēmas iegūst šīs zināšanas, un tāpēc tā ir pamata sastāvdaļa jebkuram produktam, kam nepieciešams izdarīt secinājumus, veikt darbības un paveikt reālus uzdevumus.

Mēs uzskatām, ka tradicionālās meklēšanas darbplūsmas aģentu laikmetā arvien vairāk noveco. Tradicionālā meklēšana sniedz atbildes uz vaicājumiem, taču mūsdienu aģenti izpilda uzdevumus, kas var būt visdažādāko veidu. Šie uzdevumi prasa, lai aģenti tieši savos rīkos definētu uzdevumam specifiskas izgūšanas stratēģijas. Sistēmā Perplexity Computer mēs esam novērojuši, ka viens uzdevums dažu minūšu laikā var izsaukt simtiem vai pat tūkstošiem izgūšanas operāciju — tā ir darbplūsma, kas cilvēkiem nav iespējama, bet aģentiem ir pilnīgi dabiska.

Šādā pasaulē pašai meklēšanai ir jākļūst par aģentu meklēšanu, kuras pamatelementi ir tieši pieejami kā SDK aģenta rīkā. Mēs ieviešam Search as Code (SaC) kā Perplexity jauno atsauces meklēšanas arhitektūru.

Perplexity meklēšanas infrastruktūra apkalpo tūkstošiem vaicājumu sekundē visās mūsu lietojumprogrammās un API Platformā. 2025. gada septembrī mēs publicējām pirmo mūsu meklēšanas sistēmu arhitektūras pārskatu. Pastāvīgas inovācijas šajās sistēmās ir atbalstījušas jaunu piedāvājumu, piemēram, Search API, Agent API un Computer, palaišanu, un pašuzlabošanās cikli optimizē meklēšanas infrastruktūru, lai ar katru dienu labāk apkalpotu lietotājus.

Tradicionāli mākslīgā intelekta sistēmas ir uztvērušas meklēšanu kā monolītu: MI modelis nosūta vaicājumu, meklēšanas dzinējs palaiž savu iepriekš definēto darbplūsmu, un modelis patērē rezultātus kā kontekstu. Lielā mērā tas darbojās labi, lai apmierinātu agrīno MI lietotāju vajadzības. Ņemot vērā viņu pieprasījumu relatīvo vienkāršību, nebija iemesla uztraukties par to, tieši kā ir izstrādāta meklēšanas darbplūsma vai vai šīs darbplūsmas arhitektūra ir optimāla konkrētajam uzdevumam. Tika uzskatīts, ka noklusējuma iestatījumi ir pietiekami labi, tāpat kā noklusējuma saskarnes (funkciju izsaukšana un MCP).

Tradicionālās meklēšanas arhitektūras piedāvā vienu fiksētu sistēmu, kuru modeļi izsauc secīgi, savukārt Search as Code piedāvā atomizētus meklēšanas pamatelementus, kurus aģenti kombinē, izmantojot ģenerētu kodu.

Tomēr šodien šī läeja ar katru mēnesi kļūst arvien novecojušāka. Lietotāji no MI pieprasa daudz ko vairāk nekā tikai vienreizēju analīzi. Viņi sagaida, ka aģenti paveiks uzdevumus no gala līdz galam vairāku stundu vai pat dienu laikā. Šie uzdevumi var būt sarežģīti, atvērti un ļoti mainīgi savās informācijas vajadzībās, un monolītās arhitektūras brūk šo prasību smaguma priekšā.

Galvenais vājais punkts galu galā ir saistīts ar kontroli. Robežmodeļi jau tagad diezgan labi spēj argumentēt ar fiksētu kontekstu. Tomēr visjaudīgākajām MI sistēmām būs nepieciešama spēja vadīt to, kā šis konteksts tiek izgūts, apstrādāts, apkopots un attēlots modelim.

Tradicionālās meklēšanas sistēmas netika izstrādātas, paturot prātā šādu kontrolējamības pakāpi. Galu galā no cilvēkiem lietotājiem nevar sagaidīt smalku kontroli pār meklēšanas darbplūsmas iekšienēm, pat ja tā tiktu piedāvāta. Agrīnie MI modeļi var kontrolēt meklēšanu tikai caur lineāru funkciju izsaukumu un MCP trajektoriju. Bet mūsdienu robežmodeļi, ko darbina kodam piemēroti aģentu rīki, var īstenot smalku kontroli pār jebkuriem iedomājamiem skaitļošanas pamatelementiem, izmantojot dator kodu. Mūsu uzdevums kļūst nodrošināt pareizos pamatelementus.

Lai apmierinātu šo vajadzību, mēs ieviešam jaunu meklēšanas arhitektūru visos mūsu produktos: Search as Code (SaC). Šī jaunā arhitektūra dod iespēju modeļiem ielūkoties pašā meklēšanas infrastruktūrā, nevis tikai patērēt tās galīgos rezultātus. Pamatideja ir vienkāršā: mēs eksponējam meklēšanas infrastruktūras komponentus kā pamatelementus SDK ietvaros. Jebkuram pieprasījumam, kam nepieciešama meklēšana, modelis pēc pieprasījuma savieno šos pamatelementus izgūšanas darbplūsmā, kas pielāgota šim konkrētajam pieprasījumam.

Šīs darbplūsmas montāža tiek veikta, izmantojot koda ģenerēšanu un izpildi drošā smilšu kastē. Atšķirībā no citām uz koda ģenerēšanu balstītām pieejām meklēšanā, mēs vienkārši neievietojam tradicionālu meklēšanas API apvalkā vai valodas izpildlaikā. Tā vietā mēs esam rūpīgi izstrādājuši Agentic Search SDK, kas atklāj atsevišķus meklēšanas pamatelementus iespējami visatomārākajā līmenī.

Search as Code (SaC) uzlabo aģentu meklēšanas veiktspējas robežu dažādu kritēriju kopā.

Bruņojies ar šiem pamatelementiem, SaC sniedz modeļiem tiešu kontroli pār katru atsevišķu meklēšanas soli: izgūšanu, ranžēšanu, filtrēšanu, sadalīšanu, attēlošanu un citiem. Tas arī nodrošina modelim efektivu piekļuvi starpstāvokļiem, piemēram, kandidātu sarakstiem un ranžēšanas signāliem. Šie divi kontroles un lasāmības sviras mehānismi kopā ļauj aģentiem izstrādāt pielāgotas meklēšanas darbplūsmas, kas aptver tūkstošiem izgūšanas operāciju, optimizēt šīs darbplūsmas to izpildes laikā un patērēt tikai visnoderīgāko informāciju kā modeļa kontekstu.

Šajā rakstā ir aprakstīta SaC motivācija, dizains un ieviešana, kā arī empīriskie rezultāti gan esošajiem, gan jaunajiem etaloniem. SaC nosaka jaunu izmaksu un veiktspējas robežu aģentu meklēšanai, un mēs esam priecīgi dalīties tajā ar saviem lietotājiem un plašāku MI kopienu.

Pasaulē pirmie meklēšanas dzinēji tika izveidoti cilvēkiem lietotājiem. Šie lietotāji sāka sagaidīt paredzamu pieredzi, kas parasti sastāv no fiksēta skaita dokumentu, kas sakārtoti pēc atbilstības. Lietotāji nevēlējās mikromenedžēt meklēšanas procesu; viņi vēlējās ievadīt vaicājumu un atrast noderīgu rezultātu.

Tā rezultātā cilvēkiem paredzētie meklēšanas dzinēji nonāca pie kopīgas monolītas arhitektūras, kas orientēta uz cilvēkiem draudzīgu meklēšanas dzinēja rezultātu lapu (SERP) izveidi, kurās ir ievietoti galvenie n rezultāti ievades vaicājumam. Šis modelis ir veicinājis gadu desmitiem ilgu progresu patērētāju meklēšanā. Tas ir ātrs, pazīstams un ļoti efektīvs cilvēku pārlūkošanai.

Tad parādījās LLM, un MI sistēmas kļuva arī par meklēšanas patērētājiem. Perplexity bija pionieris šajā pārejā, 2022. gadā laižot klajā mūsu atbilžu dzinēju. Kopš tā laika mūsu meklēšanas inženierijas centieni ir koncentrēti uz to, kā optimizēt meklēšanas rezultātu vērtību MI modeļiem. Lai izveidotu pasaulē visprecīzāko un uzticamāko MI, mums bija jāizstrādā meklēšanas sistēma, kas vērsta uz to, lai katrs žetons būtu pēc iespējas blīvāks ar informāciju. Tā rezultātā gūtie jauninājumi apakšdokumentu izgūšanā, konteksta efektivitātē, semantiskajā izpratnē un citās galvenajās jomās radīja ievērojamus uzlabojumus MI sistēmu spējā izgūt informāciju un rīkoties ar to.

Tomēr pat MI optimizētās sistēmas lielā mērā ir pārmantojušas to pašu pamatlīgumu, kas tradicionālajiem meklēšanas dzinējiem: pieņemt vaicājumu, palaist iepriekš definētu meklēšanas darbplūsmu, atgriezt pilnībā apstrādātu rezultātu kopu. Vienkāršiem pieprasījumiem šī läeja darbojas labi. Bet sarežģītākiem pieprasījumiem tas kļūst par arvien lielāku ierobežojošu vājo punktu, kas pasliktina veiktspēju, aizkaves laiku un izmaksas.

Tradicionālās meklēšanas sistēmas piespiež aģentu darbplūsmas secīgi kārtot meklēšanu, izmantojot modelim redzamus pagriezienus. Modeļiem ir atkārtoti jāizsauc tās pašas meklēšanas darbplūsmas dažādos vaicājumu parametros un jāievada visi rezultāti modeļa kontekstā.

Tradicionālās meklēšanas darbplūsmas ir veidotas ap vienu kontroles punktu: vaicājuma parametriem. Meklēšanas dzinējam pieder pārējā darbplūsma saskaņā ar tā iepriekš definēto loģiku, un modelim ir jāpielāgojas tam. Modelim viss, kas atrodas aiz vaicājuma parametriem, ir stingrs — faktiskās skaitļošanas forma ir ārpus modeļa kontroles.

Šī ir saprātīga robeža, kad patērētājs ir cilvēks, kas skenē saites. Tā ir slikta robeža, kad patērētājs ir MI modelis, kas mēģina atrisināt zināšanu ietilpīgus uzdevumus slēgtā ciklā. Pēc mūsu pieredzes, šī stingrība rada trīs atkārtotus kļūmes režīmus:

Rupjš konteksts. MI modeļi ir jutīgi pret konteksta kvalitāti un kompaktumu. Gan kvalitāte, gan kompaktums ir ļoti atkarīgi no vaicājuma, un monolītās meklēšanas darbplūsmas nav paredzētas optimālai darbībai visos vaicājumos. Piemēram, ja modelim ir nepieciešama viena, ļoti precīza informācijas daļa, bet tam ir piekļuve tikai pilna cikla meklēšanas galapunktam, kas piešķir prioritāti atsaukšanai, šī galapunkta izmantošana ieviesīs lielu daudzumu neatbilstošas informācijas modeļa kontekstā. No otras puses, ja modelim ir nepieciešami daudzi informācijas gabali, no kuriem katram ir nepieciešamas dažādas meklēšanas stratēģijas, tas var būt spiests secīgi izsaukt to pašu neoptimālo darbplūsmu visiem tiem, kā rezultātā pieaug izmaksas un trokšņains konteksts.

Nespēja izmantot domēna zināšanas. Daudzos gadījumos modelim var būt domēna zināšanas (no tā apmācības, aģenta prasmes (Agent Skill), atmiņas vai agrākiem žetoniem LLM trajektorijā), kurām vajadzētu vadīt meklēšanas stratēģiju. Tomēr stingra meklēšanas saskarne neļauj modelim izmantot šīs zināšanas. Piemēram, modelis konkrētam pieprasījumam var saprast, ka tam vajadzētu apvienot leksiskos un semantiskos signālus noteiktā veidā, piešķirt prioritāti noteiktiem avotiem vai apkopot rezultātus pēc noteiktas atslēgas. Ja vien šīs atziņas netiek ieviestas, izmantojot vaicājuma parametrus, modelis patiesībā nevar rīkoties saskaņā ar tām.

Neefektīva kontroles plūsma un konteksta piesārņojums. Daudzas meklēšanas darbplūsmas nav dabiski secīgas. Tām var būt nepieciešama sadalīšana vaicājumu variantos, paralēla datu iegūšana, dublikātu novēršana un citas operācijas, kas prasa nelineāru un asinhronu kontroles plūsmu. Šo darbību uzspiešana, izmantojot atkārtotus modeļa pagriezienus, palielina aizkaves laiku un apgrūtina darbplūsmas optimizēšanu. Tas arī piesārņo modeļa kontekstu ar trokšņainu starpstāvokli, kas var nebūt noderīgs modeļa spriešanai, kā rezultātā pasliktinās veiktspēja un biežāk notiek saspiešana.

Par šiem izaicinājumiem nevarēja daudz ko darīt funkciju izsaukšanas un MCP ēras laikā. Kad katrai meklēšanas operācijai ir nepieciešams savs apļa brauciens uz LLM secināšanu, izstrādātāji dabiski dod priekšroku tam, lai šajā apļa braucienā paveiktu pēc iespējas vairāk. Tas nozīmē no gala līdz galam meklēšanas darbplūsmas, kas atgriež pilnībā apstrādātas rezultātu kopas tiešai modeļa patēriņam.

Tā rezultātā lielākā daļa mūsdienu MI vērsto meklēšanas sistēmu joprojām darbojas saskaņā ar šo monolīto līgumu. Tomēr, turpinoties modeļa inteliģences un lietotāju prasību izaugsmei, šī līguma trūkumi kļūst izteiktāki. Mūsdienu vismodernākās MI sistēmas, kas būvētas uz koda pirmo rīku bāzes, var sastādīt uzdevumam specifiskas darbplūsmas, kas katru minūti izpilda tūkstošiem darbību. Meklēšanas sistēmas vēl nav pilnībā realizējušas šo potenciālu.

Mēs jau sen esam nojautuši, ka pareizā robeža MI dabiskai meklēšanai atrodas zemāk steku. Modeļiem nevajadzētu tikai izsaukt meklēšanas dzinēju. Tiem vajadzētu spēt orķestrēt meklēšanas steka atsevišķās daļas, kā to prasa konkrētais uzdevums. Tam ir nepieciešama fundamentāli atšķirīga arhitektūra.

Nākamās paaudzes meklēšanas arhitektūras būs atkarīgas no pamatprincipa: meklēšanai jābūt MI aģentu programmatiski programmējamai. Aģents nedrīkst aprobežoties ar iepriekš noteiktu meklēšanas darbplūsmu kopu. Drīzāk aģentam ir jāspēj izveidot darbplūsmu, ko prasa konkrētais uzdevums, izmantojot kombinējamus pamatelementus, kas izstrādāti dažādos abstrakcijas līmeņos.

Mūsu jaunā Search as Code (SaC) arhitektūra iemieso šo principu. SaC netiek nosūtīta neviena izgūšanas operācija, izmantojot funkciju izsaukšanas vai MCP saskarni. Tā vietā visas operācijas tiek orķestrētas, izmantojot modeļa ģenerētu Python kodu. Vienkāršākajām meklēšanas vajadzībām šis kods var sastāvēt no dažiem pieprasījumiem uz augsta līmeņa meklēšanas galapunktu. Bet sarežģītiem uzdevumiem kods var būt tik sarežģīts, cik nepieciešams, ietverot nosacītu izpildi, asinhroniju, paralēlo apstrādi un zvanus uz plašu zema līmeņa pamatelementu klāstu.

Search as Code (SaC) arhitektūra balstās uz steku, kas ietver modeļus, skaitļošanas smilšu kastes un Agentic Search SDK, kas atrodas virs Perplexity meklēšanas infrastruktūras.

SaC ietver trīs cieši savienotus slāņus:

Modeļi kalpo kā vadības plakne. Tie pamato lietotāja (vai vecāka aģenta) norādījumus, sadala norādījumus uzdevumos, izlemj, kuras izgūšanas un apstrādes darbplūsmas ir nepieciešamas katram uzdevumam, un ģenerē kodu šo darbplūsmu ieviešanai.

Skaitļošanas smilšu kastes nodrošina deterministisku skaitļošanu, izmantojot drošu koda izpildes izpildlaiku. Tās nodrošina pamatu modeļiem, lai ieviestu kontroles plūsmu, pakešu apstrādi, atkārtotus mēģinājumus, filtrēšanu, apvienošanu, agregāciju un citas deterministiskas operācijas.

Mūsu Agentic Search SDK eksponē Perplexity meklēšanas steku kā kombinējamus pamatelementus. Tas nodrošina pamatelementus no zema līmeņa izgūšanas operācijām līdz augsta līmeņa semantiskajai parsēšanai. SDK ir iegulto smilšu kastu izpildlaikos, ļaujot modeļiem orķestrēt līdz pat tūkstošiem operāciju vienā secināšanas pagriezienā. Zemāk mēs apspriežam mūsu dizaina lēmumus katram slānim.

Agentic Search SDK definē pamatelementus programmējamai meklēšanai. Svarīgi ir tas, ka mūsu SDK nav iepriekš pastāvoša meklēšanas API, kas iepakota kā bibliotēka. Pēdējo mēnešu laikā mūsu inženieru komanda ir pārstrukturējusi mūsu meklēšanas steku modulāros, kombinējamos pamatelementos. Mēs esam izveidojuši Agentic Search SDK, lai nodrošinātu tiešu piekļuvi šiem pamatelementiem, izveidojot daudz jaudīgāku audeklu, uz kura modelis var orķestrēt uzdevumam specifiskas izgūšanas darbplūsmas.

Augsta līmeņa pilna cikla meklēšanas darbplūsmas joprojām ir pieejamas SDK, taču tās vairs nav vienīgā iespēja. Drīzāk tās kalpo kā saīsinājuma veids parastiem meklēšanas modeļiem. Modelis var brīvi tos izmantot vai apiet, kā to prasa uzdevums.

Izpildlaika izvēle: Mēs apsvērām Python, Rust, TypeScript un Bash kā SDK izpildlaiku. Mēs nojautām, ka Python būs visdabiskākais risinājums, ņemot vērā tā visuresamību un datu apstrādes bibliotēku ekosistēmu. Iekšējā testēšana to apstiprināja, un šodien klajā laidamā SDK versija ir balstīta uz Python. Mēs ceram periodiski pārvērtēt izpildlaika izvēli, lai nodrošinātu, ka tā turpina nodrošināt labāko aģenta pieredzi.

Pastāvīgi uzlabojumi, izmantojot auto-izpēti (autoresearch): Mēs esam arī optimizējuši SDK patērējamību robežu LLM, izmantojot iteratīvu auto-izpētes ciklu. Šis cikls, kas nepārtraukti darbojas nedēļām ilgi, ierosina un apstiprina SDK uzlabojumus, pamatojoties uz tādiem rādītājiem kā aizkaves laiks, koda ģenerēšanas kvalitāte un kopējā uzdevuma veiktspēja. Auto-izpētes cikls jau ir veicis daudzas izmaiņas gan SDK struktūrā, gan estētikā, nodrošinot ievērojamus ieguvumus visās dimensijās. Mēs plānojam turpināt pilnveidot SDK, izmantojot auto-izpēti, parādoties jauniem robežmodeļiem un meklēšanas komponentiem.

Smilšu kastes nodrošina drošas vides SaC darbplūsmu definēšanai un palaišanai. Tās izpilda modeļa ģenerētu kodu, nodrošinot piekļuvi Agentic Search SDK, lai atvieglotu mijiedarbību ar atsevišķiem meklēšanas pamatelementiem.

Mēs esam ieguldījuši ievērojamus līdzekļus mūsu smilšu kastu optimizēšanā un nostiprināšanā, un to vispārējā sistēmas arhitektūra ir atsevišķa raksta vērta. Šeit mēs koncentrējamies uz SaC visatbilstošāko dizaina apsvērumu: starpstāvokļu pārvaldību.

SaC dod iespēju aģentiem orķestrēt sarežģītas darbplūsmas viena secināšanas pagrieziena laikā. Tomēr noteikti starpstāvokļi ir jāpārraida starp pagriezieniem. Piemēram, modelis var vēlēties iegūt dažus dokumentus 1. pagriezienā, pārbaudīt šo dokumentu apakšizlasi 2. pagriezienā, lai izlemtu, ko darīt tālāk, un pēc tam izstrādāt lejupstraumes meklēšanas darbplūsmu, lai turpinātu izpētīt šos dokumentus no 3. pagrieziena un tālāk. Kā apspriests iepriekš, starpstāvokļu nodošana caur žetonu telpu nav efektīva stratēģija.

Mēs apsvērām divas pieejas starpstāvokļu pārvaldīšanai starp pagriezieniem:

Pastāvīgā failu sistēma + eksplicīta serde (ser-de): Smilšu kastes var eksponēt pastāvīgās failu sistēmas, ko modeļi var izmantot starp pagriezieniem. Modeļi, kas vēlas saglabāt starpstāvokli, var iekļaut serializācijas soli ģenerētajā kodā vienam pagriezienam, kopā ar deserializācijas soli nākamajā pagriezienā (vai nu pašu modeļu pārbaudei, vai lejupstraumes izmantošanai). Failu sistēmas läeja ļauj modeļiem tieši un eksplicīti kontrolēt, kā starpstāvoklis tiek pārvadīts starp pagriezieniem. Tā arī nodrošina izsekojamību, uzspiežot modeļa izmantotās informācijas eksplicītu identifikāciju un saglabāšanu. Viens trūkums ir aizkaves laiks un konteksta pieskaitāmās izmaksas, kas rodas, ģenerējot serde kodu, lai gan labi izstrādātas utilītas funkcijas var mazināt šīs pieskaitāmās izmaksas.

REPL: Alternatīvi, smilšu kaste var saglabāt pašu izpildlaiku starp pagriezieniem REPL stila vidē. Tas ļauj modeļiem uzturēt starpstāvokli atmiņā, vispār neveicot tā serializāciju, jo mainīgos, kas definēti vai modificēti iepriekšējos pagriezienos, var vienkārši atsaukties pēc nosaukuma nākamajos pagriezienos. REPL läeja ir vairāk žetonu efektīva, jo tā novērš nepieciešamību ģenerēt serde kodu. Tomēr eksplicītas serializācijas soļa trūkums var kaitēt lejupstraumes veiktspējai tādu iemeslu dēļ, kas pazīstami ikvienam, kurš ir strādājis ar 100 šūnu Jupyter piezīmju grāmatiņu: mainīgo nosaukumvietai kļūstot pārpildītai, kļūst grūtāk izsekot tam, kas precīzi tiek saglabāts starp pagriezieniem un kāpēc.

Mēs testējām abas pieejas un konstatējām, ka, lai gan tās darbojas līdzīgi parastā lietošanā, uz failu sistēmu balstīta serde nodrošina labāku uzticamību īpaši garās trajektorijās. Tāpēc mēs pieņemam uz failu sistēmu balstītu serde kā savu risinājumu. Mēs pieņemam, ka prasība modeļiem pārraidīt stāvokli deklaratīvi, nevis implikīti palīdz tiem efektīvāk pārvaldīt šo stāvokli. Šis ir pagaidu secinājums, un mēs turpināsim iterēt abas pieejas.

Modeļi, kas darbina aģentu rīkus, kalpo kā SaC vadības plakne: dinamiski montējot meklēšanas darbplūsmas no Agentic Search SDK pamatelementiem, lai apmierinātu katra uzdevuma vajadzības, pēc tam nosūtot šīs darbplūsmas kā kodu smilšu kastes izpildei.

Perplexity izmanto dažādus modeļus mūsu aģentu rīkos, un mēs esam konstatējuši, ka jaunākie robežmodeļi ir diezgan efektīvi visā programmā vispārējas nozīmes koda ģenerēšanā. Galvenais izaicinājums ir panākt efektīvu koda ģenerēšanu tieši Agentic Search SDK. Tas ir, kā mēs varam panākt, ka modeļi efektīvi savij kopā mūsu SDK pamatelementus uzdevumam optimizētās darbplūsmatās?

Atšķirībā no valodas standarta bibliotēkas, pielāgots SDK diez vai būs pārstāvēts iepriekšējas apmācības datos. Pat ar SDK patērējamības uzlabojumiem no auto-izpētes, daudzi modeļi joprojām ir apmācīti mijiedarboties ar meklēšanas sistēmām, izmantojot funkciju izsaukumus un tiešu MCP izsaukumu. Šie modeļi maz ticams, ka prasmīgi pārvaldīs SDK tikai ar pirmkodu un autoģenerētu dokumentāciju.

Lai atrisinātu šo izaicinājumu, esam izstrādājuši augsti pielāgotas aģentu prasmes (Agent Skills), lai mācītu modeļiem efektīvi izmantot mūsu SDK. Sākotnējās versijas tika izstrādātas saskaņā ar Perplexity dizaina principiem attiecībā uz prasmēm, un pēc tam optimizētas, izmantojot īpašu auto-izpētes ciklu, kas vērsts uz tiem pašiem rādītājiem, ko izmanto SDK optimizācijā. Mēs arī ierobežojam prasmes lielumu, lai pasargātu no konteksta uzpūšanās, un mūsu galīgajās versijās ir mazāk nekā 2000 žetonu to saknes SKILL.md failos.

Optimizētās prasmes sniedzas tālāk par SDK pieejamo pamatelementu uzskaitījumu (ko tikpat viegli var iegūt, izmantojot izpildlaika refleksiju). Lielākā daļa žetonu tiek tērēta, nodrošinot kodolīgu, vispārinātu norādījumu un dažu šāvienu (few-shot) piemērus šo bloku sastādīšanai sarežģītos modeļos. Bruņojušies ar šīm prasmēm, mēs novērojam, ka modeļi efektīvi izmanto SDK, lai orķestrētu meklēšanas darbplūsmas, kas mērogojas līdz tūkstošiem atsevišķu operāciju.

Apvienojot šos slāņus, SaC maina attiecības starp modeļiem un meklēšanas steku. Fiksētas darbplūsmas meklēšanas sistēmās modelis atrodas virs meklēšanas un mijiedarbojas ar to caur šauru secīgu izsaucēja saskarni. SaC modelis kļūst par aktīvu dalībnieku paša meklēšanas procesa orķestrēšanā. Visi meklēšanas steka elementi kļūst tieši programmējami ar modeli, un smilšu kaste un Agentic Search SDK nodrošina nepieciešamās saskarnes šiem elementiem.

Bet kā ar spējām, kas dabiski nepastāv? Kods ir spēcīgs līdzeklis iepriekš pastāvošu spēju orķestrēšanai. Tomēr koda spēks sniedzas tālāk par orķestrēšanu. Tas var kalpot arī kā trūkumu aizpildītājs spējām, kas nav klāt meklēšanas stekā vai SDK. Aģentiem ir labums no taupības, un SDK būtu neefektīvi aptvert katru potenciālo operāciju ar īpašu funkciju. Tā vietā SDK nodrošina pamata pamatelementus, un modelis var izveidot jebkurus papildu komponentus lidojumā ar kodu.

Apsveriet, piemēram, sarežģītu regulāro izteiksmi (regex), ko nevar efektīvi ieviest, izmantojot pašas meklēšanas sistēmas vaicājuma sintaksi. Bez kodēšanas spējām modelis būtu spiests ģenerēt savu labāko tuvinājumu, izveidot vaicājumu un veikt žetonu telpas filtrēšanu uz ļoti trokšņainas rezultātu kopas. Ar SaC modelis tā vietā var ģenerēt programmu, kas veic paralēlus SDK izsaukumus, lai savāktu vēlamās regulārās izteiksmes rezultātu kopas virskopu. Pēc dublikātu novēršanas, izmantojot SDK, modelis pēc tam var uzrakstīt papildu kodu, lai deterministiski sašaurinātu rezultātus līdz precīzai regulārajai izteiksmei. Tādā veidā aģenti var ieviest pielāgotas meklēšanas spējas, nepiepildot SDK ar pārlieku šaurām apakšrutīnām.

Mēs piedāvājam gadījuma izpēti, kas balstīta uz reālu uzdevumu mūsu testēšanas komplektā. Šis uzdevums prasa aģentam identificēt un raksturot vairāk nekā 200 augstas smaguma pakāpes CVE no 2023.–2025. gada. Katrā ierakstā ir jānorāda skartā ražotāja paša ieteikums, jānosauc produkts un labojuma versija, kā arī jāparāda, ka labojuma versija ir saistīta ar konkrēto CVE.

SaC atbilde ieguva 100% precizitāti, un kopējais žetonu patēriņš samazinājās par 85,1% salīdzinājumā ar ne-SaC bāzes līniju (no 288,7K žetoniem līdz 42,9K žetoniem). Testētās ne-Perplexity sistēmas, kas sīkāk apskatītas 4. sadaļā, visas ieguva mazāk nekā 25%.

Mēs piedāvājam trīs stilizētus koda blokus no trajektorijas, lai parādītu, kā SaC programmējamība ļauj modelim ieviest efektīvas stratēģijas.

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"])
]

Šis pirmais bloks ir tīra orķestratūra. Ģenerētā programma sākas, kodējot avota klases kārtulu tieši vaicājuma plānā: attiecas tikai uz ražotājam piederošiem ieteikumu formātiem. Ne-ražotāju avoti, tostarp NVD, MITRE, CVE Details, ziņu stāsti, CERT lapas un trešo pušu datubāzes, strukturāli ir ārpus darbības jomas. Precīzas frāzes ierobežojumi arī virza meklēšanu uz lapām, kuru indeksētais teksts jau satur precīzu CVE informāciju, kas nepieciešama lejupstraumē.

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,
)

Otrais bloks izmanto LLM kā starpposma plānošanas apakšrutīnu. Kods apkopo, kuri ražotāja-gada pāri ražo pietiekami daudz kandidātu lapu, prasa mērķtiecīgus uzlabojumus un apstiprina katru ierosināto vaicājumu pirms izpildes. Tas saglabā noderīgus modeļus no trajektorijas, piemēram, vietnei piesaistītas precīzas frāzes zondes un adaptīvu aizpildīšanu atpakaļ, bez pielāgotas CVE ieteikumu pārlūka kodēšanas SDK.

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")

Galīgais bloks ir rezultātu pārbaudītājs, kura loģiku pilnībā definē aģents, izmantojot koda ģenerēšanu. Lai gan meklēšanas apakšrutīnas var atrast ticamas ieteikumu lapas, uzdevums prasa stingrāku attiecību: ieteikumam ir jāsaista viena CVE ar vienu skarto produktu un vienu labojuma versiju ražotāja sarakstītajā tekstā. Shēma padara šo attiecību eksplicītu, tāpēc lejupstraumes kods var veikt dublikātu novēršanu pēc CVE, noraidīt agregatora vietrāžus URL, atmest vājus versijas pierādījumus un turpināt aizpildīšanu atpakaļ, līdz ir sasniegts ierakstu skaita minimums.

Mēs novērtējam SaC efektivitāti visaptverošā etalonu komplektā, koncentrējoties gan uz absolūto veiktspēju, gan izmaksu un veiktspējas robežu.

Mūsu etalonu komplektā kopumā ietilpst pieci etaloni, kas paredzēti, lai stresa testētu no meklēšanas atkarīgas MI darbplūsmas dažādās jomās, uzdevumu formātos un sarežģītības līmeņos. Mēs izmantojam četrus iepriekš pastāvošos etalonus: DeepSearchQA (DSQA), BrowseComp, Humanity's Last Exam (HLE) un WideSearch. Pirmajiem trim etaloniem (DSQA, BrowseComp un HLE) mēs ziņojam par precizitāti kā galveno rādītāju. WideSearch mēs ziņojam par F1 rādītāju pa rindām.

Mēs izmantojam arī nesen izstrādāto WANDR etalonu, kas koncentrējas uz sarežģītiem “plašas pētniecības” uzdevumiem, kuri prasa rūpīgu meklēšanas, skaitļošanas un modeļa spriešanas orķestrēšanu. WANDR ir iedvesmots no zināšanu ietilpīgajiem profesionālajiem uzdevumiem, kurus Perplexity Computer apstrādā lietotājiem. Tas atkārto WideSearch un līdzīgus etalonus, bet uzsver sarežģītākus uzdevumus un uzdevumu struktūras. Mēs publicēsim WANDR etalonu tuvāko nedēļu laikā.

Mēs novērtējam piecas uz aģentiem balstītas sistēmas. Mēs apskatām individuālos braucienus, nevis “labāko no N” rādītājus, lai izolētu pamatā esošās arhitektūras veiktspēju, nevis paralelizācijas ieguvumus. Katras sistēmas konfigurācija ir aprakstīta zemāk:

Perplexity (SaC): Mēs novērtējam SaC arhitektūru Perplexity ražošanas Agent API. GPT 5.5 (augsta spriešana) kalpo kā pamata modelis.

OpenAI: Mēs novērtējam OpenAI Responses API ar iespējotu gan meklēšanu (web_search), gan Python izpildlaiku (code_interpreter). GPT 5.5 (augsta spriešana) kalpo kā pamata modelis.

Anthropic: Mēs novērtējam Anthropic Managed Agents ar 20260401 aģenta rīku kopu un automātiski atļautajām komandām. Opus 4.7 (augsta spriešana) kalpo kā pamata modelis.

Exa: Mēs novērtējam Exa Agent, izmantojot ražošanas API, ar piepūli, kas iestatīta uz augstu.

Parallel: Mēs novērtējam Parallel Tasks, izmantojot ražošanas API, ar procesoru, kas iestatīts uz ultra4x.

1. tabula sniedz etalonu rādītājus katrai sistēmai. SaC pārspēj visas pārējās sistēmas četros no pieciem etaloniem. Atlikušajā etalonā (HLE) SaC būtībā dala pirmo vietu ar OpenAI Responses. 2. attēls no Ievada vizualizē šos rādītājus grafiskā formā.

Etalons	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. tabula | Etalonu rādītāji katrai novērtētajai sistēmai. Labākais rādītājs katrā rindā treknrakstā.

Lai gan SaC sasniedz mūsdienīgāko veiktspēju visā etalonu komplektā, tās priekšrocība ir īpaši izteikta WANDR. 5. attēls sadala WANDR rādītājus, parādot, ka Perplexity SaC ieviešana pārspēj nākamo labāko sistēmu par 2,5× reizi. Neskatoties uz šo lielo pārsvaru, WANDR joprojām ir nepiesātināts un izrādās izaicinošs pat SaC. Mēs uzskatām, ka sarežģītās, ļoti horizontālās meklēšanas darbplūsmas, ko pieprasa WANDR uzdevumi, prasīs papildu sasniegumus pētniecībā un meklēšanas inženierijā, lai sasniegtu konsekventi augstu veiktspēju.

WANDR rādītāji visās novērtētajās sistēmās. Perplexity Agent API apsteidz nākamo labāko sistēmu par 2,5× reizi.

Visbeidzot, mēs mērām SaC relatīvos ieguvumus salīdzinājumā ar tradīciju bagātāku meklēšanas darbplūsmu, kas izmanto to pašu Perplexity meklēšanas infrastruktūru. 6. attēls ziņo par rādītāju atšķirību starp SaC un ne-SaC arhitektūrām katrā etalonā. Visā programmā SaC nodrošina ievērojamu veiktspējas pieaugumu, ar lielāko absolūto ieguvumu DSQA (+19,77 pp, 29%) un lielāko relatīvo ieguvumu WANDR (+12,00 pp, 45%).

Perplexity bāzes līnija pret SaC rādītāju katrā etalonā, ar anotētiem absolūtajiem un relatīvajiem deltam.

Praksē lietotāji rūpējas par veiktspēju attiecībā pret izmaksām. Tāpēc mēs novērtējam izmaksu un veiktspējas robežu DSQA un WideSearch. Mēs mērām SaC izmaksas un veiktspēju zemos, vidējos un augstos modeļa spriešanas līmeņos, blakus citām sistēmām. 7. un 8. attēls attēlo etalona rādītāju pret cenu par vienu uzdevumu, ar apgrieztu x asi, lai punkti tālāk pa labi būtu lētāki un punkti augstāk attēlotu labāku veiktspēju.

DSQA rādītājs pret cenu par vienu uzdevumu. Pārtrauktā līnija savieno SaC modeļa spriešanas konfigurācijas.

DSQA visi trīs SaC iestatījumi atrodas uz augšējās labās robežas. Zemas spriešanas iestatījums ir lētāks nekā visas pārējās sistēmas, vienlaikus darbojoties labāk nekā divas no tām. Vidējas spriešanas iestatījums pārspēj visas ne-SaC sistēmas par mazāk nekā $1 par uzdevumu. Augstas spriešanas iestatījums sasniedz augstāko veiktspēju ar konkurētspējīgām izmaksām.

WideSearch rādītājs pret cenu par vienu uzdevumu. Pārtrauktā līnija savieno SaC modeļa spriešanas konfigurācijas.

WideSearch parāda līdzīgi veidotu robežu. Tāpat kā DSQA, zemas spriešanas iestatījums sasniedz konkurētspējīgu veiktspēju par zemākām izmaksām nekā visas ne-SaC sistēmas, savukārt gan vidējas, gan augstas spriešanas iestatījumi pārspēj ne-SaC sistēmas uzdevuma veiktspējā.

Search as Code atspoguļo plašākas izmaiņas programmatūras dizainā. Jau gadu desmitiem programmatūras sistēmas tika organizētas ap deterministiskām instrukcijām, ko izpildīja tradicionālie izpildlaiki uz CPU. Robežmodeļi ievieš jaunu skaitļošanas formu: žetonu telpas spriešanu, kas var gan sekot instrukcijām, gan tās ģenerēt. Visspējīgākās skaitļošanas sistēmas apvienos šīs divas skaitļošanas formas, nevis izvēlēsies starp tām.

Meklēšana ir dabisks poligons šai hibrīda arhitektūrai. Modeļi ir labi piemēroti, lai izlemtu, kādi pierādījumi ir nepieciešami un kā būtu jāatrisina nenoteiktība. Deterministiskie izpildlaiki ir labi piemēroti pakešu apstrādei, paralēlismam, filtrēšanai, ranžēšanai un agregācijai. Meklēšanas infrastruktūra kalpo kā universāls I/O slānis, nodrošinot izpildlaiku ar noderīgiem rokturiem pasaules informācijā, kas var uzturēt tūkstošiem operāciju minūtē. Kad šie gabali ir integrēti, iegūtā sistēma ir daudz jaudīgāka un efektīvāka reālo uzdevumu izpildē.

Katra šīs arhitektūras daļa ir nepieciešama, lai atbloķētu šīs spējas. Bez inteliģentiem modeļiem sistēma nevar spriest par meklēšanas stratēģiju. Bez smilšu kastēm modeļi ir spiesti darboties secīgā I/O un neefektīvā žetonu telpas apstrādē. Un bez atomizēta meklēšanas steka modelim nav ko orķestrēt. SaC darbojas, jo spriešana, deterministiskā skaitļošana un I/O ir kopīgi izstrādāti, lai izceltu katra slāņa stiprās puses.

Šo kopīgo dizainu var vēl vairāk attīstīt, attīstot pastāvīgu uzlabojumu ciklus. Piemēram, Agentic Search SDK un SaC aģenta prasmes varētu tikt kopīgi optimizētas kopīgā auto-izpētes ciklā. Vēl ambiciozāk, modeļus var apmācīt izmantot zema līmeņa meklēšanas pamatelementus, kas eksponēti kā SDK. Varētu pat mēģināt kopīgi attīstīt SDK dizainu pašā modelis apmācības procesā. Mēs ceram turpināt agresīvākas kopīgā dizaina stratēģijas turpmākajā darbā.

Mēs izveidojām SaC, lai ļautu modeļiem kontrolēt meklēšanas procesu, nevis tikai patērēt tā rezultātus. Mūsu rezultāti pierāda šīs kontroles spēku: SaC veicina gan absolūto veiktspēju, gan izmaksu un veiktspējas robežu uz zināšanu ietilpīgiem aģentu etaloniem. Mēs esam priecīgi nodrošināt SaC spējas saviem lietotājiem, sākot šodien ar Perplexity Computer un Agent API. Mēs turpināsim optimizēt SaC arhitektūru visos steka slāņos, lai nodrošinātu, ka mūsu lietotājiem (un aģentiem, kas viņus apkalpo) ir visspēcīgākās un efektīvākās iespējamās meklēšanas spējas.

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

Ievads

Tradicionālās meklēšanas stingrība

Stingrības radītie kļūmes režīmi

Programmējamas meklēšanas arhitektūras izstrāde

Agentic Search SDK

Smilšu kastes

Modeļi

Kods kā orķestrators un trūkumu aizpildītājs

Gadījuma izpēte: CVE ražotāju ieteikumi

Novērtēšanas rezultāti

Etaloni un sistēmas

Salīdzinošā veiktspēja

Izmaksu un veiktspējas robeža

Pret jaunu skaitļošanas arhitektūru

Citāts