Nové pojetí vyhledávání jako generování kódu

Vyhledávání je základní primitivum pro systémy umělé inteligence. Špičkové modely jsou každým měsícem schopnější, ale stále potřebují přístup k čerstvým, přesným a dobře uspořádaným znalostem z širšího světa. Vyhledávání je primární způsob, jakým systémy AI tyto znalosti využívají, a představuje tak základní součást každého produktu, který potřebuje vyvozovat závěry, provádět akce a vykonávat práci v reálném světě.

Věřte, že tradiční vyhledávací potrubí jsou v éře agentů stále zastaralejší. Tradiční vyhledávání odpovídá na dotazy, ale dnešní agenti plní úkoly, které mohou mít nespočet podob. Tyto úkoly vyžadují, aby agenti definovali strategie načítání specifické pro daný úkol přímo ve svých postrojích. V rámci systému Perplexity Computer jsme byli svědky toho, jak jednorázové úkoly vyvolaly během několika minut stovky nebo dokonce tisíce operací načítání: pracovní postup, který je pro lidi nemožný, ale pro agenty zcela přirozený.

V tomto světě se samotné vyhledávání musí stát agentním a jeho stavební bloky musí být dostupné přímo jako sady SDK v rámci postroje agenta. Představujeme Search as Code (SaC) jako novou referenční vyhledávací architekturu společnosti Perplexity.

Vyhledávací stack společnosti Perplexity obsluhuje tisíce dotazů za sekundu napříč našimi aplikacemi a platformou API. V září 2025 jsme publikovali první architektonický přehled našich vyhledávacích systémů. Neustálé inovace v těchto systémech podpořily uvedení nových nabídek, jako jsou Search API, Agent API a Computer, přičemž smyčky sebezlepšování optimalizují vyhledávací stack tak, aby s každým dnem lépe sloužil uživatelům.

Tradičně systémy AI přistupovaly k vyhledávání jako k monolitu: model AI odešle dotaz, vyhledávač spustí své předdefinované potrubí a model zkonzumuje výsledky jako kontext. Ve většině případů to fungovalo dobře pro potřeby raných uživatelů AI. Vzhledem k relativní jednoduchosti jejich požadavků neexistoval žádný důvod obávat se toho, jak přesně je vyhledávací potrubí navrženo, nebo zda je architektura potrubí optimální pro daný úkol. Výchozí nastavení byla považována za dostatečně dobrá, stejně jako výchozí rozhraní (volání funkcí a MCP).

Tradiční vyhledávací architektury vystavují jediný pevný systém, který modely volají sériově, zatímco Search as Code vystavuje atomizovaná vyhledávací primitiva, která agenti skládají prostřednictvím generovaného kódu.

Dnes však tento přístup s každým uplynulým měsícem zastarává. Uživatelé požadují od AI mnohem víc než jen jednorázovou analýzu. Očekávají, že agenti budou plnit úkoly komplexně v průběhu hodin nebo dokonce dnů. Tyto úkoly mohou být složité, otevřené a vysoce variabilní ve svých informačních potřebách a monolitické architektury se pod tíhou těchto požadavků hroutí.

Klíčovým úzkým hrdlem je nakonec kontrola. Špičkové modely jsou již nyní docela dobré ve uvažování nad pevným kontextem. Nejvýkonnější systémy AI však budou vyžadovat schopnost řídit to, jak je tento kontext načítán, zpracováván, agregován a poskytován modelu.

Tradiční vyhledávací systémy nebyly navrženy s ohledem na tuto míru ovladatelnosti. Konec konců, od lidských uživatelů nelze očekávat, že budou uplatňovat podrobnou kontrolu nad vnitřnostmi vyhledávacího potrubí, i kdyby to bylo nabízeno. Rané modely AI mohou kontrolovat vyhledávání pouze prostřednictvím lineární trajektorie volání funkcí a MCP. Dnešní špičkové modely, poháněné postroji agentů schopnými pracovat s kódem, však mohou uplatňovat jemně odstupňovanou kontrolu nad jakýmikoli představitelnými výpočetními primitivy prostřednictvím počítačového kódu. Naším úkolem je poskytnout správná primitiva.

Abychom tuto potřebu naplnili, zavádíme napříč našimi produkty novou vyhledávací architekturu: Search as Code (SaC). Tato nová architektura umožňuje modelům sahat do samotného vyhledávacího stacku, namísto pouhé konzumace jeho konečných výstupů. Základní myšlenka je přímočará: vystavujeme součásti vyhledávacího stacku jako primitiva v rámci sady SDK. Pro každý požadavek, který vyžaduje vyhledávání, model tyto primitiva na požádání sestaví do vyhledávacího potrubí přizpůsobeného danému konkrétnímu požadavku.

