Search Tuningでドキュメント検索を一段深く

本題に入る前に、開発者として名前は気になるところですし、これらの機能の製品名は変遷が激しく追いきれなかった方も多いはずなので、まず整理しておきましょう。2023年初頭にGen App Builderとして登場したこのサービスは、まもなくVertex AI Search and Conversationへと名称が変わり、現在はVertex AI Agent Builderと呼ばれています。

呼び名がはっきりしたところで、いよいよ何ができるのかを見ていきましょう。

Vertex AI Agent Builderは、企業が生成AIを手軽に活用できるようにするGoogle Cloudの仕組みです。対話型AI、セマンティック検索、さらにはRetrieval Augmented Generation(RAG)システムの構築に必要な数多くの作業を抽象化し、最先端の基盤モデルと、25年にわたって培われてきた世界屈指の検索技術を活かせるようにしてくれます。

Vertex AIスイートの他のサービス(たとえばGemini 1.5 Pro APIやVector Search)と比べると、よりマネージド寄りの位置づけで、その分カスタマイズ性や柔軟性は控えめです。代わりに、市場投入までの時間を短縮でき、社内に希少な専門人材を抱えていなくても始められるのが利点です。

Vertex AI Agent Builderでは、Vertex AI AgentsとVertex AI Searchを利用できます。

• Vertex AI Agentsは、大規模言語モデル(LLM)を基盤とした自然言語理解プラットフォームを使い、対話型UIを手軽に構築できます。
• 一方のVertex AI Searchは、AIを活用した検索・レコメンデーション体験の構築を支援します。

本記事では、Search Tuningを提供しており、データチェックスクリプトの対象でもあるVertex AI Searchを取り上げます。

網羅的な解説についてはこちらのドキュメントをご参照ください。

Vertex AI Searchでは、検索アプリとレコメンデーションアプリを構築できます。本記事では検索アプリに焦点を当てます。

主な特長は次のとおりです。

• 追加実装なしで使える自然言語理解とセマンティック検索。セマンティック検索は、検索クエリの背後にある文脈や意図まで読み取ります。一方、キーワード検索のような従来型の手法は特定キーワードの完全一致に頼り、その背景や意図までは捉えません。たとえば「Appleが最後にiPhoneを発表したのはいつ?」と検索した場合、セマンティック検索はApple Inc.のことを指していると理解し、果物のリンゴとは取り違えません。
• 同義語の理解、スペル補正、検索候補のサジェストといった機能をすぐに利用可能。
• 非構造化ドキュメントに対する生成AIによる要約や対話型検索を実現。たとえば、どの形式の応答を返すかを選択できます。

- 検索(シングルターン)

- 回答付き検索(要約付きのシングルターン検索)

- フォローアップ付き検索(マルチターン検索)

Vertex AI Searchのセットアップは、大きく2つのステージに分かれます。

1. 準備:データストアを作成し、構造化データまたは非構造化データを取り込みます。データはメタデータと併せて処理・チャンク分割・エンベディングされ、Google Cloud上の高性能ベクトルデータベースVector Searchに格納されて検索可能になります。ここでもいくつかカスタマイズできます。独自スキーマの持ち込み、独自のエンベディングの持ち込み(本記事執筆時点ではプレビュー)、さらにはパースとチャンク分割のカスタマイズまで可能です。
2. ランタイム:ユーザー入力を使って実際にクエリを実行する段階です。関連ドキュメントを取得し、必要に応じてそれらをもとに回答を生成します。ここでもカスタマイズの余地があります。プロンプトはもちろん独自のものを使えますし、結果のフィルタリングなどに使うコントロールを指定したり、応答に短い回答(スニペット)を返すか、長めのパラグラフ(抽出回答またはセグメント)を返すかを選んだりできます。独自のランカーは持ち込めませんが、それについては後ほど触れます。

非構造化データストア(PDF)に対する抽出セグメントの例。元ファイルのページ番号が参照に含まれている点にご注目ください(スペースの都合でスクリーンショットは調整済み)。

では、検索結果の品質に100%満足できないときはどうすればよいのでしょうか。そんなときは、非構造化データストア向けのSearch Tuning機能(本記事執筆時点ではプレビュー)の出番です。検索対象のデータが自社特有のニッチな内容である場合、汎用モデルでは精度の高い検索が難しいことがあります。そんなときも大丈夫。少しデータを与えるだけで、モデルを鍛えられます。

