レガシーからレイクハウスへ：MazdaはどのようにGenAIをテクニカルサービスオペレーションに活用したか

自動車サービス業界はプレッシャーにさらされています。電話の問い合わせ件数は増え続け、電気自動車は新たな診断の複雑さをもたらし、コネクテッドカーはサービスホットラインのエージェントが現実的に処理できる以上のデータを生成しています。毎年のように、数百ものサービス情報（SI）ドキュメントがリリースされ、それぞれに固有の手順と条件があります。変更があった場合、サービスホットラインのエージェントは、不慣れな問題について技術者を自信を持って案内できるようになる前に、それを吸収する時間が必要です。顧客が待っている状況では、その遅延は重要です。

マツダはすでにこの問題を解決するための材料を持っていました。保証、リコール、診断コード、サービス、車両履歴のレイクハウスが成長し続けており、サービスドキュメントのライブラリも常に更新されていました。課題は、これらのアセットを、エージェントが正確性、一貫性、自信を持って業務を遂行する能力を高める方法で統合することでした。

そこでDatabricksが登場しました。マツダのデータサイエンスチームは迅速に行動し、実践を通じて学び、約8週間でキックオフから動作するコンセプトまで到達しました。長期的な計画段階はありませんでした。チームは構築し、テストし、問題を解決し、進めながら調整を行い、マツダにとって真の影響と価値をもたらすパイロットを提供しました。

出発点：大きな野心を持つ少人数のチーム

このプロジェクトは、マツダ初のクラウドデータプラットフォーム上に構築されたエンドツーエンドのGenAIイニシアチブの1つでした。チームは少数（2人のデータサイエンティストが迅速に反復作業）で、ツールも初期段階でした。データパイプラインを構築する必要がありました。ドキュメントを抽出し、ベクトル検索インデックスに変換する必要がありました。実験は独立したノートブックで行われ、成功はトレーサビリティよりも記憶に依存していました。

このような少人数のチームにとって、インフラストラクチャのオーバーヘッドは最小限にする必要がありました。それがDatabricksを選択した大きな要因でした。このプラットフォームは俊敏性を可能にしました。ベクトルデータベースの管理、分散コンピューティングフレームワークの設定、カスタムオーケストレーション、それらを連携させるためのグルーサービスの必要はありませんでした。焦点は価値の構築にあり、インフラストラクチャではありませんでした。

パイロットの構築

パイロットの初期段階では、チームは主にLLMをカスタムコーパスに接続することに焦点を当てたRetrieval Augmentation Generation（RAG）設計に注力していました。しかし、マツダはテスターがまず車両の全体像を把握したいと考えることが多いことに気づきました。つまり、サービス履歴、未解決のリコール、過去のホットラインエスカレーション、保証状況などです。

その観察が、意図的なアーキテクチャの選択を形作りました。フロントエンドとエージェントはコードとツールを共有します。車両データへのアクセス、変換、プロンプトロジックは一度実装され、Streamlitインターフェースとデプロイされたエージェントエンドポイントの両方で同じように使用されます。

サービスエージェントがセッション開始時にVINを入力すると、フロントエンドは完全な車両コンテキスト（修理履歴、ホットラインエスカレーション、保証データ、リコール状況）をプリロードし、最初のメッセージが送信される前にシステムプロンプトに注入します。これにより、ツール呼び出しが不要になり、即座に対話が可能になります。

一方、AIエージェントがプリロードされたコンテキストなしで呼び出された場合、ユーザーが対話するのと同じツールボックスを使用します。どちらの場合も出力は構造的に同一であり、システムプロンプトは両方のパスを明示的に処理します。注入されたコンテキストが存在する場合はそれを使用し、存在しない場合はツールを呼び出します。1つのプロンプト、2つの実行モード、インターフェース間の動作ドリフトはありません。

Unity Catalog

このソリューションはDatabricks Lakehouseによって強化されています。Unity Catalogは、サービスエージェントが日常的に利用するデータへのガバナンスされたアクセスを提供し、埋め込み、ベクトル検索、SQLツール呼び出し、モデルサービングがすべて同じ環境で実行されるため、開発が簡素化され、統合の摩擦が解消されます。マツダは、基盤モデルAPI（トークンごとの支払い）を介してLLMを使用し、マネージドベクトル検索エンドポイントを介して埋め込みモデルを使用しました。

SIドキュメント、車両履歴と診断コードを含むDeltaテーブル、ベクトル検索インデックス、データ変換、モデルなど、すべてがUnity Catalog内に存在します。統合されたガバナンスは、特定のデータサブセットへのアクセスを分離し、オンザフライで変更を加え、その影響を即座に観察できることを意味します。その後、Databricks AppsがStreamlitフロントエンドでこれをまとめ、サービスチームは新しいトレーニングやツールなしで使用できます。

Unity Catalog Functionsによる正確なコーパスフィルタリング

完全なコーパス全体での単純なベクトル検索では、意味論的にはもっともらしくても、必ずしも技術者の目の前にある車両に適用可能ではない結果が返されます。検索を正しく行うには、関連性の問題を解決する前にスコープの問題を解決する必要がありました。

