RAGのユースケース：チャットボット、社内検索、文書要約

何にでも RAG を付けると、遅くて高いだけになる

RAG は、質問が来るたびに検索を走らせ、取り出した本文を丸ごとプロンプトに詰めて LLM に渡します。当然、素で聞くより遅く、料金も高くつきます。

「敬語のメール文面を作って」「この英文を訳して」のような、一般的な文章力だけで済む仕事に RAG を挟んでも、増えるのはコストだけです。検索がたまたま関係のない社内文書を拾えば、かえって回答が濁ります。

RAG が効くのは、答えが手元の資料の中にしか無い仕事です。裏返すと、その条件を満たす仕事は社内に山ほどあります。判断に迷ったら、その質問に人間が答えるとき何かを開くかを考えてください。何も開かずに答えられるなら RAG は要りませんし、規程やマニュアルを開くなら RAG の出番です。

効く形は、おおむね 3 つに落ち着く

1 つ目はカスタマーサポートのチャットボットです。従来はシナリオを 1 問ずつ登録する必要があり、製品の仕様が変わるたびに全部書き直しでした。RAG なら最新のマニュアルを置き換えるだけで、回答も一緒に切り替わります。担当者ごとの当たり外れも消えます。

2 つ目は社内検索です。Slack、Notion、Google ドライブ、社内 Wiki と、情報は置き場所ごとに分断されています。これらをまとめて索引にしておくと、社員は置き場所を知らないまま「去年の同じトラブルはどう対応したか」と話し言葉で聞けます。探す作業が、聞く作業に変わります。しかも返ってくるのはファイルへのリンクだけではなく、その中身をまとめた文章です。

3 つ目は長い文書の要約と分析です。過去 5 年分の顧客要望を読み込ませ、特定の機能への不満が増えていないかと問いかければ、関係する発言だけを集めて傾向をまとめてくれます。人間が全部読む前に当たりを付けられるので、読む範囲を絞る道具として使えます。ただし、拾えていない発言があるかどうかは分かりません。件数を数えるような用途ではなく、どこを読むかを決めるために使ってください。

効きめを決めるのは、資料の手入れ

3 つに共通するのは、答えの質が資料の質を超えないことです。導入して「思ったほど賢くない」となる原因は、たいてい次の 3 つのどれかにあります。

1 つ目は鮮度です。旧版と新版のマニュアルが両方置いてあると、検索はどちらも同じくらい近いと判定します。どちらが正しいかは資料の側からは分かりません。古い版を索引から外す運用が要ります。

2 つ目は重複です。似た内容の資料が何本もあると、検索結果が同じ話で埋まります。上位 5 件が全部同じ内容の別ファイル、という状態になり、本当に必要な別の記述が押し出されます。

3 つ目は形式です。表がレイアウト崩れのまま入った PDF や、スキャン画像だけの資料は、そもそも文章として読み取れていないことがあります。読み込んだ結果を一度そのまま表示して、人が読める状態になっているかを確かめてください。Markdown のように構造がはっきりした形に直しておくと、それだけで回答が変わります。

まず自分の手元にある資料を 10 件選び、この 3 点で見直してみてください。仕組みを作り込むより、先にここを直すほうが効くことがよくあります。