Memikirkan Ulang Pencarian sebagai Pembuatan Kode

Pencarian adalah primitif inti untuk sistem AI. Model perintis semakin canggih setiap bulannya, tetapi mereka tetap memerlukan akses ke pengetahuan yang segar, akurat, dan terkurasi dengan baik dari dunia luar. Pencarian adalah cara utama bagi sistem AI untuk memanfaatkan pengetahuan tersebut, dan dengan demikian menjadi komponen fondasi dari setiap produk yang perlu menarik kesimpulan, mengambil tindakan, dan melakukan pekerjaan di dunia nyata.

Kami percaya bahwa alur kerja pencarian tradisional semakin ketinggalan zaman di era agen. Pencarian tradisional menjawab kueri, tetapi agen saat ini menyelesaikan tugas yang dapat mengambil bentuk yang tak terhitung jumlahnya. Tugas-tugas ini mengharuskan agen untuk menentukan strategi pengambilan khusus tugas langsung di dalam perangkat mereka. Di dalam Perplexity Computer, kami telah melihat satu tugas memanggil ratusan atau bahkan ribuan operasi pengambilan dalam beberapa menit: sebuah alur kerja yang mustahil bagi manusia tetapi sangat alami bagi agen.

Di dunia ini, pencarian itu sendiri harus menjadi bersifat agen, dengan blok penyusunannya dapat diakses langsung sebagai SDK di dalam perangkat agen. Kami memperkenalkan Search as Code (SaC) sebagai arsitektur pencarian referensi baru Perplexity.

Tumpukan pencarian Perplexity melayani ribuan kueri setiap detik di seluruh aplikasi dan Platform API kami. Pada bulan September 2025, kami menerbitkan tinjauan arsitektur pertama dari sistem pencarian kami. Inovasi konstan dalam sistem ini telah mendukung peluncuran penawaran baru seperti Search API, Agent API, dan Computer, dengan loop peningkatan mandiri yang mengoptimalkan tumpukan pencarian untuk melayani pengguna dengan lebih baik setiap harinya.

Secara tradisional, sistem AI telah memperlakukan pencarian sebagai monolit: model AI mengeluarkan kueri, mesin pencari menjalankan alur kerjanya yang telah ditentukan sebelumnya, dan model mengonsumsi hasilnya sebagai konteks. Sebagian besar, ini bekerja dengan baik untuk mengatasi kebutuhan pengguna AI awal. Mengingat kesederhanaan relatif dari permintaan mereka, tidak ada alasan untuk khawatir tentang bagaimana persisnya alur kerja pencarian dirancang, atau apakah arsitektur alur kerja tersebut optimal untuk tugas yang ada. Pengaturan bawaan dianggap sudah cukup, begitu pula antarmuka bawaan (pemanggilan fungsi dan MCP).

Arsitektur pencarian tradisional mengekspos satu sistem tetap yang dipanggil oleh model secara berurutan, sementara Search as Code mengekspos primitif pencarian teratomisasi yang disusun oleh agen melalui kode yang dihasilkan.

Namun saat ini pendekatan ini semakin ketinggalan zaman setiap bulannya. Pengguna menuntut lebih banyak dari sekadar analisis sekali tembak dari AI. Mereka mengharapkan agen untuk menyelesaikan tugas ujung-ke-ujung selama berjam-jam atau bahkan berhari-hari. Tugas-tugas ini bisa jadi kompleks, terbuka, dan sangat bervariasi dalam kebutuhan informasinya, dan arsitektur monolitik runtuh di bawah beban tuntutan ini.

Keterbatasan utama pada akhirnya adalah masalah kendali. Model perintis sudah cukup baik dalam bernalar atas konteks tetap. Namun, sistem AI yang paling kuat akan memerlukan kemampuan untuk mengarahkan bagaimana konteks tersebut diambil, diproses, diegritasi, dan disajikan kepada model.

Sistem pencarian tradisional tidak dirancang dengan tingkat keterkendalian seperti ini. Bagaimanapun juga, pengguna manusia tidak dapat diharapkan untuk melakukan kendali yang sangat rinci atas bagian internal alur kerja pencarian meskipun itu ditawarkan. Model AI awal dapat mengontrol pencarian hanya melalui lintasan linier pemanggilan fungsi dan MCP. Namun model perintis saat ini, yang didorong oleh perangkat agen yang mampu menghasilkan kode, dapat mengerahkan kendali terperinci atas setiap primitif komputasi yang dapat dibayangkan melalui kode komputer. Tugas kita adalah menyediakan primitif yang tepat.

Untuk memenuhi kebutuhan ini, kami memperkenalkan arsitektur pencarian baru di seluruh produk kami: Search as Code (SaC). Arsitektur baru ini memberdayakan model untuk masuk ke dalam tumpukan pencarian itu sendiri alih-alih sekadar mengonsumsi hasil akhirnya. Ide intinya sederhana: kami mengekspos komponen dari tumpukan pencarian sebagai primitif di dalam SDK. Untuk setiap permintaan yang memerlukan pencarian, model merakit primitif ini sesuai permintaan ke dalam alur kerja pengambilan yang disesuaikan dengan permintaan spesifik tersebut.