Sestavení tohoto potrubí se provádí pomocí generování a spouštění kódu v rámci zabezpečeného sandboxu. Na rozdíl od jiných přístupů k vyhledávání řízených generováním kódu jednoduše neumisťujeme tradiční vyhledávací API do prostředí shellu nebo jazykového runtime. Místo toho jsme pečlivě navrhli Agentic Search SDK, která vystavuje jednotlivé stavební bloky vyhledávání na té nejatomárnější možné úrovni.

Search as Code (SaC) posouvá výkonnostní hranici agentního vyhledávání napříč různorodou sadou srovnávacích testů.

Vyzbrojen těmito stavebními bloky poskytuje SaC modelům přímou kontrolu nad každým jednotlivým krokem vyhledávání: načítáním, řazením, filtrováním, větvením, vykreslováním a dalšími. Poskytuje také modelu efektivní přístup k mezistavům, jako jsou seznamy kandidátů a signály řazení. Tyto dvě páky kontroly a přehlednosti dohromady umožňují agentům navrhovat vlastní vyhledávací potrubí zahrnující tisíce operací načítání, optimalizovat tato potrubí za chodu a konzumovat pouze ty nejužitečnější informace jako kontext modelu.

Tento článek popisuje motivaci, design a implementaci SaC spolu s empirickými výsledky jak u stávajících, tak nových srovnávacích testů. SaC stanovuje novou hranici nákladů a výkonu pro agentní vyhledávání a jsme nadšeni, že se o něj můžeme podělit s našimi uživateli a širší komunitou AI.

První vyhledávače na světě byly vytvořeny pro lidské uživatele. Tito uživatelé si zvykli očekávat předvídatelný zážitek, který obvykle sestával z pevného počtu dokumentů seřazených podle relevance. Uživatelé nechtěli proces vyhledávání mikromanagovat; chtěli zadat dotaz a najít užitečný výsledek.

V důsledku toho vyhledávače určené pro lidi konvergovaly k běžné monolitické architektuře zaměřené na vytváření stránek s výsledky vyhledávače (SERP) vhodných pro lidi, které obsahují top n nalezených položek pro vstupní dotaz. Tento vzorec poháněl desítky let pokroku v oblasti spotřebitelského vyhledávání. Je rychlý, známý a vysoce účinný pro lidské prohlížení.

Pak přišly LLM a systémy AI se rovněž staly spotřebiteli vyhledávání. Společnost Perplexity byla v tomto posunu průkopníkem se spuštěním našeho odpovědního stroje v roce 2022. Od té doby se naše úsilí v oblasti vývoje vyhledávání zaměřuje na to, jak optimalizovat hodnotu výsledků vyhledávání pro modely AI. Abychom vytvořili nejpřesnější a nejspolehlivější AI na světě, museli jsme navrhnout vyhledávací systém zaměřený na to, aby byl každý token co nejhustší na informace. Výsledné inovace v oblasti vyhledávání podřízených dokumentů, efektivity kontextu, sémantického porozumění a dalších klíčových oblastí vedly k dramatickému zlepšení schopnosti systémů AI načítat informace a pracovat s nimi.

Avšak i systémy optimalizované pro AI do značné míry zdědily stejnou základní smlouvu jako tradiční vyhledávače: přijmout dotaz, spustit předdefinované vyhledávací potrubí, vrátit plně zpracovanou sadu výsledků. Pro jednoduché požadavky tento přístup funguje dobře. U složitějších požadavků se však stává stále omezujícím úzkým hrdlem, které snižuje výkon, latenci a zvyšuje náklady.

Tradiční vyhledávací systémy nutí agentní pracovní postupy řadit vyhledávání do sekvencí prostřednictvím kol viditelných pro model. Modely musí opakovaně volat stejná vyhledávací potrubí napříč různými parametry dotazů a zavádět všechny výsledky do kontextu modelu.

Tradiční vyhledávací potrubí jsou navržena kolem jednoho bodu kontroly: parametrů dotazu. Vyhledávač vlastní zbytek potrubí podle své předdefinované logiky a model se tomu musí přizpůsobit. Pro model je cokoli podřízeného parametrům dotazu rigidní – podoba samotného výpočtu je mimo kontrolu modelu.

To je rozumná hranice, když je spotřebitelem člověk prohledávající odkazy. Je to špatná hranice, když je spotřebitelem model AI, který se snaží řešit úkoly náročné na znalosti v uzavřené smyčce. Z našich zkušeností tato rigidita vytváří tři opakující se režimy selhání:

Hrubý kontext. Modely AI jsou citlivé na kvalitu a kompaktnost kontextu. Jak kvalita, tak kompaktnost jsou vysoce závislé na dotazu a monolitické vyhledávací potrubí nejsou navržena tak, aby fungovala optimálně pro všechny dotazy. Pokud například model potřebuje jedinou, vysoce chirurgickou informaci, ale má přístup pouze ke koncovému vyhledávacímu koncovému bodu, který upřednostňuje úplnost, použití tohoto koncového bodu vnese do kontextu modelu velké množství irelevantních informací. Na druhou stranu, pokud model potřebuje mnoho informací, z nichž každá vyžaduje jiné vyhledávací strategie, může být nucen sériově volat stejné suboptimální potrubí pro všechny z nich, což vede k rostoucím nákladům a šumu v kontextu.

Selhání při využívání doménových znalostí. V mnoha případech může mít model doménové znalosti (ze svého tréninku, dovednosti agenta, paměti nebo dřívějších tokenů v trajektorii LLM), které by měly vést vyhledávací strategii. Rigidní vyhledávací rozhraní však modelu brání tyto znalosti využít. Model si například může pro konkrétní požadavek uvědomit, že by měl určitým způsobem kombinovat lexikální a sémantické signály, upřednostnit určité zdroje nebo agregovat výsledky podle konkrétního klíče. Pokud tyto poznatky nelze implementovat prostřednictvím parametrů dotazu, nemůže podle nich model ve skutečnosti jednat.

Neefektivní tok řízení a znečištění kontextu. Mnoho pracovních postupů vyhledávání není přirozeně sériových. Mohou vyžadovat větvení nad variantami dotazů, paralelní načítání, deduplikaci a další operace, které vyžadují nelineární a asynchronní tok řízení. Vynucování těchto kroků prostřednictvím opakovaných kol modelu přidává latenci a ztěžuje optimalizaci pracovního postupu. Rovněž to znečišťuje kontext modelu šumovými mezistavy, které nemusí být užitečné pro uvažování modelu, což vede k horšímu výkonu a častějším kompacím.

S těmito výzvami se v éře volání funkcí a MCP u AI nedalo příliš dělat. Když každá operace vyhledávání vyžaduje vlastní cestu tam a zpět k odvozování LLM, vývojáři přirozeně preferují udělat v této cestě co nejvíce práce. To znamená koncová vyhledávací potrubí, která vracejí plně zpracované sady výsledků pro přímou spotřebu modelem.

V důsledku toho většina systémů vyhledávání orientovaných na AI dnes stále funguje za této monolitické smlouvy. S pokračujícím růstem inteligence modelů a požadavků uživatelů se však nedostatky této smlouvy stávají výraznějšími. Dnešní nejpokročilejší systémy AI, postavené na postrojích upřednostňujících kód, mohou skládat pracovní postupy specifické pro daný úkol, které provádějí tisíce akcí za minutu. Vyhledávací systémy tento potenciál ještě plně nerealizovaly.

Již dlouho máme podezření, že správná hranice pro vyhledávání nativní pro AI leží níže ve stacku. Modely by neměly pouze volat vyhledávač. Měly by být schopny orchestrvat jednotlivé části vyhledávacího stacku tak, jak to konkrétní úkol vyžaduje. To vyžaduje zásadně odlišnou architekturu.

Další generace vyhledávacích architektur bude záviset na základním principu: vyhledávání by mělo být pro agenty AI přirozeně programovatelné. Agent nesmí být omezen na sadu předem určených vyhledávacích potrubí. Agent musí být spíše schopen sestavit potrubí, které konkrétní úkol vyžaduje, pomocí skladebných stavebních bloků navržených na různých úrovních abstrakce.

Naše nová architektura Search as Code (SaC) tento princip ztělesňuje. V SaC není ani jediná operace načítání odeslána prostřednictvím volání funkcí nebo rozhraní MCP. Místo toho jsou všechny operace řízeny prostřednictvím kódu v Pythonu generovaného modelem. Pro nejjednodušší potřeby vyhledávání může tento kód sestávat z několika požadavků na koncový bod vyhledávání na vysoké úrovni. Pro složité úkoly však může být kód tak složitý, jak je potřeba, a zahrnovat podmíněné provádění, asynchronii, paralelismus a volání široké škály nízkoúrovňových primitiv.