Search Tuningの使い方

具体的には、3つ、場合によっては4つのトレーニングデータセットを用意します。

1. トレーニングクエリ:ユーザーがシステムに投げると想定される検索クエリです。例:

限定水域ダイブにおける生徒対インストラクターの最大比率はどれくらいですか?

2. 抽出セグメント:データストア(コーパス)内のドキュメントから取り出したスニペットです。一部は上記のクエリに対する回答となるもの、その他はそうでないものを混ぜます(前者はモデルへのポジティブ強化、後者はネガティブ強化として、それぞれ役割を担います)。セグメントは十分な長さも必要です。例:

## 比率

### 限定水域 10:1 — 認定アシスタント1人につき、生徒ダイバーを4人まで追加可能。

### オープンウォーター 8:1 — 認定アシスタント1人につき、生徒ダイバーを2人まで追加可能。

3. 関連性スコア:クエリと抽出セグメントを非負整数のスコアで結びつけるトレーニングラベルです。0はそのセグメントがクエリに無関係であることを示し、スコアが大きいほど関連性が高いことを意味します。例:

このケースでは、セグメントが質問に対する答えになっているため、関連性スコアは1となります。

4. (任意)テストラベル:関連性スコアと似たデータですが、こちらはチューニング後のモデル性能の評価に使われます。自分で用意しない場合、Search Tuningは3で定義したトレーニングラベルのクエリのうち20%を自動的に評価用に振り分けます。

つまずきやすいポイント

これらのデータはファイルとして提供する必要があり、決められたフォーマットや要件を満たさなければなりません。実際、一部のお客様がこのサービスを利用しようとした際にエラーコード13と「内部エラーが発生しました。再度お試しください。問題が解決しない場合は、サポートチームまでお問い合わせください。」というメッセージに直面するという事例がありました。

原因をたどると、ファイルの一部がドキュメント記載の要件を満たしていなかったというものでしたが、エラーメッセージからはその情報が読み取れませんでした。ご安心を。そこでDoiTの出番です。フォーマット不備のファイルを早期に発見し、エラーを未然に防ぐためのシンプルなチェックスクリプトを用意しました。GitHubで公開しており、実行も次のように簡単です。

python search_tuning_checks.py.py <corpus_path> <query_path> <scoring_path>`.

出力例は次のようになります。

General dataset checks
 - - - - - - - - - - -
Number of segments in Corpus file that don't have a match in Scoring file: 6030
Number of segments in Scoring file that don't have a match in Corpus file: 1551
Number of queries in Query file that don't have a match in Scoring file: 0
Number of queries in Scoring file that don't have a match in Query file: 0
Documentation dataset checks
 - - - - - - - - - - - - - -
Training query requirements met: ✅ met
|___ Subcheck: At least one extractive segment per query: ✅ met
|___ Subcheck: At least 10 000 additional extractive segments: ✅ met
Extractive segment requirements met: ✅ met
Relevance score requirements met: ✅ met
|___ Subcheck: At least 100 segments that contain query answers: ✅ met
|___ Subcheck: At least 10 000 random segments: ❌ not met
|___ Subcheck: At least 10 000 segments with 0 as score: ✅ met
Corpus file requirements met: ❌ not met
Query file requirements met: ✅ met
|___ Subcheck: Same ids in query and scoring data: ✅ met
|___ Subcheck: Column 'score' contains non-negative integer values: ✅ met
Training labels requirements met: ✅ met

`general data checks`では、提供データの整合性をチェックします。具体的には、各セグメントのIDがスコア側に存在するか、各クエリのIDがスコア側に存在するかを確認します。

`documentation dataset checks`では、Google Cloudのドキュメントに記載されている次のチェックを実行します。

• トレーニングデータ全般に対するチェック(最初の3項目)
• Corpusファイルに対するチェック
• Queryファイルに対するチェック
• トレーニングラベルファイルに対するチェック

フィードバックループは数時間かかることもあるため、ファイルを送信する前にすべての項目で「✅」が並んでいることを確認する価値は十分にあります。