Perplexity Decider

Decider v1.3とDecider Flash v1.3をリリースします。これらは、以前の意思決定モデルであるv1、v1.1、v1.2、Flash v1.2の後継モデルです。

Decider Flash v1.3は、Decider v1.3から蒸留された小規模なモデルです。両モデルは、ApacheライセンスのもとHugging Faceで公開されているほか、OpenRouterやPerplexity Decisions APIからも利用できます。

Perplexity Deciderは、TypeSafe AIのSystem One ModelであるJevから着想を得ています。順序付きまたは順序なしのラベルを用いた二値分類と多クラス分類をサポートし、アプリケーションが入力の分類、ルーティング、ランク付け、評価に利用できる確率を返します。

v1.3の両モデルは、双方向アテンション、より厳選された学習データ、改良された学習レシピにより、幅広いテキストおよびビジョンタスクで性能と堅牢性が向上しています。また、固有表現認識、個人情報の識別、抽出型質問応答タスクにおいて、選択されたコンテンツをハイライトする新機能locateも導入します。

この記事では、Deciderの学習方法と評価方法を説明し、Perplexity社内での活用方法を紹介します。

意思決定モデルとは？

意思決定モデルは汎用の分類器です。入力と、それぞれに回答候補が設定された一連の質問を与えると、各質問について回答に対する確率分布を返します。次の3種類の質問タイプに対応しています：

• はい／いいえ：二値の意思決定。
• 多肢選択：カスタムの多クラスラベル。
• スコア：順序付きレベル。

意思決定モデルは、幅広い分類およびスコアリングタスクに対応しています：

• 出力の判定：忠実性、品質、安全性の評価。
• ルーティング：難易度に応じた、小規模または大規模なモデルへのリクエストの振り分け。
• モデレーションとセキュリティ：有害なコンテンツ、フィッシング、ツール出力に含まれるプロンプトインジェクションの検出。
• フィルタリングとタグ付け：大量のコンテンツの整理。
• 検索とリランキング：関連性に基づく検索結果のスコアリング。

これらのタスクの多くは、自由形式のテキスト生成を必要としないにもかかわらず、これまではLLMのような生成モデルで処理されてきました。決定モデルは、LLMとタスク固有の分類器の中間に位置します。同じ入力に関する複数の質問の確率を1回のフォワードパスで返すため、トークン単位の回答生成を回避し、質問間で計算を共有できます。タスク固有の分類器とは異なり、自然言語のプロンプトによって新しいタスクに対応できます。この柔軟性は、共通の質問応答形式で多様なタスクをトレーニングすることで獲得されたものです。

学習

生成型LLMを意思決定モデルに変える

Deciderは、強力な生成LLMバックボーンを適応させて構築しています。この適応について説明するために、まずリクエストの表現方法を説明します。以下に示すように、リクエストは共有コンテキスト（ステート）と複数の質問で構成されます。ステートはすべての質問で再利用されます。

たとえば、ドキュメントとその要約が与えられた場合、1つのリクエストで、要約がドキュメントを忠実に表しているかどうかと、それが専門家向けか一般読者向けかを尋ねることができます。ステートの後に続く各質問ブロックには、質問とその回答候補が含まれ、各回答候補にはA、B、Cなどの事前定義されたラベルトークンが割り当てられます。特殊な<|marker|>トークンは、モデルの予測を読み出す位置を示します。この位置で、学習済みの線形出力層（決定ヘッド）が隠れ状態を質問の回答選択肢に対するスコアにマッピングし、そのスコアが確率に変換されます。

拡大

出力層はベースモデルから初期化します。この層は通常、語彙全体から次のトークンをスコアリングするものですが、A、B、Cなどの事前定義された選択肢トークンに対応する行のみを残します。この枝刈りした層を、<|marker|> の隠れ状態を回答スコアに変換するように学習させます。すべての分類問題は多肢選択として定式化できるため、このアプローチですべての分類問題に対応できます。

