データ活用やDXがどんどん解る用語集　　　　
検索拡張生成（RAG：Retrieval Augmented Generation）

検索拡張生成（RAG：Retrieval Augmented Generation）とは、ChatGPTなどの生成AIの活用手法であり、生成AIの利用時に外部情報源を検索して得られた情報をあわせて利用することで応答を改善する取り組みのことです。
ChatGPTなどの生成AIは大規模言語モデル（LLM）をベースにして実現されていますが、LLMは通常、一般的なデータを用いてトレーニングがなされているため一般的な知識しか持っていない傾向があります。RAGは、外部情報源から検索した情報を補うことで、LLM自体が学習していない話題（自社に関する情報など）に対しても、より適切な応答をさせる手法として期待されています。

現在、生成AIが世間的にも大変な注目を浴びています。ビジネスにおける生成AIの活用にも注目が集まっていますが、十分な成果が上がっている話は多くはないように思います。

例えばChatGPT、試しに使ってみた印象は強烈で、これを使えば何かできるのではないか？と思えたりします。さらには、他社がビジネスでの利用に取り組んでいる話を耳にしたりすると、活用せねばという気持ちに一層なってきます。

しかしながら、「文書要約」や「アイディア出しの補助」など補助的な用途では活用されていることはあるものの、その程度にとどまっていることが多く、試しに使ってみたときに受けた強烈な印象に比べてビジネスでの活用は今一つ進んでいないのが現状ではないかと思います。

どうして今一つ活躍できていないのか

どうして活用が今一つ進んでいないのでしょうか。まず、正しくないことを平気で言ってしまうハルシネーションの問題が広く知られており、正確性や結果責任が求められるような用途では使いづらい問題があります。そしてそれ以外に「自社に関連する質問をしても、一般的論な回答しかできないことが多い」など応答できることに制限があることも制約となっています。

つまり、生成AIに答えてもらいたいことや、ビジネスで利用したいと思ったことがあっても、回答を行うために必要な前提知識を「生成AIがそもそも知らない」ので活用が難しいことがあります。例えば、自社の社内規定を踏まえないとできない回答をChatGPTに求めてもうまく応答できません。

自社のビジネスで活躍させたいと考えたならば、当然に自社の事情を踏まえての回答が必要になってきますが、それができないわけです。

学習データに御社のデータは入っていない

どうしてそうなってしまうのかというと、ChatGPTを実現している大規模言語モデル（LLM）を作るときに使っている学習データが「世間で一般的に公開されているもの」だけだからです。

ですから、Webに載っているようなことや、辞書に載っているような一般的なことは学習していて答えてくれることが多いのですが、自社の社内規定などは学習データに入っていないので当然うまく答えられません。

ではどうすればよいか

そのような現実を踏まえて、生成AIはどのように活用すれば良いでしょうか。

まず、ChatGPTが知っていて処理できることを踏まえて、その制限において自分たちのビジネスで活用できることがないか考えてみることができます。それがまさに、「要約」や「アイディア出しの補助」などでのよく見られる活用です。

もう一つのアプローチは、何とかして「自社に関連したデータを生成AIに理解させて活用範囲を広げる」取り組みです。知識がないから無理ならば、知識を備えたものを用意すればいいはずです。

ChatGPTなどの生成AIは大規模言語モデル（LLM）をベースに実現されていますから、機械学習活用の通常のアプローチとしては、「自社独自のLLMを作成する」か、「ファインチューニングを用いて既存のLLMに追加学習を行う」ことでなんとかしたいところです。

•  
  機械学習の一般的事情については、こちらの記事も参照ください：
  ⇒ 機械学習｜用語集
  ⇒ ファインチューニング｜用語集

しかし残念ながら、（執筆時点では）独自のデータで学習させて自社専用のLLMを新たに作ることはあまりにも手間がかかるため現実的ではありません。それならば、既存のLLMをベースに、ファインチューニングにより自社独自のデータを追加学習させたいところですが、こちらの取り組みも（現時点では）技術的にうまく機能しないことが多いとされます。

