Mímisbrunnr知恵の泉

← MLOps 一覧

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：本番モデルの監視　|　関連：LLMの全体像（機械学習）

⚠️ 要最新確認：LLM のツール・スペックは変化が速い。本ノートの具体名は執筆時点（2026-06）の例。

要点（BLUF）

1. 3層の構成

flowchart TB
  subgraph アプリ層
    P["プロンプト管理：テンプレート・版・変数"]
    O["オーケストレーション：多段・分岐・外部連携"]
  end
  subgraph 推論層
    M["モデル呼び出し：API or セルフホスト"]
  end
  U["ユーザー入力"] --> O
  O --> P
  P --> M
  M --> O
  O --> R["応答"]
  O -.->|"必要に応じて"| EXT["外部：検索 RAG ツール"]
層役割運用の関心
プロンプト管理入力テンプレートの設計・版管理版・評価・ABテスト
推論モデルを呼んで生成遅延・コスト・可用性
オーケストレーション多段処理・外部連携・分岐信頼性・トレース・エラー処理

2. プロンプトはコードである

プロンプトを「設定ファイルの文字列」程度に扱うと運用が破綻します。プロンプトの少しの変更で出力品質が大きく変わるのに、版管理も評価もなければ「いつ・なぜ品質が変わったか」が追えません。プロンプトは：

3. 推論：API かセルフホストか

API（マネージド）セルフホスト
導入速い重い（GPU・運用）
コスト従量（トークン単価）固定（インフラ）＋運用
制御・機密限定的完全（LLMの推論サービングと最適化基盤）
向き立ち上げ・変動負荷大量・機密・低レイテンシ要件

まず API で始め、コスト・機密・制御の要件が強まればセルフホスト（LLMの推論サービングと最適化基盤）を検討する、が定石です（要最新確認）。

4. 動く最小例：プロンプトを版管理して出力を比較する

LLM 本体は呼ばず、プロンプトの版管理・テンプレート展開・出力比較の仕組みを最小化します（LLM 呼び出しはダミー関数で代替）。

from string import Template

# プロンプトレジストリ：版ごとにテンプレートを保持
prompt_registry = {
    "summarize_v1": Template("次の文章を要約して: $text"),
    "summarize_v2": Template(
        "次の文章を、専門用語を避けて3文以内で要約して:\n$text\n要約:"),
}

def render(version, **vars):
    return prompt_registry[version].substitute(**vars)

def fake_llm(prompt):
    """LLM呼び出しの代理：プロンプトの特徴で出力品質を擬似評価。
    実運用では実際のLLM API を呼ぶ（要最新確認）。"""
    quality = 0.5
    if "3文以内" in prompt:
        quality += 0.3            # 制約が明確だと品質が上がる想定
    if "専門用語を避けて" in prompt:
        quality += 0.15
    return {"text": "（要約結果）", "quality_score": round(quality, 2),
            "prompt_chars": len(prompt)}

text = "MLOpsはMLライフサイクルを継続的に回す運用規律である。"
for v in ["summarize_v1", "summarize_v2"]:
    prompt = render(v, text=text)
    out = fake_llm(prompt)
    print(f"{v}: 品質={out['quality_score']}  プロンプト長={out['prompt_chars']}文字")

出力：

summarize_v1: 品質=0.5  プロンプト長=41文字
summarize_v2: 品質=0.95  プロンプト長=59文字

出力の意味：プロンプトを版として管理し、同じ入力に対して v1 と v2 の出力品質を比較できました（ここでは制約を明確にした v2 が高品質という想定）。重要なのは仕組み——プロンプトに版番号を与え、テンプレートとして展開し、出力を評価・比較する。これがあれば「どのプロンプト版が本番か」「変更で品質がどう動いたか」を追え、プロンプトをモデルと同じく管理対象にできます。実際の品質評価はLLMの評価・ガードレール・コスト管理の手法で行います（要最新確認）。

5. 運用の勘所

なぜそうするのか

LLM アプリを3層に分け、特にプロンプトを「コード」として扱うのは、LLM では振る舞いの大半がプロンプトとオーケストレーションで決まるからです。モデルが同じでも、プロンプトの一語や処理フローの一段で出力品質が大きく変わります。これを版管理・評価・トレースの下に置かなければ、従来の ML 以上に「なぜ品質が変わったか分からない」状態に陥ります。3層に整理することで、それぞれを独立に管理・改善・差し替えできるようになります。

⚠️ よくある落とし穴

対応 lab

関連ノート