RAGの精度、どう改善する？AIアシスタント「たまちゃん」の改善事例 vol.3

前回の記事「RAGの精度、どう改善する？AIアシスタント「たまちゃん」の改善事例 vol.2」では、たまちゃんの精度を向上させるために行った取り組みの一部をご紹介しました。

今回は、以下の施策について、その目的、実施内容、そして結果をご紹介します。

RAG（検索拡張生成）の精度改善にご興味のある方の参考になれば幸いです。

RAGシステムでは、ユーザーからの質問に関連する情報を効率的に検索し、LLM（大規模言語モデル）に提供するために、ドキュメントを事前に小さな単位に分割して（チャンキングして）保存します。この分割された個々の情報単位を「チャンク（chunk）」と言います。

では、なぜチャンクサイズの調整が重要なのでしょうか。それは、チャンクサイズが不適切だと、以下のような問題が発生する可能性があるからです。

このように、RAGシステムの性能を最大限に引き出すためには、コンテンツの特性に応じてチャンクサイズを適切に調整することが不可欠です。

本施策では、たまちゃんの精度と費用のバランスの取れたチャンクサイズを明らかにすることを目的としてチャンクサイズの検証を行いました。

チャンク分割にはいくつかの手法が存在します。代表的な手法を表1にまとめました。

たまちゃんでは、シンプルで実装が容易な固定長チャンキングを採用しています。

固定長チャンキングを用いる際、隣接するチャンク間で一部の情報を重複させる「オーバーラップ」というテクニックがあります。 例えば、あるチャンクの末尾部分を、次のチャンクの先頭部分にも含めるようにします。これにより、チャンクの境界で情報が完全に途切れてしまうことを防ぎ、文脈の連続性を保つ効果が期待できます。

たまちゃんではAzure AI Searchの機能を利用し、このオーバーラップを持たせた形でチャンク分割を行っています。

従来のたまちゃんでは、チャンクサイズを900文字、オーバーラップを100文字として設定していました。 今回の検証では、まず適切なチャンクサイズの目安を探るため、情報ソースであるGoogleサイトとSlackのドキュメント1ページあたり（Slackの場合は1スレッドあたり）の文字数を調査しました。（Google Drive内のファイルは、形式やページ数が多岐にわたるため、今回の初期調査対象からは除外しました。）

調査結果は以下の通りです。

この結果から、特にGoogleサイトの平均文字数を参考に、以下の4種類のチャンクサイズで精度を比較検証することにしました。

オーバーラップについては、各チャンクサイズの3割程度に設定しました。

各チャンクサイズで評価した際の、平均トークン数、料金、評価データに対する正解率を比較しました。結果は以下の表の通りです。

(*1)評価データでRAGフロー全体を実行した際の入力トークン数から算出
(*2)(*1)の入力トークンから算出（出力トークンは計算対象外）

検証の結果、チャンクサイズを3000文字（オーバーラップ900文字）とした場合に、評価データに対する正解率が最も高くなりました。

チャンクサイズを調整したことで、従来よりも詳細かつ適切な情報を提供できるようになった事例が見られました。

変更前は住所変更の手順1から4のみが提示されていましたが、変更後は手順1から6まですべての手順を提示できるようになり、住所変更の場合の手順や入力項目についても具体的に案内できるようになりました。

現在、たまちゃんではRAG（Retrieval Augmented Generation）の検索エンジンとして、Azure AI Searchを採用しています。また、Azure AI Searchでは3種類の検索方式（全文検索、ベクトル検索、ハイブリッド検索）を組み合わせて検索を行っています。

特にベクトル検索では、埋め込みモデルを使って、テキストをベクトル（数値）に変換することで、検索クエリに類似度が高いドキュメントを検索しています。

現在は、Azure OpenAI Serviceで提供されている「text-embedding-ada-002」というモデルを使用していますが、このモデルはOpenAIが2022年に発表した少し古いモデルとなっています。その後、OpenAIは2024年に新しい埋め込みモデルを2種類発表し、これらのモデルがAzure OpenAI Serviceで利用可能になっています。

そこで今回は、図4のように、ベクトル検索に使用する埋め込みモデルを「text-embedding-ada-002」から新しい埋め込みモデルに変更することで、たまちゃんの回答精度がどれだけ良くなるかを検証することにしました。

現在、Azure OpenAI Serviceでは、表4に記した3種類の埋め込みモデルが利用可能となっています。この内、「text-embedding-ada-002」は「text-embedding-3-small」または「text-embedding-3-large」への移行が推奨されています。

※モデル呼び出し時のパラメータで、出力されるベクトルの次元数を指定可能

「text-embedding-3-small」と「text-embedding-3-large」は、従来の埋め込みモデルと異なり、出力されるベクトルの次元数が指定可能なモデルとなっています。これはマトリョーシカ表現というフレームワークを活用して学習が行われたモデルであるためです。マトリョーシカ表現で学習されたモデルは、出力されるベクトルの内、先頭の一部だけ切り出しても、大まか情報が得られるようなベクトルを出力するようになります。

