Perplexity Decider

Cara kami melatih, mengevaluasi, dan menggunakannya.

PenulisPerplexity Research

Kami merilis Decider v1.3 dan Decider Flash v1.3, penerus model keputusan kami sebelumnya: v1, v1.1, v1.2, dan Flash v1.2.

Decider Flash v1.3 adalah model yang lebih kecil hasil distilasi dari Decider v1.3. Kedua model tersedia di Hugging Face dengan lisensi Apache, melalui OpenRouter, dan Perplexity Decisions API.

Perplexity Decider terinspirasi oleh Jev, System One Model dari TypeSafe AI. Model ini mendukung klasifikasi biner dan multikelas dengan label berurutan maupun tidak berurutan, serta mengembalikan probabilitas yang dapat digunakan aplikasi untuk mengklasifikasikan, merutekan, memeringkat, dan mengevaluasi input.

Kedua model v1.3 meningkatkan performa dan ketahanan di berbagai tugas teks dan visual melalui atensi dua arah, data pelatihan yang dikurasi lebih baik, dan resep pelatihan yang disempurnakan. Kami juga memperkenalkan locate, fitur baru untuk menyorot konten yang dipilih dalam tugas pengenalan entitas bernama, identifikasi informasi pribadi, dan tanya jawab ekstraktif.

Dalam artikel ini, kami menjelaskan cara kami melatih dan mengevaluasi Decider serta membagikan cara kami menggunakannya secara internal di Perplexity.

Apa itu model keputusan?

Model keputusan adalah pengklasifikasi serbaguna. Anda memberinya input dan serangkaian pertanyaan, masing-masing dengan kemungkinan jawabannya. Untuk setiap pertanyaan, model mengembalikan distribusi probabilitas atas jawaban-jawaban tersebut. Model ini mendukung 3 jenis pertanyaan:

  • Ya / Tidak: keputusan biner.
  • Pilihan ganda: label multikelas kustom.
  • Skor: tingkatan berurutan.

Model keputusan mendukung beragam tugas klasifikasi dan penilaian:

  • Menilai output: mengukur kesetiaan terhadap sumber, kualitas, dan keamanan.
  • Perutean: mengarahkan permintaan ke model yang lebih kecil atau lebih besar berdasarkan tingkat kesulitan.
  • Moderasi dan keamanan: mendeteksi konten berbahaya, phishing, dan prompt injection dalam output alat.
  • Pemfilteran dan pemberian tag: mengatur koleksi konten berukuran besar.
  • Pengambilan dan pemeringkatan ulang: menilai hasil pencarian berdasarkan relevansi.

Banyak dari tugas ini sebelumnya ditangani oleh model generatif seperti LLM, meskipun tugas-tugas tersebut tidak memerlukan pembuatan teks bebas. Model keputusan berada di antara LLM dan pengklasifikasi khusus tugas. Model ini mengembalikan probabilitas untuk beberapa pertanyaan tentang input yang sama dalam satu forward pass, sehingga menghindari pembuatan jawaban token demi token dan berbagi komputasi antarpertanyaan. Tidak seperti pengklasifikasi khusus tugas, model ini dapat menangani tugas baru melalui prompt bahasa alami, sebuah fleksibilitas yang dipelajari dari pelatihan di berbagai tugas dalam format tanya jawab bersama.

Pelatihan

Mengubah LLM generatif menjadi model keputusan

Kami membangun Decider dengan mengadaptasi backbone LLM generatif yang kuat. Untuk menjelaskan adaptasi ini, pertama-tama kami menguraikan bagaimana sebuah permintaan direpresentasikan. Seperti diilustrasikan di bawah ini, sebuah permintaan terdiri dari konteks bersama (state) dan sejumlah pertanyaan. State akan digunakan ulang oleh semua pertanyaan.

Misalnya, jika diberikan sebuah dokumen dan ringkasannya, satu permintaan dapat menanyakan apakah ringkasan tersebut merepresentasikan dokumen secara akurat dan apakah ringkasan itu ditujukan untuk pakar atau khalayak umum. Setelah state, setiap blok pertanyaan berisi pertanyaan dan kemungkinan jawabannya, masing-masing diberi token label yang telah ditentukan seperti A, B, atau C. Token khusus <|marker|> menunjukkan posisi untuk membaca prediksi model. Pada posisi ini, lapisan output linear yang dipelajari (decision head) memetakan hidden state ke skor untuk opsi jawaban pertanyaan tersebut, yang kemudian dikonversi menjadi probabilitas.

