WEBVTT

00:00:00.160 --> 00:00:07.520
想像してみてください。あなたは社内のアプリを使っています。人事ポータルかもしれませんし、顧客サポートのデータベース、あるいは従うべき社内規定が詰まった社内ウィキかもしれません。

00:00:07.660 --> 00:00:12.680
検索バーに質問を入力します。例えば顧客との会食の経費生産はどうすればいいの?といった具合です。

00:00:12.840 --> 00:00:20.280
エンターキーを押すと何が出てくるでしょうか?何も出てきません。あるいはもっと悪いことに、3年前の無関係なPDFがずらりと並び、入力した単語が少し含まれているだけの結果が表示されます。

00:00:20.280 --> 00:00:28.660
検索は私たちが毎日使うものです。しかし、そのほとんどがひどい出来です。ですが、実はそうある必要はないのです。もしアプリがあなたの問いかけを真に理解できたらどうでしょうか?

00:00:28.780 --> 00:00:33.160
Googleのように、完璧な単語を使わなくても正しい答えを見つけてくれる検索ができたらどうでしょう?

00:00:33.420 --> 00:00:40.360
今日はAzure iSearchについて解説します。それが一体何なのか、裏側でどう動いているのか、そしてなぜ現代のアプリの検索エンジンとして選ばれているのかを見ていきます。

00:00:40.360 --> 00:00:48.060
コーヒーを片手に早速始めましょう。なぜ検索は使いにくいのか、検索がなぜ失敗するのかを理解するには、ほとんどのアプリが実際に言っている方法を見る必要があります。

00:00:48.300 --> 00:00:56.860
従来の方法は、キーワード検索や語彙検索と呼ばれます。ボックスにノートPCと入力すると、システムはその単語を正確に含むすべての文書を探し出します。

00:00:57.100 --> 00:01:06.680
その仕組みの多くは、BM25というアルゴリズムを使用しています。複雑ではありませんが、独自の上手さがあります。BM25はいくつかの要素に基づいて結果をランク付けします。

00:01:06.680 --> 00:01:12.660
検索語が文書内にどれだけ頻繁に現れるか、文書の長さ、そしてデータセット全体でその検索語がどれほど珍しいか、といった要素です。

00:01:12.780 --> 00:01:18.100
これらを基に、どの文書が最も関連性が高いかを判定する、非常に洗練された単語カウンターだと考えてください。

00:01:18.260 --> 00:01:24.200
ここで問題が生じます。人間の言語は曖昧だからです。人は文書と同じ単語を使って質問するとは限りません。

00:01:24.400 --> 00:01:28.260
具体例を挙げましょう。ユーザーがサポートポータルにこう入力します。

00:01:28.260 --> 00:01:38.040
ビデオ通話中にノートPCがフリーズするキーワード検索は、ノートPC、フリーズ、ビデオ、通話、といった単語を含む文書を忠実に探します。

00:01:38.220 --> 00:01:42.660
しかし、そのトピックに関する最適な記事のタイトルが、チーム会議中のシステムハングのトラブルシューティングだったらどうでしょう?

00:01:42.860 --> 00:01:48.280
あるいは、ドッキング中のノートPCにおけるCPUスロットリングの管理というタイトルだったら、キーワード検索ではそれらを完全に見逃してしまいます。

00:01:48.460 --> 00:01:49.140
なぜでしょうか?

00:01:49.260 --> 00:01:50.420
言葉が一致しないからです。

00:01:50.580 --> 00:01:51.900
革新的な問題はこれです。

00:01:51.900 --> 00:01:53.620
キーワード検索はスペルを理解します。

00:01:53.760 --> 00:01:56.420
文字のパターンは理解しますが、その意味は理解していないのです。

00:01:56.540 --> 00:01:59.700
結果として表示されるのは、文字は合っていても、中身は間違っていることが多いのです。

00:01:59.840 --> 00:02:03.480
では、単語の一致だけではこれほど多くの欠落が生じるなら、代わりとなる選択肢は何でしょうか?

00:02:03.620 --> 00:02:05.380
新しい手法、ベクトル検索。

