RAG（Retrieval Augmented Generation）は導入が進んでいますが、運用で最も難しいのは「改善したつもり」が頻発する点です。embedding モデルを変えた、chunk サイズを変えた、reranker を追加した。どれも良さそうに見えるのに、ユーザー満足は上がらない。このギャップを埋めるのが評価基盤です。

本記事では、RAG を継続改善するための評価パイプラインを、データセット設計から CI 統合まで具体的に解説します。

RAG評価で見るべき3層

RAG の品質は 1 指標では測れません。最低でも次の3層を分けて評価します。

1. Retrieval層: 正しい文書を取れているか
2. Generation層: 回答が正確で有用か
3. System層: レイテンシ・コスト・安定性

この分離がないと、生成品質低下の原因が retrieval なのか prompt なのか判別できません。

ステップ1：評価データセットを設計する

1-1. 問い合わせカテゴリを分割

例として次の5カテゴリに分けます。

• 定義確認（用語説明）
• 手順質問（How-to）
• 例外対応（エラー解決）
• 比較検討（A vs B）
• 根拠提示（出典必須）

カテゴリごとに難易度と重要度を持たせ、偏りを防ぎます。

1-2. 正解の持ち方

正解は「理想回答1つ」では不十分です。RAGでは表現揺れが自然なので、次を保存します。

• 期待要素（必須ポイント）
• 禁止要素（誤情報、過剰断定）
• 参照すべき文書ID

この形式にすると、自動評価と人手レビューを両立できます。

ステップ2：Retrieval評価を自動化

代表指標:

• Recall@k
• MRR
• nDCG

例えば、正解文書IDを持つ場合は次のように計算します。

1
2
3

def recall_at_k(retrieved_ids, gold_ids, k=5):
    topk = set(retrieved_ids[:k])
    return 1.0 if len(topk.intersection(gold_ids)) > 0 else 0.0

運用では平均値だけでなく、カテゴリ別分布を見ることが重要です。手順質問だけ recall が低い場合、chunk 戦略や見出し抽出に問題がある可能性が高いです。

ステップ3：Generation評価の設計

自動評価では次を推奨します。

• Faithfulness（出典との整合）
• Answer Relevance（質問への適合）
• Completeness（必要要素網羅）
• Safety（禁止事項違反）

LLM-as-a-judge を使う場合、判定プロンプトを固定し、temperature=0 で再現性を確保します。さらに、週次で人手サンプル監査を入れて判定ドリフトを検出します。

ステップ4：System評価（遅延・コスト）

品質改善がコスト爆増を招くと継続できません。次を同時に計測します。

• P50/P95 latency
• 平均 input/output token
• 1回答あたり推定コスト
• timeout率、fallback率

この4指標を CI レポートに含めると、精度改善の副作用を早期に発見できます。

ステップ5：CIへの組み込み

PR ごとに評価ジョブを実行し、閾値を満たさない変更をブロックします。

判定例:

• Recall@5: 0.82 以上
• Faithfulness: 0.90 以上
• P95 latency: 2500ms 以下
• Cost/answer: $0.005 以下

疑似フロー:

1. 変更ブランチでインデックス再構築
2. 評価データセット100件で推論
3. 指標を計算して前回基準と比較
4. 差分レポートをPRコメントに投稿

これで「なんとなく改善」を排除できます。

ステップ6：オンライン評価との接続

オフライン評価だけでは実利用の多様性を拾えません。オンライン指標を接続します。

• ユーザー評価（👍/👎）
• 再質問率（同一セッションで再問い合わせ）
• 人間オペレータ転送率

重要なのは trace_id でオフライン指標と紐づけることです。これにより「オフラインは良いのに本番満足が低い」差分を原因追跡できます。

改善ループの実例

ある社内ヘルプデスクRAGでの改善例:

• 問題: 手順質問で誤回答が多い
• 原因: chunk が短すぎ、手順文脈が分断
• 対策: section-aware chunking + reranker導入

結果:

