Repensar la cerca com a generació de codi

La cerca és un element primitiu fonamental per als sistemes d'IA. Els models de frontera cada mes són més capaços, però encara necessiten accés a coneixement fresc, precís i ben comissariat del món exterior. La cerca és la manera principal amb què els sistemes d'IA aprofiten aquest coneixement i, per tant, un component bàsic de qualsevol producte que necessiti extreure conclusions, prendre mesures i dur a terme treballs al món real.

Creiem que els pipelines de cerca tradicionals s'estan quedant antiquats en l'era dels agents. La cerca tradicional respon a consultes, però els agents d'avui dia completen tasques que poden adoptar formes incomptables. Aquestes tasques requereixen que els agents defineixin estratègies de recuperació específiques per a la tasca directament dins dels seus entorns. A Perplexity Computer, hem vist tasques individuals que invoquen centenars o fins i tot milers d'operacions de recuperació en pocs minuts: un flux de treball que resulta impossible per als humans, però completament natural per als agents.

En aquest món, la cerca en si ha de ser agència, amb els seus blocs de construcció accessibles directament com a SDKs dins de l'entorn de l'agent. Presentem Search as Code (SaC) com la nova arquitectura de cerca de referència de Perplexity.

Introducció

La pila de cerca de Perplexity serveix milers de consultes cada segon a totes les nostres aplicacions i a l'API Platform. El setembre de 2025, vam publicar la primera visió general de l'arquitectura dels nostres sistemes de cerca. La innovació constant en aquests sistemes ha donat suport al llançament de noves ofertes com Search API, Agent API i Computer, amb bucles d'auto-millora que optimitzen la pila de cerca per servir millor als usuaris dia rere dia.

Tradicionalment, els sistemes d'IA han tractat la cerca com un monolit: un model d'IA emet una consulta, el motor de cerca executa el seu pipeline predefinit i el model consumeix els resultats com a context. Majoritàriament, això ha funcionat prou bé per satisfer les necessitats dels primers usuaris d'IA. Donada la relativa simplicitat de les seves peticions, no hi havia cap motiu per preocupar-se exactament de com s'havia dissenyat el pipeline de cerca, o de si l'arquitectura del pipeline era òptima per a la tasca en qüestió. Es assumia que els valors predeterminats eren prou bons, igual que les interfícies predeterminades (crida a funcions i MCPs).

Amplia

Tot i això, avui dia aquest enfocament esdevé més antiquat cada mes que passa. Els usuaris exigeixen molt més que una anàlisi d'un sol tret per part de la IA. Esperen que els agents completin tasques d'extrem a extrem al llarg d'hores o fins i tot dies. Aquestes tasques poden ser complexes, obertes i altament variables en les seves necessitats d'informació, i les arquitectures monolítiques s'estan vinclant sota el pes d'aquestes demandes.

El coll d'ampolla clau és, en última instància, un assumpte de control. Els models de frontera ja són bastant bons raonant sobre context fix. No obstant això, els sistemes d'IA més potents requeriran la capacitat de dirigir com es recupera, processa, agrega i renderitza aquest context al model.

Els sistemes de cerca tradicionals no es van dissenyar tenint en compte aquest grau de controlabilitat. Al cap i a la fi, no es pot esperar que els usuaris humans exerceixin un control de gra fi sobre les interioritats del pipeline de cerca, fins i tot si s'oferís. Els primers models d'IA només poden controlar la cerca a través d'una trajectòria lineal de crides de funcions i MCPs. Però els models de frontera d'avui dia, impulsats per entorns d'agents capaços de generar codi, poden exercir un control de gra fi sobre qualsevol primitiva computacional imaginable a través del codi informàtic. La nostra tasca passa a ser proporcionar les primitives adequades.

Per satisfer aquesta necessitat, introduïm una nova arquitectura de cerca a tots els nostres productes: Search as Code (SaC). Aquesta nova arquitectura capacita els models per arribar dins de la pròpia pila de cerca en lloc de merament consumir els seus resultats finals. La idea central és directa: exposem els components de la pila de cerca com a primitives dins d'un SDK. Per a qualsevol petició que necessiti cerca, un model reuneix aquestes primitives sota demanda en un pipeline de cerca adaptat a aquesta petició específica.

