F3. 知識ベースと RAG

トラック: Path 0: AI 基礎 · モジュール: F3 最終更新: 2026-07-31 難易度: 中級 所要時間: 2 時間 前提モジュール: F1 AI 技術の変遷、F2 プロンプトエンジニアリング

flowchart LR
F1["F1 AI 技術の変遷"]
F1 --> F2
F2["F2 プロンプトエンジニアリング"]
F2 --> F3
F3[" F3 知識ベースと RAG<br/>(現在地)"]:::current
F3 --> F4
F4["F4 自動化と Agent"]
classDef current fill:#ff9900,stroke:#333,color:#fff,font-weight:bold

章ナビゲーション

1. なぜ AI はあなたの商品情報を知らないのか · 2. Embedding の原理 · 3. ベクトルデータベース · 4. RAG アーキテクチャ · 5. 実践概要 · 6. RAG 最適化テクニック · 7. よくある質問 · 8. 学習リソース · 9. よくある罠 · 10. 完了チェック

このモジュールで理解できること

なぜ ChatGPT はあなたの商品情報を知らないのか? どうすれば AI にあなたの独自データに基づいて回答させられるのか? RAG がこの問題を解く中核技術です。

このモジュールを終えると:

• AI があなたの商品・ポリシー・社内データを知らない理由を理解できる
• Embedding(ベクトル埋め込み)の原理を平易な言葉で説明できる
• ベクトルデータベースとは何か、なぜ必要かがわかる
• RAG の完全なアーキテクチャとワークフローを理解できる
• どのシーンで RAG が必要か、不要かを判断できる
• 商品ナレッジベース構築の基本ステップを把握できる(コード実装は B3 RAG ナレッジベース参照)

このモジュールの位置づけ: 概念理解を作ること。コードは不要です。実際に RAG システムを構築したい場合は、修了後に Path B: B3 RAG ナレッジベースへ進んでください。

1. なぜ AI はあなたの商品情報を知らないのか

1.1 AI の知識はどこから来るのか

F1 の内容を思い出してください: LLM の知識はすべて学習データ由来です。学習データはインターネット上の公開テキスト — Wikipedia、ニュース、フォーラム、コードリポジトリなど。

AI が知っていること:

• Amazon プラットフォームの一般的なルールとポリシー(公開情報)
• よくあるカテゴリの一般的特徴(公開の議論)
• 汎用的な EC 運営の知識(ブログ、チュートリアル)

AI が知らないこと:

• あなたの商品の具体的なスペックと訴求点
• 社内の価格戦略と利益データ
• サプライヤー情報と仕入コスト
• 過去の販売データとトレンド
• CS の SOP と社内ポリシー
• 最新のプラットフォームポリシー変更(学習データには締切がある)

1.2 AI にあなたのデータを「知らせる」3 つの方法

1.3 越境EC のアナロジーで理解する

直接貼り付け = すべての資料を印刷して机に広げ、アシスタントに見せながら答えさせる。

• 資料が少ないうちは問題ない
• 多くなると机に載りきらない(コンテキストウィンドウの制限)

ファインチューニング = アシスタントに 1 か月かけて全資料を暗記させる。

• 暗記後の回答は速い
• しかし資料が更新されたら暗記し直し(再学習)
• 記憶が混ざる可能性もある(幻覚)

RAG = アシスタントに書類キャビネットと検索システムを与える。質問のたびに、アシスタントはまずキャビネットから関連資料を探し、それに基づいて答える。

• キャビネットはいつでも更新できる
• 回答の根拠が追える(具体的な文書まで遡れる)
• キャビネットは無限に大きくできる

結論: 越境EC チームにとって RAG が最も実用的です。データ量が多い、更新が頻繁、追跡可能性が必要 — この 3 つの特徴は RAG の強みに完璧に合致します。

2. Embedding の原理: AI に意味を「理解」させる

2.1 Embedding とは

Embedding(ベクトル埋め込み)は、テキストを数値の並び(ベクトル)に変換する技術です。この数値の並びがテキストの「意味」を捉えます。

直感的な理解:

地図上に商品を配置することを想像してください。従来の方法はキーワードマッチ — 「Bluetooth イヤホン」は、その文字列を含む文書しかマッチしません。

Embedding の方法は、各商品を「意味空間」に配置します:

• 「Bluetooth イヤホン」と「ワイヤレスイヤホン」は意味空間で近い(意味が似ている)
• 「Bluetooth イヤホン」と「Bluetooth スピーカー」は中くらいの距離(関連はあるが別物)
• 「Bluetooth イヤホン」と「キッチンナイフ」は意味空間で遠い(まったく無関係)

