RAGは思ったより簡単：過剰設計を避ける6つのアーキテクチャ
RAG Is Simpler Than You Think
多くのチームがRAGを過剰設計している。埋め込み、ベクトルDB、リランキングに飛びつく前に、まずはBM25などの全文検索から始めるべきだ。本記事では、データの鮮度、コーパスの特性、クエリパターン、スケール、チームのスキルに基づいて、6つのRAGアーキテクチャ（全文検索、クエリ書き換え、ハイブリッド検索、オンデマンド埋め込み、ホット/コールド階層、フル事前埋め込み）を紹介し、それぞれのトレードオフを解説する。さらに、複雑なクエリを分解するエージェント型RAGの利点や、モデル非推奨時のコスト比較も示す。過剰設計を避け、データに基づいて段階的に高度な手法へ移行することを推奨する。
「埋め込みに飛びつくと、すぐに『チャンクサイズは？オーバーラップは？』といった問題に直面する。全文検索なら、これらすべてをスキップできる。ドキュメントはそのままで、検索はただ機能する。」
HNでの議論
203- usernametaken29
以前大規模なRAGシステムに携わったことがありますが、人々は全文検索を過小評価し、埋め込みを過大評価していると痛感しています。全文検索は本当に簡単で、移植性が高く、スケーラブルで、かなりの効果が得られます。80対20の法則が当てはまります。埋め込みは素晴らしく魔法のように見えますが、実際に使い込むと、意味的類似性は思ったほど良くなく、確実に皆を満足させるものではないことに気づきます。結局、より正確な埋め込み検索に対応するために、テキストのチャンクを増やしたり変えたりして再埋め込みする必要が生じ、最終的には再ランキングなどを行うことになり、その間ずっとベクトル検索の運用負荷を支えなければなりません。
それに対して、500のキーワードで検索クエリを構築するのは確かに苦痛ですが、それはただ機能し、すべてのユースケースに対応し、スケールし、全体的に保守の手間が少ないのです。
- alansaber
私はこれらのアプローチをすべて（並行して）使ってシステムを構築したことがあります。ほとんどの場合、高度に最適化されたコーパス固有の情報検索戦略を構築することは、ごく一部の特殊なケースを除けば、労力に見合う価値はありません。技術的な議論の量は、RAGのユースケースをはるかに上回っています。
- jillesvangurp
RAGは基本的に、LLMがクエリを行う昔ながらの情報検索です。これにはベクトル検索も含まれますが、それがなくても機能します。ベクトル検索を、努力なしで検索を素晴らしくする魔法の粉のように扱うのは、必ずしもうまくいきません。また、コストと複雑さが増す可能性もあります。そして、適切にチューニングしなければ、必ずしも良い結果が得られるとは限りません。
RAGの鍵は、できるだけ少ないクエリで適切な情報をコンテキストに取り込むことです。そのためには、再現率（存在する情報が適切なクエリで見つかること）と精度（最良の情報が上位に来て、誤検知を最小限に抑えること）の両方が必要です。
検索、ひいてはRAGにおいても、「ゴミを入れればゴミが出る」という原則が当てはまります。AIやRAG以前に検索チームが行っていたことのほとんどは、今でもRAGのエクスペリエンスを最適化する最良の方法です。そして、それを怠ると、検索はうまく機能せず、どんなにAIを使ってもそれを補うことはできません。あるいは、トークンと時間の多大なコストがかかるだけです。したがって、インデックスするものを前処理するETLパイプラインを持ち、検索品質をテスト・ベンチマークすることなどは、すべて役立ちます。
良い知らせは、これのために半端なものを作るのに、エージェントコーディングのスキルはそれほど必要ないということです。このコードはほとんど自動で書けます。そして、インデックス前に構造を抽出するためのほんの少しの努力でも、大きな違いを生むことができます。
- jrochkind1
LLMが生成したテキストについての、さらに多くのLLM生成テキスト。
LLMが生成したテキストを読むのがますます難しくなっていると感じている人は他にいますか？私はそれを読むのに非常に疲れます。脳がそれを読み通そうとしません。
- Angostura
私は、最初の使用時に頭字語を綴らない怠惰な記事に対して特に反感を持っています。
そこで：https://en.wikipedia.org/wiki/Retrieval-augmented_generation
- yipinwong
その技術を習得した者だけが、その仕事を簡単に見せることができるのです。
これを書いたAIがその達人かもしれません。作家ではなく。これはAIによって書かれたように見えます。
私は著者のエージェントを使います。彼の記事を読んだり、彼を仕事に使ったりはしません。
- refactor_master
さらに簡単な方法があります：最初にすべてを埋め込み、その後変更されたものを追跡します。安価なモデルを使って、ドキュメントやチャットを要約・クリーンアップし、要約とキーワードを付けます。図書館全体の本を埋め込むのでなければ、API呼び出しは数百ドル程度でしょう。
そして、それをすべてBigQueryに入れます。ベクトル関連の処理はすべてネイティブに処理されます。
その上にエージェントボットUIをかぶせて、全知全能で魔法のように見せかけます。
Google以外のベンダーにも、同じようなバッテリー内蔵のアプローチがあり、それをプラグインできると思います。
- klm127
RAGはRetrieval Augmented Generationの略です。目的は、テキストのコーパスを完全一致ではなく意味で検索することです。
調べる必要がありました。