AIインフォグラフィックス集

AI Infographics Collection

RAGの基本構造と応用アイデア - グラフィックレコーディング

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アプリの信頼性と有用性を高めよう! ✨