RAG はあなたが思うよりシンプルです

RAG はあなたが思うよりシンプルです 検索ベースのAIに対する6つのアプローチ、最小限から詳細まで Rafael Pierre 2026年6月10日 23 シェア 最近では、ほとんどの人が RAG スタックを過剰に設計しているように見えます。彼らはすぐに埋め込み、ベクトルデータベース、そしてリランキングパイプラインに飛びつきます。その一方で、ユーザーは単に「パスワードのリセット方法」と書かれたドキュメントを見つけたいだけなのです。 エンジニアリングには、常に適切な問題に対する適切なツールがあります。AI検索システムも例外ではありません。 決定要因 レシピに入る前に、それぞれのアプローチをいつ使うべきかを確立しましょう。主な要因は次のとおりです。 1. データの鮮度要件 - リアルタイム更新（ニュース、ソーシャルメディア）は、再インデックスが容易なアプローチを好みます。日次または週次の更新は、ハイブリッドアプローチに適しています。安定したコーパス（月次または四半期ごとの更新）は、事前埋め込みを可能にします。 2. コーパスの特性 - 高い変化率（毎日10%以上の変更）は、完全な事前埋め込みを避けるべきであることを意味します。安定したドキュメントは、事前埋め込みで問題ありません。ロングテール分布（90%がアクセスされない）は、オンザフライが有利であることを意味します。 3. クエリパターン - キーワード中心のクエリは、フルテキスト検索から始めるべきです。セマンティックまたは会話形式のクエリは、埋め込みから恩恵を受けます。混合パターンは、ハイブリッドアプローチを必要とします。 4. スケールとパフォーマンス - 1日あたりのクエリ数が1000未満の場合は、シンプルなアプローチで十分です。1日あたり1Kから10Kのクエリは、選択的な最適化を必要とします。1日あたり10Kを超えるクエリは、完全な最適化を正当化します。 5. チームの能力 - MLの専門知識がない場合は、フルテキストとクエリ書き換えに留めてください。ある程度のML経験があれば、ハイブリッド検索は管理可能です。MLチームが利用可能であれば、高度なアプローチが実現可能になります。 さて、レシピブックを見てみましょう。上から始めてください。データがそれを必要としていると証明した場合にのみ、下に移動してください。 レシピ1：MVP – フルテキスト検索のみ それは何ですか 古き良き BM25 です。Elasticsearch。Postgres のフルテキスト検索。埋め込みが動詞になる前に存在していたものです。 いつ使うか 始めたばかりのとき。ユーザーはキーワードスタイルのクエリ（「pandas merge dataframe」）を書きます。正確な一致が重要（「請求書 #12345」）。MLの複雑さをゼロにしたいとき。コーパスに独自の専門用語があるとき（これについては後述）。 利点 APIコストゼロ。高速（10ミリ秒未満）。デバッグが容易（ドキュメントが一致した理由を正確に確認できます）。驚くほど効果的（多くのユースケースに対応）。チャンキング戦略は不要 – フルドキュメントで機能します。評価の複雑さはありません – テストと検証が容易です。モデルの陳腐化リスクはありません（BM25 は変わりません）。 欠点 同義語を見逃す（「車」対「自動車」）。セマンティッククエリで失敗する（「〜するにはどうすればよいですか？」）。キーワードを超えた意図を理解できない。 実話 私の経験では、これはかなりの割合のユースケースに対応します。このステップをスキップしないでください。どれだけ進めるかに驚くかもしれません。 なぜこれが過小評価されているのか 埋め込みにすぐに飛びつくと、次のような質問に直面します：チャンクサイズは？（512トークン？1024？）オーバーラップは？（50トークン？100？）セマンティックチャンキングか固定サイズか？チャンキングが良いかどうかをどう評価するか？ フルテキスト検索では、これらすべてをスキップできます。ドキュメントはあなたのドキュメントです。検索は機能します。 レシピ2：エージェントによるクエリ書き換え それは何ですか LLM を使用して、乱雑なユーザークエリをクリーンなキーワード検索に変換します。 洞察 ほとんどの「セマンティック検索」の問題は、実際にはクエリ作成の問題です。 いつ使うか ユーザーが会話形式で質問するとき。語彙の不一致（ユーザーは「バグを修正する」と言い、ドキュメントは「デバッグ」と言う）。社内用語があるとき（あなたのフレームワークは「Atlas」と呼ばれます）。クエリ戦略を迅速にイテレーションする柔軟性を持ちたいとき。 コスト 〜0.001ドル/クエリ（クエリ書き換えに GPT-4o-mini を使用した場合） 魔法 LLM はストップワードを削除できます（「〜するにはどうすればよいですか」は何もなくなります）。同義語を追加できます（「車」は「車 自動車 ビークル」になります）。ドメイン用語を翻訳できます（「コードを高速化する」は「パフォーマンスを最適化する」になります）。複雑なクエリを分解できます（「CSVを読み込んでプロットする」は「CSVを読み込む」、「データをプロットする」になります）。用語集から学習できます（システムプロンプト経由）。 なぜこれが埋め込みよりも柔軟なのか 埋め込みを使用している場合、結果が良くない場合、チャンキング戦略を調整し、コーパス全体を再埋め込みし、評価セットで回帰テストを実行し、それが改善されることを願う必要があります。 クエリ書き換えでは、結果が良くない場合、システムプロンプトを調整します。それだけです。すぐにテストできます。 マルチターンエージェント書き換え さらに良いことに、ループを作成できます： def agentic_search(query, max_iterations=3): for i in range(max_iterations): # クエリを書き換える optimized = query_rewriter.rewrite(query, iteration=i) # 検索結果 results = bm25_search(optimized) # 品質を評価する quality = evaluate_results(results, query) if quality > threshold: return results # エージェントが学習し、再試行する query = refine_based_on_feedback(query, results, quality) return results エージェントは、何も再埋め込みすることなく、イテレーションし、学習し、適応できます。 例：プロプライエタリな用語の問題 あなたの会社に「Atlas」という Python フレームワークがあるとしましょう。汎用埋め込みを使用する場合： 汎用埋め込みモデル（インターネットでトレーニング済み）： 「Atlas」 = [ベクトルが指す先：ギリシャ神話、地図、地理] 実際の Atlas ドキュメント = [データ処理に関するベクトル] 類似度スコア：0.15（ひどい！) モデルはあなたの「Atlas」が存在することを知りません。トレーニングで学習したことにフォールバックします。しかし、クエリ書き換えを使用する場合： system_prompt = """ ドメイン固有の用語（これらを変更しないでください。正確なキーワードとして使用してください）： - Atlas：当社の内部データ処理フレームワーク - Mercury：当社のメッセージングシステム - Zeus：当社の認証サービス これらの用語を正確に保持し、クエリの残りの部分を最適化してください。 """ # ユーザー：「Atlas をバッチジョブに使用するにはどうすればよいですか？」 # エージェント：「Atlas バッチジョブ データ処理 パイプライン」 # BM25：「Atlas」で完全一致 ✓ プロプライエタリな用語の場合、正確なキーワード一致はセマンティック理解よりも優れています。 Lighthouse AI をお読みいただきありがとうございます！新しい投稿を受け取り、私の仕事​​をサポートするために無料で購読してください。 購読 レシピ3：ハイブリッド検索（スパース + デンスリランキング） それは何ですか BM25 を使用して候補（上位50〜100件）を取得し、次に埋め込みでリランクします（上位10件）。 なぜこれが機能するのか BM25 は高速で、キーワード一致に優れています。埋め込みはセマンティック理解に優れています。これらを組み合わせることで、互いの弱点を補い合います。 いつ使うか ユーザーがセマンティックな質問をする場合（「X の代替案を見つける」）。BM25 とクエリ書き換えだけではうまくいかない場合（これを証明するデータがある）。100〜500ミリ秒の遅延を許容できる場合。コーパスが比較的安定している場合（毎分変更されない）。 パイプライン コストの考慮事項 現在の価格（OpenAI text-embedding-3-small、100万トークンあたり0.02ドル）で計算してみましょう： クエリあたり50ドキュメントを埋め込む（平均500トークン/ドキュメント）ということは、50ドキュメント × 500トークン = 25,000トークン コスト：25,000 × 0.00002ドル = 〜0.0005ドル/クエリ。1日あたり1,000クエリ × 30日 = 月額〜15ドル。 実際にはかなりリーズナブルです。しかし、落とし穴があります：遅延。 オンザフライで50ドキュメントを埋め込むと、クエリあたり200〜500ミリ秒追加されます。ユーザー向けの検索では、これは顕著です。ここに本当のトレードオフがあります – コストではなく、速度です。 重要な考慮事項：チャンキングの問題が再浮上 埋め込みを導入すると、ドキュメントをどのようにチャンクするか（固定サイズ？セマンティック？セクションごと？）を決定する必要があります。チャンクサイズとオーバーラップをどのように使用するかを決定する必要があります。重要なコンテキストをまたぐチャンクを処理する必要があります。 これは、純粋なフルテキスト検索が回避する複雑さを追加します。 レシピ4：オンザフライ埋め込み（フレッシュデータプレイ） 洞察 データが頻繁に変更される場合、なぜすべてを再埋め込みするためにお金を払う必要があるのでしょうか？ それは何ですか いつ使うか 高いドキュメント変更率（毎日10%以上のドキュメントが更新される）。リアルタイムコンテンツ（ニュース、ソーシャルメディア、ライブアップデート）。埋め込みモデルを実験している場合（再インデックスは不要）。データの鮮度が重要（ドキュメントは最新である必要があります）。リランキングのKが小さい場合（20〜50ドキュメント）。 計算時間 オンザフライ/オンライン（1000クエリ/日、50ドキュメント/クエリ）： - 埋め込みコスト：〜15ドル/月（継続的） - ストレージ：0ドル（テキストのみを保存） - 遅延：クエリあたり200〜500ミリ秒 - 鮮度：完璧（常に最新） - モデル切り替え：容易（API呼び出しを変更するだけ） モデル陳腐化の利点 これはあまり語られないことですが、埋め込みモデルは陳腐化します。 OpenAI は text-embedding-ad を陳腐化しました。