La unió d'aquest pipeline es fa mitjançant la generació i execució de codi dins d'un entorn de proves segur. A diferència d'altres enfocaments de cerca impulsats per generació de codi, no ens limitem a col·locar una API de cerca tradicional dins d'un intèrpret d'ordres o d'un entorn d'execució de llenguatge. En canvi, hem dissenyat curosament un SDK de cerca d'agents que exposa els blocs de construcció individuals de la cerca al nivell més atòmic possible.

Amplia

Armat amb aquests blocs de construcció, SaC dóna als models un control directe sobre cada pas de cerca individual: recuperació, rànquing, filtratge, ramificacions, renderització i molt més. També proporciona al model un accés eficient a l'estat intermedi com ara llistes de candidats i senyals de rànquing. Junts, aquests dos palanques de control i llegibilitat permeten als agents dissenyar pipelines de cerca a mida que abasten milers d'operacions de recuperació, optimitzar aquests pipelines en ple vol i consumir només la informació més útil com a context del model.

Aquest article descriu la motivació, el disseny i la implementació de SaC, juntament amb resultats empírics tant en referències existents com noves. SaC estableix una nova frontera de cost-rendiment per a la cerca d'agents, i estem encantats de compartir-la amb els nostres usuaris i la comunitat d'IA en general.

La rigidesa de la cerca tradicional

Els primers motors de cerca del món es van construir per a usuaris humans. Aquests usuaris van començar a esperar una experiència predictible, normalment consistent en un nombre fix de documents ordenats per rellevància. Els usuaris no volien microgestionar el procés de cerca; volien introduir una consulta i trobar un resultat útil.

Com a resultat, els motors de cerca orientats a humans van convergir en una arquitectura monolítica comuna, orientada a produir pàgines de resultats de motors de cerca (SERP) amigables per a l'usuari que contenen els principals resultats per a una consulta d'entrada. Aquest patró ha impulsat dècades de progrés en la cerca de consumidors. És ràpid, familiar i altament eficaç per a la navegació humana.

Després van arribar els LLM, i els sistemes d'IA també es van convertir en consumidors de cerca. Perplexity va ser pionera en aquest canvi amb el llançament del nostre motor de respostes el 2022. Des de llavors, els nostres esforços d'enginyeria de cerca s'han centrat en com optimitzar el valor dels resultats de cerca per als models d'IA. Per construir la IA més precisa i fiable del món, vam haver de dissenyar un sistema de cerca centrat a fer que cada testimoni fos tan dens en informació com fos possible. Les innovacions resultants en recuperació de subdocuments, eficiència del context, comprensió semàntica i altres àrees clau van portar a millores espectaculars en la capacitat dels sistemes d'IA per recuperar i actuar sobre la informació.

No obstant això, fins i tot els sistemes optimitzats per a la IA han heretat en gran mesura el mateix contracte fonamental que els motors de cerca tradicionals: acceptar una consulta, executar un pipeline de cerca predefinit, retornar un conjunt de resultats completament processat. Per a peticions simples, aquest enfocament funciona bé. Però per a peticions més complexes, esdevé un coll d'ampolla cada cop més limitant que degrada el rendiment, la latència i el cost.

Amplia

Maneres de fallada a causa de la rigidesa

Els pipelines de cerca tradicionals estan dissenyats al voltant d'un únic punt de control: els paràmetres de consulta. El motor de cerca gestiona la resta del pipeline segons la seva lògica predefinida, i el model s'hi ha d'adaptar. Per al model, tot el que es troba aigües avall dels paràmetres de consulta és rígid; la forma del càlcul real està fora del control del model.

Aquest és un límit sensat quan el consumidor és un humà que escaneja enllaços. És un límit pobre quan el consumidor és un model d'IA que intenta resoldre tasques intensives en coneixement en un bucle tancat. Segons la nostra experiència, aquesta rigidesa crea tres maneres de fallada recurrents:

Context groller. Els models d'IA són sensibles a la qualitat i la compacitat del context. Tant la qualitat com la compacitat depenen altament de la consulta, i els pipelines de cerca monolítics no estan dissenyats per funcionar de manera òptima en totes les consultes. Per exemple, si un model necessita una sola peça d'informació altament quirúrgica, però només té accés a un punt final de cerca d'extrem a extrem que prioritza la recuperació, utilitzar aquest punt final introduirà una gran quantitat d'informació irrellevant al context del model. D'altra banda, si un model necessita moltes peces d'informació que requereixen cadascuna estratègies de cerca diferents, pot veure's obligat a invocar de manera sèrie el mateix pipeline subòptim per a totes elles, la qual cosa es tradueix en costos creixents i un context sorollós.

Incapacitat d'aprofitar el coneixement del domini. En molts casos, el model pot tenir coneixement del domini (de la seva formació, una Skill d'agent, memòria o testimonis anteriors en la trajectòria de l'LLM) que hauria de guiar l'estratègia de cerca. No obstant això, una interfície de cerca rígida impedeix que el model aprofiti aquest coneixement. Per exemple, el model pot adonar-se per a una petició específica que hauria de combinar senyals lèxics i semàntics d'una manera particular, prioritzar determinades fonts o agregar resultats per una clau específica. Tret que aquestes idees s'esdevinguin implementables mitjançant paràmetres de consulta, el model no pot actuar realment sobre elles.

Flux de control ineficient i contaminació del context. Molts fluxos de treball de cerca no són naturalment de sèrie. Poden necessitar ramificacions sobre variants de consulta, obtenció paral·lela, desduplicació i altres operacions que requereixen un flux de control no lineal i asíncron. Forçar aquests passos a través de torns repetits del model afegeix latència i fa que el flux de treball sigui més difícil d'optimitzar. També pol·lueix el context del model amb un estat intermedi sorollós que pot no ser útil per al raonament del model, donant lloc a un rendiment més pobre i compactacions més freqüents.

No es podia fer gaire cosa sobre aquests reptes durant les eres de crida de funcions i MCP de la IA. Quan cada operació de cerca requereix el seu propi viatge d'anada i tornada a la inferència de l'LLM, els desenvolupadors naturalment prefereixen fer tant com sigui possible en aquest viatge. Això significa pipelines de cerca d'extrem a extrem que retornen conjunts de resultats completament processats per al consum directe per part d'un model.

Com a resultat, la majoria dels sistemes de cerca orientats a la IA d'avui dia encara operen sota aquest contracte monolític. No obstant això, amb el creixement continuat de la intel·ligència dels models i les demandes dels usuaris, les deficiències d'aquest contracte es fan més pronunciades. Els sistemes d'IA més avançats d'avui dia, construïts a sobre d'entorns orientats al codi, poden compondre fluxos de treball específics de la tasca que executen milers d'accions cada minut. Els sistemes de cerca encara han de realitzar plenament aquest potencial.

Fa temps que sospitem que el límit adequat per a la cerca nativa d'IA es troba més avall a la pila. Els models no s'han de limitar a cridar un motor de cerca. Haurien de poder orquestrar les peces individuals de la pila de cerca a mesura que la tasca específica ho requereix. Això requereix una arquitectura fonamentalment diferent.

Disseny d'una arquitectura de cerca programable

La propera generació d'arquitectures de cerca dependrà d'un principi central: la cerca ha de ser programable de manera nativa pels agents d'IA. Un agent no s'ha de limitar a un conjunt de pipelines de cerca predeterminats. Més aviat, un agent ha de poder construir el pipeline que requereix la tasca específica, utilitzant blocs de construcció composables dissenyats a diferents nivells d'abstracció.

La nostra nova arquitectura Search as Code (SaC) encarna aquest principi. A SaC, no s'envia ni una sola operació de recuperació a través d'una interfície de crida de funcions o MCP. En canvi, totes les operacions s'orquestren mitjançant codi Python generat pel model. Per a les necessitats de cerca més simples, aquest codi pot consistir en un grapat de peticions a un punt final de cerca d'alt nivell. Però per a tasques complexes, el codi pot ser tan intrincat com sigui necessari, implicant execució condicional, asincronia, paral·lelisme i crides a una àmplia gamma de primitives de baix nivell.

Amplia

SaC implica tres capes estretament acoblades:

Els models serveixen com a pla de control. Raonen sobre la directiva de l'usuari (o agent principal), descomponen la directiva en tasques, decideixen quins pipelines de recuperació i processament es necessiten per a cada tasca i generen codi per implementar aquests pipelines.

Els entorns de proves de càlcul proporcionen un càlcul determinista mitjançant un entorn d'execució de codi segur. Proporcionen un llenç perquè els models implementin el flux de control, l'agrupació en lots, els reintents, el filtratge, la unió, l'agregació i altres operacions deterministes.

El nostre SDK de cerca d'agents exposa la pila de cerca de Perplexity com a primitives composables. Proporciona blocs de construcció des d'operacions de recuperació de baix nivell fins a anàlisi semàntica d'alt nivell. L'SDK està incrustat dins dels entorns d'execució dels entorns de proves, permetent als models orquestrar fins a milers d'operacions dins d'un únic torn d'inferència. A continuació, discutim les nostres decisions de disseny per a cada capa.

L'SDK de cerca d'agents

L'SDK de cerca d'agents defineix els blocs de construcció per a la cerca programable. És important destacar que el nostre SDK no és una API de cerca preexistent empaquetada com a biblioteca. Durant els darrers mesos, el nostre equip d'enginyeria ha rearquitecturat la nostra pila de cerca en primitives modulars i composables. Hem construït l'SDK de cerca d'agents per proporcionar accés directe a aquestes primitives, creant un llenç molt més potent sobre el qual el model pot orquestrar pipelines de cerca específics de la tasca.

Els pipelines de cerca d'alt nivell i d'extrem a extrem encara estan disponibles dins de l'SDK, però ja no són l'única opció. Més aviat, serveixen com una mena de forma abreujada per als patrons de cerca comuns. El model té la llibertat d'utilitzar-los o passar-los per alt a mesura que la tasca ho requereixi.

Elecció de l'entorn d'execució: Vam considerar Python, Rust, TypeScript i Bash com a entorn d'execució de l'SDK. Sospitàvem que Python seria el més natural donada la seva ubiqüitat i ecosistema de biblioteques de processament de dades. Les proves internes van confirmar que aquest era el cas, i la versió de l'SDK que s'està llançant avui es basa en Python. Esperem reavaluar periòdicament l'elecció de l'entorn d'execució per assegurar-nos que continua proporcionant la millor experiència d'agent.

Millora contínua mitjançant autorecerca: També hem optimitzat la consumibilitat de l'SDK per als LLM de frontera mitjançant un bucle d'autorecerca iteratiu. Aquest bucle, que s'executa contínuament durant setmanes, proposa i valida millores de l'SDK enfront de mètriques que inclouen la latència, la qualitat de la generació de codi i el rendiment general de la tasca. El bucle d'autorecerca ja ha fet nombrosos canvis tant a l'estructura com a l'estètica de l'SDK, amb guanys significatius en totes les dimensions. Tenim previst perfeccionar encara més l'SDK mitjançant l'autorecerca a mesura que sorgeixin nous models de frontera i components de cerca.

Entorns de proves

Els entorns de proves proporcionen entorns segurs per definir i executar pipelines de SaC. Executen codi generat pel model, proporcionant accés a l'SDK de cerca d'agents per facilitar la interacció amb les primitives de cerca individuals.

Hem realitzat inversions significatives en l'optimització i l'enduriment dels nostres entorns de proves, i el seu disseny de sistema global mereix un article propi. Aquí, ens centrem en la consideració de disseny més rellevant per a SaC: la gestió dels estats intermedis.

SaC capacita els agents per orquestrar pipelines complexos dins d'un únic torn d'inferència. No obstant això, certs estats intermedis s'han de transmetre a través de torns. Per exemple, un model pot voler recuperar alguns documents en el torn 1, inspeccionar una submostra d'aquests documents en el torn 2 per decidir què fer a continuació, i després desenvolupar un pipeline de cerca aigües avall per investigar més a fons aquests documents a partir del torn 3 en endavant. Com s'ha comentat anteriorment, passar estats intermedis a través de l'espai de testimonis no és una estratègia eficaç.

Vam considerar dos enfocaments per gestionar els estats intermedis a través dels torns:

Sistema de fitxers persistent + serde explícit: Els entorns de proves poden exposar sistemes de fitxers persistents perquè els models els utilitzin a través de torns. Els models que desitgin persistir l'estat intermedi poden incloure un pas de serialització dins del codi generat per a un torn, juntament amb un pas de deserialització dins d'un torn subsegüent (ja sigui per a la pròpia inspecció dels models o per a un ús aigües avall). L'enfocament del sistema de fitxers permet als models controlar de manera directa i explícita com es transmet l'estat intermedi a través dels torns. També garanteix la traçabilitat en fer complir la identificació explícita i la persistència de la informació utilitzada pel model. Un desavantatge és la sobrecàrrega de latència i context incorreguda per la generació del codi de serde, tot i que les funcions d'utilitat ben dissenyades poden mitigar aquesta sobrecàrrega.

REPL: Alternativament, un entorn de proves pot persistir el propi entorn d'execució a través dels torns en un entorn d'estil REPL. Això permet als models mantenir l'estat intermedi a la memòria sense haver de serialitzar-lo en absolut, ja que les variables definides o modificades en torns anteriors simplement es poden referenciar pel nom en torns subsegüents. L'enfocament REPL és més eficient pel que fa als testimonis, ja que evita la necessitat de generar codi de serde. No obstant això, la manca d'un pas de serialització explícit pot perjudicar el rendiment aigües avall per raons familiars a qualsevol que hagi treballat amb un quadern Jupyter de 100 cel·les: a mesura que l'espai de noms de les variables s'amuntega, es fa més difícil fer un seguiment del que es persisteix precisament a través dels torns i per què.

Vam provar tots dos enfocaments i vam trobar que, tot i que funcionen de manera similar en l'ús ordinari, el serde basat en el sistema de fitxers proporciona una millor fiabilitat en trajectòries particularment llargues. Per tant, adoptem el serde basat en el sistema de fitxers com la nostra solució. Suposem que exigir als models que transmetin l'estat de manera declarativa en lloc d'implícita els ajuda a gestionar aquest estat de manera més eficaç. Aquesta és una troballa provisional i continuarem iterant en ambdós enfocaments.

Models

Els models que alimenten els entorns d'agents serveixen com a pla de control de SaC: acoblant dinàmicament pipelines de cerca a partir dels blocs de construcció de l'SDK de cerca d'agents per satisfer les necessitats de cada tasca, i després enviant aquests pipelines com a codi per a l'execució a l'entorn de proves.

Perplexity empra una varietat de models dins dels nostres entorns d'agents, i hem trobat que els últims models de frontera són bastant eficaços en general en la generació de codi de propòsit general. el repte principal és induir una generació de codi eficaç específicament per a l'SDK de cerca d'agents. És a dir, com podem fer que els models entrellacin eficaçment els blocs de construcció del nostre SDK en pipelines optimitzats per a tasques?

A diferència de la biblioteca estàndard d'un llenguatge, és poc probable que un SDK de fabricació pròpia estigui representat en les dades de preentrenament. Fins i tot amb les millores de consumibilitat de l'SDK derivades de l'autorecerca, molts models encara estan entrenats per interactuar amb els sistemes de cerca mitjançant crides de funcions i la invocació directa d'MCP. És poc probable que aquests models manegin amb experiència l'SDK només amb codi font i documentació autogenerada.

Per resoldre aquest repte, hem desenvolupat Skills d'agent altament afinades per ensenyar als models a aprofitar eficaçment el nostre SDK. Les versions inicials es van desenvolupar segons els principis de disseny de Perplexity per a Skills, i després es van optimitzar a través d'un bucle d'autorecerca dedicat centrat en les mateixes mètriques utilitzades en l'optimització de l'SDK. També limitem la mida de les skills per protegir-nos contra la inflació del context, i les nostres versions finals tenen menys de 2000 testimonis als seus fitxers arrel SKILL.md.

Les Skills optimitzades van més enllà de llistar els blocs de construcció disponibles de l'SDK (cosa que es pot obtenir igualment fàcilment mitjançant la reflexió en temps d'execució). El gruix dels testimonis es dedica a proporcionar orientació concisa i generalitzable i exemples de pocs trets per compondre aquests blocs en patrons complexos. Armats amb aquestes Skills, observem que els models aprofiten eficaçment l'SDK per orquestrar pipelines de cerca que s'escalen a milers d'operacions discretes.

