Otsingu ümbermõtestamine koodigeneratsioonina

Otsing on tehisintellektisüsteemide jaoks keskne algeline komponent. Tipptasemel mudelid muutuvad iga kuuga võimekamaks, kuid nad vajavad endiselt juurdepääsu värsketele, täpsetele ja hästi kureeritud teadmistele laiemast maailmast. Otsing on peamine viis, kuidas tehisintellektisüsteemid nende teadmisteni jõuavad, ning seetõttu on see aluskomponent igale tootele, mis peab tegema järeldusi, samme ja reaalseid toiminguid.

Usume, et traditsioonilised otsingutöövoog on agentide ajastul üha enam iganemas. Traditsiooniline otsing vastab päringutele, kuid tänapäevased agendid täidavad ülesandeid, mis võivad võtta lugematul hulgal kujusid. Need ülesanded nõuavad agentidelt ülesandepõhiste hankimisstrateegiate määratlemist otse nende rakendustes. Perplexity Computeris oleme näinud, kuidas üksikud ülesanded käivitavad mõne minuti jooksul sadu või isegi tuhandeid hankimistoiminguid: töövoog, mis on inimeste jaoks võimatu, kuid agentide jaoks täiesti loomulik.

Selles maailmas peab otsing ise muutuma agentpõhiseks, kusjuures selle ehitusplokid on otseselt juurdepääsetavad SDK-dena agendirakenduses. Toome turule otsingu koodina (Search as Code – SaC) kui Perplexity uue võrdlusotsingu arhitektuuri.

Perplexity otsingupinu teenindab meie rakendustes ja API-platvormil igas sekundis tuhandeid päringuid. 2025. aasta septembris avaldasime oma otsingusüsteemide esimese arhitektuurse ülevaate . Pidev innovatsioon nendes süsteemides on toetanud uute pakkumiste, näiteks Search API, Agent API ja Computer, turuletoomist ning isetäiustuvad tsüklid optimeerivad otsingupinu, et teenindada kasutajaid iga mööduva päevaga paremini.

Traditsiooniliselt on tehisintellektisüsteemid käsitlenud otsingut monoliidina: tehisintellekti mudel esitab päringu, otsingumootor käivitab oma eelnevalt määratletud töövoog ning mudel tarbib tulemusi kontekstina. Suuremalt jaolt toimis see varajaste tehisintellekti kasutajate vajaduste rahuldamiseks hästi. Arvestades nende päringute suhtelist lihtsust, polnud põhjust muretseda selle pärast, kuidas täpselt otsingutöövoog oli kavandatud või kas torujuhtme arhitektuur oli käesoleva ülesande jaoks optimaalne. Vaikimisi määranguid peeti piisavalt headeks, nagu ka vaikimisi liideseid (funktsioonide kutsumine ja MCP-d).

Traditsioonilised otsingurahitektuurid paljastavad üheainsa fikseeritud süsteemi, mida mudelid kutsuvad jadana, samas kui otsing koodina toob esile atomiseeritud otsinguprimitiivid, mida agendid genereeritud koodi kaudu kombineerivad.

Tänapäeval muutub see lähenemine siiski iga mööduva kuuga iganenuks. Kasutajad nõuavad tehisintellektilt enamat kui lihtsalt ühekordset analüüsi. Nad eeldavad, et agendid täidavad ülesandeid algusest lõpuni tundide või isegi päevade jooksul. Need ülesanded võivad olla keerulised, lahtise lõpuga ja oma teabevajadustes väga muutlikud ning monoliitsed arhitektuurid annavad nende nõudmiste raskuse all järele.

Peamine kitsaskoht on lõppkokkuvõttes kontroll. Tipptasemel mudelid on fikseeritud konteksti üle arutlemisel juba üsna head. Kõige võimsamad tehisintellektisüsteemid nõuavad aga võimalust suunata , kuidas seda konteksti hangitakse, töödeldakse, koondatakse ja mudelile kuvatakse.

Traditsioonilisi otsingusüsteeme ei kujundatud sellist kontrollitavuse taset silmas pidades. Lõppude lõpuks ei saa eeldada, et inmkasutajad teostaksid otsingutöövoo sisemuse üle peeneteralist kontrolli, isegi kui seda pakutaks. Varajased tehisintellekti mudelid saavad otsingut kontrollida ainult funktsioonikutsete ja MCP-de lineaarse trajektoori kaudu. Kuid tänapäevased tipptasemel mudelid, mida juhivad koodivõimelised agendirakendused, suudavad arvutikoodi abil teostada peeneteralist kontrolli kõigi kujuteldavate arvutusprimitiivide üle. Meie ülesandeks on pakkuda õigeid primitiive.

Selle vajaduse rahuldamiseks toome oma toodetes turule uue otsinguarhitektuuri: otsing koodina (Search as Code – SaC). See uus arhitektuur annab mudelitele võimaluse ulatuda otse otsingupinu sisse, selle ainsa lõpptulemuse tarbimise asemel. Põhiidee on lihtne: teeme otsingupinu komponendid SDK-s primitiividena kättesaadavaks. Iga otsingut vajava päringu jaoks paneb mudel need primitiivid nõudmisel kokku konkreetsele päringule kohandatud hankimistöövoog.