Kami menginisialisasi lapisan output dari model dasar, yang biasanya menilai token berikutnya dari seluruh kosakata, dan hanya mempertahankan baris yang sesuai dengan token opsi yang telah ditentukan seperti A, B, atau C. Lapisan yang telah dipangkas ini kemudian dilatih untuk mengubah hidden state <|marker|> menjadi skor jawaban. Pendekatan ini mencakup semua pertanyaan klasifikasi karena semuanya dapat dirumuskan sebagai pilihan ganda.

Untuk pelatihan, kami mengambil ratusan dataset publik yang mencakup beragam tugas (sentimen, inferensi bahasa alami, deteksi intensi, pencocokan entitas, moderasi, pengecekan fakta, rating, dll.) dan mengonversi setiap contoh ke format terpadu yang dijelaskan di atas: sebuah state, satu atau beberapa pertanyaan, opsi-opsinya, dan sebuah target. Target dapat berupa satu opsi yang benar jika kami memiliki label acuan (gold label), atau distribusi probabilitas atas opsi-opsi tersebut.

Di v1.3, kami memperkenalkan locate, yang mengekstrak teks dari state alih-alih memilih dari opsi yang telah ditentukan. Pertanyaan locate menjelaskan apa yang harus dicari, menggunakan label singkat seperti “lokasi” atau instruksi seperti “Ekstrak nama kota tempat pekerjaan tersebut berada.” Model mengembalikan teks yang sama persis dari state, beserta lokasi karakter awal dan akhirnya. Jika tidak menemukan kecocokan, model mengembalikan daftar kosong.

Berkat state bersama, satu permintaan dapat menggabungkan pertanyaan locate, klasifikasi, dan penilaian tentang input yang sama. Misalnya, permintaan tersebut dapat menanyakan apakah sebuah pekerjaan memerlukan pengalaman tingkat senior sekaligus mengekstrak keterampilan yang dibutuhkan.

Atensi dua arah: memungkinkan model membaca ke dua arah

Model kami dimulai dari backbone generatif praterlatih yang kuat, dengan atensi kausal yang membuat setiap token hanya memperhatikan dirinya sendiri dan token sebelumnya. Studi ablasi kami menunjukkan bahwa membuat lapisan full-attention pada backbone menjadi dua arah meningkatkan performa, sehingga kami mengadopsi desain ini agar setiap token dapat menyertakan konteks dari seluruh input.

Atensi dua arah menghadirkan pilihan desain lain: bagaimana seharusnya state dan pertanyaan berinteraksi? Kami mempertimbangkan tiga pola atensi, dengan implikasi berbeda terhadap performa, stabilitas jawaban, dan penggunaan ulang cache:

  • Semua melihat semua (v1.2): State dan semua pertanyaan diproses bersama dengan atensi dua arah penuh. Komputasi atas state digunakan bersama, tetapi jawaban atas satu pertanyaan dapat berubah tergantung pada pertanyaan lain yang diajukan.
  • Pertanyaan terisolasi (v1.3): State memperhatikan semua pertanyaan, sedangkan setiap pertanyaan hanya memperhatikan state dan tokennya sendiri. Pertanyaan masih dapat saling memengaruhi secara tidak langsung melalui state bersama, tetapi hasilnya lebih stabil.
  • Sepenuhnya dapat di-cache: State hanya memberi atensi pada dirinya sendiri, sementara setiap pertanyaan memberi atensi pada state dan token miliknya sendiri. State tidak bergantung pada pertanyaan dan dapat digunakan ulang di berbagai permintaan untuk memanfaatkan prompt caching. Kami tidak menggunakannya secara default karena kemampuan state untuk melihat pertanyaan sangat penting bagi beberapa tugas, tetapi fine-tuning kecil dapat mengalihkan model ke mode ini.

Pada akhirnya, kami memilih pertanyaan terisolasi karena performa dan stabilitasnya yang kuat.

Resep pelatihan

Pelatihan berlangsung dalam tiga tahap untuk kedua ukuran model. Pertama, kami melatih model yang lebih besar, berbasis Qwen3.8-27B, menggunakan cross-entropy pada dataset besar, lalu mendistilasinya ke model Qwen3.5-4B yang lebih kecil.