学習には、多様なタスク（感情、自然言語推論、意図検出、エンティティマッチング、モデレーション、ファクトチェック、レーティングなど）にわたる数百の公開データセットを用い、各例を前述の統一フォーマット、すなわちステート、1つ以上の質問、その選択肢、ターゲットに変換します。ターゲットは、正解ラベルがある場合は単一の正しい選択肢とし、それ以外の場合は選択肢に対する確率分布とすることができます。

v1.3では、事前に定義された選択肢から選ぶのではなく、ステートからテキストを抽出するlocateを導入します。locateの質問では、「場所」のような短いラベル、または「求人の勤務地となる都市名を抽出してください」のような指示を使って、何を見つけるかを記述します。モデルは、ステートから完全に一致するテキストを、その開始および終了の文字位置とともに返します。一致するものが見つからない場合は、空のリストを返します。

拡大

ステートが共有されるため、1つのリクエストで、同じ入力に関するlocate、分類、スコアリングの質問を組み合わせることができます。たとえば、ある求人でシニアレベルの経験が必要かどうかを尋ねると同時に、必要なスキルを抽出できます。

双方向アテンション：モデルが両方向から読めるようにする

当社のモデルは強力な事前学習済み生成型バックボーンを出発点としています。その因果的アテンションでは、各トークンは自分自身とそれより前のトークンにのみ注意を向けることができます。アブレーション研究により、バックボーンのフルアテンション層を双方向にすると性能が向上することがわかったため、この設計を採用し、各トークンが入力全体のコンテキストを取り込めるようにしました。

双方向アテンションでは、ステートと質問をどのように相互作用させるべきかという、もう1つの設計上の選択が生じます。性能、回答の安定性、キャッシュの再利用にそれぞれ異なる影響をもたらす、3つのアテンションパターンを検討しました：

• すべてがすべてを参照（v1.2）：ステートとすべての質問が、完全な双方向アテンションでまとめて処理されます。ステートに対する計算は共有されますが、ある質問への回答が、他に何を尋ねるかによって変わる可能性があります。
• 独立した質問（v1.3）：ステートはすべての質問に注意を向けますが、各質問はステートと自身のトークンにのみ注意を向けます。質問同士が共有ステートを介して間接的に影響し合う可能性は残りますが、結果はより安定します。
• 完全キャッシュ可能：ステートは自分自身のみにアテンションし、各質問はステートと自身のトークンにアテンションします。ステートは質問に依存しないため、リクエスト間で再利用でき、プロンプトキャッシュを活用できます。ステートが質問を参照できることは多くのタスクで非常に重要なため、デフォルトではこの方式を使用していませんが、少量のファインチューニングでモデルをこの方式に切り替えることができます。

最終的に、高い性能と安定性を理由に、独立した質問を採用しました。

拡大

学習レシピ

トレーニングは、両方のモデルサイズで3つのステージに分けて行います。まずQwen3.8-27Bをベースとした大きいモデルを大規模データセット上でクロスエントロピーを用いてトレーニングし、次にそれをより小さいQwen3.5-4Bモデルへ蒸留します。

第1段階はジェネラリスト学習で、大規模なコーパスでモデルをフルファインチューニングします。この段階では、モデル全体の性能向上に役立ち、特定のベンチマークに特化していないデータのみを採用するため、ベンチマークの学習用分割はすべて除外しています。

この汎用モデルのトレーニング後、LoRAを用いて、より細かな第2ステージを実施します。このステージで使用するデータは、特定のドメインやタスクを対象としています。改善が限定的な場合や、他のタスクで性能低下が見られる場合には、データを第1ステージではなく第2ステージで追加します。LoRAを使用するのは、汎用モデルから大きく逸脱し、特定のドメインに適合させるために性能を損なうリスクを避けるためです。目標は、バックボーンの汎用的な知識を保持しながら性能を向上させることです。また、LoRAをベースモデルにマージする際には重みを用いることで、逸脱をより精密に制御し、ドメイン内での改善よりもホールドアウト指標を優先しています。