意味空間のイメージ(2D に簡略化):

オーディオ機器
↑
Bluetooth スピーカー    ワイヤレスイヤホン
Bluetooth イヤホン
スマートウォッチ    有線イヤホン

← ウェアラブル    アクセサリ →

スマホケース

キッチンナイフ(遠く離れて、この領域にはない)

実際の Embedding は 2D ではなく 768D や 1536D(数百〜数千次元)ですが、原理は同じ: 意味が似たテキストは、ベクトル距離が近い。

2.2 Embedding の処理過程

入力テキスト → Embedding モデル → ベクトル(数値の並び)

例:
「この Bluetooth イヤホンはノイズキャンセリングが優秀」
→ [0.12, -0.34, 0.56, 0.78, -0.23, ..., 0.45] (1536 個の数値)

「このワイヤレスイヤホンのアクティブノイキャンは素晴らしい」
→ [0.11, -0.32, 0.55, 0.79, -0.21, ..., 0.44] (1536 個の数値)

2 つのベクトルは非常に近い → 意味が似ている!

2.3 よく使われる Embedding モデル

越境EC での推奨:

• 低予算: OpenAI text-embedding-3-small(安くて優秀)
• 多言語ニーズ: BGE-M3(オープンソース無料、中英日独仏をサポート)
• データプライバシー: BGE-M3 ローカル展開(データがサーバーから出ない)

2.4 キーワード検索 vs 意味検索

実運用ではハイブリッド検索が最良: まずキーワード検索で範囲を絞り、次に意味検索で正確にマッチさせる。これが 2026 年の RAG システムの主流です。

3. ベクトルデータベース: 意味を保存し検索する

本節の数字は説明のために作ったものであり、実測値ではない。

3.1 なぜベクトルデータベースが必要か

通常のデータベース(MySQL、PostgreSQL)は正確なクエリが得意です: 「価格 = $25.99 の商品を探す」。

しかし意味的なクエリは苦手です: 「『ノイズキャンセリングが弱い』と意味が近いレビューを探す」。

ベクトルデータベースはベクトルの保存と検索のために設計されており、数百万のベクトルから最も似た数件をミリ秒で見つけられます。

3.2 主要ベクトルデータベースの比較

越境EC での推奨:

• まず試す: Chroma(最も簡単、10 行のコードで動く)
• 本番環境: Pinecone(運用レス)か Qdrant(セルフホスト)
• PostgreSQL がすでにある: pgvector(追加インフラ不要)

出典：Vector Databases 2026 Guide、Embeddings and Vector Databases Guide

3.3 ベクトルデータベースのワークフロー

書き込みフェーズ(一度きり):
文書 → チャンキング(分割)→ Embedding モデル → ベクトル → ベクトル DB へ保存

クエリフェーズ(質問のたび):
ユーザーの質問 → Embedding モデル → クエリベクトル → ベクトル DB 検索 → 最も似た文書チャンクを返す

チャンキング(分割)が鍵:

50 ページの製品マニュアルを 1 つのベクトルとして保存はできません — 大きすぎて意味が薄まります。文書を小さなチャンクに切る必要があります:

チャンキングの黄金律: 各チャンクは 1 つの完結した情報単位を含むこと。小さすぎると文脈を失い、大きすぎるとノイズが入る。500〜1,000 字がたいてい良い出発点です。

4. RAG アーキテクチャ: 完全なワークフロー

4.1 RAG の 3 つのステージ

ステージ 1: インデックス作成(Indexing)— 一度きりの準備

文書収集 → 文書分割 → Embedding 生成
↓ ↓ ↓
製品マニュアル 500 字/チャンク ベクトル化
FAQ 文書
レビューデータ → ベクトル DB へ保存
ポリシー文書


ステージ 2: 検索(Retrieval)— 質問のたび

ユーザーの質問 → クエリベクトル生成 → ベクトル DB 検索
↓ ↓
「この商品は防水?」 関連文書チャンク Top 5 を返す


ステージ 3: 生成(Generation)— 質問のたび

システムプロンプト + 検索された文書チャンク + ユーザーの質問
↓
LLM へ送信
↓
LLM が検索内容に基づいて回答を生成
「製品マニュアルによると、本製品は IPX5 防水に対応し...」

4.2 RAG vs AI に直接聞く場合の比較

シーン: 顧客が「お宅の Bluetooth イヤホンはどのバージョンに対応?」と質問

AI に直接聞く(RAG なし):

AI: 「一般的に、2024〜2025 年のイヤホンは Bluetooth 5.0 か 5.3 に対応して...」
→ 一般論。あなたの商品の具体的な情報ではない

