RAGアーキテクチャの選択：Naive RAGからModular RAGまで

RAGはLLMに外部知識を接続する最も実用的な手法だ。しかし「RAG」という言葉の裏には、複数のアーキテクチャパターンが隠れている。

Naive RAG

最もシンプルな構成。クエリを埋め込みに変換→ベクターDBで類似チャンクを取得→LLMにコンテキストとして渡す。

def naive_rag(query: str) -> str:
    embedding = embed(query)
    chunks = vector_db.search(embedding, top_k=5)
    context = "\n".join(chunks)
    return llm.generate(f"Context: {context}\n\nQuestion: {query}")

精度が十分なら、これで終わりにすべきだ。複雑にする必要はない。

Advanced RAG

Naive RAGで精度が足りない時のパターン。Pre-retrievalとPost-retrievalの工夫が入る。クエリ拡張（HyDE、Step-back prompting）、Re-ranking、コンテキスト圧縮などを組み合わせる。

Modular RAG

各コンポーネントをモジュールとして組み替えられる設計。LangGraphやLlamaIndexで実装することが多い。フレキシブルだが複雑度が高い。本番で必要になるまで避けるべきだ。

選択基準

まずNaive RAGで試す。recall@5 < 0.7なら検索を改善。検索は良いのに回答が悪いならPost-retrievalを追加。それでも足りないならModular RAGへ。