Rethinking Search as Code Generation

Zoeken is een kernbeginsel voor AI-systemen. Frontier-modellen worden maandelijks capabeler, maar ze hebben nog steeds toegang nodig tot verse, nauwkeurige en goed beheerde kennis uit de bredere wereld. Zoeken is de primaire manier waarop AI-systemen die kennis aanboren, en daarmee een fundamenteel onderdeel van elk product dat conclusies moet trekken, acties moet ondernemen en werk in de echte wereld moet uitvoeren.

Wij geloven dat traditionele zoekpijplijnen in het tijdperk van agents steeds verouderder worden. Traditionele zoekopdrachten beantwoorden vragen, maar de agents van vandaag voltooien taken die talloze vormen kunnen aannemen. Deze taken vereisen dat agents taakspecifieke ophaalstrategieën direct binnen hun harnesses definiëren. Binnen Perplexity Computer hebben we gezien hoe individuele taken honderden of zelfs duizenden ophaalbewerkingen binnen enkele minuten aanroepen: een workflow die onmogelijk is voor mensen, maar absoluut natuurlijk voor agents.

In deze wereld moet het zoeken zelf agent-gericht worden, met bouwstenen die direct toegankelijk zijn als SDK's binnen de agent-harness. We introduceren Search as Code (SaC) als Perplexity's nieuwe referentie-zoekarchitectuur.

Perplexity's zoekstack verwerkt duizenden zoekopdrachten per seconde via onze applicaties en API Platform. In september 2025 publiceerden we het eerste architecturaal overzicht van onze zoeksystemen. Constante innovatie binnen deze systemen heeft de lancering van nieuwe aanbiedingen ondersteund, zoals Search API, Agent API en Computer, waarbij zelfverbeteringslussen de zoekstack optimaliseren om gebruikers met elke dag die voorbijgaat beter te bedienen.

Traditioneel hebben AI-systemen zoeken als een monoliet behandeld: een AI-model voert een query uit, de zoekmachine voert zijn vooraf gedefinieerde pijplijn uit en het model consumeert de resultaten als context. Voor het grootste deel werkte dit prima om aan de behoeften van vroege AI-gebruikers te voldoen. Gezien de relatieve eenvoud van hun verzoeken was er geen reden om ons zorgen te maken over hoe de zoekpijplijn precies was ontworpen, of of de architectuur van de pijplijn optimaal was voor de taak die voorhanden was. De standaardinstellingen werden geacht goed genoeg te zijn, evenals de standaardinterfaces (functie-aanroepen en MCP's).

Traditionele zoekarchitecturen stellen één enkel vast systeem bloot dat modellen serieel aanroepen, terwijl Search as Code geatomiseerde zoekprimitieven blootstelt die agents samenstellen via gegenereerde code.

Toch wordt deze aanpak vandaag de dag met elke voorbijgaande maand verouderder. Gebruikers eisen veel meer dan eenmalige analyse van AI. Ze verwachten dat agents taken end-to-end voltooien over uren of zelfs dagen. Deze taken kunnen complex, open-eind en zeer variabel zijn in hun informatiebehoeften, en monolithische architecturen bezwijken onder het gewicht van deze eisen.

De belangrijkste knelpunt is uiteindelijk een kwestie van controle. Frontier-modellen zijn al behoorlijk goed in het redeneren over vaste context. De krachtigste AI-systemen zullen echter het vermogen vereisen om te sturen hoe die context wordt opgehaald, verwerkt, geaggregeerd en gerenderd naar het model.

Traditionele zoeksystemen waren niet ontworpen met deze mate van controleerbaarheid in gedachten. Menselijke gebruikers kunnen immers niet worden geacht fijne controle uit te oefenen over de interne werking van zoekpijplijnen, zelfs als dat zou worden aangeboden. Vroege AI-modellen kunnen zoeken alleen controleren via een lineair traject van functie-aanroepen en MCP's. Maar de huidige frontier-modellen, aangestuurd door code-capabele agent-harnesses, kunnen fijnmazige controle uitoefenen over alle rekenprimitieven die denkbaar zijn via computercode. Onze taak wordt het bieden van de juiste primitieven.

Om aan deze behoefte te voldoen, introduceren we een nieuwe zoekarchitectuur in onze producten: Search as Code (SaC). Deze nieuwe architectuur stelt modellen in staat om in de zoekstack zelf te reiken in plaats van alleen de uiteindelijke outputs te consumeren. Het kernidee is eenvoudig: we stellen de componenten van de zoekstack bloot als primitieven binnen een SDK. Voor elk verzoek dat zoeken vereist, assembleert een model deze primitieven on-demand tot een ophaalpijplijn die is afgestemd op dat specifieke verzoek.

Het samenstellen van deze pijplijn gebeurt door middel van codegeneratie en -uitvoering binnen een veilige sandbox. In tegenstelling tot andere door codegen aangestuurde benaderingen van zoeken, plaatsen we niet zomaar een traditionele zoek-API binnen een shell of runtime voor talen. In plaats daarvan hebben we zorgvuldig een Agentic Search SDK ontwikkeld die de individuele bouwstenen van het zoeken op het meest atomische niveau mogelijk blootstelt.

Search as Code (SaC) bevordert de prestatiegrens van agent-gericht zoeken via een diverse reeks benchmarks.

Gewapend met deze bouwstenen geeft SaC modellen directe controle over elke individuele zoekstap: ophalen, rangschikken, filteren, fanouts, renderen en meer. Het geeft het model ook efficiënte toegang tot tussenliggende toestanden, zoals kandidatenlijsten en rangschikkingssignalen. Samen maken deze twee hefbomen van controle en leesbaarheid het mogelijk voor agents om op maat gemaakte zoekpijplijnen te ontwerpen die duizenden ophaalbewerkingen omspannen, die pijplijnen tijdens de vlucht te optimaliseren en alleen de meest bruikbare informatie als modelcontext te consumeren.

Dit artikel beschrijft de motivatie, het ontwerp en de implementatie van SaC, naast empirische resultaten op zowel bestaande als nieuwe benchmarks. SaC vestigt een nieuwe kosten-prestatiegrens voor agent-gericht zoeken, en we zijn verheugd dit te delen met onze gebruikers en de bredere AI-gemeenschap.

De eerste zoekmachines ter wereld werden gebouwd voor menselijke gebruikers. Deze gebruikers verwachtten een voorspelbare ervaring, meestal bestaande uit een vast aantal op relevantie gerangschikte documenten. Gebruikers wilden het zoekproces niet micromanagen; ze wilden een zoekopdracht invoeren en een bruikbaar resultaat vinden.

Als resultaat convergeerden mensgerichte zoekmachines op een gemeenschappelijke monolithische architectuur, gericht op het produceren van mensvriendelijke resultatenpagina's van zoekmachines (SERP's) met de top n resultaten voor een invoerquery. Dit patroon heeft decennia van vooruitgang in consumentenzoekopdrachten aangedreven. Het is snel, vertrouwd en zeer effectief voor menselijk browsen.