Architektura Search as Code (SaC) se spoléhá na stack, který se skládá z modelů, výpočetních sandboxů a sady Agentic Search SDK umístěné nad vyhledávací infrastrukturou společnosti Perplexity.

SaC zahrnuje tři úzce propojené vrstvy:

Modely slouží jako rovina řízení. Analyzují pokyn uživatele (nebo nadřazeného agenta), rozkládají pokyn na úkoly, rozhodují, která potrubí načítání a zpracování jsou pro každý úkol potřeba, a generují kód pro implementaci těchto potrubí.

Výpočetní sandboxy poskytují deterministický výpočet prostřednictvím zabezpečeného runtime pro spouštění kódu. Poskytují plátno pro modely k implementaci toku řízení, dávkování, opakovaných pokusů, filtrování, spojování, agregace a dalších deterministických operací.

Naše Agentic Search SDK zpřístupňuje vyhledávací stack společnosti Perplexity jako skladebná primitiva. Poskytuje stavební bloky od nízkoúrovňových operací načítání až po sémantickou analýzu na vysoké úrovni. Sada SDK je integrována do spouštěcích prostředí sandboxů, což modelům umožňuje orchestrvat až tisíce operací v rámci jedné inferenční otočky. Níže probíráme naše rozhodnutí o návrhu pro každou vrstvu.

Agentic Search SDK definuje stavební bloky pro programovatelné vyhledávání. Důležité je, že naše sada SDK není předem existující vyhledávací API zabalené jako knihovna. Během posledních několika měsíců náš inženýrský tým přepracoval náš vyhledávací stack do modulárních, skladebných primitiv. Vybudovali jsme Agentic Search SDK tak, abychom poskytli přímý přístup k těmto primitivům, což vytváří mnohem výkonnější plátno, na kterém může model orchestrvat vyhledávací potrubí specifická pro daný úkol.

V rámci sady SDK jsou stále k dispozici vysoce úrovňová, koncová vyhledávací potrubí, ale už nejsou jedinou možností. Místo toho slouží jako forma zkratky pro běžné vzorce vyhledávání. Model je může volně používat nebo obcházet podle toho, jak to úkol vyžaduje.

Volba běhového prostředí: Jako běhové prostředí pro SDK jsme zvažovali Python, Rust, TypeScript a Bash. Měli jsme podezření, že Python bude nejpřirozenější volbou vzhledem k jeho všudypřítomnosti a ekosystému knihoven pro zpracování dat. Interní testování to potvrdilo a verze SDK uvedená dnes na trh je založena na Pythonu. Očekáváme, že budeme volbu běhového prostředí pravidelně přehodnocovat, abychom zajistili, že bude i nadále poskytovat nejlepší zážitek pro agenta.

Neustálé zlepšování pomocí automatického výzkumu: Optimalizovali jsme také použitelnost sady SDK pro špičkové LLM prostřednictvím iterativní smyčky automatického výzkumu. Tato smyčka, která běží nepřetržitě celé týdny, navrhuje a ověřuje vylepšení sady SDK oproti metrikám včetně latence, kvality generování kódu a celkového výkonu úkolu. Smyčka automatického výzkumu již provedla řadu změn ve struktuře i vzhledu sady SDK s výraznými přínosy ve všech směrech. Plánujeme sadu SDK dále vylepšovat prostřednictvím automatického výzkumu s tím, jak se budou objevovat nové špičkové modely a vyhledávací komponenty.

Sandboxy poskytují zabezpečená prostředí pro definování a spouštění potrubí SaC. Provádějí kód generovaný modelem a poskytují přístup k Agentic Search SDK pro usnadnění interakce s jednotlivými vyhledávacími primitivy.

Investovali jsme značné prostředky do optimalizace a zabezpečení našich sandboxů a jejich celkový návrh systému si zaslouží samostatný článek. Zde se zaměřujeme na hledisko návrhu, které je pro SaC nejrelevantnější: správu mezistavů.

SaC umožňuje agentům orchestrvat složitá potrubí v rámci jedné inferenční otočky. Některé mezistavy je však nutné přenášet napříč otočkami. Například model může chtít načíst některé dokumenty v otočce 1, zkontrolovat podvzorek těchto dokumentů v otočce 2, aby rozhodl, co dělat dál, a poté vyvinout následné vyhledávací potrubí pro další zkoumání těchto dokumentů od otočky 3 dále. Jak bylo diskutováno výše, předávání mezistavů prostřednictvím prostoru tokenů není efektivní strategií.

Zvažovali jsme dva přístupy ke správě mezistavů napříč otočkami:

Trvalý souborový systém + explicitní serde: Sandboxy mohou vystavovat trvalé souborové systémy, které mohou modely používat napříč otočkami. Modely, které si přejí zachovat mezistav, mohou zahrnout krok serializace v rámci generovaného kódu pro otočku spolu s krokem deserializace v následné otočce (buď pro vlastní kontrolu modelů, nebo pro následné použití). Přístup se souborovým systémem umožňuje modelům přímo a explicitně kontrolovat, jak je mezistav předáván napříč otočkami. Rovněž zajišťuje sledovatelnost vynucením explicitní identifikace a uchování informací použitých modelem. Jednou nevýhodou je latence a režie kontextu způsobená generováním kódu serde, ačkoli dobře navržené pomocné funkce mohou tuto režii zmírnit.

REPL: Alternativně může sandbox zachovat samotné běhové prostředí spouštění napříč otočkami v prostředí stylu REPL. To umožňuje modelům udržovat mezistav v paměti, aniž by jej musely vůbec serializovat, protože na proměnné definované nebo modifikované v předchozích otočkách lze jednoduše odkazovat podle jména v následujících otočkách. Přístup REPL je efektivnější z hlediska tokenů, protože se vyhýbá nutnosti generovat kód serde. Absence explicitního kroku serializace však může snížit následný výkon z důvodů známých každému, kdo pracoval se 100buněčným notebookem Jupyter: jak se jmenný prostor proměnných stává nepřehledným, je obtížnější sledovat, co přesně je zachováno napříč otočkami a proč.

Testovali jsme oba přístupy a zjistili jsme, že přestože při běžném použití fungují podobně, serde založené na souborovém systému poskytuje lepší spolehlivost na obzvláště dlouhých trajektoriích. Jako naše řešení proto přijímáme serde založené na souborovém systému. Domníváme se, že požadavek, aby modely předávaly stav deklarativně namísto implicitně, jim pomáhá spravovat tento stav efektivněji. Jedná se o předběžné zjištění a budeme nadále iterovat na obou přístupech.

Modely pohánějící postroje agentů slouží jako řídicí rovina SaC: dynamicky sestavují vyhledávací potrubí ze stavebních bloků Agentic Search SDK tak, aby vyhovovaly potřebám každého úkolu, a poté tato potrubí odesílají jako kód pro spuštění v sandboxu.

Společnost Perplexity využívá v rámci našich postrojů agentů řadu modelů a zjistili jsme, že nejnovější špičkové modely jsou celkově velmi účinné při generování kódu pro obecné účely. Hlavní výzvou je vyvolat efektivní generování kódu specificky pro Agentic Search SDK. To znamená, jak můžeme přimět modely, aby účinně propletly stavební bloky naší sady SDK do potrubí optimalizovaných pro daný úkol?

Na rozdíl od standardní knihovny jazyka je nepravděpodobné, že by vlastní sada SDK byla zastoupena v předtrénovacích datech. Dokonce i s vylepšeními použitelnosti sady SDK z automatického výzkumu jsou mnohé modely stále trénovány k interakci s vyhledávacími systémy prostřednictvím volání funkcí a přímého vyvolání MCP. Je nepravděpodobné, že by tyto modely dokázaly odborně ovládat sadu SDK pouze se zdrojovým kódem a automaticky generovanou dokumentací.

K vyřešení této výzvy jsme vyvinuli vysoce vyladěné dovednosti agentů (Agent Skills), které modely učí efektivně využívat naši sadu SDK. Počáteční verze byly vyvinuty v souladu s principy návrhu dovedností společnosti Perplexity a poté optimalizovány prostřednictvím vyhrazené smyčky automatického výzkumu zaměřené na stejné metriky používané při optimalizaci sady SDK. Velikost dovedností také omezujeme, abychom se chránili před nafouknutím kontextu, a naše konečné verze mají méně než 2000 tokenů ve svých kořenových souborech SKILL.md.

Optimalizované dovednosti jdou nad rámec pouhého výčtu dostupných stavebních bloků sady SDK (což lze stejně snadno získat prostřednictvím reflexe za běhu). Většina tokenů je vynaložena na poskytování stručných, zobecnitelných pokynů a příkladů málopočetných výstřelů pro skládání těchto bloků do složitých vzorců. Vyzbrojeni těmito dovednostmi pozorujeme, že modely efektivně využívají sadu SDK k orchestraci vyhledávacích potrubí, která se škálují na tisíce samostatných operací.

