RAGとは何か、そしてどのように機能するか（ガイド (初心者向け)

#30秒でわかるRAG

RAGはRetrieval-Augmented Generationの略で、検索によって補強されたテキスト生成を意味します。LLMに直接「この質問に答えてください」と頼むのではなく、まず文書データベースから最も関連性の高い箇所を検索します。そして、その箇所をプロンプトに貼り付け、「これが情報源です。これに基づいて答えてください」と指示します。

わかりやすく例えると、LLM単体は、試験で記憶を頼りに答える優秀な学生のようなものです。RAGは、その同じ学生が机の上で授業資料を開いて参照できる状態に相当します。事実にない内容を作り出すことが減り、正しいページを引用できます。また、これまで見たことのない授業資料（お手元のPDF、メール、社内Wiki）を渡しても、その内容について答えられます。

#なぜ、どんなときに必要なのか

LLMには、本格的に使うとすぐに明らかになる大きな欠点が2つあります。知らないことをでっち上げること（いわゆる「ハルシネーション」）と、学習時に見たデータしか知らないことです。Qwen 3.5 9Bは、あなたの契約書も、Notionのウィキも、インシデントデータベースも一度も読んだことがありません。それらについて直接回答するようモデルに求めるのは、開いたことのない本の内容を想像するよう人に求めるのと同じです。

RAGは両方を解決します：適切な抜粋をプロンプトに注入し、LLMがそれらを事実の基盤として利用し、回答が追跡可能になります——ソースを表示できます。

自分のPDFとチャットする

技術資料、契約書、学術論文、マニュアルなど、コンテキストウィンドウに収まりきらないほど分量の多いもの。

チーム内部向けアシスタント

Wiki、サポート用ナレッジベース、製品ドキュメント。Ctrl+F による大まかな検索の代わりに、適切なページを引用したフランス語の回答を提供します。

情報収集と要約

数百の記事やレポートをインデックス化し、複数の資料にまたがる質問をし、情報源を比較する。

最新またはプライベートデータ

LLM が参照できなかったすべての情報：あなたのコード、メール、知識カットオフ日以降の公開情報。

#4ステップのパイプライン

RAGには二つの段階があります。事前に一度行うインデックス作成と、質問のたびに行う問い合わせです。以下に、順につながる四つの構成要素を示します。

1. 01
   1. Chunking — ドキュメントを分割

   PDF、Markdown ファイルまたはウェブページは、約200から800語の断片（chunks）に分割されます。一冊の本全体を一度に埋め込むことはできません。また、質問に答える正確な箇所を特定したいのではなく、全体のドキュメントをすべて取得したいわけではありません
2. 02
   2. Embeddings — テキストをベクトルに変換する

   各チャンクは埋め込みモデルに渡され、数値のベクトル（通常384〜1024次元）に変換されます。同じ内容について述べている2つの文章は、この空間内で互いに近いベクトルになります。これが意味検索を可能にする魔法です。
3. 03
   3. ベクトルデータベースへの保存

   ベクトルと元のテキストは、専用のデータベース（Chroma、Qdrant、FAISSなど）に格納されます。このデータベースは「自分のベクトルに最も近いベクトルはどれか？」という問いに素早く答えられます。
4. 04
   4. Retrieval および生成

   ユーザーの質問の埋め込みを計算し、それに最も近い3〜10個のチャンクを取得します。それらを「これらの抜粋に基づいて回答してください」といった指示とともにLLMのプロンプトに組み込み、LLMが回答を生成します。

# Phase 1 : INDEXATION (une fois)
for doc in documents:
    chunks = split(doc, taille=500)              # 1. chunking
    for chunk in chunks:
        vector = embedder.embed(chunk)            # 2. embedding
        vector_db.add(vector, chunk)              # 3. stockage

# Phase 2 : INTERROGATION (à chaque question)
question = "Quel est le délai de résiliation ?"
q_vector = embedder.embed(question)               # même modèle qu'à l'indexation
top_chunks = vector_db.search(q_vector, k=5)      # 4a. retrieval

prompt = f"""Réponds en t'appuyant uniquement sur les extraits ci-dessous.

Extraits :
{top_chunks}

Question : {question}"""
reponse = llm.generate(prompt)                    # 4b. génération

#埋め込み：検索の核心