00:02:05.580 --> 00:02:08.280
ベクトル検索は、これまでとは全く異なるやり方です。

00:02:08.480 --> 00:02:10.860
正確な単語の一致ではなく、意味で一致させるのです。

00:02:11.020 --> 00:02:13.240
抽象的に聞こえるかもしれませんので、詳しく解説しましょう。

00:02:13.420 --> 00:02:14.940
最もシンプルな定義はこれです。

00:02:15.100 --> 00:02:18.580
ベクトルとは、コンピュータが扱える形式で何かを表した数字のリストにすぎません。

00:02:18.800 --> 00:02:19.520
それだけです。

00:02:19.680 --> 00:02:20.940
ただの数字のリストです。

00:02:21.120 --> 00:02:24.240
エンベディングとは、テキストの意味を捉える特別な種類のベクトルです。

00:02:24.440 --> 00:02:28.440
文や段落、あるいは文書全体を、長い数字のリストへと変換するのです。

00:02:28.440 --> 00:02:31.400
コンピュータは単語そのものは理解しませんが、数字は理解します。

00:02:31.540 --> 00:02:33.100
わかりやすい例え話をしましょう。

00:02:33.260 --> 00:02:35.220
ベクトルを地図上の座標のように考えてみてください。

00:02:35.380 --> 00:02:37.300
地図では、似た場所は近くに配置されます。

00:02:37.460 --> 00:02:40.080
ベクトル空間でも、似た概念は近くに配置されるのです。

00:02:40.240 --> 00:02:43.220
Oのベクトルと、上のベクトルは近い位置にあります。

00:02:43.460 --> 00:02:44.880
関連する概念だからです。

00:02:45.060 --> 00:02:48.360
一方で、Oと、リンゴのベクトルは、遠く離れた位置にあります。

00:02:48.580 --> 00:02:51.620
コンピュータは、Oが人間にとって何を意味するかは知りませんが、

00:02:51.780 --> 00:02:54.920
その座標と他のあらゆる単語や文書の座標との距離を測ることはできます。

00:02:55.100 --> 00:02:57.480
いわば、アイデアのためのGPSのようなものです。

00:02:57.660 --> 00:03:01.020
システムは数字を見るだけで、概念同士がどれだけ離れているかを知ることができます。

00:03:01.020 --> 00:03:04.920
ベクトルを使って検索を行う際、システムはクエリをエンベディングに変換します。

00:03:05.060 --> 00:03:08.400
そして、自分のクエリに最も近いエンベディングを持つ文書を探し出します。

00:03:08.560 --> 00:03:12.340
単なる語彙ではなく、意味を共有する意味的に近いものを見つけ出すのです。

00:03:12.500 --> 00:03:15.680
例えば、ノートPCがフリーズした際のトラブルシューティングを探しているとしましょう。

00:03:15.840 --> 00:03:19.540
キーワード検索では、フリーズやハングアップといった言葉を正確に入力する必要があります。

00:03:19.740 --> 00:03:23.720
しかしベクトル検索なら、コンピュータが何度も固まると入力しても正しい文書が見つかります。

00:03:23.920 --> 00:03:26.120
これこそが、意味を理解する力なのです。

00:03:26.340 --> 00:03:28.120
先ほどの検索例に戻りましょう。

00:03:28.360 --> 00:03:31.140
ユーザーがノートPCが頻繁にフリーズすると入力します。

00:03:31.360 --> 00:03:37.340
ベクトル検索なら、クエリにその単語が含まれていなくても、チーム会議中のシステムハングに関する記事を提示できます。

00:03:37.600 --> 00:03:38.420
なぜでしょうか?

00:03:38.420 --> 00:03:42.900
ベクトル空間において、システムハングとコンピュータのフリーズの意味が非常に近いためです。

00:03:43.020 --> 00:03:45.700
これらの概念は、あの地図上で近くに位置しているのです。

00:03:45.860 --> 00:03:48.960
システムは正確な単語にはこだわらず、あなたの意味を汲み取ります。

00:03:49.120 --> 00:03:50.320
これがブレイクスルーです。

