Suche als Codegenerierung neu denken

Die Suche ist ein zentrales Element für KI-Systeme. Frontier-Modelle werden von Monat zu Monat leistungsfähiger, benötigen jedoch weiterhin Zugriff auf aktuelle, genaue und sorgfältig kuratierte Erkenntnisse aus der Außenwelt. Die Suche ist der primäre Weg, auf dem KI-Systeme auf dieses Wissen zugreifen; sie ist somit eine grundlegende Komponente jedes Produkts, das Schlussfolgerungen ziehen, Maßnahmen ergreifen und reale Aufgaben ausführen muss.

Wir sind der Ansicht, dass herkömmliche Such-Pipelines im Zeitalter der Agenten zunehmend veraltet sind. Traditionelle Suchen beantworten Anfragen, aber die heutigen Agenten erfüllen Aufgaben, die unzählige Formen annehmen können. Diese Aufgaben erfordern, dass Agenten aufgabenspezifische Abrufstrategien direkt innerhalb ihrer Frameworks definieren. Bei Perplexity Computer haben wir erlebt, wie einzelne Aufgaben innerhalb weniger Minuten Hunderte oder sogar Tausende von Abrufoperationen auslösen – ein Workflow, der für Menschen unmöglich, für Agenten jedoch absolut natürlich ist.

In dieser Welt muss die Suche selbst agentenbasiert werden, wobei ihre Bausteine direkt als SDKs innerhalb des Agenten-Frameworks zugänglich sind. Wir führen Search as Code (SaC) als Perplexitys neue Referenz-Sucharchitektur ein.

Der Such-Stack von Perplexity verarbeitet pro Sekunde Tausende von Anfragen über unsere Anwendungen und die API-Plattform hinweg. Im September 2025 veröffentlichten wir den ersten architektonischen Überblick unserer Suchsysteme. Kontinuierliche Innovationen innerhalb dieser Systeme haben die Einführung neuer Angebote wie Search API, Agent API und Computer unterstützt, wobei Selbstoptimierungsschleifen den Such-Stack tagtäglich verbessern, um Nutzer besser bedienen zu können.

Traditionell haben KI-Systeme die Suche als Monolithen behandelt: Ein KI-Modell sendet eine Anfrage, die Suchmaschine führt ihre vordefinierte Pipeline aus und das Modell konsumiert die Ergebnisse als Kontext. Größtenteils funktionierte dies gut, um den Anforderungen früher KI-Nutzer gerecht zu werden. Angesichts der relativen Einfachheit ihrer Anfragen gab es keinen Grund, sich Gedanken darüber zu machen, wie genau die Such-Pipeline konzipiert war oder ob die Architektur der Pipeline für die jeweilige Aufgabe optimal war. Die Standardeinstellungen wurden als ausreichend betrachtet, ebenso wie die Standardschnittstellen (Funktionsaufrufe und MCPs).

Herkömmliche Sucharchitekturen legen ein einzelnes, festes System offen, das Modelle seriell aufrufen, während Search as Code atomisierte Suchprimitive offenlegt, die Agenten durch generierten Code zusammensetzen.

Doch heute veraltet dieser Ansatz mit jedem Monat mehr. Nutzer fordern von KI weit mehr als nur punktuelle Analysen. Sie erwarten, dass Agenten Aufgaben über Stunden oder sogar Tage hinweg von Anfang bis Ende abschließen. Diese Aufgaben können komplex, ergebnisoffen und hinsichtlich ihrer Informationsbedürfnisse höchst variabel sein, und monolithische Architekturen brechen unter dem Gewicht dieser Anforderungen zusammen.

Der entscheidende Engpass ist letztlich eine Frage der Kontrolle. Frontier-Modelle sind bereits recht gut darin, über festen Kontext zu argumentieren. Die leistungsfähigsten KI-Systeme erfordern jedoch die Fähigkeit, zu steuern, wie dieser Kontext abgerufen, verarbeitet, aggregiert und dem Modell präsentiert wird.

Traditionelle Suchsysteme wurden nicht mit diesem Maß an Steuerbarkeit entworfen. Schließlich kann von menschlichen Nutzern nicht erwartet werden, eine fein abgestimmte Kontrolle über das Innere einer Such-Pipeline auszuüben, selbst wenn dies angeboten würde. Frühe KI-Modelle können die Suche nur über einen linearen Pfad von Funktionsaufrufen und MCPs steuern. Aber die heutigen Frontier-Modelle, gesteuert durch Code-fähige Agenten-Frameworks, können mittels Computercode eine fein abgestimmte Kontrolle über beliebige Rechenprimitive ausüben. Unsere Aufgabe ist es, die richtigen Primitive bereitzustellen.

Um diesem Bedarf gerecht zu werden, führen wir eine neue Sucharchitektur über unsere Produkte hinweg ein: Search as Code (SaC). Diese neue Architektur befähigt Modelle, in den Such-Stack selbst einzugreifen, anstatt lediglich dessen Endergebnisse zu konsumieren. Die Kernidee ist einfach: Wir legen die Komponenten des Such-Stacks als Primitive innerhalb eines SDKs offen. Für jede Anfrage, die eine Suche erfordert, stellt ein Modell diese Primitive bei Bedarf zu einer Abruf-Pipeline zusammen, die auf diese spezifische Anfrage zugeschnitten ist.

