エンジニア魂が燃えたぎる！生成AI開発イベント「AI Challenge Day」 第7回

今回はECサイト用のバーチャルアシスタント　パワーアップしたお題に8社が挑む！

RAG、マルチモーダル、AIエージェント　AI Challenge Dayで生成AIの高みを目指せ

比較してわかったベクトル検索の最適解

　8社のプレゼンが終わったところで、審査員はいったん退場。審査の間、日本マイクロソフトから「Azureで利用できるベクトル検索比較＆RAGにおけるAI Platform ＆ Tools」というタイトルで技術解説のセミナーが行なわれた。前半のベクトル検索の担当は日本マイクロソフト パートナー事業本部 パートナーソリューションアーキテクトの西村栄次氏だ。

日本マイクロソフト パートナー事業本部 パートナーソリューションアーキテクト 西村栄次氏

　ベクトル検索は文章や画像などさまざまなデータを高次元の数値ベクトル化し、向きや位置、距離が近いモノを探すという検索技術。今回のAI Challenge Dayでも多用されていたAI Searchを筆頭に、RDBMSのSQL Database、PostgreSQL Flexible、Cosmos DB for NoSQL/MongoDB vCore/PostgreSQLなど、さまざまなサービスで利用できる（一部プレビュー）。ドキュメントのプロパティやテーブルの列としてベクトル保存でき、クエリのWhere句や集計などで利用できる。

　このうちCosmos DB for NoSQLでは、マイクロソフトの研究機関であるMicrosoft Researchで開発した「DiskANNベース量子化手法」という大規模データセット用の近似最近傍検索のアルゴリズムが採用されている。メモリ内に圧縮したベクトルグラフインデックス、SSDにベクトルデータ自体を保存し、高次なマッピングを実現。64GBのメモリとSSDのワークステーションで10億インデックスを保存できるという。Cosmos DB自体もデータベースとエンジンがマイクロサービス化されており、高いスケーラビリティを実現している。

　続いてこれらのベクトル検索の比較デモに移る。今回のAI Challenge Dayでも用いられたMicrosoft StoreショッピングガイドというPDFをAzure AIを呼び出して、チャンク分割し、Azure OpenAIを呼び出してEmbeddingして、AI Searchに登録。同じデータをCosmos DB for NoSQL、MongoDB vCore、PostgreSQL Flexibleにそれぞれ登録し、「利用できるクレジットカードについて教えてください」という質問で検索を行なうという流れだ。続いて設定とデモが披露された。

　Cosmos DB for NoSQLは、まずプレビュー機能をオンに。ベクトルインデックスとベクトル埋め込みポリシーを持つコンテナを作成し、システム関数を使用して呼び出すことになる。データエクスプローラーでクエリを実行すると、JSONでID、スコア、ベクトル配列、テキストなどの3件のデータが取得できる。

　続いてMongoDB vCoreの場合は、ドキュメントを登録するコレクションにベクトルインデックスを作成する必要がある。あとは集計パイブラインで$searchを使用して、ベクトルとベクトリ距離を照会する。また、PostgreSQLのFlexibleの場合は、アカウントの拡張機能でベクトル検索を有効にし、対象データベースで ベクトル検索を有効にするコマンドを実行後にテーブル作成時の項目でベクトル型を指定する。あとはベクトル演算子やベクトル関数を使用して検索すると、構造化データとして取得できる。最後は検索サービスのAI Search。こちらはインデックスを作成し、Azure OpenAI Serviceで埋め込みを作成し、インデックスを検索するという流れになる。

　続いて、これらベクトル検索の選定。前者のデータベースは、すでに構造化・半構造化されたデータベースにベクトル検索を追加する場合、トランザクションの対象としたい場合に利用するという。AI Searchはデータソースからインデックスを生成する必要があるが、検索のバラエティに富んでいる点がメリットとなる。

　サービスの選定に関しては、「ベクトルデータの挿入や更新、削除が頻繁に行なわれるか」「その他のデータといっしょに参照更新を行なうか」の2点が大きなポイント。同期が必要な場合はデータベース、ディレイが生じてもよい場合は検索サービスがオススメだという。最後、西村氏は今回照会したベクトルインデックスをディメンジョン数、検索方法、アルゴリズム、Azure Open AI Serviceとの統合などを星取り表で比較して、セッションを終えた。