00:03:50.500 --> 00:03:53.140
コンピュータが単なるスペルではなく、意図を理解し始めるのです。

00:03:53.280 --> 00:03:56.000
キーワード検索では完全に見逃してしまうような回答を見つけ出します。

00:03:56.200 --> 00:03:58.180
しかし、ベクトル検索にも弱点はあります。

00:03:58.460 --> 00:04:01.460
どうしても必要な完全一致を見逃してしまうことがあるのです。

00:04:01.460 --> 00:04:09.520
技術者が、X87570のような特定のエラーコードを検索する場合、ベクトル検索ではそのコードを解説した正確なドキュメントではなく、

00:04:09.520 --> 00:04:13.660
ディスクエラーやファイルシステムの破損に関するドキュメントが優先されてしまうことがあります。

00:04:13.900 --> 00:04:16.200
正確さを犠牲にして文脈の理解を優先しているのです。

00:04:16.360 --> 00:04:17.840
つまり、2つの方法があるわけです。

00:04:17.960 --> 00:04:19.680
キーワード検索は正確性に優れています。

00:04:19.880 --> 00:04:22.520
正確な用語、製品ID、契約番号を見つけるのに最適です。

00:04:22.520 --> 00:04:24.400
ベクトル検索は意味の理解に優れています。

00:04:24.540 --> 00:04:27.020
適切な言葉を使わなくても正しい答えを見つけ出してくれます。

00:04:27.240 --> 00:04:28.420
それぞれに盲点があります。

00:04:28.680 --> 00:04:30.440
そこで、ある当然の疑問が浮かびます。

00:04:30.600 --> 00:04:33.180
両方のアプローチを組み合わせて、いいとこ取りをすることはできないでしょうか?

00:04:33.320 --> 00:04:35.000
それがハイブリッド検索というブレイクスルーです。

00:04:35.140 --> 00:04:37.500
ハイブリッド検索こそが、両者の長所を兼ね備えた手法です。

00:04:37.640 --> 00:04:42.140
キーワード検索とベクトル検索を同時に実行し、その結果を1つのランキングリストに統合します。

00:04:42.220 --> 00:04:47.100
どちらか一方を選ぶのではなく、RRF、レシプロカルランクフュージョンと呼ばれる手法を用いています。

00:04:47.260 --> 00:04:48.480
仕組みは以下の通りです。

00:04:48.620 --> 00:04:52.640
RRFは、各ドキュメントがキーワード検索とベクトル検索の結果でそれぞれ何位にランク付けされているかを確認します。

00:04:52.800 --> 00:04:54.560
そして、それらを合わせたスコアを算出します。

00:04:54.740 --> 00:04:56.980
両方で高く評価されたドキュメントは、順位が引き上げられます。

00:04:57.100 --> 00:04:59.500
2人の専門家の意見を聞いて、平均を取るようなものです。

00:04:59.660 --> 00:05:02.440
どちらか一方だけよりも、最終的な回答の信頼性が高まります。

00:05:02.440 --> 00:05:06.400
キーワード検索とベクトル検索では根本的に強みが異なるため、この組み合わせが重要になります。

00:05:06.560 --> 00:05:08.700
キーワード検索は、完全一致に優れています。

00:05:08.920 --> 00:05:12.700
製品ID、契約番号、固有名称、エラーコードなどを探す際に頼りになります。

00:05:12.920 --> 00:05:14.260
正確で予測可能です。

00:05:14.460 --> 00:05:20.500
ベクトル検索は、意味的な類似性に優れており、正確な言葉が含まれていなくても、クエリと意味を共有するドキュメントを見つけ出します。

00:05:20.660 --> 00:05:23.240
これらを合わせることで、互いの盲点を補い合えるのです。

00:05:23.240 --> 00:05:26.520
システムは、単一のクエリで完全一致と概念的な一致の両方を捉えます。

00:05:26.640 --> 00:05:28.000
これこそが真の力です。

00:05:28.160 --> 00:05:30.100
これは単なる理論上の話ではありません。