Perakitan alur kerja ini dilakukan melalui pembuatan dan eksekusi kode di dalam kotak pasir yang aman. Tidak seperti pendekatan berbasis pembuatan kode lainnya untuk pencarian, kami tidak hanya menempatkan API pencarian tradisional di dalam cangkang atau waktu proses bahasa. Sebaliknya, kami telah merancang dengan cermat SDK Pencarian Agen yang mengekspos blok penyusun pencarian individual pada tingkat atomik semaksimal mungkin.

Search as Code (SaC) memajukan batas kinerja pencarian agen di berbagai rangkaian tolok ukur.

Berbekal blok penyusun ini, SaC memberi model kendali langsung atas setiap langkah pencarian individual: pengambilan, pemeringkatan, pemfilteran, percabangan, perenderan, dan banyak lagi. Ini juga memberi model akses efisien ke status menengah seperti daftar kandidat dan sinyal pemeringkatan. Bersama-sama, dua tuas kendali dan keterbacaan ini memungkinkan agen untuk merancang alur kerja pencarian khusus yang mencakup ribuan operasi pengambilan, mengoptimalkan alur kerja tersebut saat berjalan, dan hanya mengonsumsi informasi yang paling berguna sebagai konteks model.

Artikel ini menjelaskan motivasi, desain, dan implementasi SaC, beserta hasil empiris pada tolok ukur yang sudah ada maupun yang baru. SaC menetapkan batas biaya-kinerja baru untuk pencarian agen, dan kami sangat senang membagikannya kepada para pengguna kami dan komunitas AI yang lebih luas.

Mesin pencari pertama di dunia dibangun untuk pengguna manusia. Pengguna ini mengharapkan pengalaman yang dapat diprediksi, biasanya terdiri dari sejumlah dokumen berperingkat relevansi yang tetap. Pengguna tidak ingin mengatur proses pencarian secara mikro; mereka ingin memasukkan kueri dan menemukan hasil yang berguna.

Hasilnya, mesin pencari yang menghadap manusia menyatu pada arsitektur monolitik yang umum, yang diarahkan untuk menghasilkan halaman hasil mesin pencari (SERP) yang ramah manusia yang berisi n hit teratas untuk kueri masukan. Pola ini telah mendukung kemajuan dekade dalam pencarian konsumen. Ini cepat, akrab, dan sangat efektif untuk penjelajahan manusia.

Kemudian muncullah LLM, dan sistem AI juga menjadi konsumen pencarian. Perplexity memelopori pergeseran ini dengan peluncuran mesin jawaban kami pada tahun 2022. Sejak saat itu, upaya teknik pencarian kami berfokus pada cara mengoptimalkan nilai hasil pencarian untuk model AI. Untuk membangun AI yang paling akurat dan andal di dunia, kami harus merekayasa sistem pencarian yang berfokus pada membuat setiap token sepadat informasi mungkin. Inovasi yang dihasilkan dalam pengambilan sub-dokumen, efisiensi konteks, pemahaman semantik, dan area kunci lainnya menyebabkan peningkatan dramatis dalam kemampuan sistem AI untuk mengambil dan menindaklanjuti informasi.

Namun, bahkan sistem yang dioptimalkan untuk AI sebagian besar telah mewarisi kontrak fundamental yang sama seperti mesin pencari tradisional: menerima kueri, menjalankan alur kerja pencarian yang telah ditentukan sebelumnya, mengembalikan kumpulan hasil yang diproses sepenuhnya. Untuk permintaan sederhana, pendekatan ini bekerja dengan baik. Tetapi untuk permintaan yang lebih kompleks, ini menjadi hambatan yang semakin membatasi yang menurunkan kinerja, latensi, dan biaya.

Sistem pencarian tradisional memaksa alur kerja agen untuk mengurutkan pencarian melalui giliran yang terlihat oleh model. Model harus secara berulang memanggil alur kerja pencarian yang sama di berbagai parameter kueri dan memasukkan semua hasil ke dalam konteks model.

Alur kerja pencarian tradisional dirancang di sekitar satu titik kendali: parameter kueri. Mesin pencari memiliki sisa alur kerja sesuai dengan logika yang telah ditentukan sebelumnya, dan model harus beradaptasi dengannya. Bagi model, apa pun di hilir dari parameter kueri bersifat kaku—bentuk komputasi aktual berada di luar kendali model.

Ini adalah batasan yang masuk akal ketika konsumennya adalah manusia yang memindai tautan. Ini adalah batasan yang buruk ketika konsumennya adalah model AI yang mencoba memodelkan tugas intensif pengetahuan dalam lingkaran tertutup. Menurut pengalaman kami, kekakuan ini menciptakan tiga mode kegagalan yang berulang:

