Photon: Membangun Mesin Pengambilan dan Pemeringkatan Dari Awal

Bagaimana format data khusus, pembacaan berkelompok, dan pemisahan pembuatan indeks dari penyajian kueri meningkatkan pencarian natif-AI.

PenulisPerplexity Engineering

Pengantar

Tumpukan pencarian natif-AI Perplexity mengambil dan memeringkatkan halaman kandidat, menampilkan konten yang paling relevan untuk landasan jawaban model. Awalnya, tahap ini berjalan pada mesin sumber terbuka yang kami adaptasi ke sistem kami. Namun, seiring pertumbuhan indeks dan beban kerja kami, kami mencapai batas keras pada biaya, latensi ekor, dan waktu pemulihan node yang tidak dapat kami selesaikan dalam platform pihak ketiga yang ada.

Untuk mengatasi tantangan ini, kami membangun Photon, mesin pengambilan dan pemeringkatan internal yang baru. Ini melanjutkan pendekatan kami dalam membangun infrastruktur pencarian berbasis AI dari awal, seperti yang kami lakukan dengan CobbleDB, penyimpanan nilai-kunci terdistribusi kami untuk melayani catatan halaman, dan Search API kami.

Photon menggunakan format data yang ringkas untuk membaca dan mendekode hanya apa yang dibutuhkan oleh setiap kueri, dengan caching yang sadar kumpulan (batch-aware) dan pembacaan asinkron untuk mengurangi akses diska dan tumpang tindih waktu tunggu. Pembuatan indeks berjalan secara terpisah dari penyajian kueri, memperbarui satu grup penyajian dalam satu waktu dan menghangatkan singgahannya sebelum merutekan kueri langsung ke grup tersebut.

Photon kini mendukung saluran pipa pencarian kami dan juga merupakan fondasi dari preset cepat baru untuk Search API kami, dengan latensi panggilan pencarian tunggal sebesar 160 ms pada p50 dan 230 ms pada p95. Di seluruh enam tolok ukur publik, preset cepat mengurangi perkiraan biaya model-plus-pencarian per tugas sebesar 68% sambil mempertahankan kualitas tugas agregat yang sebanding dengan preset default. Kami merilisnya hari ini agar pengembang dapat mengakses peningkatan ini.

Latensi panggilan pencarian tunggal yang dilaporkan sendiri. PPLX Fast melaporkan latensi p50 sebesar 160 ms dan latensi p95 sebesar 230 ms. Exa Instant melaporkan p90, bukan p95, untuk nilai ekor tingginya; nilai ekor tinggi Parallel tidak dipublikasikan. Persentil yang dilaporkan dan penyiapan pengukuran bukanlah perbandingan perbandingan langsung yang dikontrol.
Kualitas tugas agregat versus perkiraan total biaya model-plus-pencarian untuk 3.554 tugas terpilih yang sama. Skor dibobotkan oleh jumlah tugas, dan biaya mencakup seluruh set tugas. PPLX Fast mencetak skor 64,3% pada $59,73, versus 64,0% pada $187,60 untuk preset PPLX default, dengan perkiraan biaya sekitar 68% lebih rendah untuk jumlah tugas yang sama.

Persyaratan mesin pengambilan dan pemeringkatan

Untuk setiap kueri, mesin pengambilan dan pemeringkatan mencari indeks terdistribusi yang besar untuk memilih dan mengurutkan sekumpulan kecil halaman yang relevan dalam anggaran latensi tumpukan pencarian. Sistem juga harus menjaga agar indeks tetap mutakhir seiring datangnya halaman baru dan berubahnya halaman yang ada, tanpa membiarkan pekerjaan tersebut memperlambat kueri langsung.

Kami mengevaluasi beberapa opsi sumber terbuka dan memilih mesin pengambilan dan pemeringkatan tujuan umum yang matang yang memenuhi kebutuhan awal kami. Kami kemudian mengadaptasinya ke arsitektur dan beban kerja kami, mempertahankan latensi dan throughput yang stabil pada skala produksi.

Kelemahan sistem kami sebelumnya