最後に、ビジョン固有のステップを追加します。第2段階と同様に、このビジョンステップも細粒度の特化ステップの1つとして扱い、重み付けしてベースモデルにマージし戻すLoRAアダプターを使用します。一部のビジョン能力は、テキスト性能を犠牲にして得られる場合があります。モデルはテキストでの利用がはるかに多いため、ビジョンの指標よりもテキストの指標を優先しています。

両方のテキスト段階では、それぞれ異なるランダムシードを用いた3回の実行から得た重みの平均を使用します。これにより、統合されたモデルの性能と堅牢性が向上することがわかりました。

最終的な大規模モデルが得られたら、同じ3ステージのトレーニング手順を小規模モデルにも適用します。ここでは大規模モデルが教師となり、その予測出力分布がゴールドラベルの代わりとなります。小規模モデルは、自身の予測と教師の予測との間のKLダイバージェンスを最小化するようにトレーニングされます。この蒸留目的関数は、同じトレーニングデータにおいてクロスエントロピーを上回る性能を示します。クロスエントロピーは専用のトレーニングデータがあるベンチマークでは優れた性能を発揮しますが、ホールドアウトデータへの汎化性能は劣ります。私たちは、蒸留がゴールド以外の選択肢に対する確信度も含めて教師の出力分布をより適切に転移する一方、クロスエントロピーはベンチマーク固有のトレーニング分布への過学習を促すという仮説を立てています。そのため、KLベースの蒸留目的関数を採用しています。

トレーニングデータとテストデータの混入（コンタミネーション）を軽減するため、使用する評価のいずれかと重複する可能性のあるトレーニングサンプルはすべて除去しています。一部の公開トレーニングデータセットには、評価データセットの大部分が含まれている場合があるため、これは重要です。また、得られた改善が信頼できるものであり、学習されたバイアスによるものだけではないことを確認するため、広範なバイアス監査とバイアスの除去も実施しています。

情報抽出機能の追加

locate 機能 は、通常のリクエストへの回答方法を変えることなく、テキストから固有表現などの情報を抽出します。そのために、追加の学習段階を導入し、Deciderに新しい特殊トークン<|locate|>、スパンヘッド、LoRAアダプターを追加します。

<|locate|>の埋め込みは、前の学習段階で学習した<|marker|>から初期化します。元のバックボーンの重みと決定ヘッドは凍結したまま、この新しい埋め込み、スパンヘッド、LoRAアダプターのみを学習します。要求された各フィールドには、それぞれ専用の<|locate|>トークンが割り当てられます。

スパンヘッドは、<|locate|>の表現とステートトークンの表現を組み合わせて、一致するスパンの開始位置と終了位置、およびどの開始・終了のペアが対応するかをスコアリングします。また、<|locate|>トークンの表現を用いて、これらのスコアに対するフィールドごとのしきい値も予測します。選択されたスパンは、元のテキスト内の文字位置として返されます。

スパンヘッドは、すべての正解スパンをしきい値より上に、しきい値をそれ以外のすべてのスパンより上に押し上げる、改良版のInfoNCE損失でトレーニングします。この損失には2つの項があります。1つ目の項は、正しいスパンのスコアをしきい値および誤ったスパンより上に押し上げます。2つ目の項は、しきい値を誤ったスパンのスコアより上に押し上げます。回答のないフィールドには2つ目の項のみが適用され、これによりモデルは空のリストを返すことを学習します。

固有表現認識、PII検出、抽出型質問応答など、さまざまなスパン抽出タスクを組み合わせて学習します。フィールドの説明を短いラベルから詳細な指示までさまざまに変化させることで、モデルが固定のラベルセットを暗記するのではなく、リクエストに従うことを学習するようにしています。

