RAGの精度が上がらない原因チェックリスト｜実務でそのまま使える改善ガイド（AWS / Kubernetes対応）

1. 結論（最初に答え）

RAG（Retrieval-Augmented Generation）の精度が上がらない最大の原因は、「検索精度（Retrieval）」「分割設計（Chunking）」「Embedding品質」「再ランキング不足」の4つのどれか、または複合です。

最短で改善するには以下の順でチェックするのが実務的です：

• ① Chunk設計（500〜1000 tokensに適切分割されているか）
• ② Embeddingモデルの品質（text-embedding-3-large等）
• ③ ベクトル検索の精度（Top-k / フィルタリング）
• ④ Rerankモデルの有無（Cross Encoder未使用が多い）
• ⑤ プロンプト設計（コンテキスト過多 or 指示不足）

---

2. そもそもRAGとは何か（初心者向け）

RAGは「検索 + 生成」を組み合わせたLLM拡張構成です。 LLM単体の幻覚（hallucination）を抑えるために、外部知識を検索して回答に利用します。

• 検索（Retriever）：関連ドキュメント取得
• 生成（Generator）：LLMで回答生成

AWSでは以下構成がよく使われます：

• S3：ドキュメント保管
• OpenSearch（Vector）：ベクトル検索
• Lambda / ECS / Kubernetes：API層

---

3. 仕組み解説（技術アーキテクチャ）

この構成で重要なのは「Vector検索の質」ではなくその前後（Embedding / Rerank / Chunk設計）です。

---

4. 実装手順（再現可能）

■使用技術

• Python 3.11
• FastAPI
• OpenAI Embedding API
• FAISS（ローカル検証用）

■ディレクトリ構成

rag-project/
├── app/
│   ├── main.py
│   ├── rag.py
│   ├── embedding.py
├── data/
│   ├── docs.txt
├── requirements.txt

■コード例（FastAPI + RAG最小構成）

# app/main.py
from fastapi import FastAPI
from rag import retrieve_and_answer

app = FastAPI()

@app.get("/ask")
def ask(q: str):
    return {"answer": retrieve_and_answer(q)}

# app/rag.py
from embedding import search_docs
import openai

def retrieve_and_answer(query: str):
    docs = search_docs(query)

    context = "\n".join(docs)

    response = openai.chat.completions.create(
        model="gpt-4.1",
        messages=[
            {"role": "system", "content": "You are a precise assistant."},
            {"role": "user", "content": f"Context:\n{context}\n\nQ:{query}"}
        ]
    )

    return response.choices[0].message.content

■起動方法

pip install fastapi uvicorn openai
uvicorn app.main:app --reload

■動作確認

curl "http://localhost:8000/ask?q=RAGとは何か"

---

5. 実務例（AWS / Kubernetes構成）

実務では以下構成が一般的です：

• EKS（Kubernetes）上にRAG APIを配置
• OpenSearch ServerlessでVector検索
• S3にドキュメント保管
• IRSAでIAM認証制御

特に障害が多いのは以下です：

• OpenSearchのシャード設計ミス → 検索遅延
• Embeddingコスト増大 → 大量ドキュメントで課金爆発
• KubernetesのHPA設定不足 → 負荷スパイクでタイムアウト

---

6. メリット・デメリット

項目	メリット	デメリット
RAG構成	最新情報を反映できる / 幻覚抑制	構築が複雑 / コスト高
LLM単体	シンプル / 低コスト	情報が古い / 幻覚発生
Fine-tuning	特定領域で高精度	更新が困難 / 再学習コスト高

---

7. よくあるエラーと対策

① 検索は成功するが回答がズレる

事象：

Retrieved context is irrelevant but similarity score is high

原因：

Chunkが大きすぎて意味が混在しているため、Embeddingが誤った類似度を返している。

対策：

• Chunkサイズを 300〜800 tokensに変更
• Sentence-based splitを導入

---

② OpenSearchで検索ヒットしない

事象：

No documents returned from vector search

原因：

Embeddingモデル変更後に再indexしていないためベクトル空間が不整合。

対策：

1. 全ドキュメント再Embedding
2. Index再構築

---

③ LLMが無関係な回答を生成する

事象：

Contextを渡しているのに無視する

原因：

プロンプトに「Context優先指示」がない

対策：

Use ONLY the provided context. If not enough information, say "I don't know".

---

8. まとめ

RAG精度改善は「LLMの問題」ではなく、ほぼ100%がデータパイプライン設計の問題です。

特に重要なのは以下です：

• Chunk設計
• Embeddingモデル
• Rerank導入
• 検索インデックス設計

本番環境では「精度」よりも「コスト・遅延・再現性」がボトルネックになるため、AWS / Kubernetes前提で設計することが重要です。