このブログは、「企業で生成AIを本当に使えるようにするには何が必要か」を、全3回にわたって順を追って解説するシリーズです。
ChatGPTの登場によって、生成AIは私たちの生活や仕事に急速に浸透しました。自然な文章を書き、要約し、翻訳し、プログラムを書くこともできます。その能力の高さに驚いた方も多いでしょう。
しかし、企業で生成AIを利用しようとすると、すぐに一つの問題に直面します。「AIは社内の情報を知らない」ということです。
例えば「リモートワークの申請方法を教えてください」と質問しても、ChatGPTは一般的な制度は説明できますが、あなたの会社の就業規則を知っているわけではありません。「製品Aの交換手順を教えてください」も同様で、その会社独自のマニュアルや設計資料を読んでいるわけではないため、正確な回答はできません。
企業で生成AIを活用するには、AI自身が企業の情報を参照できるようにする必要があります。そこで登場したのがRAGという仕組みです。
LLMは「知っている」のではなく「文章を生成している」
RAGを理解するには、まずLLM（Large Language Model：大規模言語モデル）の特徴を知る必要があります。LLMは人間のように知識を記憶しているわけではありません。大量の文章を学習し、「次に続く言葉として最も自然なもの」を予測しながら文章を生成しています。
例えば「日本で一番高い山は」と入力されると「富士山です。」と続きを生成します。これは辞書から知識を検索しているのではなく、学習した膨大な文章のパターンから最も自然な続きを生成しているのです。そのため多くの場合は正しくても、常に正しいとは限りません。
ハルシネーションという問題
LLMにはHallucination（ハルシネーション、幻覚）と呼ばれる問題があります。もっともらしい文章を生成しているものの、その内容が事実とは異なる状態です。存在しない製品仕様を説明したり、存在しない社内ルールを回答したり、存在しない論文を引用したりすることがあります。しかも文章自体は非常に自然なため、人間が読むと正しい内容のように感じてしまいます。
医療、金融、製造業などでは、一つの誤回答が大きな事故や損失につながりかねません。企業では「それらしい答え」ではなく「根拠のある正しい答え」が求められます。
RAGという考え方
この問題を解決するために考えられたのがRAG（Retrieval-Augmented Generation：検索拡張生成）です。考え方はシンプルで、AIに回答を考えさせる前に、まず関連する文書を探して渡します。
「製品Aの交換手順を教えてください」という質問があれば、最初に製品マニュアルの中から交換手順が書かれたページを検索します。そのページをLLMへ渡し、「この内容をもとに回答してください」と指示します。するとAIは自分の記憶だけでなく、実際の社内文書を参考にしながら回答を生成できます。RAG の基本フロー質問「製品Aの交換手順は？」① 関連文書を検索意味が近いページを探す② LLM へ渡すその文書を参照して生成③ 根拠付きで回答出典を示せる
図1-1｜RAGは「まず検索、それから生成」。回答に出典を添えられる
文章を「意味」で検索する
ここで新しい問題が生まれます。企業には数千、数万、多い場合には数百万ページもの文書があります。その中から質問に関係するページをどう探すのでしょうか。
昔ながらの検索はキーワードが一致する文書を探しました。しかし人間は必ずしも文書と同じ言葉で質問しません。利用者は「退職するときに返すものを教えてください」と尋ねても、社内規程には「雇用契約終了時には貸与物を返却すること」と書かれているかもしれません。使われている単語が違うため、キーワード検索では必要な文書を見つけられないことがあります。
図1-2｜言葉が違っても意味が同じなら見つけたい。そこで使うのが Embedding
Embeddingとは
Embeddingとは、文章の意味を数値で表現する技術です。コンピュータは文章の意味をそのまま理解できないため、AIは文章を数百〜数千次元の数値へ変換します。意味の近い文章ほど、この数値も近くなります。
「退職」「雇用契約終了」「会社を辞める」は表現が違っても意味が近いため、似た位置に配置されます。反対に「犬」「自動車」「半導体」のように意味が大きく異なるものは、遠く離れた場所に配置されます。こうして文章そのものではなく「意味」で検索できるようになります。
配置図1-3｜意味の近さが「距離の近さ」になる
Vector Databaseとは
Embeddingで作られた数値を保存し、意味の近い情報を高速に検索するために使うのがVector Databaseです。質問も文書もEmbeddingへ変換し、その距離を比較することで意味の近い文書を探します。そのため「高温」と「過熱」、「障害」と「故障」のように言葉が一致しなくても関連する文書を見つけられます。
RAGでは、①質問をEmbeddingへ変換し、②Vector Databaseから意味の近い文書を検索し、③その結果をLLMへ渡し、④LLMが文書を参考に回答する、という流れになります。この仕組みによって、生成AIは企業文書を参照しながら回答できるようになりました。
RAGにも限界がある
RAGは企業向けAIを大きく前進させました。しかし、企業の質問は必ずしも一つの文書だけで答えられるとは限りません。例えば次のような質問です。
「この部品を使用している製品を教えてください。また、その製品を購入した顧客のうち、現在も保守契約が有効な会社を一覧にしてください。」
この答えは一つの文書には書かれていません。部品表・製品情報・出荷履歴・顧客情報・保守契約——これら複数の情報をつなぎ合わせて初めて答えが分かります。つまり企業の知識は、文章の中だけでなく、情報同士の「つながり」の中にも存在しているのです。RAGは文章を探すのは得意ですが、このような複雑な関係をたどるのは得意ではありません。
図1-4｜一つの文書では答えられない問いがある
そこで次のステップとして登場するのがKnowledge Graphという考え方です。文書の内容だけでなく、人・製品・部品・契約・規格などの関係そのものを知識として整理し、AIがそれらをたどりながら推論できるようにします。
NEXT：
次回は、企業向けAIで注目される Knowledge Graph とは何かを説明していきます。
