RAGを評価する魔法のツールが登場！トゥルーレンズ + ミルバス =?

データから大規模モデルのアプリケーションまで、開発のヒントを共有する杭州元創会議が 11 月 25 日に開催されました。

大規模言語モデル (LLM) の人気の高まりにより、ベクトルデータベースの軌道が爆発的に進み、ベクトル検索テクノロジが開発者からますます注目を集めています。現在、主流のベクトル検索テクノロジープロバイダーには、ベクトルデータベース Milvus および Zilliz Cloud、ベクトル検索ライブラリ FAISS、および従来のデータベースと統合されたベクトル検索プラグインが含まれます。

同時に、ベクトル検索は検索拡張生成 (RAG) における重要なコンポーネントになりつつあります。RAG ( https://zilliz.com.cn/use-cases/llm-retrieval-augmented-generation ) このタイプの質問と回答のアプリケーションは、生成 AI の重要なエンタープライズレベルのユースケースです。RAG アプリケーションでは、LLM はナレッジベースに簡単にアクセスし、それを質問に答えるためのコンテキストとして使用できます。このアプリケーションを実現する鍵はベクトルデータベースにあります。Milvus は、このアプリケーション専用に設計された拡張性の高いオープンソースベクトルデータベースです。

01.RAGを構築する

効率的な RAG スタイル LLM アプリケーションを構築する場合、最適化できる構成が多数あり、さまざまな構成の選択が取得品質に大きく影響します。利用可能な構成は次のとおりです。

ベクターデータベースの選択

データの選択
埋め込みモデル
インデックスの種類

ニーズを正確に満たす高品質のデータを見つけることが重要です。データが十分に正確でない場合、検索では無関係な結果が返される可能性があります。関連するデータを選択した後、使用する埋め込みモデルも考慮する必要があります。選択したモデルも検索品質に大きな影響を与えるためです。埋め込みモデルがドメイン固有のコンテンツのセマンティクスを理解できない場合、使用されるデータベースに関係なく、検索者は誤った結果を返す可能性があります。コンテキストの関連性は検索品質の重要な指標であり、ベクトルデータベースの選択はこの指標の結果に大きく影響します。

最後に、インデックスタイプはセマンティック検索の効率に大きく影響する可能性があります。インデックスタイプの選択は、大規模なデータセットに直面する場合に特に重要です。さまざまなインデックスタイプを使用すると、ユーザーはリコール、速度、リソース要件の間でトレードオフを行うことができます。Milvus は、FLAT、積量子化インデックス、グラフベースのインデックスなど、複数のインデックスタイプをサポートしています。

検索パラメータの選択

取得されたコンテキストの数 (上位 K)
チャンクサイズ

取得する場合、top-K は取得するコンテキストチャンクの数を制御する重要なパラメータです。トップ K が高いほど、必要な情報を取得できる確率が高くなります。ただし、top-K が高すぎると、回答に無関係な情報が含まれることになります。したがって、単純な質問の場合は、検索パフォーマンスと結果がより良くなるように、一般に、より低い top-K 値を推奨します。

チャンクサイズは、取得コンテキストのサイズを制御します。比較的複雑な問題の場合、チャンクサイズが大きいほど、検索効果は高くなります。単純な質問の場合は、回答に必要な情報がほんの一部であるため、小さなチャンクが最適です。

では、あらゆる状況に対処するのに役立つ絶対的なソリューションと構成のセットは存在するのでしょうか? 答えはいいえだ。データの種類とサイズ、言語モデル、ベクトルデータベースの組み合わせが異なると、パフォーマンス結果も異なります。したがって、評価ツールを使用して、独自の使用シナリオとニーズに基づいて、特定の使用例におけるさまざまな構成の選択肢の品質を評価する必要があります。評価中は TruLens が使用されます。

02.言語モデルアプリケーションの追跡と評価のためのTruLens

TruLens は、RAG などの言語モデルアプリケーションのパフォーマンスを評価するためのオープンソースライブラリです。TruLens を使用すると、言語モデル自体を活用して出力や取得品質などを評価することもできます。

言語モデルアプリケーションを構築するときに、ほとんどの人が最も懸念する問題は AI の幻覚です。RAG は、言語モデルに取得コンテキストを提供することで情報の正確性を保証しますが、完全に正確な情報を提供することが 100% 保証されるわけではありません。したがって、アプリケーションが幻覚を引き起こさないという事実は、検証の焦点を示す重要な指標となります。TruLens は 3 つのテストを提供します。

文脈上の関連性
回答精度
回答の関連性

次に、これら 3 つのテストを 1 つずつ見てみましょう。

文脈上の関連性

すべての RAG アプリケーションの最初のステップは取得です。取得品質を検証するには、各コンテキストブロックが入力クエリに関連していることを確認します。言語モデルはこのコンテキストを使用して回答を生成するため、コンテキスト内の無関係な情報により LLM が幻覚を引き起こす可能性があります。

回答精度

コンテキストを取得した後、LLM は回答を生成します。場合によっては、LLM は真実から逸脱し、正解を誇張または拡張する傾向があります。答えの正確さを検証するには、応答を独立したステートメントに分割し、検索コンテキスト内の各ステートメントのソースを個別に検証する必要があります。

回答の関連性

最終的に、私たちの応答は元の質問に答える必要があり、これは、最終的な応答がユーザーが入力した質問にどの程度関連しているかを評価することで検証できます。

上記 3 つの指標の結果が満足のいくものであれば、知識ベースによる検証の結果、RAG 錯視は解消されたと言えます。言い換えれば、ベクトルデータベースに含まれる情報が正確であれば、RAG が提供する回答も正確になります。

03.具体的な事例

前述したように、RAG 構成の選択は、幻覚の除去に大きな影響を与える可能性があります。以下では、City Encyclopedia の記事に基づいて Q&A RAG アプリケーションを構築し、さまざまな構成の選択がアプリケーションのパフォーマンスにどのような影響を与えるかを示します。構築プロセス中、アプリケーションのフレームワークとして LlamaIndex を使用しました。すべてのコードはGoogle Colab ( https://colab.research.google.com/github/truera/trulens/blob/main/trulens_eval/examples/expositional/vector-dbs/milvus/milvus_evals_build_better_rags.ipynb ) で見つけることができます。

百科事典からデータをロードする

まずデータをロードする必要があります。ここでは、LlamaIndex のデータローダーを使用して、百科事典からデータを直接ロードします。

from llama_index import WikipediaReader


cities = [
"Los Angeles", "Houston", "Honolulu", "Tucson", "Mexico City",
"Cincinatti", "Chicago"
]


wiki_docs = []
for city in cities:
try:
doc = WikipediaReader().load_data(pages=[city])
wiki_docs.extend(doc)
except Exception as e:
print(f"Error loading page for city {city}: {e}")

エバリュエーターのセットアップ

次に、評価器を設定し、前述の 3 つのテストを使用します。

TruLens は、OpenAI、Anthropic、HuggingFace などの特定のモデルを使用した一連のプロンプト評価機能またはフィードバック機能を提供します。

# Initialize OpenAI-based feedback function collection class:openai_gpt4 = feedback.OpenAI()

モデルを設定したら、まずクエリの関連性をテストします。各評価中に、結果をより深く理解するために思考の連鎖を使用します。詳細については、1_with_cot_reason接尾辞で表されるフィードバック機能を参照してください。

この時点で、フィードバック関数に渡すテキストを選択する必要もあります。TruLens は、まずアプリケーションをシリアル化してから、テキストの選択に使用される JSON のような構造にインデックスを生成します。TruLens は、この操作を簡素化する一連のヘルパー関数を提供します。

on_input()フィードバック関数に渡される最初のテキストとして LlamaIndex アプリケーションに渡されるメイン入力を自動的に検索します。
TruLlama.select_source_nodes()LlamaIndex の取得に使用されるソースノードを識別します。

最後に、各文脈上の関連性がスコアに結合されます。この例では、最大値を使用して相関関係を測定していますが、開始プロセス中に平均値や最小値などの他の指標を使用することもできます。

# Question/statement relevance between question and each context chunk.
f_context_relevance = Feedback(openai.qs_relevance_with_cot_reason, name = "Context Relevance").on_input().on(
TruLlama.select_source_nodes().node.text
).aggregate(np.max)

精度設定は同様ですが、統合プロセスは若干異なります。ここでは、各ステートメントの最高精度スコアと各ステートメントの平均精度スコアを取得します。

grounded = Groundedness(groundedness_provider=openai_gpt4)
f_groundedness = Feedback(grounded.groundedness_measure_with_cot_reason, name = "Groundedness").on(
TruLlama.select_source_nodes().node.text # context
).on_output().aggregate(grounded.grounded_statements_aggregator)

回答の関連性に関するフィードバック関数は、入力/出力のみに依存するため、セットアップが最も簡単です。新しい TruLens ヘルパー関数を使用できます.on_input_output()。

# Question/answer relevance between overall question and answer.f_qa_relevance = Feedback(openai.relevance_with_cot_reason,
name = "Answer Relevance").on_input_output()

構成スペースを定義する

データのロードとエバリュエーターのセットアップが完了したら、RAG の構築を開始できます。このプロセスでは、さまざまな構成で一連の RAG を構築し、選択した各構成のパフォーマンスを評価して、最適な構成に到達します。

この場合、さまざまなインデックスタイプ、埋め込みモデル、Top-K、チャンクサイズをテストしました。もちろん、さまざまな類似性タイプ (距離メトリック) や検索パラメーターなど、他の構成をテストすることもできます。

選択を繰り返す

構成空間を定義した後、itertools を使用して各組み合わせを試し、評価します。さらに、Milvus のオーバーライドパラメーターも利便性を提供し、さまざまな構成を簡単に反復するのに役立ちます。それ以外の場合、他のベクトルデータベースを使用している場合は、遅いインスタンス化プロセスを繰り返す必要がある場合があります。

各反復では、ストレージコンテキストを使用してインデックスパラメーターの選択を MilvusVectorStore とアプリケーションに渡します。埋め込みモデルをサービスコンテキストに渡して、インデックスを作成します。

vector_store = MilvusVectorStore(index_params={
"index_type": index_param,
"metric_type": "L2"
},
search_params={"nprobe": 20},
overwrite=True)
llm = OpenAI(model="gpt-3.5-turbo")
storage_context = StorageContext.from_defaults(vector_store = vector_store)
service_context = ServiceContext.from_defaults(embed_model = embed_model, llm = llm, chunk_size = chunk_size)
index = VectorStoreIndex.from_documents(wiki_docs,
service_context=service_context,
storage_context=storage_context)

次に、このインデックスを使用してクエリエンジンを構築できます - 定義top_k:

query_engine = index.as_query_engine(similarity_top_k = top_k)

ビルド後、TruLens でアプリケーションをラップします。ここでは、簡単に識別できる方法で名前を付け、構成をアプリケーションのメタデータとして記録します。次に、評価のためにフィードバック関数を定義します。

tru_query_engine = TruLlama(query_engine,
app_id=f"App-{index_param}-{embed_model_name}-{top_k}",
feedbacks=[f_groundedness, f_qa_relevance, f_context_relevance],
metadata={
'index_param':index_param,
'embed_model':embed_model_name,
'top_k':top_k
})

これはtru_query_engine元のクエリエンジンと同じように実行されます。

最後に、少数のテストプロンプトを使用して評価され、各プロンプトに応答してアプリケーションが呼び出されます。OpenAI API を短期間で迅速かつ継続的に呼び出す必要があるため、Tenacity は指数バックオフ戦略を通じてレート制限の問題を回避するのに役立ちます。

@retry(stop=stop_after_attempt(10), wait=wait_exponential(multiplier=1, min=4, max=10))def call_tru_query_engine(prompt):
return tru_query_engine.query(prompt)
for prompt in test_prompts:
call_tru_query_engine(prompt)

結果

どの構成が最もパフォーマンスがよいでしょうか?

どの構成のパフォーマンスが最も悪いでしょうか?

どのようなタイプのエラーが見つかりましたか?

エラーの 1 つのタイプは、間違った都市情報を取得することであることがわかります。以下の思考連鎖フィードバックからわかるように、RAG はヒューストンではなくツーソンのコンテキストを取得しました。

同様に、RAG が正しい都市を答えても、その答えが入力された質問に関連しておらず、コンテキストなしで取得されるという状況にも遭遇します。

言語モデルは、無関係な文脈に基づいて幻覚を起こし始めます。区別すべきことは、幻覚は必ずしも間違った事実ではなく、それを裏付ける証拠のない模範解答を指すだけであるということです。

さらに、RAG が無関係な回答を返す状況も見つかりました。

04. パフォーマンスをより深く理解する

インデックスの種類

この場合、インデックスの種類はクエリの速度、トークンの使用量、または評価に大きな影響を与えません。これは、データのサイズが小さいことが原因である可能性があります。索引タイプは、大規模なコーパスではより重要になる可能性があります。

埋め込みモデル

text-embedding-ada-002 は、精度 (0.72、平均 0.60) と回答の関連性 (0.82、平均 0.62) の点で MiniLM 埋め込みモデルよりも優れています。この 2 つは、文脈上の関連性の点で一貫しています。この結果は、OpenAI Embedding の方が百科事典情報に適しているためと考えられます。

類似度トップ-K

top-k を増やすと、検索品質がわずかに向上します (文脈上の関連性によって測定されます)。取得されるテキストのチャンクが多いほど、取得者が高品質のコンテキストを取得できる可能性が高くなります。

トップ K の増加により、精度 (0.71、平均 0.62) と回答の関連性 (0.76、平均 0.68) も向上します。コンテキストテキストのより多くのチャンクを取得すると、言語モデルにその結論をサポートするためのより多くのコンテンツが与えられます。ただし、top-K が高いほど、トークンの使用コストが高くなります (呼び出しごとに平均 590 個の追加トークンが必要です)。

チャンクサイズ

チャンクサイズが大きくなると、入力された質問とは無関係なテキストが多く含まれることになり、検索精度が低下します。ただし、チャンクが大きくなるほど、答えをサポートするコンテンツがより多く提供されます。

つまり、チャンクサイズが大きいほど、LLM が結果を返すときにより多くのコンテキストを取得できます。

ブロックが増加すると、さらに 400 トークンを使用する必要があります。

この記事では、インデックスタイプ、埋め込みモデル、トップ K、チャンクサイズなどのさまざまな構成とパラメーターを使用して RAG を構築する方法を学習します。私たちのテストでは、さまざまな構成があり、パラメーターのオーバーライドが可能な Milvus の恩恵を受けました。TruLens で各構成とパラメーターの組み合わせを評価することで、最高のパフォーマンスを発揮するパラメーター構成を迅速に見つけることができます。

試して調べてみたい場合は、まずオープンソースツール TruLens とオープンソースベクトルデータベース Milvus またはフルマネージド Milvus サービス Zilliz Cloud をインストールします。

この記事は元々 The New Stack に掲載されたもので、許可を得て転載しています。