RAGの基本構造と応用アイデア

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

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

AI Infographics Collection