Konteks kasar. Model AI sensitif terhadap kualitas dan kekompakan konteks. Baik kualitas maupun kekompakan sangat bergantung pada kueri, dan alur kerja pencarian monolitik tidak dirancang untuk tampil secara optimal di semua kueri. Misalnya, jika model memerlukan satu bagian informasi yang sangat bedah tetapi hanya memiliki akses ke titik akhir pencarian ujung-ke-ujung yang memprioritaskan perolehan kembali, menggunakan titik akhir tersebut akan memasukkan sejumlah besar informasi yang tidak relevan ke dalam konteks model. Di sisi lain, jika model memerlukan banyak potongan informasi yang masing-masing memerlukan strategi pencarian yang berbeda, model tersebut mungkin terpaksa memanggil secara serial alur kerja suboptimal yang sama untuk semuanya, yang menghasilkan biaya yang membengkak dan konteks yang bising.

Kegagalan untuk memanfaatkan pengetahuan domain. Dalam banyak kasus, model mungkin memiliki pengetahuan domain (dari pelatihannya, Skill Agen, memori, atau token sebelumnya dalam lintasan LLM) yang harus memandu strategi pencarian. Namun, antarmuka pencarian yang kaku mencegah model memanfaatkan pengetahuan tersebut. Misalnya, model dapat menyadari untuk permintaan tertentu bahwa ia harus memadukan sinyal leksikal dan semantik dengan cara tertentu, memprioritaskan sumber tertentu, atau menggabungkan hasil berdasarkan kunci tertentu. Kecuali wawasan tersebut kebetulan dapat diimplementasikan melalui parameter kueri, model tidak dapat benar-benar bertindak atas wawasan tersebut.

Alur kendali yang tidak efisien dan polusi konteks. Banyak alur kerja pencarian tidak bersifat serial secara alami. Mereka mungkin memerlukan percabangan atas varian kueri, pengambilan paralel, deduplikasi, dan operasi lain yang memerlukan alur kendali non-linier dan asinkron. Memaksa langkah-langkah ini melalui giliran model berulang menambah latensi dan membuat alur kerja lebih sulit untuk dioptimalkan. Ini juga mencemari konteks model dengan status menengah bising yang mungkin tidak berguna untuk penalaran model, yang menghasilkan kinerja yang lebih buruk dan pemadatan yang lebih sering.

Tidak banyak yang dapat dilakukan mengenai tantangan ini selama era pemanggilan fungsi & MCP dari AI. Ketika setiap operasi pencarian memerlukan perjalanan pulang pergi sendiri ke inferensi LLM, pengembang secara alami lebih suka menyelesaikan sebanyak mungkin dalam perjalanan pulang pergi tersebut. Ini berarti alur kerja pencarian ujung-ke-ujung yang mengembalikan kumpulan hasil yang diproses sepenuhnya untuk dikonsumsi langsung oleh model.

Hasilnya, sebagian besar sistem pencarian yang menghadap AI saat ini masih beroperasi di bawah kontrak monolitik ini. Namun, dengan pertumbuhan berkelanjutan dalam kecerdasan model dan tuntutan pengguna, kekurangan dari kontrak tersebut menjadi lebih jelas. Sistem AI paling canggih saat ini, yang dibangun di atas perangkat yang dipimpin kode, dapat menyusun alur kerja khusus tugas yang mengeksekusi ribuan tindakan setiap menit. Sistem pencarian belum sepenuhnya menyadari potensi ini.

Kami telah lama menduga bahwa batasan yang tepat untuk pencarian asli AI berada lebih rendah di tumpukan. Model seharusnya tidak hanya memanggil mesin pencari. Mereka harus dapat mengatur bagian individual dari tumpukan pencarian sesuai tuntutan tugas khusus. Itu memerlukan arsitektur yang secara fundamental berbeda.

Generasi berikutnya dari arsitektur pencarian akan bergantung pada prinsip inti: pencarian harus dapat diprogram secara asli oleh agen AI. Agen tidak boleh dibatasi pada sekumpulan alur kerja pencarian yang telah ditentukan sebelumnya. Sebaliknya, agen harus dapat membangun alur kerja yang diperlukan oleh tugas khusus, menggunakan blok penyusun yang dapat disusun yang dirancang pada berbagai tingkat abstraksi.

Arsitektur Search as Code (SaC) baru kami mewujudkan prinsip ini. Dalam SaC, tidak ada satu pun operasi pengambilan yang dikirimkan melalui antarmuka pemanggilan fungsi atau MCP. Sebagai gantinya, semua operasi diatur melalui kode Python yang dihasilkan model. Untuk kebutuhan pencarian paling sederhana, kode ini mungkin terdiri dari beberapa permintaan ke titik akhir pencarian tingkat tinggi. Tetapi untuk tugas yang kompleks, kode tersebut bisa rumit sesuai kebutuhan, yang melibatkan eksekusi bersyarat, asinkronisitas, paralelisme, dan panggilan ke berbagai macam primitif tingkat rendah.

