RAG 2.0 実装ロードマップ - 残存機能と将来フェーズ

Last Updated: 2026-05-23
Status: Implementation Planning + Operational Hardening Implemented
Owner: RAG System Development Team

---

概要

RAG 2.0 プロジェクトの実装フェーズと残存機能を体系的に管理するドキュメント。 Phase 1～5 は RAG_JAPANESE_SpecV2.md に詳述。本ドキュメントは Phase 6 以降の拡張機能と継続的な改善を管理。

---

実装済み・計画中フェーズ概観

┌─────────────────────────────────────────────────────────────────┐
│                    RAG 2.0 Implementation Timeline               │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│ Phase 1 (Prep)      Phase 2 (KW Opt)    Phase 3 (Semantic)    │
│ ─────────────       ──────────────────   ────────────────       │
│ • Sudachi          • Sudachi + ES       • Query Expansion       │
│ • NER Model        • Index Rebuild      • NER Integration       │
│ • Test Cases       • Evaluation         • Entity Boosting       │
│ [2-3 days]         [2-3 days]          [3-4 days]             │
│                                                                 │
│         ↓                    ↓                    ↓            │
│ ┌─────────────┐    ┌──────────────┐    ┌──────────────┐        │
│ │   READY     │    │  MRR > 0.7   │    │ Recall > 0.8 │        │
│ └─────────────┘    └──────────────┘    └──────────────┘        │
│                                                                 │
│ Phase 4 (Integration)    Phase 5 (Operations)                 │
│ ──────────────────       ───────────────────                  │
│ • RRF Tuning            • Dashboard                           │
│ • Full Test             • Monitoring                          │
│ • Production            • Feedback Loop                       │
│ [2-3 days]              [Ongoing]                             │
│                                                                 │
│         ↓                    ↓                                │
│ ┌─────────────┐    ┌──────────────┐                          │
│ │NDCG > 0.75  │    │ Production   │                          │
│ └─────────────┘    └──────────────┘                          │
│                                                                 │
│ Phase 6+ (REMAINING - This Document)                          │
│ ────────────────────────────────────                          │
│ • Context-aware RRF                                            │
│ • Advanced NER fine-tuning                                     │
│ • Relevance Feedback Loop                                      │
│ • Multilingual Expansion                                       │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

---

Phase 1-5: 既定フェーズ（詳細は RAG_JAPANESE_SpecV2.md を参照）

Phase	名前	期間	主要タスク	Exit Criteria
1	準備・検証	2-3日	Sudachi/NER/Test Cases	テストセット frozen
2	KW検索最適化	2-3日	Sudachi + ES統合	MRR > 0.7
3	Semantic最適化	3-4日	Query Exp + NER	Recall > 0.8
4	統合・最適化	2-3日	RRF調整 + 全テスト	NDCG > 0.75
5	運用・監視	継続	ダッシュボード + Feedback	SLA達成

---

2026-05-22 実装反映（RAG v2 厳格化・運用監視）

以下は EvoSpikeNet-Core の実装に反映済みです（evospikenet/api_modules/rag_v2_api.py）。

• v2 API 厳格化:
• POST /api/v2/rag/search と POST /api/v2/rag/feedback の失敗時 fail-closed 挙動を強化。
• 前処理依存（Sudachi/NER/QueryExpander）不備時に 503 を返し、曖昧なフォールバックを抑止。
• 前処理モジュール分離:
• SudachiTokenizer / EntityRecognizer / QueryExpander を明示分離し、責務を整理。
• Sudachi バージョンガード:
• 期待値（既定）sudachipy=0.7.5、辞書 20240716 を検証。
• 本番系では不一致をエラー化、非本番は警告運用。
• QueryExpander 強化:
• バックエンド rule|llm|hybrid を実装。
• LLM 拡張は JSON スキーマ固定（{"expansions": [...]}）で解析。
• 不正JSONは strict 時に例外、非 strict 時は deterministic 経路へ退避。
• 品質ガード実装:
• diversity_score / redundancy_rate による品質しきい値評価。
• 低品質時は llm/hybrid から rule へ自動フォールバック。
• 可観測性:
• GET /api/v2/rag/preprocessing/health 追加。
• debug_info.preprocessing に query_expansion_quality、query_expansion_guard、query_expansion_guard_stats、query_expansion_guard_history、query_expansion_guard_hash_summary を出力。
• ガード履歴はリングバッファ運用（時刻、理由、fallback_backend、query_hash、quality snapshot）。