RAG を使う:

RAG が検索した文書チャンク:
「製品型番 XB-500、Bluetooth バージョン 5.3、AAC/SBC/LDAC コーデック対応、
接続距離 15 m、2 台同時接続に対応。」

AI は検索内容に基づいて回答:
「当社の XB-500 は Bluetooth 5.3 に対応し、AAC、SBC、LDAC の
オーディオコーデックをサポート。接続距離は最大 15 m、
2 台のデバイスへの同時接続にも対応しています。」
→ 正確、具体的、あなたの商品データに基づいている

4.3 越境EC における RAG の応用シーン

関連: B3 RAG ナレッジベース 構築の実践は B3 へ · A4 カスタマーサービス CS FAQ 自動回答への応用は A4 へ。

4.4 RAG のプロンプト設計

RAG システムで LLM に送るプロンプトは通常 3 つの部分から成ります:

システムプロンプト(固定):
「あなたは製品カスタマーサポートのアシスタントです。以下の参考資料に
基づいてユーザーの質問に答えてください。参考資料に該当情報がない場合は、
わからない旨を明確に伝え、答えを作り出さないでください。
回答には情報源を明記してください。」

検索された文書チャンク(動的):
---参考資料ここから---
[チャンク 1]: 製品型番 XB-500、Bluetooth 5.3...
[チャンク 2]: 防水等級 IPX5、雨中での使用が可能...
[チャンク 3]: バッテリー: ANC オンで 30 時間、オフで 50 時間...
---参考資料ここまで---

ユーザーの質問(動的):
「このイヤホンは泳ぐときに使える?」

設計の重要原則:

4.5 RAG の評価指標

RAG システムを作った後、良し悪しをどう知るか? 2 つの次元で評価します:

検索品質:

生成品質:

簡単な評価方法:

テスト質問と模範回答を 20〜30 組用意し、定期的にテストを実行して品質の変化を追跡します。

テストセットの例:
| 質問 | 期待する回答 | 期待する引用文書 |
|------|--------------|------------------|
| 「Bluetooth バージョンは?」 | 「5.3」 | product_spec.md |
| 「水中で使える?」 | 「IPX5 防水。水しぶきは防げるが水没は不可」 | product_spec.md |
| 「保証期間は?」 | 「12 か月」 | warranty_policy.md |

4.6 RAG のコスト分析

コスト試算の例(小規模な商品ナレッジベース):

文書量: 製品マニュアル 50 冊 + FAQ 500 件 ≈ 約 200 ページ
Embedding 費用: $0.02(一度きり)
ベクトル DB: $0(ローカルの Chroma)
月間クエリ数: 1,000 回
LLM 費用: $5〜10/月(T3 高速級)
月額合計: $5〜10

人件費との比較:
CS が毎日 30 件の製品質問に回答 × 5 分/件 = 2.5 時間/日
月間人件費: 2.5h × 22 日 × $15/h = $825

ROI: ($825 − $10) / $10 = 8,150%

5. 実践概要: 商品ナレッジベースの構築

このセクションは概念的なステップの説明です。完全なコード実装は B3 RAG ナレッジベースを参照してください。

5.1 最小の RAG システム(コード 10 行)

LlamaIndex + Chroma なら、Python 10 行で使える RAG システムが作れます:

# 概念的なコード(完全版は B3 モジュール)
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader

# 1. 文書を読み込む(製品マニュアル、FAQ など)
documents = SimpleDirectoryReader("product_docs/").load_data()

# 2. インデックスを構築(自動分割 + Embedding + 保存)
index = VectorStoreIndex.from_documents(documents)

# 3. クエリエンジンを作成
query_engine = index.as_query_engine()

# 4. 質問する
response = query_engine.query("この製品の Bluetooth バージョンは?")
print(response)
# → 「製品マニュアルによると、XB-500 は Bluetooth 5.3 に対応し...」

5.2 構築ステップの概要

Step 1: 文書の収集(1〜2 時間)
製品マニュアル(PDF/Word)
FAQ 文書
CS のよくある質問と回答
製品スペック表
社内ポリシー文書

Step 2: 文書の前処理(30 分)
統一フォーマットへ変換(テキスト/Markdown)
フォーマットの問題を掃除(文字化け、余分な空行)
内容の完全性を確認

Step 3: RAG システムの構築(1〜2 時間)
依存のインストール(pip install llama-index chromadb)
Embedding モデルと LLM の設定
文書をロードしてインデックス構築
クエリの効果をテスト