Kami memelihara fork kami sendiri untuk mengadaptasi mesin ke indeks kami yang sedang berkembang, tetapi mengatasi keterbatasan utama semakin memerlukan perancangan ulang sebagian besar bagian platform. Beberapa kendala terbukti sulit diselesaikan tanpa perubahan arsitektur mendasar:

1. Biaya penskalaan. Jumlah dokumen yang kami simpan maupun jumlah data per-dokumen yang perlu kami ambil dan peringkatkan terus bertambah dari waktu ke waktu. Penskalaan ini memberikan tekanan pada perangkat keras kami, terutama jumlah RAM yang tersedia. Untuk mengontrol biaya, kami membutuhkan representasi data yang lebih ringkas dan kontrol yang lebih baik atas apa yang tetap berada di memori dan apa yang dibaca dari diska sesuai permintaan.

2. Latensi ekor yang buruk. Pada lalu lintas produksi, waktu respons p99 sistem lama adalah sekitar 800 ms. Dataset melebihi RAM yang tersedia, sehingga kami tidak dapat menggunakan mlock untuk menjaganya tetap di memori sepenuhnya. Mengakses data non-residen dapat memicu page fault besar, yang menghentikan eksekusi kueri saat sistem operasi membaca dari diska.

Mesin ini juga secara berkala menggabungkan indeks diska utamanya dengan indeks yang lebih kecil yang dibilas dari memori. Selama proses fusi indeks diska ini, jumlah page fault naik lebih tinggi lagi, dengan latensi p99 mencapai sekitar 1,2 s selama 10–15 menit. Saat singgahan menghangat, frekuensi page fault dan latensi keduanya menurun, yang menyarankan bahwa pembacaan dingin merupakan kontributor utama lonjakan tersebut. Pemuatan awal data dan pemanasan indeks mengurangi lonjakan tetapi tidak secara memadai mengatasi latensi ekor yang tinggi.

3. Pemulihan dan sinkronisasi yang memakan waktu. Pada sistem sebelumnya, menerapkan kluster tambahan dan menyinkronkan datanya dapat memakan waktu lebih dari seminggu. Sinkronisasi juga diperlukan saat menambahkan grup node untuk menampung salinan data tambahan atau memulihkan dari kegagalan node. Selama pemulihan, bagian yang lebih besar dari respons pencarian bersifat parsial, yang menurunkan skor kualitas jawaban akhir.

Pada akhirnya, kami menyimpulkan bahwa membangun dari awal akan lebih sederhana dan lebih murah daripada terus mengadaptasi dan memelihara fork kami. Mengandalkan pengalaman kami dalam mengoperasikan sistem sebelumnya, tim teknik kecil bekerja bersama segerombolan agen pengodean persisten untuk membangun Photon.

Posisi Photon dalam tumpukan pencarian

Photon dirancang untuk dua alur kerja utama: melayani permintaan pencarian dan menyerap pembaruan dari alur kerja pemrosesan.

Permintaan dari layanan pencarian tingkat tinggi mencapai broker Photon melalui penyeimbang beban (load balancer). Broker memilih grup shard dan meneruskan permintaan ke setiap shard, memantau batas waktu (timeout) dan mengeluarkan permintaan tambahan bila diperlukan.

Setiap shard melakukan pengambilan, pemeringkatan awal, dan pemeringkatan tahap kedua, lalu mengembalikan kandidat terbaiknya ke broker. Broker menggabungkan kandidat ini menjadi satu daftar berurutan dan mengambil field dokumen kunci untuk halaman yang dipilih dari shard yang relevan. Broker kemudian mengembalikan hasil ini ke layanan pencarian tingkat tinggi, yang mengumpulkan konten halaman yang diperlukan agen untuk menghasilkan jawaban berbasis fakta.

Pembaruan indeks mengikuti jalur yang terpisah. Pillar, lapisan penerbitan kami, menyiapkan data dan menyimpannya di tabel YTsaurus. Pengindeks mengonversi tabel ini menjadi struktur indeks yang dapat dimuat shard untuk pencarian. Pengontrol mengoordinasikan penyiapan data, pembuatan indeks, dan penerapan versi indeks baru ke grup penyajian. Sebelum menangani lalu lintas langsung, setiap shard memutar ulang kueri pencarian nyata untuk menghangatkan singgahannya.