つまり、自社独自のLLMを用意することは難しく「汎用のものをそのまま使わざるを得ない状況」が現状あります。そこで代わりに注目されているのが、「RAG」の活用による生成AIの活用範囲の拡大です。

TOPへ

RAG（ラグ）は「Retrieval Augmented Generation」を略した言葉です。日本語では「検索拡張生成」と訳されます。生成AI（LLM）自身には手を入れず汎用のものをそのまま使い、自社に関するデータを「利用時に外部から補う」ことで、「自社の事情や自社固有のデータなどを踏まえた回答をさせる」取り組みです。

• 利用者が質問文などを入力する。
• [検索フェーズ] その質問文から、外部情報源（ChatGPTの外側にある社内文書など）を検索し、検索結果から生成AIに追加で与える情報を用意する。
• [生成フェーズ] 利用者の質問文に加えて、検索結果から作った追加情報を併せてプロンプトとして与えることで、生成AIの応答を外部情報源の内容を踏まえたものに変える。

検索する

利用者が生成AIに対して入力したテキストから、その入力内容に関連した情報を外部情報源から検索して取得します。例えば「社内規程を踏まえると、（こういうケースの）出張費申請はどのようにすればよいですか」という質問であるなら、「社内規程」とか「出張費申請」といった話題で、社内文書を検索して関連文書を見つけ出す処理をします。

ではどうやって、関連文書を見つけてくるのでしょうか。

「ベクトル化（エンベディング）」や「ベクトルデータベース」のようなディープラーニング系の技術を用いることで、質問文と「意味が似ている」社内情報を探し出してくる検索機能が利用されていることがあります。あるいは、社内文書の横断検索はナレッジマネジメントの取り組みなどで大昔からある分野でもあり、そちらで長年の実績がある「全文検索エンジン（エンタープライズサーチ）」を用いて関連文書を探してくることもできます。

RAGの説明ではベクトル化のような知らないキーワードが出てくることがありますが、想像もつかないようなことが行われるわけではなく、基本としては「関連情報の検索」が行われています。

生成AIに入力できる形にする

検索して取得したデータを、利用している生成AIに入力できる形に加工します。ベクトル化したデータかもしれませんし、検索したドキュメントから抜き出したテキストデータかもしれません。あるいはその生成AIが、WordやExcelのファイルをそのまま理解できるのなら、見つけてきたそのままで良いかもしれません。

先ほどの例ならば、「交通費の社内規程」について全文検索エンジンで関連文書を検索し、社内のファイルサーバにあるWordドキュメントがヒットしたとするなら、そのWordファイルの内容を抜き出して、テキストデータにするなどの処理をします。

データベースに入っている正規化された表形式のデータ（DWHやRDBなど）が関連情報であった場合など、見つかったデータの形式が生成AIと相性が悪いこともあります。そのような場合には、うまく回答できるように工夫して前加工しなければいけないこともあります。

生成AIに関連情報を与えて回答させる

最後に、「利用者が入力したテキスト」に、「外部情報源を検索して取得した関連情報」も併せた入力を生成AIに与えて応答を生成させます。

技術的には、LLMを事前学習する代わりに、「利用時に追加学習させたかのような挙動変更」を実現できる「コンテキスト内学習（In-Context Learning）」を用いることで、生成AIの挙動を動的に変更していることになります。

⇒ コンテキスト内学習（ICL: In-Context Learning）｜用語集

RAGの性能を引き上げる方法は日々研究されており、もっと手順が工夫されていることもありますが、「基本的な実現手順」としてはここまでの説明の通りです。

TOPへ

RAGのシステムを実際に開発するのは大変ですが、「手作業」で似たようなことをやってみましょう。

RAGなしで聞いてみると

その前にRAGなしでそのまま聞いてみましょう

