高信頼な注文であっても、処理を進めるには許可が必要です。

数量の確認が必要な間も、価格は適正であり得ます

信頼度スコアはベンダーの解釈を表します。レストランがその数量を許可するかどうかには答えません。水のフィクスチャでは、メニュー合計が$0.00であるため、価格のみのチェックは反対する理由がありません。数量チェックは異議を唱えます。18,000は保存された上限の8を超えています。

この区別により、運用チームには有益なレビューの問いが生まれます。どのレストランルールが送信権限を付与し、保留された理由をオペレーターはどこで検査できるのか？デモでは、高信頼に見える解釈を権限付与として扱うのではなく、届いた注文を保持し、決定証拠を提示します。

解釈から許可までの注文を追跡

これらの保持されたフレームは、実際のローカルデモンストレーションからのものです。注文、レーン映像、厨房ディスプレイは合成またはシミュレーションです。ベンダーやメニューのブランド表記はフィクスチャのスタイリングであり、連携、顧客、または支持の証拠ではありません。

水注文はゼロ価格であっても待機します

ドロワーは、届いた18,000杯のカップ、8の上限、単一注文の個数境界を開示します。提案された数量は8です。その提案はルール証拠から生じるものであり、HOLDの決定とは別個のままです。

通常の注文は引き続きパスします

通常のフィクスチャでは、2つのポテトと1つのバーガーが検証をパスします。PASSに対しても例外と同様に受領証が保持されるため、レビュー画面はモデル生成の説明に依存しません。

不確実な意味には確認が必要です

生のトークンの反復により、合成解釈において3つのバーガーが生成されます。反復と、設定されたしきい値0.85を下回るベンダー信頼度0.71によりHOLDが生成され、1つのバーガーが提案されます。エンジンは顧客の意図を確定できていないため、確認が必要なままです。

未知のトッピングは攻撃ではなく疑問です

この合成注文では、アイスクリームコーンにベーコンを要求しています。保存された観測済みトッピングのセットにはチョコレートディップとスプリンクルが含まれますが、ベーコンは含まれません。したがって、組み合わせチェックはHOLDを生成し、トッピングの削除を提案します。これは確認を求める理由であり、その組み合わせが物理的に不可能であることや顧客が悪意を持って行動している証拠ではありません。

この区別はレビュー設計に影響を与えます。本番ポリシーには、信頼できるメニューと、オペレーターが正当な例外を確認する方法が必要になります。実演されたプロファイルは、シードされた5,000件の合成注文に由来するものであり、レストランチェーンの運用履歴ではありません。

数量、価格、総個数は別個のチェックです

260個のナゲットのフィクスチャは、品目あたり20の数量上限を超えています。また、$117のメニュー合計は設定された価格境界$116.76を超え、260個の数量は単一注文の境界44を超えています。3つのチェックが注文を待機させるべきであることに一致しています。これらの通常のポリシー例外はいずれも単独でBLOCKを生成することはありません。

価格ルールは、保存された履歴合計統計の3倍と$100のうち大きい方を使用します：max(3 × $38.92, $100) = $116.76。総個数ルールは、max(2 × 22, 40) = 44を使用します。ドロワーに表示される小さな履歴統計はこれらの数式への入力であり、最終的なトリガー境界ではありません。両方の境界は設定されたデモポリシーであり、営業中のレストラン向けに較正された制限ではありません。

認識された単語であっても提供可能性のチェックが必要です

11:15に注文された朝食ブリトーは、このフィクスチャの朝食締切時刻が10:30であるため保留されます。リクエストが設定された提供時間帯から外れていても、品目と価格は理解できます。削除提案はその矛盾を開示しますが、顧客がどの代替品を受け入れるかは確認しません。

この例では、届いたフィクスチャの時刻に対して設定された1つの朝食時間枠をチェックします。リアルタイムの在庫、店舗固有のスケジュール、タイムゾーン処理、または統合メニューサービスを確立するものではありません。これらは、本番送信パスが依存する前に個別の設計と検証が必要です。

低い信頼度は他には通常の注文であっても保留する場合があります

1つのスパイシーチキンサンドイッチのベンダー信頼度は0.62であり、設定されたしきい値0.85を下回っています。通常の数量であっても不確実性は解消されないため、エンジンはHOLDを返します。反復トークンの例とは異なり、このケースでは数量訂正を必要とせずに低信頼度を単独で分離します。

次に問うべき適切な問いは、解釈された品目がリクエストと一致しているかどうかです。実演ではその不確実性をレビューへとルーティングします。音声を診断したり、音響録音を評価したり、このしきい値が許容可能な本番エラー率をもたらすことを証明したりするものではありません。

設定された攻撃シグナルは異なる結果をもたらします

指示を含む書き起こしは以前の指示を無視するよう要求し、500個のナゲットを含んでいます。インジェクションパターンがトリガーされ、BLOCKが生成されます。数量、価格、個数規模、低信頼度もトリガーされますが、この結果をHOLDからBLOCKに変更するのはインジェクションルールのみです。有限のパターンセットでは網羅的なインジェクション耐性を確立することはできません。

受領証は明示された境界内で完全性をチェックします

受領証は、注文、8つのすべてのルール評価、決定、提案された訂正、およびアドバイザリテキストを保持します。変更されていない水の受領証は実際のローカルエンドポイントを通じて検証されます。元の署名を保持したままHOLDをPASSに変更すると失敗します。

HMAC-SHA256は署名と検証に同一の共有シークレットを使用します。デフォルトキーは公開デモ素材であるため、それを知っている者なら誰でも変更された本文に再署名できます。これは境界のあるローカル完全性チェックを実証するものであり、独立した保管、不変ストレージ、または完了した人間の行動の記録ではありません。

提案はリリースされた注文ではありません

大量注文のフィクスチャには40個のポテトと40個のソーダが含まれ、合計80個となり44個の境界を超えています。訂正アルゴリズムは、相対的な数量超過が最も著しい単一の品目を変更します。ポテトは上限の4個に引き下げられますが、ソーダは40個のままです。ソーダの数量は依然として自身の上限である6個を超えています。したがって、視覚的に注文が小さくなったことは、提案された注文全体がパスすることの証拠にはなりません。

「Approve Correction」と「Escalate」はラベルを変更して自身を無効化します。これらは人間の行動を記録したり、再送信、再検証、HOLDの解除、受領証の変更、実際のPOSシステムへの注文送信を行ったりしません。本番環境の引き継ぎには、確認された顧客の意図、完全な改訂注文に対する新たな検証決定、および送信権限を付与する前に記録された行動が必要です。

レストラン技術チームからのよくある質問