• Recall@5: 0.74 → 0.88
• Faithfulness: 0.81 → 0.93
• P95 latency: +180ms（許容内）

このように、どの変更がどの指標に効いたかを記録すると、次回改善の再現性が高まります。

よくある失敗

1. 評価データが少なすぎる
   • 20件程度では統計的に不安定。最低100件、理想300件。
2. 単一スコアで判定する
   • 精度だけでコストを見ないと運用破綻。
3. 判定プロンプトを頻繁に変える
   • 指標比較の連続性が失われる。
4. 失敗事例をデータセットへ反映しない
   • 同じ不具合を繰り返す。

90日ロードマップ

• 0-30日: 評価データセット整備、retrieval指標導入
• 31-60日: generation指標 + CIゲート導入
• 61-90日: オンライン評価統合、週次改善会の定着

この順序なら、運用負荷を抑えつつ確実に品質を上げられます。

まとめ

RAG の実力は、モデル選定より評価基盤で決まります。retrieval、generation、system の3層を分離し、CI に組み込むことで、改善の再現性が生まれます。

まずは小さく始めて、失敗ケースを評価データセットに反映し続けてください。評価が回り始めると、RAG は「当たるかどうかの賭け」から「制御可能なプロダクト」へ変わります。

実装例：評価結果をPRコメントに自動投稿する

運用で効くのは、評価結果を開発者が日常的に見る導線を作ることです。GitHub Actions で評価スクリプトを実行し、結果を PR コメントへ投稿します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

name: rag-eval
on: [pull_request]
jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: uv sync
      - run: uv run python scripts/run_rag_eval.py --dataset evalset_v3.json --out report.json
      - run: uv run python scripts/post_pr_comment.py report.json

この仕組みがあると、レビュー段階で「この変更は Faithfulness を 0.04 落とすが latency は改善」という会話ができ、意思決定が定量化されます。

評価データセットの更新運用

評価セットを固定しすぎると、現実の問い合わせ変化に追従できません。次のルールを推奨します。

• 月1回、実ユーザー失敗ケースを20件追加
• 四半期ごとに古いケースを棚卸し
• 重要カテゴリ比率を維持（例: 手順質問30%以上）

この更新を怠ると、指標が良くても体感品質が落ちる「評価腐敗」が起きます。

A/Bテストとの接続

大きな変更（embedding刷新、reranker導入）は、オフライン評価だけでなくオンライン A/B を併用します。

• A群: 現行パイプライン
• B群: 新パイプライン
• 比較指標: 👍率、再質問率、回答時間、コスト

2週間程度の観測で統計差が出るケースが多く、主観ベースの議論を減らせます。

まとめ（定着のポイント）

RAG 改善を継続する鍵は、評価を「一回の検証」ではなく「開発フローの標準」にすることです。CI コメント、データセット更新、A/B テストを回すことで、品質向上が偶然ではなく再現可能な活動になります。

補足

評価結果は経営指標とも接続できます。問い合わせ解決率やサポート工数削減と紐づけることで、RAG 改善が事業価値にどう効いたかまで説明可能になります。

はじめに

「自社の膨大なマニュアルやナレッジベースの内容を、ChatGPTのように対話形式で手軽に引き出したい」 「開発中のAIチャットボットに、社内規定や顧客との過去のやり取りを正確に回答させたい」 「でも、機密情報を含む自社データを、外部のAIサービスに学習データとして渡すのはセキュリティ的に絶対に避けたい」

AI、特に大規模言語モデル（LLM）の活用を検討する多くのエンジニアや開発担当者が、このような課題に直面しているのではないでしょうか。LLMは非常に強力ですが、その知識は特定の時点までのものであり、自社の独自データについては何も知りません。

この課題を解決するために「ファインチューニング」を検討するかもしれません。しかし、ファインチューニングには大量の教師データと高い計算コストが必要な上、情報の更新があるたびにモデルを再学習させるのは現実的ではありません。さらに、AIがもっともらしい嘘をつく「ハルシネーション」という問題も依然として残ります。