Kombinací těchto vrstev mění SaC vztah mezi modely a vyhledávacím stackem. V systémech vyhledávání s pevným potrubím sedí model nad vyhledáváním a komunikuje s ním prostřednictvím úzkého rozhraní sériového volajícího. V SaC se model stává aktivním účastníkem orchestrace samotného procesu vyhledávání. Všechny prvky vyhledávacího stacku se stávají přímo programovatelnými modelem, přičemž sandbox a Agentic Search SDK poskytují potřebná rozhraní k těmto prvkům.

A co schopnosti, které nativně neexistují? Kód je mocným médiem pro orchestraci dříve existujících schopností. Síla kódu však přesahuje orchestraci. Může také sloužit jako výplň mezer pro schopnosti, které ve vyhledávacím stacku nebo SDK chybí. Agenti těží z úspornosti a pro sadu SDK by nebylo efektivní pokrýt každou potenciální operaci vyhrazenou funkcí. Místo toho sada SDK poskytuje nejzákladnější primitiva a model může za chodu vytvořit jakékoli další komponenty pomocí kódu.

Zvažte například složitý regulární výraz, který nelze efektivně implementovat pomocí vlastní syntaxe dotazů vyhledávacího systému. Bez schopností kódování by byl model nucen generovat svou nejlepší aproximaci, provést dotaz a provést filtrování v prostoru tokenů na velmi zašuměné sadě výsledků. S SaC může model místo toho vygenerovat program, který provádí paralelní volání SDK ke sběru nadmnožiny požadované sady výsledků regulárního výrazu. Po deduplikaci přes SDK může model napsat dodatečný kód k deterministickému zúžení výsledků na přesný regulární výraz. Tímto způsobem mohou agenti implementovat vlastní vyhledávací schopnosti, aniž by nafukovali sadu SDK příliš úzkými podprogramy.

Prezentujeme případovou studii založenou na úkolu z reálného světa v rámci naší testovací sady. Tento úkol požaduje po agentovi, aby identifikoval a charakterizoval přes 200 vysoce závažných chyb CVE z let 2023–2025. Každý záznam musí citovat vlastní doporučení dotčeného dodavatele, pojmenovat produkt a verzi opravy a ukázat, že verze opravy je vázána na konkrétní CVE.

Odpověď SaC dosáhla 100% přesnosti, přičemž celkové využití tokenů kleslo o 85,1 % oproti výchozímu stavu bez SaC (z 288,7 tisíc tokenů na 42,9 tisíc tokenů). Testované systémy jiné než Perplexity, rozebrané podrobněji v sekci 4, dosáhly skóre nižšího než 25 %.

Prezentujeme tři stylizované bloky kódu z trajektorie, abychom ilustrovali, jak programovatelnost SaC umožňuje modelu implementovat efektivní strategie.

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

Tento první blok je čistá orchestrace. Vygenerovaný program začíná kódováním pravidla třídy zdrojů přímo do plánu dotazu: relevantní jsou pouze formáty doporučení vlastněné dodavatelem. Zdroje nepocházející od dodavatelů, včetně NVD, MITRE, CVE Details, zpráv, stránek CERT a databází třetích stran, jsou strukturálně mimo záběr. Omezení na přesnou frázování také tlačí vyhledávání směrem ke stránkám, jejichž indexovaný text již obsahuje přesné podrobnosti CVE potřebné v dalších krocích.

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

Druhý blok využívá LLM jako mezipodprogram plánování. Kód shrnuje, které páry dodavatel-rok produkují dostatek stránek kandidátů, požaduje cílená upřesnění a ověřuje každý navržený dotaz před provedením. To zachovává užitečné vzorce z trajektorie, jako jsou sondy s přesnou frází vymezené na webech a adaptivní doplňování, aniž by se v SDK pevně zakódoval specifický prohledávač doporučení CVE.

python

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

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

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

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

Konečný blok je ověřovač výsledků, jehož logika je zcela definována agentem pomocí generování kódu. Zatímco podprogramy vyhledávání mohou najít věrohodné stránky doporučení, úkol vyžaduje přísnější vztah: doporučení musí v textu vytvořeném dodavatelem svázat jednu chybu CVE s jedním dotčeným produktem a jednou verzí opravy. Schéma činí tento vztah explicitním, takže následný kód může provádět deduplikaci podle CVE, odmítnout URL adresy agregátorů, zahodit slabé důkazy o verzích a pokračovat v doplňování, dokud není dosaženo minimálního počtu záznamů.

Vyhodnocujeme efektivitu SaC na komplexní sadě srovnávacích testů se zaměřením jak na absolutní výkon, tak na hranici nákladů a výkonu.