Kueri berpindah dari layanan pencarian tingkat tinggi melalui penyeimbang beban dan broker ke grup shard yang dipilih. Setiap shard mengambil dan memeringkatkan kandidat; broker menggabungkan hasilnya, mengambil field dokumen untuk halaman yang dipilih, dan mengembalikannya ke layanan pencarian tingkat tinggi. Langkah-langkah bernomor menunjukkan urutan. Panah padat membawa permintaan, dan panah putus-putus membawa hasil kembali. Label fase sisi kiri membedakan pemilihan kandidat dari pembacaan ringkasan.

Merancang Photon untuk alur kerja kami

Tiga pilihan desain membuat Photon sangat cocok untuk alur kerja kami: representasi data yang ringkas, singgahan dan pembacaan diska asinkron, serta memisahkan pembaruan indeks dari penyajian kueri.

Representasi data untuk pengambilan dan pemeringkatan

Pengambilan dan pemeringkatan mengakses data dokumen secara berbeda. Pengambilan leksikal dimulai dengan istilah kueri dan menemukan dokumen yang memuatnya. Pemeringkatan kemudian memerlukan informasi rinci tentang setiap dokumen yang dipilih, termasuk frekuensi dan posisi istilah.

Photon menggunakan dua representasi komplementer untuk mendukung pola akses ini. Indeks terbalik menyimpan daftar dokumen yang cocok untuk setiap istilah, yang disebut daftar pemuatan (posting list), untuk mendukung pemilihan kandidat. Catatan per-dokumen terpisah menyediakan data yang diperlukan untuk pemeringkatan. Kami juga mengoptimalkan cara penyimpanan dan penelusuran daftar pemuatan untuk meningkatkan pemilihan di bawah anggaran kerja tetap.

Representasi data khusus memungkinkan kita menyimpan data kunci dengan lebih efisien. Indeks terbalik yang lebih ringkas mengurangi jumlah data yang dibaca atau dipindahkan per kueri, meningkatkan latensi dengan menghilangkan operasi I/O yang tidak perlu. Format ini juga memungkinkan untuk memeriksa apakah suatu dokumen muncul dalam daftar tanpa mendekodenya secara penuh, properti yang diandalkan oleh logika penelusuran kami untuk mengontrol seberapa banyak pekerjaan yang dilakukan kueri di bawah anggaran tetap. Mengoptimalkan catatan per-dokumen memungkinkan kita menyimpan lebih banyak data per dokumen untuk pemeringkatan, sekaligus mengurangi biaya penskalaan yang terkait dengan sistem sebelumnya.

Indeks terbalik

Untuk setiap istilah, indeks terbalik menyimpan daftar pemuatan. Daftar ini dapat berkisar dari segelintir dokumen hingga jutaan, sehingga tidak ada satu format tunggal yang bekerja dengan baik untuk setiap daftar. Photon memilih format berdasarkan jumlah dokumen yang berisi istilah tersebut.

Daftar pendek menggunakan representasi sebaris yang pas dalam satu halaman dan tidak memerlukan tabel blok. Daftar yang lebih panjang yang tidak pas dengan format sebaris dibagi menjadi blok-blok yang mencakup rentang pengenal dokumen tetap. Representasi setiap blok bergantung pada kepadatannya: blok jarang menyimpan array terurut dari offset ID dokumen, sementara blok padat menggunakan bitmap. Blok jarang menggunakan pencarian galop (galloping search), yang maju dalam langkah-langkah yang semakin besar untuk melewati wilayah daftar. Blok padat memungkinkan pemeriksaan keanggotaan dengan mencari bit yang sesuai dengan dokumen.

Frekuensi kueri suatu istilah menentukan di mana daftar pemuatannya ditempatkan pada diska. Daftar yang sering dikueri disimpan berdekatan satu sama lain, mengonsentrasikan data panas di wilayah penyimpanan yang lebih kecil. Dalam setiap daftar, dokumen diurutkan berdasarkan sinyal kegunaan terpisah sehingga kandidat yang lebih menjanjikan ditemui lebih awal.