Selle torujuhtme kokkupanemine toimub koodi genereerimise ja täitmise kaudu turvalises liivakastis. Erinevalt teistest otsingule suunatud koodigeneratsiooni lähenemisviisidest ei paiguta me traditsioonilist otsingu API-d lihtsalt kesta või keelekäitusaega. Selle the oleme hoolikalt välja töötanud agentpõhise otsingu SDK, mis toob otsingu üksikud ehitusplokid esile võimalikult madalal tasemel.

Otsing koodina (SaC) viib agentpõhise otsingu jõudluse piire edasi erinevates võrdlusalustes.

Nende ehitusplokkidega relvastatud SaC annab mudelitele otsese kontrolli iga üksiku otsinguetapi üle: hankimine, järjestamine, filtreerimine, hargnemised, renderdamine ja palju muud. Samuti annab see mudelile tõhusa juurdepääsu vaheolekutele, nagu kandidaatide loendid ja järjestussignaalid. Need kaks kontrolli ja loetavuse hooba võimaldavad agentidel kavandada eritellimusel põhinevaid otsingutöövooge, mis hõlmavad tuhandeid hankimistoiminguid, optimeerida neid töövooge lennult ja tarbida mudeli kontekstina ainult kõige kasulikumat teavet.

See artikkel kirjeldab SaC motivatsiooni, disaini ja juurutamist koos empiiriliste tulemustega nii olemasolevatel kui ka uutel võrdlusalustel. SaC loob agentpõhise otsingu jaoks uue kulude ja jõudluse piiri ning meil on hea meel seda oma kasutajate ja laiema tehisintellekti kogukonnaga jagada.

Maailma esimesed otsingumootorid ehitati inmkasutajatele. Need kasutajad hakkasid ootama etteaimatavat kogemust, mis tavaliselt koosneb fikseeritud arvust asjakohasuse alusel järjestatud dokumentidest. Kasutajad ei soovinud otsinguprotsessi mikromajandada; nad soovisid sisestada päringu ja leida kasuliku tulemuse.

Selle tulemusena koondusid inmkasutajatele suunatud otsingumootorid ühisele monoliitsele arhitektuurile, mis on suunatud inmsõbralike otsingumootori tulemuste lehtede (SERP-ide) tootmisele, mis sisaldavad sisendpäringu jaoks n parimat tabamust. See muster on toitnud aastakümnete pikkust edusammu tarbijaotsingus. See on kiire, tuttav ja inmsirvimiseks väga tõhus.

Seejärel tulid LLM-id ja tehisintellektisüsteemidest said samuti otsingu tarbijad. Perplexity oli selle nihke teerajaja oma vastusemootori turuletoomisega 2022. aastal. Alates sellest ajast on meie otsinguin-g-tehnilised pingutused keskendunud sellele, kuidas optimeerida otsingutulemuste väärtust tehisintellekti mudelite jaoks. Maailma kõige täpsema ja usaldusväärsema tehisintellekti ehitamiseks pidime konstrueerima otsingusüsteemi, mis keskendub iga märgi võimalikult suurele teabetihedusele. Sellest tulenevad uuendused alamdokumentide hankimises, kontekstitõhususes, semantilises mõistmises ja muudes valdkondades on viinud tehisintellektisüsteemide võime hankida teavet ja selle alusel tegutseda drastiliste paranemisteni.

Kuid isegi tehisintellekti jaoks optimeeritud süsteemid on suurel määral pärinud traditsiooniliste otsingumootoritega sama põhilepingu: võta vastu päring, käivita eelnevalt määratletud otsingutöövoog, tagasta täielikult töödeldud tulemuste komplekt. Lihtsate päringute puhul töötab see lähenemine hästi. Kuid keerukamate päringute puhul muutub see üha piiravamaks kitsaskohaks, mis halvendab jõudlust, latentsust ja kulusid.

Traditsioonilised otsingusüsteemid sunnivad agentpõhiseid töövooge otsingut järjestama mudelile nähtavate pöörete kaudu. Mudelid peavad korduvalt kutsuma samu otsingutöövooge erinevate päringuparameetrite lõikes ja lisama kõik tulemused mudeli konteksti.

Traditsioonilised otsingutöövoog on kujundatud ühe kontrollpunkti ümber: päringuparameetrid. Otsingumootor omab ülejäänud töövoogu oma eelnevalt määratletud loogika kohaselt ja mudel peab sellega kohanema. Mudeli jaoks on kõik päringuparameetritest allavoolu jääv jäik – tegeliku arvutuse kuju on väljaspool mudeli kontrolli.

See on mõistlik piir, kui tarbijaks on linke skanniv inimene. See on halb piir, kui tarbijaks on tehisintellekti mudel, mis püüab kinnises tsüklis lahendada teadmistemahukaid ülesandeid. Meie kogemuse kohaselt loob see jäikus kolm korduvat tõrkerežiimi:

