業務水準適応に向けたRAGの論点

前回の記事では、RAG（Retrieval Augmented Generation）を用いてLLMから独自データを含めた回答を可能とする仕組みを解説した。今回はいよいよRAGの業務水準への適応に向けた論点に言及する。

なお、本文中の意見に関する部分については、筆者の私見であることを、あらかじめお断りする。

また論点への言及においては、「知識を拡張した生成AIから回答を得ること」に直接影響する内容のみを対象とし、人材や開発環境などのリソース調達、およびVector Store（データベース）の非機能要件などの間接的なものは除外している。

RAGの実用化で考慮すべきポイントは主に下記の3点に分類できる。これらは通常のLLMの利用と比較した場合に、RAGにのみ存在するプロセスである「データの検索」「検索結果の選定」「検索結果を加味した回答の生成」にフォーカスしたものである。

※かっこ内の論点IDは本記事のダウンロード資料（rag-ai-03.pdf）と同一である。本記事では主要な論点のみに触れ、詳細はダウンロード資料にて補足しているため、併せて参照頂きたい。なお、「d」はデータ準備の論点、「a」はアプリケーションの論点を意味する。

• プロンプトの意図に沿ったデータ検索の実行
  RAGではデータの検索結果を回答生成の入力として用いる。インターネットでの検索と同様、データ検索の結果およびLLMの回答が意図しないものであれば、ユーザーは言葉を変えて検索の試行を繰り返すことになり、最後には離脱してしまう。
  従って、当該ユースケースにおいて必要なデータが十分に準備されており（d1）、検索結果（順位）が適切に取得できること（d6、d7）が重要となる。
  
  
• 回答の生成に必要な検索結果の選定
  取得したデータの検索結果はLLMに入力することになるが、その際の対象の選定方法（a1、a2）や件数（a3）も重要な論点である。
  例えば、過去の販売実績を参考に新しい製品・サービスの開発のポイントが知りたい場合、成功した1製品の情報だけでは不十分である。成功／失敗の別や、特徴の異なる製品の情報をインプットとして回答を生成させた方が、考察を深めるための回答を得ることになる。その点で、LLMに入力する件数、および単純なベクトル類似度の順位以外でのデータ選定は重要と言える。
  
  
• 検索結果を反映した適切な回答の生成
  前段で適切なデータの選定がなされれば、残るはLLMが回答を生成するステップでの論点である。LLMに入力可能な文字数（トークン数）が少ない（d4、a4）場合、十分に検索結果を入力することができず、その結果、回答の質が下がってしまう可能性があるため注意が必要だ。
  また、入力されたデータを正しく解釈し、プロンプトに対して必要な情報を出力するにはモデルの「自力」が重要となる。評価手法を確立し、最適なモデルを選択したい（a5）。
  
  以降、IDの附番された各個別論点について掘り下げるが、理解のため各論点の在り処をデータ準備フロー・アプリケーションの処理フローと紐づけて図示しておく。

d1．ユースケースに適したデータの準備
質問への回答を行う際、知識=データが必須となることから、RAGにおいても「ユーザーの質問に回答するため」のデータ準備が重要となる。

RAGでは旧来のキーワード検索とは異なり、（1）ベクトル検索*を行い、（2）最終的な回答はLLMが行うため、それらを考慮したデータの準備を行うべきである。

*精度の向上を目的とした検索手法であり、単純なキーワード検索では実現できない同義語の解釈やコンテクストも加味した検索を可能とする。RAGで用いるデータ、および検索時に入力されたプロンプトを「方向と長さを持った多次元のベクトル」に置き換えることで、2つのベクトルの類似度を計算する手法を用いる。

d6．適切なベクトル次元数の選択
検索の際に用いるベクトルは、x・y・z軸の3次元程度のものではなく、数千以上もの高次元なベクトルになる。次元数は個々のデータの分類軸と考えることができ、一般的に多いほどデータの違いが解釈でき、検索の精度は高まるとされる。

次元数を増やすと検索の速度は低下するなどのトレードオフもあるため、バランスをみて調整したい。