El codi com a orquestrador i connector de buits

En combinar aquestes capes, SaC canvia la relació entre els models i la pila de cerca. En els sistemes de cerca de pipeline fix, el model se situa per sobre de la cerca i hi interactua a través d'una interfície de trucades en sèrie estreta. A SaC, el model es converteix en un participant actiu en l'orquestració del procés de cerca en si. Tots els elements de la pila de cerca esdevenen directament programables pel model, amb l'entorn de proves i l'SDK de cerca d'agents proporcionant les interfícies necessàries per a aquests elements.

Però què passa amb les capacitats que no existeixen de manera nativa? El codi és un mitjà potent per orquestrar capacitats preexistents. No obstant això, el poder del codi va més allá de l'orquestració. També pot servir com a connector de buits per a capacitats que no estan presents a la pila de cerca o a l'SDK. Els agents es beneficien de la parsimònia, i seria ineficient que l'SDK cobrís cada operació potencial amb una funció dedicada. En canvi, l'SDK proporciona les primitives més fonamentals, i el model pot construir qualsevol component addicional sobre la marxa amb codi.

Considereu, per exemple, una expressió regular complexa que no es pot implementar de manera eficient mitjançant la pròpia sintaxi de consultes del sistema de cerca. Sense capacitats de codificació, el model es veuria obligat a generar la seva millor aproximació, fer una consulta i realitzar un filtratge en l'espai de testimonis sobre un conjunt de resultats molt sorollós. Amb SaC, el model pot generar en el seu lloc un programa que faci crides paral·leles a l'SDK per recollir un superconjunt del conjunt de resultats de l'expressió regular desitjada. Després de la desduplicació a través de l'SDK, el model pot escriure codi addicional per reduir deterministament els resultats a l'expressió regular exacta. D'aquesta manera, els agents poden implementar capacitats de cerca personalitzades sense inflar l'SDK amb subrutines excessivament de nínxol.

Estudi de cas: avisos de proveïdors de CVE

Presentem un estudi de cas basat en una tasca del món real dins del nostre conjunt de proves. Aquesta tasca demana a un agent que identifiqui i caracteritzi més de 200 CVE d'alta severitat del període 2023–2025. Cada registre ha de citar l'avís propi del proveïdor afectat, anomenar el producte i la versió de correcció, i mostrar que la versió de correcció està lligada al CVE específic.

La resposta de SaC va obtenir un 100% de precisió, amb l'ús total de testimonis disminuint un 85,1% en relació amb la línia de base sense SaC (de 288,7K testimonis a 42,9K testimonis). Els sistemes provats sense Perplexity, discutits amb més detall a la Secció 4, van obtindre tots puntuacions inferiors al 25%.

Presentem tres blocs de codi estilitzats de la trajectòria per il·lustrar com la programabilitat de SaC permet al model implementar estratègies eficaces.

Aquest primer bloc és purament d'orquestració. El programa generat comença codificant la regla de la classe de font directament al pla de consulta: només els formats d'avís propietat del proveïdor són rellevants. Les fonts alienes al proveïdor, incloent-hi NVD, MITRE, CVE Details, notícies, pàgines de CERT i bases de dades de tercers, queden estructuralment fora de l'abast. Les restriccions de frase exacta també empenyen la cerca cap a pàgines el text indexat de les quals ja conté els detalls exactes de la CVE necessaris aigües avall.

El segon bloc utilitza un LLM com a subrutina de planificació intermèdia. El codi resumeix quins parells proveïdor-any estan produint suficients pàgines candidates, demana refinaments dirigits i valida cada consulta proposta abans de l'execució. Així es preserven patrons útils de la trajectòria, com ara sondes de frases exactes amb àmbit de lloc i reompliment adaptatiu, sense codificar de manera fixa un rastrejador d'avisos de CVE a mida a l'SDK.