Das Zusammenstellen dieser Pipeline erfolgt durch Codegenerierung und Ausführung in einer sicheren Sandbox. Im Gegensatz zu anderen Codegen-gesteuerten Ansätzen zur Suche fügen wir nicht einfach eine traditionelle Such-API in eine Shell oder Laufzeitumgebung ein. Stattdessen haben wir sorgfältig ein Agentic Search SDK entwickelt, das die einzelnen Bausteine der Suche auf der atomarsten Ebene offenlegt.

Search as Code (SaC) erweitert die Leistungsgrenze der agentenbasierten Suche über eine vielfältige Reihe von Benchmarks hinweg.

Ausgestattet mit diesen Bausteinen gibt SaC den Modellen die direkte Kontrolle über jeden einzelnen Suchschritt: Abruf, Ranking, Filterung, Fan-Outs, Rendering und mehr. Es bietet dem Modell zudem effizienten Zugriff auf Zwischenzustände wie Kandidatenlisten und Ranking-Signale. Zusammen ermöglichen diese beiden Hebel der Kontrolle und Lesbarkeit den Agenten, maßgeschneiderte Such-Pipelines zu entwerfen, die Tausende von Abrufoperationen umfassen, diese Pipelines während der Laufzeit zu optimieren und nur die nützlichsten Informationen als Modellkontext zu konsumieren.

Dieser Artikel beschreibt die Motivation, das Design und die Implementierung von SaC sowie empirische Ergebnisse sowohl zu bestehenden als auch zu neuen Benchmarks. SaC etabliert eine neue Kosten-Leistungs-Grenze für agentenbasierte Suche, und wir freuen uns, dies mit unseren Nutzern und der breiteren KI-Community zu teilen.

Die ersten Suchmaschinen der Welt wurden für menschliche Nutzer entwickelt. Diese Nutzer erwarteten eine vorhersehbare Erfahrung, die typischerweise aus einer festen Anzahl relevanzgeprüfter Dokumente bestand. Nutzer wollten den Suchprozess nicht im Detail steuern; sie wollten eine Anfrage eingeben und ein nützliches Ergebnis finden.

Infolgedessen konvergierten nutzerorientierte Suchmaschinen auf einer gemeinsamen monolithischen Architektur, die darauf ausgerichtet war, nutzerfreundliche Ergebnisseiten (SERPs) zu produzieren, die die Top-N-Treffer für eine Eingabeanfrage enthielten. Dieses Muster hat Jahrzehnte des Fortschritts bei der Verbrauchersuche vorangetrieben. Es ist schnell, vertraut und für das menschliche Surfen höchst effektiv.

Dann kamen LLMs, und KI-Systeme wurden ebenfalls zu Nutzern der Suche. Perplexity leistete mit der Einführung unserer Antwort-Engine im Jahr 2022 Pionierarbeit bei diesem Wandel. Seitdem konzentrieren sich unsere Bemühungen in der Sucheinigung darauf, wie der Wert von Suchergebnissen für KI-Modelle optimiert werden kann. Um die genaueste und zuverlässigste KI der Welt zu bauen, mussten wir ein Suchsystem entwickeln, das darauf fokussiert ist, jeden Token so informationsdicht wie möglich zu machen. Die daraus resultierenden Innovationen in der Sub-Dokument-Abfrage, Kontexteffizienz, semantischem Verständnis und anderen Schlüsselbereichen führten zu dramatischen Verbesserungen der Fähigkeit von KI-Systemen, Informationen abzurufen und darauf zu reagieren.

Selbst KI-optimierte Systeme haben jedoch weitgehend denselben grundlegenden Vertrag wie traditionelle Suchmaschinen geerbt: eine Anfrage akzeptieren, eine vordefinierte Such-Pipeline ausführen, einen vollständig verarbeiteten Ergebnissatz zurückgeben. Bei einfachen Anfragen funktioniert dieser Ansatz gut. Bei komplexeren Anfragen wird dies jedoch zu einem zunehmend einschränkenden Engpass, der Leistung, Latenz und Kosten beeinträchtigt.

Traditionelle Suchsysteme zwingen agentenbasierte Workflows dazu, die Suche über modell-sichtbare Turns hinweg zu sequenzieren. Modelle müssen wiederholt dieselben Such-Pipelines über verschiedene Anfrageparameter aufrufen und alle Ergebnisse in den Modellkontext einbringen.

Traditionelle Such-Pipelines sind um einen einzelnen Kontrollpunkt herum konzipiert: die Anfrageparameter. Die Suchmaschine besitzt den Rest der Pipeline gemäß ihrer vordefinierten Logik, und das Modell muss sich daran anpassen. Für das Modell ist alles, was den Anfrageparametern nachgelagert ist, starr – die Form der tatsächlichen Berechnung liegt außerhalb der Kontrolle des Modells.

Dies ist eine vernünftige Grenze, wenn der Nutzer ein Mensch ist, der Links scannt. Es ist eine schlechte Grenze, wenn der Nutzer ein KI-Modell ist, das wissensintensive Aufgaben in einer geschlossenen Schleife lösen will. Unserer Erfahrung nach erzeugt diese Starrheit drei wiederkehrende Fehlermodi:

Grobkörniger Kontext. KI-Modelle reagieren empfindlich auf die Qualität und Kompaktheit des Kontextes. Sowohl Qualität als auch Kompaktheit sind stark von der Anfrage abhängig, und monolithische Such-Pipelines sind nicht darauf ausgelegt, über alle Anfragen hinweg optimal zu funktionieren. Wenn ein Modell beispielsweise ein einzelnes, hochspezifisches Informationsteil benötigt, aber nur Zugriff auf einen End-zu-End-Suchendpunkt hat, der den Abruf priorisiert, führt die Verwendung dieses Endpunkts eine große Menge irrelevanter Informationen in den Modellkontext ein. Wenn ein Modell hingegen viele Informationsteile benötigt, die jeweils unterschiedliche Suchstrategien erfordern, ist es möglicherweise gezwungen, seriell dieselbe suboptimale Pipeline für alle aufzurufen, was zu explodierenden Kosten und verrauschtem Kontext führt.

Versäumnis, Domänenwissen zu nutzen. In vielen Fällen verfügt das Modell möglicherweise über Domänenwissen (aus seinem Training, einer Agenten-Skill, dem Speicher oder früheren Token in der LLM-Trajektorie), das die Suchstrategie leiten sollte. Eine starre Suchschnittstelle hindert das Modell jedoch daran, dieses Wissen zu nutzen. Das Modell könnte beispielsweise für eine spezifische Anfrage erkennen, dass es lexikalische und semantische Signale auf eine bestimmte Weise mischen, bestimmte Quellen priorisieren oder Ergebnisse nach einem spezifischen Schlüssel aggregieren sollte. Sofern diese Erkenntnisse nicht zufällig über Anfrageparameter implementierbar sind, kann das Modell tatsächlich nicht darauf reagieren.

Ineffizienter Kontrollfluss und Kontextverschmutzung. Viele Such-Workflows sind nicht von Natur aus seriell. Sie benötigen möglicherweise Fan-Outs über Anfragevarianten, paralleles Abrufen, Deduplizierung und andere Operationen, die einen nichtlinearen und asynchronen Kontrollfluss erfordern. Das Erzwingen dieser Schritte durch wiederholte Modell-Turns erhöht die Latenz und macht den Workflow schwieriger zu optimieren. Es verschmutzt zudem den Modellkontext mit verrauschtem Zwischenzustand, der möglicherweise für das Denken des Modells nicht nützlich ist, was zu schlechterer Leistung und häufigeren Kompaktierungen führt.

Während der Ära von Funktionsaufrufen & MCPs der KI konnte nicht viel gegen diese Herausforderungen unternommen werden. Wenn jede Suchoperation ihren eigenen Roundtrip zur LLM-Inferenz erfordert, bevorzugen Entwickler es natürlich, so viel wie möglich in diesem Roundtrip zu erledigen. Dies bedeutet End-zu-End-Such-Pipelines, die vollständig verarbeitete Ergebnissätze zur direkten Verwendung durch ein Modell zurückgeben.

Infolgedessen arbeiten die meisten KI-orientierten Suchsysteme heute immer noch unter diesem monolithischen Vertrag. Mit dem anhaltenden Wachstum der Modellintelligenz und der Nutzeranforderungen werden die Mängel dieses Vertrags jedoch deutlicher. Die fortschrittlichsten KI-Systeme von heute, die auf Code-First-Frameworks basieren, können aufgabenspezifische Workflows zusammenstellen, die jede Minute Tausende von Aktionen ausführen. Suchsysteme haben dieses Potenzial noch nicht vollständig ausgeschöpft.

Wir vermuten schon lange, dass die richtige Grenze für KI-native Suche weiter unten im Stack liegt. Modelle sollten nicht nur eine Suchmaschine aufrufen. Sie sollten in der Lage sein, die einzelnen Stücke des Such-Stacks nach Bedarf der spezifischen Aufgabe zu orchestrieren. Das erfordert eine grundlegend andere Architektur.

Die nächste Generation von Sucharchitekturen wird auf einem Kernprinzip basieren: Suche sollte von KI-Agenten nativ programmierbar sein. Ein Agent darf nicht auf eine Menge vordefinierter Such-Pipelines beschränkt sein. Vielmehr muss ein Agent in der Lage sein, die Pipeline, die die spezifische Aufgabe erfordert, unter Verwendung kombinierbarer Bausteine, die auf unterschiedlichen Abstraktionsebenen entworfen wurden, zu konstruieren.

Unsere neue Search as Code (SaC)-Architektur verkörpert dieses Prinzip. In SaC wird keine einzige Abrufoperation über eine Funktionsaufruf- oder MCP-Schnittstelle ausgelöst. Alle Operationen werden stattdessen über vom Modell generierten Python-Code orchestriert. Für die einfachsten Suchbedürfnisse kann dieser Code aus einer Handvoll Anfragen an einen High-Level-Suchendpunkt bestehen. Aber für komplexe Aufgaben kann der Code beliebig kompliziert sein und bedingte Ausführung, Asynchronität, Parallelität und Aufrufe an eine Vielzahl von Low-Level-Primitiven umfassen.