本記事では、これらの課題をエレガントに解決する技術として、今、AIエージェント開発の現場でデファクトスタンダードとなりつつある**RAG（Retrieval-Augmented Generation：検索拡張生成）**というアプローチを徹底的に解説します。

RAGは、LLMに自社データを「学習」させるのではなく、必要な情報を「検索」して外部から与えることで、LLMの能力を最大限に引き出す画期的な手法です。そして、その中核を担うのが**Vector DB（ベクトルデータベース）**です。

この記事を読み終える頃には、あなたは以下のことを理解し、自社のAIエージェント開発に活かすための一歩を踏み出せるようになっているはずです。

• LLMが抱える根本的な課題（知識のカットオフ、ハルシネーション）
• なぜファインチューニングだけでは不十分なのか
• RAGがどのようにしてこれらの課題を解決するのか、その具体的な仕組み
• RAGの心臓部であるEmbeddingとVector DBの役割
• PythonとLangChainを使ったRAGの基本的な実装方法

それでは、AIエージェント開発の新たな扉を開く、RAGとVector DBの世界へご案内します。

なぜRAGとVector DBが重要なのか？ LLMの限界と従来の課題

RAGの重要性を理解するためには、まずLLMが単体で抱える限界を知る必要があります。

LLMが抱える3つの大きな壁

1. 知識のカットオフ（Knowledge Cut-off） GPT-4のような最先端のLLMでさえ、その知識は学習データが収集された特定の日時で止まっています。例えば、GPT-4の初期モデルは2021年9月までの情報しか持っていません。そのため、それ以降の出来事や、新製品の情報、最新の社内規定について質問しても、答えることができません。ビジネスの世界では情報の鮮度が命であり、この「知識の壁」は致命的な欠点となります。

2. ハルシネーション（Hallucination：幻覚） LLMは、事実に基づかない情報を、あたかも真実であるかのように生成することがあります。これをハルシネーションと呼びます。特に、学習データに含まれていない専門的な内容や、社内情報のようなクローズドなドメインについて質問された場合に、この現象は顕著になります。顧客サポート用のAIが誤った製品情報を伝えたり、社内アシスタントが架空の規定を案内したりする事態は、企業の信頼を著しく損なうリスクをはらんでいます。

3. 情報セキュリティとプライバシー 自社の機密情報や顧客の個人情報を扱う場合、それらを外部のLLM提供企業のサーバーに学習データとしてアップロードすることには、非常に大きなセキュリティリスクが伴います。一度学習データとして取り込まれてしまうと、他のユーザーへの回答に利用されてしまう可能性もゼロではなく、データのコントロールを失うことになります。

従来の解決策「ファインチューニング」とその限界

これらの課題を解決するアプローチとして、以前は「ファインチューニング」が主流でした。これは、既存の学習済みモデルに対して、自社データを含む追加の教師データセットを与えて再学習させる手法です。

ファインチューニングは、LLMに特定の文体や口調を真似させたり、特定のタスク（例えば、要約や感情分析）への性能を特化させたりするのには有効です。しかし、「知識を注入する」という目的においては、いくつかの大きな課題があります。

• 高いコスト: ファインチューニングには、大量の高品質な教師データ（質問と回答のペアなど）の準備と、モデルの学習を実行するための高価な計算リソース（GPU）が必要です。
• 知識の更新が困難: 新しい情報（例えば、週次レポートや新しいマニュアル）を追加したい場合、その都度ファインチューニングをやり直す必要があります。これは時間的にも金銭的にも非効率です。
• 透明性の欠如: ファインチューニングされたモデルが、なぜその回答を生成したのか、どの情報を根拠にしているのかを追跡することは非常に困難です。ハルシネーションが起きた場合の原因究明も難しくなります。

そこで登場したのが、**RAG（検索拡張生成）**です。RAGは「学習」ではなく「検索」というアプローチで、これらの問題を根本から解決します。