埋め込みモデルは、テキストの断片をその「意味」を捉える数値のベクトルに変換する単一のタスクに特化したミニLLMです。同じ話題について述べている2つの文は、共通の単語がなくても、近いベクトルを生成します。これがRAGを単純なCtrl+Fと区別する点です。

RAGの最終的な品質は、背後にあるLLMと同じくらい、そして多くの場合はそれ以上に、エンベディングモデルに依存します。質の低いエンベディングでは不適切なチャンクが検索されるため、世界最高のLLMでも、話題と関係のないテキスト断片から正しく回答することはできません。

nomic-embed-text

137Mパラメータ、768次元、8192トークンのコンテキスト。Ollamaが提供する標準的な設定。英語では良好で、フランス語でも正確です。

mxbai-embed-large

335Mパラメータ、1024次元。より正確ですが、3倍遅い。リトリーブの品質が限定されている場合に適しています。

multilingual-e5-large

560M、1024次元。文書がフランス語または多言語の場合に最適な選択です。

bge-m3

フランス語で優れた性能を発揮し、長いコンテキストに対応しています。動作にはより多くのリソースが必要ですが、多言語コンテンツでは定番のモデルです。

#ベクトルデータベース：ベクトルの保存先

ベクトルデータベースは、「このベクトルに最も近いN個のベクトルを見つけて」という操作に特化したデータベースです。内部ではHNSWやIVFなどのアルゴリズムを使い、数百万のベクトルがあっても高速に検索できます。使い始めるにあたって、これらのアルゴリズムを理解する必要はありません。どのベクトルデータベースを選べばよいかが分かれば十分です。

Chroma

Pythonプロジェクトに組み込む形でも、サーバーとしても使えるオープンソースのベクトルデータベースです。設定不要で、データをディスクに永続保存できるため、始めるのに最適です。

Qdrant

本番運用により適した堅牢性：専用サーバー、フィルター、マルチテナント対応。コマンド一つでDockerコンテナ内で起動できます。

FAISS

Facebook（Meta）のライブラリ。非常に高速ですが、これは単なるインデックスであり、メタデータの管理はできません。パフォーマンスが極めて重要なケースに適しています。

ツール内に保存されています

Open WebUI、AnythingLLM、LM Studioは、それぞれ独自のベクトルデータベースを内蔵しています。利用者が意識する必要はなく、PDFをアップロードすればインデックス化されます。コードを書かずに始めるのに最適です。

#LLM：情報に基づく生成

LLM は処理の最後を担います。受け取るプロンプトは、例えば次のようなものです。「以下はドキュメントから抜粋した5つの文章です。この抜粋だけに基づいて質問に答えてください。情報が抜粋に含まれていない場合は、その旨を伝えてください。」

このように情報を与えることで、状況は大きく変わります。コンテキストを与えなければ、LLMは学習時に記憶した情報に基づいて回答し、その情報に抜けがあれば作り話をします。適切な抜粋をプロンプトに入れれば、事実に基づく情報を参照でき、言い換えや要約だけを行います。

LLMのサイズはどれくらいですか？

シンプルなRAGには、8 GBのメモリに収まる2026年の小型モデル（Qwen 3.5 9B、Granite 4.2 8B）で十分です。検索の品質はLLMのサイズよりも重要です。

どのコンテキストウィンドウが適しているか？

少なくとも4096トークン。取得されたチャンクに加え、質問とシステムインストラクションが2000〜3000トークンをすぐに消費します。8192トークン以上であれば、十分に余裕があります。

システムプロンプトは？

たとえば、次のような指示です：「提供された抜粋だけを根拠に、フランス語で回答してください。そこに情報がない場合は、その旨を明確に伝えてください。」

#ローカル RAG とクラウド API の比較

OpenAIやClaudeのAPIを使ってRAGを構築することも（短時間で導入でき、性能は最大限）、Ollama＋ベクトルデータベース＋埋め込みモデルを使ってすべてローカルで構築することもできます（データ漏洩ゼロ、利用ごとのコストゼロ）。選択はドキュメントの機密性と予算によって決まります。

クラウドAPIを介したRAG

文書は、インデックス作成時と質問のたびに、サービス提供者（OpenAI、Anthropic、Mistralなど）に送信されます。性能と品質は最高水準ですが、機密データの取り扱い（RGPD、医療上の守秘義務、顧客との契約）には適しません。

100％ローカルのRAG

