AIエージェントにとって新鮮さは十分か？誰も定義しないデータの新鮮さの予算

Andrew Tanによる

AIエージェントにとって新鮮さは十分か？誰も定義しないデータの新鮮さの予算

多くのチームはAIコンテキストをストレージの問題と捉えています。より難しい質問は、エージェントが行動を起こす際にデータが新鮮であるかどうかです。

多くのAIインフラストラクチャの会話は、まだ間違ったボトルネックに向けられています。

チームはベクターデータベース、プロンプトキャッシング、長期メモリ、MCPサーバー、そしてエージェントの背後にどのモデルを置くべきかを議論します。それらはすべて重要です。しかし、それらはエージェントが本番環境で安全に使用できるかどうかを実際に決定する質問には答えていません。

エージェントが何かを決定する際に、データはどれくらい新鮮ですか？

その質問は退屈に聞こえます。しかし、エージェントが間違った返金を送信したり、間違った注文を承認したり、間違ったインシデントをエスカレートしたり、20分前の顧客記録を見て間違ったツールを呼び出したりするとき、それは退屈ではありません。

ほとんどのデータチームはすでに品質、系統、スキーマドリフトを理解しています。新鮮さは、エージェントが登場するまで「あると良いもの」として扱われます。そして、新鮮さはダッシュボードの好みから運用の境界に変わります。

コンテキストは許可と同じではない

これは多くのチームが飛ばす部分です。

エージェントは多くのコンテキストを持っていても、あなたが望む行動に対して間違ったコンテキストを持っていることがあります。倉庫にある1000万行のデータは、重要な1つのフィールドが3分前に変更され、同期が毎時行われる場合には役に立ちません。

それが情報的データと行動可能なデータの違いです。

情報的データはエージェントが先週何が起こったかを説明するのに役立ちます。行動可能なデータは、今何をすべきかを決定するのに役立ちます。

それらは同じワークロードではありません。

サポートコパイロットが過去5件のチケットを要約する場合、多少の遅延は許容できます。返金がすでに行われたかどうかを決定するエージェントは許容できません。

営業アシスタントがアカウントブリーフを作成する場合、夜間のCRM同期から作業できます。現在の製品使用状況に基づいてライブリードをルーティングするエージェントは、せいぜい数分前のデータが必要です。

月次の差異要約を準備するファイナンスボットはバッチで問題ありません。疑わしい支払いを凍結するエージェントはできません。

すべてのAIコンテキストを「AI対応データ」という1つのカテゴリとして扱うのは間違いです。

それは1つのカテゴリではありません。それは異なる新鮮さの要件を持つ意思決定のスタックです。

新鮮さの予算

これを考える最も簡単な方法は、新鮮さの予算です。

すべてのエージェントタスクには、ソースシステムで起こったこととエージェントが行動する際に見るものとの間の最大許容遅延があります。

その遅延予算は、間違った場合の結果に依存します。

ここに簡単なバージョンがあります：

これは普遍的な表ではありません。これは強制機能です。

ほとんどのチームはこれらの数字を全く定義しません。ただ「リアルタイムAI」や「AI対応パイプライン」が欲しいと言い、スタックが後で自動的に解決することを期待します。

それはしません。

新鮮さの予算を定義しない場合、デフォルトの予算は「パイプラインがすでに行っていること」になります。それは通常、偶然であり、設計上の選択ではありません。

多くのAI作業においてバッチはまだ有効

すべてのワークロードをストリーミングに押し込むことが答えだとは思いません。

それは高価です。また、チームがそれを必要としない場合、新しいクラスの運用問題を引き起こします。

いくつかのAIユースケースはバッチで完全に満足しています：

• 内部要約の作成
• 調査ブリーフの準備
• トレンド分析のためのサポート会話のタグ付け
• 更新準備ノートの作成
• 計画ドキュメントの強化
• 週次エグゼクティブ要約の作成

これらのタスクは、即時性よりも完全性から利益を得ます。

通常、15秒前の最新イベントではなく、完全な記録を望みます。

これは、現在の多くのAIメッセージングが未来を1つの巨大なリアルタイムシステムとしてフレームしているため、重要です。それは過剰支出を招く良い方法です。

より良い質問は狭いです：低レイテンシーデータが実際に行動の質を変えるのはどこですか？

答えがどこにもない場合、それをバッチに保ちます。

答えが特定のインターフェースである場合、最初にそれらのインターフェースを移動します。

危険な中間

本当にバッチでもなく、真にリアルタイムでもないのが本当の問題です。

それは、チームが毎時更新されるパイプラインや、30分ごとに更新されるパイプライン、またはコネクタが追いつく気になったときに更新されるパイプラインを持ち、そのデータを行動する許可を持つエージェントに渡すときです。

そこで間違いが高価になります。

毎時の新鮮さは、ワークフローにマッピングするまでまともに聞こえます。

顧客が10:02にアップグレードし、エージェントが11:00まで古いプランを見ている場合、顧客がすでに支払った権利を否定することができるほぼ1時間があります。

注文が2:11にキャンセルされ、在庫アシスタントが3:00までそれを知らない場合、不要な在庫を再注文することができます。

