Aimpoint Digital: AIで旅のプラン作りがもっとスマートに！

インスピレーション

休暇を楽しむことは楽しい経験ですが、旅行の計画を立てるのはほとんどの人にとって時間と労力がかかります。訪れる場所は無数にあり、食事をするレストランは数え切れないほどあり、レビューを見て決定を下すことは終わりがありません。 Expediaによる最近の調査結果によれば、旅行者は旅行の調査と計画に5時間以上を費やしています。人々は旅行のアクティビティを最終決定する前に最大で約270のウェブページを訪れ、このプロセスは旅行の45日前から始まることもあります。選択肢が多すぎるため、旅行の計画は一部の人々にとって圧倒的なものになることがあります。GenAIを活用してこのプロセスを効率化し、30秒以内に行程を作成することは可能でしょうか？旅行者が自分の行程に活動をカスタマイズして調整するパーソナルエージェントを持つことができたらどうでしょうか？このブログでは、旅行の行程を作成するためにDatabricks Data Intelligence Platformと共に開発したAIエージェントシステムの詳細について深掘りします。 

アプローチ

過去数年間で、生成型AIは旅行業界を劇的に形成してきました。ChatGPTのような独立したGenAIツールは、旅行の行程を生成することができます。しかし、最新の情報を欠いたLLMに基づいているため、旅程が誤解を招くか間違っている可能性があります。例えば、2024年12月にモロッコへの旅行を計画している旅行者を想像してみてください。2023年12月に最後に訓練されたLLMは、2024年7月に閉店したレストランを知らない可能性があり、旅行者に誤ってそれを推奨するかもしれません。ほとんどのLLMは、最新のデータで訓練されたり、微調整されたりしていないため、この「最新性の問題」に苦しんでいます。もう一つの課題は、LLMが幻覚を見たり、不正確な情報を作り出す可能性があることです。

Retrieval Augmentation Generation（RAG）を使用すると、LLMは訓練データを最新のデータで補完することができ、LLMの最新性と幻覚問題を解決します。RAGは、最新の情報を含むデータベースを定期的に更新することで、最新性の問題を克服します。これらのデータベースはベクトルデータベースと呼ばれ（一例としてDatabricks Mosaic AI Vector Searchがあります）関連するデータをベクトル化した埋め込みとして保存します。このベクトルデータベースは、これらの観光地のデータ、開閉時間などを毎晩更新します。このRAGフレームワークは、旅行者の興味に基づいて最も関連性のある場所を検索し、正確な旅程を作成するGenAIアプリケーションを動かすことができます。

AIエージェントシステム

旅行行程は観光地だけで完結することは少なく、旅行者は目的地でのレストランやイベントの情報を求めることがあります。この問題を解決するために、私たちはAIエージェントシステムの中で複数のRAGを組み合わせました（一つは場所、一つはレストラン、一つはイベントのためのもの）。

AIエージェントシステムは、単一のLLMに依存するGenAIアーキテクチャから、複数のコンポーネント、リトリーバー、モデル、ツールを統合する進化を表しています。複数の相互作用するコンポーネントを含むシステムは、標準的なテストの幅広い範囲で単独のAIモデルよりも優れたパフォーマンスを発揮することが証明されています。2024年6月の最近の研究論文では、研究者たちは、予定された役割を持つLLMが互いに相互作用することを許すと、ソフトウェアエンジニアリングタスクのための高品質なコードを生成することができることを示しています。これらのLLMは詳細な役割の説明（開発者、シニア開発者、プロジェクトマネージャーなど）を持ち、ソフトウェアコードの作成、レビュー、テストを交代で行うことができます。これは、一群のLLM（またはエージェント）が単独のLLMよりも優れたパフォーマンスを発揮するAIエージェントシステムの優れた例です。これらのシステムの明確な利点を考慮に入れ、私たちは旅行計画生成ツールのAIエージェントの作成を追求することにしました。

ユーザークエリによる旅行計画生成

旅行者の計画や興味に関する情報を収集し、関連性の高い価値ある旅行計画を生成する必要があります。これらのパラメーターには、目的地の都市、目的地の国、旅行の日程、旅行の目的（ビジネス、レジャー、レクリエーションなど）、旅行の同伴者（友人、パートナー、ソロなど）、予算などがあります。ユーザークエリから生成された入力は、埋め込みモデルを通過し、旅行者のプロフィールに密接に一致する場所、レストラン、イベントを取得するために使用されます。

