評価ファーストのAIエージェント：ZeptoがDatabricksとMLflowでカスタマーサポートをスケールした方法

信頼性の高いリアルタイムなカスタマーサポートを目指すZeptoの取り組み

Zeptoは、数千種類以上の商品を取り扱い、60以上の都市で展開し、数分単位の配送時間を誇る、インドで最も急成長しているクイックコマースプラットフォームの1つです。スピードこそが価値であるこのビジネスにおいて、カスタマーサポートも同様に迅速に機能する必要があります。

その期待に応えるため、Zeptoは1日10万件以上のチケットを処理するマルチエージェントAIシステムでカスタマーサポートを運営しています。初期の段階では、チームはエージェントを迅速に構築してリリースすることができました。しかし、処理量が増え、カテゴリが拡大し、顧客の行動が変化し続ける中で、これらのエージェントの信頼性をどのように維持するかがより困難な課題となりました。ZeptoはDatabricksと提携し、単にエージェントを増やすのではなく、評価をエージェントの構築、テスト、運用の主要な手段に据えることで、この課題を解決しました。

このブログでは、システムアーキテクチャ、DatabricksとMLflowを活用した評価フレームワーク、本番環境での実績、そしてそこから得られた成果と教訓など、その道のりを紹介します。

なぜ「とにかくエージェントをリリースする」やり方が大規模環境で破綻するのか

変化の激しいビジネスにおいて、「とにかくエージェントをリリースする」アプローチは、大規模環境で破綻するまではうまく機能します。しかし、AIエージェントが処理するチケットが1日10万件を超えると、わずか1%のエラー率であっても、毎日数千件の不適切な対応が発生し、実際の収益損失につながります。

負荷は不規則な波のように押し寄せました。気象イベント、ディワリ（光のフェスティバル）、夏の始まりなどは、チケット数の急激なスパイクを引き起こしました。また、食料品からアパレル、電子機器、美容製品へのカテゴリ拡大に伴い、返金、交換、返品といった新たなカスタマージャーニーが追加されました。さらに、顧客層の多様化と多言語化により、サポートリクエストの幅が広がり、数週間ごとに新しいエラーパターン（失敗モード）が表面化しました。

より深刻な問題は、アシュアランスギャップ（品質保証のギャップ）です。エージェントシステムは、意図の分類、知識の検索、入力の分析、意思決定の推論、トランザクションツールの呼び出し、回答の生成といったマルチステップのワークフローとして動作するため、最終的な回答だけでなく、プロセスの途中のどこででもエラーが発生する可能性があります。

このアシュアランスギャップは、以下のような具体的な問題をもたらしました。

• 顧客から苦情が来るまでエラーが可視化されなかった
• 修正に時間がかかっていた
• 最終的な回答の裏に内部エラーが隠れてしまっていた
• エージェントのコスト、パフォーマンス、品質のバランスを取るための体系的な方法が欠けていた
• エージェントの設計に、すべての重要なステークホルダーの視点が反映されていなかった
• エージェントが急速に進化する中で、信頼性を保証することが困難だった

目指すべき方向は明確になりました。それは、DatabricksとMLflow上で評価フレームワークを構築し、エージェントを構築・運用するためのコアなAIインフラとして機能させることです。

なぜ評価フレームワークが必要なのか、そしてその成果

強固な評価フレームワークは、本番環境への対応における5つの軸に直接影響を与えます。

• 信頼性：単に「それらしく聞こえる」だけでなく、エージェントがすべてのステップで正しく動作することをシステムレベルで保証
• 開発速度：変更が自動的に回帰テストされるため、プロンプト、ポリシー、モデルのイテレーションをより迅速かつ安全に実行可能
• コスト・品質・パフォーマンスの制御：確かな評価データに基づき、制約条件の最適なバランス（スイートスポット）を満たす最適なモデル、プロンプト戦略、またはハイブリッドルーティング戦略を選択可能
• ガバナンス：監査可能なトレース、バージョン管理された評価基準（ベースライン）、およびデプロイやロールバックのための明確に定義されたしきい値。直感（「このバージョンのほうが良さそうだ」）から、証拠（「このバージョンは合意されたメトリクスでベースラインを上回っている」）に基づく意思決定への移行
• ステークホルダーとのコラボレーション：ステークホルダーの視点から成功と信頼性の基準を捉え、トレードオフを全員にとって明確かつ測定可能に