Photon memilih representasi daftar pemuatan berdasarkan panjang dan kepadatan blok. Daftar pendek pas secara sebaris dalam halaman. Daftar yang lebih panjang dibagi menjadi rentang ID dokumen tetap, dengan array offset terurut untuk blok jarang dan bitmap untuk blok padat.

Menelusuri daftar dalam anggaran kerja

Pemilihan kandidat memerlukan penelusuran daftar pemuatan untuk menemukan dokumen yang berpotensi relevan. Memindai setiap daftar secara menyeluruh memerlukan biaya yang besar, sehingga Photon menggunakan algoritma seperti-WAND yang hanya menelusuri beberapa daftar sementara tetap memperhitungkan kecocokan di daftar lainnya.

Algoritma membagi daftar menjadi dua grup. Daftar pendorong memajukan penelusuran dan mengusulkan dokumen kandidat. Daftar probe berkontribusi pada skor kandidat tersebut tetapi tidak menghasilkan kandidat sendiri.

Skor kandidat menggabungkan cakupan istilah kueri berbobot dan kontribusi frekuensi, dengan normalisasi panjang dokumen dan batas atas pada perolehan dari istilah yang berulang. Photon terlebih dahulu memeriksa keberadaan istilah dalam array dan bitmap untuk membatasi skor maksimum yang mungkin dari setiap kandidat. Photon membaca frekuensi istilah yang tepat hanya untuk kandidat yang masih dapat memenuhi ambang batas pemilihan.

Pemilihan kemudian dilanjutkan dalam tiga langkah:

  • Penelusuran: Mulai dengan persyaratan cakupan kueri yang ketat. Jika terlalu sedikit kandidat yang ditemukan, ulangi dengan persyaratan yang dilonggarkan.
  • Retensi: Kandidat ditahan dalam set terikat menggunakan skor yang menggabungkan cakupan dan frekuensi. Seiring dengan peningkatan kandidat teratas yang dikumpulkan, ambang batas penerimaan naik.
  • Pemilihan akhir: Hasil akhir untuk tahapan ini dipilih dari set yang dipertahankan berdasarkan skor frekuensi. Setiap field menjalankan tahapannya sendiri, dan hasilnya digabungkan menggunakan bobot field.

Algoritma menghasilkan set kandidat dokumen relevan yang akan digunakan dalam pemeringkatan lebih lanjut.

Penelusuran kandidat terikat ilustratif. Daftar pendorong mengusulkan dokumen, sementara batas atas memungkinkan kandidat di bawah ambang batas penerimaan saat ini dipangkas tanpa membaca daftar pemeriksaan atau frekuensi persisnya. Ambang batas naik seiring dengan peningkatan set yang dipertahankan. Skor diciptakan untuk ilustrasi, dan kandidat yang dipertahankan bukanlah top-k tepat yang dijamin.

Docblob

Setelah halaman kandidat dipilih, fase pemeringkatan memerlukan frekuensi istilah, cakupan field, serta lokasi dan kedekatan kemunculan. Mendapatkan data ini melalui indeks terbalik akan memerlukan akses yang tersebar di banyak pasangan istilah-dokumen. Di Photon, kami menyimpan catatan per-dokumen yang ringkas yang disebut docblob yang berisi frekuensi istilah, field tempat kemunculan suatu istilah, dan di mana istilah tersebut muncul dalam dokumen. Hasilnya, memeringkatkan kandidat hanya memerlukan satu pencarian per dokumen.

Format ini dibuat untuk menghindari dekode yang melebihi kebutuhan. Di dalam docblob, field dikelompokkan berdasarkan penganalisis teks. Setiap grup menyimpan daftar istilah terurut yang dikodekan dengan Elias-Fano, sehingga istilah kueri dapat dicari secara langsung tanpa memperluas seluruh daftar terlebih dahulu. Masker field menandai tempat terjadinya suatu istilah, penghitung frekuensi melacak seberapa sering, dan posisi aktual berada di blok terpisah per pasangan istilah-field yang dikodekan sebagai perbedaan posisi. Hanya blok untuk istilah yang benar-benar cocok yang didekode, sementara hal lain dalam catatan tetap dalam format terkompresi.

