ストーリー

MLOpsからLLMOpsへの進化

MLOpsの振り返り

MLOps（Machine Learning Operations）は、機械学習モデルの開発から運用までのライフサイクルを管理するプラクティスです。LLMOpsはこの延長線上にありつつ、LLM固有の課題に対応します。

MLOpsの進化:

DevOps（ソフトウェア）
  │
  ├── CI/CD、モニタリング、IaC
  │
  ▼
MLOps（機械学習）
  │
  ├── モデルバージョニング、実験管理、特徴量ストア
  │
  ▼
LLMOps（大規模言語モデル）
  │
  ├── プロンプト管理、RAGパイプライン、出力品質評価
  ├── トークンコスト最適化、ガードレール
  └── ハルシネーション検出、安全性フィルタ

LLMOpsの4つの柱

柱1: モデル管理

LLMを活用するシステムでは、外部APIモデルとファインチューニングモデルの両方を管理する必要があります。

# モデル管理の設定例
model_registry:
  production:
    primary:
      provider: "openai"
      model: "gpt-4o"
      version: "2024-11-20"
      max_tokens: 4096
      temperature: 0.1
    fallback:
      provider: "anthropic"
      model: "claude-3-5-sonnet"
      version: "20241022"
  staging:
    primary:
      provider: "openai"
      model: "gpt-4o"
      version: "2025-01-15"  # 新バージョンの検証

柱2: プロンプト管理

プロンプトはLLMシステムの「ソースコード」に相当します。バージョン管理、テスト、レビューが必要です。

プロンプト管理のライフサイクル:

作成 → レビュー → テスト → ステージング → 本番
  │       │        │         │           │
  │       │        │         │           └── モニタリング
  │       │        │         └── カナリアリリース
  │       │        └── 自動評価スイート実行
  │       └── ピアレビュー（PRベース）
  └── プロンプトテンプレート + 変数定義

柱3: 評価パイプライン

LLMの出力品質を継続的に評価する仕組みです。

# 評価パイプラインの例
class LLMEvaluationPipeline:
    def __init__(self):
        self.evaluators = [
            FormatChecker(),        # フォーマット準拠チェック
            SafetyFilter(),         # 安全性フィルタ
            FactualityChecker(),    # 事実性チェック（RAGソースとの照合）
            RelevanceScorer(),      # 質問との関連性スコア
            LLMJudge(),             # LLMによる総合品質判定
        ]

    def evaluate(self, query, response, context):
        results = {}
        for evaluator in self.evaluators:
            results[evaluator.name] = evaluator.score(
                query=query,
                response=response,
                context=context
            )
        return EvaluationResult(
            passed=all(r.passed for r in results.values()),
            scores=results,
            timestamp=datetime.now()
        )

柱4: フィードバックループ

ユーザーからのフィードバックをシステム改善に反映する仕組みです。

フィードバックループ:

ユーザー入力 → LLM応答 → ユーザー評価（👍/👎）
                              │
                              ▼
                         フィードバック収集
                              │
                    ┌─────────┴─────────┐
                    ▼                   ▼
              定量分析              定性分析
           （評価スコア推移）    （低評価回答の分析）
                    │                   │
                    └─────────┬─────────┘
                              ▼
                         改善アクション
                    ┌─────────┼─────────┐
                    ▼         ▼         ▼
              プロンプト   RAGデータ   モデル
              改善        更新        変更

CI/CDパイプラインのAI拡張

従来のCI/CDとの違い

AIシステムのCI/CDは、コードだけでなくプロンプト、RAGデータ、モデル構成もデプロイ対象になります。

# AI拡張CI/CDパイプラインの例
name: AI System CI/CD

on:
  push:
    paths:
      - "prompts/**"          # プロンプト変更
      - "rag/knowledge/**"    # ナレッジベース変更
      - "src/**"              # アプリケーションコード変更
      - "model-config.yaml"   # モデル設定変更

jobs:
  prompt-test:
    name: "プロンプトテスト"
    runs-on: ubuntu-latest
    steps:
      - name: プロンプト構文チェック
        run: python scripts/validate_prompts.py
      - name: 評価スイート実行
        run: python scripts/run_eval_suite.py --suite=regression
      - name: コスト見積もり
        run: python scripts/estimate_token_cost.py

  rag-validation:
    name: "RAGデータ検証"
    runs-on: ubuntu-latest
    steps:
      - name: ドキュメント形式チェック
        run: python scripts/validate_documents.py
      - name: エンベディング生成テスト
        run: python scripts/test_embeddings.py
      - name: 検索精度テスト
        run: python scripts/test_retrieval.py

  integration-test:
    name: "統合テスト"
    needs: [prompt-test, rag-validation]
    runs-on: ubuntu-latest
    steps:
      - name: E2E評価テスト
        run: python scripts/run_e2e_eval.py
      - name: 安全性テスト
        run: python scripts/run_safety_tests.py
      - name: レイテンシテスト
        run: python scripts/run_latency_tests.py

  deploy:
    name: "デプロイ"
    needs: [integration-test]
    if: github.ref == 'refs/heads/main'
    steps:
      - name: カナリアデプロイ（10%）
        run: ./deploy.sh --canary --percentage=10
      - name: カナリア評価（30分）
        run: python scripts/monitor_canary.py --duration=30m
      - name: フルデプロイ
        run: ./deploy.sh --full

デプロイ戦略

実験管理とA/Bテスト

実験管理の重要性

LLMシステムでは、プロンプトの微修正、モデルの変更、RAG設定の調整など、多くの実験が必要です。

# 実験管理の例
experiment = Experiment(
    name="prompt-v3-vs-v2",
    description="システムプロンプトにCoT指示を追加",
    variants={
        "control": PromptConfig(version="v2", template="base"),
        "treatment": PromptConfig(version="v3", template="base_with_cot"),
    },
    traffic_split={"control": 50, "treatment": 50},
    metrics=[
        "response_quality_score",
        "user_satisfaction",
        "avg_latency_ms",
        "avg_token_cost",
    ],
    duration_days=7,
    min_sample_size=1000,
)

# 実験結果の分析
results = experiment.analyze()
print(f"品質スコア: control={results.control.quality:.2f}, "
      f"treatment={results.treatment.quality:.2f}")
print(f"統計的有意性: p={results.p_value:.4f}")

LLMOpsツールチェーン

主要ツールの比較

ツールチェーン統合の例

LLMOpsツールチェーン統合:

開発フェーズ:
  IDE → LangSmith/Langfuse（トレース） → W&B（実験管理）

CI/CDフェーズ:
  GitHub Actions → 評価スイート → MLflow（モデルレジストリ）

本番フェーズ:
  アプリケーション → LangSmith/Langfuse（トレース）
       │                    │
       ▼                    ▼
  Arize Phoenix        ダッシュボード
  （ドリフト検出）      （品質メトリクス）

ツール選定の判断基準

まとめ

チェックリスト

• MLOpsからLLMOpsへの進化の背景を理解した
• LLMOpsの4つの柱（モデル管理、プロンプト管理、評価パイプライン、フィードバックループ）を理解した
• CI/CDパイプラインへのAI固有テストの統合方法を理解した
• 実験管理とA/Bテストの重要性を理解した
• LLMOpsツールチェーンの選定基準を理解した

次のステップへ

次は「AI品質モニタリング」です。LLMの出力品質を継続的に監視し、品質劣化を早期に検出する手法を学びましょう。

推定読了時間: 30分