Naše sada srovnávacích testů obsahuje celkem pět testů navržených k zátěžovému testování pracovních postupů AI závislých na vyhledávání napříč řadou domén, formátů úkolů a úrovní složitosti. Používáme čtyři již existující srovnávací testy: DeepSearchQA (DSQA), BrowseComp, Humanity's Last Exam (HLE) a WideSearch. Pro první tři srovnávací testy (DSQA, BrowseComp a HLE) uvádíme přesnost jako hlavní metriku. Pro WideSearch uvádíme F1 skóre po řádcích.

Používáme také nově vyvinutý srovnávací test WANDR, který se zaměřuje na obtížné úkoly „širokého výzkumu“ vyžadující pečlivou orchestraci vyhledávání, výpočtů a uvažování modelu. WANDR je inspirován odbornými úkoly náročnými na znalosti, které Perplexity Computer zpracovává pro uživatele. Navazuje na WideSearch a podobné srovnávací testy, ale klade důraz na komplexnější úkoly a struktury úkolů. Srovnávací test WANDR publikujeme v nadcházejících týdnech.

Vyhodnocujeme pět systémů založených na agentech. Zvažujeme jednotlivé běhy namísto skóre „best-of-N“, abychom izolovali výkon základní architektury namísto výhod paralelizace. Konfigurace každého systému je popsána níže:

Perplexity (SaC): Vyhodnocujeme architekturu SaC v rámci produkčního Agent API společnosti Perplexity. Jako základní model slouží GPT 5.5 (vysoké uvažování).

OpenAI: Vyhodnocujeme OpenAI Responses API s povoleným vyhledáváním (web_search) i Python runtime (code_interpreter). Jako základní model slouží GPT 5.5 (vysoké uvažování).

Anthropic: Vyhodnocujeme Anthropic Managed Agents s nástroji agenta 20260401 a automaticky povolenými příkazy. Jako základní model slouží Opus 4.7 (vysoké uvažování).

Exa: Vyhodnocujeme Exa Agent přes produkční API, s úsilím nastaveným na vysoké.

Parallel: Vyhodnocujeme Parallel Tasks přes produkční API, s procesorem nastaveným na ultra4x.

Tabulka 1 uvádí skóre srovnávacích testů pro každý systém. SaC překonává všechny ostatní systémy ve čtyřech z pěti srovnávacích testů. Vzbývajícím srovnávacím testu (HLE) se SaC v podstatě dělí o první místo s OpenAI Responses. Obrázek 2 z úvodu vizualizuje tato skóre v grafické podobě.

Srovnávací test	Perplexity (SaC)	OpenAI	Anthropic	Exa	Parallel
DSQA	0,871	0,733	0,815	0,530	0,386
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

Tabulka 1 | Skóre srovnávacích testů pro každý vyhodnocený systém. Nejlepší skóre v řádku tučně.

Ačkoli SaC dosahuje špičkového výkonu napříč sadou srovnávacích testů, jeho výhoda je obzvláště výrazná u WANDR. Obrázek 5 rozebírá skóre WANDR a ukazuje, že implementace SaC od společnosti Perplexity překonává druhý nejlepší systém 2,5krát. Navzdory tomuto velkému náskoku zůstává WANDR nenasycený a představuje výzvu i pro SaC. Věříme, že složité, vysoce horizontální pracovní postupy vyhledávání vyžadované úkoly WANDR budou vyžadovat další pokroky ve výzkumu a vývoji vyhledávání, aby bylo možné dosahovat trvale vysokého výkonu.

Skóre WANDR napříč vyhodnocenými systémy. Perplexity Agent API vede před druhým nejlepším systémem 2,5krát.

Nakonec měříme relativní zisky SaC oproti tradičnějšímu vyhledávacímu potrubí, které využívá stejnou vyhledávací infrastrukturu Perplexity. Obrázek 6 uvádí rozdíl ve skóre mezi architekturami SaC a bez SaC v každém srovnávacím testu. Ve všech směrech poskytuje SaC podstatné zvýšení výkonu, přičemž největší absolutní zisk je u DSQA (+19,77 pp, 29 %) a největší relativní zisk u WANDR (+12,00 pp, 45 %).

Základní linie Perplexity vs. skóre SaC na každém srovnávacím testu s vyznačenými absolutními a relativními deltami.

V praxi se uživatelé zajímají o výkon vzhledem k nákladům. Vyhodnocujeme proto hranici nákladů a výkonu u DSQA a WideSearch. Měříme náklady a výkon SaC napříč nízkou, střední a vysokou úrovní uvažování modelu spolu s ostatními systémy. Obrázky 7 a 8 vynášejí skóre srovnávacího testu proti ceně za úkol, přičemž osá x je obrácená, takže body dále vpravo jsou levnější a body výše představují lepší výkon.