Toen kwamen LLM's, en AI-systemen werden ook consumenten van zoekopdrachten. Perplexity was pionier in deze verschuiving met de lancering van onze antwoordmachine in 2022. Sindsdien hebben onze zoektechnische inspanningen zich gericht op hoe de waarde van zoekresultaten voor AI-modellen kan worden geoptimaliseerd. Om 's werelds meest nauwkeurige en betrouwbare AI te bouwen, moesten we een zoeksysteem engineeren dat erop gericht was elk token zo informatierijk mogelijk te maken. De resulterende innovaties in sub-document ophalen, context-efficiëntie, semantisch begrip en andere belangrijke gebieden leidden tot dramatische verbeteringen in het vermogen van AI-systemen om informatie op te halen en ernaar te handelen.

Echter, zelfs door AI geoptimaliseerde systemen hebben grotendeels hetzelfde fundamentele contract geërfd als traditionele zoekmachines: accepteer een query, voer een vooraf gedefinieerde zoekpijplijn uit, retourneer een volledig verwerkte resultatenset. Voor eenvoudige verzoeken werkt deze aanpak prima. Maar voor complexere verzoeken wordt dit een steeds beperkender knelpunt dat prestaties, latentie en kosten verslechtert.

Traditionele zoeksystemen dwingen agent-gerichte workflows om zoeken te sequencen via voor het model zichtbare beurten. Modellen moeten herhaaldelijk dezelfde zoekpijplijnen aanroepen via verschillende query-parameters en alle resultaten in de modelcontext introduceren.

Traditionele zoekpijplijnen zijn ontworpen rond één enkel controlepunt: de query-parameters. De zoekmachine bezit de rest van de pijplijn volgens zijn vooraf gedefinieerde logica, en het model moet zich daaraan aanpassen. Voor het model is alles stroomafwaarts van de query-parameters rigide—de vorm van de feitelijke berekening ligt buiten de controle van het model.

Dit is een verstandige grens wanneer de consument een mens is die links scant. Het is een slechte grens wanneer de consument een AI-model is dat probeert kennisintensieve taken op te lossen in een gesloten lus. In onze ervaring creëert deze rigiditeit drie terugkerende foutmodi:

Grove context. AI-modellen zijn gevoelig voor de kwaliteit en compactheid van context. Zowel kwaliteit als compactheid zijn sterk query-afhankelijk, en monolithische zoekpijplijnen zijn niet ontworpen om optimaal te presteren bij alle query's. Bijvoorbeeld, als een model een enkel, zeer chirurgisch stukje informatie nodig heeft, maar alleen toegang heeft tot een end-to-end zoekeindpunt dat prioriteit geeft aan recall, zal het gebruik van dat eindpunt een grote hoeveelheid irrelevante informatie in de modelcontext introduceren. Aan de andere kant, als een model veel stukjes informatie nodig heeft die elk verschillende zoekstrategieën vereisen, kan het gedwongen worden om serieel dezelfde suboptimale pijplijn voor allemaal aan te roepen, wat resulteert in stijgende kosten en lawaaierige context.

Niet in staat om domeinkennis te benutten. In veel gevallen kan het model domeinkennis hebben (van zijn training, een Agent Skill, geheugen of eerdere tokens in het LLM-traject) die de zoekstrategie moet sturen. Een rigide zoekinterface verhindert het model echter om die kennis te benutten. Het model kan bijvoorbeeld voor een specifiek verzoek beseffen dat het lexicale en semantische signalen op een bepaalde manier moet mengen, prioriteit moet geven aan bepaalde bronnen of resultaten moet aggregeren op een specifieke sleutel. Tenzij die inzichten via query-parameters kunnen worden geïmplementeerd, kan het model er niet daadwerkelijk op handelen.

Inefficiënte controlestroom en contextvervuiling. Veel zoekworkflows zijn niet van nature serieel. Ze kunnen fan-out over query-varianten, parallel ophalen, ontdubbeling en andere bewerkingen vereisen die een niet-lineaire en asynchrone controlestroom vereisen. Het afdwingen van deze stappen via herhaalde modelbeurten voegt latentie toe en maakt de workflow moeilijker te optimaliseren. Het vervuilt ook de modelcontext met lawaaierige tussenliggende toestand die mogelijk niet nuttig is voor het redeneren van het model, wat resulteert in slechtere prestaties en vaker voorkomende compacties.

Er kon niet veel worden gedaan aan deze uitdagingen tijdens de functie-aanroep- en MCP-tijdperken van AI. Wanneer elke zoekactie zijn eigen retourtje naar LLM-inferentie vereist, geven ontwikkelaars er de voorkeur aan om in dat retourtje zoveel mogelijk gedaan te krijgen. Dit betekent end-to-end zoekpijplijnen die volledig verwerkte resultatensets retourneren voor directe consumptie door een model.

Als resultaat opereren de meeste op AI gerichte zoeksystemen vandaag de dag nog steeds onder dit monolithische contract. Echter, met de voortdurende groei in modelintelligentie en gebruikersvereisten, worden de tekortkomingen van dat contract duidelijker. De meest geavanceerde AI-systemen van vandaag, gebouwd op code-first harnesses, kunnen taakspecifieke workflows samenstellen die elke minuut duizenden acties uitvoeren. Zoeksystemen moeten dit potentieel nog volledig realiseren.

We vermoedden al lang dat de juiste grens voor AI-native zoeken lager in de stack ligt. Modellen moeten niet alleen een zoekmachine aanroepen. Ze moeten in staat zijn om de individuele stukjes van de zoekstack te orkestreren naarmate de specifieke taak dat vereist. Dat vereist een fundamenteel andere architectuur.

De volgende generatie zoekarchitecturen zal afhangen van een kernprincipe: zoeken moet native programmeerbaar zijn door AI-agents. Een agent mag niet beperkt zijn tot een set vooraf bepaalde zoekpijplijnen. Een agent moet juist in staat zijn om de pijplijn te construeren die de specifieke taak vereist, met behulp van samenstelbare bouwstenen die op verschillende abstractieniveaus zijn ontworpen.

Onze nieuwe Search as Code (SaC)-architectuur belichaamt dit principe. In SaC wordt geen enkele ophaalbewerking verzonden via een functie-aanroep- of MCP-interface. Alle bewerkingen worden in plaats daarvan georkestreerd via door het model gegenereerde Python-code. Voor de eenvoudigste zoekbehoeften kan deze code bestaan uit een handvol verzoeken naar een hoogwaardig zoekeindpunt. Maar voor complexe taken kan de code zo ingewikkeld zijn als nodig, met voorwaardelijke uitvoering, asynchroniteit, parallellisme en aanroepen naar een breed scala aan low-level primitieven.