DatabricksとMLflowを評価の基盤とし、評価を最優先するエージェントアーキテクチャを採用したことで、Zeptoは以下の成果を達成しました。

コストと効率

• 人間の監視のもと、80%以上のチケットをAIエージェントが完全に管理
• サポートコストまたはサポートチケットを65%削減
• 1ヶ月未満の投資回収期間

品質と評判

• 顧客満足度（CSAT）が20%向上
• 正確性が8%向上

パフォーマンスと運用

• 開発サイクルが3倍高速化
• 解決までの時間が4倍高速化

フレームワークの構築：確信と制御をもたらすデュアルループ

このアプローチの核心は、クオリティゲートによって接続された開発ループと本番ループからなる「デュアルループモデル」です。このセクションでは、これらのループがどのように連携するかを説明します。

• 開発ループ：リリース前に確信を持って構築できるよう、エージェントのバージョンを設計、反復、評価する場所
• 本番ループ：確信を持ってエージェントを運用できるよう、実際の動作を監視し、エラーを検出する場所
• フィードバックループ：本番環境でのエラーを開発にフィードバックし、次のイテレーションを充実させる場所
• クオリティゲート：ループ間の移行を制御し、どのバージョンを本番環境に移行させ、どのバージョンをさらなる改善のために開発に戻すかを決定

これら2つのループが連携することで、エージェントが適切に制御された状態で構築・運用されるようになります。あらゆるエラーが自動的にキャプチャされ、フィードバックされ、修正されます。その結果、エージェントは確信を持って構築され、制御された状態で実行され、時間の経過とともに本番環境でのエラーにうまく対処できるよう継続的に改善されます。このデュアルループこそが、私たちのフレームワークの核心です。

フェーズ0：トレースの有効化：設計によるエージェントの透明化

エージェントが呼び出されるたびに、プロンプト、補完（出力）、取得されたドキュメント、ツールの呼び出し、レイテンシ、意思決定パスなどを記録した詳細な実行トレースが出力されます。これにより、単に入入力と最終出力だけでなく、ワークフロー全体を詳細なレベルで観察できるようになります。

私たちは、MLflowを使用したハイブリッドなアプローチでこれを実現しました。わずか1行のmlflow.<library>.autolog()で自動トレースが有効になり、@mlflow.trace デコレータによって、より詳細な情報が必要な場所にカスタムスパンを追加できます。トレースは、構成可能性を維持するために一意のIDを持つOpenTelemetryスパンとしてリアルタイムに出力され、MLflowとUnity Catalogの統合により、ログがDeltaテーブルに一元化されます。

フェーズ1：評価次元の設定：ピラーとゲート

トレースが有効になったら、次のステップは、各ステークホルダーの視点から「このエージェントにとっての成功とは何か？」を捉えることです。私たちはこれを評価ピラーとして定式化し、それぞれに特定のゲートを設けました。

これにより、複数のステークホルダー間の議論が、共有された測定可能な契約へと変わります。エージェントは、各ステークホルダーにとって実際に重要な次元に沿って評価されます。代表的なピラーには、顧客体験、業務効率、リスクとコンプライアンス、財務的影響などがあり、各ピラーにはデプロイ前に満たすべき明確な数値しきい値が設定されています。

フェーズ2：ゴールデンデータセット：信頼性の礎

ゴールデンデータセットは、開発ループにおけるエージェントの動作を評価するための唯一の信頼できる情報源（Single Source of Truth）です。これは以下を満たす必要があります。

• エージェントが対処しなければならない、正常系、エッジケース、およびエラーケースを網羅していること
• さまざまなステークホルダーからの期待値が具体例として含まれていること
• メタデータ（シナリオタイプ、ビジネスライン、リスクレベルなど）が豊富にアノテーションされていること

すべてのステークホルダーが協力してデータセットを形成します。たとえば、セキュリティチームはプロンプトインジェクション、アイデンティティ攻撃、データ流出の試みなどの敵対的パターンの例を提供します。これにより、通常の利用だけでなく、あらゆる現実世界のシナリオに対して信頼性が測定されるようになります。

