RAGと外部知識

モデルが知らないことは、2種類ある

大規模言語モデルは、学習に使ったテキストの範囲でしか物を知りません。ここから、業務で必ずぶつかる2つの壁が生まれます。

1つ目は学習データのカットオフです。モデルの学習には終わりの時点があり、それより後に起きたことは学習に含まれていません。昨日発表された制度改正について尋ねても、モデルは知らないまま、それでも何かもっともらしい答えを返してきます。

2つ目は社内文書を知らないことです。自社の就業規則、製品マニュアル、過去の見積書、顧客とのやり取りは、当然ながら公開テキストの中にありません。どれだけ賢いモデルでも、社内独自の運用ルールを言い当てることはできません。

この2つに共通するのは、モデルの賢さではなく持っている情報が足りないという点です。だから対処も、もっと賢いモデルに変えるのではなく、必要な情報を渡す方向になります。

検索してから答えさせる

RAG (Retrieval-Augmented Generation、検索拡張生成) の発想は素朴です。答えさせる前に、根拠になりそうな文書を検索して探し出し、その文書をプロンプトに貼り付けてからモデルに答えさせます。手順は次の流れです。

1. あらかじめ社内文書を細かく分割し、それぞれを埋め込みベクトルに変換して保存しておきます
2. 利用者の質問が来たら、質問文も同じ方法でベクトルに変換します
3. 質問のベクトルと近い位置にある文書の断片を、上位から数件取り出します
4. 取り出した断片と質問文をまとめてプロンプトに組み立て、モデルに渡します
5. モデルは渡された文書を読んだうえで回答を作ります

重要なのは、モデルそのものは一切変わっていないことです。パラメータは書き換わらず、学習も起きません。変わったのは、モデルに渡す入力に読むべき資料が同梱された点だけです。

支える部品は3つです。

従来のキーワード検索は文字列の一致で探すため、「有給」で検索すると「年次有給休暇」の記述は見つかっても「休みの申請」と書かれた箇所は取りこぼします。埋め込みによる検索は意味の近さで探すので、言い回しが違っても拾える点が強みです。チャンク分割の粒度は実務でよく悩む点で、断片が大きすぎると関係のない記述までプロンプトに入って注意が散り、小さすぎると文脈が切れて回答の役に立ちません。章や節の区切りを尊重しつつ、前後を少し重ねて切るのが定石です。

検索が外せば、回答も外れる

RAG は万能ではありません。試験でも実務でも、限界の理解のほうが問われます。

• 検索が外せば回答も外れます。関係のない文書を拾ってきた場合、モデルは渡された資料に沿ってもっともらしく誤答します。RAG の品質は、生成の品質である前に検索の品質です
• 根拠のない断定は残ります。渡した資料に書かれていないことを、モデルが文脈から補って言い切ってしまうことがあります。ハルシネーションは減らせても、ゼロにはなりません
• 元の文書が古ければ古い答えが返ります。RAG は検索先を新しく保つ運用とセットで初めて意味を持ちます
• 権限の管理が要ります。誰でも検索できる状態にすると、閲覧権限のない文書の内容が回答に混ざる事故が起きます

出典を回答に添えさせる設計が広く使われるのは、これらの限界を人が確認できるようにするためです。

試験ではこう出る

• 「社内文書を参照して回答させたい」「最新情報を反映したい」というシナリオはほぼ RAG が答えです。ファインチューニングと並べて迷わせてきます
• 「RAG はモデルのパラメータを更新するか」という正誤問題が出ます。更新しない、が正解です
• 「文書を検索しやすい大きさに分割すること」を問う形でチャンク分割の語が出ます
• 「RAG を導入すればハルシネーションは完全になくなる」という言い切りの選択肢は誤りです。完全、必ず、ゼロという語は、この分野では誤答の合図になりがちです