チームは、Unity Catalogのユーザー定義関数を通じてフィルタリングを実装しました。ベクトル検索が実行される前に、システムはVIN（または診断トラブルコード）をその車両に適用可能なドキュメントのサブセットにマッピングするUC関数を呼び出し、意味論的なマッチングを適用可能なドキュメントのみに制限します。

このロジックをアプリケーションコードではなくUnity Catalog関数としてホストすることにより、適用可能性のルールは、それが管理するデータとともに存在し、エージェントおよび他のダウンストリームアプリケーションからアクセス可能になり、エージェントのデプロイメントサイクルとは独立して更新できます。

アドホックテストからテスト駆動開発へ

マツダは、10人のサービスエージェンারテスターでこのアプリケーションをパイロットしました。パイロットの初期段階では、イテレーションはフィードバック駆動でした。テスターが問題を報告し、チームがプロンプトまたは検索設定を調整し、結果を非公式に評価しました。これは初期開発には機能しましたが、システムがより複雑になるにつれてスケーリングしませんでした。

MLflow 3のネイティブGenAI評価フレームワークがチームのワークフローを変えました。MLFlow 3は、評価データセットを作成するための包括的な方法と、さまざまなLLMおよび決定論的スコアラーを提供します。迅速なテストのために、ドラフト評価データセットはYAMLで定義されてから標準評価データセットに昇格されます。テスターがギャップを指摘すると、チームはそれを評価データセットに追加し、それらのケースをパスすることを修正の受け入れ基準と見なしました。新しい機能とデータソースが追加されたとき、統合が受け入れられる前に新しい評価ケースが作成されました。

結果として、「より良くなったように見える」から「実際に良くなり、ここにその証拠がある」へと移行しました。実験トレースは、プロンプト、検索戦略、トークン数、および応答品質メトリクスをキャプチャしたため、変更を記憶ではなく客観的に比較できました。

多言語機能

初期の迅速な成功により、同じアーキテクチャが他の地域にも対応できるかどうかという疑問が生じました。多言語埋め込みモデルを試した後、チームは、コアアーキテクチャとツールに変更を加えることなく、LLMがユーザープロンプトと最終応答を翻訳できることに気づきました。これは、マツダがアプリケーションを市場全体に拡大するというより広範な計画に影響を与えます。

ガバナンス

Apps、クラスター、ウェアハウス、エンドポイント、エージェント全体で権限を調整するには学習曲線がありましたが、標準化されると、安全で将来のGenAIアプリケーションに適用可能な再利用可能なガバナンスパターンが作成されました。機能したパターンは次のとおりです。すべてのアクセスをサービングエンドポイントのサービスプリンシパル経由でルーティングし、カタログおよびスキーマレベルでロールベースのアクセス制御グループへの付与を定義します。これが確立されると、再利用可能になりました。新しいモデルまたはデータソースのオンボーディングは、権限構造の再交渉ではなく、同じスキーマに対する同じサービスプリンシパルへのアクセスを付与することを意味しました。プライベート接続をAIトラフィックに組み合わせることで、マツダはアプリケーションとガバナンスされたデータ間の制御された安全なパスを得ることができます。

Databricksフィールドエンジニアリングチームとのパートナーシップにより、マツダはベストプラクティスに導かれ、障害を未然に防ぐことで、より迅速に進むことができました。

影響と今後の展望

マツダは現在、構造化データと非構造化データを組み合わせたGenAIアプリケーションのための再現可能な基盤をレイクハウス内に持っています。ベクトル検索インデックス、モデルサービング、評価、オブザーバビリティ、カタログレベルのガバナンス、Webアプリを通じたフロントエンド配信などです。これらの機能を単一のプラットフォームで利用できるようになったことで、複数のサービスを連携させる必要がなくなり、開発が大幅に加速しました。

サイロ化されたノートブックから始めた2人のデータサイエンティストは、現在、Databricks上で完全なトレーサビリティを持つAIアプリケーションと実験を実行しています。チームは、このアプローチを他の診断ワークフローに拡大しており、生成エージェントが技術者、フィールドエンジニア、カスタマーサポートをどのように支援できるかを探求しています。

このシフトは技術的なものだけではありません。マツダは、記述的なレポートから、ガバナンスされたエンタープライズデータ上に直接構築されたインテリジェントな生成アプリケーションへと移行しています。

テイクアウェイ

GenAIアプリケーションを構築するために、大規模なチームや成熟したMLOpsプラクティスは必要ありません。Mazdaは2人のデータサイエンティスト、タイトなスケジュール、そして多くのことを学ぶ必要がありました。Databricksプラットフォームは予想以上に多くの重労働を担い、Databricksは私たちが実際に動作するものを迅速に出荷するのに役立ちました。

プロジェクトの核心は、Mazdaの指針である「おもてなし」の精神の表現です。Mazdaのテクニシャンサービスエージェントに優れたツールを提供することで、顧客をより適切にケアできるようになります。そして今、この基盤が整ったことで、チームは始まったばかりです。

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