ChatGPTをはじめとする言語系の生成AIについて、RAG（Retrieval-Augmented Generation：検索拡張生成）で利用することは、すでに一般的になっています。
ただ、RAGを何で実現するかについては、実利用における有効な方法が定まっていないのが実情と思います。
（極論では、RAGと言いつつ、利用token数が上がったモデルを使って、ドキュメントの全データを送っている、という製品やPoCも見受けられますね。。。）
このRAGを実現する機能について、テクノロジー系の情報では、ベクトル型検索、その代表としてAzure AI Search（旧：Cognitive Search）を利用すると良いという記事が多く見受けられます。Azure AI SearchはCognitive Searchからリニューアルされて、まだ若い機能ではありますが、優秀な検索技術だと思います。
ただ、技術という視点ではなく、技術を活かした実利用という視点においては、必ずしもベクトル型検索が良いとは思えない部分もあり、ランカー型検索の方が良い部分があります。
そこで、ランカー型であるIBM Watson Discoveryが企業や行政・自治体のRAG型生成AIの実利用においてベクトル型検索より優れていると考える点をシェアしていきたいと思います。
なお、この記事は2024年9月30日に開催された『IBM TechXchange:Watson事例共有会』での私の発表内容を元にしています。
■この記事で参考となること
- ベクトル型検索とランカー型検索（Watson Discovery）の実利用での違い
- Watson DiscoveryのRAGでの優位
■前提：私について
西原中也（株式会社アイアクト）
コードを書かないCTOをとしてAIサービスの提供をしています。
テクノロジーに知見のあるコンサルタントと思っていただければ。
2016年3月に、生まれたての日本語版Watsonを利用した会話ロボットを製造し、九州のテーマパークに納めました（活躍させました）。
NLC、Dialog、Retrieve & Rank、Assistant、Discovery、Watson Explorer：ここまで実利用
watsonx.ai：研究中
■前提：Watson Discoveryについて
本記事では、分析などを扱わず、自然言語検索部分だけを指しています。
また、Watson Discoveryをランカー型検索としています。
Watson Discoveryを使った支援例と製品の構成
実利用でのWatson Discoveryの優位性を理解していただくために、私たちの支援例や製品の構成を先にお伝えします。
以下が、私たちの製品Cogmo Enterprise 生成AIの画面です。検索部分にWatson Discovery、要約部分にChatGPTを利用しています。ChatGPTのモデルはお客様のドキュメント内容によって変えています。
- 知りたいことを質問・検索する
- Watson Discoveryによる検索結果が出てきます
- 検索結果をリアルタイムでAzure OpenAI APIに引き渡し結果を受け取り、回答が表示されます
この画面や検索窓はWebサイトやイントラサイトなどに埋め込んで使うことができます。JavaScriptベースなのでWebサーバなどに新しい実行環境は不要です。
チャット型でないところがCogmoのサービスの特徴です。生成された回答だけではなく、AI検索結果として情報を出すことでより情報を探しやすくし、かつ、ヒトによる判断の根拠データを多く与えることで、生成AIによる回答の鵜呑みを防止しています。希望あれば、検索型画面に加えてチャット型画面（FAQ管理不要の生成AI利用のチャットボット）も提供しています。
検索対象のドキュメントは、オリジナルのクローラーでWebサイトやイントラサイト、SharePoint、Boxなどのクラウドドライブにアクセスして、必要な処理をしてWatson Discoveryに格納しています。
別途、Cogmo管理画面を提供し、企業の管理ユーザがWatson Discoveryの関連性の学習（検索精度の向上）、アノテーション付与、類義語強化を実施することができます。この他、システムテスト、Discoveryにはない検索補助機能などを提供しています。
構成としては、以下のような構成です。
Watson Discoveryにもクローラーはありますが、例えばWebサイトでは、このディレクトリはカテゴリAなどとして付加情報をつけ、その情報で検索時の対象の絞り込みを行うなどが必要ですので、多様なパターンに対応できるよう、また、顧客の望む時間に定期的にクロールして情報更新できるよう、オリジナルのクローラーを持っています（約7年のノウハウの塊です、うちのエンジニアに感謝）。
ChatGPTとの連携については、ドキュメントのハイライトを渡す、文頭から渡すなどの切り替え機能（文書の種類によってどちらを選ぶかで精度がぜんぜん違います）、モデルやプロンプトを複数利用する機能（検索する箇所によって自動切り替えなど）、ChatGPTが知らない単語を教える機能などを用意しています。
事例としては、わかりやすいものが江戸川区のWebサイトです。右肩にある「メニュー」を押すと検索窓が出てきます。そこに入力すれば、江戸川区Webサイトに組み込まれたCogmoの画面に遷移し、Watson Discoveryによる検索結果とChatGPTの生成文が出てきます。対象は数万ページのHTML、サイト内のPDFファイルを対象にしています。
このほか、従業員3万人程度のインフラ系企業のITポータルサイトで、システムのマニュアルやFAQなどの検索で利用、ソフトウェアサポートのコンタクトセンターの過去の顧客対応メールを検索対象にして、新しい問合せが来たら半自動で障害特定のための初回ヒアリング項目を生成させるなどでご利用いただいています。
いろいろな導入や運用をご支援した結果、RAG型生成AIの実利用のポイントは以下になります。
RAG型生成AIシステムの実利用におけるポイント
- ドキュメントは数万ページ、数十万ページと膨大
- ドキュメントは文書形式がさまざま
規程類のようなWord型文書、マニュアルのようなPPT型文書、同じHTMLでも、製品紹介ページやFAQのような違い
- ドキュメントの更新が頻繁に必要
Webサイトやイントラサイトは基本、毎日
- ドキュメントやナレッジは更新されるので、精度運用が必要（運用をしたい）
精度運用とは検索結果の精度を向上させること。
それは自動的にChatGPTに渡すドキュメント抽出の精度をあげられ、結果、ChatGPTの生成精度があがる
ランカー型検索とベクトル型検索を実利用ポイントで評価する
さて、それでは本題のWatson Discoveryの優位性についてです。
まず、Watson Discoveryなどのランカー型検索がどのように検索精度を出すかといえば、一般的にはセマンティック・ランカーと呼ばれる方法で、言葉の関連性を学習し、検索結果を検索文に対する関連度でソートし直すことで検索精度を出しています。関連性の学習は、「検索文例」と「対応するドキュメント」を指定することで学習させます。これは、画面にすると比較的簡単な画面で、「検索文例」を登録し、それに関連のある文書を選択させることで実現可能です。操作も簡単ですので、製品やデリバリーのエンジニアではなく、企業ユーザが実施することができます。
一方、ベクトル型検索の場合は、文書・文章をチャンク（言葉のかたまり）に分割してデータベースに登録する必要があり、基本、それが検索精度に大きく影響を与えます。ライブラリなども進化しているので、文の途中でチャンクに分割され、文章の意味が壊れるようなことを心配することは今日ではありませんが、文書内容によって、どの程度の文字量をチャンクとすべきかなどは、精度を上げるうえで大きな課題となります（無論、ここがAI屋・言語処理屋のノウハウ、テクニックでもあります）。
このようにランカー型では、DBに文書をインデックスした後に、別の機能で検索精度を調整することができます。一方、ベクトル型検索ではDBに文書をインデックスする際のチャンク化などで検索精度を調整することができます。
これを実利用の視点で見ると、ベクトル型検索は、
- ドキュメントは数万ページ、数十万ページと膨大
- ドキュメントは文書形式がさまざま
⇒最適なチャンク化が困難
- ドキュメントの更新が頻繁に必要
- ドキュメントやナレッジは更新される
⇒更新のたびにチャンク化する必要、かつ、一度決めたチャンク方針が常に良いとは限らない
- 精度運用が必要
⇒企業ユーザがエンジニアとしてチャンク化を行うのは困難、精度運用ができない
の課題があり、企業や行政・自治体にある幅広い文書を扱う場合、なかなか実利用が現実的ではないことはご理解いただけるかと思います。
もちろんベクトル型検索の良い部分もあります。
例えば、情報の更新が数ヶ月に1回程度のコールセンターのFAQなどを対象にする場合です。FAQなので、文章の書き方、文字量なども一様でチャンク化はしやすく、極論、1FAQを1チャンクにするなども可能です。また、ベクトル型検索は検索する際の言語を選ばないので（「こんにちは」と「Hello」でも検索としては同じに扱える）、外国語で検索文を入れても日本語のドキュメントを検索することができます。不思議な使い方だなと感じられるかもしれませんが、コールセンタ、コンタクトセンタに外国人の方が増えている中では、重要な機能ポイントです。文章は日本語で読める、話すこともできる、ただ、資料を検索する良い日本語が浮かばないとき、母国語で検索しても検索できるのは便利です。
ただ、多様な文書があり、その情報更新頻度が高い企業ユースや行政・自治体ユースでは業務の実利用に耐えうるものとしては、ランカー型検索の方が耐えられると考えます。
ランカー型で精度は出るのか
次はランカー型検索で精度がでるのか、ということについてです。同じドキュメント使ってベクトル型検索と精緻に比較したものではありませんが、ランカー型検索でも検索精度は十分でます。また、その学習コストもそこまで高くないというのが実感です。
例えば、以下は、ある学習の実例です。
左が導入当初にWatsonのディレクターが行った学習です。赤枠が精度となります。
この精度は「ある検索文」に対して「検索上位にいてほしいページ・URL」を指定し、それが「上位何位」以内に入っていてほしいかでテストし、指定したページが指定した順位内であればOK、順位に入らなければNGというものです。このテストは5位以内でのテストです。
初回は学習などなんの設定も行わす、38%。そこからちょっとした設定で60%弱、70-90%弱までは細かい調整で対応して95%まで達成しています。2日間の作業です（フルではなく）。
一方右側は、お客様による学習です。新しいドキュメントが増えてきたので、テスト数を60%増やして（追加、更新、削除の結果）、テストを実施。確認のための初回精度が60%強。そこから、業務の合間での学習作業で数日で90%を越える精度まで至っています。
どのような業務で利用するかによって精度の閾値の議論はありますが、ランカー型の学習操作を企業ユーザができ、それが数日で30-40%も精度向上できるのであれば、企業ユーザも納得して運用できます。AIシステムで一番の課題である「精度への納得」が、このような形で十分に得られるのはランカー型検索の良いところだと思います（システム提供側にも利用側にも）。
もちろん、ベクトル型検索にさらにランカー型検索をつけるという方法もあるので、どの方法が一番精度が出る、学習コスト対効果が良いとは私からは言えませんが、チャンク化の不安定さと比べるとランカー型での精度向上で十分だと考えています（時間あれば、精緻比較はしてみますが）。
ドキュメントや運用の実利用での課題、精度が出るかという課題の2つのみの視点でしたが、RAGはランカー型検索で行うのがいまは最善と考えています。
Watson Discoveryは、ベースの検索精度、価格、応答速度、対応できるドキュメント数などから、その代表となり得るものです。
Azure AI SearchなどでRAGの精度がでなかったなどの場合は、ぜひ、Watson Discoveryを試してみてください。
ご相談いただければ、製品提供、エンジニアリング提供、コンサルティング提供など可能です。
※補足：Azure AI Searchにもセマンティック・ランカー機能はあり、利用可能です。
ベクトル型検索＝Azure AI Searchという認識が世の中強いので、本記事ではあえてそのままのバイアスで記述しています。