実運用におけるRAG：アーキテクチャと最も故障しやすい箇所

RAGとは、トレーニング時の曖昧な記憶に頼るのではなく、手元の資料に基づいて回答のパターンを抽出する手法です。基本的なアーキテクチャは4つのステップしかありませんが、各ステップにはそれぞれ独自の落とし穴があります。

4つのステップと、それに対応する落とし穴

1. 文書の切り取り。 固定文字数で切り分けるのは最もよくある間違いです。これにより、文が途切れたり、表が見出しから切り離されたり、コードが2つに分割されたりします。意味的な区切り（見出し、段落、箇条書き）に沿って切り分けるべきです。また、必ず親文脈（少なくとも文書のタイトルと見出しの連なり）を添付してください。

2. ベクトルへの埋め込み。ベトナム語を処理する多言語埋め込みモデルの性能はまちまちです。一般的なランキングを鵜呑みにせず、自身のデータで実際に検証すべきです。

3. 検索。これが決定的な段階です。ベクトルのみを使用すると、固有名詞、エラーコード、製品コードの検索では劣ってしまいます。キーワード検索とベクトル検索を組み合わせ、結果を統合すると、ベクトルのみを使用する場合よりも、ほぼ常に優れた検索順位が得られます。

4. 回答を生成する。段落を入れすぎると、回答の質が低下してしまう。むしろ、20個の段落を用意し、ランク付けモデルを使ってその中から最適な4つを選ぶほうがよい。

長いコンテキストウィンドウにはRAGが削除されるか

いいえ、3つの実用的な理由があります。各質問に大量の資料を詰め込むと、呼び出しごとにコストがかかります。文脈の量が増えるにつれて遅延も増大します。また、長い文章の中に埋もれた情報に対する注意の質は、その情報を選別して提示された場合よりも低くなります。

長い文脈はRAGの処理を楽にしてくれます――より多くの段落を取り入れることができるようになります――が、RAGに取って代わるものではありません。

何を測定するのか

ほとんどのチームは最終的な答えしか評価しません。これを分けて考えましょう：検索の段階で答えを含む段落を見つけられたか、生成の段階でその段落を正しく使用できたか、という2点です。ほとんどの場合、前者の指標の方が後者よりも悪い結果となります。