Locateはモデルに構造的に異なるタスクを教えるものであり、モデルがすでに得意としていることを損なわずに追加したいと考えています。locateアダプターをバックボーンにマージすると、決定リクエストでの性能が一部低下します。これを抑えるため、以前のステージからのリプレイデータを増やすことや、決定リクエストに対するモデルの出力を元のモデルの出力に近い状態に保つ補助目的関数など、さまざまな検証を進めています。しかし、現時点ではマージはまだロスレスではないため、アダプターはマージせずに保持し、locateリクエストの場合にのみ有効化しています。

評価

Decider v1.3とDecider Flash v1.3を、Hugging Face Decision Index、Vals AIのClaimBench、Artificial Analysis Decision Indexの外部ベンチマークで評価しています。

これらの評価全体を通じて、私たちのモデルは高い性能を示しています。これらのリーダーボードには非公開のタスクも含まれていますが、繰り返しの提出やリーダーボードのフィードバックに基づく反復的なチューニングによって攻略される可能性は残ります。これらのリーダーボードを補完するため、非公開の本番タスクと、公開されている非ベンチマークデータセットから抽出したホールドアウト評価を組み合わせた社内評価スイートでもモデルを評価しています。これらの評価は、公開ベンチマークを超えた汎化性能を追加で確認する手段となり、より広範な改善と、見慣れた評価スイートに特有の改善とを区別するのに役立ちます。

社内では、分類、スコアリング、リランキング、エンティティ抽出など、さまざまな領域とタスクにまたがる 200を超えるタスクからなるスイートを構築しました。Deciderの実環境での性能を公正に評価するため、すべての評価はタスク固有のファインチューニングを行わないゼロショットで実施しており、モデルの改善すべき点を明確に把握できます。

クエリ分類

Perplexityでは、マルチヘッド分類システムを使用して各ユーザークエリを処理しています。各クエリはまず、特徴抽出器として機能する埋め込みモデルに渡されます。得られた埋め込みは、二値分類器とマルチラベル分類器の両方を含む、複数の独立した分類ヘッドに入力されます。たとえば、あるヘッドは、ユーザークエリでウェブ検索を実行すべきかどうかを判定します。

最先端のLLMによって独立して再ラベル付けされた参照を用いた63の分類タスクにおいて、Decider v1.3は平均正解率91.6%を達成し、当社の本番環境の分類器を6.54パーセントポイント上回りました。Decider Flash v1.3も本番環境のベースラインを上回り、Decider v1.3はJev 1.14も上回りました。

拡大

領域特化型の分類

公開データセットから領域特化型の評価スイートを構築し、意思決定モデルの分類性能を7つの領域で評価しました：主張の検証（6タスク）、医療（7）、サイバーセキュリティ（8）、プログラミング（16）、行政（7）、法律（9）、金融（9）。

たとえば、「Pythonプログラムの時間計算量を判定する」や、「年次財務報告書を使って、企業の使途制限のない現金が今後12か月以内に返済期限を迎える債務元本をまかなえるかどうかを判断する」といったタスクです。Decider v1.3は7つの領域すべてでトップとなり、Jev 1.14を金融で最大12.9パーセントポイント、法律で9.3ポイント上回りました。Decider Flash v1.3は、金融、プログラミング、法律ではJev 1.14に及ばず、その他の領域ではほぼ同等の性能でした。

拡大

検索とリランキング

検索はPerplexityの中核です。当社では、モデルのリランキング性能を評価するため、幅広い検索タスクのスイートを維持しています。各タスクでは、まず埋め込みモデルのプールを使用して、各コーパスから上位50件の候補ドキュメントを取得します。次に、Deciderを使ってこれらの候補をリランキングし、その性能を強力なリランカーのベースラインであるQwen3-Reranker-8Bと比較します。

Deciderは、ゼロショットのポイントワイズ設定で評価しています。モデルを使って各クエリとドキュメントのペアを独立して直接スコアリングし、関連性に基づいてドキュメントをランク付けします。72の検索タスクにおいて、Decider v1.3は平均nDCG@10で83.99を達成し、Qwen3-Reranker-8Bを1.81ポイント、Jev 1.14を2.24ポイント上回りました。

