Lyftが生産環境で意味のある評価を構築する仕組み

Lyft が本番環境で AI エージェントを信頼できるものにする評価戦略

Lyft のデータサイエンスチームは、月間 7900 万回の利用と 27 万件の AI インタラクションを処理する大規模顧客対応 AI「AI Assist」において、従来の汎用的なスコアリングに頼らない評価体系を構築しました。彼らのアプローチは、単なるベンチマーク数値の向上ではなく、「実際のビジネス課題が解決されたか」という実効性を担保するための厳格な品質ゲートと、現実的なユーザー像をシミュレートする擬似ユーザーの活用にあります。

オフライン評価を「品質ゲート」として再定義する

AI エージェントを本番環境にリリースする際、多くのチームが「ユーザーを実験データとして使う」ことに躊躇しますが、Lyft の Nick 氏はこれを明確に避けるべきだと指摘します。大規模企業において顧客をテストデータとして使うことはリスクが高すぎます。

「オフライン評価は品質ゲートとして機能します。ユーザーをテストデータとして使いたくありません。」

従来の機械学習（ML）エンジニアリングでは、ノートブック上で正解ラベル付きのデータセットでモデルを訓練し、リリース前にオフライン評価を行うのが標準でした。Nick 氏は、AI エンジニアリングにおいてもこの原則は変わらないと主張します。

Lyft が構築したのは、軽量なシミュレーターです。LangGraph で動く AI エージェントに対し、LLM を使用した擬似ユーザー（LLM User）を配置してエンドツーエンドのインタラクションを生成します。設定ファイル（YAML）で「世界の状態」「ユーザーの意図」「ペルソナ」を定義し、多様な組み合わせによる長い軌道チェーンを自動生成します。

このシミュレーションでは、外部ツール（MCP サーバーなど）への呼び出しもモックデータで行うため、ネットワーク依存なく安全にテストが可能です。これにより、本番環境での振る舞いを予測する強力な代理指標が得られます。

汎用スコアではなく「タスク固有のルブリック」を採用する

多くの LLM 評価システムでは、「有用性」「自然さ」「トーン」といった抽象的な指標を 0 から 1 のスカラー値でスコアリングします。しかし、Nick 氏はこの手法に重大な欠陥があると指摘します。

「0.4 というスコアが 0.7 と比べて何を意味するのか？どうすれば改善できるのか？全体スコアを上げることが、どのような製品上の洞察につながるのでしょうか？」

抽象的な数値は、エンジニアやプロダクトチームにとって具体的なアクションに結びつきにくいのです。Lyft が採用したのは、タスク固有のルブリック評価です。

AI エージェントには「ポリシーの説明」「損傷請求の処理」など複数のタスクがあり、それぞれに明確な成功・失敗基準（ルブリック）を設けます。例えば、「ライド利用料に関するポリシー説明」タスクにおいては、特定の条件が満たされたかどうかをコードアサーションで判定します。

このアプローチの利点は、評価結果から即座に「どのような一般的な失敗モードが発生したか」を把握できる点にあります。エンジニアはプロンプトやツールロジックを修正し、ルブリック基準を満たすまで改善ループを回すことができます。これにより、数値の向上ではなく、具体的な問題解決が追求されます。

理想化された LLM を避ける「現実的な LLM ユーザー」

オフライン評価で最も陥りやすい罠の一つに、「LLM が親切で丁寧なアシスタントとして振る舞う」というバイアスがあります。実際のユーザーは、一語二語の短文でせっかちに質問をするものです。

Nick 氏は、標準的な LLM をユーザー役として使うと、評価結果が 90% という高得点になりがちだが、本番環境では厳しい現実に直面すると警告します。

「LLM は私たちの AI エージェントに非常に丁寧に問題を説明します。しかし、実際にサポートに問い合わせる際はそうはしません。」

このバイアスを解消するため、Lyft は実在するユーザーの発言データでトレーニングした擬似ユーザー（LLM User）の開発を進めています。

Microsoft の研究に基づき、実際の顧客の逐語データを学習させたカスタム LLM を使用することで、「現実的なユーザー」をシミュレートします。技術的には評価が難しくなり、ベンチマークスコアは低下するかもしれませんが、本番環境でのパフォーマンスを正確に予測できる「良い代理指標」として機能します。

LangSmith による自動化と人間フィードバックのループ

評価システムを運用し続けるためには、LangSmith などの観測プラットフォームを活用した自動化が不可欠です。Lyft は以下の仕組みで継続的な改善を実現しています。

1. トレーシング: オフラインシミュレーションと本番環境でのすべてのインタラクションを LangSmith で記録・管理します。
2. 自動アノテーションキュー: LLM ジャッジの基準を満たさない失敗事例（トレース）が検出された際、自動的に注釈キューへ送信されます。
3. 人間による分析: 運用チームやエンジニアは、このキューから例を選び出し、手動でラベル付けして系統的な失敗モードを分析します。
4. フィードバックループ: 分析結果はプロンプト調整やモデル改善に反映され、再び評価パイプラインへ戻されます。

また、LLM ジャッジ自体の信頼性確保のため、ドメインの専門家による人間ラベル付きデータで LLM ジャッジを訓練するプロセスも実施しています。これにより、人間の判断と整合した評価者が獲得されています。

まとめ

Lyft の事例は、大規模企業における AI エージェント導入において、「単なるスコア向上」から「実効性の担保」へとパラダイムシフトすべきことを示しています。タスク固有のルブリックと現実的なユーザーシミュレーションを組み合わせ、LangSmith を活用した自動化フィードバックループを確立することで、AI の信頼性を劇的に高めることが可能になります。