De Search as Code (SaC)-architectuur vertrouwt op een stack bestaande uit modellen, compute-sandboxes en een Agentic Search SDK bovenop Perplexity's zoekinfrastructuur.

SaC omvat drie nauw gekoppelde lagen:

Modellen dienen als het controle vlak. Ze redeneren over de richtlijn van de gebruiker (of bovenliggende agent), ontleden de richtlijn in taken, beslissen welke ophaal- en verwerkingspijplijnen nodig zijn voor elke taak en genereren code om die pijplijnen te implementeren.

Compute-sandboxes bieden deterministische compute via een veilige runtime voor code-uitvoering. Ze bieden een canvas voor modellen om controlestroom, batching, nieuwe pogingen, filteren, samenvoegen, aggregatie en andere deterministische bewerkingen te implementeren.

Onze Agentic Search SDK stelt Perplexity's zoekstack bloot als samenstelbare primitieven. Het biedt bouwstenen van low-level ophaalbewerkingen tot hoogwaardige semantische parsing. De SDK is ingebed in de uitvoeringsruntimes van de sandboxes, waardoor modellen tot duizenden bewerkingen binnen een enkele inferentiebeurt kunnen orkestreren. Hieronder bespreken we onze ontwerpbeslissingen voor elke laag.

De Agentic Search SDK definieert de bouwstenen voor programmeerbaar zoeken. Belangrijk is dat onze SDK geen reeds bestaande zoek-API is die als bibliotheek is verpakt. In de afgelopen maanden heeft ons engineering-team onze zoekstack geherarchitecteerd tot modulaire, samenstelbare primitieven. We hebben de Agentic Search SDK gebouwd om directe toegang tot deze primitieven te bieden, wat zorgt voor een veel krachtiger canvas waarop het model taakspecifieke ophaalpijplijnen kan orkestreren.

Hoogwaardige, end-to-end zoekpijplijnen zijn nog steeds beschikbaar binnen de SDK, maar ze zijn niet langer de enige optie. Ze dienen eerder als een vorm van steno voor veelvoorkomende zoekpatronen. Het model is vrij om ze te gebruiken of te omzeilen naarmate de taak dit vereist.

Keuze van runtime: We overwogen Python, Rust, TypeScript en Bash als de SDK-runtime. We vermoedden dat Python de meest natuurlijke pasvorm zou zijn gezien de alomtegenwoordigheid en het ecosysteem van bibliotheken voor gegevensverwerking. Interne tests bevestigden dat dit het geval was, en de versie van de SDK die vandaag wordt uitgerold, is Python-gebaseerd. We verwachten de keuze van runtime periodiek opnieuw te evalueren om ervoor te zorgen dat het de beste agent-ervaring blijft bieden.

Voortdurende verbetering via autoresearch: We hebben ook de consumabiliteit van de SDK voor frontier LLM's geoptimaliseerd via een iteratieve autoresearch-lus. Deze lus, die wekenlang continu draait, stelt SDK-verbeteringen voor en valideert deze tegen statistieken zoals latentie, codegen-kwaliteit en algehele taakprestaties. De autoresearch-lus heeft al talloze wijzigingen aangebracht in zowel de structuur als de esthetiek van de SDK, met aanzienlijke winsten in alle dimensies. We zijn van plan de SDK verder te verfijnen via autoresearch naarmate nieuwe frontier-modellen en zoekcomponenten verschijnen.

Sandboxes bieden veilige omgevingen voor het definiëren en uitvoeren van SaC-pijplijnen. Ze voeren door het model gegenereerde code uit en bieden toegang tot de Agentic Search SDK om interactie met individuele zoekprimitieven te vergemakkelijken.

We hebben aanzienlijke investeringen gedaan in het optimaliseren en verharden van onze sandboxes, en hun algehele systeemontwerp verdient een eigen artikel. Hier richten we ons op de ontwerpoverweging die het meest relevant is voor SaC: het beheren van tussenliggende toestanden.

SaC stelt agents in staat om complexe pijplijnen te orkestreren binnen een enkele inferentiebeurt. Bepaalde tussenliggende toestanden moeten echter over beurten heen worden overgebracht. Een model wil bijvoorbeeld in beurt 1 enkele documenten ophalen, in beurt 2 een substeekproef van die documenten inspecteren om te beslissen wat de volgende stap is, en vervolgens een stroomafwaartse zoekpijplijn ontwikkelen om die documenten vanaf beurt 3 verder te onderzoeken. Zoals hierboven besproken, is het doorgeven van tussenliggende toestanden via token-ruimte geen effectieve strategie.

