AI時代のデータ探索：ベクトル検索の手法とデータ連携方法を解説

べクトル／ベクトルデータベースとは

ベクトル検索を理解するためには、まずベクトルとは何なのか、ベクトルを格納するベクトルデータベースが従来のデータベースとどう異なるのかを理解することが重要です。

• ▼ベクトルデータベースについてもっと詳しく知りたい
  ⇒ ベクトルデータベース（Vector database）｜用語集

ベクトルとは

ベクトルとは、テキスト、画像、音声、動画といった非構造化データを数値表現に変換したものです。

例えば、赤・緑・青の光の強度を示すRGBカラーモデルは、広義の意味で三次元ベクトル表現と見なすことができます。RGBカラーモデルでは、赤(R)・緑(G)・青(B)それぞれについて0から255の値を取り、そのバランスで色を表現しています。

例えば、色名「赤」はベクトル（230,0,51）で表現され、色名「青」は（0,149,217）で表現することができます。赤はRの値が大きく、青はBの値が大きいのが特徴です。逆に、赤と青それぞれの中間に近い値である（136,72,152）は色名「紫」を意味します。このように、ベクトルで表現される数値には意味があります。

また、ベクトル表現の一つの特徴として、異なる単語でも近しい意味であれば数値が近くなるという特性があります。RGBカラーモデルを例に取れば、色名「水色」と色名「空色」は言葉としては全く異なりますが、近しい色をイメージすることができます。実際に、RGBで表現すると水色は（188,226,232）、空色は（160,216,239）と近しい値であることが分かります。

実際のベクトル表現においては、数百・数千の次元で表現され、表現上全く異なる単語が意味の近さに基づいて配置されます。このベクトル表現に置き換えることを「埋め込み（Embedding）」と言います。

ベクトルデータベースとは

ベクトルデータベースは、ベクトル表現に置き換えられたデータを保存し、検索のための索引（インデックス）を作成し、検索のためのクエリを実行するために特化して設計されたデータベースです。

従来のデータベースと言えば、取引情報や顧客情報などの行と列からなるスキーマを持つリレーショナルデータベースや、SNSの投稿など柔軟なスキーマで大量の非構造化データ・半構造化データを扱えるNoSQLなどが挙げられます。これら従来のデータベースでは、事前に定義された構造（スキーマ、キー等）に対するクエリは処理できるものの、意味的なパターンや類似性に基づいた検索には向いていません。

ベクトルデータベースでは、データをベクトルという数値表現に置き換えることによって、数値的な近接性の計算に基づいてクエリを処理することが可能です。すなわち、データ毎に語彙や表現が異なっていたとしても、意味として近しいものであれば検索結果として導くことが可能になります。

生成AIの登場により、人間が日常的に使う言葉である「自然言語」がデータ活用において当たり前に用いられるようになりました。自然言語は話者によって使用する語彙や表現が異なります。すなわち、表記揺れが常に起こるのが特徴です。この「揺れ」に柔軟に対応できる検索の仕組みがベクトルデータベースであると言えます。

TOPへ

検索手法

さて、ベクトル及びベクトルデータベースという概念について紹介しましたが、そもそも検索手法にはどのようなものがあるのでしょうか。従来のキーワード検索から、その課題を克服するセマンティック検索、両者の特性を兼ねるハイブリッド検索について紹介します。

キーワード検索

キーワード検索は、ユーザーが入力する単語やフレーズに対して部分一致または完全一致、あるいはある単語の出現頻度に応じて検索を行います。この検索手法は、検索対象となるデータの表現方法が厳密に定められていたり、検索すべきキーワードが既知である場合に有効です。

キーワード検索の最も顕著な課題の一つが、表記揺れや同義語に対する検索性です。例えば、ユーザーが「テレワーク」と検索した場合、キーワード検索では「在宅勤務」や「リモートワーク」といった単語を含む結果を見逃してしまう可能性があります。同様に「マニュアル」と検索した際、同義語である「手順書」や「操作ガイド」といった同義語を認識することができません。

また、キーワード検索はユーザーの文脈を考慮しないため、曖昧な検索に対して対応することが困難です。例えば「評価制度変更」のように複数の意図が含まれる複雑なクエリでは、ユーザーが探している「新しい評価基準」や「評価面談の進め方」といった具体的な情報が見つからず、期待と異なる結果が返される可能性があります。

