1. モデル選定

2. コスト試算

月間リクエスト: 2,000 × 30 = 60,000
平均入力: 2,500 tokens（システムプロンプト1000 + 検索結果1200 + クエリ300）
平均出力: 400 tokens

GPT-4o-mini（90%のリクエスト = 54,000件）:
  Input: 54,000 × 2,500 / 1M × $0.15 = $20.25
  Output: 54,000 × 400 / 1M × $0.60 = $12.96
  小計: $33.21

GPT-4o（10%のリクエスト = 6,000件）:
  Input: 6,000 × 2,500 / 1M × $2.50 = $37.50
  Output: 6,000 × 400 / 1M × $10.00 = $24.00
  小計: $61.50

Embedding（text-embedding-3-small）:
  60,000 × 2,500 / 1M × $0.02 = $3.00

月間合計: 約 $97.71（予算 $2,000 の5%。十分余裕あり）

3. セキュリティ対応

• Azure OpenAI Japan East リージョンを使用（データは日本国内に留まる）
• Azure Private Endpoint で VNet 経由のアクセス
• Microsoft の Data, Privacy, and Security for Azure OpenAI 準拠
• ログにはユーザー入力を保存しない設定
• フォールバックの AWS Bedrock も Tokyo リージョン

4. スケーラビリティ

• Azure OpenAI の TPM (Tokens Per Minute) 制限を確認
• ピーク時 300 リクエスト/時 = 5 リクエスト/分。現在の制限では十分
• セマンティックキャッシュで重複クエリを削減（30-40%の節約見込み）
• 利用者が増えた場合はキャッシュの強化とモデルルーティングで対応

1. チャンキング戦略

2. メタデータ設計

// 共通メタデータ
interface CommonMetadata {
  documentId: string;
  documentTitle: string;
  documentType: 'tech-doc' | 'incident-report' | 'adr';
  team: string;
  updatedAt: Date;
  tags: string[];
}

// 技術ドキュメント固有
interface TechDocMetadata extends CommonMetadata {
  sectionPath: string[];    // ["API設計", "認証", "JWT"]
  technology: string[];     // ["TypeScript", "PostgreSQL"]
}

// インシデントレポート固有
interface IncidentMetadata extends CommonMetadata {
  severity: 'P1' | 'P2' | 'P3' | 'P4';
  section: 'summary' | 'cause' | 'impact' | 'resolution' | 'prevention';
  resolvedAt: Date;
}

// ADR固有
interface ADRMetadata extends CommonMetadata {
  adrNumber: number;
  status: 'proposed' | 'accepted' | 'deprecated' | 'superseded';
  decisionDate: Date;
}

3. オーバーラップの根拠

• 技術ドキュメント（50 tokens）: セクション間で用語の引き継ぎがあるため、前セクションの末尾を含めて文脈を保持
• インシデントレポート（30 tokens）: セクションが独立しているため最小限のオーバーラップ
• ADR（0）: 分割しないためオーバーラップ不要

1. パイプラインアーキテクチャ