具体的な解決策：RAGの仕組みとVector DBの役割

RAGは、その名の通り「検索（Retrieval）」でLLMの知識を「拡張（Augmented）」し、回答を「生成（Generation）」するアーキテクチャです。LLMを「非常に優秀だが記憶喪失のコンサルタント」、Vector DBを「完璧な記憶力を持つ外部の専門図書館」に例えると分かりやすいでしょう。

コンサルタント（LLM）は、質問を受けるたびに、まず図書館（Vector DB）へ行って関連資料を調べ（検索）、その資料を読み込みながら（コンテキストとしてプロンプトに含める）、質問に対する的確な回答を生成します。

この仕組みにより、LLMは常に最新かつ正確な情報に基づいて回答できるようになり、ハルシネーションを劇的に抑制できます。

RAGの全体像と処理フロー

RAGのシステムは、大きく2つのフェーズに分かれています。

1. データ準備フェーズ（Indexing）: 事前に自社ドキュメントを検索可能な状態にして、Vector DBに保存しておくフェーズ。
2. 実行フェーズ（Retrieval & Generation）: ユーザーからの質問を受け取り、Vector DBから関連情報を検索して、LLMが回答を生成するフェーズ。

この流れを図で示すと以下のようになります。

graph TD
    subgraph "データ準備フェーズ（Indexing）"
        A[ドキュメント群<br>PDF, TXT, Markdown, etc.] --> B(Load<br>ドキュメント読み込み);
        B --> C(Split<br>テキストを適切なサイズに分割);
        C --> D(Embed<br>分割したテキストをベクトル化);
        D --> E[Vector DB<br>ベクトルと元のテキストを保存];
    end

    subgraph "実行フェーズ（Retrieval & Generation）"
        F[ユーザーからの質問] --> G(Embed<br>質問をベクトル化);
        G --> H{Vector DB<br>類似ベクトル検索};
        E --> H;
        H --> I[関連性の高い<br>テキストチャンク（コンテキスト）];
        F & I --> J(Prompt<br>質問とコンテキストを結合し<br>プロンプトを作成);
        J --> K[LLM (e.g., GPT-4)<br>回答生成];
        K --> L[ユーザーへの回答];
    end

それでは、このフローの各要素を詳しく見ていきましょう。

構成要素①: Embedding - テキストを「意味」のベクトルに変換する魔法

RAGを理解する上で最も重要な概念が**Embedding（エンベディング、埋め込み）**です。

人間は「犬」と「猫」が似ていて、「犬」と「車」はあまり似ていないことを直感的に理解できます。しかし、コンピュータは単なる文字の羅列としてしか認識できません。Embeddingは、この「意味の近さ」をコンピュータが扱えるように、テキストを高次元のベクトル（数値の配列）に変換する技術です。

例えば、以下のように変換されます（次元数は簡略化しています）。

• 犬: [0.8, 0.1, 0.3, ...]
• 猫: [0.7, 0.2, 0.4, ...]
• 車: [-0.5, 0.9, -0.1, ...]

このベクトル空間上では、意味的に近い単語や文章は、その距離も近くなります。OpenAIのtext-embedding-ada-002（1536次元）や、様々なオープンソースのモデルがこの変換を行うために利用されます。

RAGでは、事前にドキュメントの各部分（チャンク）をベクトル化しておき、ユーザーの質問も同じモデルでベクトル化します。そして、質問のベクトルと最も近いベクトルを持つドキュメントチャンクを探すことで、質問に最も関連性の高い情報を特定するのです。

構成要素②: Vector DB - 意味で検索する次世代のデータベース

Embeddingによって得られた大量のベクトルデータを効率的に保存し、高速に「意味の近さ（類似度）」で検索するための専用データベースがVector DBです。

従来のRDB（リレーショナルデータベース）がWHERE user_id = 123のように完全一致でデータを検索するのに対し、Vector DBは「このベクトルに最も近いベクトルを探して」という**近似最近傍探索（Approximate Nearest Neighbor, ANN）**を得意とします。