Jäme kontekst. Tehisintellekti mudelid on konteksti kvaliteedi ja kompaktsuse suhtes tundlikud. Nii kvaliteet kui ka kompaktsus sõltuvad suurel määral päringust ning monoliitsed otsingutöövoog ei ole loodud optimaalseks toimimiseks kõigi päringute puhul. Näiteks kui mudel vajab ühteainsat väga kirurgilist teavet, kuid tal on juurdepääs ainult lõpp-punkti otsingu otspun-k-t-i-le, mis seab esikohale tagasikutsumise, toob selle otspun-k-i kasutamine mudeli konteksti suure hulga ebaolulist teavet. Teisest küljest, kui mudel vajab palju teavet, millest igaüks nõuab erinevaid otsingustrateegiaid, võib see olla sunnitud kõigi nende jaoks jadaviisiliselt sama ebaoptimaalset torujuhet kutsuma, mille tulemuseks on kasvavad kulud ja mürarikas kontekst.

Valdkonnateadmiste ärakasutamise ebaõnnestumine. Paljudel juhtudel võib mudelil olla valdkonnateadmisi (oma treeningust, agenti oskusest, mälust või LLM-i trajektoori varasematest märkidest), mis peaksid otsingustrateegiat suunama. Jäik otsinguliides aga takistab mudelil neid teadmisi ära kasutada. Näiteks võib mudel konkreetse päringu puhul mõista, et ta peaks segama leksikaalseid ja semantilisi signaale teatud viisil, seadma esikohale teatud allikad või koondama tulemused konkreetse võtme järgi. Kui need arusaamad ei juhtu olema rakendatavad päringuparameetrite kaudu, ei saa mudel nende alusel tegelikult tegutseda.

Ebatõhus juhtimisvoog ja konteksti saastumine. Paljud otsingutöövoog ei ole loomulikult jadapõhised. Nad võivad vajada hargnemist üle päringuvariantide, paralleelset toomist, duplikaatide eemaldamist ja muid toiminguid, mis nõuavad mittelineaarset ja asünkroonset juhtimisvoogu. Nende sammude sundimine läbi korduvate mudelipöörete lisab latentsust ja muudab töövoo optimeerimise raskemaks. Samuti saastab see mudeli konteksti mürarohke vaheolekuga, mis ei pruugi mudeli arutluskäigu jaoks kasulik olla, mille tulemuseks on halvem jõudlus ja sagedasemad tihendamised.

AI funktsioonide kutsumise ja MCP ajastul ei saanud nende väljakutsetega palju ette võtta. Kui iga otsingutoiming nõuab oma edasi-tagasi reisi LLM-i järeldusse, eelistavad arendajad loomulikult saada selle edasi-tagasi reisi jooksul võimalikult palju tehtud. See tähendab lõpp-punkti otsingu torujuhtmeid, mis tagastavad täielikult töödeldud tulemuste komplektid otseseks tarbimiseks mudeli poolt.

Selle tulemusena toimib enamik tehisintellektile suunatud otsingusüsteeme tänapäeval endiselt selle monoliitse lepingu alusel. Mudelite intelligentsuse ja kasutajate nõudmiste jätkuva kasvuga muutuvad selle lepingu puudused siiski ilmsemaks. Tänapäevased kõige edasijõudnumad tehisintellektisüsteemid, mis on ehitatud koodikesksete rakenduste peale, saavad koostada ülesandepõhiseid töövooge, mis täidavad iga minut tuhandeid toiminguid. Otsingusüsteemid ei ole seda potentsiaali veel täielikult realiseerinud.

Oleme pikka aega kahtlustanud, et AI-native otsingu jaoks õige piir asub pinus madalamal. Mudelid ei tohiks otsingumootorit lihtsalt kutsuda. Nad peaksid suutma otsingupinu üksikuid osi vastavalt konkreetse ülesande nõudmistele orkestreerida. See nõuab põhimõtteliselt teistsugust arhitektuuri.

Järgmise põlvkonna otsinguarhitektuurid tuginevad ühele põhiprintsiibile: otsing peaks olema tehisintellekti agentide poolt olemuslikult programmeeritav. Agent ei tohi piirduda etteantud otsingutöövoogude komplektiga. Pigem peab agent suutma konstrueerida torujuhtme, mida konkreetne ülesanne nõuab, kasutades erinevatel abstraktsioonitasemetel kavandatud komponeeritavaid ehitusplokke.

Meie uus otsing koodina (SaC) arhitektuur kehastab seda põhimõtet. SaC-s ei edastata ühtegi hankimistoimingut funktsioonikutse või MCP-liidese kaudu. Selle asemel orkestreeritakse kõiki toiminguid mudeli genereeritud Pythoni koodi kaudu. Lihtsaimate otsinguvajaduste jaoks võib see kood koosneda käputäiest päringutest kõrgetasemelise otsingu lõpp-punkti poole. Keeruliste ülesannete korral võib kood aga olla nii keerukas kui vaja, hõlmates tingimuslikku täitmist, asünkroonsust, paralleelsust ja kutseid paljudele madala taseme primitiividele.

