LLMの長文読解に有利なのはRAGかコンテキストか?

解説

LLMに長文を理解させる際のアプローチとして、知識を溜め込んでいるベクトルデータベースから情報を取ってくるRAG(Retrieval Augmented Generation)と、一つのコンテキストに全ての情報を詰め込むLCW(Long Context Window)の二つがあります。これらにはそれぞれメリットとデメリットがあります。

RAGLCW
コスト・速度線形増加指数関数的増加
実装難度少し面倒単純
検索精度ベクトル同士の距離に依存するLost in the Middle問題がある
知識を更新するためにデータベースの操作が要るテキスト編集だけ
複数の知識の参照苦手得意

RAGの特徴

コスト効率が高いです。後述しますが、LCWではコンテキストが大きくなるにつれて指数関数的に計算量が増加しますが、RAGは知識の項目が増えても計算量は線形の増加にとどまります(一次関数的)。レイテンシの小ささもこれに由来します。

知識の検索に失敗することがあります。文脈的に同じことを言っているがベクトルにすると互いに遠い、といった場合、検索に引っかかりません。また、複数の知識を統合して答えなければならない問いに弱いです(A社とB社の共通取引先を教えて、など)。
知識に変更があった場合ベクトルデータベースに保存されているデータをいちいち削除・追加しなければなりません。テキストエディタでさっと修正してコンテキストに突っ込むだけのLCWよりも少し面倒です。

LCWの特徴

RAGのような検索失敗はありません(別の要因で失敗することはあります)。コンテキストをそのまま突っ込むので、文脈的に同じことを言っていればよしなに応答してくれますし、複数の知識を統合して答えることもできます。
そして何より実装が楽です。コンテキストに知識をそのまま詰め込めばいいので。

こちらも知識の検索に失敗することがあります。Lost in the Middle問題といって、コンテキストの真ん中あたりに書かれている情報を無視しやすいという特徴があります。自作の小説を読ませて中盤あたりに書かれていることを尋ねたら、見事に「そんなシーンはない」と言われました。ちょうど人間も同じように、最初に聞いたことと最後に聞いたことを強く覚えていますね(系列位置効果)。

また、コンテキストに全ての知識を詰め込むということは、コンテキストが膨大になるということです。コンテキストが増えたとき、コンテキスト全体を処理するのにかかる計算量は指数関数的に増加しますから、コンテキストを増やすほど極端に生成に時間がかかるようになります。

どちらも知識を拾えないことがある

RAGは結構検索に失敗します。知識の記し方や検索結果の提示方法などを改善すれば幾分良くなりますが、根本的な解決にはなりません。またLCWのLost in the Middle問題も深刻で、どうしても知識の見落としが発生します。そしてこれはコンテキストが大きくなるほど顕著に現れます。

RAGとLCWのハイブリッドも作れる

まずRAGに知識を登録する際に、細かく区切らず大きな塊で、しかも文章の最初と最後に特に重要な情報を偏らせて記述した状態で登録します。そして多すぎない文量の検索結果をLLMに提示して回答させるといった具合です。
知識が細分化されすぎてベクトル検索が不利になる問題も、Lost in the Middle問題もこれで緩和できます。実装と運用は面倒です。
ただ、先程例に挙げた「A社とB社の共通取引先を教えて」というようなリクエストでは、tool callでLLMにデータベースを検索できるようにさせておくという方法がベストな気がします。つまり扱いたい問いやクライアントの性質によってケースバイケースで対応するしかありません。

コメント

タイトルとURLをコピーしました