BEIRベンチマークでは、両モデルともQwen3-Reranker-8BをnDCG@10でそれぞれ8.78ポイント、7.05ポイント上回りました。Jev 1.14と比較すると、Decider v1.3は1.33ポイント高く、Flash版は0.4ポイント低いスコアでした。

拡大

多言語分類

英語以外での意思決定モデルの性能を評価するため、8つの公開データセットから得た19の言語別タスクで構成される多言語分類ベンチマークを構築しました。このベンチマークには、ドイツ語、スペイン語、フランス語、イタリア語、ロシア語、日本語、韓国語、中国語の8言語にわたる46,484件の例が含まれ、意図検出、トピック分類、感情分析、自然言語推論、言い換え検出、攻撃的表現の検出、文法的容認性を対象としています。

各言語内のタスク全体の平均正解率を、各タスクを均等に重み付けして報告しています。Decider v1.3は8言語すべてで、Decider Flash v1.3は6言語でJev 1.14を上回り、平均タスク正解率はDecider v1.3が88.16%、Decider Flash v1.3が86.50%、Jev 1.14が85.41%でした。

拡大

NER、PII、抽出型QA

locate機能は、さまざまな領域、入力形式（テキスト、表、構造化ドキュメント）、指示（短いラベル、質問、詳細な説明）にわたる抽出能力を検証する17のドメイン外タスクで評価しています。対象領域は、Wikipediaから学術論文、サイバー脅威レポート、テクニカルサポート、プライバシーポリシー、履歴書、法的契約書まで多岐にわたります。リクエストは、「人物」や「メールアドレス」のような短いラベル名から、表やサポートチケットに関する質問、さらにはNDAの当事者や請求書の合計金額といった構造化抽出のための詳細なフィールド説明まで、さまざまです。

NERとPIIは、予測スパンが正解の境界と完全に一致することを求める完全一致スパンF1で評価します。抽出型QAでは、重複する回答テキストに部分点を与える文字レベルF1を使用し、構造化抽出では、正しく抽出されたフィールドの割合であるフィールド精度を使用します。CV（履歴書）解析については、NERとPIIの完全一致スパンF1スコアの平均を用います。

当社のモデルを、さまざまなサイズの汎用抽出モデルであるGLiNER large v2.5（0.5B）、Liquid d1（2B）、CloudflareのClairic（サイズ非公開）と比較しました。Decider v1.3の平均スコア（各タスクの主要指標を使用）は69.0、Decider Flash v1.3は63.6で、Liquid d1の43.3、Clairicの41.5、GLiNER large v2.5の33.6を上回りました。両Deciderモデルは、すべてのカテゴリでトップとなりました。

拡大

画像分類

Deciderはv1からビジョンタスクをネイティブにサポートしています。テキスト以外での性能を評価するため、請求書、手紙、履歴書などの文書分類に特に重点を置いた、5つのタスクからなるベンチマークスイートを構築しました。このスイートでは、衛星画像分類、テクスチャ分類、ペットの品種分類、動物のカウントも対象としています。

Decider v1.3は5つの視覚タスク全体で平均正解率76.99%を達成し、Jev 1.14を1.47パーセントポイント上回りました。Decider Flash v1.3は72.77%を達成し、より小規模なモデルでも視覚分類が可能であることを示しています。

拡大

実環境での意思決定リクエスト

Perplexity Decision APIの提供開始から最初の18日間に送信されたリクエストのうち、重複を除去しPIIをマスクした100万件をサンプリングしました。各リクエストには同じステートに関する複数の質問を含めることができるため、サンプルには合計2,318,887件の個別の質問が含まれます。すべてのリクエストは、研究目的での利用について明示的なユーザー許可を得たうえで含めています。