Die Search as Code (SaC)-Architektur stützt sich auf einen Stack bestehend aus Modellen, Rechen-Sandboxes und einem Agentic Search SDK, das auf der Suchinfrastruktur von Perplexity aufbaut.

SaC umfasst drei eng gekoppelte Schichten:

Modelle dienen als Steuerungsebene. Sie argumentieren über die Anweisungen des Nutzers (oder des übergeordneten Agenten), zerlegen die Anweisung in Aufgaben, entscheiden, welche Abruf- und Verarbeitungspipelines für jede Aufgabe erforderlich sind, und generieren Code, um diese Pipelines zu implementieren.

Rechen-Sandboxes bieten deterministische Berechnungen durch eine sichere Codeausführungs-Laufzeit. Sie bieten eine Leinwand für Modelle, um Kontrollfluss, Batching, Wiederholungsversuche, Filterung, Zusammenführung, Aggregation und andere deterministische Operationen zu implementieren.

Unser Agentic Search SDK legt den Such-Stack von Perplexity als kombinierbare Primitive offen. Es bietet Bausteine von Low-Level-Abrufoperationen bis hin zu semantischem High-Level-Parsing. Das SDK ist innerhalb der Ausführungslaufzeiten der Sandboxes eingebettet, was es Modellen ermöglicht, bis zu Tausende von Operationen innerhalb eines einzelnen Inferenz-Turns zu orchestrieren. Nachfolgend diskutieren wir unsere Designentscheidungen für jede Schicht.

Das Agentic Search SDK definiert die Bausteine für programmierbare Suche. Wichtig ist, dass unser SDK keine bereits existierende Such-API ist, die als Bibliothek verpackt wurde. Im Laufe der letzten Monate hat unser Engineering-Team unseren Such-Stack in modulare, kombinierbare Primitive umgestaltet. Wir haben das Agentic Search SDK gebaut, um direkten Zugriff auf diese Primitive zu bieten, was eine weitaus leistungsfähigere Leinwand schafft, auf der das Modell aufgabenspezifische Abruf-Pipelines orchestrieren kann.

High-Level End-zu-End-Such-Pipelines sind weiterhin innerhalb des SDK verfügbar, aber sie sind nicht mehr die einzige Option. Vielmehr dienen sie als eine Art Abkürzung für gängige Suchmuster. Das Modell steht es frei, diese zu nutzen oder zu umgehen, wie es die Aufgabe erfordert.

Wahl der Laufzeitumgebung: Wir haben Python, Rust, TypeScript und Bash als SDK-Laufzeit in Betracht gezogen. Wir vermuteten, dass Python die natürlichste Wahl wäre, angesichts seiner Allgegenwärtigkeit und seines Ökosystems an Datenverarbeitungsbibliotheken. Interne Tests bestätigten dies, und die Version des SDK, die heute eingeführt wird, basiert auf Python. Wir erwarten, die Wahl der Laufzeitumgebung regelmäßig neu zu bewerten, um sicherzustellen, dass sie weiterhin die beste Agenten-Erfahrung bietet.

Kontinuierliche Verbesserung durch Autoresearch: Wir haben die Konsumierbarkeit des SDK für Frontier-LLMs durch eine iterative Autoresearch-Schleife optimiert. Diese Schleife, die über Wochen hinweg kontinuierlich läuft, schlägt SDK-Verbesserungen basierend auf Metriken wie Latenz, Codegen-Qualität und Gesamt-Aufgabenleistung vor und validiert diese. Die Autoresearch-Schleife hat bereits zahlreiche Änderungen sowohl an der Struktur als auch an der Ästhetik des SDK vorgenommen, mit signifikanten Zugewinnen in allen Dimensionen. Wir planen, das SDK mittels Autoresearch weiter zu verfeinern, während neue Frontier-Modelle und Suchkomponenten aufkommen.

Sandboxes bieten sichere Umgebungen zum Definieren und Ausführen von SaC-Pipelines. Sie führen vom Modell generierten Code aus und bieten Zugriff auf das Agentic Search SDK, um die Interaktion mit individuellen Suchprimitiven zu erleichtern.

Wir haben erhebliche Investitionen in die Optimierung und Härtung unserer Sandboxes getätigt, und ihr übergeordnetes Systemdesign verdient einen eigenen Artikel. Hier konzentrieren wir uns auf die Designüberlegung, die für SaC am relevantesten ist: die Verwaltung von Zwischenzuständen.

SaC befähigt Agenten, komplexe Pipelines innerhalb eines einzelnen Inferenz-Turns zu orchestrieren. Bestimmte Zwischenzustände müssen jedoch über Turns hinweg übermittelt werden. Zum Beispiel möchte ein Modell vielleicht in Turn 1 einige Dokumente abrufen, in Turn 2 eine Stichprobe dieser Dokumente inspizieren, um zu entscheiden, was als Nächstes zu tun ist, und dann eine nachgelagerte Such-Pipeline entwickeln, um diese Dokumente ab Turn 3 weiter zu untersuchen. Wie oben diskutiert, ist das Übergeben von Zwischenzuständen über den Token-Raum keine effektive Strategie.

Wir haben zwei Ansätze zur Verwaltung von Zwischenzuständen über Turns hinweg in Betracht gezogen:

Persistentes Dateisystem + explizite Serialisierung/Deserialisierung (serde): Sandboxes können persistente Dateisysteme zur Verwendung durch Modelle über Turns hinweg bereitstellen. Modelle, die Zwischenzustand speichern möchten, können einen Serialisierungsschritt innerhalb des generierten Codes für einen Turn einfügen, zusammen mit einem Deserialisierungsschritt innerhalb eines nachfolgenden Turns (entweder zur Inspektion durch die Modelle selbst oder zur nachgelagerten Verwendung). Der Dateisystem-Ansatz erlaubt es Modellen, direkt und explizit zu steuern, wie Zwischenzustand über Turns hinweg übermittelt wird. Er stellt zudem die Rückverfolgbarkeit sicher, indem er die explizite Identifizierung und Speicherung von Informationen erzwingt, die vom Modell verwendet werden. Ein Nachteil ist die Latenz & Kontextbelastung durch das Generieren des Serde-Codes, obwohl gut entworfene Hilfsfunktionen diese Belastung mildern können.

REPL: Alternativ kann eine Sandbox die Ausführungslaufzeit selbst über Turns hinweg in einer REPL-artigen Umgebung beibehalten. Dies ermöglicht es Modellen, Zwischenzustand im Speicher zu halten, ohne ihn überhaupt serialisieren zu müssen, da Variablen, die in früheren Turns definiert oder geändert wurden, einfach in nachfolgenden Turns namentlich referenziert werden können. Der REPL-Ansatz ist token-effizienter, da er das Generieren von Serde-Code vermeidet. Der Mangel eines expliziten Serialisierungsschritts kann jedoch die nachgelagerte Leistung aus Gründen beeinträchtigen, die jedem bekannt sind, der mit einem 100-Zellen-Jupyter-Notebook gearbeitet hat: Wenn der Variablen-Namensraum unübersichtlich wird, wird es schwieriger, nachzuvollziehen, was genau über Turns hinweg gespeichert bleibt und warum.

Wir haben beide Ansätze getestet und festgestellt, dass, obwohl sie im gewöhnlichen Gebrauch ähnlich funktionieren, Dateisystem-basierte Serde eine bessere Zuverlässigkeit bei besonders langen Trajektorien bietet. Wir übernehmen daher Dateisystem-basierte Serde als unsere Lösung. Wir vermuten, dass die Anforderung an Modelle, Zustand deklarativ statt implizit zu übermitteln, ihnen hilft, diesen Zustand effektiver zu verwalten. Dies ist eine vorläufige Erkenntnis, und wir werden weiterhin an beiden Ansätzen iterieren.

Die Modelle, die Agenten-Frameworks antreiben, dienen als Steuerungsebene für SaC: Sie stellen dynamisch Such-Pipelines aus den Bausteinen des Agentic Search SDK zusammen, um den Anforderungen jeder Aufgabe gerecht zu werden, und versenden diese Pipelines dann als Code zur Sandbox-Ausführung.

Perplexity setzt eine Vielzahl von Modellen innerhalb unserer Agenten-Frameworks ein, und wir haben festgestellt, dass die neuesten Frontier-Modelle bei der allgemeinen Codegenerierung durchweg sehr effektiv sind. Die Hauptherausforderung besteht darin, eine effektive Codegenerierung speziell für das Agentic Search SDK zu induzieren. Das heißt, wie können wir Modelle dazu bringen, die Bausteine unseres SDKs effektiv zu aufgabenoptimierten Pipelines zu verweben?

Im Gegensatz zur Standardbibliothek einer Sprache ist es unwahrscheinlich, dass ein maßgeschneidertes SDK in Pretraining-Daten repräsentiert ist. Selbst mit den Verbesserungen der SDK-Konsumierbarkeit durch Autoresearch sind viele Modelle immer noch darauf trainiert, über Funktionsaufrufe und direkten MCP-Aufruf mit Suchsystemen zu interagieren. Es ist unwahrscheinlich, dass diese Modelle das SDK allein mit Quellcode und automatisch generierten Dokumenten fachmännisch handhaben.

Um diese Herausforderung zu lösen, haben wir hochgradig abgestimmte Agenten-Skills entwickelt, um Modellen beizubringen, unser SDK effektiv zu nutzen. Die ersten Versionen wurden gemäß den Designprinzipien von Perplexity für Skills entwickelt und dann durch eine dedizierte Autoresearch-Schleife optimiert, die sich auf dieselben Metriken konzentrierte, die auch bei der SDK-Optimierung verwendet wurden. Wir begrenzen auch die Skill-Größe, um uns gegen Kontext-Bloat zu schützen, und unsere endgültigen Versionen haben weniger als 2000 Token in ihren Root-SKILL.md-Dateien.

Die optimierten Skills gehen über das bloße Auflisten der verfügbaren Bausteine des SDK hinaus (etwas, das ebenso leicht über Laufzeitreflexion erhalten werden kann). Der Großteil der Token wird darauf verwendet, prägnante, verallgemeinerbare Anleitungen und Few-Shot-Beispiele für das Zusammensetzen dieser Blöcke zu komplexen Mustern bereitzustellen. Ausgestattet mit diesen Skills beobachten wir, wie Modelle das SDK effektiv nutzen, um Such-Pipelines zu orchestrieren, die auf Tausende von diskreten Operationen skalieren.

