RAG is Dead. Long Live RAG!
以下の記事が面白かったのでまとめます。ベクトルデータベースのQdrantのポジショントークな面もありますが、読んでみてください。
RAGは死んだ。RAG万歳！
Anthropic社やGoogle社は、LLMのコンテキストウィンドウを拡大することでベクトル検索が不要になると主張しています。
「ベクトル検索は死んだ。LLMはより正確になり、もはやRAGを必要としなくなるだろう」
しかし、これは現実的な解決策ではありません。コミュニティはすでにGemini 1.5のストレステストを行っています:
より大きなコンテキストウィンドウは、計算リソースを消費し、処理時間を遅くします。LLMの実行には膨大な計算と記憶が必要です。また、応答に30秒も待つ人はいません。
1. Context stuffing is not the solution
コンテキストに依存することは高価で、実世界のアプリケーションでは応答品質が向上しません。LLMだけに頼って検索と精度を完璧にするのは間違いです。大きなコンテキストウィンドウでは、関連情報に集中しにくく、エラーやハルシネーションのリスクが高まります。
GoogleのGemini 1.5は、短いコンテキストではGPT-4よりも有意に正確ですが、再現率は0.8を下回っています。60〜80％の再現率では不十分で、最大40％の情報が失われます。
ベクトル検索の目的は、アプリケーションに必要な情報を効率的に選択することで、このプロセスを回避することです。ベクトルデータベースは、計算負荷を低く抑え、クエリ応答を高速に保ちます。Qdrantのベンチマーク結果は、精度と効率性を強く支持しています。
2. Vector search in compound systems
AIの将来は慎重なシステムエンジニアリングにかかっています。Databricksの結果では、LLMアプリケーションの60％がRAGを、30％がマルチステップチェーンを使用しています。
Gemini 1.5でさえ、複雑な戦略の必要性を示しており、90％の精度を達成するためにモデルを32回呼び出す必要がありました。これは、基本的な複合配置がモノリシックモデルよりも優れていることを示しています。
ベクトルデータベースは複合システムのニーズに完全に適合し、LLMのより優れたアプリケーションの可能性を開きます。それは、より高速で正確であり、実行コストが安いためです。
RAGの主な利点は、LLMが最新の内部および外部の知識ソースからリアルタイム情報を取り込むことができ、新しい情報に対してより動的で適応性が高くなることです。
3. Qdrant scales to enterprise RAG scenarios
エンタープライズ環境でRAGを使用する場合、LLMだけに頼ると膨大なコストがかかります。1つの質問につき1ドルもの費用がかかる可能性があります。一方、ベクトル検索クエリはLLMによるクエリよりも少なくとも1億倍安価です。
ベクトルデータベースの唯一の先行投資はインデックス作成ですが、セットアップ後はQdrantの機能を活用して容易にスケーリングできます。これにより、ベクトル検索への依存度を高め、計算量の多いLLMの使用を最小限に抑えることができます。
RAGは、企業の独自の高価値な知識を活用するための方法であり、LLMをライティングアシスタントとして使用することで、コストを大幅に削減できます。巨大な汎用モデルを使うよりも、小さなオープンソースモデルを使う方が経済的です。
Qdrantは、マルチテナンシーやシャーディングなどの機能により、エンタープライズRAGシナリオに容易にスケーリングできる、代替不可能なソリューションです。
4. Long Live RAG
LLMが膨大な計算能力を必要とし続ける中、ユーザーはベクトル検索とRAGを活用する必要があります。
Qdrantのベクトルデータベースは、スケーラブルでビジネスフレンドリーな製品であり、Unix哲学に従って戦略的に機能を開発しています。Qdrantは、顧客が適切と思うあらゆる方法で使用できるようにすることを目的としています。
大企業が生成型AIを本番環境にリリースする際、最高の品質の応答を維持しながらコストを管理する必要があり、Qdrantにはそれを実現するツールがあります。Qdrantは、RAG、セマンティック検索、非類似性検索、レコメンデーション、マルチモーダリティを通じて、旅を続けていきます。
この記事が気に入ったらサポートをしてみませんか？