RAGの課題メモ

RAG使ってユーザの質問に回答するチャットボットを作成しようとしている。

業務ドメイン情報は学習させるのではなく、RAGで情報を取得しコンテキストとしてLLMに渡して回答を生成する。

RAGとは

RAGとは、LLM（大規模言語モデル）に対して、外部の知識ベースから情報を検索・取得し、その結果をコンテキストとして与えることで、学習していない内容についても回答を生成させる手法。

RAG使って発見した課題

不完全な情報を無理に一般化する

回答生成のために多岐にわたる外部情報を必要とする場合、RAGで検索するだけでは十分な情報が集まらないことがある。
その際に、部分的にすぎない情報を、それがあたかもすべてみたいな回答をしてしまう。

LLMが意味理解せず鵜呑みにしてしまう

LLMが学習をしていないから、あるいは不十分だから、それを補うためにRAGで外部参照させている。
なのでRAGで取得した文書の内容をLLMは意味理解できず、鵜呑みにして回答してしまう。

ではどうしたらいいのか？
大別すると2つのアプローチがあると思っている。

①LLMにコンテキストとして渡す情報の品質を上げる
②LLMがRAGから取得したデータを意味理解できるようにする

①LLMにコンテキストとして渡す情報の品質を上げる

検索の仕組みとして工夫できそうなことをいくつか列挙する。
（チャンク分割の最適化などは当然やるとして）

GraphRAGで構造的に検索

GraphRAGにすれば、ドキュメント間の関係性をグラフ構造で保持できて、構造的に検索できるようになる。
※試していないがどうやら検索に時間がかかるらしい。検証してみる。どうやらFastGraphRAGなんかが良いらしい。

メタデータ付き検索

文書にタグやカテゴリなどのメタデータを付与して、属性で検索できるようにする

ハイブリッド検索

ベクトル検索と全文検索を組み合わせて情報の拾い漏れを防ぐ。クエリに含まれる文字列の傾向によっては有効。

②LLMがRAGから取得したデータを意味理解できるようにする

いっそLLMがRAGから取得した情報を概念的にある程度理解できれば良い、というアプローチもある。
RAGを使用するという選択肢がある時点で、大規模な再学習などは、プロジェクト的には最初から対象外であろうと思うので、現実的なラインでLLMに意味理解させてみたい。

ファインチューニング

RAGで取得される文書そのもの、ないしRAG内に記述されている業務ドメイン情報に関する解説を入力にしてファインチューニングをするのは良さそう。だけどプロジェクト的には、コストと効果のバランスを判断するのが大変そう

SLM（Small Language Model）

小型のLLMであるSLMに学習させて意味理解できるようにし、高精度な汎用LLMとの多段構成にする。
学習コストもそこまで高くないらしい（ほんとに？試してみたい）

プロンプトに書いちゃう

業務ドメイン情報の説明がそこまで長くならないのであれば、プロンプトに書いちゃうのも手はありそう。（現実的にはそう簡易に説明できる業務ドメイン情報ならわざわざLLMに理解させるまでもなさそうだけど）

GraphRAG

データをナレッジグラフにすることでマルチホップに検索出来たり推論能力が上がったりする。