データセットは生きた資産であり、その品質は時間の経過とともに向上します。開発環境と本番環境の精度のギャップ自体が、データセットの品質を示すシグナルとなります。Zeptoは6か月にわたりMLflowの評価データセットに継続的に投資し、当初の500例・開発-本番精度ギャップ8ポイントから、2,000例・2ポイントのギャップ、最終的には5,247例・0.4ポイントのギャップへと改善しました。データセットの品質向上に費やす1時間は、本番環境でのデバッグ時間を約10時間削減します。そのため、ゴールデンデータセットは10倍の効果をもたらす乗数となります。本番環境での失敗が発生するたびに、そのトレースがゴールデンデータセットに追加され、将来のすべてのバージョンにおいてシステムがより頑健になります。

フェーズ3：プロンプトエンジニアリングの自動化：自動生成と自動最適化

プロンプトを手動で作成する代わりに、プロンプトエンジニアリングをデータ駆動型の自動化されたプロセスにしました。プロンプト設計はエンジニアが最も時間を費やす重要なフェーズであり、プロンプトの品質はエージェントの出力品質とパフォーマンスに極めて大きな影響を与えます。

Using MLflowプロンプト最適化を使用することで、初期プロンプトを登録し、デプロイの判定基準となるスコアラーに対してバリアントを生成・最適化し、A/B評価を自動的に実行して、最良の結果をデプロイします。最適化ツールは強力なモデルを用いて検討を行い、本番環境ではより安価なモデルで候補をスコアリングするため、探索プロセス自体のコスト効率が維持されます。これにより、手動でのプロンプト実験が削減され、精度が向上し、プロンプトの改善が本番環境に適用される前に必ずゴールデンデータセットで測定されるようになりました。

フェーズ4：スコアラーの定義とAI審査員のセットアップ

本番環境のループにトレースが流れる中、エージェントの品質にとって重要な次元（評価次元）に沿ってそれらをスコアリングする必要があります。これは、各スコアラーがそれぞれの強みを発揮する「AI審査員」のようなものと考えてください。MLflowでは、スコアラーを作成するための3つのオプションを提供しています。

• 組み込みの評価者 - すぐに使えるスコアラー
• カスタム評価者 - 独自のニーズに合わせてカスタマイズされた評価者を作成
• コードベースのスコアラー - ツールのレイテンシやツールの呼び出し回数などの決定論的なメトリクス用

人間のような判断が必要な場合にのみLLMベースのスコアラーを使用し、決定論的なロジックで十分な場合はシンプルなルールに依存します。人間によるラベルと評価者の判定を調整して80〜90%の一致率を達成し、重要な決定には複数の評価者を使用します。

フェーズ5：モデルの選択肢のセットアップ

モデルの選択肢（Model optionality）は、Databricksでモデル名を変更するだけで、多くの商用モデルやオープンソースモデルを簡単に切り替えることができる重要なコンポーネントです。これにより、開発ループはコスト、パフォーマンス、品質の最適なトレードオフを見つけるために、より優れた組み合わせを継続的に探索できます。

フェーズ6：自動回帰評価の構築

回帰評価を自動化することで、再現可能で設定可能、かつスケーラブルな開発ループを構築します。いかなる変更も自動回帰評価をトリガーし、信頼性が保証されると自動デプロイが実行されます。

これらを組み合わせると、一般的な変更は以下のようなプロセスをたどります。

1. 誰かがエージェントのロジック、プロンプト、またはモデルを変更します。
2. 評価ワークフローが、新しいエージェントバージョン、ゴールデンデータセット、現在の本番環境のベースラインという3つのインプットを用いて自動的にトリガーされます。
3. システムが評価を実行し、すべてのスコアラーと評価軸にわたるメトリクスを生成します。
4. クオリティゲートが以下をチェックします。
   • 新しいバージョンはすべてのゲート（コスト、品質、パフォーマンスなど）を満たしていますか？
   • 本番環境のベースラインと同等以上のパフォーマンスを発揮していますか？
5. 満たしている場合、新しいバージョンが本番環境に昇格します。満たしていない場合は却下され、既存のエージェントが引き続きトラフィックを処理します。

フェーズ7：本番ループの構築 - リアルタイムセーフティネットのセットアップ