graph TD
    Q["ユーザークエリ"] --> QA["Query Analysis
（クエリ分析）"]
    QA --> QA1["意図分類:
tech-doc / incident / adr / cross-cutting"]
    QA --> QA2["複雑度判定: simple / complex"]
    QA --> QA3["時間範囲抽出:
先月 → 日付フィルタ"]

    QA --> QP["Query Processing
（クエリ前処理）"]
    QP --> QP1["simple → そのまま検索"]
    QP --> QP2["complex → Query Decomposition で分解"]

    QP --> RL["Retrieval Layer"]
    RL --> RL1["Hybrid Search
Vector + BM25"]
    RL --> RL2["メタデータフィルタ
documentType, team, 日付範囲"]
    RL --> RL3["複数サブクエリの場合は並列検索"]

    RL --> RR["Re-ranking Layer"]
    RR --> RR1["Cross-Encoder Re-ranker
Cohere Rerank"]
    RR --> RR2["Top-5 に絞り込み"]

    RR --> GL["Generation Layer"]
    GL --> GL1["simple → GPT-4o-mini"]
    GL --> GL2["complex → GPT-4o"]

    GL --> PP["Post-processing"]
    PP --> PP1["Citation Extraction
出典の抽出"]
    PP --> PP2["Groundedness Check
忠実性検証"]
    PP --> PP3["Response formatting"]

    style Q fill:#1e293b,stroke:#475569,color:#f8fafc
    style QA fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e40af
    style QP fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e40af
    style RL fill:#d1fae5,stroke:#059669,color:#065f46
    style RR fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#92400e
    style GL fill:#f3e8ff,stroke:#7c3aed,color:#5b21b6
    style PP fill:#fee2e2,stroke:#dc2626,color:#991b1b
    style QA1,QA2,QA3,QP1,QP2 fill:#f3f4f6,stroke:#9ca3af,color:#374151
    style RL1,RL2,RL3,RR1,RR2 fill:#f3f4f6,stroke:#9ca3af,color:#374151
    style GL1,GL2,PP1,PP2,PP3 fill:#f3f4f6,stroke:#9ca3af,color:#374151

2. 使用テクニック

3. ルーティングロジック

class QueryRouter {
  async route(query: string): Promise<{
    documentTypes: string[];
    searchStrategy: 'simple' | 'decomposed';
    model: string;
    filters: Record<string, unknown>;
  }> {
    const analysis = await this.analyzeQuery(query);

    return {
      documentTypes: analysis.targetDocTypes,
      searchStrategy: analysis.isComplex ? 'decomposed' : 'simple',
      model: analysis.isComplex ? 'gpt-4o' : 'gpt-4o-mini',
      filters: {
        documentType: { $in: analysis.targetDocTypes },
        ...(analysis.dateRange && { updatedAt: analysis.dateRange }),
        ...(analysis.team && { team: analysis.team }),
      },
    };
  }
}

1. 評価データセット

2. メトリクスと目標値

3. CI/CD回帰テスト

# .github/workflows/rag-eval.yml
name: RAG Quality Gate
on:
  pull_request:
    paths:
      - 'src/rag/**'
      - 'prompts/**'

jobs:
  eval:
    steps:
      - name: Run golden set evaluation
        run: npm run rag:eval -- --dataset golden-set
      - name: Check quality gates
        run: |
          npm run rag:check-gates -- \
            --faithfulness 0.90 \
            --relevancy 0.85 \
            --recall 0.80
      - name: Report results
        run: npm run rag:report >> $GITHUB_STEP_SUMMARY

4. A/Bテスト設計

graph TD
    EXP["実験: Re-ranking の効果検証"]
    EXP --> CTRL["Control 50%
Naive vector search → LLM"]
    EXP --> TREAT["Treatment 50%
Vector search → Cohere Rerank → LLM"]

    MET["メトリクス"]
    MET --> M1["Primary:
ユーザー満足度（サムズアップ/ダウン）"]
    MET --> M2["Secondary:
Faithfulness スコア"]
    MET --> M3["Guardrail:
レイテンシが3秒を超えないこと"]

    CFG["実験設定"]
    CFG --- C1["期間: 2週間"]
    CFG --- C2["サンプルサイズ: 各群 10,000 クエリ"]
    CFG --- C3["有意水準: p < 0.05"]

    style EXP fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e40af
    style CTRL fill:#d1fae5,stroke:#059669,color:#065f46
    style TREAT fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#92400e
    style MET fill:#f3e8ff,stroke:#7c3aed,color:#5b21b6
    style M1,M2,M3 fill:#f3f4f6,stroke:#9ca3af,color:#374151
    style CFG fill:#1e293b,stroke:#475569,color:#f8fafc
    style C1,C2,C3 fill:#f3f4f6,stroke:#9ca3af,color:#374151