Dekode selektif tersebut memungkinkan docblob mendukung penyimpanan lebih banyak data per dokumen tanpa peningkatan biaya yang proporsional. Menumbuhkan rekaman tidak memaksa lebih banyak pekerjaan per pencarian, karena pemeringkatan hanya menyentuh bagian yang relevan dengan istilah yang cocok alih-alih seluruh rekaman.

Docblob mengelompokkan data pemeringkatan ke dalam catatan per-dokumen yang ringkas. Istilah kueri dicari dalam daftar istilah yang dikodekan dengan Elias–Fano; masker field, frekuensi, dan blok posisi menyediakan data yang diperlukan untuk istilah yang cocok sementara istilah yang tidak terkait tetap terkompresi. ID dan posisi istilah bersifat ilustratif.

Pembacaan berkelompok dan bekerja dengan memori

Bahkan dengan representasi data yang lebih efisien, RAM tetap habis sebelum sumber daya lainnya, sehingga kami sering kali perlu mengakses data yang disimpan di diska. Photon menggunakan pembacaan diska asinkron dan singgahan yang dioptimalkan untuk pembacaan berkelompok guna mempercepat akses ini, memangkas waktu tunggu per permintaan. Hal ini berkontribusi pada peningkatan yang signifikan dalam latensi ekor dibandingkan dengan sistem sebelumnya.

Photon memeriksa sekumpulan offset rekaman yang diketahui di singgahannya sebelum mengeluarkan pembacaan diska. Cache hit disalin ke dalam buffer yang disiapkan; cache miss dikirim melalui io_uring agar waktu tunggu diska dapat tumpang tindih, dan data yang dikembalikan mengisi singgahan. Rekaman dan garis waktu bersifat skematis, bukan latensi yang diukur.

Tumpang tindih waktu tunggu diska

Pemeringkatan memerlukan perolehan fitur dari seratus dokumen yang terletak di bagian file yang berbeda. Sistem sebelumnya menggunakan mmap untuk memetakan file ke dalam ruang alamat virtual sehingga dapat dibaca melalui pointer memori. Namun, mengakses halaman yang tidak ada dari memori masih memerlukan pembacaan diska. Utas harus menunggu data sebelum melanjutkan komputasi, dan waktu tunggu ini bertambah ketika proses perlu membaca rekaman dingin secara berurutan.

Photon memanfaatkan fakta bahwa offset rekaman sudah diketahui sebelumnya, sehingga kita dapat mengirimkan beberapa pembacaan sekaligus. Hal ini dikelola oleh reaktor: utas pekerja khusus mengirimkan kumpulan melalui io_uring dan meneruskan data yang dibaca ke kode pemanggil. Setiap utas memelihara io_uring-nya sendiri; kumpulan dikirim ke reaktor dengan beban paling ringan. Deskriptor file dan kumpulan buffer yang telah didaftarkan sebelumnya mengurangi overhead dari pembacaan yang berulang. Eksekusi asinkron ini memungkinkan waktu tunggu untuk beberapa operasi tumpang tindih, sehingga mengurangi latensi ekor.

Mengurangi jumlah akses diska (drive accesses)

Sebelum mengirimkan pembacaan, Photon memeriksa seluruh kumpulan dalam singgahan dalam memori. Hanya permintaan untuk rekaman yang hilang yang menuju ke diska; data yang dibaca kemudian mengisi singgahan.

Singgahan dirancang untuk pembacaan berkelompok (batched reads). Khususnya:

  • Tidak ada alokasi terpisah pada cache hit. Alih-alih, data disalin ke dalam buffer yang disiapkan sebelumnya oleh kode pemanggil.
  • Tidak ada perolehan kunci oleh pembaca. Alih-alih, pembaca memeriksa versi data dan mencoba lagi jika berkonflik dengan penulisan.
  • Photon menggunakan penggusuran CLOCK, alih-alih mengharuskan pembaruan ke daftar LRU bersama pada setiap pembacaan.
  • Photon menggunakan prefetching singgahan CPU, tempat metadata dan data untuk rekaman mendatang diminta terlebih dahulu.

Optimasi ini mengurangi latensi tanpa merusak kinerja pada beban kerja yang kita pedulikan.

