---
source_url: https://www.lighthousenewsletter.com/p/rag-is-simpler-than-you-think
source_title: "6 RAG Architectures — and How to Avoid Over-Engineering"
source_site: "Lighthouse AI"
source_published_at: 2026-06-10T13:53:00+00:00
hero_image: https://substackcdn.com/image/fetch/$s_!yF7E!,w_1200,h_675,c_fill,f_jpg,q_auto:good,fl_progressive:steep,g_auto/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F03ad851c-75b8-4afe-ae16-fd98c8e61836_1920x1280.jpeg
tags: rag,retrieval-augmented-generation,search,vector-databases,embeddings
generated_at: 2026-08-26T12:01:09.086Z
model: claude-haiku-4-5
---
# RAG アーキテクチャ 6 パターン — 過度な複雑化を避ける方法

1日 1,000 クエリ程度のシステムは BM25 と LLM クエリ書き換えで十分対応でき、本格的なベクトル検索は多くの場合で不要だと指摘する記事が公開された。

Lighthouse AI が 2026-06-10 に公開した記事は、RAG システム構築における 6 つのアーキテクチャパターンと、段階的な最適化戦略を提示している。BM25 などの全文検索、LLM によるクエリ書き換え、ハイブリッド検索、動的埋め込み、ホットコールドティアの埋め込み分離、完全事前埋め込みという 6 つの選択肢を比較し、各アプローチの適用条件とコストを具体的な数値で示している。著者は多くの企業が必要以上に複雑な RAG スタックを構築していると主張し、シンプルな手法から始めて必要に応じてのみ段階的に高度な最適化を加えるべきだと述べている。

![RAG アーキテクチャの比較図](https://substackcdn.com/image/fetch/$s_!yF7E!,w_2400,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F03ad851c-75b8-4afe-ae16-fd98c8e61836_1920x1280.jpeg)

## 6 つの RAG アーキテクチャ

記事が提示する検索アーキテクチャは以下のとおり：

- **BM25 / 全文検索**：10ms 以下の高速応答、API コストなし、デバッグが容易。ただし意味的理解に欠ける。
- **LLM によるクエリ書き換え**：不正形なクエリから不用語を除去、同義語を追加、ドメイン用語を変換。GPT-4o-mini を用いた場合、1 クエリあたり $0.001 のコスト。
- **ハイブリッド検索**：BM25 で候補を取得（上位 50～100 件）後、埋め込みで再ランク付け（上位 10 件）する組み合わせ方式。
- **動的埋め込み**：クエリごとに文書を埋め込む方式。1 クエリあたり 200～500ms のレイテンシと $0.0005 のコスト（1 日 1,000 クエリで月 $15）。
- **ホットコールドティア**：アクセス頻度の高い 20% の文書のみ事前埋め込みし、残り 80% は動的に処理する。月 10% 以上の文書更新率がある場合に適している。
- **完全事前埋め込み**：全文書を事前埋め込みする方式。text-embedding-3-small では 100 万文書あたり $10、ストレージ 6GB（月 $10～30）で実現でき、レイテンシは 50ms 以下。

## 段階的な意思決定フレームワーク

![意思決定ツリー](https://substackcdn.com/image/fetch/$s_!TXCo!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F035b8f95-ee55-4356-a00e-d6e5f1e76f4e_1400x400.avif)

アーキテクチャ選択の鍵となる要因は、データ鮮度要件、文書集合の特性、クエリパターン、スケール・性能要件、チームの技術力の 5 つとされている。記事は「データが示すまで次のステップへ進まない」という段階的な最適化を推奨している。

一般向け埋め込みモデルが企業固有の用語（例えば社内フレームワークの名称）を理解できないため、社内用語集をシステムプロンプトで LLM に付与してクエリ書き換えを行うといったドメイン適応策の有効性が示唆されている。

## 実装上の考慮事項

Perplexity や ChatGPT の検索機能では、複雑なクエリを複数のサブクエリに分解するエージェント型 RAG が採用されている。著者の分析では、クエリ分解により全体コストが $0.03 から $0.002 に削減される（15 倍のコスト削減）ことが示されている。

文書更新率が週 10% を超える場合や 1 日のクエリ数が 1,000 以下である場合は、完全事前埋め込みを回避すべきとされる。モデル廃止時の再埋め込みコストも考慮すると、100 万文書の完全事前埋め込みには $10,000 かかるのに対し、ホットコールドティア方式では 20 万文書のみ再埋め込みして $2,000 に抑えられる。

ベースライン性能の測定には 2～4 週間、クエリ書き換えやハイブリッド検索の A/B テストには各 2 週間を要することが目安とされている。

## 構成別の適用分布

著者の見立てでは、全文検索にクエリ書き換えを組み合わせた構成で対応可能なシステムが 60%、ハイブリッド検索またはホットコールドティア方式が 25%、完全事前埋め込みが 10%、カスタムソリューション要件が 5% と推定されている。

*この記事は元記事の事実のみに基づいて自動生成されました。*

## 筆者の見立て

- 多くの「セマンティック検索」の問題は実際にはクエリ定式化の問題であると解釈している。
- シンプルなアプローチでかなりの用途に対応できると予想している。
- チャンキング戦略や複雑なベクトルデータベース設定の最適化は、クエリ書き換えで 90% の問題が解決する場合には不要だと論じている。
- 完全事前埋め込みはモデル廃止時の再埋め込みコストが最大の痛手だと解釈している。
- ほとんどのシステムにとって完全事前埋め込みは過剰だと述べている。
- エージェント型検索システムがサブクエリごとの処理最適化で実力を発揮すると見ている。
- エージェントは、どのサブクエリに高コストの処理が必要かを知的に判断できると解釈している。
- 全システムの 60% は全文検索とクエリ書き換えで止めるべきであり、残りのみ段階的に高度な手法を検討すべきだと予想している。
- 60% の問題に対して 5% レベルのソリューションを構築してはいけないと述べている。

## 出典

**Lighthouse AI**  
「6 RAG Architectures — and How to Avoid Over-Engineering」  
https://www.lighthousenewsletter.com/p/rag-is-simpler-than-you-think