Tahap pertama adalah pelatihan generalis, saat kami melakukan fine-tuning penuh pada model menggunakan korpus berskala besar. Pada tahap ini, kami hanya menerima data yang membantu model secara menyeluruh dan tidak spesifik untuk tolok ukur tertentu; karena itu, kami mengecualikan semua split pelatihan tolok ukur.

Setelah model generalis ini dilatih, kami menjalankan tahap kedua yang lebih terperinci menggunakan LoRA. Data yang digunakan pada tahap ini ditargetkan untuk domain dan tugas tertentu. Kami menambahkan data pada tahap kedua alih-alih tahap pertama jika kami mengamati peningkatan yang sempit atau jika kami mengamati beberapa regresi pada tugas lain. Kami menggunakan LoRA agar tidak menyimpang terlalu jauh dari model generalis dan berisiko kehilangan performa demi menyesuaikan diri dengan domain-domain spesifik tersebut. Tujuannya adalah meningkatkan performa sambil mempertahankan pengetahuan umum backbone. Kami juga menggunakan bobot saat menggabungkan LoRA kembali ke model dasar, untuk mengendalikan penyimpangan dengan lebih presisi dan mengutamakan metrik held-out di atas peningkatan apa pun dalam domain.

Terakhir, kami menambahkan langkah khusus visual. Serupa dengan tahap kedua, langkah visual ini diperlakukan sebagai langkah spesialisasi terperinci lainnya, menggunakan adaptor LoRA yang digabungkan kembali ke model dasar dengan suatu bobot. Beberapa kemampuan visual dapat mengorbankan performa teks. Karena kami mengamati penggunaan model yang jauh lebih banyak pada teks, kami memprioritaskan metrik teks di atas metrik visual.

Untuk kedua tahap teks, kami menggunakan rata-rata bobot dari tiga kali pelatihan, masing-masing dengan random seed yang berbeda. Kami mendapati cara ini meningkatkan performa dan ketahanan model gabungan.

Setelah model besar final diperoleh, kami menerapkan prosedur pelatihan tiga tahap yang sama pada model yang lebih kecil. Di sini, model besar berperan sebagai guru: distribusi output yang diprediksinya menggantikan label gold, dan model yang lebih kecil dilatih untuk meminimalkan divergensi KL antara prediksinya dan prediksi model guru. Objektif distilasi ini mengungguli cross-entropy pada data pelatihan yang sama. Meskipun cross-entropy berkinerja lebih baik pada benchmark yang memiliki data pelatihan khusus, kemampuan generalisasinya ke data held-out kurang baik. Kami berhipotesis bahwa distilasi lebih baik dalam mentransfer distribusi output model guru, termasuk tingkat keyakinannya terhadap alternatif non-gold, sedangkan cross-entropy mendorong overfitting pada distribusi data pelatihan yang spesifik untuk benchmark. Oleh karena itu, kami mengadopsi objektif distilasi berbasis KL.

Untuk memitigasi kontaminasi train-test, kami menghapus sampel pelatihan apa pun yang mungkin tumpang tindih dengan evaluasi mana pun yang kami gunakan. Hal ini penting karena beberapa dataset pelatihan publik memuat sebagian besar dari beberapa dataset evaluasi. Kami juga melakukan audit dan penghapusan bias secara ekstensif untuk memastikan peningkatan yang kami capai dapat diandalkan dan bukan sekadar didorong oleh bias yang dipelajari.

Menambahkan kemampuan untuk mengekstrak informasi

Fitur locate mengekstrak informasi seperti entitas bernama dari teks, tanpa mengubah cara model menjawab permintaan biasa. Untuk itu, kami memperkenalkan tahap pelatihan tambahan: kami menambahkan token khusus baru, <|locate|>, sebuah span head, dan adaptor LoRA ke Decider.

Kami menginisialisasi embedding <|locate|> dari <|marker|> yang dipelajari pada tahap pelatihan sebelumnya. Kami hanya melatih embedding baru ini, span head, dan adaptor LoRA, sambil membekukan bobot backbone asli dan decision head. Setiap kolom yang diminta mendapatkan token <|locate|> sendiri.

