RAGの基本構造と応用アイデア
検索システムと生成系LLMを結合し、根拠付きの回答を実現するアーキテクチャ
2025年4月28日
なぜRAGが必要か
LLM単体の3つの弱点を補うアーキテクチャ
📚 知識が学習時点で止まる
例: 「2025年EU AI Actの最終条文は?」
→ RAG対策 検索フェーズで最新版の条文PDFを取得・要約
💭 ハルシネーション
例: 架空の論文を引用
→ RAG対策 検索結果を引用付きで提示→出典がなければ生成を抑制
📄 長文コンテキストに弱い
例: 200ページのマニュアル要約
→ RAG対策 必要箇所だけベクトル検索で抽出し、短いプロンプトに注入
RAG 5レイヤー構成
俯瞰図
1. コーパス(生テキスト / PDF / DB)
(a) Chunk & Embed
2. ベクトルストア(pgvector / Pinecone …)
(b) Similarity / Hybrid Search
3. リトリーバ (Top-k, Filter, Rerank)
(c) Prompt Assembly
4. LLM (Generator)
(d) Post-process / Cite
5. Application UI / API
✨ 情報の流れ ✨
- 文書を小さく分割→埋め込みベクトル化
- クエリもベクトル化し、類似度orハイブリッドで検索
- 上位文書をテンプレに挿入(メタデータも付加)
- 生成結果を検証し、引用リンクや要約を返却
RAGの性能評価
指標 | どこを見る? | 計算方法 |
---|---|---|
Recall@k | 検索 | 正解文書がTop-kに含まれる率 |
Relevance | 生成 | 参考回答との類似度 |
Faithfulness | 生成 | 生成文の全根拠がソースに存在するか |
Latency/Cost | 全体 | ms・$ per 1k req |
💡 テストセット作り:社員FAQ+正答、APIドキュメントQ&Aなど "質問↔根拠"ペアを100件程度ラベリングすると 実務評価しやすい!
コンポーネント詳細(1)
2.1 コーパス準備 📚
項目 | ベストプラクティス |
---|---|
チャンクサイズ | 300–800 tokens(文脈保持と検索ヒット率の両立) |
オーバーラップ | 10–20 % → 文の切れ目をまたぐ情報欠落を防止 |
メタデータ | タイトル・日付・アクセス制御タグをJSONで付与 |
2.2 ベクトルストア 🗄️
選定軸: スケール(10M→分散必須)、フィルタ検索、コスト
Pinecone: 高速マルチテナント
pgvector: 手軽にPostgres拡張
Weaviate: GraphQL API
2.3 リトリーバ&リランカー 🎯
層 | 役割 | 代表実装 |
---|---|---|
1st (Recall) | Top-k 類似度検索(高速) | vector_db.similarity_search() |
2nd (Filter) | アクセス権・言語などで絞込 | メタデータ条件 |
3rd (Rerank) | クロスエンコーダで関連度を再計算 | Cohere Rerank, ColBERT |
コンポーネント詳細(2)
2.4 LLMプロンプト設計 ✏️
You are a helpful agent.
Answer with **reference tags** like [doc1] …
<references> ← Top-k ドキュメントをここに追加
- インストラクション → 役割 & 出力形式
- コンテキスト → 検索結果 (400–2,000 tokens)
- クエリ再掲 → 「あなたは何を答えるか」の明示
2.5 ポストプロセス 🔄
- 引用タグをURLに置換
- 検索ヒットなし → 「情報なし」と明示しハルシネを抑止
- キャッシュキー:hash(query + retrieved_ids) でコスト削減
よくある落とし穴と対策
症状 | 原因 | 処方箋 |
---|---|---|
関係ない文書が混じる | チャンクが大き過ぎ/類似度のみ検索 | BM25+ベクトル or Rerank導入 |
ハルシネーション復活 | コンテキスト長オーバーで切り捨て | Top-kを絞りつつ要約を前段に挿入 |
計算コスト増大 | LLMへ長文投入 | Map-Reduce Summarizationで一次要約→短縮 |
応用ユースケース6選
法務レビュー
契約書+判例ベースで条項チェック
リスク抜け漏れを定量可視化
カスタマーサポート
過去チケットを自動引用し回答ドラフト
平均応答時間 ▲60%
IoTトラブルシュート
デバイスログ→既知KBを検索→修復手順生成
現場復旧時間 ▲50%
コードアシスト
リポジトリ全体から類似実装を再利用
再発明防止・品質均一化
社内ナレッジ検索
Confluence, SharePointを統合しQ&A出力
問合せ工数 ▲70%
金融リサーチ
10-K, カンファレンスコールから企業概要を要約
アナリスト工数 ▲40%
💡 業界ごとの具体的な効果が見えるのがRAGの強み!
ミニ実装(LangChain + pgvector)
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores.pgvector import PGVector
from langchain.retrievers import ContextualCompressionRetriever
from langchain.chat_models import ChatOpenAI
from langchain.chains import RetrievalQA
# ① ベクトルストア接続
db = PGVector(connection_string="postgresql://user:pwd@localhost/mydb",
collection_name="docs",
embedding_function=OpenAIEmbeddings())
# ② Retriever + Rerank
retriever = ContextualCompressionRetriever.from_llm(
base_retriever=db.as_retriever(search_kwargs={"k":20}),
llm=ChatOpenAI(model="gpt-4o-mini")
)
# ③ RAGチェーン
rag = RetrievalQA.from_chain_type(
llm=ChatOpenAI(model="gpt-4o-mini", temperature=0),
chain_type="stuff", retriever=retriever)
answer = rag({"query": "EU AI Actの施行スケジュールを教えて"})
まとめ & 次のステップ
1 RAG = 検索 × LLM。設計は「どの文書を、どれだけ、どう挿入するか」が核心
2 3層検索(Recall→Filter→Rerank) で精度と速度を両立
3 評価指標を整備し、P0:ハルシネ率、P1:応答時間で運用モニタ
4 応用余地は 社内検索・文書要約・分析自動化 など無限大
5 まずは小規模 Corpus+pgvector+LangChain で PoC → KPI 計測 → スケール検討
✨ RAGでLLMアプリの信頼性と有用性を高めよう! ✨