トラフィックの100%を評価するのはコストがかかりますが、単純な10%の一様サンプリングではほとんどのエッジケースを見落としてしまいます。そこで私たちは、高価値の顧客、新機能や最近変更されたフロー、ネガティブなセンチメントや高いエスカレーションリスク、画像ベースまたは不正が発生しやすいインタラクションなどに応じて評価サンプリング率を変動させる層化サンプリングを導入しました。これにより、管理可能なコストで実質18〜20%の評価サンプル（1日あたり約14,400トレース）を確保しつつ、エッジケースの45〜60%を捉え、4〜6分以内に問題を検出できるようになりました。

財務的な論理は非常に説得力があります。一様サンプリングのアプローチと比較して、層化サンプリング手法は特定された問題あたりのレビューコストを86%削減し、同時にエッジケースの検出率を9倍向上させました。これにより、品質保証プロセスが大幅に効率化され、拡張可能になりました。

評価結果はDeltaテーブルに書き込まれ、Databricksのダッシュボードやアラートルールを介して可視化されます。重大なアラート（5分ごとにチェック）は、意図（インテント）精度の低下、根拠性（groundedness）の違反、高いエスカレーションリスク、およびP95レイテンシの超過を監視します。高/中レベルのアラートは、共感性の低下、コストの急増、ツールの失敗率、CSATの傾向、不正検出率、およびマルチモーダルレイテンシを追跡します。これにより、AIエージェントに対するSRE（サイト信頼性エンジニアリング）のような運用（迅速な検出、トリアージ、および緩和策の実行）が可能になります。

構成可能なアーキテクチャのエージェントスタック

優れた評価フレームワークは、エージェントアーキテクチャが最初から観測可能で分解可能に設計されている場合に、はるかに効果的に機能します。Zeptoのサポートスタックはこの考え方に基づいて構築されています。

チャットまたは画像形式の顧客からの問い合わせは、まずエージェント型オーケストレーターとルーターを通過します。ルーターはいつでも人間のオペレーターに引き継ぐことができます。その下で、システムは2種類のエージェントに分かれます。

垂直型エージェントはスペシャリストであり、それぞれが明確に定義された単一のインテント（意図）ファミリーを担当します。

• WIMO：注文追跡およびETAに関する質問用
• Missing：未配送または一部未配送の注文用
• Expiry：賞味期限・消費期限切れのパッケージ商品用
• Returns：返金ステータスおよび処理用
• Quality：鮮度の落ちた、または傷んだ農産物用
• Unable to Pay：ウォレット、プロモーション、決済のエラー用
• General（フォールバック用）

水平型エージェントは、ユースケースを横断する監視レイヤーとして機能します。

• Image Deduplication（画像の重複排除）：複数の申請にわたって再利用された画像を検出します
• Item Matching and Image Manipulation Detection（商品マッチングと画像改ざん検出）：アップロードされた画像がカタログ商品と一致し、編集されていないことを検証します

この分離は2つのメリットをもたらします。WIMOのインテントF1やExpiry（期限切れ）のOCR精度など、垂直型エージェントごとにメトリクスを計算できます。また、不正検出の適合率、画像の再利用、改ざん検出といった横断的な懸念事項について、水平型エージェントを評価できます。各パーツは、単体でも組み合わせても測定可能です。

フレームワークの実践

AIエージェントを初めて本番環境に導入するときは、優秀だが予測不可能なインターンを会社の代表として送り出すような気分になります。指示を出してうまくいくことを祈るしかなく、実際にプレッシャーがかかる状況になるまでは、実質的に手探り状態です。

私たちは早い段階で、従来のソフトウェア監視がAIにはまったく役に立たないことに気づきました。サーバーの稼働率は100%でエラーもゼロなのに、エージェントがイライラしている顧客に対してまったく同じ間違った回答を繰り返す、といったことが起こり得るからです。エンジニアにとってはダッシュボードが正常（グリーン）に見えても、顧客にとっては災難でしかありません。

希望的観測だけでAIをスケールさせることはできないと分かっていました。AIがただ話しているかどうかを追跡するだけでなく、実際に何を言っているのか、どこで失敗しているのかを理解する評価フレームワークが必要でした。以下のストーリーは、このフレームワークがその真価を発揮し、優れた評価システムがまったく新しいプロダクト機能を解放することを証明した瞬間です。

ストーリー1：まったく動かないETA

本番環境の不具合により、配達員が渋滞に巻き込まれている間、エージェントはキャッシュされたデータを読み込んでいたため、「あと10分で到着します」とループで返答し続けました。顧客が注文はどこにあるのかと尋ねると同じセリフが返ってき、再度尋ねてもまた同じセリフが返ってきました。