El bloc final és un verificador de resultats la lògica del qual està definida íntegrament per l'agent mitjançant la generació de codi. Tot i que les subrutines de cerca poden trobar pàgines d'avís plausibles, la tasca requereix una relació més estricta: l'avís ha de vincular un CVE a un producte afectat i una versió de correcció en un text escrit pel proveïdor. L'esquema fa que aquesta relació sigui explícita, de manera que el codi aigües avall pot desduplicar per CVE, rebutjar URL d'agregadors, descartar proves de versió febles i continuar reomplint fins que s'assoleixi el mínim de recomptes de registres.

Resultats de l'avaluació

Avaluem l'eficàcia de SaC en un conjunt de referència exhaustiu, centrant-nos tant en el rendiment absolut com en la frontera de cost-rendiment.

Referències i sistemes

El nostre conjunt de referència comprèn cinc referències en total, dissenyades per posar a prova fluxos de treball d'IA dependents de la cerca a través d'un rang de dominis, formats de tasques i nivells de complexitat. Utilitzem quatre referències preexistents: DeepSearchQA (DSQA), BrowseComp, Humanity's Last Exam (HLE) i WideSearch. Per a les tres primeres referències (DSQA, BrowseComp i HLE), informem de la precisió com a mètrica principal. Per a WideSearch, informem de la puntuació F1 per fila.

També utilitzem la referència WANDR, recentment desenvolupada, que se centra en tasques difícils de "recerca àmplia" que requereixen una acurada orquestració de la cerca, el càlcul i el raonament del model. WANDR s'inspira en les tasques professionals intensives en coneixement que Perplexity Computer gestiona per als usuaris. Itera sobre WideSearch i referències similars, però posa èmfasi en tasques i estructures de tasques més complexes. Publicarem la referència WANDR a les properes setmanes.

Avaluem cinc sistemes basats en agents. Considerem execucions individuals en lloc de puntuacions de "millor de N" per tal d'aïllar el rendiment de l'arquitectura subjacent en lloc dels beneficis de la paral·lelització. La configuració de cada sistema es descriu a continuació:

Perplexity (SaC): Avaluem l'arquitectura SaC dins de l'Agent API de producció de Perplexity. GPT 5.5 (alt raonament) serveix com a model subjacent.

OpenAI: Avaluem l'API de respostes d'OpenAI amb la cerca (web_search) i l'entorn d'execució de Python (code_interpreter) habilitats. GPT 5.5 (alt raonament) serveix com a model subjacent.

Anthropic: Avaluem els agents gestionats d'Anthropic amb el conjunt d'eines d'agents 20260401 i ordres permeses automàticament. Opus 4.7 (alt raonament) serveix com a model subjacent.

Exa: Avaluem Exa Agent mitjançant l'API de producció, amb l'esforç establert a alt.

Parallel: Avaluem Parallel Tasks mitjançant l'API de producció, amb el processador establert a ultra4x.

Rendiment comparatiu

La Taula 1 informa de les puntuacions de referència per a cada sistema. SaC supera a tots els altres sistemes en quatre de les cinc referències. En la referència restant (HLE), SaC empata prèviament pel primer lloc amb OpenAI Responses. La Figura 2 de la Introducció visualitza aquestes puntuacions en forma gràfica.

Taula 1 | Puntuacions de referència per a cada sistema avaluat. La millor puntuació per fila en negreta.

Tot i que SaC aconsegueix un rendiment d'última generació en tot el conjunt de referència, el seu avantatge és particularment pronunciat a WANDR. La Figura 5 desglossa les puntuacions de WANDR, mostrant que la implementació SaC de Perplexity supera el segon millor sistema per un factor de 2,5×. Malgrat aquest gran marge, WANDR continua sent insaturat i resulta desafiant fins i tot per a SaC. Creiem que els fluxos de treball de cerca complexos i altament horitzontals requerits per les tasques de WANDR necessitaran avenços addicionals en recerca i enginyeria de cerca per aconseguir un rendiment consistentment alt.

Amplia

Finalment, mesurem els guanys relatius de SaC enfront d'un pipeline de cerca més tradicional que aprofita la mateixa infraestructura de cerca de Perplexity. La Figura 6 informa de la diferència de puntuacions entre les arquitectures SaC i no SaC a cada referència. En general, SaC proporciona un impuls substancial en el rendiment, amb el guany absolut més gran a DSQA (+19,77 pp, 29%) i el guany relatiu més gran a WANDR (+12,00 pp, 45%).