新規/更新された主要環境変数

• RAG_V2_NER_BACKEND (transformers|regex)
• RAG_V2_NER_MODEL
• RAG_V2_PREPROCESSING_WARMUP
• RAG_V2_PREPROCESSING_WARMUP_STRICT
• RAG_V2_SUDACHI_VERSION
• RAG_V2_SUDACHI_DICT_VERSION
• RAG_V2_SUDACHI_DICT_DIST_NAMES
• RAG_V2_QUERY_EXPANDER_BACKEND (rule|llm|hybrid)
• RAG_V2_QUERY_EXPANDER_STRICT
• RAG_V2_QUERY_EXPANDER_LM_BACKEND
• RAG_V2_QUERY_EXPANDER_QUALITY_GUARD
• RAG_V2_QUERY_EXPANDER_MIN_DIVERSITY
• RAG_V2_QUERY_EXPANDER_MAX_REDUNDANCY
• RAG_V2_QUERY_EXPANDER_GUARD_HISTORY_SIZE

残タスク（本ドキュメント上の今後フェーズ）

• Context-aware RRF の本格導入（Phase 6）
• Domain-specific NER の本格ファインチューニング（Phase 7）
• フィードバックループの自動調整（Phase 8）
• 多言語拡張（Phase 9）

---

2026-05-23 実装反映（RAG v2 記憶ランキング契約の同期）

以下は EvoSpikeNet-Core の実装と RAG_JAPANESE_SpecV2.md v3.1 に反映済みです。

• 拡張クエリ間 RRF 統合:
  • 同一 doc_id が複数の拡張クエリ結果に出現した場合、RRF スコアを加算して統合。
• 記憶強化ランキング:
  • RAGMemoryIntegrator.compute_memory_boost() の結果を final_score に加算。
  • final_score で再ソートした後に rank を確定。
• API 契約同期:
  • POST /api/v2/rag/search の session_id、memory_context、results[].memory_boost を仕様へ明示。
  • POST /api/v2/rag/feedback は session_id 必須、成功時に memory_id と importance を返す契約へ同期。
• テスト階層追加:
  • Unit: 記憶強化ランキング計算。
  • Integration: API 経由の memory_boost 最終順位反映。
  • System: 拡張クエリ間 RRF 加算の仕様契約。
  • E2E: 検索からフィードバック記録までのメモリ連携ジャーニー。

---

Phase 6: 文脈認識検索の高度化（新規フェーズ）

6.1 Context-Aware RRF の実装

目的: エピソード記憶（いつ、誰が、どの文脈で）を重み付けに反映

背景: 現在、RRF は BM25 スコアとベクター距離を均等に扱っています。 しかし、検索ユーザーの文脈（例：プロジェクトA に属している）を考慮すると、 より精緻なランキングが可能になります。

実装仕様:

class ContextAwareRRF:
    """文脈を考慮した RRF"""

    def __init__(self, user_context: Dict[str, Any]):
        self.project_id = user_context.get("project_id")
        self.department = user_context.get("department")
        self.timestamp = user_context.get("timestamp")
        self.search_history = user_context.get("search_history", [])

    def compute_context_weight(self, doc: Dict) -> float:
        """
        ドキュメントのメタデータに基づいて、文脈重みを計算

        返値: 0.5 ~ 2.0 の重み倍数
        - 関連度高: 2.0
        - 中立: 1.0
        - 関連度低: 0.5
        """
        weight = 1.0

        # プロジェクト一致
        if doc.get("project_id") == self.project_id:
            weight *= 1.5

        # 部門一致
        if doc.get("department") == self.department:
            weight *= 1.2

        # 検索履歴との関連度
        for prev_query in self.search_history[-5:]:
            if prev_query in doc.get("source", ""):
                weight *= 1.1

        # 時間的な鮮度
        doc_age_days = (self.timestamp - doc.get("updated_at")).days
        recency_penalty = max(0.5, 1.0 - (doc_age_days / 365) * 0.3)
        weight *= recency_penalty

        return min(weight, 2.0)

    def reciprocal_rank_fusion_with_context(
        self,
        search_results_lists: List[List[Dict]],
        k: int = 60
    ) -> List[str]:
        """
        文脈重みを考慮した RRF
        """
        fused_scores = {}

        for results in search_results_lists:
            for i, result in enumerate(results):
                doc_id = result["id"]
                base_score = 1 / (k + i + 1)
                context_weight = self.compute_context_weight(result)
                weighted_score = base_score * context_weight

                fused_scores[doc_id] = fused_scores.get(doc_id, 0) + weighted_score

        reranked = sorted(fused_scores.items(), key=lambda x: x[1], reverse=True)
        return [doc_id for doc_id, _ in reranked]