一般論で頑張って答えてくれていますが（これはこれでありがたいことですが）、しかし自社のルールで具体的に何をどうしたらいいのかはわかりません。しかし、ChatGPTは社内のルールについて知らないので、このようになってしまいがちです。

RAGで関連情報を与えるイメージ

では次に、「関連情報を与えて回答させる」とはどういうイメージなのか、まずは例を見てもらいましょう。なお、あくまでもイメージ例です。

この全体を利用者が入力するわけではありません。利用者が入力した部分は「太字の部分」だけ（先ほどと同内容）です。それ以外はRAGにより自動的に追加される部分です。

RAGでは質問文を元に検索を行って外部情報を参照するわけですが、上記だと「補助情報」の部分に関連情報を埋め込んだプロンプトを作ります。

実際に関連情報を入れて回答させてみる

では例として、以下のURLにある「東京都職員の場合の規程」を外部情報源として、プロンプト内にテキストデータとして張りつけたもので実際に聞いてみましょう。

⇒ 職員の旅費支給規程（東京都）

回答としてはどうも今一つな感じはありますが（ここから「質問の仕方を工夫する」とか「追加質問をして回答を変えてもらう」などのプロンプトのテクニックで必要な回答を引き出してゆくことはできるでしょう）、特に工夫したわけでもないプロンプトでとりあえず動かしてみた程度のものでも、それなりに回答することはわかりました。

ともかくも、回答が一般論ではなくなっていることに注目してください。ChatGPTに「固有の事情を配慮した回答をさせる」ことに成功しているのです。外部情報源から追加で与えた「東京都での規程」をともかくも踏まえて質問に回答した形になっています。

どうでしょうか。このようにRAGを用いれば、汎用のChatGPTでも自社の事情を踏まえた回答をしてくれそうなことがわかります。

TOPへ

汎用の生成AIを利用しつつも、自社のデータを参照して回答させることができるため、（執筆時点において）RAGの活用には大きな期待がかけられています。しかしRAGの利活用にあたっては考えておくべきことがあります。

「全文検索システム（エンタープライズサーチ）」と、どう違うのか

すでにそのような感想をお持ちになった方もおられたかもしれませんが、生成AIが回答を作っているというよりは、「検索により答えを見つけている」ようなところがあります。

検索結果をそのまま利用者が参照するだけで用は足りてしまうことも多いかもしれません。例えば、検索でヒットした社内規定の旅費に関する記述を自分で読めばそれで充分なこともあるでしょう。

検索結果を生成AIに処理させると、むしろハルシネーションなどで回答が間違っていないかの不安も生じますし、生成AIは確率的に動作することもあり、RAGを用いたシステムでは同じことを聞いているのに毎回回答が違って困ることもあります。情報検索手段として利用する場合には、不安になる挙動をすることがあります。

ただし、全文検索で見つけた大量の関連ドキュメント（例えば社内規程関連のドキュメント類を全部など）を読みこませた上で回答するような話になると、利用者が自分で全てのドキュメントを読み込むのは大変なので、生成AIに回答をお願いするメリットが大きくなってきます。

検索して見つかるものから回答できるとは限らない

検索は「質問文」から行います。つまり質問文を基にして、含まれるキーワードや意味などが似ている関連ドキュメントを検索して探し出してくることになります。しかし、適切な回答に必要な関連情報が載っている資料は、質問文に類似性があるとは限りません。

必要なのは質問文に似ている関連情報ではなく「素晴らしい回答文」です。そのような回答を生成するために必要な外部ドキュメントは質問文ではなく回答文に似ている（あるいはどちらにも類似しない）可能性があります。

例えば、「日本以外で、このような事業が適した国がありますか？」と尋ねた場合、必要なのは「日本に関連する資料」ではなく「むしろそれ以外の様々なこと」になります。問題を解いてほしいとか何かを思いついてほしいなど、創造的な回答が欲しい場合にも、元の質問文と似ている情報からは良い応答を生み出せるとは限りません。これも検索であることの限界だと言えます。