Durch die Kombination dieser Schichten verändert SaC die Beziehung zwischen Modellen und dem Such-Stack. In Suchsystemen mit festen Pipelines steht das Modell über der Suche und interagiert mit ihr über eine enge, serielle Anruferschnittstelle. In SaC wird das Modell zu einem aktiven Teilnehmer bei der Orchestrierung des Suchprozesses selbst. Alle Elemente des Such-Stacks werden direkt vom Modell programmierbar, wobei die Sandbox und das Agentic Search SDK die notwendigen Schnittstellen zu diesen Elementen bereitstellen.

Aber was ist mit Fähigkeiten, die nicht nativ existieren? Code ist ein mächtiges Medium zur Orchestrierung bereits bestehender Fähigkeiten. Doch die Macht des Codes geht über die Orchestrierung hinaus. Er kann auch als Lückenfüller für Fähigkeiten dienen, die im Such-Stack oder SDK nicht vorhanden sind. Agenten profitieren von Sparsamkeit, und es wäre ineffizient, wenn das SDK jede potenzielle Operation mit einer dedizierten Funktion abdecken würde. Stattdessen stellt das SDK die grundlegendsten Primitive bereit, und das Modell kann im laufenden Betrieb mit Code beliebige zusätzliche Komponenten bauen.

Betrachten wir zum Beispiel ein komplexes Regex, das nicht effizient über die eigene Abfragesyntax des Suchsystems implementierbar ist. Ohne Coding-Fähigkeiten wäre das Modell gezwungen, seine beste Annäherung zu generieren, eine Anfrage zu stellen und eine Filterung im Token-Raum auf einem sehr verrauschten Ergebnissatz durchzuführen. Mit SaC kann das Modell stattdessen ein Programm generieren, das parallele SDK-Aufrufe tätigt, um eine Obermenge des gewünschten Regex-Ergebnissatzes zu sammeln. Nach der Deduplizierung über das SDK kann das Modell dann zusätzlichen Code schreiben, um die Ergebnisse deterministisch auf das exakte Regex einzugrenzen. Auf diese Weise können Agenten benutzerdefinierte Suchfähigkeiten implementieren, ohne das SDK mit übermäßig nischigen Unterroutinen aufzublähen.

Wir präsentieren eine Fallstudie, die auf einer realen Aufgabe innerhalb unserer Test-Suite basiert. Diese Aufgabe bittet einen Agenten, über 200 hochkritische CVEs aus den Jahren 2023–2025 zu identifizieren und zu charakterisieren. Jeder Datensatz muss den eigenen Hinweis des betroffenen Anbieters zitieren, das Produkt und die Fix-Version benennen und zeigen, dass die Fix-Version mit der spezifischen CVE verknüpft ist.

Die Antwort von SaC erzielte 100 % Genauigkeit, wobei der gesamte Token-Verbrauch im Vergleich zur Nicht-SaC-Baseline um 85,1 % sank (von 288,7K Token auf 42,9K Token). Die getesteten Nicht-Perplexity-Systeme, die in Abschnitt 4 detaillierter diskutiert werden, erzielten alle weniger als 25 %.

Wir präsentieren drei stilisierte Codeblöcke aus der Trajektorie, um zu veranschaulichen, wie SaCs Programmierbarkeit es dem Modell ermöglicht, effektive Strategien zu implementieren.

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

Dieser erste Block ist reine Orchestrierung. Das generierte Programm beginnt damit, die Quellklassen-Regel direkt in den Abfrageplan zu kodieren: Nur anbieter-eigene Hinweissformate sind relevant. Nicht-Anbieter-Quellen einschließlich NVD, MITRE, CVE Details, Nachrichtenberichte, CERT-Seiten und Datenbanken von Drittanbietern sind strukturell außerhalb des Geltungsbereichs. Die Exakt-Phrasen-Beschränkungen drängen die Suche ebenfalls auf Seiten, deren indexierter Text bereits die präzisen CVE-Details enthält, die nachgelagert benötigt werden.

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

Der zweite Block verwendet ein LLM als intermediäre Planungsunterroutine. Der Code fasst zusammen, welche Anbieter-Jahr-Paare genügend Kandidatenseiten produzieren, bittet um gezielte Verfeinerungen und validiert jede vorgeschlagene Anfrage vor der Ausführung. Dies bewahrt nützliche Muster aus der Trajektorie, wie etwa standortbezogene Exakt-Phrasen-Sonden und adaptives Backfilling, ohne einen maßgeschneiderten CVE-Hinweis-Crawler fest in das SDK zu kodieren.

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

Der letzte Block ist ein Ergebnisverifizierer, dessen Logik vollständig vom Agenten via Codegen definiert wird. Während Such-Unterroutinen plausible Hinweis-Seiten finden können, erfordert die Aufgabe eine strengere Relation: Der Hinweis muss eine CVE an ein betroffenes Produkt und eine Fix-Version im vom Anbieter verfassten Text binden. Das Schema macht diese Relation explizit, sodass nachgelagerter Code nach CVE deduplizieren, Aggregator-URLs ablehnen, schwache Versionsnachweise verwerfen und mit dem Backfilling fortfahren kann, bis der Untergrenze der Datensatzanzahl erreicht ist.