Arsitektur Search as Code (SaC) mengandalkan tumpukan yang terdiri dari model, kotak pasir komputasi, dan SDK Pencarian Agen yang berada di atas infrastruktur pencarian Perplexity.

SaC melibatkan tiga lapisan yang digabungkan erat:

Model berfungsi sebagai bidang kendali. Mereka bernalar tentang arahan pengguna (atau agen induk), memecah arahan menjadi tugas-tugas, memutuskan pengambilan dan alur kerja pemrosesan mana yang diperlukan untuk setiap tugas, dan menghasilkan kode untuk mengimplementasikan alur kerja tersebut.

Kotak pasir komputasi menyediakan komputasi deterministik melalui waktu proses eksekusi kode yang aman. Mereka menyediakan kanvas bagi model untuk mengimplementasikan alur kendali, pengelompokan, percobaan ulang, pemfilteran, penggabungan, agregasi, dan operasi deterministik lainnya.

SDK Pencarian Agen kami mengekspos tumpukan pencarian Perplexity sebagai primitif yang dapat disusun. Ini menyediakan blok penyusun dari operasi pengambilan tingkat rendah hingga penguraian semantik tingkat tinggi. SDK disematkan dalam waktu proses eksekusi kotak pasir, yang memungkinkan model untuk mengatur hingga ribuan operasi dalam satu giliran inferensi. Di bawah ini, kami mendiskusikan keputusan desain kami untuk setiap lapisan.

SDK Pencarian Agen mendefinisikan blok penyusun untuk pencarian yang dapat diprogram. Yang penting, SDK kami bukanlah API pencarian yang sudah ada sebelumnya yang dikemas sebagai pustaka. Selama beberapa bulan terakhir, tim teknik kami telah merearchiteki tumpukan pencarian kami menjadi primitif yang modular dan dapat disusun. Kami telah membangun SDK Pencarian Agen untuk menyediakan akses langsung ke primitif ini, yang menghasilkan kanvas yang jauh lebih kuat tempat model dapat mengatur alur kerja pengambilan khusus tugas.

Alur kerja pencarian ujung-ke-ujung tingkat tinggi masih tersedia di dalam SDK, tetapi itu bukan lagi satu-satunya pilihan. Sebaliknya, mereka berfungsi sebagai bentuk singkatan untuk pola pencarian umum. Model bebas menggunakan atau melewati mereka sesuai tuntutan tugas.

Pilihan waktu proses: Kami mempertimbangkan Python, Rust, TypeScript, dan Bash sebagai waktu proses SDK. Kami menduga bahwa Python akan menjadi yang paling pas mengingat keberadaannya di mana-mana dan ekosistem pustaka pemrosesan datanya. Pengujian internal mengonfirmasi hal ini, dan versi SDK yang diluncurkan hari ini berbasis Python. Kami berharap dapat mengevaluasi ulang pilihan waktu proses secara berkala untuk memastikan bahwa ia terus memberikan pengalaman agen terbaik.

Perbaikan berkelanjutan melalui penelusuran mandiri: Kami juga telah mengoptimalkan keterkonsumsian SDK untuk LLM perintis melalui loop penelusuran mandiri iteratif. Loop ini, yang berjalan terus menerus selama berminggu-minggu, mengusulkan dan memvalidasi peningkatan SDK terhadap metrik termasuk latensi, kualitas pembuatan kode, dan kinerja tugas secara keseluruhan. Loop penelusuran mandiri telah membuat banyak perubahan pada struktur dan estetika SDK, dengan peningkatan signifikan di semua dimensi. Kami berencana untuk lebih menyempurnakan SDK melalui penelusuran mandiri saat model perintis baru dan komponen pencarian muncul.

Kotak pasir menyediakan lingkungan yang aman untuk mendefinisikan dan menjalankan alur kerja SaC. Mereka mengeksekusi kode yang dihasilkan model, menyediakan akses ke SDK Pencarian Agen untuk memfasilitasi interaksi dengan primitif pencarian individual.

Kami telah melakukan investasi signifikan dalam mengoptimalkan dan memperkuat kotak pasir kami, dan desain sistem menyeluruh mereka layak mendapatkan artikel tersendiri. Di sini, kami fokus pada pertimbangan desain yang paling relevan dengan SaC: mengelola status menengah.

SaC memberdayakan agen untuk mengatur alur kerja yang kompleks dalam satu giliran inferensi. Namun, status menengah tertentu perlu disampaikan di seluruh giliran. Misalnya, model mungkin ingin mengambil beberapa dokumen pada giliran 1, memeriksa sub-sampel dokumen tersebut pada giliran 2 untuk memutuskan apa yang harus dilakukan selanjutnya, dan kemudian mengembangkan alur kerja pencarian hilir untuk menyelidiki lebih lanjut dokumen tersebut dari giliran 3 dan seterusnya. Seperti dibahas di atas, meneruskan status menengah melalui ruang token bukanlah strategi yang efektif.