代表的なVector DBには以下のようなものがあります。

• Chroma: ローカル環境で手軽に試せるオープンソースのVector DB。プロトタイピングに最適。
• FAISS: Facebook (Meta) AIが開発した、ベクトル類似検索に特化したライブラリ。
• Pinecone, Weaviate, Qdrant: クラウドネイティブなマネージドサービスとして提供されることが多く、スケーラビリティや高度な機能（メタデータフィルタリングなど）が特徴。

Vector DBは、ベクトル化されたドキュメントチャンクと、その元となったテキスト本文のペアを保存します。検索時には、質問ベクトルに類似したベクトルを持つチャンクを複数個見つけ出し、その元テキストをLLMへのコンテキストとして渡します。

RAGの実装ステップ（PythonとLangChainによるコード例）

それでは、実際にPythonのフレームワークLangChainを使って、簡単なRAGシステムを構築してみましょう。LangChainは、LLMアプリケーション開発における一連の流れを抽象化し、簡単に実装できるようにしてくれる便利なツールです。

ここでは、架空の「社内副業規定.pdf」というドキュメントの内容について回答するAIエージェントを作成します。

前提: PDFファイルinternal_rules.pdfが手元にあるとします。内容は以下のようなものです。

第5条（副業・兼業）

1. 社員は、会社の許可を得た上で、副業または兼業を行うことができる。
2. 副業を希望する社員は、所定の申請書を人事部に提出し、事前の承認を得なければならない。
3. 会社の競合他社での業務や、会社の信用を損なう可能性のある業務は許可されない。

ステップ1: 環境構築と準備

まず、必要なライブラリをインストールし、OpenAIのAPIキーを設定します。

1

pip install langchain openai chromadb pypdf tiktoken

1
2
3
4

import os

# 環境変数にOPENAI_API_KEYを設定
os.environ["OPENAI_API_KEY"] = "YOUR_OPENAI_API_KEY"

ステップ2: ドキュメントの読み込み (Load)

LangChainのPyPDFLoaderを使って、PDFファイルを読み込みます。

1
2
3
4
5
6
7

from langchain.document_loaders import PyPDFLoader

loader = PyPDFLoader("internal_rules.pdf")
documents = loader.load()

print(f"ドキュメントを {len(documents)} ページ読み込みました。")
# 出力例: ドキュメントを 1 ページ読み込みました。

ステップ3: テキストの分割 (Split/Chunking)

LLMが一度に処理できるテキスト量（コンテキストウィンドウ）には限りがあるため、また、検索精度を向上させるために、読み込んだドキュメントを小さなチャンクに分割します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

from langchain.text_splitter import RecursiveCharacterTextSplitter

# テキスト分割の設定
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,  # チャンクの最大文字数
    chunk_overlap=50   # チャンク間のオーバーラップ文字数
)

# 分割の実行
split_docs = text_splitter.split_documents(documents)

print(f"ドキュメントを {len(split_docs)} 個のチャンクに分割しました。")
# 出力例: ドキュメントを 3 個のチャンクに分割しました。

chunk_sizeとchunk_overlapはRAGの性能を左右する重要なパラメータです。chunk_overlapを設けることで、文の途中でチャンクが分断され、文脈が失われるのを防ぎます。

ステップ4: EmbeddingとVector DBへの保存 (Embed & Store)

分割したチャンクをEmbeddingモデルでベクトル化し、Chroma DBに保存します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

from langchain.embeddings.openai import OpenAIEmbeddings
from langchain.vectorstores import Chroma

# Embeddingモデルのインスタンス化
embeddings = OpenAIEmbeddings()

# Chroma DBにドキュメントを読み込み、ベクトル化して保存
# persist_directoryを指定すると、DBがディスクに永続化される
vectordb = Chroma.from_documents(
    documents=split_docs,
    embedding=embeddings,
    persist_directory="./chroma_db"
)

print("Vector DBの準備が完了しました。")