生成AIに全情報を入力すればいいのでは？

検索して関連する情報を絞り込む必要などなく、「外部情報源を全部丸ごと」生成AIに入力すれば良いのではないか、RAGは要らないのでは？という意見もあります。

昨今、生成AIが一度に受け取れるデータ量はどんどん増加しており、本一冊分くらいのテキストデータなら一気に読み込めるくらいになってきています。そういう状況もあるために、検索などせずとも「社内の文書を全部読み込ませる」ようなことが、現実的にできるようになってきています。

ただし生成AI、読み込ませるデータ量に応じて課金されることが多いので、全部読ませると利用料金が多くかかります。また、必要な情報を絞り込んで与えた場合と、絞り込まずに全部与えた場合では、必要な情報のみに絞り込んだ方が回答の質が高いのではないか、と現時点（の研究論文など）では言われています。

ただし、検索で適切な情報が探し出せている前提での話ではあり、元の質問文から必要な情報をうまく検索できない場合もあることを考えるなら、全部読み込ませた方が現実的には回答の質は担保されるかもしれません。

また、RAGを「読み込ませたくない情報」を除外できる点で優れていると考えることもできます。参照してほしくない話題が混ざらないように除外するとか、利用者の権限では参照出来てはいけない情報など除外することができます。つまりファインチューニングなどに比べて、回答するたびにその都度、利用するデータを制御して動作させることができる長所がある、と考えることもできます。

ハルシネーション対策になるのか？

RAGがハルシネーション対策の技術だと説明されていることがあります。緩和策になる場合はあると思われますが、問題を根本的になくすようなことを期待できる技術ではないはずです。

RAGは外部情報源からデータを流し込むだけであって、生成AIの動作そのものを変更するものではありません。外部情報源に答えるべき内容そのものがある場合にはそれが直接参照されて正確な回答をすることは多くなるかもしれませんが、存在しない話を積極的に創作してしまうこともあるハルシネーションの本質的挙動に介入して抑止しているわけではありません。

データ流出の抑止になる？

RAGではファインチューニング等に比べて情報流出を防ぐことができると言われていることがあります。しかし、クラウドサービスとして外部の生成AIを利用するなら、結局データの外部送信は行われます。

たしかにRAGでは自社の持つデータを生成AIの「学習」に用いることはなく、その過程で情報が外部に出ることはありません。しかし、利用時にプロンプトに含める形でデータは送信されますから、別の形での外部送信はなされることになります。

クラウドサービスが、利用時に入力された情報を生成AIの学習など他の用途に使いませんと表明しているからRAGは大丈夫だと考えるのなら、ファインチューニングで用いた学習データについて、他の用途に利用しないことが表明されていれば同じく大丈夫なはずです。

ただしファインチューニング等と違い、自社の持つデータ全体を外部送信せず、その都度、検索により見つかった一部分のみ送信するので、データの外部送信を局在化して小さくできていると考えることもできます。

TOPへ

RAGを活用するためにはもう一つ考慮が必要なことがあります、「検索対象のデータをどう用意するのか」です。データの検索により回答を生成しているわけですから、必要なデータが用意され、それが必要に応じて検索できる状態になっていなければ機能しません。

「検索できる」状態にするには社内のデータを整備する必要がある

例えば、企業でChatGPT活用にはRAG導入に効果があると聞いて、RAGができるシステムを調達しても、社内のデータ整備ができていなければ十分な効果は得られないでしょう。なぜなら外部情報源の検索がうまく出来ないからです。

自社の持つデータについて、どこに同様なデータがあるかを確認してデータの利用環境を整備することで「検索できる」状況を整備しなければいけません。さらには、検索結果から必要なデータを選び、適切に前処理して生成AIに渡せる必要もあります、そのためにはデータの質や形式についても整備が必要になることがあるはずです。