Kami mempertimbangkan dua pendekatan untuk mengelola status menengah di seluruh giliran:

Sistem file persisten + serde eksplisit: Kotak pasir dapat mengekspos sistem file persisten untuk digunakan model di seluruh giliran. Model yang ingin mempertahankan status menengah dapat menyertakan langkah serialisasi dalam kode yang dihasilkan untuk sebuah giliran, beserta langkah deserialisasi dalam giliran berikutnya (baik untuk pemeriksaan model sendiri maupun untuk penggunaan hilir). Pendekatan sistem file memungkinkan model untuk secara langsung dan eksplisit mengontrol bagaimana status menengah disampaikan di seluruh giliran. Ini juga memastikan keterlacakan dengan menegakkan identifikasi eksplisit dan persistensi informasi yang digunakan oleh model. Salah satu kelemahannya adalah latensi & overhead konteks yang terjadi akibat menghasilkan kode serde, meskipun fungsi utilitas yang dirancang dengan baik dapat mengurangi overhead ini.

REPL: Sebagai alternatif, kotak pasir dapat mempertahankan waktu proses eksekusi itu sendiri di seluruh giliran dalam lingkungan bergaya REPL. Ini memungkinkan model untuk mempertahankan status menengah di dalam memori tanpa harus menyerialisasikannya sama sekali, karena variabel yang didefinisikan atau dimodifikasi dalam giliran sebelumnya dapat dengan mudah direferensikan dengan nama di giliran berikutnya. Pendekatan REPL lebih efisien token karena menghindari kebutuhan untuk menghasilkan kode serde. Namun, kurangnya langkah serialisasi eksplisit dapat merugikan kinerja hilir karena alasan yang akrab bagi siapa saja yang bekerja dengan buku catatan Jupyter 100 sel: saat namespace variabel menjadi berantakan, menjadi lebih sulit untuk melacak apa persisnya yang dipertahankan di seluruh giliran dan mengapa.

Kami menguji kedua pendekatan tersebut dan menemukan bahwa meskipun kinerjanya serupa dalam penggunaan biasa, serde berbasis sistem file memberikan keandalan yang lebih baik pada lintasan yang sangat panjang. Oleh karena itu, kami mengadopsi serde berbasis sistem file sebagai solusi kami. Kami menduga bahwa mengharuskan model untuk menyampaikan status secara deklaratif alih-alih secara implisit membantu mereka mengelola status tersebut dengan lebih efektif. Ini adalah temuan sementara dan kami akan terus mengulangi kedua pendekatan tersebut.

Model yang mendukung perangkat agen berfungsi sebagai bidang kendali SaC: secara dinamis merakit alur kerja pencarian dari blok penyusun SDK Pencarian Agen untuk memenuhi kebutuhan setiap tugas, kemudian mengirimkan alur kerja tersebut sebagai kode untuk eksekusi kotak pasir.

Perplexity mempekerjakan berbagai model di dalam perangkat agen kami, dan kami mendapati model perintis terbaru cukup efektif secara menyeluruh dalam pembuatan kode tujuan umum. Tantangan utamanya adalah memicu pembuatan kode yang efektif khusus untuk SDK Pencarian Agen. Yaitu, bagaimana kita dapat membuat model berhasil merajut bersama blok penyusun SDK kita ke dalam alur kerja yang dioptimalkan tugas?

Tidak seperti pustaka standar bahasa, SDK yang dibuat khusus tidak mungkin direpresentasikan dalam data pra-pelatihan. Bahkan dengan peningkatan konsumabilitas SDK dari penelusuran mandiri, banyak model yang masih dilatih untuk berinteraksi dengan sistem pencarian melalui pemanggilan fungsi dan pemanggilan MCP langsung. Model-model ini tidak mungkin secara ahli menggunakan SDK dengan kode sumber dan dokumentasi yang dihasilkan otomatis saja.

Untuk mengatasi tantangan ini, kami telah mengembangkan Skill Agen yang sangat disetel untuk mengajari model cara memanfaatkan SDK kami secara efektif. Versi awal dikembangkan sesuai dengan prinsip desain Perplexity untuk Skill, dan kemudian dioptimalkan melalui loop penelusuran mandiri berdedikasi yang berfokus pada metrik yang sama yang digunakan dalam optimasi SDK. Kami juga membatasi ukuran skill untuk mengantisipasi pembengkakan konteks, dan versi akhir kami memiliki kurang dari 2000 token di file akar SKILL.md mereka.

Skill yang dioptimalkan lebih dari sekadar mencantumkan blok penyusun SDK yang tersedia (sesuatu yang dapat diperoleh dengan mudah melalui refleksi waktu proses). Sebagian besar token dihabiskan untuk memberikan panduan yang ringkas dan dapat digeneralisasikan serta contoh sedikit tembakan untuk menyusun blok-blok ini menjadi pola yang kompleks. Berbekal Skill ini, kami mengamati model secara efektif memanfaatkan SDK untuk mengatur alur kerja pencarian yang berskala hingga ribuan operasi diskrit.

