いまだから「検索」を語ろう！ - SharePoint FAST Search から Microsoft Search セマンティック インデックスまで - 2023/12/12 第 8 回 Japan M365 Dev User Group 勉強会 篠原 敬志 (@karamem0)

自己紹介 篠原 敬志 (Takashi Shinohara) アバナード株式会社 グループ マネージャー Power Platform ソリューション アーキテクト & スクラム マスター Microsoft MVP for M365 (M365 Development) FY23 Microsoft Top Partner Engineer Award (Biz Apps) Japan M365 Dev User Group 運営

いまなぜ「検索」が求められるのか

生成 AI 時代における検索の意義 GPT に代表される大規模言語モデル (LLM) はインターネットの情報を学習させたもの ユーザーのデータを大規模言語モデルに学習させることはできない ユーザーのデータを理解させるための方法としてグラウンディング (Grounding) がある ナレッジベースを外部化して生成 AI に回答させる方法を RAG (Retrieval Augmented Generation) と呼ぶ

RAG (Retrieval Augmented Generation) User Application AI Search Storage Account OpenAI Service Response Search Chat Completion Crawl Request

RAG における検索の重要性 検索精度を上げることが最重要課題 大規模言語モデルがいくら賢くても元となるデータが正しくないと意味をなさない

そもそも「検索」とは何か？

単純な検索 (SQL LIKE 文) の流れ AI に関する情報が知りたい… SELECT * FROM documents WHERE content LIKE '%AI%' id content 2 生成 AI の活用方法教えます！… 5 Airbnb を使った宿泊施設の予約方法… 7 ハイチ共和国 (Haiti) はカリブ海…

単純な検索 (SQL LIKE 文) の問題点 パフォーマンス インデックスが使用されない フルスキャンとなりとてつもなく時間がか かる 負荷 フルスキャンであればサーバーも高負荷 となりほかのクエリにも影響が出る 最悪の場合はシステムが止まる 精度 条件一致したものをすべて返すのでど れが求める情報かがわからない 全然関係のない内容でもキーワードさ え入ってれば引っかかってしまう 検索としては使えない

No content

フルテキスト検索 (全文検索) パフォーマンス 負荷 精度 検索データベース もとのデータベースとは別に検索に特化 したデータベースを作成する 定期または即時のタイミングでデータを 同期 (クロール) する 検索エンジン テキストをそのまま扱うのではなく事前 に分割して検索しやすくする 形態素解析や N-gram など スコアリング 検索キーワードが出現する頻度など関 連性の高いテキストが優先的に検索 結果として出てくるようにする

フルテキスト検索: 形態素解析 ドキュメントを単語で分割してインデックス化する手法 言語ごとに解析方法が異なる (日本語の場合は MeCab など) メロスは激怒した。 単語 動詞 メロス 名詞 は 助詞 激怒 名詞 し 動詞 た 助動詞 。 記号

フルテキスト検索: N-gram ドキュメントを単語ではなく文字で分割する手法 N の値によってユニグラム (1 文字)、バイグラム (2 文字)、トリグラム (3 文字) など メロスは激怒した。 バイグラム メロ ロス スは は激 激怒 怒し した た。

フルテキスト検索の弱点 形態素解析の場合 対象の言語を指定する必要がある 言語が一致しない場合に精度が著しく劣化する N-gram の場合 単語中に別の単語が含まれるときに誤検知が発生する 「東京都」をバイグラムすると「京都」に引っかかる

フルテキスト検索: スコアリング 検索キーワードに対して正しく検索できるだけでは駄目 検索キーワードに対して関連度の高い内容を上位に表示する必要がある 単語の出現頻度や特徴量などからスコアを算出する

SharePoint における「検索」

SharePoint における検索の歴史 MOSS 2007 • Microsoft Search Server (MSS) を使 用したエンタープライ ズ検索 SharePoint 2010 • Microsoft FAST Search Server for SharePoint (FS4SP) の導入 • 現在に至るまでの SharePoint 検索の 基礎 SharePoint 2013 • FAST Search が SharePoint の標準 機能に SharePoint Online • SharePoint Online からオンプレミスの SharePoint を検 索 (クラウド ハイブ リッド検索) できるよ うに Microsoft Search • Microsoft 365 全 体の検索サービスに • 外部データを検索す ることも可能に (Microsoft Graph コネクタ)

SharePoint 検索: 基本的な機能 ドキュメント、リスト、ユーザー プロファイル、および外部データの検索 列レベルの詳細な制御 フルテキスト検索およびクエリ (KQL または FQL) を使ったフィルター 検索結果のカスタマイズ

SharePoint 検索: クロール フル クロール 対象のデータソースをすべてクロールする 時間がかかる & 負荷がかかるので夜間や土日にスケジュールすることが多い 増分クロール フル クロールの間の差分を更新するクロール (既定は 4 時間) 継続的クロール SharePoint 2013 から追加された機能 増分クロールよりも短い間隔 (既定は 15 分) でクロールする セキュリティ クロール インデックスの ACL を更新するクロール (増分クロール時に実施)

SharePoint 検索: 管理プロパティ リストのすべての列は自動的にクロールされたプロパティとして管理される 検索対象にするにはクロールされたプロパティと管理プロパティをマッピングする 特徴 説明 検索可能 プロパティのフルテキスト検索を可能にする クエリ可能 プロパティのクエリ検索 (KQL または FQL) を可能にする 取得可能 プロパティの検索結果としての表示を可能にする 絞り込み可能 プロパティの Web パーツからの絞り込みを可能にする 並べ替え可能 プロパティの並べ替えを可能にする

