senior-ml-engineer

シニア ML エンジニア

モデルのデプロイ、MLOps インフラストラクチャ、LLM 統合に関する本番環境向けの ML エンジニアリングパターンです。

---

目次

• モデルのデプロイワークフロー
• MLOps パイプラインのセットアップ
• LLM 統合ワークフロー
• RAG システムの実装
• モデルのモニタリング
• リファレンスドキュメント
• ツール

---

モデルのデプロイワークフロー

トレーニング済みモデルを、本番環境でモニタリングしながらデプロイします。

1. モデルを標準形式（ONNX、TorchScript、SavedModel）にエクスポートします
2. 依存関係とともにモデルを Docker コンテナにパッケージ化します
3. ステージング環境にデプロイします
4. ステージング環境を対象に統合テストを実行します
5. 本番環境にカナリアリリース（トラフィックの 5%）をデプロイします
6. レイテンシとエラー率を 1 時間モニタリングします
7. メトリクスに問題がなければ、本番環境全体に展開します
8. 検証： p95 レイテンシ < 100ms、エラー率 < 0.1%

コンテナテンプレート

FROM python:3.11-slim

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY model/ /app/model/
COPY src/ /app/src/

HEALTHCHECK CMD curl -f http://localhost:8080/health || exit 1

EXPOSE 8080
CMD ["uvicorn", "src.server:app", "--host", "0.0.0.0", "--port", "8080"]

サービングの選択肢

選択肢	レイテンシ	スループット	用途
FastAPI + Uvicorn	低	中	REST API、小規模モデル
Triton Inference Server	非常に低い	非常に高い	GPU 推論、バッチ処理
TensorFlow Serving	低	高	TensorFlow モデル
TorchServe	低	高	PyTorch モデル
Ray Serve	中	高	複雑なパイプライン、複数モデル

---

MLOps パイプラインのセットアップ

トレーニングとデプロイを自動化します。

1. トレーニングデータ用の特徴量ストア（Feast、Tecton）を設定します
2. 実験トラッキング（MLflow、Weights & Biases）をセットアップします
3. ハイパーパラメーターのログ記録を行うトレーニングパイプラインを作成します
4. バージョンメタデータとともに、モデルレジストリにモデルを登録します
5. レジストリイベントをトリガーとしてステージング環境にデプロイするよう設定します
6. モデル比較用の A/B テストインフラストラクチャをセットアップします
7. アラート機能付きのドリフトモニタリングを有効にします
8. 検証： 新しいモデルがベースラインに対して自動的に評価されます

特徴量ストアのパターン

from feast import Entity, Feature, FeatureView, FileSource

user = Entity(name="user_id", value_type=ValueType.INT64)

user_features = FeatureView(
    name="user_features",
    entities=["user_id"],
    ttl=timedelta(days=1),
    features=[
        Feature(name="purchase_count_30d", dtype=ValueType.INT64),
        Feature(name="avg_order_value", dtype=ValueType.FLOAT),
    ],
    online=True,
    source=FileSource(path="data/user_features.parquet"),
)

再トレーニングのトリガー

トリガー	検出方法	アクション
スケジュール	Cron（週次／月次）	全体を再トレーニング
パフォーマンス低下	精度 < しきい値	即時に再トレーニング
データドリフト	PSI > 0.2	評価後に再トレーニング
新規データ量	X 件の新しいサンプル	増分更新

---

LLM 統合ワークフロー

LLM API を本番アプリケーションに統合します。

1. ベンダーを柔軟に切り替えられるプロバイダー抽象化レイヤーを作成します
2. 指数バックオフを使った再試行ロジックを実装します
3. セカンダリプロバイダーへのフォールバックを設定します
4. トークンカウントとコンテキストの切り詰めをセットアップします
5. 繰り返しのクエリに対するレスポンスキャッシュを追加します
6. リクエストごとのコスト追跡を実装します
7. Pydantic を使った構造化出力の検証を追加します
8. 検証： レスポンスが正しく解析され、コストが予算内に収まること

プロバイダーの抽象化

from abc import ABC, abstractmethod
from tenacity import retry, stop_after_attempt, wait_exponential

class LLMProvider(ABC):
    @abstractmethod
    def complete(self, prompt: str, **kwargs) -> str:
        pass

@retry(stop=stop_after_attempt(3), wait=wait_exponential(min=1, max=10))
def call_llm_with_retry(provider: LLMProvider, prompt: str) -> str:
    return provider.complete(prompt)

コスト管理

価格をハードコードせず、ドキュメント（このドキュメントを含む）に記載された価格表も鵜呑みにしないでください。プロバイダーは年に数回価格を改定するため、古い数値に基づくと、自信を持って誤ったビジネスケースを提示することになります。

段階別に管理し、リクエスト時に最新の数値を確認してください。

段階	典型的な用途	相対コスト
小	分類、抽出、ルーティング、短い出力	基準の 1 倍
中	要約、構造化出力、中程度の推論	小の約 10～25 倍
大	多段階の推論、コード生成、長いコンテキスト	小の約 50～100 倍