トークンカウンター（トークン使用量を監視）と警告スコアラーが、5分以内にこの繰り返しと高いエスカレーションリスクを検知し、ETAが変わらないまま停止している配達員のトレースを浮き彫りにしました。これをきっかけにルールの変更が行われました。配達員が10分以上停止している場合、エージェントは古い約束を繰り返すのではなく、正直な最新情報を伝え、全額返金によるキャンセルを主体的に提案するようになりました。

オンライン評価によって得られたこの1つのインサイトは、一連の機能ラインへと発展しました。これには、遅延時のキャンセル、配達員不足時の主体的なキャンセル提案、設定された時間内に配達員が割り当てられない場合の自動キャンセル、そして優良顧客向けの無条件キャンセルが含まれます。

ストーリー2：顧客が気づく前にキャンセルの精度低下を検知する

ZeptoがWIMOエージェントにキャンセル処理を追加した際、モデルは「注文はどこですか」「キャンセルしたいです」「注文はキャンセルされましたか」という、まったく異なる3つのインテント（意図）を混同し始めました。

開発フェーズのMLflow評価により、これが即座に検出されました。全体的なインテントの正解率は約92.1%から87.4%に低下し、新しいWIMO_CANCELおよびWIMO_CANCEL_STATUSインテントのF1スコアは低迷していました。この精度低下はゴールデンデータセットに対して現れたため、顧客の目に触れることはありませんでした。プロンプトの最適化とデータセットの更新により、全体の正解率は元のベースラインを上回る約94.2%に回復し、キャンセルAPIに対するツール呼び出しのF1スコアはほぼ完璧になりました。この機能はロールバックすることなく本番リリースされました。

ストーリー3：人間の判断基準に合わせたマルチモーダルエージェントの調整

生鮮食品の品質をスコアリングするのは本当に難しく、人間の意見が常に一致するとは限りません。同じキノコの画像に対して、ある評価者は5点満点中2点をつけ、別の評価者は3点をつけるかもしれません。私たちはこの不一致をコヘンのカッパ係数で測定し、それを信頼性の上限とみなしました。学習元となる人間以上に一貫性のあるモデルは存在し得ないからです。

また、AIが安全策を取ることも分かりました。そのままにしておくと、難しい判断を避けるためにスコア3を連発したのに対し、人間のスコアは4と5に集中していました。そのため、平均値に対する誤差を最小限に抑えるだけでなく、人間のスコア分布の形状に合わせるようにしました。さらに、オンライン評価により、パッケージ商品として棚に並んでいるものの生鮮食品のように判断する必要がある凝固した牛乳や、写真ではどうしても伝わらない味や臭いに関する苦情など、システムが想定していなかったケースが浮き彫りになり、これらは別のルートに振り分けられました。

この調整されたベースラインにより、商品タイプごとにどのモデルを使用するか、人間の判断基準に合わせてどのようにプロンプトを反復改善するか、そして実際のエージェントのパフォーマンスに基づいて顧客セグメントごとに返金ポリシーをどのように調整するかを決定できるようになります。

ストーリー4：不正利用の抜け穴を塞ぐ

返金制度の不正利用の試みには、カタログ画像、加工された写真、複数の申請で再利用された画像などが使われていました。マルチモーダル評価パイプラインは、画像をブレ、明るさ、解像度の前処理チェックにかけ、OCRで検証した後、合意ルールを持つ3つのビジョンモデルの合議制を用いて、自動承認するか人間のレビューに回すかを決定しました。その上に、ブレ検出、スクリーンショット検出、重複検出、画像とSKUの照合、画像と申告理由の照合、および配達証明の検証が重ねられました。

これを大規模に運用して学んだこと

このフレームワークを大規模に運用することで、クイックコマースの枠を超えて一般化できるいくつかの原則を学びました。