Membangun dan memperbarui indeks secara terpisah dari penyajian

Di Photon, pembuatan indeks dan penyajian kueri berjalan pada node yang berbeda. Pengindeks mengubah data menjadi struktur penyimpanan yang siap, sementara node penyajian membacanya dan melakukan pengambilan dan pemeringkatan. Hasilnya, pembuatan indeks tidak bersaing dengan kueri pencarian untuk CPU, dan sumber daya untuk tugas-tugas ini dapat disesuaikan skalanya secara independen.

Pemisahan ini mengatasi hambatan pemulihan dan sinkronisasi yang ada pada implementasi sebelumnya. Karena pembuatan indeks berjalan di dalam kluster yang sama yang melayani kueri, memulihkan node yang gagal atau menambahkan salinan data baru dapat berarti mengindeks ulang dokumen di tempat, proses yang memakan waktu berhari-hari dan meningkatkan respons parsial selama pemulihan. Photon menghilangkan ketercouplingan tersebut; pengindeks berjalan sebagai pekerjaan terdistribusi yang menghasilkan struktur indeks versi yang siap disajikan secara independen dari node penyajian, sehingga membangun versi indeks berikutnya tidak lagi bersaing dengan lalu lintas langsung.

Pembuatan indeks berjalan terpisah dari penyajian kueri langsung. Pillar mengekspor data sumber, YTsaurus menyiapkan tabel versi berdasarkan shard, dan pengindeks paralel menulis struktur indeks yang siap disajikan ke penyimpanan objek. Node penyajian memuat struktur tersebut untuk pengambilan dan pemeringkatan; konkurensi pengindeks dan jumlah shard dikonfigurasi secara independen.

Persiapan dan pembangunan terdistribusi

Pembuatan dimulai dengan memilih dokumen untuk indeks aktif dan menghasilkan ekspor sumber. Pengontrol mencatat versi sumber, tabel input, dan perkiraan jumlah shard. Pekerjaan MapReduce di YTsaurus menyiapkan teks, metadata, fragmen, fitur, dan embedding yang telah dihitung sebelumnya ke dalam tabel versi yang dipartisi berdasarkan shard. Setiap pengindeks mengalirkan tabel yang disiapkan, membangun struktur untuk shard-nya, dan menggabungkan segmen teks. Indeks siap, beserta deskripsi komponennya, diunggah ke penyimpanan objek.

Jumlah shard dan jumlah pengindeks yang berjalan secara bersamaan dikonfigurasi secara independen, sehingga pembuatan dapat berjalan dalam beberapa gelombang, atau lebih banyak komputer dapat dialokasikan untuk bekerja secara paralel. Persiapan terdistribusi dan pengindeks paralel memungkinkan indeks web penuh dibangun dalam waktu satu digit jam, peningkatan yang signifikan dibandingkan sistem sebelumnya.

Menerapkan versi baru

Sebelum penerapan, pengontrol memeriksa bahwa indeks baru sudah siap. Jika data tidak lengkap, penerapan diblokir secara otomatis.

Ketika ada beberapa grup penyajian, pengontrol memperbaruinya satu per satu. Pengontrol pertama-tama menghapus grup dari perutean broker dan memulai grup tersebut pada versi indeks baru. Sebelum melayani permintaan, shard melalui tahap pemanasan terpisah berdasarkan log pencarian, yang mengisi pra-status awal dan membuat transisi ke lalu lintas nyata menjadi lebih lancar. Setelah pemanasan, pengontrol memeriksa status dan kesiapan indeks, lalu mengembalikan grup ke perutean. Grup lain terus melayani permintaan selama waktu ini. Karena status operasi bertahan, memulai ulang tidak memaksa pembuatan dimulai dari awal; pengontrol dapat memasang kembali ke persiapan yang sedang berjalan, menggunakan kembali hasil yang siap, atau melanjutkan rotasi yang terganggu dari langkah yang disimpan.

Waktu pembaruan data berbeda di berbagai vertikal pencarian. Untuk vertikal dengan persyaratan kesegaran tinggi, pengiriman dokumen membutuhkan waktu dalam jumlah satu digit menit. Salinan data tambahan dapat diterapkan dalam waktu sekitar setengah jam; indeks siap dimuat dan dilampirkan ke shard tanpa mengindeks ulang dokumen sumber.