チャージバックフラグがあるシステムに到着する前に、リスクエージェントが健康なアカウントを見て、次の取引を完全な自信を持って承認することができます。

これらの例では何も明らかに壊れていません。ジョブは実行されました。テーブルは更新されました。ダッシュボードはおそらく問題ないように見えます。

問題は、アクションウィンドウがデータウィンドウよりも狭いことです。

そのギャップがエージェントの失敗が生じる場所です。

承認ゲートも新鮮さ戦略の一部

自動化に急ぐ中で失われるもう一つのポイントがあります。

時には正しい答えはより速いデータではありません。時には正しい答えは承認ゲートです。

エージェントが古いまたは曖昧なコンテキストで作業する場合、必ずしもそのユースケースを永遠にブロックする必要はありません。最後のステップを変更するだけで済むことがあります。

エージェントにデータを収集させます。応答を下書きさせます。行動を推奨させます。そして、新鮮さの予算が満たされていない場合や、決定が金銭、コンプライアンス、アクセス、または顧客向けのリスクに関わる場合は、人間の承認を要求します。

これは自動化の失敗ではありません。それは設計の一部です。

良いAIシステムは、モデルの品質だけでなく、いつ単独で行動しないかを考えます。

それは特に、基礎となるデータが異なる速度で移動するバッチ同期、CDCパイプライン、イベントストリーム、外部APIの混合を通じて到着する場合に当てはまります。

プラットフォームのスローガンではなく、インターフェースごとの新鮮さが必要

多くのベンダーのポジショニングはこれを意図的にぼかします。

約束は通常次のように聞こえます：すべてのデータを接続し、エージェントに供給し、リアルタイムの意思決定を解放します。

良いでしょう。しかし、どの決定ですか？

会社全体のための1つの巨大な新鮮さの目標は必要ありません。インターフェースごとの新鮮さの目標が必要です。

エージェントがアドバイスから行動に移る場所から始めます：

• 何かを承認または拒否する
• 顧客コミュニケーションを送信する
• アクセスまたは権利を変更する
• お金を動かす
• インシデントを開いたり閉じたりする
• 下流システムを自動的にトリガーする

これらのインターフェースは、明示的な遅延制限、監視、フォールバック動作、および所有権に値します。

パイプラインが予算を逃した場合、何が起こるべきですか？

おそらくアクションが一時停止します。

おそらくエージェントは下書きはできるが送信はできません。

おそらく安全なツールの狭いサブセットで動作できます。

おそらく人間がループに入る必要があります。

ポイントは、最初のインシデントがそれを教える前にこれを定義することです。

データスタックにとっての意味

新鮮さの予算を定義すると、スタックの会話が簡単になります。

バッチ対ストリーミングをイデオロギーとして議論するのをやめることができます。

いくつかのインターフェースはイベント駆動の処理を必要とします。いくつかは厳しいSLAを持つCDCを必要とします。いくつかはスケジュールされた同期で問題ありません。いくつかは、同じワークフローが履歴のバックフィルと低レイテンシーの更新の両方を処理するハイブリッドパスを必要とします。

最後のカテゴリは、アーキテクチャがバッチとストリーミングを別々のシステムに分割する場合にすぐに痛みを伴うものです。

今、あなたは同じビジネスロジックの2つのバージョンを維持しています。1つは履歴の質問に答えます。1つはライブアクションをサポートします。それらはドリフトします。エージェントは触れたパスに応じて一貫性のない状態を取得します。

だからこそ、私が考えるより良い長期的な設計は「リアルタイムをどこでも」ではありません。それは、バッチとストリーミングの両方を処理し、それらの周りのオーケストレーションを行う1つのランタイムであり、チームが新鮮さの要件が変わるたびにワークフローを再構築することを強制しません。

それがlayline.ioがフィットする場所でもあります。ポイントは、すべてのパイプラインをストリームに変えることではありません。ポイントは、行動がそれを必要とする場所で新鮮さを引き締め、十分な場所でバッチを維持し、1つの運用モデルで両方を管理することです。

実用的なテスト

あなたのチームが今AIエージェントを展開している場合、すべてのエージェントアクションに対して1つの質問をしてください：

このアクションが安全でなく、間違っている、または恥ずかしいものになる前に許容できるデータの最大年齢はどれくらいですか？

その数字を書き留めてください。

誰もそれに答えられない場合、あなたはまだAIの問題を持っていません。要件の問題を抱えています。

そして、答えが「それは依存します」である場合、それは問題ありません。それが依存しなくなるまでインターフェースごとに分解してください。

これをうまく行うチームは、最も声の大きいAIスタックを持つチームではありません。どの決定が秒を必要とし、どの決定が分を必要とし、どの決定が明日まで待てるか、そしてどこに人間がまだループにいるべきかを知っているチームです。

それは通常のエージェントデモよりも興奮しないように聞こえます。

それはまた、役立つシステムと新しい種類のオンコールローテーションを作成するシステムの違いです。

Andrew Tanは、layline.ioの創設者であり、バッチとリアルタイムのワークロードを大規模に処理する企業データ処理インフラストラクチャを構築しています。