We overwogen twee benaderingen voor het beheren van tussenliggende toestanden over beurten heen:

Persistent bestandssysteem + expliciete serde: Sandboxes kunnen persistente bestandssystemen blootstellen voor modellen om over beurten heen te gebruiken. Modellen die tussenliggende toestanden willen behouden, kunnen een serialisatiestap opnemen binnen de gegenereerde code voor een beurt, samen met een deserialisatiestap binnen een volgende beurt (ofwel voor eigen inspectie van de modellen of voor stroomafwaarts gebruik). De bestandssysteembenadering stelt modellen in staat om direct en expliciet te controleren hoe tussenliggende toestand over beurten heen wordt overgebracht. Het zorgt ook voor traceerbaarheid door expliciete identificatie en persistentie van informatie die door het model wordt gebruikt, af te dwingen. Een nadeel is de latentie & context-overhead die wordt veroorzaakt door het genereren van de serde-code, hoewel goed ontworpen hulpprogramma's deze overhead kunnen verzachten.

REPL: Als alternatief kan een sandbox de uitvoeringsruntime zelf behouden over beurten heen in een REPL-achtige omgeving. Hierdoor kunnen modellen tussenliggende toestanden in-memory behouden zonder deze helemaal te hoeven serialiseren, aangezien variabelen die in eerdere beurten zijn gedefinieerd of gewijzigd, eenvoudig bij naam kunnen worden verwezen in volgende beurten. De REPL-benadering is token-efficiënter omdat deze de noodzaak vermijdt om serde-code te genereren. Het gebrek aan een expliciete serialisatiestap kan echter de stroomafwaartse prestaties schaden om redenen die bekend zijn bij iedereen die met een Jupyter-notebook met 100 cellen heeft gewerkt: naarmate de variabelenaamruimte rommeliger wordt, wordt het moeilijker om bij te houden wat precies over beurten heen wordt behouden en waarom.

We hebben beide benaderingen getest en ontdekten dat, hoewel ze vergelijkbaar presteren bij normaal gebruik, bestandssysteemgebaseerde serde betere betrouwbaarheid biedt op bijzonder lange trajecten. We adopteren daarom bestandssysteemgebaseerde serde als onze oplossing. We vermoeden dat het vereisen van modellen om toestanden declaratief in plaats van impliciet over te brengen, hen helpt die toestand effectiever te beheren. Dit is een voorlopige bevinding en we zullen op beide benaderingen blijven itereren.

De modellen die de agent-harnesses aandrijven, dienen als SaC's controle vlak: ze assembleren dynamisch zoekpijplijnen vanuit de bouwstenen van de Agentic Search SDK om aan de behoeften van elke taak te voldoen, en verzenden die pijplijnen vervolgens als code voor sandbox-uitvoering.

Perplexity gebruikt een verscheidenheid aan modellen binnen onze agent-harnesses, en we hebben ontdekt dat de nieuwste frontier-modellen behoorlijk effectief zijn over de hele linie bij algemene codegeneratie. De grootste uitdaging is om effectieve codegeneratie specifiek voor de Agentic Search SDK te induceren. Dat wil zeggen, hoe kunnen we modellen effectief de bouwstenen van onze SDK laten verweven in taakgeoptimaliseerde pijplijnen?

In tegenstelling tot de standaardbibliotheek van een taal, is het onwaarschijnlijk dat een op maat gebouwde SDK wordt vertegenwoordigd in pretraining-data. Zelfs met de verbeteringen in SDK-consumabiliteit door autoresearch, zijn veel modellen nog steeds getraind om te communiceren met zoeksystemen via functie-aanroepen en directe MCP-aanroeping. Het is onwaarschijnlijk dat deze modellen de SDK vakkundig zullen hanteren met alleen broncode en automatisch gegenereerde documenten.

Om deze uitdaging op te lossen, hebben we hoogwaardig afgestemde Agent Skills ontwikkeld om modellen te leren onze SDK effectief te benutten. De initiële versies werden ontwikkeld volgens Perplexity's ontwerpprincipes voor Skills, en vervolgens geoptimaliseerd via een toegewijde autoresearch-lus die gericht was op dezelfde statistieken als die in SDK-optimalisatie. We beperken ook de skill-grootte om context-bloat te voorkomen, en onze uiteindelijke versies hebben minder dan 2000 tokens in hun hoofd SKILL.md-bestanden.