Pengontrol memeriksa bahwa indeks baru sudah lengkap, lalu merotasi satu grup penyajian dalam satu waktu. Suatu grup meninggalkan perutean broker, memuat versi baru, menghangatkan singgahannya dengan kueri log pencarian, dan melewati pemeriksaan kesiapan sebelum kembali ke lalu lintas. Grup lain terus melayani, dan status pengontrol yang bertahan memungkinkan rotasi yang terganggu untuk dilanjutkan.

Migrasi dan validasi dalam tumpukan pencarian kami

Tujuan pertama kami adalah mengganti sistem lama dengan mesin yang mempertahankan fungsionalitas dan kualitas pencarian sekaligus mengurangi waktu respons. Kami memvalidasi Photon secara bertahap, dimulai dengan uji beban yang dapat direproduksi dan evaluasi kualitas offline sebelum beralih ke lalu lintas langsung. Photon kini mendukung pengambilan dan pemeringkatan dalam tumpukan pencarian produksi kami, dengan waktu respons yang jauh lebih rendah daripada sistem lama.

Pengujian beban dan evaluasi

Untuk pengujian kinerja, kami membangun alat pengujian beban yang memutar ulang kueri dari log pencarian kami pada tingkat kedatangan yang dapat dikonfigurasi. Alat ini membandingkan hasil di berbagai eksekusi dan menerapkan uji statistik untuk menilai apakah perbedaan kinerja yang diamati konsisten. Secara terpisah, kami mengevaluasi Photon dan sistem lama pada dataset yang sama di sistem evaluasi offline internal kami untuk memeriksa regresi kualitas.

Setelah pemeriksaan ini, kami mengirimkan kueri langsung ke kedua mesin secara bersamaan menggunakan lalu lintas bayangan (shadow traffic). Hal ini memungkinkan kami membandingkan kinerja dan hasil pada beban kerja produksi sebelum mengubah mesin mana yang melayani pengguna. Kami kemudian mengaktifkan Photon untuk subset kecil pengguna dan secara bertahap memperluas peluncuran, memantau kualitas dan kinerja secara keseluruhan. Versi pertama lolos pengujian penerimaan tanpa regresi kualitas, dan kami melanjutkan peluncuran hingga Photon melayani semua lalu lintas produksi.

Peningkatan terukur dalam produksi

Dalam alur kerja produksi kami, waktu respons p99 turun dari sekitar 800 ms pada sistem lama menjadi sekitar 65 ms pada Photon. Pengukuran ini mencakup semua tahap di dalam Photon, tetapi tidak termasuk tahap berikutnya dalam tumpukan pencarian tingkat tinggi. Kami juga tidak lagi mengamati lonjakan latensi yang sebelumnya dikaitkan dengan peralihan versi indeks.

Photon menggunakan mesin penyajian ekuivalen sekitar 20% lebih sedikit daripada node konten sistem lama sambil menyimpan data sekitar 2,5 kali lebih banyak per dokumen. Setelah migrasi, kami menggunakan data tambahan ini untuk meningkatkan kualitas pemeringkatan melebihi sistem lama.

Photon juga mengurangi jumlah data yang harus tetap berada di memori. Menyematkan dataset Photon yang sama di RAM dengan mlock akan memerlukan memori residen sekitar 4,6 kali lipat dari yang digunakan Photon saat ini.

Evaluasi preset Search API yang cepat

Kami juga menggunakan Photon sebagai dasar untuk preset cepat baru untuk Search API kami, yang dirancang untuk beban kerja yang sensitif terhadap latensi. Berdasarkan pengukuran kami, latensi panggilan pencarian tunggal untuk preset cepat adalah 160 ms pada p50 dan 230 ms pada p95, lebih rendah atau sebanding dengan angka yang dilaporkan sendiri oleh penyedia Search API lainnya, meskipun persentil ekor yang dilaporkan berbeda.