Wir evaluieren die Effektivität von SaC auf einer umfassenden Benchmark-Suite, mit Fokus sowohl auf der absoluten Leistung als auch auf der Kosten-Leistungs-Grenze.

Unsere Benchmark-Suite umfasst insgesamt fünf Benchmarks, die darauf ausgelegt sind, suchabhängige KI-Workflows über eine Reihe von Domänen, Aufgabenformaten und Komplexitätsstufen hinweg zu stressen. Wir verwenden vier bereits existierende Benchmarks: DeepSearchQA (DSQA), BrowseComp, Humanity's Last Exam (HLE) und WideSearch. Für die ersten drei Benchmarks (DSQA, BrowseComp und HLE) berichten wir Genauigkeit als Topline-Metrik. Für WideSearch berichten wir den F1-Score nach Zeile.

Wir verwenden auch den neu entwickelten WANDR-Benchmark, der sich auf schwierige „Wide Research“-Aufgaben konzentriert, die eine sorgfältige Orchestrierung von Suche, Berechnung und Modellschlussfolgerungen erfordern. WANDR ist inspiriert von den wissensintensiven professionellen Aufgaben, die Perplexity Computer für Nutzer abwickelt. Er iteriert auf WideSearch und ähnlichen Benchmarks, betont jedoch komplexere Aufgaben und Aufgabenstrukturen. Wir werden den WANDR-Benchmark in den kommenden Wochen veröffentlichen.

Wir evaluieren fünf agentenbasierte Systeme. Wir betrachten individuelle Durchläufe statt „Best-of-N“-Scores, um die Leistung der zugrunde liegenden Architektur zu isolieren und nicht die Vorteile der Parallelisierung. Die Konfiguration jedes Systems wird nachfolgend beschrieben:

Perplexity (SaC): Wir evaluieren die SaC-Architektur innerhalb der produktiven Agent API von Perplexity. GPT 5.5 (hohe Argumentationsfähigkeit) dient als zugrunde liegendes Modell.

OpenAI: Wir evaluieren die OpenAI Responses API mit aktivierter Suche (web_search) und Python-Laufzeit (code_interpreter). GPT 5.5 (hohe Argumentationsfähigkeit) dient als zugrunde liegendes Modell.

Anthropic: Wir evaluieren Anthropic Managed Agents mit dem 20260401-Agenten-Toolset und automatisch erlaubten Befehlen. Opus 4.7 (hohe Argumentationsfähigkeit) dient als zugrunde liegendes Modell.

Exa: Wir evaluieren Exa Agent über die produktive API, mit der Aufwandsstufe auf „hoch“ gesetzt.

Parallel: Wir evaluieren Parallel Tasks über die produktive API, mit dem Prozessor auf „ultra4x“ gesetzt.

Tabelle 1 berichtet Benchmark-Scores für jedes System. SaC übertrifft alle anderen Systeme bei vier der fünf Benchmarks. Beim verbleibenden Benchmark (HLE) liegt SaC im Wesentlichen gleichauf mit OpenAI Responses auf dem ersten Platz. Abbildung 2 aus der Einführung visualisiert diese Scores in grafischer Form.

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

Tabelle 1 | Benchmark-Scores für jedes evaluierte System. Bester Score pro Zeile in Fettdruck.

Obwohl SaC eine hochmoderne Leistung über die Benchmark-Suite hinweg erreicht, ist sein Vorteil bei WANDR besonders ausgeprägt. Abbildung 5 schlüsselt die WANDR-Scores auf und zeigt, dass die SaC-Implementierung von Perplexity das nächstbeste System um den Faktor 2,5× übertrifft. Trotz dieses großen Abstands bleibt WANDR ungesättigt und erweist sich selbst für SaC als herausfordernd. Wir glauben, dass die komplexen, hochgradig horizontalen Such-Workflows, die für die Aufgaben von WANDR erforderlich sind, zusätzliche Fortschritte in Forschung und Such-Engineering erfordern werden, um eine konsistent hohe Leistung zu erzielen.

WANDR-Scores über evaluierte Systeme hinweg. Die Perplexity Agent API führt vor dem nächstbesten System mit einem Faktor von 2,5×.

Schließlich messen wir die relativen Zugewinne von SaC gegenüber einer traditionelleren Such-Pipeline, die dieselbe Suchinfrastruktur von Perplexity nutzt. Abbildung 6 berichtet den Unterschied in den Scores zwischen der SaC- und der Nicht-SaC-Architektur über jeden Benchmark hinweg. Durchweg bietet SaC einen wesentlichen Leistungsschub, mit dem größten absoluten Gewinn bei DSQA (+19,77 pp, 29 %) und dem größten relativen Gewinn bei WANDR (+12,00 pp, 45 %).

Perplexity-Baseline vs. SaC-Score bei jedem Benchmark, mit annotierten absoluten und relativen Deltas.

In der Praxis interessieren sich Nutzer für Leistung im Verhältnis zu Kosten. Wir evaluieren daher die Kosten-Leistungs-Grenze bei DSQA und WideSearch. Wir messen die Kosten und Leistung von SaC über niedrige, mittlere und hohe Modell-Argumentationsstufen hinweg, neben den anderen Systemen. Abbildungen 7 und 8 tragen den Benchmark-Score gegen den Preis pro Aufgabe auf, wobei die x-Achse umgekehrt ist, sodass Punkte weiter rechts billiger sind und Punkte weiter oben eine bessere Leistung darstellen.