プロバイダーの料金ページで最新の料金を確認し、 engineering-team/skills/senior-prompt-engineer/scripts/prompt_optimizer.py の --price-per-mtok のように渡してください。 段階間の比率は絶対価格よりはるかに安定しているため、その比率に基づいて モデルのルーティングを決定してください。

---

RAG システムの実装

検索拡張生成パイプラインを構築します。

1. ベクトルデータベースを選択します（Pinecone、Qdrant、Weaviate）
2. 品質とコストのトレードオフに基づいて埋め込みモデルを選択します
3. ドキュメントのチャンク分割戦略を実装します
4. メタデータ抽出を伴う取り込みパイプラインを作成します
5. クエリの埋め込みを使用した検索を構築します
6. 関連性を高めるために再ランキングを追加します
7. コンテキストを整形して LLM に送信します
8. 検証： 応答が検索されたコンテキストを参照し、ハルシネーションがないことを確認します

ベクトルデータベースの選択

データベース	ホスティング	規模	レイテンシ	最適な用途
Pinecone	マネージド	高	低	本番環境、マネージド
Qdrant	両方	高	非常に低	パフォーマンスが重要な用途
Weaviate	両方	高	低	ハイブリッド検索
Chroma	セルフホスト	中	低	プロトタイピング
pgvector	セルフホスト	中	中	既存の Postgres

チャンク分割戦略

戦略	チャンクサイズ	オーバーラップ	最適な用途
固定	500-1000 トークン	50-100	一般的なテキスト
文単位	3-5 文	1 文	構造化されたテキスト
セマンティック	可変	意味に基づく	研究論文
再帰的	階層型	親子	長いドキュメント

---

モデルのモニタリング

本番環境のモデルについて、ドリフトや性能低下を監視します。

1. レイテンシの追跡を設定します（p50、p95、p99）
2. エラー率のアラートを設定します
3. 入力データのドリフト検出を実装します
4. 予測分布の変化を追跡します
5. 利用可能な場合は正解データを記録します
6. A/B メトリクスでモデルのバージョンを比較します
7. 自動再トレーニングのトリガーを設定します
8. 検証： ユーザーが認識できる性能低下が発生する前にアラートが作動することを確認します

ドリフト検出

from scipy.stats import ks_2samp

def detect_drift(reference, current, threshold=0.05):
    statistic, p_value = ks_2samp(reference, current)
    return {
        "drift_detected": p_value < threshold,
        "ks_statistic": statistic,
        "p_value": p_value
    }

アラートのしきい値

メトリクス	警告	重大
p95 レイテンシ	> 100ms	> 200ms
エラー率	> 0.1%	> 1%
PSI（ドリフト）	> 0.1	> 0.2
精度の低下	> 2%	> 5%

---

リファレンスドキュメント

MLOps の本番環境パターン

references/mlops_production_patterns.md には以下が含まれています。

• Kubernetes マニフェストを使ったモデルデプロイパイプライン
• Feast の例を使ったフィーチャーストアのアーキテクチャ
• ドリフト検出コードを含むモデルのモニタリング
• トラフィック分割を使った A/B テスト基盤
• MLflow を使った自動再トレーニングパイプライン

LLM 統合ガイド

references/llm_integration_guide.md には以下が含まれています。

• プロバイダー抽象化レイヤーパターン
• tenacity を使ったリトライとフォールバックの戦略
• プロンプトエンジニアリングのテンプレート（少数例、CoT）
• tiktoken を使ったトークンの最適化
• コストの計算と追跡

RAG システムアーキテクチャ

references/rag_system_architecture.md には以下が含まれています。

• コードを使った RAG パイプラインの実装
• ベクトルデータベースの比較と統合
• チャンク分割戦略（固定、セマンティック、再帰的）
• 埋め込みモデルの選択ガイド
• ハイブリッド検索と再ランキングのパターン

---

ツール

モデルデプロイパイプライン

python scripts/model_deployment_pipeline.py --model model.pkl --target staging

デプロイ用アーティファクト（Dockerfile、Kubernetes マニフェスト、ヘルスチェック）を生成します。

RAG システムビルダー

python scripts/rag_system_builder.py --config rag_config.yaml --analyze

ベクトルストアとの統合と検索ロジックを備えた RAG パイプラインのひな形を作成します。

ML モニタリングスイート

python scripts/ml_monitoring_suite.py --config monitoring.yaml --deploy

ドリフト検出、アラート、パフォーマンスダッシュボードを設定します。

---

技術スタック

カテゴリ	ツール
ML フレームワーク	PyTorch、TensorFlow、Scikit-learn、XGBoost
LLM フレームワーク	LangChain、LlamaIndex、DSPy
MLOps	MLflow、Weights & Biases、Kubeflow
データ	Spark、Airflow、dbt、Kafka
デプロイ	Docker、Kubernetes、Triton
データベース	PostgreSQL、BigQuery、Pinecone、Redis