マトリョーシカ表現学習のコンセプトは、「ベクトルの前半に大雑把な情報、後半に詳細な情報が含まれているようなベクトルを作る」ことです。図5は、マトリョーシカ表現学習で作成されるベクトルのイメージとなります。全次元のベクトルでは完全な情報が得られますが、先頭から一部切り出したベクトルだけでも大まかな情報を得ることができます。

次に、マトリョーシカ表現学習でどのようにモデルの学習を行うかをざっくりご紹介します。マトリョーシカ表現学習は図6のような流れでモデルの学習を行います。

真ん中の灰色の縦棒が全次元のベクトルとなっており、黄色の縦棒が半分の次元数のベクトル、青色の縦棒が¼の次元数のベクトル、オレンジ色が⅛の次元数のベクトルとなっております。

従来のモデル学習では、灰色の縦棒の全次元のベクトルに対してのみ損失（正解データとモデルの予測結果の誤差）を計算し、モデルのパラメータを更新していました。

しかし、マトリョーシカ表現学習では、灰色の縦棒の全次元のベクトルだけでなく、黄色の縦棒の半分の次元数のベクトル、青色の縦棒の¼の次元数のベクトル、オレンジ色の⅛の次元数のベクトルに対しても損失を計算し、モデルのパラメータを更新します。これにより、学習後のモデルは、マトリョーシカ表現学習のコンセプトである「ベクトルの前半に大雑把な情報、後半に詳細な情報が含まれているようなベクトルを作る」ようになります。

OpenAIの発表「新しい埋め込みモデルと API の更新」によると、「text-embedding-3-small」と「text-embedding-3-large」は従来の「text-embedding-ada-002」よりも精度が高いと報告されています。

例えば、表5のように、MIRACLE（多言語での情報検索タスク）とMTEB（埋め込みモデル評価用の8つのタスク）における平均スコアは、どれも従来の「text-embedding-ada-002」を上回るスコアとなりました。特にMIRACLEでは平均スコアが大幅に上昇しました。

（出典：「新しい埋め込みモデルと API の更新」）

また、表6のように、「text-embedding-3-small」と「text-embedding-3-large」から出力されるベクトルの次元数を小さくした場合においても、従来の「text-embedding-ada-002」より精度が高いと報告されています。

（出典：「新しい埋め込みモデルと API の更新」）

「text-embedding-3-small」は、ベクトルの次元数をデフォルトの⅓に削減しても従来の「text-embedding-ada-002」より精度が高いです。また、「text-embedding-3-large」は、ベクトルの次元数をデフォルトの1/10に削減しても従来の「text-embedding-ada-002」より精度が高いです。

たまちゃんではAzure OpenAI Serviceで利用可能なOpenAIの埋め込みモデルを採用していますが、世の中にはOpenAI以外にも、様々な企業や団体が埋め込みモデルを公開しています。Azure OpenAI Serviceを採用していないケースでは、表7に記載したモデルが活用できると考えられます。

たまちゃんのベクトル検索で使用している埋め込みモデルを変更した場合の精度は、表8のようになりました。

まず、「text-embedding-3-small」に変更した場合は、現行のモデルよりも精度が下がりました。これは正解を含むドキュメントがベクトル検索で上手くヒットしなくなった結果、回答できなかったケースが増えたためです。実際、これまで3位や4位で検索にヒットしていたドキュメントが、10位以下になってしまう場合があることも確認できました。

次に、「text-embedding-3-large」に変更した場合は、現行のモデルと同じ精度になりました。精度向上しなかった要因としては、ベクトル検索の後に、より強力で精度向上に寄与しやすい検索手法（ハイブリッド検索とセマンティックランカー）を適用していることで、埋め込みモデルによるベクトル検索の差が現れづらかったことが考えられます。

また、「text-embedding-3-large」では、生成されるベクトルの次元数が増えるため、Azure AI Searchに登録されるベクトルデータのサイズが現行の約2倍になることも確認しました。 なお、「text-embedding-3-large」は、現行の「text-embedding-ada-002」よりも大きいモデルですが、検索速度の低下は感じられませんでした。

以上の検証結果から精度の違いはほとんどありませんでしたが、Azure側で移行を推奨されている点も踏まえ、「text-embedding-3-large」への切り替えを決定しました。

今回の記事で紹介した2つの施策の結果を表9にまとめました。

今回の記事では、「チャンクサイズの調整」と「埋め込みモデルの最新化」という2つの施策についてご紹介しました。

「チャンクサイズの調整」では、チャンクサイズを3000文字、オーバーラップを900文字に設定することで、評価データに対する正解率を9ポイント向上させることができました。これにより、従来よりも詳細かつ適切な情報を提供できるようになった事例も見られました。

「埋め込みモデルの最新化」では、現行の「text-embedding-ada-002」と比較すると正解率はほぼ変わりませんでしたが、Azureが推奨している新しい「text-embedding-3-large」への移行を決定しました。

改善事例vol.2の時点から評価データを見直したことにより、ベースラインとなる正解率は変動していますが 、今回ご紹介した施策によって着実に改善を進めています。以降の取り組みについては、本コラムで順次紹介する予定です。

最後までお読みいただき、誠にありがとうございました。

本記事に記載されているロゴ、システム名称、企業名称、製品名称は各社の登録商標または商標です。