RAGとは？AIに社内文書を読ませても、精度が上がらない理由

社内の規程やマニュアルをAIに読み込ませ、質問すると答えが返ってくる。こうした仕組みをRAG（Retrieval-Augmented Generation／検索拡張生成）と呼びます。生成AIを社内で使う方法として、RAGを検討する企業が増えています。

ただ、実際に入れてみると期待した精度が出ないという相談を多くいただきます。例えば、去年の規程を根拠に答えてしまう、部門の内部資料を全社の資料として返してしまう、といった誤りが起きます。そのため、利用者はAIの回答をそのまま使えず、結局は元のマニュアルを開いて確かめ直すことになります。

この記事では、弊社の事例をもとに、RAGの仕組みと、精度が上がらない原因、AIを選ぶ前に決めておくべきポイントを解説します。

RAGとは（検索拡張生成の仕組み）

RAGとは、質問が届くたびに関連しそうな文書を自社の資料から探し出し、その文面をAIに渡したうえで答えさせる仕組みです。AIは自分が学習して覚えている知識ではなく、検索した内容をもとに回答を生成します。

処理は大きく二段階に分かれます。前半で質問に関連する文書を探し出す部分を検索側、後半で取り出した文面から回答を組み立てる部分を生成側と呼びます。回答の精度が出ないときは、検索側と生成側のどちらに原因があるのかを先に切り分ける必要があります。

RAGと社内検索・ファインチューニングの違い

似た言葉と混ざりやすいため、違いを整理しておきます。

• 一般的な検索は、質問に関連しそうな文書の一覧を返します。
• ファインチューニング（追加学習）は、AI自身に社内の内容を覚え込ませる方法です。参照したい文書に変更があるたびに、追加で学習を実施する必要があります。
• RAGは、資料を検索して、その内容をもとにAIが回答を生成します。そのため、規程を差し替えた翌日から新しい内容で答えられます。

RAGの精度が上がらないまま運用に入るとどうなるか

一度でもAIが古い規程を根拠に答えると、担当者はAIを信用しなくなります。逆に、確認されないまま使われた場合は、誤った情報のまま業務が進んでしまいます。

どちらにしても、社内には「生成AIは使えなかった」という印象が残り、次の企画が通りにくくなります。

RAGの精度が上がらない3つの原因

弊社が相談を受けてご支援する中で見えてきた原因は、大きく3つでした。いずれもAIモデルそのものの精度ではなく、その手前で起きています。

1. 複数の利用ケースで必要なデータを、1つのデータストアに格納している

RAGでは、文書をそのまま渡すのではなく、いくつかの断片に区切り、ベクトル形式にして保存します。この区切りをチャンク分割と呼びます。質問が届くと、断片の中から近いものが選ばれてAIに渡されます。

社内の文書をすべて1つのデータストアに入れる必要はありません。旅費規程を引く問い合わせと、情報システムの手順を引く問い合わせでは、探す先も利用ケースも違います。違うのであれば、分けて構いません。1か所にまとめるほど、関係のない文書が候補に混ざります。

それでも、使いみちが決まっているなら、その単位で分けておくことは効果があります。出張精算なら旅費規程の別表まで、経費精算なら経理規程まで、1回の質問で知りたい範囲をひとまとまりにします。

2. 同じ題名の文書が、複数のバージョンで残っている

共有フォルダを開くと、「就業規則」「就業規則_改定版」「就業規則_最終」といったファイルが並んでいることがあります。人はファイル名の末尾や置き場所から新しいものを見分けます。しかしAIに、その見分けはつきません。どの版も本文の中身が似ているため、質問との近さ（類似度）に差が出ず、たまたま最も近かった1件が選ばれます。それが3年前の版であれば、古い内容のまま回答が返ります。

文書に部門・版・施行日といった属性を記載する、あるいは古い版を削除する。こうしたデータマネジメントが必要になります。

相談を受けたときに私たちが最初に確認するのも、AIの種類ではなく、データがどう分類されているかです。

3. 根拠が見つからないときも、答えを作ってしまう

検索側が探し出しに失敗しても、生成側は止まりません。渡された文面が的外れでも、読み取れる範囲でもっともらしい文章を組み立ててしまいます。一般論としては正しい内容を自社の規程として書いてしまうため、最も見つけにくい誤りになります。

出典が付いていない答えは、読んだ側から確かめようがないため、結局は元の文書を開き直すことになります。

着手前に決めておくこと

弊社ではまず、データを整備し、利用スコープを整理し、成果をどう測るかを決めます。いずれもAIモデルを選ぶ前に決められる内容です。

データの整備

検索側が扱えるように、文書そのものと、その置き場を整えます。

• ユースケース単位でデータストアを分ける。出張精算と情報システムの手順のように、探す先が違う問い合わせは、検索する範囲をそれぞれに限定します。1か所にまとめないことで、関係のない文書が候補に混ざらなくなります。
• 答えの単位で区切る（チャンク分割の設計）。見出し・条番号・別表を手掛かりに、そこだけ読めば答えになる長さで区切ります。
• 文書に属性を付ける（メタデータの付与）。文書種別・部門・版・施行日・社外に出してよいかの5つを決めると、探す前に候補を絞れます。旧版を削除できない場合は、参照対象から外す印を付けます。

利用スコープの整理

すべての業務を対象に、すべての社内資料の検索精度をすぐに上げることは、難易度がとても高くなります。対象の業務が絞られていれば、必要な文書の量も、探し方も定義しやすくなります。「社内のことなら何でも答えるAI」ではなく、「情報システム部門のヘルプデスクをAIで支援する」というところまで、目標のスコープを具体化します。

• 対象業務を絞る。効率化しやすいのは、答えが1つに定まり、なおかつ探すのに時間がかかっている業務です。規程の参照、手順の確認、過去の申請内容の照会が当てはまります。判断が必要な質問に当てると、担当者が結局すべてを確かめることになりかねません。
• 答えられる範囲を決める。見つからなければ「分かりません」と返すこと、答えには出典を添えることを、回答の方針として先に決めます。失敗が「間違った答え」ではなく「答えられなかった」という形で表に出ます。

成果を測る

RAGを直したあとに良くなったかどうかを、あとから判断することはできません。

• 評価用の質問を先に集める。まず、現場に実際に届いた質問を、こちらで選ばずに集めます。自動で評価する仕組みを先に作り、変更を一つずつ試します。なお、こちらで選んだ質問で測った数字が本番では再現しない点は、生成AIのPoCと同じです。
• 検索側と生成側を分けて数える。探し出せなかったのか、探し出したうえで答えを外したのか。どちらだったのかが履歴に残る形で、ログを保持します。

まとめ

1. データがAIにとって検索しやすい形で保たれているかを確認しましょう。
   文書の置かれ方と、取り出す単位の設計に課題があることが多いため、モデルを新しくしても結果は変わりません。まず見るべきなのは、データの構造とドキュメントの管理方法です。
2. 業務の対象を絞ってテストしましょう。
   「社内のことなら何でも答えるAI」を目標に置くのではなく、どの業務をどのように解決すれば人的コストが減るのかを整理します。
3. 計測の仕組みを用意し、PoCで精度を検証しましょう。
   現場に実際に届いた質問をもとに、回答にどのくらいの精度が必要なのかという基準を先に設計します。この基準がなければ、良くなったのかを判定できず、検索側と生成側のどちらを直すのかも切り分けられません。

フィード株式会社では、RAGの構築、AIエージェントの開発、AIシステム開発を数多く手掛けています。AIの精度にお悩みの際は、ぜひ一度ご相談ください。