00:05:30.260 --> 00:05:35.760
エンタープライズ向けのハイブリッド検索に関する調査では、データセットに応じて70から80%の検索精度が得られることが示されています。

00:05:35.940 --> 00:05:39.780
これは、ベクトル検索単体と比較して約15から20ポイント高い数値です。

00:05:39.920 --> 00:05:42.880
この違いは大きく、実際のビジネス成果として現れています。

00:05:43.060 --> 00:05:45.400
会計プラットフォームのゼロ、お礼にあげましょう。

00:05:45.400 --> 00:05:49.540
彼らはコベオという企業を通じて、カスタマーサポートにハイブリッド検索を導入しました。

00:05:49.740 --> 00:05:53.640
導入から3ヶ月以内に、セルフサービスによる解決率が20%向上しました。

00:05:53.800 --> 00:05:57.720
顧客はサポートに連絡することなく、自分で答えを見つける機会が増えたのです。

00:05:57.880 --> 00:06:03.060
同じケーススタディ内の他社では、サポート案件の解決までの時間が最大40%短縮されました。

00:06:03.240 --> 00:06:08.660
つまり、エージェントは正しい情報をより早く見つけ、顧客はより迅速に回答を得られ、サポートコストも削減されたということです。

00:06:08.720 --> 00:06:12.240
これは単なる便利な機能ではなく、利益に直接貢献する測定可能なインパクトなのです。

00:06:12.340 --> 00:06:13.700
ここが重要なポイントです。

00:06:13.700 --> 00:06:18.020
ハイブリッド検索は、単なる便利なアップグレードや機能リストの項目の一つではなく、測定可能なほど優れたものです。

00:06:18.160 --> 00:06:21.280
精度が向上し、再現率が高まり、より良いユーザー成果をもたらします。

00:06:21.440 --> 00:06:26.140
このアプローチの組み合わせこそが、現代のアプリケーションにおいてAzure iSearchを強力なものにしている理由です。

00:06:26.280 --> 00:06:30.600
しかし、この組み合わせによって実現するもう一つの技術があり、現在大きな注目を集めています。

00:06:30.800 --> 00:06:32.460
それが、ラグと呼ばれるものです。

00:06:32.640 --> 00:06:34.240
それでは、ラグについてお話ししましょう。

00:06:34.240 --> 00:06:37.420
ラグは、リトリーバルオーグメンテッドジェネレーション、原作拡張生成の略称です。

00:06:37.580 --> 00:06:39.860
少し難しい言葉ですが、最もシンプルな定義はこうです。

00:06:40.000 --> 00:06:43.860
AIアシスタントが学習に使用されていない情報にアクセスできるようにするフレームワークです。

00:06:44.060 --> 00:06:48.440
GPTのような大規模言語モデルは歴史や科学、プログラミングには詳しいですが、

00:06:48.820 --> 00:06:54.620
あなたの会社の社内文書ポリシー、顧客履歴、あるいはチームが従う特定の業務手順については知りません。

00:06:54.820 --> 00:06:58.640
多くの人は、そうした社内知識をそのままモデルに詰め込めば良いと考えがちです。

00:06:58.800 --> 00:07:00.180
しかし、それではうまくいきません。

00:07:00.320 --> 00:07:02.140
コストがかかりますし、更新も困難だからです。

00:07:02.280 --> 00:07:04.240
ラグはこの問題を懸命な方法で解決します。

00:07:04.480 --> 00:07:09.720
すべてをモデルに詰め込む代わりに、誰かが質問した瞬間にナレッジベースから関連情報を検索するのです。

00:07:09.720 --> 00:07:14.060
ユーザーのクエリを受け取り、社内データを検索して最も関連性の高いドキュメントを見つけ、

00:07:14.340 --> 00:07:16.900
そのコンテキストを元の質問と一緒にLLMに入力します。

00:07:17.060 --> 00:07:19.780
すると、LLMはあなたのデータに基づいた回答を生成します。

00:07:19.940 --> 00:07:21.500
これこそが魔法のような仕組みなのです。

00:07:21.640 --> 00:07:24.900
Azure iSearchは、その方程式における検索の半分を担っています。