このコードを実行すると、./chroma_dbというディレクトリが作成され、ベクトルデータが保存されます。

ステップ5: 検索と生成 (Retrieve & Generate)

いよいよ、作成したVector DBを使って質問応答チェーンを構築し、実際に質問をしてみます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

from langchain.chat_models import ChatOpenAI
from langchain.chains import RetrievalQA

# LLMモデルのインスタンス化
llm = ChatOpenAI(model_name="gpt-4", temperature=0)

# Vector DBをRetriever（検索機）として使用するQAチェーンを作成
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",  # 最もシンプルなチェーンタイプ
    retriever=vectordb.as_retriever()
)

# 質問を実行
question = "社員が副業を始めるには、どのような手続きが必要ですか？"
response = qa_chain.run(question)

print(f"質問: {question}")
print(f"回答: {response}")

実行結果の例:

質問: 社員が副業を始めるには、どのような手続きが必要ですか？
回答: 社員が副業を始めるには、所定の申請書を人事部に提出し、事前の承認を得る必要があります。

見事に、PDFの内容に基づいた正確な回答が生成されました。これはLLMが元々持っていた知識ではなく、私たちがVector DB経由で提供した情報に基づいています。これがRAGの力です。

RAGのメリットとデメリット

RAGは非常に強力な技術ですが、万能ではありません。そのメリットとデメリットを正しく理解し、ファインチューニングとの使い分けを考えることが重要です。

RAGのメリット

1. ハルシネーションの劇的な抑制: LLMは与えられたコンテキスト（検索結果）に基づいて回答を生成するため、事実に基づかない情報を捏造する可能性が大幅に低下します。
2. 知識の更新が容易かつ低コスト: 新しい情報やドキュメントの更新があった場合、モデル全体を再学習する必要はありません。Vector DB内の該当データを追加・更新するだけで、即座に知識を最新の状態に保てます。
3. 透明性と解釈可能性: RAGシステムでは、LLMがどのドキュメントチャンクを参考にして回答を生成したのかを追跡できます。これにより、ユーザーに出典を提示することが可能となり、回答の信頼性が向上します。
4. 高いセキュリティ: 自社の機密情報を外部のLLMに学習させる必要がありません。データは自社で管理するVector DB内に保持し、実行時に必要な情報だけをプロンプトの一部としてLLMに渡すため、データ漏洩のリスクを最小限に抑えられます。

RAGのデメリットと課題

1. 検索精度への依存: RAGの性能は、検索コンポーネントの精度に大きく依存します。ユーザーの質問に対して関連性の低いドキュメントしか検索できなかった場合、当然ながら回答の質も低くなります（Garbage In, Garbage Out）。
2. Chunking戦略の難しさ: テキストをどのように分割するか（chunk_size、chunk_overlap、分割単位など）は、試行錯誤が必要な職人芸的な側面があります。ドキュメントの構造を無視した不適切なChunkingは、検索精度を著しく低下させます。
3. システム構成の複雑化: LLM単体で完結せず、データローダー、テキストスプリッター、Embeddingモデル、Vector DBなど、複数のコンポーネントを組み合わせたパイプラインを構築・運用する必要があります。
4. レイテンシの増加: ユーザーからのリクエストごとに「検索」というステップが挟まるため、LLM APIを直接呼び出す場合に比べて、応答に時間がかかる可能性があります。

RAG vs ファインチューニング：どちらを選ぶべきか？

RAGとファインチューニングは対立するものではなく、補完関係にあります。目的によって使い分けるのが賢明です。

使い分けの指針:

• 事実に基づいた正確な知識を扱いたい場合は、まずRAGを検討します。
• LLMの**振る舞い（口調、文体、思考プロセス）**を特定の形に変えたい場合は、ファインチューニングが有効です。
• 両方を組み合わせる、つまりファインチューニングしたモデルをRAGの生成器（Generator）として使用することで、特定のスタイルで、かつ正確な情報に基づいた回答を生成する、という高度なアプローチも可能です。

