Perplexity przepisuje wyszukiwanie od podstaw. Search as Code to architektura, której modele AI od zawsze potrzebowały

Zapomnij o tym, jak wyszukiwarki działają dziś. Perplexity pokazało właśnie, że klasyczny model „zapytaj i dostań listę linków” to przeżytek, który nie przeżyje ery agentów AI. 1 czerwca 2026 roku firma opublikowała nową architekturę o nazwie Search as Code (SaC), która całkowicie zmienia relację między modelem językowym a silnikiem wyszukiwania. Nie ewolucja. Rewolucja.

Co to jest Search as Code i dlaczego to ważna zmiana

Przez dekady wyszukiwarki były projektowane z myślą o ludziach. Użytkownik wpisuje zapytanie, dostaje dziesięć linków, klika, czyta. Schemat prosty, sprawdzony, przewidywalny. Gdy pojawiły się modele językowe, zaczęły korzystać z wyszukiwarek dokładnie w ten sam sposób: wyślij zapytanie, odbierz wyniki, wstrzyknij do kontekstu. Monolityczna architektura, stały pipeline, zero kontroli nad tym, co dzieje się w środku.

Problem zaczął się wtedy, kiedy agenci AI zaczęli wykonywać zadania naprawdę złożone. Nie „co to jest fotosyneza”, ale „zidentyfikuj 200 luk bezpieczeństwa CVE z ostatnich dwóch lat i do każdej znajdź oficjalne advisory producenta z numerem patcha”. W Perplexity Computer, czyli własnym produkcie agentowym firmy, pojedyncze zadania wymagają już setek, a czasem tysięcy operacji wyszukiwania w ciągu kilku minut. To jest skala, przy której stary model po prostu się sypie.

SaC zmienia to fundamentalnie: zamiast wywoływać gotowy endpoint wyszukiwania, model generuje kod w Pythonie, który bezpośrednio orkiestruje poszczególne elementy stosu wyszukiwania. Nie „zapytaj wyszukiwarkę i dostań odpowiedź”. Model sam pisze program, który wie, gdzie szukać, jak szukać i co z wynikami zrobić.

Trzy warstwy, jeden pomysł

Architektura SaC opiera się na trzech warstwach:

• Model językowy jako centrum dowodzenia (control plane), który rozumie zadanie, rozkłada je na mniejsze kroki i generuje kod wyszukiwania
• Sandbox obliczeniowy jako bezpieczne środowisko wykonawcze dla generowanego kodu Pythona
• Agentic Search SDK jako zestaw narzędzi udostępniający poszczególne elementy infrastruktury wyszukiwania Perplexity bezpośrednio w kodzie

Podstawowe operacje, takie jak pobieranie, filtrowanie, deduplikacja i reranking, są dostępne jako proste funkcje SDK. Model nie musi już akceptować tego, co zwróci mu czarna skrzynka. Może sam zdecydować, że dla konkretnego zadania warto szukać równolegle w dwunastu różnych źródłach z precyzyjnymi wyrażeniami regularnymi, a wyniki zweryfikować osobnym wywołaniem modelu językowego.

Sam prezes Perplexity, Aravind Srinivas, tak podsumował zmianę w poście na X:

„We’re moving away from search as a web fetch tool call to search as codegen to be future proof in a world where code execution inside agent harnesses is the way to do almost all of our knowledge work.”

„Odchodzimy od traktowania wyszukiwania jako wywołania narzędzia web fetch w stronę wyszukiwania jako generowania kodu, by być gotowi na świat, w którym wykonywanie kodu wewnątrz agentów to sposób na niemal całą pracę z wiedzą.”

We’re moving away from search as a web fetch tool call to search as codegen to be future proof in a world where code execution inside agent harnesses is the way to do almost all of our knowledge work.

Doing this lets you compose multi-step primitives far more naturally and be… https://t.co/fGTGWUtcCh

— Aravind Srinivas (@AravSrinivas) June 1, 2026

Prawdziwy test: 200 luk bezpieczeństwa

Perplexity nie poprzestało na teorii. Przeprowadziło konkretny test na zadaniu z kategorii tych, które normalnie zajęłyby analitykowi bezpieczeństwa kilka dni. Agent miał zidentyfikować ponad 200 luk CVE o wysokiej krytyczności z lat 2023-2025, dla każdej znaleźć oficjalny raport producenta (nie MITRE, nie NVD, tylko advisory napisane przez firmę, której dotyczy problem) i potwierdzić, że wskazana wersja naprawcza faktycznie dotyczy konkretnego CVE.

SaC osiągnął 100% dokładności na tym zadaniu, jednocześnie redukując zużycie tokenów o 85,1% w porównaniu z klasyczną architekturą, z 288 700 do 42 900 tokenów. Każdy inny testowany system uzyskał wynik poniżej 25%.