Kami mengevaluasi preset cepat pada enam tolok ukur agen: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0, dan SEAL-Hard. Di seluruh evaluasi ini, preset tersebut memiliki perkiraan total biaya model-plus-pencarian terendah dan skor tugas agregat tertinggi di antara konfigurasi yang diuji.

Preset cepat memasangkan Photon dengan pemeringkatan yang dioptimalkan untuk alur kerja agen, memberikan kinerja yang sebanding dengan preset default pada biaya yang jauh lebih rendah. Namun, preset ini memiliki kompromi dalam kualitas pencarian yang lebih luas. Preset cepat menggunakan komputasi yang lebih sedikit untuk pemeringkatan daripada preset default. Pada tolok ukur internal yang mencakup kueri ekor panjang, cakupan luas, dan keragaman hasil, preset ini mencetak skor 0,24 poin lebih rendah pada relevansi dan sekitar 3 persentase poin lebih rendah pada ketersediaan jawaban. Kami percaya ini adalah kompromi yang masuk akal untuk alur kerja agen, karena penalaran dan pengetahuan model itu sendiri dapat membantu mengompensasi perbedaan tersebut.

Perbandingan kualitas pengambilan internal antara preset PPLX default dan PPLX Fast. Relevansi (DCG) turun dari 2,45 menjadi 2,21, penurunan sebesar 0,24 poin; ketersediaan jawaban turun dari 0,596 menjadi 0,567, penurunan sebesar 2,9 persentase poin. Kedua panel menggunakan garis dasar sumbu bukan nol yang berbeda, sehingga tinggi batang menekankan kesenjangan alih-alih perbedaan proporsional.

Kami merekomendasikan preset cepat untuk tugas agen sehari-hari. Untuk pertanyaan yang lebih menantang atau ambigu yang tidak terlalu sensitif terhadap waktu, preset default menawarkan kualitas yang lebih kuat, membenarkan latensi dan biayanya yang lebih tinggi.

Kesimpulan

Kami terus memindahkan tumpukan pencarian kami ke infrastruktur internal berbasis Rust. Mengganti mesin sumber terbuka dengan Photon, mesin pengambilan dan pemeringkatan kustom kami, adalah langkah terbaru. Photon memberi kami kontrol penuh atas representasi data, cara pengorganisasian pembacaan, dan cara penerapan indeks baru, memungkinkan kami mengoptimalkan setiap lapisan untuk beban kerja kami.

Photon telah mengaktifkan pencarian yang lebih cepat di seluruh produk Perplexity dan menyediakan fondasi untuk preset cepat baru kami di Search API. Mengikuti migrasi, latensi pengambilan-dan-pemeringkatan p99 turun dari sekitar 800 ms menjadi 65 ms. Format data kami yang ringkas juga memungkinkan kami menyimpan data 2.5 kali lebih banyak per dokumen, memberi pengambilan dan pemeringkatan akses ke informasi dokumen yang lebih kaya.

Preset cepat memberikan latensi panggilan pencarian tunggal sebesar 160 ms pada p50 dan 230 ms pada p95. Di seluruh enam tolok ukur agen yang dievaluasi, preset ini mengurangi perkiraan biaya model-plus-pencarian per tugas sebesar 68% relatif terhadap preset default sambil mempertahankan kualitas tugas agregat yang sebanding. Hasil ini menunjukkan manfaat praktis dari infrastruktur yang dirancang di sekitar beban kerja pencarian kami, baik untuk produk Perplexity maupun untuk pengembang yang membangun dengan API kami.

Kami terus meningkatkan kinerja Photon dan efisiensi penyimpanan. Tujuan kami adalah mendukung indeks yang lebih besar dan data dokumen yang lebih kaya pada perangkat keras yang sama sambil menjaga pencarian tetap cepat seiring pertumbuhan beban kerja kami.

Sitasi

BibTeX
@online{perplexity2026Photon,
  author = {{Perplexity} and Maksim Morozov and Bogdan Savko and Ruslan Kovalev and Aleksei Bykov and Artur Zayats and Denis Bykov and Nikita Kireev and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Photon: Building a retrieval and ranking engine from scratch}},
  date = {2026-09-24},
  url = {https://www.perplexity.ai/hub/blog/photon}
}