Dengan menggabungkan lapisan-lapisan ini, SaC mengubah hubungan antara model dan tumpukan pencarian. Dalam sistem pencarian alur kerja tetap, model berada di atas pencarian dan berinteraksi dengannya melalui antarmuka pemanggil serial yang sempit. Dalam SaC, model menjadi partisipan aktif dalam mengatur proses pencarian itu sendiri. Semua elemen tumpukan pencarian menjadi dapat diprogram secara langsung oleh model, dengan kotak pasir dan SDK Pencarian Agen menyediakan antarmuka yang diperlukan untuk elemen-elemen tersebut.

Tetapi bagaimana dengan kemampuan yang tidak ada secara asli? Kode adalah media yang kuat untuk mengatur kemampuan yang sudah ada sebelumnya. Namun kekuatan kode lebih dari sekadar orkestrasinya. Kode juga dapat berfungsi sebagai pengisi kesenjangan untuk kemampuan yang tidak ada dalam tumpukan pencarian atau SDK. Agen mendapat manfaat dari parsimoni, dan tidak efisien bagi SDK untuk mencakup setiap potensi operasi dengan fungsi berdedikasi. Sebagai gantinya, SDK menyediakan primitif paling mendasar, dan model dapat membangun komponen tambahan apa pun dengan cepat menggunakan kode.

Pertimbangkan, misalnya, regex kompleks yang tidak dapat diimplementasikan secara efisien melalui sintaks kueri sistem pencarian itu sendiri. Tanpa kemampuan pengodean, model akan dipaksa untuk menghasilkan perkiraan terbaiknya, membuat kueri, dan melakukan pemfilteran ruang token pada kumpulan hasil yang sangat bising. Dengan SaC, model dapat menghasilkan program yang membuat panggilan SDK paralel untuk mengumpulkan supersepset dari kumpulan hasil regex yang diinginkan. Setelah deduplikasi melalui SDK, model kemudian dapat menulis kode tambahan untuk mempersempit hasil secara deterministik ke regex yang tepat. Dengan cara ini, agen dapat mengimplementasikan kemampuan pencarian kustom tanpa membuat SDK membengkak dengan subrutin yang terlalu khusus.

Kami menyajikan studi kasus berdasarkan tugas dunia nyata dalam rangkaian pengujian kami. Tugas ini meminta agen untuk mengidentifikasi dan mencirikan lebih dari 200 CVE keparahan tinggi dari 2023–2025. Setiap catatan harus mengutip saran dari vendor yang terkena dampak, menyebutkan produk dan versi perbaikan, dan menunjukkan bahwa versi perbaikan tersebut terikat pada CVE tertentu.

Jawaban SaC mencetak skor 100% pada akurasi, dengan total penggunaan token turun 85.1% relatif terhadap garis dasar non-SaC (dari 288.7K token menjadi 42.9K token). Sistem non-Perplexity yang diuji, yang dibahas secara lebih rinci di Bagian 4, semuanya mencetak skor lebih rendah dari 25%.

Kami menyajikan tiga blok kode bergaya dari lintasan untuk mengilustrasikan bagaimana keterprograman SaC memungkinkan model untuk mengimplementasikan strategi yang efektif.

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

Blok pertama ini adalah orkestrasian murni. Program yang dihasilkan dimulai dengan mengenkode aturan kelas sumber langsung ke dalam rencana kueri: hanya format saran milik vendor yang relevan. Sumber non-vendor termasuk NVD, MITRE, CVE Details, berita, halaman CERT, dan database pihak ketiga secara struktural berada di luar cakupan. Batasan frasa persis juga mendorong pencarian ke halaman yang teks terindeksnya sudah berisi detail CVE tepat yang diperlukan di hilir.

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

Blok kedua menggunakan LLM sebagai subrutin perencanaan menengah. Kode tersebut merangkum pasangan vendor-tahun mana yang menghasilkan halaman kandidat yang cukup, meminta penyempurnaan yang ditargetkan, dan memvalidasi setiap usulan kueri sebelum dieksekusi. Ini mempertahankan pola berguna dari lintasan, seperti penyelidikan frasa persis yang dicakup situs dan pengisian ulang adaptif, tanpa melakukan pengodean keras perayap saran CVE khusus ke dalam SDK.

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

Blok terakhir adalah verifikator hasil yang logikanya sepenuhnya didefinisikan oleh agen melalui pembuatan kode. Sementara subrutin pencarian dapat menemukan halaman saran yang masuk akal, tugas tersebut memerlukan hubungan yang lebih ketat: saran tersebut harus mengikat satu CVE ke satu produk yang terkena dampak dan satu versi perbaikan dalam teks yang ditulis oleh vendor. Skema tersebut membuat hubungan itu eksplisit, sehingga kode hilir dapat melakukan deduplikasi berdasarkan CVE, menolak URL agregator, membuang bukti versi yang lemah, dan terus mengisi ulang hingga batas bawah jumlah catatan terpenuhi.