アーキテクチャの動機付け

場所、レストラン、イベントを含む旅程を生成するために、私たちのアーキテクチャは並列に配置された3つのRAGで構成されていました。ユーザーのクエリは埋め込みモデルを使用してベクトルに変換され、各RAGのリトリーバーはそれぞれのベクトル検索インデックスから最上位のマッチを取得しようとします。取得されたマッチの数は旅行の長さに対応しており、短い旅行では活動が少なく、長い旅行では活動が多く必要となります。平均的に、私たちのシステムは毎日3つの場所やイベント、そして3つのレストラン（朝食、昼食、夕食）を取得するように設定されています。

私たちのソリューションは、2つのベクトル検索インデックスを利用しており、将来的に数百のヨーロッパの都市への拡大をサポートする柔軟性を提供します。パリの約500のレストランのデータを収集し、市内全体で約50,000にスケールする計画です。各ベクトル検索インデックスは、ランタイム中の簡単なクエリを保証するために、独立したDatabricksベクトル検索エンドポイントにデプロイされています。さらに、観光地、レストラン、イベントに関する生の情報を含むすべてのデータソーステーブルは、「Change Data Feed’を利用したDeltaテーブルです。これにより、生データの変更がベクトル検索インデックスを手動で介入することなく自動的に更新することが保証されます。異なるRAGsに対して3つの同時呼び出しが並行して行われ、推奨事項を収集します。

シリーズの最後の呼び出しは、レスポンスを合成するためにLLMに行われます。RAGが場所、レストラン、イベントを取得した後、私たちはLLMを使用して、これらの推奨事項を一貫した旅程に組み合わせます。私たちは、DBRX InstructやMeta-Llama-3.1-405b-InstructなどのオープンソースのLLMをDatabricks上で、組み込みのガードレールを使用してAIエージェントシステムの誤用を防ぐProvisioned Throughput Endpointsとともに使用しています。

取得メトリクス

私たちは、レストラン、観光地、イベントのリトリーバーのパフォーマンスを評価するために、いくつかの指標を使用しました。

• Precision at k: 簡単に説明すると、Precision at kは、上位kの取得文書の中で、特定のクエリに実際に関連するアイテムがいくつあるかを示します。文書が取得されない場合、Precision at kは0です。ここにPrecision at kの正確な定義についてのMLFlowのドキュメンテーションがあります。

• kでのリコール： kでのリコールは、取得したkのドキュメントの中の関連する結果の割合を、全体の関連するドキュメントに対して教えてくれます。関連するドキュメントが取得されない場合や、適切な基準のドキュメントが指定されない場合、kでのリコールは1となります。 kでのリコールについてのMLFlowのドキュメンテーションはこちら。 

• NDCG at k: Normalized Discounted Cumulative Gain (NDCG) at kは、取得者を評価するために関連性スコアを使用します。バイナリスコアは、グラウンドトゥルースにある取得文書（関連性=1）と、グラウンドトゥルースにない取得文書（関連性=0）に使用されます。関連性スコアのセットが割り当てられると、NDCGは累積ゲイン（CG）の概念を使用します。これは、設定された閾値（k）で取得された関連文書の総数を測定します。例えば、あなたの取得者が上位10の関連文書を取得するように設定されている（k = 10）が、取得された文書のうち7/10だけがグラウンドトゥルースの一部である場合、CGは7です。

しかし、CGは、正しく取得された7つの文書のランクについての全体像を描き出すことはありません。取得された10の文書の中で、2/10の文書は9/10の文書よりもクエリに似ています。これを考慮に入れるために、我々はDiscounted Cumulative Gain (DCG)の概念を導入します。これは、正しく取得されたが元のクエリに似ていない文書に対する対数的なペナルティです。DCGを正規化するとNDCGが得られます。NDCG at kについての公式MLFlowドキュメンテーションはこちらです。

LLM-as-a-Judge

私たちはLLMを使用して旅行行程のプロフェッショナリズムを評価しました。これは、AIエージェントソリューションからのレスポンスを評価する自動化された方法で、LLMは良好な評価を行うために以下の入力を必要とします。
 