Jak to możliwe? Agent wygenerował trzyetapowy program. Najpierw zbudował plan równoległych zapytań dostosowanych do tego, jak poszczególni producenci (Mozilla, Jenkins, Google Chrome, Android) formatują swoje biuletyny bezpieczeństwa. Potem sprawdził, które kombinacje producent-rok są słabo pokryte i wygenerował uzupełniające zapytania. Na końcu zweryfikował każdy wynik przez schemat strukturalny, upewniając się, że CVE, produkt i wersja naprawcza faktycznie do siebie pasują.

Komentarz redaktora

Perplexity trafiło w coś fundamentalnego. Problem, który rozwiązuje Search as Code, nie jest nowy. Każdy, kto budował agenta opartego na wyszukiwaniu, wie, jak frustrujące jest zderzenie z monolitycznym API: zwraca to, co jego pipeline uzna za stosowne, i nie masz żadnej kontroli nad tym procesem. SaC to odwrócenie tej logiki.

Ale zanim zacznę bić brawo, dwie rzeczy do przemyślenia. Po pierwsze: benchmarki opublikowało samo Perplexity. W tym jeden stworzony przez nie samo (WANDR), na którym wypadło 2,5 raza lepiej od konkurencji. To jest sygnał ostrzegawczy. Niezależna walidacja tych wyników powinna być warunkiem koniecznym przed wyciągnięciem poważnych wniosków. Po drugie: generowany kod to nowa powierzchnia ataku. Jeśli model pisze Python, który trafia do sandboxu i wywołuje API, to jakość tego kodu jest częścią granicy bezpieczeństwa systemu. Perplexity wspomina o tym mimochodem, ale myślę, że to jest poważniejszy temat, niż artykuł sugeruje.

Czy to zmieni rynek? Tak, jeśli zadziała tak, jak pokazano. I jeśli inni gracze zaczną udostępniać podobne SDK, bo model referencyjny będzie otwarty. Na razie Perplexity ma SDK tylko dla własnej infrastruktury. To jeszcze nie jest otwarta rewolucja.

Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl

Benchmarki: gdzie SaC bije konkurencję, a gdzie tylko remisuje

W zbiorczym teście obejmującym pięć benchmarków, SaC przewyższył wszystkie inne systemy na czterech z nich. Jedynym wyjątkiem był HLE (Humanity’s Last Exam), gdzie wynik Perplexity (0,612) był praktycznie remisem z OpenAI Responses (0,614). Na pozostałych benchmarkach różnice były wyraźne:

• DSQA: 0,871 vs. 0,733 (OpenAI) i 0,815 (Anthropic)
• BrowseComp: 0,805 vs. 0,720 (OpenAI) i 0,598 (Anthropic)
• WideSearch: 0,651 vs. 0,522 (OpenAI) i 0,590 (Anthropic)
• WANDR: 0,386 vs. 0,130 (OpenAI) i 0,152 (Anthropic)

Warto jednak pamiętać, że benchmark WANDR, na którym Perplexity osiągnęło tak spektakularną przewagę, został stworzony przez samo Perplexity i jego wyniki wymagają niezależnej walidacji. To nie dyskwalifikuje wyników, ale nakłada na nie naturalny asterisk.

Nie tylko wyszukiwanie: zmiana architektury AI

Perplexity patrzy na SaC szerzej niż jako na poprawkę do silnika wyszukiwania. Firma postrzega to jako element większego trendu: tradycyjne oprogramowanie opiera się na deterministycznych instrukcjach, modele frontier dodają rozumowanie w przestrzeni tokenów, a najpotężniejsze systemy łączą obie formy.

To jest trafna diagnoza. Model jest dobry w rozumieniu, co i dlaczego. Deterministyczny runtime jest dobry w batchowaniu, filtrowaniu, równoległości. Infrastruktura wyszukiwania łączy je z aktualną wiedzą o świecie. Kiedy te trzy warstwy są dobrze zaprojektowane razem, dostaje się coś, czego żadna z nich nie oferuje osobno.

CEO Srinivas podkreślał, że lepsze zdolności kodowania modeli frontier będą bezpośrednio przekładać się na lepszą orkiestrację wyszukiwania, tworząc coś w rodzaju koła zamachowego: silniejsze modele, lepsza jakość generowanego kodu wyszukiwania, lepsze wyniki.

SaC jest dostępne już teraz jako domyślna architektura w Perplexity Computer i przez Agent API. Perplexity zapowiedziało też, że w najbliższych tygodniach opublikuje benchmark WANDR jako otwarty zasób dla całej społeczności badawczej. Zobaczymy wtedy, czy wyniki się utrzymają.