Kami mengevaluasi efektivitas SaC pada rangkaian tolok ukur yang komprehensif, dengan fokus pada kinerja mutlak dan batas biaya-kinerja.

Rangkaian tolok ukur kami terdiri dari lima tolok ukur secara total, yang dirancang untuk menguji tegangan alur kerja AI yang bergantung pada pencarian di berbagai domain, format tugas, dan tingkat kerumitan. Kami menggunakan empat tolok ukur yang sudah ada: DeepSearchQA (DSQA), BrowseComp, Humanity's Last Exam (HLE), dan WideSearch. Untuk tiga tolok ukur pertama (DSQA, BrowseComp, dan HLE), kami melaporkan akurasi sebagai metrik utama. Untuk WideSearch, kami melaporkan skor F1 berdasarkan baris.

Kami juga menggunakan tolok ukur WANDR yang baru dikembangkan, yang berfokus pada tugas “penelitian luas” yang sulit yang memerlukan orkestrasian cermat atas pencarian, komputasi, dan penalaran model. WANDR terinspirasi oleh tugas profesional intensif pengetahuan yang ditangani oleh Perplexity Computer untuk pengguna. Ini mengulangi WideSearch dan tolok ukur serupa, tetapi menekankan tugas dan struktur tugas yang lebih kompleks. Kami akan menerbitkan tolok ukur WANDR dalam beberapa minggu mendatang.

Kami mengevaluasi lima sistem berbasis agen. Kami mempertimbangkan eksekusi individual alih-alih skor “terbaik dari N” untuk mengisolasi kinerja arsitektur mendasar alih-alih manfaat dari paralelisasi. Konfigurasi setiap sistem dijelaskan di bawah ini:

Perplexity (SaC): Kami mengevaluasi arsitektur SaC dalam Agent API produksi Perplexity. GPT 5.5 (penalaran tinggi) berfungsi sebagai model mendasar.

OpenAI: Kami mengevaluasi OpenAI Responses API dengan pencarian (web_search) dan waktu proses Python (code_interpreter) yang diaktifkan. GPT 5.5 (penalaran tinggi) berfungsi sebagai model mendasar.

Anthropic: Kami mengevaluasi Anthropic Managed Agents dengan perangkat alat agen 20260401 dan perintah yang diizinkan otomatis. Opus 4.7 (penalaran tinggi) berfungsi sebagai model mendasar.

Exa: Kami mengevaluasi Exa Agent melalui API produksi, dengan upaya diatur ke tinggi.

Parallel: Kami mengevaluasi Parallel Tasks melalui API produksi, dengan pemroses diatur ke ultra4x.

Tabel 1 melaporkan skor tolok ukur untuk setiap sistem. SaC unggul atas semua sistem lain pada empat dari lima tolok ukur. Pada tolok ukur yang tersisa (HLE), SaC pada dasarnya seri untuk tempat pertama dengan OpenAI Responses. Gambar 2 dari Pendahuluan memvisualisasikan skor ini dalam bentuk grafis.

Tolok Ukur	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 | Skor tolok ukur untuk setiap sistem yang dievaluasi. Skor terbaik per baris dicetak tebal.

Meskipun SaC mencapai kinerja canggih di seluruh rangkaian tolok ukur, keunggulannya sangat menonjol pada WANDR. Gambar 5 merinci skor WANDR, menunjukkan bahwa implementasi SaC Perplexity mengungguli sistem terbaik berikutnya dengan faktor 2.5×. Terlepas dari margin yang besar ini, WANDR tetap tidak jenuh dan terbukti menantang bahkan untuk SaC. Kami percaya alur kerja pencarian yang kompleks dan sangat horizontal yang disyaratkan oleh tugas-tugas WANDR akan memerlukan kemajuan tambahan dalam penelitian dan teknik pencarian untuk mencapai kinerja yang secara konsisten tinggi.

Skor WANDR di seluruh sistem yang dievaluasi. Perplexity Agent API memimpin sistem terbaik berikutnya dengan faktor 2.5×.

Terakhir, kami mengukur keuntungan relatif SaC versus alur kerja pencarian yang lebih tradisional yang memanfaatkan infrastruktur pencarian Perplexity yang sama. Gambar 6 melaporkan perbedaan skor antara arsitektur SaC dan non-SaC di setiap tolok ukur. Secara menyeluruh, SaC memberikan dorongan substansial dalam kinerja, dengan keuntungan mutlak terbesar pada DSQA (+19.77 pp, 29%) dan keuntungan relatif terbesar pada WANDR (+12.00 pp, 45%).

Garis dasar Perplexity vs. skor SaC pada setiap tolok ukur, dengan delta mutlak dan relatif dianotasikan.