Span head menggunakan representasi <|locate|> bersama dengan representasi token state untuk menilai di mana span yang cocok dimulai dan berakhir, serta pasangan awal-akhir mana yang saling terkait. Span head juga menggunakan representasi token <|locate|> untuk memprediksi ambang batas khusus per bidang untuk skor-skor ini. Span yang dipilih dikembalikan sebagai posisi karakter dalam teks asli.

Kami melatih span head dengan loss InfoNCE yang diadaptasi, yang mendorong setiap span gold berada di atas ambang batas, dan ambang batas berada di atas setiap span lainnya. Loss ini memiliki dua suku: Suku pertama mendorong skor span yang benar berada di atas ambang batas dan span yang salah. Suku kedua mendorong ambang batas berada di atas skor span yang salah. Bidang tanpa jawaban hanya mendapatkan suku kedua, yang mengajari model untuk mengembalikan daftar kosong.

Kami melatih model dengan campuran tugas ekstraksi span, termasuk pengenalan entitas bernama, deteksi PII, dan tanya jawab ekstraktif. Kami memvariasikan deskripsi kolom, mulai dari label singkat hingga instruksi terperinci, sehingga model belajar mengikuti permintaan alih-alih menghafal kumpulan label yang tetap.

Locate mengajarkan model tugas yang secara struktural berbeda, dan kami ingin menambahkannya tanpa kehilangan apa yang sudah dikuasai model dengan baik. Menggabungkan adapter locate ke dalam backbone menyebabkan sejumlah regresi pada permintaan keputusan. Untuk membatasinya, kami sedang menjalankan investigasi seperti menambah data replay dari tahap-tahap sebelumnya dan objektif tambahan yang menjaga output model pada permintaan keputusan tetap mendekati output model asli. Namun, kami mendapati bahwa penggabungan saat ini masih belum lossless, sehingga kami membiarkan adapter tidak digabungkan dan hanya mengaktifkannya untuk permintaan locate.

Evaluasi

Kami mengevaluasi Decider v1.3 dan Decider Flash v1.3 pada benchmark eksternal dari Hugging Face Decision Index, ClaimBench milik Vals AI, dan Artificial Analysis Decision Index.

Di seluruh evaluasi ini, model kami menunjukkan performa yang kuat. Meskipun papan peringkat ini mencakup tugas yang dirahasiakan, papan peringkat tersebut tetap dapat dimanipulasi melalui pengiriman berulang dan penyetelan iteratif berdasarkan umpan balik papan peringkat. Untuk melengkapi papan peringkat ini, kami mengevaluasi model pada rangkaian internal yang menggabungkan tugas produksi privat dengan evaluasi held-out yang diambil dari dataset publik non-benchmark. Evaluasi ini memberikan pemeriksaan tambahan atas generalisasi di luar benchmark publik, sehingga membantu kami membedakan peningkatan yang lebih luas dari peningkatan yang hanya spesifik pada rangkaian evaluasi yang sudah dikenal.

Secara internal, kami membangun rangkaian lebih dari 200 tugas yang mencakup berbagai domain dan jenis tugas seperti klasifikasi, penilaian, pemeringkatan ulang, dan ekstraksi entitas. Untuk menilai performa Decider di dunia nyata secara jujur, semua evaluasi dilakukan secara zero-shot, tanpa fine-tuning khusus tugas, sehingga kami mendapatkan sinyal yang jelas tentang bagian model yang perlu ditingkatkan.

Klasifikasi kueri

Di Perplexity, kami menggunakan sistem klasifikasi multi-head untuk memproses setiap kueri pengguna. Setiap kueri pertama-tama diteruskan ke model embedding yang berfungsi sebagai pengekstrak fitur. Embedding yang dihasilkan kemudian dimasukkan ke beberapa head klasifikasi terpisah, termasuk pengklasifikasi biner dan multi-label. Misalnya, satu head menentukan apakah kueri pengguna harus memicu pencarian web.

Di 63 tugas klasifikasi dengan referensi yang dilabeli ulang secara independen oleh LLM frontier, Decider v1.3 mencapai akurasi rata-rata 91,6%, melampaui pengklasifikasi produksi kami sebesar 6,54 poin persentase. Decider Flash v1.3 juga mengungguli baseline produksi, sedangkan Decider v1.3 mengungguli Jev 1.14.

Klasifikasi khusus domain