SharePoint 検索: 未使用の管理プロパティ 種類 複数 クエリ 検索 取得 絞り込み 並べ替え 名前の範囲 日付 X Date00 ～ Date09 X X X X X RefinableDate00 ～ RefinableDate19 X X X X RefinableDateInvariant00 ～ RefinableDateInvariant01 X X X X RefinableDateSingle00 ～ RefinableDateSingle04 10 進数 X Decimal00 ～ Decimal09 X X X X X RefinableDecimal00 ～ RefinableDecimal09 倍精度浮動小数点数 X Double00 ～ Double09 X X X X X RefinableDouble00 ～ RefinableDouble09 整数 X Int00 ～ Int49 X X X X X RefinableInt00 ～ RefinableInt49 文字列 X X X X X RefinableString00 ～ RefinableString199 X X X X X RefinableStringFirst00 ～ RefinableStringFirst39 X X X X X RefinableStringLn00 ～ RefinableStringLn09 X X X X RefinableStringWbOff00 ～ RefinableStringWbOff49 X X X X X RefinableStringWbOffFirst00 ～ RefinableStringWbOffFirst49

SharePoint 検索: KQL KQL = キーワード クエリ 言語 構文 返される値 author:"John Smith" John Smith によって作成されたコンテンツ項目を返します filetype:docx ファイルの種類が Microsoft Word (docx) であるコンテンツ項目を返します filename:budget.xlsx budget.xlsx というファイル名を持つコンテンツ項目を返します

SharePoint 検索: FQL FQL = FAST クエリ言語 構文 返される値 body:string("hello world", mode="and") 本文に hello かつ world が含まれるコンテンツ項目を返します

SharePoint 検索: 言語設定 クロール時にはドキュメントの内容から自動的に言語を判定して形態素解析が行われる ドキュメントの内容によっては誤判定が行われるため検索に引っかからないということも 検索するときのユーザーのプロファイルやブラウザーの言語設定にも依存する

SharePoint 検索から Microsoft Search への進化 Microsoft 365 のあらゆるものを検索 ドキュメント、メール、チャット、ニュース、ビデオの検索 個人に最適化された検索 Microsoft Graph の分析情報を使用して関連性の高い情報を表示 Microsoft Bing との統合 Microsoft Bing からの社内情報の検索

AI 時代に求められる次世代の「検索」

フルテキスト検索の限界 検索インデックス 検索キーワード

セマンティック検索 検索したい内容の意味を理解して関連性の高い情報を返す仕組み 検索したいキーワードが含まれていなくても検索できる 引っ越しするときの手続きが 知りたいんだけど… 引っ越し…つまり転居するのですね！ お探しの情報はこちらです！

ベクトル検索 セマンティック検索の手法のひとつ ドキュメントを多次元のベクトルに数値化することで類似度を算出する ユークリッド距離、ドット積、コサイン類似度など ※コサイン類似度の場合 類似度=1 似ている 0° 類似度=0 どちらでもない 90° 類似度=-1 似ていない 180°

ハイブリッド検索 フルテキスト検索とセマンティック検索を組み合わせてより最適な回答を得る それぞれのスコアは異なるアルゴリズムのため RRF (Reciprocal Rank Fusion) などを使って再 計算する

セマンティック インデックス作成のプロセス データソース テキスト抽出 テキスト分割 ベクトル化 インデックス

テキスト抽出 Office ファイル (Word、PowerPoint、Excel)、PDF ファイルをテキスト データに変換する Python の場合は比較的簡単、C# の場合は有償ライブラリまたは頑張る 不要な文字の削除などのクリーンアップも合わせて実施する

テキスト分割 (チャンク) OpenAI が扱えるテキスト量 (トークン数) には限界がある ページ、段落、文字数、トークン数などで分割する (＝Chunk、チャンク) コンテキストが分断されるため検索精度は落ちる可能性がある

ベクトル化 分割したテキストデータからベクトルを算出する OpenAI Embeddings (text-ada-embeddings-002) の場合 最大トークン長: 8K ベクトル サイズ: 1536

セマンティック検索 on Azure

Azure におけるセマンティック検索の選択肢 Azure AI Search Azure Database for PostgreSQL Azure Cosmos DB for MongoDB vCore

Azure AI Search (Azure Cognitive Search) ノーコードで検索機能を構築できる (インデックス、インデクサ、スキル セット) セマンティック ランカーによるフルテキスト検索の精度向上 ハイブリッド検索のサポート API 経由でのアクセス (データベースにはアクセスできない) プラン (SKU) の変更ができない

Azure Database for PostgreSQL 拡張機能の pgvector を有効にすることでベクトル検索が可能に ハイブリッド検索もできるが、日本語がいまいち (pgroonga を有効にできない) 低レイヤーなのでプログラミングは必須

Azure Cosmos DB for MongoDB vCore Microsoft Ignite 2023 で一般提供開始 似たような名前の Azure Cosmos DB for MongoDB RU ではベクトル検索はできない 低レイヤーなのでプログラミングは必須

Copilot for Microsoft 365 とセマンティック検索

No content

Semantic Index for Copilot Copilot for Microsoft 365 を持つ組織向けに Microsoft Search でセマンティック インデックス が作成される見込み

まとめ

まとめ 検索するのに知恵と工夫が必要な 世界から すべての人が自然に検索でき、欲しい情報が見つかる 世界へ

ご清聴ありがとうございました 質問はありますか？