現場で使える実践的なTips

基本的なRAGの実装は比較的簡単ですが、実運用で高い性能を出すためにはいくつかの工夫が必要です。

1. 高度なChunking戦略: 単純な固定長分割ではなく、ドキュメントの構造を活かしましょう。MarkdownであればMarkdownHeaderTextSplitter、ソースコードであればCodeSplitterなど、LangChainには様々なスプリッターが用意されています。これにより、意味のあるまとまりでテキストを分割でき、検索精度が向上します。

2. Embeddingモデルの選定: OpenAIのモデルは高性能ですが、コストがかかります。Hugging Faceで公開されているオープンソースのモデル（例: intfloat/multilingual-e5-largeなど日本語性能が高いもの）をセルフホストすることで、コストを抑えつつ、特定のドメインに特化した性能を得られる場合があります。

3. ハイブリッド検索（Hybrid Search）: Vector Search（意味検索）は万能ではありません。特定の製品名や型番、人名といった固有名詞を含むクエリには、従来のキーワード検索（BM25アルゴリズムなど）の方が強い場合があります。この2つを組み合わせたハイブリッド検索を実装することで、検索の網羅性と精度を両立させることができます。多くのマネージドVector DBサービスがこの機能を提供しています。

4. Retrieverのチューニング:

   • 検索ドキュメント数（k）の調整: retriever=vectordb.as_retriever(search_kwargs={"k": 5}) のように、一度に検索するチャンク数を調整します。多すぎるとノイズが増え、少なすぎると必要な情報が欠落します。
   • Re-ranking: 最初に多めにチャンクを検索（例: k=20）し、その後、より軽量で高速なCross-Encoderモデルなどを使って、質問との関連性を再計算し、上位のチャンク（例: top 5）だけをLLMに渡す手法です。ノイズを減らし、コンテキストの質を高めるのに非常に有効です。

5. メタデータフィルタリング: ドキュメントをVector DBに保存する際に、作成日、カテゴリ、著者などのメタデータを一緒に格納します。これにより、「2024年以降に作成された、“技術部"カテゴリのドキュメントの中から検索する」といった、より高度な絞り込み検索が可能になります。これは実用的なアプリケーションを構築する上で必須の機能です。

まとめ

本記事では、AIエージェント開発における必須知識として、RAG（検索拡張生成）と、その中核をなすVector DBの基礎について、仕組みから具体的な実装例、実践的なTipsまでを網羅的に解説しました。

RAGは、LLMに自社のデータを「学習」させるのではなく、必要な情報をリアルタイムに「検索」して与えることで、LLMの持つハルシネーションや知識の陳腐化といった課題を解決し、ビジネスの現場で安全かつ効果的に活用するための強力なパラダイムです。

その心臓部であるEmbeddingとVector DBは、非構造化データであるテキストを「意味」で扱えるようにする革新的な技術であり、これからのAIアプリケーション開発においてますます重要性を増していくでしょう。

今日学んだことをまとめると、以下のようになります。

• LLMの限界を克服するため、RAGは「検索」と「生成」を組み合わせる。
• Embeddingがテキストを意味的ベクトルに変換し、Vector DBがそれを高速に検索する。
• LangChainのようなフレームワークを使えば、RAGパイプラインを効率的に構築できる。
• RAGは知識の注入に、ファインチューニングは振る舞いの調整に適している。
• 実用的な性能を出すには、Chunking、Hybrid Search、Re-rankingなどの高度なテクニックが鍵となる。

RAGはまだ発展途上の技術であり、日々新しい手法が提案されています。しかし、本記事で解説した基礎をしっかりと理解していれば、その進化にキャッチアップしていくことは十分に可能です。

まずは、あなた自身のPCで、身近なドキュメントを使って小さなRAGシステムを構築してみてください。自分のデータに基づいてAIが的確な回答を生成する体験は、きっと新たなインスピレーションを与えてくれるはずです。この記事が、あなたのAIエージェント開発の第一歩となることを願っています。