Step 4: 最適化と運用(継続)
分割戦略の調整
検索パラメータの最適化
新しい文書の追加
回答品質のモニタリング

5.3 コードを書かずに使える RAG

コードを書きたくない場合、以下のツールが RAG 機能を標準装備しています:

6. RAG 最適化テクニック

6.1 RAG 品質を左右する要因

6.2 上級 RAG パターン(2026)

基本 RAG(Naive RAG):
質問 → 検索 → 生成
シンプルだが有効。大半のシーンに適合

上級 RAG(Advanced RAG):
質問 → クエリ書き換え → ハイブリッド検索 → リランキング → 生成
クエリ書き換え: LLM でユーザーの質問を最適化
ハイブリッド検索: キーワード + 意味の同時検索
リランキング: Cross-Encoder で検索結果を並べ直す
品質要求が高いシーンに

モジュラー RAG(Modular RAG):
質問 → ルーティング → 最適な検索戦略の選択 → 複数ソース検索 → 融合 → 生成
ルーティング: 質問タイプを判定し戦略を選択
複数ソース検索: 複数の知識ベースを同時に検索
融合: 複数ソースの結果を統合
複雑なエンタープライズ用途に

出典：RAG Architecture Guide 2026、RAG Systems Production Guide 2026

7. よくある質問

7.1 RAG FAQ

7.2 RAG が不要なケース

8. 学習リソース

8.1 入門におすすめ

8.2 さらに深く

9. よくある罠

9.1 RAG がハルシネーションを消すと思い込む

RAG が減らすのは「何もないところからの捏造」だ。「検索できたが読み違えた」「検索できないのに答えた」は消えない。本当の防御線は、プロンプトで出典の明記を求め、「資料にない」と答えることを許すことだ。

9.2 チャンク分割の既定値をそのまま使う

固定長の分割は仕様表やコンプライアンス条文を途中で断ち切る。取り出された断片が答えられないのは当然だ。EC では意味単位(1 SKU、1 ポリシー、1 FAQ)での分割のほうが、文字数での分割よりたいてい良い。

9.3 ナレッジベースを作るだけで保守しない

商品仕様、プラットフォームのポリシー、送料規則はいずれも変わる。RAG の最も多い失敗は技術的な問題ではなく、中の資料が半年放置されていることだ。それは使わないより危険になる。

9.4 データベースでやるべきことを RAG でやる

「先月どの SKU が一番売れたか」は SQL クエリであって意味検索の問題ではない。構造化クエリを RAG に押し込むと、遅くて不正確になる。

この方法が効かないとき

• 文書が数十件に満たないとき。 RAG の価値は「大量のテキストから関連する数段落を見つける」ところにある。製品マニュアルが十数件しかないなら、全文をコンテキストウィンドウに入れるほうが簡単で正確だ。今のモデルは数十万字を保持できるので、検索層はむしろ新しい失敗点を増やすだけになる。
• 必要な答えが位置ではなく集計のとき。 「全商品のうち返品率が高い上位 3 件は」— これは検索で答えられる問いではない。返ってくるのは似た段落であって合計ではない。この種はデータベースに聞くこと。検索型 QA が得意なのは「X はどこに書いてあるか」であり、「X は全部でいくつか」ではない。
• 文書自体が誤っている、または古いとき。 RAG は与えられたものを忠実に拾ってくる。2 年前の料率表がナレッジベースに残っていれば、2 年前の料率を自信満々で顧客に伝える。公開前の文書棚卸しは chunk_size の調整よりはるかに重要である。
• 誤答の責任を負う立場のとき。 サポートボットが顧客に直接返信する、コンプライアンス回答をそのまま申告に使う — こうした場面では、検索が空振りしたときに作文する RAG の性質が実害になる。人手レビューを挟むか、「見つからなければ知らないと言え」と Prompt で縛った上で、実際にそうなるか検証すること(本章 §7 のカスタマーサポート Prompt はこの用途である)。

10. 完了チェック

• AI があなたの商品情報を知らない理由を説明できる
• Embedding の概念を理解した(テキスト → ベクトル → 意味の類似度)
• ベクトルデータベースの役割と主要な選択肢を知っている
• RAG の 3 ステージ構成(インデックス → 検索 → 生成)を描ける
• あるシーンに RAG が必要かどうか判断できる
• コード不要の RAG 方案を最低 1 つ知っている(ChatGPT ファイルアップロード / Claude Projects)

以上をすべて完了すれば、AI に独自データを使わせる中核技術を理解できています。次は F4 自動化と Agentへ。AI に「答える」だけでなく「実行させる」方法を学びます。