00:07:25.080 --> 00:07:28.700
LLMが正確に回答できるよう、適切なドキュメントを見つけ出すエンジンなのです。

00:07:28.860 --> 00:07:33.120
強固な検索レイヤーがなければ、ラグシステムの性能は見つけ出すドキュメントの質に依存してしまいます。

00:07:33.160 --> 00:07:35.500
ここでハイブリッド検索が進化を発揮します。

00:07:35.660 --> 00:07:41.080
ラグのクエリは多くの場合自然言語の質問であり、答えは全く異なる用語が使われたドキュメントの中にあることが多いためです。

00:07:41.240 --> 00:07:44.120
その違いを如実に示すいくつかの数字をご紹介しましょう。

00:07:44.300 --> 00:07:52.700
エンタープライズ検索に関する調査では、ハイブリッドラグフレームワークはキーワード検索のみと比較して、トップ系の検索精度が18倍から25倍に向上しました。

00:07:52.760 --> 00:07:56.140
ワークフローのタスク完了精度は21倍に向上しました。

00:07:56.140 --> 00:08:02.960
つまり、ハイブリッド検索を使用したラグシステムでサポートされている場合、ユーザーが複雑なタスクを成功させる可能性が飛躍的に高まったということです。

00:08:03.100 --> 00:08:10.960
全体として、適切に実装されたラグシステムは検索精度を平均85%向上させることができ、一部の専門領域では99%に近い精度に達します。

00:08:11.140 --> 00:08:19.040
また、LLMは独自の推測ではなく検索されたコンテキストに基づいて回答を生成するため、ラグシステムではハルシネーション、誤情報の発生が約40%減少しました。

00:08:19.040 --> 00:08:23.360
これこそが、Azure iSearchがAIエージェントやコパイロットを構築する上で不可欠である理由です。

00:08:23.500 --> 00:08:28.600
それは、ビジネスの現場においてLLMを信頼できるものにする、根拠に基づいた事実検索を提供するからです。

00:08:28.780 --> 00:08:35.300
正確に質問に答え、情報源を引用する必要があるアシスタントを構築する場合、ハイブリッド検索とラグを組み合わせたアーキテクチャが最適です。

00:08:35.440 --> 00:08:38.360
つまり、ハイブリッド検索とラグは強力な組み合わせなのです。

00:08:38.520 --> 00:08:41.020
しかし、これは実際にはどのようなものなのでしょうか。

00:08:41.140 --> 00:08:42.600
現実世界への影響です。

00:08:42.780 --> 00:08:44.900
では、実際にどこで活用されているのでしょうか。

00:08:45.040 --> 00:08:46.360
いくつか例を挙げてみましょう。

00:08:46.560 --> 00:08:48.560
eコマースはおそらく最も身近な例です。

00:08:48.680 --> 00:08:51.640
顧客が検索バーに快適なランニングシューズと入力したとします。

00:08:51.880 --> 00:08:56.440
製品リストには、マーケティングチームが選んだクッション性のある運動靴と記載されているかもしれません。

00:08:56.600 --> 00:08:59.440
キーワード検索だけでは、この一致を見逃してしまいます。

00:08:59.440 --> 00:09:05.120
Azure iSearchなら、システムが文脈から快適とクッション性がほぼ同じ意味であることを理解します。

00:09:05.280 --> 00:09:08.100
言葉が一致しなくても、正しい製品を提示できるのです。

00:09:08.260 --> 00:09:11.820
これによって、顧客は不満を感じてサイトを離れることなく、欲しいものを見つけることができます。

00:09:11.980 --> 00:09:13.740
カスタマーサポートポータルでも同様です。

00:09:13.900 --> 00:09:17.500
顧客がサブスクリプションを解約するには?と入力したと想像してください。

00:09:17.660 --> 00:09:21.400
関連するポリシーには、サービス利用契約の終了というタイトルがついているかもしれません。

00:09:21.400 --> 00:09:26.000
ハイブリッド検索は、法律用語のキーワード一致でその文章を見つけるだけでなく、