Otsing koodina (SaC) arhitektuur tugineb pinule, mis koosneb mudelitest, arvutusliivakastidest ja agentpõhisest otsingu SDK-st, mis asub Perplexity otsinguinfrastruktuuri peal.

SaC hõlmab kolme tihedalt seotud kihti:

Mudelid toimivad juhtimistasandina. Nad arutlevad kasutaja (või vanemagendi) direktiivi üle, jagavad direktiivi ülesanneteks, otsustavad, milliseid hankimis- ja töötlemistöövooge on iga ülesande jaoks vaja, ning genereerivad koodi nende torujuhtmete rakendamiseks.

Arvutusliivakastid tagavad deterministliku arvutuse turvalise kooditäitmise käitusaja kaudu. Need pakuvad lõuendit mudelitele juhtimisvoo, pakettide töötlemise, korduskatsete, filtreerimise, ühendamise, koondamise ja muude deterministlike toimingute rakendamiseks.

Meie agentpõhine otsingu SDK toob Perplexity otsingupinu esile komponeeritavate primitiividena. See pakub ehitusplokke madala taseme hankimistoimingutest kõrgetasemelise semantilise parsimiseni. SDK on manustatud liivakastide täitmiskeskkondadesse, võimaldades mudelitel ühe järelduspöörde jooksul orkestreerida kuni tuhandeid toiminguid. Allpool käsitleme oma disainiotsuseid iga kihi jaoks.

Agentpõhine otsingu SDK määratleb programmeeritava otsingu ehitusplokid. Oluline on see, et meie SDK ei ole teegina pakendatud eelnev otsingu API. Viimaste kuude jooksul on meie insenerimeeskond muutnud meie otsingupinu modulaarseteks, komponeeritavateks primitiivideks. Oleme ehitanud agentpõhise otsingu SDK, et tagada otsene juurdepääs nendele primitiividele, luues palju võimsama lõuendi, millel mudel saab orkestreerida ülesandepõhiseid hankimistöövooge.

Kõrgetasemelised otsingu lõpp-punkti torujuhtmed on SDK-s endiselt saadaval, kuid need pole enam ainus võimalus. Pigem toimivad need tavaliste otsingumustrite lühendatud vormina. Mudel võib neid ülesande nõudmistel vabalt kasutada või neist mööda hiilida.

Käitusaja valik: kaalusime SDK käituskeskkonnana Pythonit, Rusti, TypeScripti ja Bashi. Kahtlustasime, et Python on selle üldlevinud olemuse ja andmetöötlusteekide ökosüsteemi tõttu kõige loomulikum sobivus. Sisemine testimine kinnitas selle paikapidavust ja täna turule toodav SDK versioon põhineb Pythonil. Eeldame käitusaja valiku perioodilist ümberhindamist, et tagada selle jätkuv parim agentkogemus.

Pidev täiustamine automaatse uurimise kaudu: Oleme optimeerinud SDK tarbitavust tipptasemel LLM-ide jaoks iteratiivse automaatse uurimise tsükli abil. See tsükkel, mis töötab pidevalt mitu nädalat, pakub välja ja kinnitab SDK täiustusi selliste mõõdikute alusel nagu latentsus, koodigeneratsiooni kvaliteet ja üldine ülesande täitmise jõudlus. Automaatse uurimise tsükkel on teinud SDK struktuuris ja esteetikas juba arvukalt muudatusi, saavutades märkimisväärse kasvu kõigis mõõtmetes. Plaanime SDK-d automaatse uurimise kaudu veelgi täiustada, kui ilmnevad uued tipptasemel mudelid ja otsingu komponendid.

Liivakastid pakuvad turvalisi keskkondi SaC torujuhtmete määratlemiseks ja käitamiseks. Nad käivitavad mudeli genereeritud koodi, pakkudes juurdepääsu agentpõhisele otsingu SDK-le, et hõlbustada suhtlust üksikute otsinguprimitiividega.

Oleme teinud märkimisväärseid investeeringuid oma liivakastide optimeerimisse ja karastamisse ning nende ülenev süsteemidisain väärib eraldi artiklit. Siin keskendume SaC jaoks kõige olulisemale disainikaalutlusele: vaheolekute haldamisele.

SaC annab agentidele võimaluse orkestreerida keerulisi töövooge ühe järelduspöörde jooksul. Teatud vaheolekuid on aga vaja pöörete vahel edastada. Näiteks võib mudel soovida tuua mõned dokumendid pöördel 1, kontrollida nende dokumentide alamvalimit pöördel 2, et otsustada, mida edasi teha, ja seejärel töötada välja allavoolu otsingutöövoo, et neid dokumente alates pöördest 3 edasi uurida. Nagu eespool arutatud, ei ole vaheolekute edastamine märgiruumi kaudu tõhus strateegia.