Dalam praktiknya, pengguna peduli dengan kinerja relatif terhadap biaya. Oleh karena itu, kami mengevaluasi batas biaya-kinerja pada DSQA dan WideSearch. Kami mengukur biaya dan kinerja SaC di seluruh tingkat penalaran model rendah, sedang, dan tinggi, berdampingan dengan sistem lainnya. Gambar 7 dan 8 memetakan skor tolok ukur terhadap harga per tugas, dengan sumbu x dibalik sehingga titik yang lebih jauh ke kanan lebih murah dan titik yang lebih tinggi mewakili kinerja yang lebih baik.

Skor DSQA versus harga per tugas. Garis putus-putus menghubungkan konfigurasi penalaran model SaC.

Pada DSQA, ketiga pengaturan SaC terletak di batas kanan atas. Pengaturan penalaran rendah lebih murah daripada semua sistem lain sementara berkinerja lebih baik daripada dua di antaranya. Pengaturan penalaran sedang mengungguli semua sistem non-SaC dengan harga di bawah $1 per tugas. Pengaturan penalaran tinggi mencapai kinerja puncak dengan biaya yang kompetitif.

Skor WideSearch versus harga per tugas. Garis putus-putus menghubungkan konfigurasi penalaran model SaC.

WideSearch menunjukkan batas yang dibentuk serupa. Seperti pada DSQA, pengaturan penalaran rendah mencapai kinerja kompetitif dengan biaya lebih rendah daripada semua sistem non-SaC, sementara penalaran sedang dan tinggi mengungguli sistem non-SaC dalam kinerja tugas.

Search as Code mencerminkan perubahan yang lebih luas dalam desain perangkat lunak. Selama beberapa dekade, sistem perangkat lunak diatur di sekitar instruksi deterministik yang dieksekusi oleh waktu proses tradisional pada CPU. Model perintis memperkenalkan bentuk komputasi baru: penalaran ruang token yang dapat mengikuti dan menghasilkan instruksi. Sistem komputasi yang paling mampu akan menggabungkan kedua bentuk komputasi ini alih-alih memilih di antara keduanya.

Pencarian adalah lahan uji alami untuk arsitektur hibrida ini. Model sangat cocok untuk memutuskan bukti apa yang diperlukan dan bagaimana ketidakpastian harus diselesaikan. Waktu proses deterministik sangat cocok untuk pengelompokan, paralelisme, pemfilteran, pemeringkatan, dan agregasi. Infrastruktur pencarian berfungsi sebagai lapisan I/O universal, yang menyediakan waktu proses dengan pegangan yang berguna ke dalam informasi dunia yang dapat mempertahankan ribuan operasi per menit. Ketika bagian-bagian ini diintegrasikan, sistem yang dihasilkan jauh lebih kuat dan efisien dalam menyelesaikan tugas dunia nyata.

Setiap bagian dari arsitektur ini diperlukan untuk membuka kemampuan ini. Tanpa model yang cerdas, sistem tidak dapat bernalar atas strategi pencarian. Tanpa kotak pasir, model dipaksa ke I/O serial dan pemrosesan ruang token yang tidak efisien. Dan tanpa tumpukan pencarian yang teratomisasi, model tidak memiliki apa pun untuk diatur. SaC bekerja karena penalaran, komputasi deterministik, dan I/O dirancang secara bersama-sama untuk menonjolkan kekuatan setiap lapisan.

Desain bersama ini dapat dibawa lebih jauh lagi melalui pengembangan loop peningkatan berkelanjutan. Misalnya, SDK Pencarian Agen dan Skill Agen SaC dapat dioptimalkan bersama dalam loop penelusuran mandiri yang umum. Lebih ambisius lagi, model dapat dilatih untuk memanfaatkan primitif pencarian tingkat rendah yang diekspos sebagai SDK. Seseorang bahkan dapat mencoba ikut mengembangkan desain SDK selama proses pelatihan model itu sendiri. Kami menantikan untuk mengejar strategi desain bersama yang lebih agresif di pekerjaan masa depan.

Kami membangun SaC untuk memungkinkan model mengontrol proses pencarian, alih-alih sekadar mengonsumsi hasilnya. Hasil kami membuktikan kekuatan kendali ini: SaC memajukan kinerja mutlak dan batas biaya-kinerja pada tolok ukur agen intensif pengetahuan. Kami sangat senang membawa kemampuan SaC kepada pengguna kami, dimulai hari ini dengan Perplexity Computer dan Agent API. Kami akan terus mengoptimalkan arsitektur SaC di semua lapisan tumpukan untuk memastikan pengguna kami (dan agen yang melayani mereka) memiliki kemampuan pencarian yang paling kuat dan efisien.

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

Pendahuluan

Kekakuan Pencarian Tradisional

Mode Kegagalan dari Kekakuan

Merancang Arsitektur Pencarian yang Dapat Diprogram

SDK Pencarian Agen

Kotak pasir

Model

Kode sebagai Orkestrator dan Pengisi Kesenjangan

Studi Kasus: Saran Vendor CVE

Hasil Evaluasi

Tolok Ukur dan Sistem

Kinerja Perbandingan

Batas Biaya-Kinerja

Menuju Arsitektur Komputasi Baru

Kutipan