本番環境のリクエストには正解ラベルが付いていないため、最先端のLLMジャッジを使用して参照回答を生成し、各モデルとそれらとの一致度を測定しました。また、リクエストを10のタスクカテゴリに分類しました：情報抽出、ドメイン分類、感情分析、意図とルーティング、関連性ランキング、コンテンツモデレーション、品質・コンプライアンスレビュー、エンティティマッチング、ビジネス分析、「その他」カテゴリです。この内訳から、実環境のユースケースによって性能がどのように異なるかがわかります。

タスクの構成には偏りがあり、情報抽出が425,402問、ドメイン分類が409,564問、感情分析が344,158問を占めています。これら3つのカテゴリを合わせると、サンプリングされた質問の50.8%になります。

Decider v1.3はジャッジとの一致率が93.98%と最も高く、Decider v1.2は93.68%、Jev 1.14は93.35%でした。Decider v1.3とJev 1.14は、ドメイン分類と感情分析ではほぼ互角で、その差はそれぞれ0.34パーセントポイントと0.07パーセントポイントでした。関連性ランキングではJevが0.69ポイントリードしている一方、Decider v1.3は情報抽出（サンプル中で最も多いタスク）で0.93ポイント、意図とルーティングで1.21ポイントリードしています。

拡大

下のグラフは、同じ100万件の本番リクエストを実行した際に報告されたコストを比較したものです。各リクエストには複数の質問を含めることができるため、ここでの単位は個々の質問ではなくリクエストです。

拡大

堅牢性

372問の多肢選択式問題でラベル感度を評価し、モデルごとに4,788件のリクエストを送信しました。各問題の意味を保ったまま、選択肢の並べ替え、回答テキストへのラベルの再割り当て、ラベル名の変更を行い、モデルの意味的な回答が変化するかどうかを確認しました。フリップ率が低いほど安定性が高いことを示します。

各変換において、Decider v1.3の回答が変わったのはわずか0.27%の質問で、Jev 1.14では2.69～4.84%でした。また、サービング時のばらつきを測定するために同一の入力を繰り返したところ、Decider v1.3では変化がなかったのに対し、Jev 1.14では1.88%の質問で回答が変わりました。

拡大

Deciderの活用方法

Deciderは、高速で構造化された意思決定を必要とするワークフロー向けに構築されています。このセクションでは、Deciderを活用して私たちの働き方に意味のある影響をもたらす方法を探ります。ここでは特に際立った事例をいくつか紹介します。

自己改善するセキュリティルール

社内では、すでにDeciderを活用してセキュリティポリシーの改善に取り組んでいます。

当社のエージェントのアクティビティは記録され、問題のある挙動を特定するために一連のルールベースのチェックが実行されます。ルールベースのアプローチにより、追加のレイテンシをほとんど生じさせずにエージェントをリアルタイムで監視できます。オフラインでは、Deciderを使ってこれらの記録されたエージェントログのサンプルを確認します。問題のある挙動が検出されなかった場合、Deciderはルールセットが見逃したものがないかを確認し、アラームが発生した場合は、それが誤検知だったかどうかを確認します。いずれの場合でもルールセットが正しく機能しなかった記録はエージェントに送られてトリアージされ、ルールの修正案が作成されます。修正案はセキュリティチームのメンバーの承認を経て適用されます。

Deciderは1日で7,000件のエージェントセッションにわたって10億トークンを読み取り、14件のルール修正につながる欠陥を特定しました。そのうち6件は2日以内に承認され、本番に反映されました。1週間分のログで再生したところ、これらの修正によって最も件数の多いルールの発生量が52%減少し、対象を広げたルールでは、調査すべき正当なアクションを約40%多く捕捉しました。

拡大

RLロールアウトの監視

強化学習でモデルをポストトレーニングする際、最終報酬のような集計指標では、ロールアウト（タスクに対する個々の試行）が成功または失敗した理由を説明できません。ツールサービスやサンドボックスの障害によって不当に報酬を失うこともあれば、評価者が根拠のない主張（どのツールも返していない捏造された値など）を見落とした場合には、本来得るべきでない報酬を受け取ることもあります。