Kaalusime vaheolekute haldamiseks pöörete vahel kahte lähenemisviisi:

Püsiv failisüsteem + selgesõnaline serde: liivakastid saavad pöörete vahel kasutamiseks paljastada püsivad failisüsteemid. Mudelid, mis soovivad vaheolekut säilitada, võivad kaasata pöörde jaoks genereeritud koodi sisse serialiseerimisetapi koos deserialiseerimisetapiga järgneval pöördel (kas mudelite endi kontrollimiseks või allavoolu kasutamiseks). Failisüsteemi lähenemine võimaldab mudelitel otseselt ja selgesõnaliselt kontrollida, kuidas vaheolekut pöörete vahel edastatakse. Samuti tagab see jälgitavuse, nõudes mudeli kasutatava teabe selgesõnalist tuvastamist ja püsivust. Üheks puuduseks on latentsus- ja kontekstikulud, mis tulenevad serde-koodi genereerimisest, kuigi hästi kavandatud utiliidifunktsioonid võivad neid kulusid leevendada.

REPL: Teise võimalusena võib liivakast säilitada täitmiskeskkonna ennast pöörete vahel REPL-laadses keskkonnas. See võimaldab mudelitel säilitada vaheolekut mälus ilma seda üldse serialiseerimata, kuna eemistel pööretel määratletud või muudetud muutujaid saab järgnevatel pööretel lihtsalt nime järgi viidata. REPL-lähenemine on märgitõhusam, kuna see välistab vajaduse genereerida serde-koodi. Selgesõnalise serialiseerimisetapi puudumine võib aga allavoolu jõudlust kahjustada põhjustel, mis on tuttavad kõigile, kes on töötanud 100-rakulisega Jupyteri märkmikuga: muutujate nimeruumi segaseks muutudes on raskem jälgida, mis täpselt pöörete vahel säilib ja miks.

Testisime mõlemat lähenemisviisi ja leidsime, et kuigi need toimivad tavakasutuses sarnaselt, pakub failisüsteemipõhine serde eriti pikkadel trajektooridel paremat töökindlust. Seetõttu võtame oma lahendusena kasutusele failisüsteemipõhise serde. Oletame, et mudelitel riigi deklareerivalt, mitte kaudselt edastamise nõudmine aitab neil seda riiki tõhusamalt hallata. See on esialgne leid ja me jätkame mõlema lähenemisviisi itereerimist.

Agendirakendusi toetavad mudelid toimivad SaC juhtimistasandina: nad panevad dünaamiliselt kokku otsingutöövooge agentpõhise otsingu SDK ehitusplokkidest, et vastata iga ülesande vajadustele, ning edastavad need torujuhtmed koodina liivakastis täitmiseks.

Perplexity kasutab meie agendirakendustes erinevaid modele ning oleme leidnud, et viimased tipptasemel mudelid on üldotstarbelise koodi genereerimisel üsna tõhusad. Peamine väljakutse on esile kutsuda tõhus koodi genereerimine spetsiaalselt agentpõhise otsingu SDK jaoks. Teisisõnu, kuidas saame panna mudelid meie SDK ehitusplokid tõhusalt ülesande jaoks optimeeritud torujuhtmeteks põimima?

Erinevalt keele standardraamatukogust ei ole kohandatud SDK eelkoolitusandmetes tõenäoliselt esindatud. Isegi automaatse uurimise SDK tarbitavuse täiustustega on paljud mudelid endiselt treenitud otsingusüsteemidega suhtlema funktsioonikutsete ja otsese MCP kutsumise kaudu. Need mudelid ei suuda tõenäoliselt SDK-d asjatundlikult käsitseda ainult lähtekoodi ja autogenereeritud dokumentide abil.

Selle väljakutse lahendamiseks oleme välja töötanud kõrgelt häälestatud agenti oskused, et õpetada mudeleid meie SDK-d tõhusalt ära kasutama. Esialgsed versioonid töötati välja Perplexity oskuste disainiprintsiipide kohaselt ja seejärel optimeeriti spetsiaalse automaatse uurimise tsükli abil, mis keskendus samadele mõõdikutele, mida kasutati SDK optimeerimises. Samuti piirame oskuse suurust, et kaitsta konteksti paisumise eest, ja meie lõppversioonidel on juurfailis SKILL.md vähem kui 2000 märki.

Optimeeritud oskused lähevad kaugemale SDK saadaolevate ehitusplokkide loetlemisest (midagi, mida saab sama hõlpsasti hankida käitusaja peegelduse kaudu). Suurem osa märkidest kulutatakse lühikese, üldistatava juhendi ja väheste näidete pakkumisele nende plokkide keerulisteks mustriteks kombineerimiseks. Nende oskustega relvastatud mudelid kasutavad SDK-d tõhusalt ära, et orkestreerida otsingutöövooge, mis ulatuvad tuhandete eraldiseisvate toiminguteni.