進化するAI Search　ナレッジグラフをサポートするMicrosoft GraphRAG

　後半の「RAGにおけるAI Platform & Tools」は松崎剛氏が担当した。まずはAI Challenge DayではおなじみのAzure AI Search。GAしてちょうど1年となるAI Searchはキーワード検索、セマンティック検索、両社を組み合わせたハイブリッド検索をカバーするフルマネージドの検索サービス。ベクトル検索に特化した高度な機能を有しており、テキストと画像を同じ空間にマップするようなマルチモーダル対応や、複数のベクトルに対するマルチベクトル検索、バイナリベクトル対応も可能となる。

日本マイクロソフト パートナー事業本部 クラウドソリューションアーキテクト 松崎剛氏

　このようにもともとベクトル検索に強かったAI Searchだが、この数ヶ月でさらなる進化を遂げているという。ハイブリッド検索におけるベクトル検索、非ベクトルの重み付け調整、低スコア排除のためのスレッシュホールド設定、ベクトルの量子化（圧縮）、トランケーション、オーバーサンプリング＆リランキング、ターゲットされたベクトルフィルター、サブスコアの確認、トークンによるテキスト分割スキルなど。「要はかなりプロっぽくなっています。まずはフルで精度を上げてみて、その精度を保ちつつ、チューニングによってパフォーマンスを上げることができる」と松崎氏は語る。

　残りは研究分野の紹介で、松崎氏はナレッジグラフによるRAGの実装について基礎知識を解説する。ナレッジグラフはさまざまなナレッジ（知識）を体系的に連携させたグラフ化ネットワークで、AIの基盤技術として用いられている。

　たとえば、「Microsoftの本社はワシントン州にあり、同州に住むビル・ゲイツは創業者の一人です」というトピックは、「マイクロソフト」「ワシントン州」「ビル・ゲイツ」というそれぞれのエンティティの関係性をグラフにできる。「ビル・ゲイツ」は「ワシントン州」に住んでいるという関係性、「ビル・ゲイツ」は「マイクロソフト」の創業者の一人といった具合だ。これに「マウントレーニアはワシントン州にあります」というトピックを追加する場合は、ワシントン州にあることをひも付ければグラフをさらに育てることができる。

　一方で、ワシントン州について聞きたければ、属性情報を含んだワシントン州のエンティティのみをコンテキストとして持ち込めばよい。「ドキュメントを横断すると、一通り見なければならないが、グラフにしておけば要素がまとまっている」とのこと。例に出されたハリーポッターの人物関係を表したナレッジグラフは登場人物だけでもかなり巨大になるが、ストーリー全体をグラフ化するとさらに巨大化する。

　こうしたナレッジグラフはLLMで作成でき、LangChainでもそれをサポートするツールが用意されている。そして、マイクロソフトからはOSSとして「Microsoft GraphRAG」を公開している。Microsoft GraphRAGではLeiden Clusteringという手法を用いて、エンティティの集合であるグループ同士間でのエッジがなるべく少なくなるように分割を行なう（関連ページ：Microsoft GraphRAG でこれまでの RAG にはできなかった質問に回答させる）。ここでmax_cluster_sizeというパラメーターを調整すると、大きすぎるグループはさらに分割され、すべてのグループは指定された大きさ以下になるまで分割される。分割しすぎると意味を持たなくなる（モジュラリティの欠如）こともあるので、ここはLLMによって自動調整されるという。

　ここで分割されたグループは「コミュニティ」と呼ぶ。それぞれのコミュニティでフルレポートのほかに内容を要約したレポートが作成され、グローバル検索でもこれらを参照するので、効率的に回答を引き出せる。さらにこの10月にはローカル検索をより柔軟に行なうためのDRIFT Searchの手法がサポートされた。ここではコミュニティレポートを元にまず初期回答を生成し、その結果についてローカル検索を行なってフォローアップを実行し、回答をさらに洗練させる。その上で質問と回答の階層を作成し、元の質問に対するリレバンシー（親和性）を評価してくれるという。