• メトリックの定義: LLMが評価するメトリックの明確な定義。この定義は、LLMにレスポンスのどの部分を評価する必要があるかを伝えます。
  
   
• ルーブリック：LLMのスコアリングガイドとして機能する明確に定義されたルーブリック。私たちのスコアリングガイドは1-5の範囲で、各レベルで必要な専門性のレベルについて明確な説明がありました。LLMを混乱させないためには、異なるスコアレベルができるだけ異なることが重要です。
  
   
• フューショットの例： 専門性のレベルが異なる旅程の例がLLMにとっての例となります。これにより、LLMは正しいスコアを割り当てるようにガイドされます。
  
   

以下は、LLM-as-judgeによって評価された私たちのいくつかの応答と、なぜ特定の方法でスコアが付けられたのかについての根拠です。

プロンプトの最適化

私たちのアーキテクチャにおけるLLMへのプロンプトは、最終的に合成される旅程の品質と形式にとって重要です。プロンプトに微妙な変更を加えると、出力に大きな、意図しない影響を及ぼすことがあることを私たちは観察しました。これを緩和するために、私たちは DSPyという最先端のパッケージを使用しました。DSPyは、カスタム定義のメトリックと共にLLM-as-a-judgeを使用して、基準となる真実のデータセットに基づいて応答を評価します。以下のコードスニペットに示すように、私たちのカスタムメトリックは以下のルーブリックを使用して応答を評価しました：
 

• 旅行行程は完全ですか？それは旅行者がプロンプトで示したことと一致していますか？
• 旅行者は公共交通機関などを利用して、旅行計画の場所間を合理的に移動できますか？
• レスポンスは礼儀正しく、友好的な言葉を使用していますか？

DSPyを使用してプロンプトを最適化すると、結果に非常に焦点を当てた正確なプロンプトが生成されることに気付きました。LLMが特定の方法で応答するように強制する追加の言語は排除されました。最適化されたプロンプトの品質は、定義されたカスタムメトリックとグラウンドトゥルースの品質に大きく依存することに注意が必要です。

ツール呼び出しについての注意

私たちのアーキテクチャは、場所、レストラン、イベントの推奨事項を取得するために3つの並列呼び出しを行うAIエージェントシステムを利用しています。トップのオプションが集められたら、最終的にLLM（Large Language Model）に呼び出しを行い、これらの推奨事項を統合した旅行行程を作成します。私たちのAIシステムのコンポーネントが呼び出される順序は固定されており、これが一貫して信頼性の高い旅行行程を生成することがわかりました。

代替的なアプローチでは、旅行者の好みに基づいて、どのツールを呼び出し、何の順序で呼び出すかを動的に決定するために別のLLMを使用することが考えられます。例えば、旅行者がイベントに興味がない場合、Events RAGはトリガーされません。この方法は、ツール呼び出しとして知られており、旅行者のニーズにより効果的に旅行計画をカスタマイズすることができます。不要なツールをスキップすることで、レイテンシーも改善する可能性があります。しかし、ツール呼び出しを使用して生成された行程は一貫性が低く、適切なツールを選択するためのLLMが時折エラーを起こすことが観察されました。

このアプローチは私たちのアプリケーションとは一致しませんでしたが、LLMをツール呼び出しに使用することはまだ研究の途中であり、将来の開発に大きな可能性があるという点を強調しておきたいと思います。

まとめ

AI駆動の行程生成ツールは、旅行業界において変革的な可能性を示しています。開発中、ツールはステークホルダーから圧倒的に肯定的なフィードバックを受け、シームレスな計画体験と推奨の精度を評価しました。このソリューションのスケーラビリティは、多様な旅行先に対応できることを保証し、より広範な実装に適応可能にします。このAIエージェントシステムが進化するにつれて、ダイナミックな価格設定ツールとのより深い統合、多様な旅行好みの強化された文脈理解、リアルタイムの旅程調整のサポートが期待されます。

Aimpoint Digitalについて

Aimpoint Digitalは、データと分析技術を通じて最も複雑なビジネスと経済の課題を解決する先端の市場リーディング分析会社です。自己サービス分析の統合からAIの大規模実装、データインフラストラクチャ環境の近代化まで、Aimpoint Digitalは組織のパフォーマンスを向上させるための変革的な領域で活動しています。詳細は以下をご覧ください： https://www.aimpointdigital.com/