00:09:26.440 --> 00:09:31.020
セマンティックな類似性によって、プランの早期終了に関するFAQも提示します。

00:09:31.200 --> 00:09:35.860
顧客は5つの異なる記事を探し回ることなく、包括的な回答を得ることができます。

00:09:36.060 --> 00:09:38.080
法務文書の検索もその一つです。

00:09:38.260 --> 00:09:42.700
弁護士は、正確な条項番号やセクションの参照に基づいて契約書を検索する必要があります。

00:09:42.900 --> 00:09:44.800
それは純粋なキーワード検索の領域ですが、

00:09:45.040 --> 00:09:48.660
同時に、表現が異なっていても異なる契約書間で類似した内容を見つける必要もあります。

00:09:48.660 --> 00:09:52.120
ハイブリッド検索はこれを単一のクエリで処理でき、規制の厳しい業界では、

00:09:52.460 --> 00:09:56.080
なぜその検索結果が表示されたのかを正確に追跡できることがコンプライアンス紙不可欠です。

00:09:56.260 --> 00:09:58.520
社内ナレッジベースも同様のメリットがあります。

00:09:58.780 --> 00:10:02.380
従業員が休暇規定を検索すると、公式の人事文書だけでなく、

00:10:02.760 --> 00:10:05.000
ホームチームからの繰り越し日数に関するメールや、

00:10:05.340 --> 00:10:08.440
社内イントラネットに投稿された最近の更新情報も表示されます。

00:10:08.600 --> 00:10:12.360
検索機能が、これらすべてが同じ質問に関連していることを理解しているのです。

00:10:12.560 --> 00:10:15.640
製造業はあまり目立ちませんが、強力な活用例です。

00:10:15.820 --> 00:10:19.500
技術者が検索インターフェースに、モーター加熱の修理と入力します。

00:10:19.740 --> 00:10:22.360
システムは機器マニュアルのトラブルシューティングセクションと、

00:10:22.720 --> 00:10:25.220
関連部品を示すスキャンされた図面を返します。

00:10:25.460 --> 00:10:30.000
図面が画像であっても、Azure iSearchはテキストコンテンツを抽出してインデックス化できるため、

00:10:30.300 --> 00:10:31.500
検索結果に表示されます。

00:10:31.500 --> 00:10:35.060
これらすべての例に共通するのは、非構造化データであるという点です。

00:10:35.200 --> 00:10:38.540
PDF、ワード文書メールのサポートチケット、スキャンされた画像などです。

00:10:38.720 --> 00:10:42.660
従来のデータベースクエリやキーワード検索は、このようなデータのために設計されたものではありませんでした。

00:10:42.820 --> 00:10:45.020
Azure iSearchはこの世界のために構築されており、

00:10:45.260 --> 00:10:48.960
詳しく調べるほど、ハイブリッド検索が単なる便利な機能ではないことが明確になります。

00:10:49.140 --> 00:10:52.080
これは現代のアプリケーション構築における基盤となる要素です。

00:10:52.280 --> 00:10:54.120
どのように各要素が組み合わさるのか。

00:10:54.120 --> 00:10:56.760
では、内部では実際にどのように動作しているのでしょうか。

00:10:56.760 --> 00:11:01.760
Azure iSearchには、データソース、インデクサー、検索インデックスという3つの主要な構成要素があります。

00:11:01.960 --> 00:11:04.520
データソースとは、情報が格納されている場所です。

00:11:04.700 --> 00:11:09.380
BlobストレージやAzure SQLデータベース、Cosmos DB、あるいはSharePointなどが挙げられます。

00:11:09.520 --> 00:11:11.860
検索可能にする必要があるせいのデータです。

00:11:12.080 --> 00:11:14.800
整理されるのを待っている書類の山だと考えてください。

00:11:14.800 --> 00:11:23.060
インデクサーは、データソースからデータを読み取り、コンテンツを抽出し、設定したAIエンリッチメントを適用して、検索インデックスを構築するパイプラインです。

00:11:23.240 --> 00:11:24.980
わかりやすい例えを紹介します。

