Your Agent Demo Works. That's The Trap.
私は企業向けにAIエージェントを構築しています。よく同じパターンを目にします。デモではモデルがうまく機能する。製品をリリースする。すると、本番環境では3回に1回の割合で失敗する。なぜなのか、誰も知らない。
デモと本番環境の差は数学の問題です。数学を理解すれば、構築の仕方が変わります。
エージェントの各ステップの信頼性が95%であれば、一見良さそうに思えます。しかし、エージェントはステップを連鎖（チェーン）させて使用します。10個のステップを繋げると、成功率は60%に低下します。20個のステップを使うと、成功率は36%まで落ち込みます。
実務では、ステップの誤り率が10%から20%になることも珍しくありません。もしエージェントが8つのステップを持ち、それぞれの信頼性が85%だとすると、75%の確率で失敗することになります。
問題はモデルではありません。確率の累積が問題なのです。
デモは単一のハッピーパス（理想的な経路）を示します。クリーンな入力と短いチェーンを使用します。一方、本番環境では、何百人ものユーザーからの乱雑なデータを使用します。また、隠れたステップを含む長いチェーンを使用します。
エージェントの失敗は、クラッシュのような形では現れません。「静かなエラー」として現れます。
ステップ3でフィールドの読み取りを誤る。しかし、出力は依然として有効なJSONのように見える。ステップ4はその誤ったデータに基づいて推論を行う。ステップ5から8はその間違いの上に積み重なっていく。最終的な回答は間違っているが、もっともらしく見える。どこで間違えたのかを示すエラーログも存在しません。
「モデルがハルシネーションを起こした」と言うのはやめましょう。モデルは単に、受け取った誤ったデータをそのまま渡しただけです。あなたのシステムに、ステップ3でエラーを捕捉するためのチェックポイントが欠けていたのです。
エージェントを単なるプロンプトとして扱うのをやめましょう。システムとして扱い始めてください。
信頼性の高いエージェントを構築するために、以下のルールに従ってください：
エージェントの外側に状態（state）を保存する。状態は会話の中ではなく、データベースに保持してください。プロセスがステップ6で失敗した場合、ステップ6から再開できます。チェーン全体を最初からやり直す必要はありません。
境界（boundaries）でバリデーションを行う。すべての入力と出力をスキーマに照らしてチェックしてください。エラーが発生したそのステップで捕捉します。これにより、原因不明の事態を、回復可能なエラーへと変えることができます。
副作用を冪等（べきとう）にする。ステップが失敗したときはリトライする必要があります。ステップがメールを送信したりカード決済を行ったりする場合は、冪等キー（idempotency key）を使用してください。これにより、リトライ中の重複アクションを防ぐことができます。
CIでエバリュエーション（evals）を使用する。エージェントの挙動は、微調整のたびに変化します。プロンプトの変更が1つのケースを解決しても、他の5つのケースを壊してしまうかもしれません。テストセットを使用して、これらのデグレ（退行）を自動的に捕捉してください。
デモから実際の製品へと移行することは、エンジニアリングそのものです。それはエラーハンドリング、状態管理、そしてオブザーバビリティ（観測性）の問題です。より良いプロンプトの問題ではありません。
もし本番環境でエージェントの挙動が不安定になるなら、より大きなモデルを探すのではなく、チェーンが狂い始めたステップを探してください。なぜシステムがそこでエラーを捕捉できなかったのかを問い直してください。
Source: https://dev.to/sagar_jain4010/your-agent-demo-works-thats-the-trap-4joc
Optional learning community: https://t.me/GyaanSetuAi