De geoptimaliseerde Skills gaan verder dan het vermelden van de beschikbare bouwstenen van de SDK (iets dat net zo gemakkelijk kan worden verkregen via runtime-reflectie). Het grootste deel van de tokens wordt besteed aan het bieden van beknopte, generaliseerbare richtlijnen en few-shot-voorbeelden voor het samenstellen van deze blokken tot complexe patronen. Gewapend met deze Skills zien we modellen de SDK effectief benutten om zoekpijplijnen te orkestreren die schalen naar duizenden discrete bewerkingen.

Door deze lagen te combineren, verandert SaC de relatie tussen modellen en de zoekstack. In systemen met een vaste pijplijn zit het model boven de zoekopdracht en interageert het via een smalle seriële caller-interface. In SaC wordt het model een actieve deelnemer in het orkestreren van het zoekproces zelf. Alle elementen van de zoekstack worden direct programmeerbaar door het model, waarbij de sandbox en Agentic Search SDK de nodige interfaces bieden aan die elementen.

Maar hoe zit het met mogelijkheden die niet native bestaan? Code is een krachtig medium voor het orkestreren van reeds bestaande mogelijkheden. Toch gaat de kracht van code verder dan orkestratie. Het kan ook dienen als een gatenvuller voor mogelijkheden die niet aanwezig zijn in de zoekstack of SDK. Agents profiteren van zuinigheid, en het zou inefficiënt zijn als de SDK elke potentiële bewerking met een toegewijde functie zou dekken. In plaats daarvan biedt de SDK de meest fundamentele primitieven, en kan het model on-the-fly aanvullende componenten bouwen met code.

Beschouw bijvoorbeeld een complexe regex die niet efficiënt kan worden geïmplementeerd via de query-syntaxis van het zoeksysteem zelf. Zonder codeermogelijkheden zou het model gedwongen worden zijn beste benadering te genereren, een query uit te voeren en token-ruimte-filtering uit te voeren op een zeer lawaaierige resultatenset. Met SaC kan het model in plaats daarvan een programma genereren dat parallelle SDK-aanroepen doet om een superset van de resultatenset van de gewenste regex te verzamelen. Na ontdubbeling via de SDK kan het model vervolgens extra code schrijven om de resultaten deterministisch te vernauwen tot de exacte regex. Op deze manier kunnen agents aangepaste zoekmogelijkheden implementeren zonder de SDK op te zwellen met overmatig niche-subroutines.

We presenteren een casestudy gebaseerd op een echte taak binnen onze testsuite. Deze taak vraagt een agent om meer dan 200 CVE's met een hoge ernst uit 2023–2025 te identificeren en te karakteriseren. Elk record moet het eigen advies van de getroffen leverancier citeren, het product en de fix-versie benoemen en aantonen dat de fix-versie is gekoppeld aan de specifieke CVE.

Het antwoord van SaC scoorde 100% op nauwkeurigheid, met een totaal tokenverbruik dat met 85,1% daalde ten opzichte van de niet-SaC-baseline (van 288,7K tokens naar 42,9K tokens). De geteste niet-Perplexity-systemen, die in meer detail worden besproken in Sectie 4, scoorden allemaal lager dan 25%.

We presenteren drie gestileerde codeblokken uit het traject om te illustreren hoe de programmeerbaarheid van SaC het model in staat stelt effectieve strategieën te implementeren.

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

Dit eerste blok is pure orkestratie. Het gegenereerde programma begint met het direct coderen van de source-class-regel in het queryplan: alleen adviesformaten van leveranciers zelf zijn relevant. Bronnen die niet van leveranciers zijn, waaronder NVD, MITRE, CVE Details, nieuwsverhalen, CERT-pagina's en databases van derden, vallen structureel buiten het bereik. De exact-phrase-beperkingen dwingen het zoeken ook naar pagina's waarvan de geïndexeerde tekst al de precieze CVE-details bevat die stroomafwaarts nodig zijn.

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

Het tweede blok gebruikt een LLM als een tussenliggende planningssubroutine. De code vat samen welke leverancier-jaar-paren genoeg kandidaat-pagina's produceren, vraagt om gerichte verfijningen en valideert elke voorgestelde query vóór uitvoering. Dit behoudt nuttige patronen uit het traject, zoals site-scoped exact-phrase-probes en adaptieve backfilling, zonder een speciaal CVE-advies-crawler in de SDK te hardcoden.

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

Het laatste blok is een resultaatverificator waarvan de logica volledig door de agent via codegen wordt gedefinieerd. Hoewel zoeksubroutines plausibele adviespagina's kunnen vinden, vereist de taak een strengere relatie: het advies moet één CVE binden aan één getroffen product en één fix-versie in tekst die door de leverancier is geschreven. Het schema maakt die relatie expliciet, zodat stroomafwaartse code kan ontdubbelen op CVE, aggregator-URL's kan afwijzen, zwak versiebewijs kan negeren en kan blijven backfillen totdat de record-count-ondergrens is bereikt.