Kami menyusun rangkaian evaluasi khusus domain dari dataset publik untuk menilai performa klasifikasi model keputusan di tujuh domain: verifikasi klaim (6 tugas), layanan kesehatan (7), keamanan siber (8), pemrograman (16), pemerintahan (7), hukum (9), dan keuangan (9).

Misalnya, “menilai kompleksitas waktu sebuah program Python”, atau “menggunakan laporan keuangan tahunan untuk menentukan apakah kas perusahaan yang penggunaannya tidak dibatasi dapat menutupi pokok utang yang jatuh tempo dalam dua belas bulan ke depan”. Decider v1.3 unggul di ketujuh domain, mengungguli Jev 1.14 hingga 12,9 poin persentase di bidang keuangan dan 9,3 poin di bidang hukum. Decider Flash v1.3 tertinggal dari Jev 1.14 di bidang keuangan, pemrograman, dan hukum, serta berperforma serupa di domain lainnya.

Pengambilan dan Pemeringkatan Ulang

Pencarian adalah inti dari Perplexity. Kami mengelola rangkaian tugas pengambilan yang luas untuk mengevaluasi performa pemeringkatan ulang model kami. Untuk setiap tugas, pertama-tama kami menggunakan sekumpulan model embedding untuk mengambil 50 dokumen kandidat teratas dari setiap korpus. Kami kemudian memeringkat ulang kandidat ini menggunakan Decider dan membandingkan performanya dengan baseline reranker yang kuat, Qwen3-Reranker-8B.

Kami mengevaluasi Decider dalam pengaturan zero-shot dan pointwise, menggunakan model untuk langsung menilai setiap pasangan kueri–dokumen secara independen dan memeringkat dokumen berdasarkan relevansi. Di 72 tugas pengambilan, Decider v1.3 mencapai nDCG@10 rata-rata 83,99, mengungguli Qwen3-Reranker-8B sebesar 1,81 poin dan Jev 1.14 sebesar 2,24 poin.

Pada tolok ukur BEIR, kedua model mengungguli Qwen3-Reranker-8B masing-masing sebesar 8,78 dan 7,05 nDCG@10. Dibandingkan Jev 1.14, Decider v1.3 lebih tinggi 1,33 poin, sedangkan versi Flash mendapat skor 0,4 lebih rendah.

Klasifikasi multibahasa

Untuk mengevaluasi model keputusan di luar bahasa Inggris, kami menyusun tolok ukur klasifikasi multibahasa yang terdiri dari 19 tugas khusus bahasa dari 8 dataset publik, dengan 46.484 contoh dalam delapan bahasa: Jerman, Spanyol, Prancis, Italia, Rusia, Jepang, Korea, dan Mandarin. Tolok ukur ini mencakup deteksi intensi, klasifikasi topik, analisis sentimen, inferensi bahasa alami, deteksi parafrasa, deteksi bahasa ofensif, dan keberterimaan gramatikal.

Kami melaporkan akurasi rata-rata di seluruh tugas dalam setiap bahasa, dengan bobot yang sama untuk setiap tugas. Decider v1.3 mengungguli Jev 1.14 di kedelapan bahasa dan Decider Flash v1.3 melakukannya di enam bahasa, dengan akurasi tugas rata-rata 88,16% untuk Decider v1.3 dan 86,50% untuk Decider Flash v1.3, dibandingkan dengan 85,41% untuk Jev 1.14.

NER, PII, dan QA Ekstraktif

Kami mengevaluasi fitur locate pada 17 tugas di luar domain pelatihan yang menguji kemampuan ekstraksinya di berbagai domain, format input (teks, tabel, dokumen terstruktur), dan instruksi (label singkat, pertanyaan, dan deskripsi terperinci). Domainnya beragam, mulai dari Wikipedia hingga makalah ilmiah, laporan ancaman siber, dukungan teknis, kebijakan privasi, resume, dan kontrak hukum. Permintaannya juga beragam, mulai dari nama label singkat seperti “orang” atau “alamat email”, pertanyaan tentang tabel atau tiket dukungan, hingga deskripsi kolom terperinci untuk ekstraksi terstruktur, seperti para pihak dalam NDA atau total pada faktur.

