ml-system-design-interview
推論パイプライン、レコメンデーションシステム、RAG、フィーチャーストア、モニタリングなど、MLシステム設計の包括的なインタビューコーチング機能を提供します。L6以上の設計ラウンド、ML アーキテクチャのホワイトボーディング、システム設計練習、モデルサービングのトレードオフ分析に活用できます。「ML system design」「ML interview」「recommendation system design」「RAG architecture」「feature store design」「model serving」といったキーワードで起動します。コーディングインタビュー、行動面接、ML理論クイズ、論文の実装には対応していません。
description の原文を見る
Coaches end-to-end ML system design interviews covering inference pipelines, recommendation systems, RAG, feature stores, and monitoring. Use for L6+ design rounds, ML architecture whiteboarding, system design practice, serving tradeoff analysis. Activate on "ML system design", "ML interview", "recommendation system design", "RAG architecture", "feature store design", "model serving". NOT for coding interviews, behavioral questions, ML theory quizzes, or paper implementations.
SKILL.md 本文
MLシステム設計インタビュー
スタッフレベル以上のエンジニア向けのエンドツーエンドMLパイプライン設計コーチング。問題定義から本番環境モニタリングまで全体を網羅します。これはトップティアのML組織でのL6+インタビューで期待される範囲です。
このスキルは15年以上のML/CV/AI/NLP経験を前提としています。基礎は教えません。既に持つ知識をインタビュアーが評価する形式に構造化します。
使用するべき場面
以下の場合に使用してください:
- 45分のMLシステム設計ラウンドの練習
- 推奨、ランキング、RAG、不正検知、知覚システムのホワイトボードプレゼンテーションの構造化
- サービング可能性アーキテクチャのトレードオフ分析(バッチ vs オンライン vs ストリーミング)
- L6+の差別化シグナル特定(問題所有権、組織制約、データフライホイール)
- MLシステム設計の回答の確認と批判
以下の場合には使用しないでください:
- コーディングインタビュー(
senior-coding-interviewを使用) - 行動・リーダーシップに関する質問(
interview-loop-strategistを使用) - ML理論または数学的導出
- モデルの実装またはトレーニングコードの作成
- 論文読または研究レビュー
7段階設計フレームワーク
すべてのMLシステム設計の回答はこの流れに従います。各段階は順序立てられていますが、制約が明らかになるにつれて前に戻ります。以下のMermaidダイアグラムがホワイトボードの骨組みになります。
flowchart TD
R[1. Requirements\n- Business goal\n- Users and scale\n- Latency/throughput SLA\n- Constraints] --> M[2. Metrics\n- Offline: precision, recall, NDCG\n- Online: CTR, conversion, revenue\n- Guardrails: latency p99, fairness]
M --> D[3. Data\n- Sources and collection\n- Labeling strategy\n- Pipeline: ETL, validation\n- Freshness and staleness]
D --> F[4. Features\n- Engineering and transforms\n- Feature store architecture\n- Online vs offline features\n- Freshness requirements]
F --> Mo[5. Model\n- Architecture selection\n- Training pipeline\n- Iteration strategy\n- Baseline and ablation]
Mo --> S[6. Serving\n- Batch vs online vs streaming\n- Caching and precomputation\n- Scaling and cost\n- Canary and shadow mode]
S --> Mon[7. Monitoring\n- Data drift detection\n- Model degradation alerts\n- A/B testing framework\n- Rollback strategy\n- Feedback loops]
Mon -.->|Feedback loop| D
Mon -.->|Retrain trigger| Mo
段階の詳細
段階1 -- 要件(5分) 何かを設計する前に明確化の質問をしましょう。確立すべき項目:ユーザーは誰か?ビジネスメトリクスは?レイテンシSLAは?スケール(QPS、データボリューム)は?ハード制約(コスト、プライバシー、規制)は?L6+の候補者は問題定義を所有します。インタビュアーが要件を提供するまで待たないでください。
段階2 -- メトリクス(3分) デプロイ前に測定できるオフラインメトリクスおよびビジネスに重要なオンラインメトリクスを定義します。ギャップを説明してください:「オフラインでのNDCG改善は、ポジションバイアスと新規性効果のため、必ずしもオンラインでのCTRリフトに変換されません」。ガードレールメトリクスを定義します:レイテンシp99、ユーザーセグメント間の公平性、予測当たりのコスト。
段階3 -- データ(7分) トレーニングデータはどこから来ますか?ラベル付けの方法は(人間、弱教師あり学習、暗黙的シグナル)?クラスバランスは?データの新鮮度はどの程度必要ですか?データパイプライン(バッチETL vs ストリーミング)は?データ品質チェックはどれが存在しますか?この段階がL6+候補とL5候補を区別します。ジュニア候補はクリーンなラベル付きデータを仮定します。
段階4 -- 特徴量(5分) モデルにはどの特徴量が必要ですか?どれが事前計算(オフライン)され、どれがリクエスト時に計算(オンライン)されますか?特徴量ストアアーキテクチャ:オンラインストア(低レイテンシの参照)vs オフラインストア(バッチトレーニング)。特徴量の新鮮度:ユーザー特徴量は日次更新、アイテム特徴量は時間単位の更新、文脈特徴量はリアルタイム。
段階5 -- モデル(8分) シンプルなベースライン(ロジスティック回帰、XGBoost)から始めて、その理由を説明してください。その後、本番アーキテクチャ(ツータワー、トランスフォーマーなど)を提案し、アップグレードを正当化してください。トレーニングパイプラインについて議論:頻度、データ量、分布シフトへの対応。イテレーション戦略:最初に実行する実験。
段階6 -- サービング(8分) ここでシステム設計とMLが交差します。以下を議論してください:推論レイテンシ要件、バッチ事前計算 vs オンライン推論、GPU/CPUトレードオフ、モデルサービングフレームワーク、キャッシング戦略、コスト最適化(量子化、蒸留、スポットインスタンス)。サービングアーキテクチャを描いてください。
段階7 -- モニタリング(5分) デプロイ後はどうなりますか?データドリフト検出(PSI、KLダイバージェンス)。モデル劣化アラート(時間経過による指標減衰)。A/Bテストフレームワーク(サンプルサイズ、期間、新規性効果)。ロールバック戦略(シャドウモード、キャナリア率)。時間経過でモデルを改善するフィードバックループ。
45分間のタイムバジェット
| 段階 | 時間 | カバーする内容 |
|---|---|---|
| 要件+明確化 | 5分 | ビジネス目標、ユーザー、スケール、SLA、制約 |
| メトリクス | 3分 | オフライン、オンライン、ガードレール、メトリクスアライメント |
| データ | 7分 | ソース、ラベル付け、パイプライン、品質、新鮮度 |
| 特徴量 | 5分 | エンジニアリング、ストア設計、オンライン/オフライン分割 |
| モデル | 8分 | ベースライン、本番アーキテクチャ、トレーニング、イテレーション |
| サービング | 8分 | レイテンシ、アーキテクチャ、コスト、デプロイメント戦略 |
| モニタリング | 5分 | ドリフト、アラート、A/Bテスト、ロールバック、フィードバック |
| Q&Aバッファ | 4分 | インタビュアーのディープダイブ、トレードオフの防御 |
インタビュアーが質問を挟む場合は適応してください。ただし、7段階すべてを簡潔にでもカバーしてください。モニタリングをスキップするのは最も一般的なL5の間違いです。
標準的な問題セット
| 問題 | 主な課題 | 必須議論事項 |
|---|---|---|
| 推奨システム | コールドスタート、ポジションバイアス、マルチオブジェクティブ最適化 | ツータワーリトリーバル+リランキング、探索-活用 |
| 検索ランキング | クエリインテント分類、関連性 vs エンゲージメント、スケール時のレイテンシ | 反転インデックス+埋め込みリトリーバル、L1/L2ランキングカスケード |
| コンテンツモデレーション | マルチモーダル(テキスト+画像+動画)、敵対的回避、適合率-再現率のトレードオフ | 人間参加型、エスカレーションティア、アピール補正ワークフロー |
| RAGパイプライン | リトリーバル品質、チャンク戦略、ハルシネーション検出、評価 | 埋め込みモデル選択、ハイブリッド検索、リランキング、引用 |
| 不正検知 | 極端なクラス不均衡、敵対的適応、リアルタイム要件 | 特徴量速度、グラフ特徴量、アンサンブル+ルール、フィードバック遅延 |
| 自動運転知覚 | センサーフュージョン、安全クリティカルなレイテンシ、ロングテール分布 | マルチタスクアーキテクチャ、シミュレーション、OTAアップデート、規制 |
サービングアーキテクチャの比較
| パターン | レイテンシ | 新鮮度 | コスト | 最適な用途 |
|---|---|---|---|---|
| バッチ予測 | N/A(事前計算) | 数時間古い | 低計算、高ストレージ | メール推奨、日次レポート |
| オンライン推論 | 10-500ms | リアルタイム | 高計算(GPU) | 検索ランキング、不正検知 |
| ニアリアルタイム | 1-60秒 | 数分新鮮 | 中程度 | フィード順位付け、コンテンツモデレーション |
| ストリーミング | サブ秒 | 継続的 | 高(常時稼働) | 不正、異常検知、入札 |
詳細なサービングトレードオフ、フレームワーク比較、コスト最適化戦略はreferences/serving-tradeoffs.mdにあります。
L6+の差別化シグナル
スタッフレベル以上の回答をシニアレベルの回答から区別するもの:
1. 問題定義を所有する 問題をそのまま受け入れないでください。質問してください:「どのビジネスメトリクスを最適化していますか?これは収益の問題か、エンゲージメントの問題か?現在のソリューションは何で、なぜそれで十分ではないのか?」L5候補は「推奨システムを構築する」と受け入れます。L6+候補は「何を、誰に推奨し、成功は何に見えるか」と質問します。
2. 組織制約について議論する 実際のシステムは組織内に存在します。以下に対応してください:チームサイズ(カスタムモデルを維持できるか、マネージドサービスを使うべきか)、オンコール負担、クロスチーム依存、コンプライアンス要件、レガシーシステムからの移行パス。
3. データフライホイール戦略 より良いモデル -> より多くのエンゲージメント -> より多くのデータ -> より良いモデルの好循環について考えていることを示します。それを加速する方法を議論してください:アクティブラーニング、暗黙的フィードバックループ、探索戦略、コールドスタートブートストラッピング。
4. 構築 vs 購入の決定 すべてをカスタムで構築すべきではありません。適切な場合はマネージドサービスを主張し(埋め込みAPI、特徴量ストア、サービングプラットフォーム)、競争優位が必要な場合はカスタムソリューションを主張してください。総所有コストを理解していることを示してください。
5. マルチオブジェクティブ思考 実際のシステムは複数の目的を同時に最適化します:関連性かつ多様性、精度かつ公平性、品質かつレイテンシ。衝突への対応方法を議論してください:パレート最適化、制約付き最適化、マルチタスク学習、ビジネスルール後処理。
ホワイトボード戦略
何を、いつ描くか:
| 時間 | 描くもの | 目的 |
|---|---|---|
| 0-5分 | 要件ボックス(箇条書き) | 議論をアンカーし、構造化思考を示す |
| 5-8分 | メトリクス表(オフライン vs オンライン) | モデル精度以上の思考を示す |
| 8-15分 | データパイプラインダイアグラム(ソース -> ETL -> ストア) | データエンジニアリング理解を示す |
| 15-20分 | 特徴量アーキテクチャ(オフラインストア+オンラインストア) | 特徴量ストア知識を示す |
| 20-28分 | モデルアーキテクチャ+サービングダイアグラム | コアシステム設計アーティファクト |
| 28-36分 | レイテンシ注記付き全体システムダイアグラム | すべてを接続、シップ可能なことを示す |
| 36-41分 | モニタリングダッシュボードスケッチ+フィードバック矢印 | ループを閉じ、本番環境思考を示す |
コンポーネント用のボックス、データフロー用の矢印を使い、レイテンシ/スループット数値で注記を付けてください。ダイアグラムは30分時点で入ってきた誰かでも読めるべきです。
アンチパターン
モデル重視の思考
初級: 問題を理解する前、メトリクスやデータについて議論する前に、最初の2分で「トランスフォーマーを使う」または「注意メカニズムについて説明する」に飛び込みます。時間の70%をモデルアーキテクチャに、0%をサービングに使います。
専門家: 最初の10分を要件、メトリクス、データに費やしてから、モデルについて言及します。シンプルなベースライン(ハンドクラフト特徴量上のロジスティック回帰)を最初に名前付けて、その後、ベースラインの制限が明らかな場合にのみ複雑さを主張します。サービングとモニタリングに同等の時間を割きます。
検知: アーキテクチャダイアグラムに詳細なモデルボックスはありますが、データパイプライン、特徴量ストア、サービングレイヤー、モニタリングコンポーネントはありません。最初の文でモデルアーキテクチャについて言及します。
データを無視する
初級: クリーンでラベル付けされたデータがスケール時に存在すると仮定します。「数百万のラベル付き例でトレーニングする」と言い、ラベルがどこから来るか、どのくらいのコストか、クラス分布は何か、またはデータがどのくらい古くなるかについて議論しません。
専門家: データソース、ラベル付け戦略(人間 vs 弱教師あり学習 vs 暗黙的シグナル)、クラス不均衡の処理、データ新鮮度SLA、データ品質監視について質問します。ラベル付けコストを議論し、それを減らす戦略を提案します(アクティブラーニング、半教師あり学習、合成データ)。
検知: 回答のどこにもデータ収集、ラベル付けコスト、クラス不均衡、データ品質チェック、またはデータ新鮮度についての議論がありません。単語「ラベル」は出現しません。
モニタリングストーリーがない
初級: 設計はサービングレイヤーで終わります。モデルがデプロイ後どうなるかについて言及しません。劣化検知、ロールバック、またはモデルの長期的な改善方法について議論しません。
専門家: データドリフト検出(母集団安定性指数、特徴量分布監視)、モデルパフォーマンス減衰アラート、適切な統計的厳密さを持つA/Bテストフレームワーク、キャナリアデプロイメント戦略、安全なロールアウトのためのシャドウモード、本番からトレーニングへのデータフローバックの明示的なフィードバックループについて議論します。
検知: アーキテクチャダイアグラムにモニタリングコンポーネントがありません。本番からトレーニングへのフィードバック矢印がありません。A/Bテスト、キャナリアデプロイメント、またはロールバックについて言及しません。
参考ファイル
ディープダイブのためにこれらを参照してください。デフォルトでは読み込まれません:
| ファイル | 参照するべき場合 |
|---|---|
references/ml-design-templates.md | 特定の問題(推奨、検索、RAG、不正検知、コンテンツモデレーション、知覚)に取り組むとき。Mermaidダイアグラム付きの6つの完全な設計を含みます。 |
references/serving-tradeoffs.md | サービングアーキテクチャ、フレームワーク選択、キャッシング、コスト最適化、デプロイメント戦略についてのディープダイブ。フレームワーク比較と使用例別レイテンシターゲットを含みます。 |
references/evaluation-metrics-guide.md | メトリクス選択、メトリクスアライメント理解、A/Bテスト設計、生成AIの評価。メトリクス決定木と公式を含みます。 |
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- curiositech
- ライセンス
- MIT
- 最終更新
- 2026/4/29
Source: https://github.com/curiositech/some_claude_skills / ライセンス: MIT
関連スキル
agent-browser
AI エージェント向けのブラウザ自動化 CLI です。ウェブサイトとの対話が必要な場合に使用します。ページ遷移、フォーム入力、ボタンクリック、スクリーンショット取得、データ抽出、ウェブアプリのテスト、ブラウザ操作の自動化など、あらゆるブラウザタスクに対応できます。「ウェブサイトを開く」「フォームに記入する」「ボタンをクリックする」「スクリーンショットを取得する」「ページからデータを抽出する」「このウェブアプリをテストする」「サイトにログインする」「ブラウザ操作を自動化する」といった要求や、プログラマティックなウェブ操作が必要なタスクで起動します。
anyskill
AnySkill — あなたのプライベート・スキルクラウド。GitHubを基盤としたリポジトリからエージェントスキルを管理、同期、動的にロードできます。自然言語でクラウドスキルを検索し、オンデマンドでプロンプトを自動ロード、カスタムスキルのアップロードと共有、スキルバンドルの一括インストールが可能です。OpenClaw、Antigravity、Claude Code、Cursorに対応しています。
engram
AIエージェント向けの永続的なメモリシステムです。バグ修正、意思決定、発見、設定変更の後はmem_saveを使用してください。ユーザーが「覚えている」「記憶している」と言及した場合、または以前のセッションと重複する作業を開始する際はmem_searchを使用します。セッション終了前にmem_session_summaryを使用して、コンテキストを保持してください。
skyvern
AI駆動のブラウザ自動化により、任意のウェブサイトを自動化できます。フォーム入力、データ抽出、ファイルダウンロード、ログイン、複数ステップのワークフロー実行など、ユーザーがウェブサイトと連携する必要があるときに使用します。Skyvernは、LLMとコンピュータビジョンを活用して、未知のサイトも自動操作可能です。Python SDK、TypeScript SDK、REST API、MCPサーバー、またはCLIを通じて統合できます。
pinchbench
PinchBenchベンチマークを実行して、OpenClawエージェントの実世界タスクにおけるパフォーマンスを評価できます。モデルの機能テスト、モデル間の比較、ベンチマーク結果のリーダーボード提出、またはOpenClawのセットアップがカレンダー、メール、リサーチ、コーディング、複数ステップのワークフローにどの程度対応しているかを確認する際に使用します。
openui
OpenUIとOpenUI Langを使用してジェネレーティブUIアプリを構築できます。これらはLLM生成インターフェースのためのトークン効率的なオープン標準です。OpenUI、@openuidev、ジェネレーティブUI、LLMからのストリーミングUI、AI向けコンポーネントライブラリ、またはjson-render/A2UIの置き換えについて述べる際に使用します。スキャフォルディング、defineComponent、システムプロンプト、Renderer、およびOpenUI Lang出力のデバッグに対応しています。