利用したいデータが電子化されずに紙のままになっていて電子化するところから作業しなければいけないこともあるでしょうし、古いデータと新しいデータが混ざって存在しているなら、新旧データが混ぜこぜに検索されて生成AIに投入されてしまうと、良い応答はできなくなるはずです。

つまりRAGを活躍させるためには、その前提として「社内のデータ利用環境を整備」する必要があります。

データを利用できる環境は、整備し続けなければいけない

外部ベンダに依頼をして、社内のデータ利用環境を整備したとしてもまだ問題があります。データ利用環境は継続的に整備をする必要があるためです。

例えば、社内で組織変更があって新部署ができたとか、新事業に取り組むことになった場合、従来なかったデータ（外部情報源）が発生することや、データ利活用（生成AIを用いて聞きたいこと）の新しいニーズができることがあります。

つまり、RAGを継続的に機能させるためには、組織やビジネスの状況変化にあわせて、新しいデータが新しいニーズによって検索できるように、社内のデータ利用環境を整備し続ける必要があります。そうしなければ例えば、新設された事業部門に関連するデータについて聞いても答えられないようなことが起こりえます。

TOPへ

このようにRAGを継続的に機能させるためには、社内でデータの利用環境を整備して必要な情報を適切に検索できるようにし、検索結果を適切に前処理して生成AIで利用できる状況を継続的に維持する必要があります。業務での利用ニーズに合わせてRAGが良い結果を出せるようにするため、検索方法や前処理を工夫するなど、試行錯誤が必要になることもあります。

データの整備作業を行うたび、あるいは利活用での試行錯誤が必要になるたびに、外部ベンダに作業を依頼しないといけないなど毎回手間と時間がかかってしまうなら、RAGの活用がうまく進められなくなることも考えられます。

つまりRAGをうまく活用するためには、「社内のデータ利用環境整備」をスムーズかつ効率的に実現できる手段を用意する必要があります。

「つなぐ」技術を活用ください

このような、多種多様なシステムやクラウド上にあるデータに連携し、必要に応じでデータを読み取り、加工し、転送処理を行い、データ環境を整備する取り組みを、「GUIだけ」で効率的に開発できる手段が存在します。「EAI」や「ETL」、「iPaaS」と呼ばれる、「DataSpider」や「HULFT Square」などの「つなぐ」技術です。

GUIだけで利用できる

通常のプログラミングのようにコードを書く必要がありません。GUI上でアイコンを配置し設定をすることで、多種多様なシステムやデータ、クラウドサービスへの連携処理を実現できます。

「GUIで開発できる」ことは長所でもある

GUIだけでのノーコード開発は、本格的なプログラミングに対して簡易で妥協的な印象を受けるかもしれません。しかしながら、GUIだけで開発できることは「業務の現場の担当者が自分たち自身で主体的にクラウド連携に取り組む」ことを可能にします。ビジネスのことを一番良くわかっているのは現場の担当者です。

本格的処理を実装できる

「GUIだけで開発できる」ことを謳っている製品は沢山ありますが、そういう製品に簡易で悪い印象を持っている人もおられるかもしれません。

確かに、「簡単に作れるが簡易なことしかできない」「本格的処理を実行しようとしたら処理できずに落ちてしまった」「業務を支えられるだけの高い信頼性や安定稼働能力がなくて大変なことになってしまった」ようなことは起こりがちです。

「DataSpider」や「HULFT Square」は、簡単に使うこともできますが本格的プログラミングと同等のレベルの処理の作りこみもできます。内部的にJavaに変換されて実行されるなど本格的プログラミングと同様の高い処理能力があり、長年にわたって企業ITを支えてきた実績もあります。「GUIだけ」の良さと、本格的能力の両方を兼ね備えています。

iPaaSなので自社運用不要

DataSpiderなら自社管理下のシステムでしっかりと運用できます。クラウドサービス（iPaaS）のHULFT Squareなら、このような「つなぐ」技術そのもの自体もクラウドサービスとして自社運用不要で利用でき、自社での導入やシステム運用の手間がなく利用できます。