00:11:25.160 --> 00:11:28.460
図書館員が本でいっぱいの倉庫に入る様子を想像してください。

00:11:28.680 --> 00:11:34.240
すべての本を読み、詳細なメモを取り、重要なテーマや実態を特定し、すべてをカードカタログに整理します。

00:11:34.440 --> 00:11:37.020
その読み込みとメモ取りの作業がインデックス作成プロセスです。

00:11:37.160 --> 00:11:39.420
検索インデックスが、そのカードカタログに当たります。

00:11:39.600 --> 00:11:40.900
本そのものではありません。

00:11:41.080 --> 00:11:45.640
必要な情報をミリ秒単位で見つけ出せるように最適化された構造化システムなのです。

00:11:45.800 --> 00:11:49.960
クエリを入力したとき、システムは元のドキュメントに戻ってスキャンすることはありません。

00:11:50.140 --> 00:11:54.100
代わりに、すべてがどこにあるかをすでに把握しているインデックスを参照します。

00:11:54.300 --> 00:11:56.980
この事前の整理を、点置インデックスと呼びます。

00:11:56.980 --> 00:12:01.660
ドキュメントにどんな単語が含まれているかを保存するのではなく、単語ごとにそれが含まれるドキュメントのリストを保存します。

00:12:07.020 --> 00:12:09.220
その結果、劇的な速度向上が実現します。

00:12:09.400 --> 00:12:14.400
データ量が増えるほど時間がかかる全ドキュメントのスキャンではなく、正しい場所に直接アクセスできます。

00:12:14.680 --> 00:12:20.140
数百万ものドキュメントがある場合、それは検索に数秒かかるか、数ミリ秒で済むかという決定的な違いとなります。

00:12:20.300 --> 00:12:25.760
これでAzure iSearchとは何か、主要コンポーネントがどう組み合わさるのか、そしてなぜハイブリッド検索が革新的なのかが理解できたはずです。

00:12:25.880 --> 00:12:28.740
最後に、これで実際に何ができるのかをいくつか見ていきましょう。

00:12:28.920 --> 00:12:31.000
まず、自分のデータを理解することです。

00:12:31.000 --> 00:12:38.540
SQLの製品テーブルやデータベースの顧客レコードなど、すでに構造化され、行と列が整理されたデータであれば、SQLで直接クエリを実行できます。

00:12:38.720 --> 00:12:41.560
Azure iSearchは非構造化テキストのために構築されています。

00:12:41.720 --> 00:12:44.780
PDF、メール、ワードドキュメント、サポートチケットなどが対象です。

00:12:44.960 --> 00:12:46.900
そこにこそ、真の価値があるのです。

00:12:47.060 --> 00:12:53.780
次に、ラグアプリケーションやAIアシスタントを構築するなら、ハイブリッド検索を備えたAzure iSearchが最適な検索エンジンとなります。

00:12:54.000 --> 00:12:58.320
正確性のためのキーワード一致と、文脈を理解するためのセマンティック検索の両方を提供します。

00:12:58.520 --> 00:13:03.080
その組み合わせにより、どちらか一方のアプローチよりも信頼性が高く、出典も示せる回答が得られます。

00:13:03.240 --> 00:13:05.620
3つ目は、設定を複雑にしすぎないことです。

00:13:05.780 --> 00:13:07.880
Azureポータルには、データインポートウィザードがあります。

00:13:08.100 --> 00:13:11.920
ブログストレージを接続し、いくつかの設定を行うだけで、インデクサーが最初のインデックスを作成してくれます。

00:13:11.920 --> 00:13:14.160
1時間もかからずに最初の検索を実行できるでしょう。

00:13:14.160 --> 00:13:16.540
以上が、Azure iSearchのわかりやすい解説です。

00:13:16.660 --> 00:13:20.540
乱雑で構造化されていない情報を、検索可能でAIが活用できる知識へと変えてくれます。

00:13:20.700 --> 00:13:21.640
ご視聴ありがとうございました。

00:13:22.040 --> 00:13:23.060
チャンネル登録をお願いします。

00:13:23.380 --> 00:13:24.560
また次回の動画でお会いしましょう。