エージェントの修正が別の何かを壊した - Sofia Jakovcevic, Arize AI

하이라이트

• AIシステムの修正を施した際に他の10箇所を同時に壊していないことを確認することが最大の課題である。

• セキュリティエンジニアの提案によりアクションの安全性は17ポイント改善したものの、確認プロセスが追加されたことでタスク完了率が17ポイント低下した。

• エージェントはコードレベルではなく実行時に失敗するため、静的なコードではなく本番環境のトレースが新たな真実の源泉となる。

• 本番データの選択、スコアリングメカニズムの用意、ベースライン実験の実行、変更の適用、CIへの組み込みという5つのステップから回帰ループが構成される。

• LLM as a judgeを活用することで、ハルシネーションやタスク完了といった主観的な指標を0から1のバイナリスコアなどの定量的な測定値に変換できる。

• Ariseプラットフォームのプロンプトプレイグラウンドやエージェントプレイグラウンドを使用することで、単一エージェントから複雑なマルチエージェントシステムまでUI上でテストが可能である。

타임라인

1. 00:00:00 - 06:26:00

   エージェント開発における回帰の課題とオブザーバビリティの必要性

   AIエージェントの挙動は自然言語で記述されるため、エンジニアは直感でプロンプトを変更しがちである。しかし、一つの側面を改善しても別の箇所に悪影響を及ぼす「サイレントエラー」が発生するため、数値化された評価データに基づく判断が求められる。従来のソフトウェアとは異なり、エージェントの実際のロジックはランタイムやトレースの中にしか存在しないため、オブザーバビリティが不可欠となる。

   • AIシステムの構築において、低レイヤーのプログラムがブラックボックス化することで予測やデバッグが困難になる。
   • サポートエージェントにアクション前の確認を求める1行を追加したところ、安全性が17ポイント向上する一方でタスク完了率が17ポイント低下した。
   • エージェントのエラーはコードレベルではなく実行時に発生するため、静的なコードの差分ではなく本番環境のトレースが実際の動作を示す。
2. 06:26:00 - 01:18:00

   5つのステップで構築する回帰テストループ

   信頼性の高い回帰テストプロセスは、実際のユーザーデータを用いたデータセットの構築から始まる。次に、ハルシネーションやタスク完了といった指標を評価するためのスコアリングメカニズムを導入する。すべての本番トレースに対してベースラインを実行し、プロンプトやモデル変更後の結果と比較することで、リリース前にパフォーマンスへの影響を正確に測定することが可能になる。

   • 回帰テストの最初のステップとして、平均的なワークフロー、既知の障害、エッジケース、保護したい成功ワークフローを含む本番データセットを選択する。
   • LLM as a judgeなどの評価器を用いることで、主観的な指標をバイナリスコアなどの定量的な測定値に変換できる。
   • ベースライン実験を実行した上で変更を加え、GitHub ActionsなどのCIに組み込むことで自動化されたゲートを構築できる。
3. 01:18:00 - 00:19:15

   プラットフォームを活用した実験とオブザーバビリティの未来

   UIやSDK、コーディングエージェントのスキルを通じて、開発環境とオブザーバビリティのバックエンドを直接結びつけることができる。手動のデバッグやトリアージがボトルネックとなる中、今後はエージェント自身が失敗から学び、自ら修正を行う自己改善の仕組みへと進化していく。

   • Ariseプラットフォームのプロンプトプレイグラウンドやエージェントプレイグラウンドを利用して、単一およびマルチエージェントのテストを実行できる。
   • すべての失敗したケースを回帰テストスイートの新しいテストケースとして取り込むことで、エージェントを継続的に強化できる。
   • オブザーバビリティの未来は人間がエージェントを理解するためだけでなく、エージェントが自らを評価し自己改善するためのものへと移行している。