ユーザーの質問と社内ドキュメントのような説明文とでは文体が異なることが多く、キーワード検索では適切な結果が得られない可能性があります。

セマンティック検索

セマンティック検索（いわゆる「ベクトル検索」）は、従来のキーワード検索とは対照的に、ユーザーの文脈や単語の意味を理解し、その類似性に基づいて情報を検索する手法です。このアプローチでは、検索対象の単語の背後にある意味や意図を捉えるため、キーワードが完全に一致していなくとも、文脈に関連した結果を提供することが可能になります。

セマンティック検索は、テキストのみならず、画像や音声、動画といった非構造化データも統一的に扱うことが可能です。そのため、レコメンデーションや問い合わせ対応、マルチモーダル検索といった幅広いAIアプリケーションで活用することが可能です。

こうしたセマンティック検索の技術は、近年では生成AIとの組み合わせによって新たな可能性を広げています。その代表的なアプローチが RAG（Retrieval-Augmented Generation） です。

RAGは、検索システムとLLM（生成AI）を組み合わせ、外部のデータソースに基づいて回答を動的に生成する仕組みです。LLMが単独で生成できる回答は、LLMが学習データを通じて得た知識に限定されるため、時間の経過とともに知識は陳腐化するという課題があります。また、LLMはハルシネーションと呼ばれる、事実に基づかない誤情報を提示することがあります。

RAGは、外部の最新かつ信頼できる情報源に「グラウンディング（Grounding）」することで、地に足のついた回答をLLMに行わせることが可能になります。この検索機能の中核を担うのが、ベクトルデータベースによるセマンティック検索です。

ハイブリッド検索

セマンティック検索は文脈の理解に優れる一方で、特定の固有名詞やキーワードの正確な一致には弱点があります。この限界を克服し、検索品質を高めるために注目を集めているのがハイブリッド検索です。

ハイブリッド検索は、キーワード検索とセマンティック検索を組み合わせることによって、完全性と関連性のバランスを補完します。キーワード検索によって特定の単語への厳密な一致による検索結果を、セマンティック検索によって完全一致を必要としない意味的な類似性の一致による検索結果を取得します。

これら両者の検索結果を統合してランク付けを行うことより、意味的なパターンや類似性に紐づく関連性を考慮しながらも、キーワードによる一致によって検索品質を高めることができます。

TOPへ

ベクトル検索のプロセス

ベクトル検索を含む検索手法（セマンティック検索・ハイブリッド検索など）は単一のデータ処理ではなく、複数のステップによって成立する一連のパイプラインです。検索精度を高めるためには、パイプライン全体の効率と精度を見極めることが重要です。

ベクトル化（Embedding）

最初のステップは、検索対象となるあらゆる非構造化データを数値ベクトルに変換することです。このプロセスは、テキスト、画像、音声など、データの種類に応じて、適切な言語モデルやマルチモーダルモデルを使用して実行されます。

• ▼ベクトル化（Embedding）についてもっと詳しく知りたい
  ⇒ ベクトル化 / エンベディング（Embedding）｜用語集

インデックス作成（Indexing）

次に、生成された大量のベクトルは、効率的な検索のために、特殊なデータ構造であるインデックスに格納されます。インデックスは、類似したベクトルを素早く検索できるように最適化されています。

クエリ実行（Query Execution）

ユーザーが検索を行う際は、ユーザーによる入力である検索クエリも同様にベクトル化されます。このベクトル化されたクエリが、データベース内のインデックス付きベクトルと比較され、検索結果として返却されます。この比較プロセスは、キーワードの完全一致ではなく、ベクトル間の近接性（距離）に基づいて行われます。

リランキング（Reranking）

検索品質を高めるため、ユーザーによる入力とクエリの実行結果の類似性を再評価してランク付けを行うリランキングを行う場合があります。リランキングによって、得られた大量の検索結果を再評価し、LLMに検索結果を上位数件に絞り込んだうえで提供することで、LLMはより近接性の高い情報に基づいて回答を生成することが可能になります。

TOPへ

データソースとの統合