We evalueren de effectiviteit van SaC op een uitgebreide benchmarksuite, waarbij we ons concentreren op zowel absolute prestaties als de kosten-prestatiegrens.

Onze benchmarksuite omvat in totaal vijf benchmarks, ontworpen om zoekafhankelijke AI-workflows te stress-testen over een reeks domeinen, taakformaten en complexiteitsniveaus. We gebruiken vier reeds bestaande benchmarks: DeepSearchQA (DSQA), BrowseComp, Humanity's Last Exam (HLE) en WideSearch. Voor de eerste drie benchmarks (DSQA, BrowseComp en HLE) rapporteren we nauwkeurigheid als de topline-statistiek. Voor WideSearch rapporteren we de F1-score per rij.

We gebruiken ook de nieuw ontwikkelde WANDR-benchmark, die zich richt op moeilijke "wide research"-taken die een zorgvuldige orkestratie van zoeken, compute en model-redeneren vereisen. WANDR is geïnspireerd door de kennisintensieve professionele taken die Perplexity Computer voor gebruikers afhandelt. Het itereert op WideSearch en soortgelijke benchmarks, maar legt de nadruk op complexere taken en taakstructuren. We zullen de WANDR-benchmark de komende weken publiceren.

We evalueren vijf op agents gebaseerde systemen. We beschouwen individuele runs in plaats van "best-of-N"-scores om de prestaties van de onderliggende architectuur te isoleren in plaats van de voordelen van parallellisatie. De configuratie van elk systeem wordt hieronder beschreven:

Perplexity (SaC): We evalueren de SaC-architectuur binnen Perplexity's productie Agent API. GPT 5.5 (hoge redenering) dient als het onderliggende model.

OpenAI: We evalueren de OpenAI Responses API met zowel zoeken (web_search) als Python-runtime (code_interpreter) ingeschakeld. GPT 5.5 (hoge redenering) dient als het onderliggende model.

Anthropic: We evalueren Anthropic Managed Agents met de 20260401 agent-toolset en auto-toegestane opdrachten. Opus 4.7 (hoge redenering) dient als het onderliggende model.

Exa: We evalueren Exa Agent via de productie-API, met de inspanning ingesteld op hoog.

Parallel: We evalueren Parallel Tasks via de productie-API, met de processor ingesteld op ultra4x.

Tabel 1 rapporteert benchmarkscores voor elk systeem. SaC presteert beter dan alle andere systemen op vier van de vijf benchmarks. Op de resterende benchmark (HLE) staat SaC in wezen op een gedeelde eerste plaats met OpenAI Responses. Figuur 2 uit de Introductie visualiseert deze scores in grafische vorm.

Benchmark	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 | Benchmarkscores voor elk geëvalueerd systeem. Beste score per rij in vetgedrukt.

Hoewel SaC state-of-the-art prestaties behaalt over de hele benchmarksuite, is het voordeel bijzonder uitgesproken op WANDR. Figuur 5 splitst de WANDR-scores uit en laat zien dat de SaC-implementatie van Perplexity het op één na beste systeem met een factor 2,5× overtreft. Ondanks deze grote marge blijft WANDR onverzadigd en bewijst het zelfs voor SaC uitdagend te zijn. We geloven dat de complexe, zeer horizontale zoekworkflows die voor de taken van WANDR vereist zijn, aanvullende vooruitgang in onderzoek en zoektechniek zullen vereisen om consistent hoge prestaties te behalen.

WANDR-scores over geëvalueerde systemen. Perplexity Agent API leidt het op één na beste systeem met een factor 2,5×.

Ten slotte meten we de relatieve winsten van SaC versus een traditionelere zoekpijplijn die gebruikmaakt van dezelfde Perplexity-zoekinfrastructuur. Figuur 6 rapporteert het verschil in scores tussen de SaC- en niet-SaC-architecturen over elke benchmark. Over de hele linie biedt SaC een substantiële prestatieboost, met de grootste absolute winst op DSQA (+19,77 pp, 29%) en de grootste relatieve winst op WANDR (+12,00 pp, 45%).

Perplexity baseline versus SaC-score op elke benchmark, met absolute en relatieve delta's geannoteerd.

In de praktijk geven gebruikers om prestaties in relatie tot kosten. We evalueren daarom de kosten-prestatiegrens op DSQA en WideSearch. We meten de kosten en prestaties van SaC over lage, gemiddelde en hoge model-redeneerniveaus, naast de andere systemen. Figuren 7 en 8 plotten de benchmarkscore tegen de prijs per taak, met de x-as omgekeerd zodat punten verder naar rechts goedkoper zijn en punten hoger betere prestaties vertegenwoordigen.