Kami mengevaluasi NER dan PII menggunakan F1 span-eksak, yang mengharuskan span yang diprediksi cocok persis dengan batas referensi. QA ekstraktif menggunakan F1 tingkat karakter, yang memberikan nilai parsial untuk teks jawaban yang tumpang tindih, sedangkan ekstraksi terstruktur menggunakan akurasi bidang, yaitu proporsi bidang yang diekstraksi dengan benar. Untuk parsing CV, kami merata-ratakan skor F1 span-eksak NER dan PII.

Kami membandingkan model kami dengan model ekstraksi serbaguna dengan berbagai ukuran: GLiNER large v2.5 (0,5B), Liquid d1 (2B), dan Clairic dari Cloudflare (tidak diungkapkan). Decider v1.3 mencapai skor rata-rata 69,0 (menggunakan metrik utama setiap tugas) dan Decider Flash v1.3 mencapai 63,6, dibandingkan dengan 43,3 untuk Liquid d1, 41,5 untuk Clairic, dan 33,6 untuk GLiNER large v2.5. Kedua model Decider unggul di setiap kategori.

Klasifikasi gambar

Decider telah mendukung tugas visual secara native sejak v1. Untuk mengevaluasi performanya di luar teks, kami menyusun rangkaian tolok ukur lima tugas dengan fokus khusus pada klasifikasi dokumen, termasuk faktur, surat, dan resume. Rangkaian ini juga mencakup klasifikasi citra satelit, klasifikasi tekstur, klasifikasi ras hewan peliharaan, dan penghitungan hewan.

Decider v1.3 mencapai akurasi rata-rata 76,99% di kelima tugas visual, mengungguli Jev 1.14 sebesar 1,47 poin persentase. Decider Flash v1.3 mencapai 72,77%, menunjukkan kemampuan klasifikasi visual dalam model yang lebih kecil.

Permintaan keputusan di dunia nyata

Kami mengambil sampel satu juta permintaan yang telah dideduplikasi dan disamarkan PII-nya, yang dikirimkan ke Perplexity Decision API selama 18 hari pertama ketersediaannya. Karena setiap permintaan dapat berisi beberapa pertanyaan tentang state yang sama, sampel ini terdiri dari 2.318.887 pertanyaan individual. Semua permintaan disertakan dengan izin eksplisit dari pengguna untuk keperluan penelitian.

Permintaan produksi tidak dilengkapi label ground-truth, sehingga kami menggunakan LLM frontier sebagai juri untuk menghasilkan jawaban referensi dan mengukur tingkat kesesuaian setiap model dengan jawaban tersebut. Kami juga mengelompokkan permintaan ke dalam 10 kategori tugas, termasuk ekstraksi informasi, klasifikasi domain, analisis sentimen, intensi dan perutean, pemeringkatan relevansi, moderasi konten, tinjauan kualitas dan kepatuhan, pencocokan entitas, analisis bisnis, serta kategori “Lainnya”. Rincian ini menunjukkan bagaimana performa bervariasi di berbagai kasus penggunaan di dunia nyata.

Komposisi tugasnya tidak merata: ekstraksi informasi mencakup 425.402 pertanyaan, klasifikasi domain 409.564, dan analisis sentimen 344.158. Ketiga kategori ini secara keseluruhan mencakup 50,8% dari pertanyaan sampel.

Decider v1.3 mencapai tingkat kesesuaian tertinggi dengan juri, yaitu 93,98%, dibandingkan dengan 93,68% untuk Decider v1.2 dan 93,35% untuk Jev 1.14. Decider v1.3 dan Jev 1.14 bersaing ketat dalam klasifikasi domain dan analisis sentimen, dengan selisih masing-masing 0,34 dan 0,07 poin persentase. Jev unggul 0,69 poin dalam pemeringkatan relevansi, sedangkan Decider v1.3 unggul 0,93 poin dalam ekstraksi informasi (tugas paling umum dalam sampel) dan 1,21 poin dalam intensi dan perutean.

Grafik di bawah ini membandingkan biaya yang dilaporkan untuk menjalankan satu juta permintaan produksi yang sama. Setiap permintaan dapat berisi beberapa pertanyaan, sehingga satuan yang digunakan di sini adalah permintaan, bukan pertanyaan individual.

Decider dijalankan secara lokal; GLM dan DeepSeek menggunakan llm-api; Jev menggunakan OpenRouter. Biaya yang dilaporkan bersifat spesifik untuk beban kerja, dengan perhitungan biaya perangkat keras lokal yang tidak dirinci dan tanpa perbandingan latensi yang setara.