LLMにはOllama、埋め込みにはnomicまたはbge、データベースにはChromaまたはQdrantを使用します。データは一切マシンの外に出ません。専門職（法律家、医師、人事担当者）、GDPRの適用を受ける企業、そして自分で管理し続けたいすべての人に最適です。

ハイブリッド

埋め込みはローカルで生成し、LLM は API 経由で利用します。外部に送るデータを抑えられます（文書全体はローカルに残り、質問時に関連するチャンクだけがクラウドに送信されます）。現実的な折衷案ですが、チャンク自体に機密情報が含まれる場合は推奨しません。

#実際にどうやって始めればよいですか

利用者の経験や用途に応じて、3つの方法があります。どれも、お使いのマシン上で100 %ローカルに動作します。

1. 01
   コードを書かずに、インターフェース（Open WebUI または AnythingLLM）を用いる

   Ollamaをインストールし、DockerでOpen WebUIまたはAnythingLLMを起動して、PDFを「Knowledge Base」にアップロードし、会話を始めます。チャンク分割、埋め込み、検索は、すべて自動で処理されます。最初から最後まで30分です。
2. 02
   コードを書かずに、オールインワンで（LM Studio）

   バージョン 0.3 以降、LM Studio には「Chat with Documents」機能が搭載されています。チャットにファイルを添付するだけで、システムが処理します。制限事項：1チャットあたり5ファイルまで、かつ対応形式が限定されています（テキスト PDF、DOCX、TXT、MD）。特定のドキュメントに関する一時的な質問に最適です。
3. 03
   LangChainまたはLlamaIndexを使ってPythonで実行

   チャンク分割ツール、埋め込みモデル、データベース、LLM、プロンプトをすべて自由に選べます。最初のきちんとしたプロトタイプには半日を見込み、最適化（リランカー、ハイブリッド検索など）も行うなら、さらに時間を確保してください。

# 1. Installer Ollama (https://ollama.com)
# 2. Récupérer un LLM et un modèle d'embeddings
ollama pull qwen3.5:9b
ollama pull nomic-embed-text

# 3. Vérifier que le daemon répond
curl http://localhost:11434/api/tags

# 4. Lancer Open WebUI (interface ChatGPT-like avec RAG intégré)
docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

# Ouvrir http://localhost:3000
# Settings -> Documents -> uploader des PDF
# Dans un chat : taper # pour attacher une Knowledge Base

#初心者が陥りやすい落とし穴

英語向けの埋め込みモデル、フランス語の文書

フランスにおけるRAGの期待外れな結果の第1位の要因です。埋め込みモデルがフランス語に対応していることを確認してください（multilingual-e5、bge-m3）。

チャンクが大きすぎるか小さすぎる

まずは500語を目安にするとよいでしょう。チャンクが小さすぎると（100語未満）文脈が失われ、大きすぎると（1500語を超える場合）エンベディングがすべてを平均化してしまい、精度が低下します。

インデックスを再構築せずに埋め込みモデルを変更する

モデルのベクトルは他のモデルのベクトルと互換性がありません。nomicからbgeに切り替える場合、すべてのインデックスを再構築する必要があります。そうでなければ、検索結果はまったく意味のないものになります。

コンテキストにチャンクが多すぎる

チャンク数が8〜10を超えると、LLMは情報をうまく整理できなくなり始めます。関連性が中程度のチャンクを20個渡すより、関連性が非常に高いチャンクを5個渡すほうがよい結果につながります（より高度な段階では、ここでリランカーが役立ちます）。

引用は表示されません

RAG が実際に機能しているかを確認するには、各回答で使用された情報源を表示してください。それを確認できなければ、適切な回答と、もっともらしいハルシネーションを区別できません。

#さらに詳しく

RAGとは何かが分かったところで、次に実践へ進むのに適したガイドをご紹介します。

Ollamaでコーディング不要のローカルRAG

ステップバイステップで Open WebUI と AnythingLLM を使って、GPU がなくても30分で最初の RAG を構築するチュートリアル

フランス語対応の優れた埋め込みモデル

コーパスに応じてnomic、multilingual-e5、bge-m3、Solonから選ぶための詳細な比較です。

ローカル RAG：入門

概念を詳しく解説するガイド：チャンキング、検索、リランキング、評価指標。

Ollama とは何か、どのように動作するか

まだ Ollama をインストールしていない場合は、こちらから。