DSQA-score versus prijs per taak. De stippellijn verbindt de SaC-model-redeneerconfiguraties.

Op DSQA liggen alle drie de SaC-instellingen op de rechtsboven-grens. De lage redeneerinstelling is goedkoper dan alle andere systemen terwijl deze beter presteert dan twee ervan. De gemiddelde redeneerinstelling presteert beter dan alle niet-SaC-systemen voor minder dan $1 per taak. De hoge redeneerinstelling behaalt topprestaties met concurrerende kosten.

WideSearch-score versus prijs per taak. De stippellijn verbindt de SaC-model-redeneerconfiguraties.

WideSearch toont een vergelijkbaar gevormde grens. Net als bij DSQA behaalt de lage redeneerinstelling concurrerende prestaties tegen lagere kosten dan alle niet-SaC-systemen, terwijl zowel gemiddelde als hoge redenering beter presteren dan niet-SaC-systemen in taakprestaties.

Search as Code weerspiegelt een bredere verandering in softwareontwerp. Decennialang werden softwaresystemen georganiseerd rond deterministische instructies die door traditionele runtimes op CPU's werden uitgevoerd. Frontier-modellen introduceren een nieuwe vorm van compute: token-ruimte-redenering die zowel instructies kan volgen als genereren. De meest capabele computersystemen zullen deze twee vormen van compute combineren in plaats van te kiezen tussen beide.

Zoeken is een natuurlijk testterrein voor deze hybride architectuur. Modellen zijn zeer geschikt om te beslissen welk bewijs nodig is en hoe onzekerheid moet worden opgelost. Deterministische runtimes zijn zeer geschikt voor batching, parallellisme, filteren, rangschikken en aggregatie. Zoekinfrastructuur dient als een universele I/O-laag, die de runtime nuttige handvatten biedt in de wereldinformatie die duizenden bewerkingen per minuut kan ondersteunen. Wanneer deze stukjes worden geïntegreerd, is het resulterende systeem veel krachtiger en efficiënter in het volbrengen van taken in de echte wereld.

Elk deel van deze architectuur is noodzakelijk om deze mogelijkheden te ontsluiten. Zonder intelligente modellen kan het systeem niet redeneren over zoekstrategie. Zonder sandboxes worden modellen gedwongen tot seriële I/O en inefficiënte token-ruimte-verwerking. En zonder een geatomiseerde zoekstack heeft het model niets om te orkestreren. SaC werkt omdat redeneren, deterministische compute en I/O gezamenlijk zijn ontworpen om de sterke punten van elke laag te accentueren.

Dit co-ontwerp kan nog verder worden doorgevoerd door de ontwikkeling van loops voor voortdurende verbetering. De Agentic Search SDK en SaC Agent Skills zouden bijvoorbeeld gezamenlijk kunnen worden geoptimaliseerd in een gemeenschappelijke autoresearch-lus. Ambitieuzer is dat modellen kunnen worden getraind om gebruik te maken van low-level zoekprimitieven die als een SDK worden blootgesteld. Men zou zelfs kunnen proberen het SDK-ontwerp mee te evolueren tijdens het modeltrainingsproces zelf. We kijken ernaar uit om in toekomstig werk agressievere co-ontwerpstrategieën na te streven.

We hebben SaC gebouwd om modellen het zoekproces te laten controleren, in plaats van alleen de resultaten te consumeren. Onze resultaten bewijzen de kracht van deze controle: SaC bevordert zowel de absolute prestaties als de kosten-prestatiegrens op kennisintensieve agent-benchmarks. We zijn verheugd de mogelijkheden van SaC naar onze gebruikers te brengen, vanaf vandaag met Perplexity Computer en Agent API. We zullen de SaC-architectuur over alle lagen van de stack blijven optimaliseren om ervoor te zorgen dat onze gebruikers (en de agents die hen bedienen) de krachtigste en efficiëntste zoekmogelijkheden hebben die mogelijk zijn.

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

Introductie

De rigiditeit van traditioneel zoeken

Foutmodi door rigiditeit

Het ontwerpen van een programmeerbare zoekarchitectuur

De Agentic Search SDK

Sandboxes

Modellen

Code als orkestrator en gatenvuller

Casestudy: CVE-leveranciersadviezen

Evaluatieresultaten

Benchmarks en systemen

Vergelijkende prestaties

Kosten-prestatiegrens

Naar een nieuwe architectuur van computing

Citaat