こうしたケースに備えて、Deciderを使ってロールアウトを監視しています。まずコードによって、ロールアウトの中で詳しく調べるべき部分を特定します。たとえば、失敗したツール呼び出しとその前後の推論、エラーなしで実行されたコード、最終回答などです。次にDeciderが、各部分について多肢選択式の質問に回答します。たとえば、あるステップで何が失敗したか（ツールサービス、外部サイト、サンドボックス、ハーネス、エージェント自身のコードのいずれか）や、エージェントが結果を正しく解釈したかどうかといった質問です。特定の部分に関するすべての質問を1つのリクエストにまとめ、判定結果ではなく確率を保存することで、Deciderに再度問い合わせることなく後からしきい値を調整できるようにしています。モニターは観察と診断のみを行い、報酬を変更したり実行を停止したりすることはありません。

拡大

ページ品質フィルタリング

ウェブページをクロールしてインデックス化し、ユーザーに提供する際、多くのページは品質が低すぎて役に立ちません。これには、ボット対策ウォール、CAPTCHA、エラーページのほか、正しく読み込まれていても、スパム、SEO目的の埋め草、ナビゲーションのみのページなど、有用な情報を含まないウェブページも含まれます。こうした低品質なページを特定し、インデックスから除外する必要があります。

Deciderを使えば、クロールしながらページの品質を判定できます。同じフォワードパスの中で、コンテンツのドメインや想定読者の特定、有害な情報・違法な情報・個人を特定できる情報が含まれているかどうかの判定など、その他の一連の分類タスクも実行します。LLMジャッジを使う場合と比べて、Deciderは大幅に高速かつ低コストです。

拡大

こうした社内での用途以外にも、Deciderは次のようなワークフローに適しています。

ビジュアルQA

Deciderは画像を読み取れるため、ビジュアルチェッカーとしても機能し、ウェブページやアプリのスタイル変更をレビューして不具合を特定できます。変更をリリースする前にページのスクリーンショットを確認して、テキストの見切れ、要素の重なり、レイアウトの崩れがないかをチェックしたり、デザインが読み手に誤解を与えたりブランドガイドに違反したりする可能性のあるグラフにフラグを立てたりできます。

拡大

ブラウザナビゲーション

エージェントは、大きなタスクの中にある小さな判断にDeciderを利用できます。ブラウザエージェントは、各ステップでスクリーンショットを送信し、ページの状態や、実行可能な各アクションの想定される結果に関する詳細な情報を受け取ることができます。

拡大

研究タスクの計画

ユーザーの質問の複雑さは大きく異なり、回答を見つけるために必要な検索の深さも同様に異なります。Deciderは検索開始前にこれを推定できるため、シンプルな質問に費やすリソースを減らすことができます。

拡大

はじめに

Deciderは確率を返します。適切な判定しきい値はアプリケーションによって異なります。ラベルの出現頻度や、偽陽性と偽陰性の相対的なコストは、ユースケースごとに異なります。そのため、固定のカットオフ値がすべてのタスクで同じようにうまく機能すると想定するのではなく、小規模で代表的なラベル付き開発セットでしきい値を調整することをお勧めします。

微妙な判断、詳細な評価基準（ルーブリック）、エラーのコストが高いワークフローには、Decider v1.3の使用をおすすめします。レイテンシとコストが主な制約となる大量のルーティング、ラベリング、フィルタリングには、Decider Flash v1.3をお選びください。ワークロードの代表的な例で両方のモデルを評価し、品質、レイテンシ、予算の要件を満たすモデルを選択してください。

両モデルは、ApacheライセンスのもとHugging Faceでダウンロード可能な重みとして公開されているほか、OpenRouterやPerplexity Decisions APIからも利用できます。

引用

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