Neid kihte ühendades muudab SaC mudelite ja otsingupinu vahelist suhet. Fikseeritud torujuhtmega otsingusüsteemides asub mudel otsingu kohal ja suhtleb sellega kitsa järjestikuse helistaja liidese kaudu. SaC-s saab mudelist aktiivne osaleja otsinguprotsessi enda orkestreerimises. Otsingupinu kõigist elementidest saavad mudeli poolt otse programmeeritavad elemendid, kusjuures liivakast ja agentpõhine otsingu SDK pakuvad nendele elementidele vajalikke liideseid.

Kuidas aga on lood võimalustega, mida algselt ei eksisteeri? Kood on võimas meedium eelnevate võimaluste orkestreerimiseks. Koodi võimsus ulatub aga orkestreerimisest kaugemale. See võib toimida ka lüngatäitjana võimaluste jaoks, mida otsingupinust või SDK-st ei leidu. Agendid saavad kokkuhoidlikkusest kasu ja SDK jaoks oleks ebatõhus katta iga potentsiaalset toimingut spetsiaalse funktsiooniga. Selle asemel pakub SDK kõige fundamentaalsemaid primitiive ja mudel saab koodiga lennult luua mis tahes täiendavaid komponente.

Mõelgem näiteks keerukale regulaaravaldisele, mida pole otsingusüsteemi enda päringusüntaksi abil tõhusalt rakendatav. Ilma kodeerimisvõimetuseta oleks mudel sunnitud genereerima oma parima lähenduse, esitama päringu ja teostama väga mürarohke tulemuste komplekti märgiruumi filtreerimise. SaC-ga saab mudel selle asemel genereerida programmi, mis teeb paralleelseid SDK-kutsungeid soovitud regulaaravaldisetulemuste komplekti ülemhulga kogumiseks. Pärast SDK kaudu duplikaatide eemaldamist saab mudel kirjutada täiendavat koodi, et tulemused deterministlikult täpse regulaaravaldise järgi kitsendada. Sel viisil saavad agendid rakendada kohandatud otsinguvõimalusi ilma SDK-d liiga kitsaste alamprogrammidega paisutamata.

Esitleme juhtumiuuringut, mis põhineb meie testimiskomplekti reaalsel ülesandel. See ülesanne palub agendil tuvastada ja iseloomustada üle 200 kõrge raskusastmega CVE aastatest 2023–2025. Iga kirje peab viitama mõjutatud müüja enda soovitusele, nimetama toote ja parandusversiooni ning näitama, et parandusversioon on seotud konkreetse CVE-ga.

SaC vastus saavutas täpsuse osas 100%, kusjuures märkide kogukasutus langes võrreldes mitte-SaC baastasemega 85,1% (288,7 tuhandelt märgilt 42,9 tuhandele märgile). Testitud mitte-Perplexity süsteemid, mida on üksikasjalikumalt käsitletud jaotises 4, said kõik vähem kui 25%.

Esitleme trajektoorilt kolme stiliseeritud koodiplokki, et illustreerida, kuidas SaC programmeeritavus võimaldab mudelil rakendada tõhusaid strateegiaid.

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

See esimene plokk on puhas orkestreerimine. Genereeritud programm algab allikaklassi reegli kodeerimisega otse päringuplaani: asjakohased on ainult müügile kuuluvad soovituse vormingud. Mitte-müüja allikad, sealhulgas NVD, MITRE, CVE Details, uudisartiklid, CERT-lehed ja kolmandate osapoolte andmebaasid, on struktuuriliselt ulatusest väljas. Täpse fraasi piirangud lükkavad otsingu ka lehtedele, mille indekseeritud tekst sisaldab juba allavoolu vajalikke täpseid CVE üksikasju.

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

Teine plokk kasutab vahepealse planeerimise alamprogrammina LLM-i. Kood võtab kokku, millised müüja-aasta paarid toodavad piisavalt kandidaatlehti, küsib sihitud täpsustusi ja valideerib iga kavandatud päringu enne täitmist. See säilitab trajektoorilt kasulikud mustrid, näiteks saidi ulatusega täpse fraasi sondid ja kohanduva tagasitäite, ilma SDK-sse eritellimusel põhinevat CVE-soovituse roomikut kõvakodeerimata.

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

Viimane plokk on tulemuste kontrollija, mille loogika on agendi poolt koodigeneratsiooni kaudu täielikult määratletud. Kuigi otsingu alamprogrammidega võib leida usutavaid soovituse lehti, nõuab ülesanne rangemat seost: soovitus peab müüja kirjutatud tekstis siduma ühe CVE ühe mõjutatud toote ja ühe parandusversiooniga. Skeem muudab selle seose selgesõnaliseks, nii et allpool asuv kood saab CVE järgi duplikaadid eemaldada, lükata tagasi aggregator URL-id, visata ära nõrgad versioonitõendid ja jätkata tagasitäitmist kuni kirjete arvu alampiiri täitumiseni.