期間: Phase 5 の 3-4 週間後、2-3 週間の実装

期待効果: - NDCG@10: 0.75 → 0.82 (+9%) - ユーザー満足度: 85% → 92%

---

Phase 7: 高度な固有表現認識の微調整

7.1 Domain-Specific NER Fine-tuning

目的: 組織・部門・プロジェクトIDなど、社内固有の固有表現を認識精度 95% 以上で抽出

背景: 標準 NER モデルでは、社内プロジェクトコード「EV-2024-001」や 部門名「AIシステム開発部」の認識精度が不十分（80-85%）。

実装仕様:

class DomainSpecificNER:
    """組織固有の固有表現認識"""

    def __init__(self, base_model: str = "tner/roberta-large-japanese-char-luw-ner"):
        self.base_model = base_model
        self.fine_tuned_model = None
        self.entity_dict = self._load_internal_entities()

    def _load_internal_entities(self) -> Dict[str, List[str]]:
        """社内辞書から固有表現を読み込み"""
        return {
            "PROJECT_ID": ["EV-2024-001", "EV-2024-002", "SPIKE-00123"],
            "DEPARTMENT": ["AIシステム開発部", "データサイエンス部", "研究開発グループ"],
            "PRODUCT": ["EvoSpikeNet Pro", "EvoSpikeNet Core"],
            "PERSON": ["田中太郎", "山田花子"]
        }

    def fine_tune_on_internal_data(
        self,
        training_data: List[Dict],
        num_epochs: int = 3
    ):
        """
        社内アノテーションデータで微調整
        """
        from transformers import AutoModelForTokenClassification, Trainer

        model = AutoModelForTokenClassification.from_pretrained(self.base_model)
        # 微調整処理
        self.fine_tuned_model = model

    def extract_entities_with_dict_matching(self, text: str) -> List[Dict]:
        """
        モデル予測 + 辞書マッチングのアンサンブル
        """
        # モデル予測
        model_predictions = self._predict_with_model(text)

        # 辞書マッチング
        dict_matches = self._match_against_internal_dict(text)

        # マージ（重複排除、信頼度統合）
        merged = self._merge_predictions(model_predictions, dict_matches)

        return merged

期間: Phase 5 の 4 週間後、3-4 週間の実装

期待効果: - Entity Recall: 85% → 95% - Entity Precision: 88% → 96%

---

Phase 8: ユーザーフィードバックループの自動化

8.1 Relevance Feedback と Self-Learning

目的: ユーザーの「関連性」評価から自動的にモデル・ルールを改善

背景: 初期段階の検索結果は「期待値」で評価されます。これらのフィードバックを 蓄積し、モデルのパラメータを自動調整することで、継続的な精度向上が可能。

実装仕様:

class FeedbackLoop:
    """ユーザーフィードバックの収集と学習"""

    def __init__(self, rag_system, feedback_db):
        self.rag = rag_system
        self.db = feedback_db

    def record_feedback(
        self,
        query: str,
        doc_id: str,
        rating: int,
        user_id: str,
        timestamp: datetime
    ):
        """ユーザーフィードバックを記録"""
        feedback = {
            "query": query,
            "doc_id": doc_id,
            "rating": rating,
            "user_id": user_id,
            "timestamp": timestamp
        }
        self.db.insert(feedback)

    def analyze_feedback_patterns(self, window_days: int = 30) -> Dict:
        """
        過去N日のフィードバックから問題パターンを抽出
        """
        feedbacks = self.db.query_recent(days=window_days)

        patterns = {
            "low_rated_queries": [],
            "false_negatives": [],
            "entity_misses": [],
            "variation_issues": []
        }

        for feedback in feedbacks:
            if feedback["rating"] <= 2:
                if self._is_entity_query(feedback["query"]):
                    patterns["entity_misses"].append(feedback)
                elif self._is_variation_query(feedback["query"]):
                    patterns["variation_issues"].append(feedback)

        return patterns

    def auto_adjust_parameters(self, patterns: Dict):
        """
        フィードバックパターンに基づいて、自動的にパラメータを調整
        """
        if len(patterns["entity_misses"]) > 5:
            self.rag.entity_boost_weight *= 1.1
            logging.info("Auto-increased entity boost weight")

        if len(patterns["variation_issues"]) > 5:
            self.rag.query_expansion_enabled = True
            logging.info("Auto-enabled query expansion")

期間: Phase 6 の 2 週間後、2-3 週間の実装

期待効果: - 月次の NDCG 改善率: 0.5-1.0%（継続的な向上） - ユーザー満足度の自動向上

---

Phase 9: 多言語・多地域対応

9.1 Multilingual RAG Extension

目的: 英語、中国語、その他言語にも対応

現在の状況: - 日本語: 完全対応（Phase 1-5 で実装） - 英語: 基本対応（言語検出のみ） - その他: 未対応

実装仕様:

class MultilingualRAG:
    """多言語対応 RAG"""

    LANGUAGE_CONFIGS = {
        "ja": {
            "tokenizer": "sudachi",
            "stop_words": "ja_stop",
            "embedding_model": "paraphrase-multilingual-MiniLM-L12-v2",
            "ner_model": "tner/roberta-large-japanese-char-luw-ner"
        },
        "en": {
            "tokenizer": "english",
            "stop_words": "english",
            "embedding_model": "paraphrase-multilingual-MiniLM-L12-v2",
            "ner_model": "dslim/bert-base-NER"
        },
        "zh": {
            "tokenizer": "chinese",
            "stop_words": "chinese",
            "embedding_model": "paraphrase-multilingual-MiniLM-L12-v2",
            "ner_model": "uer/roberta-base-chinese-cluener"
        }
    }

    def retrieve_multilingual(self, query: str, languages: List[str] = None) -> Dict:
        """
        複数言語で同時検索
        """
        results = {}
        for lang in languages:
            if lang in self.supported_languages:
                detected_lang = self._detect_language(query)

                if detected_lang == lang:
                    results[lang] = self.rag.retrieve(query, lang_config=self.LANGUAGE_CONFIGS[lang])
                else:
                    translated_query = self._translate(query, detected_lang, lang)
                    results[lang] = self.rag.retrieve(translated_query, lang_config=self.LANGUAGE_CONFIGS[lang])

        return results

期間: Phase 7 の 3 週間後、4-5 週間の実装

期待効果: - グローバル対応の実現 - ユーザーベースの拡大

---

Phase 10: リアルタイム更新とストリーミング

10.1 Real-time Index Updates

目的: ドキュメントが追加・更新された時、即座にインデックスに反映

現在: - バッチ更新（数時間～数日のラグ）

改善後: - リアルタイム更新（秒単位）

実装仕様:

class RealtimeRAGIndexer:
    """リアルタイムインデックス更新"""

    def __init__(self, milvus_client, es_client):
        self.milvus = milvus_client
        self.es = es_client
        self.update_queue = asyncio.Queue()

    async def process_updates(self):
        """
        キューから取得したドキュメントを非同期処理
        """
        while True:
            doc = await self.update_queue.get()

            try:
                embedding = self._generate_embedding(doc["text"])

                await self._update_milvus(doc["id"], embedding, doc)
                await self._update_elasticsearch(doc["id"], doc)

                logging.info(f"Document {doc['id']} updated in real-time")
            except Exception as e:
                logging.error(f"Failed to update document: {e}")
                await self.update_queue.put(doc)

期間: Phase 8 の 2 週間後、3-4 週間の実装

