詳しい解説 · 読了目安 7 分
Perplexityのエージェント評価ガイド：実行履歴と採点者の校正でスコアを読む
公式の6段階ガイドは、実際の失敗、固定したテストデータ、人間に照らして校正した採点者を結び付ける。一度の正答は信頼性の証明ではない。
- 当サイトの公開日
- 原典の公開日
- 出典確認日
Perplexityが10月22日に公開したのは、エージェント評価の組み立て方を説明するガイドであり、新モデルや新しいベンチマーク結果の発表ではない。部品調達の例から、行動、再現性、採点の確かさを理解せずにスコアは解釈できないことが分かる。
ニュースを聴く
この記事を読み上げるか、ニュースを続けて聴けます。
読み上げを準備中…
端末の音声
読み上げはブラウザーまたは端末が処理します。AISubHub は文章を音声 API に送りません。利用できる音声やロック画面での再生は端末によって異なります。
再開時に短い部分を繰り返す場合があります。
要点
- 最終回答がもっともらしくても、無許可の操作や漏えいした解答の利用を隠している場合がある。結果と経路の両方を確認する。
- 約100件の履歴はエラー分析の目安で、必須件数ではない。pass@kは明示したk回のうち少なくとも1回の成功を指す。
- 同じ保存済み実行を繰り返し採点して採点者の変動を分離する。回帰試験、運用監視、A/Bには異なる役割がある。
正しい回答には何が隠れ得るのか
在庫アシスタントは、一見適切な部品を勧めながら承認規則を飛ばすかもしれない。Perplexityの工場例では、承認済み部品の欠品や古い供給元情報に適切に対処すべきで、根拠のない代替品を選んではならない。ガイドは仕事の成功条件と、成功に見えても許容できない手段を定義し、分野の専門家に実務と一致するか確認させる。文章が流暢でも権限順守は証明できない。
評価対象には検索した情報、ツール呼び出し、中間判断も含まれる。タスク成功、行動の正しさ、回答品質は別の性質で、信頼性は反復試行や境界的な入力にも関わる。成功した仕事の費用には時間、token、ツール呼び出しも影響する。当サイトの分析：公開判断には、読みやすい回答への好みではなく、業務フロー全体の受け入れ条件が必要になる。
どの失敗をテストに変えるべきか
出発点は、入力、取得した証拠、行動、出力を含む実際の実行履歴だ。専門家が各実行の最初の意味のある誤りを記し、似た観察を失敗類型へまとめる。LLMは分類候補を提案できるが、優先順位には頻度と重大性を使う。重要な失敗は、入力、開始条件、期待結果、採点基準を備えた再利用可能なケースにする。修正対象を都合のよい合成問題に置き換えないためである。
約100件は実用上の目安で、普遍的な標本要件や統計的な信頼保証ではない。追加の履歴から意味のある新しい失敗パターンが出なくなる理論的飽和に達すれば、早く止めてもよい。公開前は合成例で始められるが、利用データが得られたら取り込む。標準ベンチマークは補助になる一方、意外な合否は問題や正解データを調べてから解釈すべきだ。
二つの版を同じ条件で比べるには
図の構成は、保存した保守依頼と固定した在庫・承認部品データを分ける。maintenance_request_01.jsonが入力と期待結果、inventory_snapshot.jsonとapproved_parts.jsonが比較用データ、run_evals.pyが実行と検査を担い、resultsが出力、履歴、合否を保存する。これは構成例であり、当サイトが動かした本番システムや配布ソフトではない。当サイトの分析：比較中に在庫が変われば、エージェントだけでなく問題も変わる。
最終文だけでなく検索工程とツール操作を残す。同じ入力でも結果は変わり得るため、危険度、頻度、修正難度に応じて反復する。pass@1は単一試行の成功、pass@kは指定したk回のうち少なくとも1回成功することを表す。kを必ず示す。複数回から正答が一つ見つかっても、毎回の成功やエージェント自身が正答を選べることは保証しない。
各条件を誰に採点させるのか
厳密に検査できる条件にはコードを使う。部品が承認リストにあるか、フィールドやツール引数が有効か、データベースの最終状態が期待どおりか、といった検査だ。規則は明確だが、主観的な判断をすべて確実に処理できるわけではない。代替を勧められない説明の妥当性など文脈依存の判断には、明示的な評価規準を持つLLMを使える。規準には許容される行動と判断の証拠を記す。
専門的・論争的な判断には人間の専門家が必要で、一つの実行で複数の採点方式を組み合わせてもよい。プラットフォームを選んでも、事業に重要な失敗類型は決まらない。当サイトの分析：権限確認と説明品質を分けると合成スコアの意味を理解しやすい。LLMによる文章への好評価を、承認リストの厳密な照合の代わりにしてはいけない。この分担の精度向上は実測されていない。
エージェントと採点者の誤りをどう分けるか
ガイドの校正は5段階だ。入力、出力、履歴を集め、専門家が独立に判断し、LLM採点者を実行し、双方を比較し、不一致を調べて規準を直した後、新しい例で確かめる。人間の判断はこの工程の参照であり、無謬だという主張ではない。校正は採点者を評価することで、評価対象のエージェントをもう一度動かすことではない。
一貫性を調べるには、同一の保存済み実行とファイルを、エージェントを再実行せず何度か採点する。そうしなければ二種類の変動が混ざる。混同行列で検出した誤り、見逃し、適切な出力への誤警報を確認できる。人間の再確認は既存採点者が認識しない失敗も見つける。原文がリンクするベンチマーク研究は、当サイトでは独立に全文を読んだり再現したりしていない。
一つの修正はいつ公開の根拠になるか
保存入力で元の失敗を再現し、プロンプト、モデル、フローを狙って変更して、そのケースが直ったか確かめる。その後、残りのテスト一式を実行して従来成功していた動作の破損を探す。旧版と新版ではケースと採点基準を同じにする。assert、テスト基盤、CI/CDで検査と公開閾値を自動化できるが、基準が実際の製品リスクを捉えている証明にはならない。
公開後は校正済み採点者で本番履歴を抽出評価し、失敗類型を追跡し、人間が新しい誤りや特殊な要求を調べる。適切なA/Bは解決率や満足度など事業上の証拠を追加するが、評価の代替でも全根因の説明でもない。当サイトの分析：観察した失敗、反復可能な検査、回帰判断をつなぐ循環が重要であり、この方法論は新しい利用権や独立に測定した信頼性を示さない。
注目する理由
失敗、その証拠、採点者を保存すれば修正を検査可能にできる。フロー全体との比較を経て、実利用からさらに調整するための指針となる。
制約と提供状況
Perplexityの方法論と部品調達の構成例に基づく。本文と必要な構成図を確認したが、外部研究、本番エージェント、アカウントの権利は検証していない。精度、費用削減、普遍的な合格閾値は実測していない。
出典と根拠
AI を活用した編集記事を、記載した一次情報で確認しています。企業の主張は出典を明示し、掲載は推奨を意味しません。