Ketahanan

Kami mengevaluasi sensitivitas label pada 372 pertanyaan pilihan ganda, dengan 4.788 permintaan per model. Kami mengubah urutan opsi, menetapkan ulang label ke teks jawaban, dan mengganti nama label sambil mempertahankan makna setiap pertanyaan, lalu memeriksa apakah jawaban semantik model berubah. Tingkat perubahan jawaban yang lebih rendah menunjukkan stabilitas yang lebih tinggi.

Decider v1.3 mengubah jawabannya hanya pada 0,27% pertanyaan di setiap transformasi, dibandingkan dengan 2,69–4,84% untuk Jev 1.14. Kami juga mengulang input yang identik untuk mengukur variabilitas penyajian: Decider v1.3 tidak menunjukkan perubahan, sedangkan Jev 1.14 berubah pada 1,88% pertanyaan.

Cara kami menggunakan Decider

Decider dibuat untuk alur kerja yang memerlukan keputusan cepat dan terstruktur. Di bagian ini, kami membahas cara memanfaatkannya untuk memberikan dampak berarti pada cara kami bekerja. Berikut beberapa yang menonjol.

Aturan keamanan yang menyempurnakan diri sendiri

Secara internal, kami sudah menggunakan Decider untuk meningkatkan kebijakan keamanan kami.

Aktivitas agen kami direkam, lalu serangkaian pemeriksaan berbasis aturan dijalankan untuk mengidentifikasi perilaku bermasalah. Pendekatan berbasis aturan memungkinkan kami memantau agen secara real-time dengan tambahan latensi yang dapat diabaikan. Secara offline, kami menggunakan Decider untuk memeriksa sampel dari log agen yang direkam ini. Jika tidak ada perilaku bermasalah yang ditandai, Decider memeriksa apakah ada sesuatu yang terlewat oleh rangkaian aturan kami; dan jika alarm berbunyi, Decider memeriksa apakah itu alarm palsu. Setiap catatan yang menunjukkan kegagalan rangkaian aturan kami dalam salah satu kasus tersebut dikirim ke agen untuk ditriase, lalu perbaikan aturan diusulkan untuk disetujui oleh anggota tim keamanan kami.

Dalam satu hari, Decider membaca 1 miliar token di 7.000 sesi agen dan mengidentifikasi kelemahan yang menghasilkan 14 perbaikan aturan, 6 di antaranya disetujui dan dirilis dalam dua hari. Saat diputar ulang pada log selama seminggu, perbaikan tersebut memangkas volume aturan tersibuk kami sebesar 52%, dan aturan yang diperluas berhasil menangkap sekitar 40% lebih banyak tindakan sah untuk diselidiki.

Memantau rollout RL

Saat kami melakukan post-training model dengan reinforcement learning, metrik agregat seperti reward akhir tidak menjelaskan mengapa sebuah rollout (satu upaya individual untuk menyelesaikan tugas) berhasil atau gagal. Rollout dapat kehilangan reward secara tidak adil karena layanan alat atau kotak pasir gagal, atau menerima reward yang tidak layak jika evaluator melewatkan klaim yang tidak didukung, seperti nilai karangan yang tidak pernah dikembalikan oleh alat mana pun.

Kami menggunakan Decider untuk memantau rollout dalam kasus-kasus ini. Kode terlebih dahulu mengidentifikasi bagian rollout yang perlu diperiksa lebih dekat: panggilan alat yang gagal beserta penalaran di sekitarnya, kode yang berjalan tanpa error, atau jawaban akhir. Decider kemudian menjawab pertanyaan pilihan ganda tentang setiap bagian, misalnya apa yang gagal dalam suatu langkah (layanan alat, situs eksternal, kotak pasir, harness, atau kode milik agen itu sendiri) dan apakah agen menafsirkan hasilnya dengan benar. Kami menggabungkan semua pertanyaan tentang satu bagian ke dalam satu permintaan dan menyimpan probabilitasnya alih-alih putusan, sehingga kami dapat menyesuaikan ambang batas nanti tanpa perlu mengirim kueri ke Decider lagi. Monitor hanya mengamati dan mendiagnosis: monitor tidak pernah mengubah reward atau menghentikan proses yang sedang berjalan.