期待効果: - 情報の鮮度向上 - ユーザー体験の向上

---

Phase 11: 推論の説明可能性（Explainability）

11.1 検索結果の根拠表示

目的: ユーザーに「なぜこのドキュメントが出現したのか」を説明

実装例:

class ExplainableRAG:
    """説明可能な検索結果"""

    def retrieve_with_explanation(self, query: str, top_k: int = 5) -> List[Dict]:
        """
        検索結果に根拠を付与
        """
        results = []

        docs, debug_info = self.rag.retrieve(query, return_debug_info=True)

        for i, doc in enumerate(docs[:top_k]):
            explanation = {
                "document": doc,
                "rank": i + 1,
                "reasons": [
                    {
                        "type": "keyword_match",
                        "matched_terms": debug_info["keyword_results"][i]["matched_keywords"],
                        "score": debug_info["keyword_results"][i]["score"]
                    },
                    {
                        "type": "semantic_similarity",
                        "similarity": debug_info["vector_results"][i]["score"],
                        "explanation": "クエリとのセマンティック距離が小さい"
                    },
                    {
                        "type": "rrf_fusion",
                        "combined_score": debug_info["rrf_scores"][doc["id"]]
                    }
                ]
            }
            results.append(explanation)

        return results

期間: Phase 9 の 1 週間後、2 週間の実装

期待効果: - ユーザーの信頼向上 - デバッグ・最適化の効率化

---

マイルストーン概観

Phase	名前	開始時期	期間	主要成果
1	準備	Immediate	2-3日	テストセット frozen
2	KW最適化	Week 1	2-3日	MRR 0.7+
3	Semantic最適化	Week 2	3-4日	Recall 0.8+
4	統合・最適化	Week 3	2-3日	NDCG 0.75+
5	運用・監視	Week 4	継続	本番稼働
6	文脈認識RRF	Week 7	2-3週	NDCG 0.82+
7	Domain NER	Week 10	3-4週	Entity Recall 95%+
8	Feedback Loop	Week 13	2-3週	自動改善
9	多言語対応	Week 16	4-5週	Global Ready
10	Real-time更新	Week 21	3-4週	秒単位更新
11	説明可能性	Week 25	2週	Explainable RAG

---

リソース計画

Phase 1-5 （必須）

ロール	FTE	期間
ML Engineer	1.5	2週
Backend Engineer	1.5	2週
QA / Test	0.5	2週
合計	3.5	2週

Phase 6-11 （拡張・オプション）

ロール	FTE	期間
ML Engineer	1.0	8週
Backend Engineer	1.0	8週
DevOps	0.5	8週
合計	2.5	8週

---

成功指標（Success Metrics）

Phase 1-5 のゴール

メトリクス	初期値	目標値	達成期限
Variation MRR	0.42	0.70	Week 3
Entity Recall	0.35	0.80	Week 4
Overall NDCG	0.55	0.75	Week 4
ユーザー満足度	78%	90%	Week 5

Phase 6-11 のゴール

メトリクス	目標値	達成期限
Context-aware NDCG	0.82	Week 8
Entity Precision	0.96	Week 11
Self-learning NDCG向上	+0.5-1.0%/月	Week 13
グローバル対応	3言語	Week 21

---

依存関係と制約

外部依存

• ✅ Sudachi / TNER / Elasticsearch - 利用可能
• ⚠️ 社内用語辞書 - Phase 1 中に構築が必要
• ⚠️ ユーザーフィードバック機能 - Phase 5 で実装

技術的制約

• GPU メモリ: NER モデル実行に 8GB 以上推奨
• Elasticsearch ストレージ: インデックス再構築時に 2倍必要
• Milvus クレディット: 大規模インデックス時に追加確保

---

リスク管理

リスク	確率	影響	対策
Sudachi の依存性問題	中	高	代替案（Mecab）の準備
NER モデルの精度不足	低	中	社内データでの微調整
インデックス再構築の時間超過	中	中	incremental インデックス戦略
ユーザーフィードバック収集不足	中	中	インセンティブ機構の導入

---

Document Version: 1.0
Status: Ready for Implementation
Owner: RAG Development Team
Last Updated: 2026-05-20