Amplia

Frontera de cost-rendiment

A la pràctica, als usuaris els importa el rendiment en relació amb el cost. Per tant, avaluem la frontera de cost-rendiment en DSQA i WideSearch. Mesurem el cost i el rendiment de SaC a través de nivells de raonament del model baixos, mitjans i alts, juntament amb els altres sistemes. Les Figures 7 i 8 representen gràficament la puntuació de referència enfront del preu per tasca, amb l'eix x invertit de manera que els punts situats més a la dreta són més barats i els punts més alts representen un millor rendiment.

Amplia

A DSQA, les tres configuracions de SaC es troben a la frontera superior dreta. La configuració de raonament baix és més barata que tots els altres sistemes alhora que funciona millor que dos d'ells. La configuració de raonament mitjà supera tots els sistemes no SaC per menys de 1 dòlar per tasca. La configuració de raonament alt aconsegueix el màxim rendiment amb un cost competitiu.

Amplia

WideSearch mostra una frontera de forma similar. Com amb DSQA, la configuració de raonament baix aconsegueix un rendiment competitiu a un cost inferior que tots els sistemes no SaC, mentre que tant el raonament mitjà com l'alt superen els sistemes no SaC en el rendiment de les tasques.

Cap a una nova arquitectura de computació

Search as Code reflecteix un canvi més ampli en el disseny de programari. Durant dècades, els sistemes de programari es van organitzar al voltant d'instruccions deterministes executades per entorns d'execució tradicionals en CPU. Els models de frontera introdueixen una nova forma de càlcul: el raonament en l'espai de testimonis que pot tant seguir com generar instruccions. Els sistemes computacionals més capaços combinaran aquestes dues formes de càlcul en lloc de triar entre elles.

La cerca és un terreny de prova natural per a aquesta arquitectura híbrida. Els models s'adapten bé a decidir quina evidència es necessita i com s'ha de resoldre la incertesa. Els entorns d'execució deterministes s'adapten bé a l'agrupació en lots, el paral·lelisme, el filtratge, el rànquing i l'agregació. La infraestructura de cerca serveix com a capa d'E/S universal, proporcionant a l'entorn d'execució gestos útils a la informació del món que poden mantenir milers d'operacions per minut. Quan aquestes peces s'integren, el sistema resultant és molt més potent i eficient en la realització de tasques del món real.

Cada part d'aquesta arquitectura és necessària per desbloquejar aquestes capacitats. Sense models intel·ligents, el sistema no pot raonar sobre l'estratègia de cerca. Sense entorns de proves, els models es veuen obligats a l'E/S sèrie i al processament ineficient en l'espai de testimonis. I sense una pila de cerca atomitzada, el model no té res a orquestrar. SaC funciona perquè el raonament, el càlcul determinista i l'E/S estan dissenyats conjuntament per accentuar els punts forts de cada capa.

Aquest codisseny es pot portar encara més enllà mitjançant el desenvolupament de bucles de millora contínua. Per exemple, l'SDK de cerca d'agents i les Skills d'agent de SaC es podrien optimitzar conjuntament en un bucle d'autorecerca comú. De manera més ambiciosa, els models es poden entrenar per aprofitar les primitives de cerca de baix nivell exposades com a SDK. Fins i tot es podria intentar coevolucionar el disseny de l'SDK durant el procés d'entrenament del model mateix. Esperem poder seguir estratègies de codisseny més agressives en futurs treballs.

Vam construir SaC per permetre als models controlar el procés de cerca, en lloc de merament consumir els seus resultats. Els nostres resultats proven el poder d'aquest control: SaC fa avançar tant el rendiment absolut com la frontera de cost-rendiment en referències d'agents intensives en coneixement. Estem encantats de portar les capacitats de SaC als nostres usuaris, començant avui amb Perplexity Computer i Agent API. Continuarem optimitzant l'arquitectura SaC a totes les capes de la pila per assegurar-nos que els nostres usuaris (i els agents que els serveixen) tinguin les capacitats de cerca més potents i eficients possibles.

Citació

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