Penyaringan kualitas halaman

Saat merayapi halaman web untuk diindeks dan disajikan kepada pengguna, banyak halaman yang kualitasnya terlalu rendah untuk berguna. Ini termasuk dinding anti-bot, CAPTCHA, dan halaman error, serta halaman web yang dimuat dengan benar tetapi tidak berisi informasi bermanfaat apa pun, seperti spam, konten pengisi SEO, atau halaman yang hanya berisi navigasi. Halaman berkualitas rendah ini perlu diidentifikasi dan disaring dari indeks kami.

Dengan Decider, kami dapat menilai kualitas halaman saat merayapinya. Dalam forward pass yang sama, kami juga menjalankan serangkaian tugas klasifikasi lain, seperti mengidentifikasi domain dan audiens sasaran konten, serta menentukan apakah konten tersebut mengandung informasi yang berbahaya, ilegal, atau dapat mengidentifikasi seseorang secara pribadi. Dibandingkan dengan menggunakan LLM sebagai penilai, Decider jauh lebih cepat dan murah.

Contoh ilustratif permintaan kualitas halaman: Informasi berguna, target audiens, konten berbahaya atau ilegal, dan informasi identitas pribadi dinilai dari halaman yang sama.

Selain penggunaan internal ini, Decider juga cocok untuk alur kerja seperti berikut.

QA visual

Karena Decider dapat membaca gambar, model ini juga berfungsi sebagai pemeriksa visual yang meninjau perubahan gaya pada halaman web atau aplikasi dan mengidentifikasi kesalahan. Decider dapat meninjau tangkapan layar halaman untuk menemukan teks yang terpotong, elemen yang tumpang-tindih, dan tata letak yang rusak sebelum perubahan dirilis, atau menandai grafik yang desainnya dapat menyesatkan pembaca atau melanggar panduan merek.

Navigasi browser

Agen dapat menggunakan Decider untuk keputusan-keputusan kecil di dalam tugas yang lebih besar. Agen browser dapat mengirim tangkapan layar di setiap langkah dan menerima informasi terperinci tentang kondisi halaman serta hasil yang diharapkan dari setiap tindakan yang mungkin dilakukan.

Merencanakan tugas riset

Pertanyaan pengguna bisa sangat beragam tingkat kompleksitasnya, begitu pula kedalaman pencarian yang perlu dilakukan untuk menemukan jawaban. Decider dapat memperkirakan hal ini sebelum pencarian dimulai, sehingga lebih sedikit sumber daya yang perlu dihabiskan untuk pertanyaan sederhana.

Memulai

Decider mengembalikan probabilitas. Ambang batas keputusan yang tepat bergantung pada aplikasinya. Frekuensi label serta biaya relatif dari positif palsu dan negatif palsu berbeda-beda di setiap kasus penggunaan. Oleh karena itu, kami menganjurkan pengguna untuk menyesuaikan ambang batas pada set pengembangan berlabel yang kecil dan representatif, alih-alih berasumsi bahwa batas tetap akan bekerja sama baiknya di semua tugas.

Kami merekomendasikan penggunaan Decider v1.3 untuk penilaian yang bernuansa, rubrik terperinci, dan alur kerja yang kesalahannya berdampak mahal. Pilih Decider Flash v1.3 untuk routing, pelabelan, dan pemfilteran bervolume tinggi yang latensi dan biayanya menjadi batasan utama. Evaluasi kedua model pada contoh representatif dari beban kerja Anda, lalu pilih model yang memenuhi persyaratan kualitas, latensi, dan anggaran Anda.

Kedua model tersedia sebagai bobot yang dapat diunduh di Hugging Face dengan lisensi Apache, melalui OpenRouter, dan Perplexity Decisions API.

Sitasi

BibTeX
@online{perplexity2026PerplexityDecider,
  author = {{Perplexity} and Antoine Chaffin and Jonas Golde and Louis Milliken and Sarah Eslami and Markus Krimmel and Nandor Licker and Aleksandr Nikolenko and Ron Heichman and Bo Wang and Jarrod Bryan and Jeremy Yang and Denis Yarats},
  title = {{Perplexity Decider}},
  date = {2026-11-12},
  url = {https://www.perplexity.ai/hub/blog/perplexity-decider}
}