DSQA-Score gegen Preis pro Aufgabe. Die gestrichelte Linie verbindet die SaC-Modell-Argumentationskonfigurationen.

Bei DSQA liegen alle drei SaC-Einstellungen an der oberen rechten Grenze. Die niedrige Argumentationseinstellung ist billiger als alle anderen Systeme, während sie besser abschneidet als zwei davon. Die mittlere Argumentationseinstellung übertrifft alle Nicht-SaC-Systeme bei unter 1 $ pro Aufgabe. Die hohe Argumentationseinstellung erzielt Spitzenleistung bei kompetitiven Kosten.

WideSearch-Score gegen Preis pro Aufgabe. Die gestrichelte Linie verbindet die SaC-Modell-Argumentationskonfigurationen.

WideSearch zeigt eine ähnlich geformte Grenze. Wie bei DSQA erreicht die niedrige Argumentationseinstellung eine kompetitive Leistung bei geringeren Kosten als alle Nicht-SaC-Systeme, während sowohl die mittlere als auch die hohe Argumentation bei der Aufgabenleistung die Nicht-SaC-Systeme übertreffen.

Search as Code spiegelt einen umfassenderen Wandel im Softwaredesign wider. Über Jahrzehnte hinweg waren Softwaresysteme um deterministische Anweisungen herum organisiert, die von traditionellen Laufzeiten auf CPUs ausgeführt wurden. Frontier-Modelle führen eine neue Form der Berechnung ein: Token-Raum-Argumentation, die Anweisungen sowohl befolgen als auch generieren kann. Die leistungsfähigsten Computersysteme werden diese zwei Arten der Berechnung kombinieren, anstatt zwischen ihnen zu wählen.

Die Suche ist ein natürliches Erprobungsfeld für diese Hybrid-Architektur. Modelle sind gut geeignet, um zu entscheiden, welche Beweise benötigt werden und wie Unsicherheit aufgelöst werden sollte. Deterministische Laufzeiten sind gut geeignet für Batching, Parallelität, Filterung, Ranking und Aggregation. Die Suchinfrastruktur dient als universelle E/A-Schicht und versorgt die Laufzeitumgebung mit nützlichen Griffen in das Weltwissen, die Tausende von Operationen pro Minute aufrechterhalten können. Wenn diese Teile integriert sind, ist das resultierende System bei der Erledigung realer Aufgaben weitaus leistungsfähiger und effizienter.

Jeder Teil dieser Architektur ist notwendig, um diese Fähigkeiten freizuschalten. Ohne intelligente Modelle kann das System nicht über Suchstrategien argumentieren. Ohne Sandboxes sind Modelle zu serieller E/A und ineffizienter Verarbeitung im Token-Raum gezwungen. Und ohne einen atomisierten Such-Stack hat das Modell nichts zu orchestrieren. SaC funktioniert, weil Argumentation, deterministische Berechnung und E/A gemeinsam darauf ausgelegt sind, die Stärken jeder Schicht zu betonen.

Dieses Co-Design kann durch die Entwicklung kontinuierlicher Verbesserungsschleifen noch weiter vorangetrieben werden. Zum Beispiel könnten das Agentic Search SDK und die SaC-Agenten-Skills gemeinsam in einer Autoresearch-Schleife optimiert werden. Ambitionierter ist es, Modelle darauf zu trainieren, die Vorteile von Low-Level-Suchprimitiven zu nutzen, die als SDK offenliegen. Man könnte sogar versuchen, das SDK-Design während des Modell-Trainingsprozesses selbst mitzuentwickeln. Wir freuen uns darauf, in zukünftigen Arbeiten aggressivere Co-Design-Strategien zu verfolgen.

Wir haben SaC gebaut, um Modellen zu ermöglichen, den Suchprozess zu steuern, anstatt dessen Ergebnisse lediglich zu konsumieren. Unsere Ergebnisse beweisen die Kraft dieser Kontrolle: SaC verbessert sowohl die absolute Leistung als auch die Kosten-Leistungs-Grenze bei wissensintensiven Agenten-Benchmarks. Wir freuen uns, die Fähigkeiten von SaC unseren Nutzern zugänglich zu machen, beginnend heute mit Perplexity Computer und der Agent API. Wir werden die SaC-Architektur weiterhin über alle Schichten des Stacks hinweg optimieren, um sicherzustellen, dass unsere Nutzer (und die Agenten, die ihnen dienen) über die leistungsfähigsten und effizientesten Suchfunktionen verfügen, die möglich sind.

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

Einführung

Die Starrheit der traditionellen Suche

Fehlermodi durch Starrheit

Design einer programmierbaren Sucharchitektur

Das Agentic Search SDK

Sandboxes

Modelle

Code als Orchestrator und Lückenfüller

Fallstudie: CVE-Anbieterhinweise

Evaluierungsergebnisse

Benchmarks und Systeme

Vergleichende Leistung

Kosten-Leistungs-Grenze

Auf dem Weg zu einer neuen Computer-Architektur

Zitierung