01
グラウンディング性
提供されたコンテキストまたは参照回答によってクレームがサポートされているかどうかを確認します。
決定
1 つの答えが 3 つの異なる方法で失敗する可能性がある
チームが回答が合格または不合格になった理由を確認できるように、ルーブリックのディメンションを別にしておきます。
02
関連性
有用な回答と、質問から逸れた自信に満ちた回答を区別してください。
03
完全
すべてを 1 つのラベルにまとめることなく、回答が必要なポイントをカバーしているかどうかを尋ねます。
より安全なループ
スコアを信頼する前にジャッジを検証する
レビュー担当者が同意しない例から始めて、障害モードを測定してから、自動化のしきい値を選択します。
小規模な評価セットを作成する. 明確なパス、明確な失敗、および曖昧なケースを含めます。
人と比較する. 不一致を平均化するのではなく、ルーブリックの次元ごとに不一致を確認します。
不確実なケースのルートを決定する. 信頼性の低い決定やリスクの高い決定を人間のレビューキューに送信します。
回答 + 参照コンテキスト
“返答にはポリシーが記載されていますが、返金期間については記載されていません。”
回答 + 参照コンテキスト
→
入力された判定case 18
独自のルーブリックを使用する
並行して質問する
証拠を目に見える状態に保つ
01
答えを持ってきてください
生成された回答、質問、参考資料を 1 つの状態として送信します。
02
チェックに名前を付けます
品質のあらゆる側面について、焦点を絞った「はい/いいえ」、選択、または採点の質問をします。
03
結果をつなげる
評価実行の隣に、判定、信頼度、レビュー決定を保存します。
1 つのリクエストでルーブリック
1 つのリクエストでルーブリック
レビュー担当者が同意しない例から始めて、障害モードを測定してから、自動化のしきい値を選択します。
1 つのリクエストでルーブリック
POST /v1/evaluate{
"state": {
"question": "Can I get a refund?",
"answer": "Refunds are available within 30 days.",
"policy": "Refunds are available within 14 days."
},
"questions": {
"grounded": { "type": "noul", "instructions": "Is the answer supported by policy?" },
"complete": { "type": "score", "instructions": "How complete is the answer?", "criteria": ["missing", "partial", "complete"] }
}
}よくある質問
評価する前の質問
これは LLM にスコアを求めるのと同じですか?+
ワークフローは各基準を明示的に保ち、確率とともに入力された回答を返します。アプリケーションは、それらをどのように組み合わせるか、いつ人を関与させるかを決定できます。
独自の評価ルーブリックを使用できますか?+
はい。基準と回答オプションはリクエストの一部であるため、ルーブリックは製品またはレビュー ポリシーに一致します。
すべての結果を自動化する必要がありますか?+
いいえ。代表的な例を使用してしきい値を設定し、曖昧なケースや影響の大きいケースをレビューにルーティングします。
