最近、RAGという言葉を見かけることが増え、生成AIの実務利用における有力な構成として定着しつつあるように感じていた。
そこで今回、環境構築から評価までを自分でも試し、その挙動を順に確認してみることにした。この記事では、その記録と所感を整理していく。同様に、RAGを業務でどう使えるのか、どこに限界があるのかを見極めたい人にとって、参考になればうれしい。
RAGとは何か
RAGは Retrieval-Augmented Generation の略で、日本語では「検索拡張生成」と訳されることが多い。
大まかに言えば、まず外部の文書群から質問に関連する情報を検索し、その結果をもとにLLMが回答を生成する仕組みである。
LLM単体でも多くの質問には答えられるが、実務で使おうとすると、どうしても次のような課題にぶつかる。
- 最新情報を知らない
- 組織固有の文書や規程を知らない
- 学習済み知識だけでは根拠を示しにくい
- それらしい答えは出ても、業務上そのまま使うには不安が残る
RAGは、こうした弱点を補うための現実的な構成として広まってきた。
事前学習済みモデルにすべてを覚え込ませるのではなく、手元の文書やFAQ、マニュアル、制度説明ページなどを検索対象として持たせ、必要に応じてそこから情報を取ってくる。これにより、組織固有の知識や比較的新しい情報にも対応しやすくなる。
技術的には、文書を小さな単位に分割し、それを埋め込みベクトルとして保存しておき、質問文も同じ埋め込み空間に写して近い文書片を検索する、という構成がよく使われる。
最近よく見かける「社内文書に答えるAI」「FAQ自動応答」「マニュアル検索AI」などの多くは、この考え方の延長にある。
なぜ今RAGが注目されているのか
RAGが注目される理由は、単に流行しているからではなく、実務上の都合とかなり相性が良いからだと思う。
多くの企業や自治体には、すでに大量の文書がある。
FAQ、手順書、規程、マニュアル、制度説明、過去の問い合わせ記録など、知識そのものは存在しているが、それが活用しやすい形になっていないことが多い。
このとき、すべてを作り直したり、LLM用に学習し直したりするのは現実的ではない。
その点、RAGは既存文書を比較的そのまま活用しやすい。データ整備の負担はあるものの、「まずは今ある文書を検索対象にして試してみる」という始め方ができる。
また、生成AIの導入を考える場面では、「自由生成だけに任せるのは怖いが、既存知識を踏まえた回答なら検討しやすい」という空気もある。RAGはまさにその中間に位置していて、LLM単体よりも実務側が受け入れやすい構成に見える。
そうした背景もあり、RAGは生成AI活用の現実解の一つとして広がっているのだと思う。
実際どこまでできるのか、自分で確かめてみたくなった
RAGが有力な構成であることは分かる。
ただ、実際にどの程度のことができるのかは、外から見ているだけでは分かりにくい。
たとえば、単純なFAQであれば、それなりにうまくいきそうだという感覚は持ちやすい。
一方で、実務で出てくる問い合わせは、必ずしもそんなにきれいではない。
- 言い換えが多い
- 必要な情報が一部欠けている
- 背景事情が長く含まれている
- 一つの質問に複数の論点が混ざっている
- 質問文だけでは、何を本当に知りたいのかが曖昧なことがある
このような入力に対して、RAGが実際にどう振る舞うのかには前から関心があった。
特に、検索はできることと、業務上そのまま使えることは同じではない。近い文書片を拾えるとしても、それが実際の問い合わせ対応として十分かどうかは、別に見ておく必要があるように思えた。
そこで今回は、RAGを実際に組み、少なくとも自分の手元で、
- 基本的な検索精度はどうか
- 言い換えにどこまで耐えるか
- ノイズを含む質問でどうなるか
- 複数意図を含む質問でどう振る舞うか
- 情報不足の質問に対して何が起きるか
といった点を順に見ていくことにした。
今回の取り組みで見ていきたいこと
今回の検証は、RAGの優秀さを礼賛することも、逆に限界を誇張することも目的ではない。
むしろ、実際に触ってみることで、その強さと弱さの両方を落ち着いて見ていくことを目的としている。
特に関心があるのは、次のような点である。
基本的な検索精度
まずは、単純な質問に対して関連文書をどの程度正しく上位に出せるかを見たい。
ここが弱ければ、その先の議論は成り立たない。
言い換えやノイズに対する強さ
実務の問い合わせは、文書見出しどおりの表現では来ない。
そのため、自然な言い換えや余計な背景説明があっても、主たる意図に近い文書を拾えるかは重要になる。
複数意図を含む質問への対応
一つの問い合わせの中に、複数の論点が含まれることは珍しくない。
このとき、RAGがどちらか一方だけを強く拾うのか、それとも複数の関連情報をある程度うまく候補に含められるのかは、かなり気になるところである。
情報不足や曖昧さへの振る舞い
検索ができることと、答えてよいことは同じではない。
情報が不足している質問や、制度的な判断を伴う問い合わせに対して、RAGがどういう振る舞いを見せるのかも、実務上は無視できない。
まずは実際に触ってみるところから始める
生成AIの話題は広がりが大きく、概念的な議論だけでもかなりのことが言えてしまう。
ただ、RAGについては、実際に環境を組み、検索結果を見てみることで初めて分かる部分も多い。
今回の取り組みでは、そうした「実際に動かしてみてどう見えたか」を軸に、環境構築、評価、所感を順に整理していきたいと思う。
次回は、まず今回の検証でどのような環境を組んだのか、どのようなデータを使い、どういう形でRAGを動かしたのかを整理する予定である。
おわりに
RAGは、生成AIの実務利用を考えるうえで、かなり有力な構成の一つだと思う。
一方で、広く使われ始めているからこそ、実際にどこまでできるのか、どこから慎重に見た方がよいのかを、自分の手で確かめておく意味もあるように感じている。
この記事では、その入口として、RAGを試してみようと思った理由と、今回見ていきたいポイントを整理した。
次回は、実際に構築した環境とデータの準備についてまとめる。