TOPへ

機械学習に関連したキーワード

• 機械学習
• AutoML
• ファインチューニング
• 転移学習
• In-Context Learning
• RAG（Retrieval-Augmented Generation）
• ベクトル化
• ベクトルデータベース

生成AI/ChatGPTに関係するキーワード

• 生成AI
• 大規模言語モデル（LLM：Large Language Model）
• ChatGPT
• プロンプトエンジニアリング
  • -ロールプレイプロンプティング / Role-Play Prompting
  • -プロンプトテンプレート
  • -Few-Shot プロンプティング / Few-shot Learning
  • -CoT：Chain-of-Thought / Zero-shot CoT
  • -Self-translateプロンプティング / 英語で考えて日本語で回答してください
  • -The Flipped Interaction Pattern（解らないことがあったら聞いてください）

データ連携やシステム連携に関係するキーワード

• EAI
  • -システム間をデータ連携して「つなぐ」考え方で、様々なデータやシステムを自在につなぐ手段です。IT利活用をうまく進める考え方として、クラウド時代になるずっと前から、活躍してきた考え方です。
• ETL
  • -昨今盛んに取り組まれているデータ活用の取り組みでは、データの分析作業そのものではなく、オンプレミスからクラウドまで、あちこちに散在するデータを集めてくる作業や前処理が実作業の大半を占めます。そのような処理を効率的に実現する手段です。
• MFT（Managed File Transfer）
  • -ファイルによる連携処理を、企業活動を支えられるだけの高度な水準の「安全安心確実さ」で実現する連携基盤です。単にファイルの転送処理ができるだけではなく、転送処理が間違いなく確実に行われることや、セキュアで安全な転送、転送ログをきちんと残して確認や管理ができる機能などが揃えられているファイル転送やそれを実現する基盤のことをそう呼びます。
• iPaaS
  • -様々なクラウドを外部のシステムやデータと、GUI上での操作だけで「つなぐ」クラウドサービスのことをiPaaSと呼びます。

オンプレミスにあるITシステムからクラウドサービスまで、様々なデータやシステムを自在に連携し、IT利活用をうまく成功させる製品を実際に試してみてください。

「つなぐ」ツールの決定版、データ連携ソフトウェア「DataSpider<」および、データ連携プラットフォーム「HULFT Square」

当社で開発販売しているデータ連携ツール「DataSpider」は長年の実績がある「つなぐ」ツールです。データ連携プラットフォーム「HULFT Square」はDataSpiderの技術を用いて開発された「つなぐ」クラウドサービスです。

通常のプログラミングのようにコードを書くこと無くGUIだけ（ノーコード）で開発できるので、自社のビジネスをよく理解している業務の現場が自ら活用に取り組めることも特徴です。

DataSpider / HULFT Squareの「つなぐ」技術を試してみてください：

簡易な連携ツールならば世の中に多くありますが、GUIだけで利用でき、プログラマではなくても十分に使える使いやすさをもちつつ、「高い開発生産性」「業務の基盤（プロフェッショナルユース）を担えるだけの本格的な性能」を備えています。

IT利活用の成功を妨げている「バラバラになったシステムやデータをつなぐ」問題をスムーズに解決することができます。無料体験版や、無償で実際使ってみることができるハンズオンも定期開催しておりますので、ぜひ一度お試しいただけますと幸いです。

 

「HULFT Square」で貴社のビジネスが変えられるか「PoC」をしてみませんか：

貴社のビジネスで「つなぐ」がどう活用できるのか、データ連携を用いた課題解決の実現可能性や得られる効果検証を行ってみませんか？

• SaaSとのデータ連携を自動化したいが、その実現可能性を確認したい
• データ利活用に向けて進めたいがシステム連携に課題がある
• DXの実現に向けてデータ連携基盤の検討をしたい