Hindame SaC tõhusust põhjalikus võrdlusaluste komplektis, keskendudes nii absoluutsele jõudlusele kui ka kulude ja jõudluse piirile.

Meie võrdlusaluste komplekt koosneb kokku viiest võrdlusalusest, mis on loodud otsingust sõltuvate tehisintellekti töövoogude stressitestimiseks erinevates valdkondades, ülesandevormingutes ja keerukustasemetes. Kasutame nelja olemasolevat võrdlusalust: DeepSearchQA (DSQA), BrowseComp, Humanity's Last Exam (HLE) ja WideSearch. Esimese kolme võrdlusaluse (DSQA, BrowseComp ja HLE) puhul teatame täpsusest kui peamisest mõõdikust. WideSearchi puhul teatame F1-skoorist rea kaupa.

Kasutame ka äsja välja töötatud WANDR-i võrdlusalust, mis keskendub rasketele laia ulatusega uurimisülesannetele, mis nõuavad otsingu, arvutuse ja mudeli arutluskäigu hoolikat orkestreerimist. WANDR on inspireeritud teadmistemahukatest professionaalsetest ülesannetest, mida Perplexity Computer kasutajate jaoks haldab. See itereerib WideSearchi ja sarnaseid võrdlusaluseid, kuid rõhutab keerukamaid ülesandeid ja ülesannete struktuure. Avaldame WANDR-i võrdlusaluse lähipäevil.

Hindame viit agentipõhist süsteemi. Vaatleme eraldi käivitamisi, mitte „parima N-i“ skoore, et isoleerida aluseks oleva arhitektuuri jõudlus, mitte paralleelsuse eelised. Iga süsteemi konfiguratsioon on kirjeldatud allpool:

Perplexity (SaC): Hindame SaC arhitektuuri Perplexity tootmisagendi API-s. Aluseks oleva mudelina toimib GPT 5.5 (kõrge arutluskäik).

OpenAI: Hindame OpenAI Responses API-d nii lubatud otsingu (web_search) kui ka Pythoni käituskeskkonnaga (code_interpreter). Aluseks oleva mudelina toimib GPT 5.5 (kõrge arutluskäik).

Anthropic: Hindame Anthropic Managed Agentsi 20260401 agenditööriistade komplekti ja automaatselt lubatud käskudega. Aluseks oleva mudelina toimib Opus 4.7 (kõrge arutluskäik).

Exa: Hindame Exa Agentit tootmis-API kaudu, kus vaevatase on määratud kõrgele.

Parallel: Hindame Parallel Tasksi tootmis-API kaudu, kus protsessor on seadistatud väärtusele ultra4x.

Tabel 1 esitab iga süsteemi võrdlusskoorid. SaC edastab kõiki teisi süsteeme neljas viiest võrdlusalusest. Ülejäänud võrdlusalusel (HLE) jagab SaC sisuliselt esikohta OpenAI Responsesiga. Sissejuhatusejoonis 2 visualiseerib neid skoore graafilisel kujul.

Võrdlusalus	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

Tabel 1 | Iga hinnatud süsteemi võrdlusskoorid. Parim skoor rea kohta paksus kirjas.

Kuigi SaC saavutab võrdlusaluste komplektis tipptasemel jõudluse, on selle eelis eriti ilmne WANDR-is. Joonis 5 jagab WANDR-i skoorid osadeks, näidates, et Perplexity SaC juurutus edastab paremuselt järgmist süsteemi 2,5 korda. Vaatamata sellele suurele marginaalile on WANDR endiselt küllastumata ja osutub keeruliseks isegi SaC jaoks. Usume, et WANDR-i ülesannete poolt nõutavad keerulised, väga horisontaalsed otsingutöövoog nõuavad pidevalt kõrge jõudluse saavutamiseks täiendavaid edusamme teadusuuringutes ja otsingutehnikas.

WANDR-i skoorid hinnatud süsteemide lõikes. Perplexity Agent API edestab paremuselt järgmist süsteemi 2,5 korda.

Lõpuks mõõdame SaC suhtelisi saavutusi võrreldes traditsioonilisema otsingupinuga, mis kasutab sama Perplexity otsinguinfrastruktuuri. Joonis 6 kajastab skooride erinevust SaC ja mitte-SaC arhitektuuride vahel iga võrdlusaluse lõikes. SaC pakub märkimisväärset jõudluse tõusu kogu ulatuses, suurima absoluutse kasvuga DSQA-s (+19,77 pp, 29%) ja suurima suhtelise kasvuga WANDR-is (+12,00 pp, 45%).

Perplexity baastase vs. SaC skoor iga võrdlusaluse puhul, kusjuures absoluutsed ja suhtelised deltad on märgitud.

Praktikas huvitab kasutajaid jõudlus kulude suhtes. Seetõttu hindame DSQA ja WideSearchi kulude ja jõudluse piiri. Mõõdame SaC kulusid ja jõudlust madalal, keskmisel ja kõrgel mudeli arutluskäigu tasemel koos teiste süsteemidega. Joonised 7 ja 8 joonestavad võrdlusskoori ülesande hinna vastu, kusjuures x-telg on ümber pööratud, nii et paremal asuvad punktid on odavamad ja kõrgemal asuvad punktid tähistavad paremat jõudlust.