• 単一のメトリクスを決して最適化しないこと。かつて私たちはインテントの正解率だけを追い求めた結果、CSAT（顧客満足度）が低下するのを目の当たりにしました。インテントのみを最適化すると、インテントの正解率は5ポイント向上したものの、レイテンシーが133%増加し、CSATが0.4ポイント低下しました。複合的な多目的スコアを採用したところ、レイテンシーの増加をわずか17%に抑えつつ、インテントを3ポイント向上させ、CSATを0.2ポイント高めることができました。複数の視点、LLMによる評価、ルールベースのチェック、人間のラベル、そして本番環境のメトリクスが合わさることで、真実が形作られます。その冗長性は無駄ではなく、保険なのです。
• ゴールデンデータセットが基盤であること。早期に投資して、何千もの多様で高品質なサンプルを確保しましょう。開発環境と本番環境の精度のギャップを追跡し、それが収束するまで調整します。開発と本番のギャップは、謎ではなく、データセットの品質を示すシグナルです。
• LLMによる評価者にはキャリブレーションが必要であること。評価者を、独自の評価を持つモデルとして扱います。人間との一致度を測定し、リスクの高いケースではアンサンブルを使用し、ベースモデルが変更されたときには再調整を行います。
• サンプリングレートよりもサンプリング戦略が重要であること。単純な一様サンプリングは低コストですが、問題を見落とします。リスクの高いフローに焦点を当てた層化サンプリングは、コスト効率よく桁違いに優れた問題検出を可能にします。
• 初日からフィードバックループを自動化すること。検出、ラベリング、再学習、デプロイ、監視はすべて自動化されるべきであり、失敗するたびに次の学習ラウンドが自動的に強化されるようにします。私たちの場合、これにより月に約155時間が節約され、これはフルタイムのエンジニア2人分を機能開発に振り向けられることに相当します。
• 評価をプロダクトのインターフェースとして扱うこと。ダッシュボードやメトリクスは、サポート、プロダクト、不正対策、運用の各チームによって使用されます。それらは単に技術的に正しいだけでなく、解釈可能で実用的なアクションにつなげられるものでなければなりません。

エージェント開発者への推奨事項

Databricks上でエージェントシステムを構築している組織に対して、Zeptoの経験は以下のロードマップを示唆しています。

• モデルだけでなく、トレースから始める：共通のトレーススキーマを適用し、すべてをDeltaにログ記録する
• MLflow評価をCI/CDの必須ゲートにする：合意されたメトリクスでベースラインを上回らない限りデプロイしない
• ゴールデンデータセットを資産として構築し、独自のKPI（サイズ、開発と本番のギャップ、エッジケースのカバー率）を設定する
• 現在人間が判断していること（品質、共感、根拠性）にLLM-as-judgeを使用する。ただし、キャリブレーションを行い、適切なセグメントに限定する
• 層化サンプリングとリアルタイムアラートをできるだけ早期に実装する。後から運用の可視性を後付けするのはコストがかかります
• エージェントを垂直型（専門化）と水平型（監視）に設計し、単体でも組み合わせても評価できるようにする

結論

実験的なデモからミッションクリティカルなインフラへの移行において、主な制約は生のモデルの能力からシステムの保証へとシフトしています。Zeptoの歩みは、評価を開発の基本プリミティブとして確立することで、品質、コスト、リスク軽減に関する厳格な保証に裏打ちされた、マルチモーダルな入力にわたる毎日何万件もの複雑なインタラクションを処理するエージェントを、組織が確実にスケールできることを示しています。

DatabricksとMLflowはこの進化に不可欠な基盤であり、Unity CatalogとDelta上のトレース中心のデータインフラストラクチャに加え、スケーラブルな評価、プロンプトの自動最適化、シームレスなCI/CD統合を提供します。この構成可能なスタックとモデルの選択肢を組み合わせることで、チームは特定のタスクごとにパフォーマンスとコストのバランスを微調整できるようになります。

結局のところ、競争上の優位性は、評価を最終チェックとしてではなく、コアなAIインフラストラクチャとして扱うという戦略的決定にあります。本番規模のエージェントを運用するための設計図（ブループリント）は、もはや謎ではありません。ZeptoとDatabricksがその答えを提供しています。現在の課題は、導入のスピードです。急速に進化するAI環境において、リーダーとなるのは、完璧な確実性を待つ人々ではなく、初日から信頼性を考慮して設計する人々です。

本番環境で信頼を獲得する必要があるエージェントを開発している開発者向けに、これらと同じ基盤となるビルディングブロックがDatabricksとMLflow 3で用意されています。次のフロンティアを切り拓く組織は、今日から「評価ファースト」の取り組みを始める組織となるでしょう。

Databricksでのエージェント構築
MLflowの評価とモニタリングを開始する

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事