Skóre DSQA versus cena za úkol. Přerušovaná čára spojuje konfigurace uvažování modelu SaC.

U DSQA leží všechna tři nastavení SaC na pravé horní hranici. Nastavení s nízkým uvažováním je levnější než všechny ostatní systémy a zároveň funguje lépe než dva z nich. Nastavení se středním uvažováním překonává všechny systémy bez SaC za méně než 1 $ za úkol. Nastavení s vysokým uvažováním dosahuje špičkového výkonu s konkurenceschopnými náklady.

Skóre WideSearch versus cena za úkol. Přerušovaná čára spojuje konfigurace uvažování modelu SaC.

WideSearch ukazuje podobně tvarovanou hranici. Stejně jako u DSQA dosahuje nastavení s nízkým uvažováním konkurenceschopného výkonu za nižší náklady než všechny systémy bez SaC, zatímco střední i vysoké uvažování překonávají systémy bez SaC ve výkonu úkolu.

Search as Code odráží širší změnu v návrhu softwaru. Po desetiletí byly softwarové systémy organizovány kolem deterministických instrukcí prováděných tradičními běhovými prostředími na procesorech. Špičkové modely představují novou formu výpočtu: uvažování v prostoru tokenů, které dokáže jak následovat, tak generovat instrukce. Nejschopnější výpočetní systémy budou tyto dvě formy výpočtu kombino-vat namísto volby mezi nimi.

Vyhledávání je přirozeným testovacím prostředím pro tuto hybridní architekturu. Modely se dobře hodí k rozhodování o tom, jaké důkazy jsou potřeba a jak by měla být nejistota vyřešena. Deterministická běhová prostředí se dobře hodí pro dávkování, paralelismus, filtrování, řazení a agregaci. Vyhledávací infrastruktura slouží jako univerzální I/O vrstva, která poskytuje běhovému prostředí užitečné rukojeti k informacím světa, které dokážou udržet tisíce operací za minutu. Když jsou tyto kousky integrovány, výsledný systém je mnohem výkonnější a efektivnější při plnění úkolů v reálném světě.

Každá část této architektury je nezbytná k odemčení těchto schopností. Bez inteligentních modelů nemůže systém uvažovat nad vyhledávací strategií. Bez sandboxů jsou modely tlačeny do sériového I/O a neefektivního zpracování v prostoru tokenů. A bez atomizovaného vyhledávacího stacku nemá model co orchestrvat. SaC funguje proto, že uvažování, deterministický výpočet a I/O jsou společně navrženy tak, aby zdůraznily silné stránky každé vrstvy.

Tento společný návrh lze posunout ještě dále vývojem smyček neustálého zlepšování. Například Agentic Search SDK a dovednosti SaC Agent Skills by mohly být společně optimalizovány v běžné smyčce automatického výzkumu. Ambiciózněji lze modely trénovat tak, aby využívaly nízkoúrovňová vyhledávací primitiva vystavená jako sada SDK. Někdo by se mohl dokonce pokusit o společný vývoj designu sady SDK během samotného procesu trénování modelu. Těšíme se na prosazování agresivnějších strategií společného návrhu v budoucí práci.

Vybudovali jsme SaC, abychom modelům umožnili kontrolovat proces vyhledávání, namísto pouhé konzumace jeho výsledků. Naše výsledky dokazují sílu této kontroly: SaC posouvá jak absolutní výkon, tak hranici nákladů a výkonu u benchmarků agentů náročných na znalosti. Jsme nadšeni, že můžeme přinést schopnosti SaC našim uživatelům, počínaje dneškem s Perplexity Computer a Agent API. Budeme i nadále optimalizovat architekturu SaC napříč všemi vrstvami stacku, abychom zajistili, že naši uživatelé (a agenti, kteří jim slouží) budou mít k dispozici co nejvýkonnější a nejefektivnější možné vyhledávací schopnosti.

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

Úvod

Rigidita tradičního vyhledávání

Režimy selhání způsobené rigiditou

Navrhování programovatelné vyhledávací architektury

Agentic Search SDK

Sandboxy

Modely

Kód jako orchestrátor a výplň mezer

Případová studie: Doporučení dodavatelů CVE

Výsledky vyhodnocení

Srovnávací testy a systémy

Srovnávací výkon

Hranice nákladů a výkonu

Směrem k nové architektuře výpočetní techniky

Citace