DSQA skoor versus ülesande hind. Katkendlik joon ühendab SaC mudeli arutluskäigu konfiguratsioone.

DSQA-s asuvad kõik kolm SaC seadistust ülemises parempoolses piiris. Madala arutluskäigu seadistus on odavam kui kõik teised süsteemid, toimides samal ajal paremini kui kaks neist. Keskmise arutluskäigu seadistus edestab kõiki mitte-SaC süsteeme alla 1 dollari eest ülesande kohta. Kõrge arutluskäigu seadistus saavutab tipptasemel jõudluse konkurentsivõimelise hinnaga.

WideSearchi skoor versus ülesande hind. Katkendlik joon ühendab SaC mudeli arutluskäigu konfiguratsioone.

WideSearch näitab sarnase kujuga piiri. Nagu DSQA puhul, saavutab madala arutluskäigu seadistus konkurentsivõimelise jõudluse madalama hinnaga kui kõik mitte-SaC süsteemid, samas kui nii keskmine kui ka kõrge arutluskäik edestavad mitte-SaC süsteeme ülesannete täitmisel.

Otsing koodina peegeldab laiemat muutust tarkvaradisainis. Aastakümneid olid tarkvarasüsteemid korraldatud deterministlike juhiste ümber, mida täitsid traditsioonilised käituskeskkonnad CPU-del. Tipptasemel mudelid toovad sisse uue arvutusvormi: märgiruumi arutluskäigu, mis suudab nii juhiseid järgida kui ka neid genereerida. Kõige võimekamad arvutussüsteemid kombineerivad neid kahte arvutusvormi, selle asemel et nende vahel valida.

Otsing on selle hübriidarhitektuuri jaoks loomulik katsepolügoon. Mudelid sobivad hästi otsustama, milliseid tõendeid on vaja ja kuidas ebakindlust tuleks lahendada. Deterministlikud käituskeskkonnad sobivad hästi pakettide töötlemiseks, paralleelsuseks, filtreerimiseks, järjestamiseks ja koondamiseks. Otsinguinfrastruktuur toimib universaalse I/O kihina, pakkudes käituskeskkonnale kasulikke käepidemeid maailma teabeni, mis suudavad toetada tuhandeid toiminguid minutis. Kui need osad on integreeritud, on saadaval olev süsteem reaalsete ülesannete täitmisel palju võimsam ja tõhusam.

Selle arhitektuuri iga osa on nende võimaluste avamiseks hädavajalik. Ilma intelligentsete mudeliteta ei saa süsteem otsingustrateegia üle arutleda. Ilma liivakastideta on mudelid sunnitud jadajuurdepääsuga I/O-sse ja ebatõhusasse märgiruumi töötlemisse. Ja ilma atomiseeritud otsingupinuta pole mudelil midagi orkestreerida. SaC toimib seetõttu, et arutluskäik, deterministlik arvutus ja I/O on ühiselt loodud iga kihi tugevuste esiletoomiseks.

Seda koodidisaini saab pideva täiustamise tsüklite arendamise kaudu veelgi kaugemale viia. Näiteks võib agentpõhise otsingu SDK ja SaC agenti oskused ühiselt optimeerida tavalises automaatse uurimise tsüklis. Julgemalt öeldes saab mudeleid treenida ära kasutama SDK-na avaldatud madala taseme otsinguprimitiive. Võib isegi proovida SDK disaini mudeli treenimisprotsessi ajal ise kaasarengusse viia. Ootame huviga agressiivsemate koodidisaini strateegiate elluviimist tulevastes töödes.

Ehitasime SaC, et võimaldada mudelitel otsinguprotsessi kontrollida, mitte ainult selle tulemusi tarbida. Meie tulemused tõestavad selle kontrolli võimsust: SaC viib edasi nii absoluutset jõudlust kui ka kulude ja jõudluse piiri teadmistemahukates agendi võrdlusalustes. Meil on hea meel tuua SaC võimalused oma kasutajateni, alustades tänasest Perplexity Computerist ja Agent API-st. Jätkame SaC arhitektuuri optimeerimist pinu kõigis kihtides, et tagada meie kasutajatele (ja neid teenindavatele agentidele) võimalikult võimsad ja tõhusad otsinguvõimalused.

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

Sissejuhatus

Traditsioonilise otsingu jäikus

Jäikusest tulenevad tõrkerežiimid

Programmeeritava otsinguarhitektuuri kavandamine

Agentpõhine otsingu SDK

Liivakastid

Mudelid

Kood orkestreerija ja lüngatäitjana

Juhtumiuuring: CVE müüja soovitused

Hindamistulemused

Võrdlusalused ja süsteemid

Võrdlev jõudlus

Kulude ja jõudluse piir

Uue arvutusarhitektuuri suunas

Tsitaat