利益:
- スキーマおよびルールベースの出力検証層を確立する機能
- 影響の大きい意思決定において、有意義に人間参加者を要求する能力
- 2 番目のモデルで検証および信頼しきい値ベースのルーティングを設計する機能
言語モデルは、流動的で説得力があり、多くの場合正確です。しかし、「説得力がある」ことと「正しい」ことは同じではありません。モデルは金額、日付、または JSON フィールドをサイレントに適合させることができます。これは幻覚と呼ばれます (モデルは現実には存在しない情報を自信を持って生成します)。エンタープライズ システムでは、その出力が次のステップ (支払い、電子メール、データベースの書き込み) に進むと、エラーが現実の世界に波及します。この単元では、出力がシステムに入力される前に検証レイヤーで出力をフィルタリングする方法と、影響の大きい意思決定において人間参加型の関与を必要とする方法を学習します。
出力の検証が必要なのはなぜですか?
モデル出力は、主に 2 つの方法で破損する可能性があります。フォーマット (予期された JSON スキーマに準拠していない、フィールドが欠落している/過剰である) とコンテンツ (フォーマットは正しいが、値が間違っている、つまり存在しない製品コード、論理的でない日付) です。セキュリティの観点からは 3 番目の側面があります。それは、悪意のある出力 (インジェクションまたはリークの結果として生成された悪意のあるコマンド) です。堅牢なシステムが 3 つすべてをドアで停止します。
注意: 「モデルは概ね正確である」は製造基準ではありません。検証のないシステムでは、1,000 件に 1 件のエラーでも、1 日あたり 100,000 件のリクエストで 1 日あたり 100 件のエラー トランザクションが発生することを意味します。
認証の層: ステップバイステップ
- スキーマの検証。出力が予期された構造に準拠していることをマシンで確認します。フィールドが存在するか、その型が正しいか、必須フィールドが入力されているか。
- ルール/ビジネス ロジックの検証。値はビジネスルールと一致していますか? (金額 > 0、日付は未来ではありません、製品コードはカタログに属しています。)
- リファレンス/ソース管理。モデルがアサーションを生成する場合、それをソースにリンクできますか? (RAG の見積もりは実際に文書内にありますか?)
- 2 番目のモデル (LLM-as-judge) による検証。独立したモデルは、出力を「正しい/不完全/危険」として評価します。
- 信頼のしきい値と方向性。モデルまたはバリデーターが信頼度が低いと報告した場合、出力は自動的に合格しません。人間に向けられています。
- 人間のコントロール。有効性が高いか安全性が低いかは、専門家の承認に依存します。
4 つのコピー可能なテンプレート
スキーム + 「分からない場合は補う」を組み合わせる:
次の JSON スキーマのみで応答を返します。「low」と書き込みます。決して正確であるかのように見積もりを書かないでください。
2 番目のモデルによる検証 (判定プロンプト):
あなたは独立したバリデータです。以下は <source> テキストと <claim> です。主張内のすべての数字と日付がソースにそのまま記載されているかどうかを確認してください。それぞれについて、「検証済み | ソースにない | ソースと矛盾します。」と言います。それらのうちの 1 つでも「存在しない/矛盾している」場合は、結果を「人間によるレビューが必要」としてマークします。<source>{{ text }}</source><claim>{{ model_output }}</claim>
信頼しきい値ルーティング ルール:
ルーティング ルール:- emin_misin = "高" AND 量 < 10,000 TL -> 自動処理 - emin_misin = "中" OR 量 10,000 ～ 100,000 TL -> 2 番目のモデル検証 - emin_misin = "低" OR 量 > 100,000 TL -> 人間の承認が必要
人間による監査の概要カード (レビューを高速化):
人に決定を提示するときは、次のカードを提示します。 - 何が提案されていますか? (一文) - どのような情報源に基づいていますか? (記事/文書参照)- 最も弱い 2 つの仮定は何ですか?- 承認された場合、それらを覆すことはできますか? (はい/いいえ)
弱いプロンプト / 強いプロンプト
下手なアプローチ
強力なアプローチ
「請求書から金額を差し引いてください」（フリーテキスト）
厳密な JSON スキーマ + null + trust フィールド
出力を支払いシステムに直接書き込む
スキーマ → ルール → 人間の承認 (必要な場合)
モデルに「必ず」と伝えるだけ
2 番目のモデルでの番号/日付の検証
すべての出力を同等の信頼性で処理する
影響力と信頼に基づいたルーティング
強力なアプローチでは、モデルが正しいことは期待されていません。それは、あなたが間違っているときにあなたを捕まえるドアを作成します。
ミニケース3個
ケース 1 — スキームだけでは十分ではありませんでした。会計自動化により、請求書から金額が JSON として抽出されていました。このスキームは正しかったのですが、このモデルでは請求書に「1,250.00」ではなく「125,000」が生成されました (小数点シフト)。この計画はこれを捉えることができませんでした。ルール検証 (「金額は請求書項目の合計と±1% 一致する必要がある」) をキャッチし、112,500 TL の誤った記録を防止しました。
ケース 2 — 2 番目のモデルは幻覚をキャプチャしました。 「契約解除の場合は30日前に通知します」と法務支援アシスタントは契約概要の中で述べている。ただし、契約では90日となっていた。独立した裁判官がモデルに「ソースと矛盾している」というフラグを立てたとき、出力は人間に転送されて修正されました。自動の場合、顧客は間違った日付に基づいてキャンセルを通知することになります。
ケース 3 — ルーティングにより負荷が 70% 削減されました。保険金請求システムは、低額で安全性の高い保険金請求を自動的に承認し、しきい値を超える/安全性の低い保険金のみを専門家に送信します。 1 日あたり 3,200 件の需要のうち、人間が負担するのは 950 件のみです。専門家は本当にリスクの高い 30% に時間を費やし、平均取引時間は 4 時間から 40 分に短縮されました。
ヒント: 「人々がすべてを見ることができる」ように人間による制御を設定しないでください。これでは人々は疲れ果て、承認がゴム印になってしまいます。代わりに、影響が大きく信頼性の低い出力のみを人間にルーティングします。これにより、本当に重要なことに注意が集中します。
人間によるコントロールを意味あるものにする
人間参加型とは、紙にチェックボックスを付けることではありません。査読者は、(1) 決定を理解するための背景、(2) 情報源へのアクセス、(3) 「ノー」と言う権限を持っている必要があります。それ以外の場合、コントロールは表面的なままになります。レビュー カード (上記の 4 番目のテンプレート) は、まさにそのコンテキストを提供することを目的としています。
よくある間違い
- スキーマ検証を実行し、コンテンツ/値エラーをスキップするだけです。
- モデルに「確認してください」と伝えることで、実際の検証を行っていると考えます。
- 影響が大きく、取り消しが難しい決定を自動的に実行します。
- すべての出力を人間が制御し、承認を無意味なゴム印に変えます。
- ソースや背景を示さずにレビュー担当者に「承認」と言う。
- 信頼しきい値とルーティングを確立せずに、すべての出力を同じリスクで処理します。
要約すると
- 出力は、形式、内容、悪意の 3 つの方法で破損します。堅牢なシステムが 3 つすべてをドアで停止します。
- レイヤー: スキーマ検証、ルール/ビジネス ロジック、ソース管理、第 2 モデル (LLM-as-judge)、および信頼しきい値ルーティング。
- 影響が大きく安全性が低い出力には、人間参加型が必須である必要があります。
- 人間によるレビューは意味のあるものでなければなりません。レビュー担当者はコンテキスト、リソースへのアクセス、そして「ノー」と言う権限を持っていなければなりません。
- すべての出力ではなく、危険なものだけを人間に向けることで、安全性と効率性の両方が得られます。
アプリケーションタスク
独自の AI 出力から例を見てみましょう。まず JSON スキーマを定義し、それに出力を強制します。次に、少なくとも 2 つのビジネス ルール (たとえば、「金額はアイテムの合計と一致する」) を作成します。最後に、ルーティング テーブルを設定します。どの信頼と影響力の組み合わせが自動的に送信され、どれが 2 番目のモデルに送信され、どれが人間に送信されますか?欠陥のあるサンプルを生成し、各層がそれをキャプチャする場所を観察します。
チェックリスト
- [ ] 出力の厳密なスキーマを定義し、マシンで検証します。
- [ ] 少なくとも 1 つのビジネス/ルール検証 (値ロジック) を追加しました。
- [ ] アサーションをソースにリンクして確認できます。
- [ ] 高衝撃/低安全性の結果については、2 番目のモデルまたは人による検証が利用可能です。
- [ ] 信頼と影響力に基づいて定義されたルーティング ルール。
- [ ] レビュー担当者には、コンテキスト、ソース、および拒否する権限が提供されます。