前述のように、非構造化データを類似性に従って検索できるようにするためには、ベクトル化やインデックス化を通してベクトルデータベースにデータを保管する必要があります。しかし、実際に活用したいデータは、ファイルサーバやクラウドストレージ等、本来別の場所で保管されています。最後に、これらのデータソースからベクトルデータベースまでどのようにデータを統合することができるかを紹介します。

データソースからの収集

まずはデータの発生源であるデータソースからデータをどのようにして取り出すことができるかを考えます。非構造化データであれば、一般にファイルサーバやクラウドストレージにデータが格納されているケースが大半です。

ファイルサーバであれば、ファイル連携が可能であるかを検討します。具体的には、FTP/SFTPやHULFTによる動的なデータ連携や、RPAによる自動エクスポートの実装が考えられます。クラウドストレージであれば、利用するサービスにもよりますが、REST APIによる連携が一般的でしょう。

データソースの収集タイミングは、データが持つ業務的な性質によって変わります。例えば、日々更新されて、常に最新のデータが検索結果として表示される必要がある場合、日次でのバッチ処理での収集が必要でしょう。逆に滅多に更新されないか、あるいは情報の鮮度に対して影響が小さいデータは月次や年次での収集でも良いかもしれません。

また、ビジネスにおいて発生する非構造化データの量は膨大であり、日次で更新するとしてもそのデータ処理量も相当です。差分連携の考えを取り入れ、必要な情報だけを収集することも重要です。

ベクトルデータベースへの登録

データソースからデータを収集した後は、ベクトルデータベースに登録（または更新）を行います。ベクトルデータベースへの登録方法は、採用するベクトルデータベースによって様々ですが、直接的に連携するパターンと、間接的に連携するパターンを考えます。

直接的に連携するパターンの場合は、ベクトル化する前の状態で連携する場合と、ベクトル化した後の状態で連携する場合に分かれます。後者の場合は、ベクトルデータベースに登録する前に、埋め込みモデルを用いてデータをベクトルに変換する必要があります。ベクトルデータベースへの連携は、ベクトルデータベースの対応プロトコルに従い、JDBCまたはREST APIによる連携が考えられます。

間接的に連携するパターンの場合は、ベクトルデータベースが対応するオブジェクトストレージにデータを格納することによって同期的または非同期的にベクトルデータベースに取り込むことが可能です。例えば、Microsoft AzureのAzure AI Searchを使用する場合は、Azure Blob Storageにデータを配置することで、Azure AI SearchがAzure Blob Storageのデータを取り込むことができるようになります。

オブジェクトストレージへの連携は、オブジェクトストレージの対応プロトコルに従い、REST APIやSDKによる連携が考えられます。ベクトルデータベースの取り込みスケジュールは、ベクトルデータベース側のスケジュール機能で制御するか、あるいはAPIが提供されている場合は取り込み指示を出して同期的に取り込ませる方法があります。

データパイプラインの構築

データソースからデータを収集しベクトルデータベースに登録していくには、データ連携の仕掛けが重要です。データパイプラインとして上記に挙げたデータ処理を定義することにより、ベクトルデータベースへの登録までに必要な一連の処理を同期的に行い、かつ日々再帰的に一貫した処理を提供することが可能になります。

クラウド型データ連携プラットフォームであるiPaaS（Integration Platform as a Service）は、散在したデータの収集・整備・連携といったAI時代に求められる一連のデータの供給プロセスを統合し、安定的に提供することが可能です。社内に眠るデータ資産を活用し、AIに安定的に供給するための仕掛けとして、データパイプラインは非常に重要な役割を担います。

TOPへ

さいごに

今回は、非構造化データの活用の鍵となるベクトル検索に焦点を当て、検索の基本的な考え方やAI活用のためのベクトルデータベースへのデータ処理・連携プロセスについて紹介しました。

RAGやAIエージェントなど、生成AIの回答精度につながり得る要素は様々であり、ベクトルデータベースや検索手法の選択、検索プロセスにおけるチューニングもまた重要な精度改善の要素です。

同時に、これらAIをビジネスにおいて安定的に活用していく上で避けては通ることができないのがデータソースとの統合です。データパイプラインは、ビジネスにおけるAI活用を継続的かつ安定的に推進する上での重要な基盤となるでしょう。

TOPへ

おすすめコンテンツ

TOPへ