mcpField
E
evaluate-ml-pipeline

evaluate-ml-pipeline

github.com/probabl-aiデータ・データベース144152 回インストール4 日前に更新
リポジトリ

evaluate-ml-pipeline について

evaluate-ml-pipeline は、設定済みの機械学習モデルを skore で評価し、レポートを保存するスキルです。評価手順、分割方式、チェック、レポートの永続化を扱います。

主な機能

  1. 01skore.evaluate による評価
  2. 02設定済み分割器の再利用
  3. 03事前学習済みモデルの訓練・テストデータ対応
  4. 04レポートのチェックと要約
  5. 05project.put による保存

活用シーン

  1. 01設定済みモデルのスコアリング
  2. 02事前学習済みモデルのテスト表での評価
  3. 03評価指標とチェック結果の保存
  4. 04選択した Skore モードでのレポート作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/probabl-ai/skills --skill evaluate-ml-pipeline

インストール後、Claude Code で/evaluate-ml-pipelineを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

evals/
evals.json
references/
custom-checks.md
custom-metrics.md
g_skore_mode.md
metadata-routing.md
reports.md
skrub_interop.md
templates/
materialize.py

詳細

ML パイプラインを評価する

1 つの学習器をスコアリングし、レポートを保存します。パイプライン、分割器、およびデフォルト以外のスコアは、すでに宣言されています。 skore.evaluate がエントリーポイントです。cross_val_score、cross_validate、classification_report、またはメトリクスの出力を独自に実装しないでください。

SkrubLearner は sklearn の fit(X, y) を実装していません。 cross_val_score はエラーになります。skore.evaluate(learner, data={...}) を呼び出し、translation.splitter が prefit の場合を除き、splitter= を省略してください。

ユーザー向けの文章

詳細:setup-workspace references/human_facing_prose.md。 実験の Markdown と # コメントでは、この評価について説明します。 質問と締めくくりでは、スキル ID、G-* 名、ラッパー CLI ではなく、データサイエンスの言葉を使います。 `` はサイトマーカーです。

手順

  1. python -m skore_skills status。status.setup.pending が空でなく、 status.skills.setup-ml-project が true の場合は、 setup-ml-project を読み込み、停止します。このスキルを 開始してはいけません。スキルから戻ったら続行します。このターンでは 再度読み込まないでください。そのスキルがインストールされていない場合は、 保留中の項目を1行で示して停止します。git init、scaffold、または env init をでっち上げてはいけません。status.setup.env または status.setup.workspace が declined の場合は、1行で停止します。 git または editable が declined の場合は、再度尋ねずに続行します。 次に --revise を付けずに python -m skore_skills frame show を実行します。 status.modeling_decisions が locked でない場合は、 draft を含め、model-ml-pipeline に戻って停止します。 同意やストレージモードを尋ねたり、プレビューであっても skore.evaluate の呼び出しを表示したりしてはいけません。 proceed 以外の場合は frame-ml-problem を読み込んで停止します。 translation が null の場合は停止します。評価呼び出しを記述してはいけません。
  2. 履歴に依存するパイプライン(後方シフト、ラグ、ローリング ウィンドウ、ターゲットシフト、または履歴データを持つテーブルとの結合): tests/smoke/test_<stem>.py が存在しない場合、または pytest が失敗した場合は、 停止して build に戻ります(§ Back to build)。skore.evaluate を 記述してはいけません。履歴依存のステップがない場合に限り、 文書に n/a と記載できます。
  3. python -m skore_skills evaluate consent --stem <stem>。
    • ask であり、このターンに build-ml-pipeline の Evaluate にまだ回答していない場合は、JSON の context を引用し、 Evaluate(推奨)/Modify/Stop を提示します。停止します。 初回の実行で「評価を実行する」と言うことは同意ではありません。
    • ユーザーがこのターンにすでに Evaluate と回答した場合、 または JSON が proceed の場合(実際のロケーターがすでに存在します): 続行します。
    • stop — スモークテストファイルがありません。build に戻ります (§ Back to build)。
  4. G-SKORE-MODE。status.policy.skore_mode を読みます。すでに設定されている場合は、 その設定を維持します。未設定の場合は local(推奨)/hub/mlflow を尋ねてから、 python -m skore_skills policy set skore_mode <mode> を実行します。local:mkdir reports を実行します (exist_ok)。reports/README.md を記述してはいけません。hub または mlflow:reports/ を作成してはいけません。次に、 インストールされている場合は add-python-package を読み込みます。 このスキルは env add-skore --mode <mode> --execute を実行します。 ここで skore[...] と書いてはいけません。ここで env add を 実行してはいけません。コンストラクターについては references/g_skore_mode.md を参照してください。モードの切り替えや 移行の際は、そのスキルがインストールされていれば sync-ml-reports を読み込みます。
  5. Pre-flight を出力し、続けて1~3文で説明します。これは、ロック済みの方式、 レポートメトリクス、skore のチェック、project.put を使った ローカルでの全データセット評価です。チェックはこの実行で計算され、 レポートとともに保存されます。translation.splitter が prefit の場合は、 モデルを学習テーブルで学習し、提供されたテストテーブルでスコアを 算出すると伝えます。stem、判明している場合は fold 数、 experiments/<stem>.py、および scratch/results/<stem>/ を明記します。 所要時間は行数、fold 数、学習器、チェックによって異なります。 分数をでっち上げてはいけません。同意がまだ保留中の場合は、 プレビューを表示して停止します。
  6. 呼び出しは experiments/NN_*.py のみに記述します。以下の呼び出し形式を 参照してください。編集後に python -m skore_skills style を実行します。 実験は report.checks.summarize()、 project.put、および単独の report で終了します。このファイルを 実行してはいけません。
  7. templates/materialize.py を scratch/results/<stem>/materialize.py にコピーします。Project の初期化を 置き換えます。<CALL> ブロックを、引数と順序が同じ実験呼び出しに 置き換えます。このファイルを env verify で確認した composed-dev Python で 1回実行します。これが唯一の skore.evaluate 呼び出しであり、 唯一の project.put です。id.txt を読み取り、ロケーターを作成して locator.txt に書き込みます。policy.notebooks が true の場合は、 python -m skore_skills notebook fill experiments/<stem>.py を実行し、 policy.site も true の場合に限り --html を追加します。 実験を notebook convert してはいけません。また、実験ファイルを 実行してはいけません。notebooks が null または false の場合は、 ポリシーを変更せず、fill も実行しません。policy.site が true で、 export-ml-site がインストールされている場合は、ロケーターの作成後、 監査/レビュー、または別のユーザー確認の前に python -m skore_skills site build --if-stale を実行します。 これにより結果ビューアーをただちに公開できます。record-outcome 後の クローズ時ビルドの代わりにはなりません。その後、ターンを終了します。 実験ファイルに materialize の書き込みを追加してはいけません。 すべての Python プローブは scratch/<ts>_<short>.py に保存し、 env verify の composed-dev Python で実行します。インラインの python -c は使いません。ユーザーから依頼されない限り、 warnings.filterwarnings は使いません。確認できていないシグネチャは 書きません。そのプローブの末尾には BLOCKED: <class> signature needs an API lookup that cannot run this turn (<why>). と記載します。キャッシュにあれば、参照確認済みとして扱います。

呼び出し

experiments/NN_*.py の skore.evaluate を使います。 translation.splitter が prefit でない限り、splitter= は省略して skore に DataOp の cv と split_kwargs を再利用させます。それ以外の splitter= を渡すと、split_kwargs は破棄されます。DataOp に cv が 設定されていない状態で splitter= を省略すると、80/20 のホールドアウト になります。これは translation.report が EstimatorReport で、 translation.splitter が null の場合に限り正しい設定です。配線方法: references/metadata-routing.md。

translation.splitter が prefit の場合は、トレーニングテーブルだけで 学習してから、テストテーブルをスコアリングします。fit と evaluate を api get で確認します。トレーニングテーブルを evaluate に渡しては いけません。この場合に splitter= を省略すると、テストテーブルが新たに 80/20 に分割されます。2 つのテーブルを連結してはいけません。

learner = build_learner()
fitted = learner.fit({"table": train_df})
report = skore.evaluate(
    fitted,
    data={"table": test_df},
    splitter="prefit",
)

fit が (X, y) を取る推定器にも、同じルールが適用されます。

fitted_model = LogisticRegression().fit(X_train, y_train)
report = skore.evaluate(
    fitted_model, X_test, y_test, splitter="prefit"
)

X / y と data は同時に指定できません。

  • SkrubLearner — skore.evaluate(learner, data={...})。キーは skrub.var の名前です。相互運用: references/skrub_interop.md。
  • fit が (X, y) を取る推定器 — skore.evaluate(estimator, X, y)。固定済みの cv がすでに評価方式に なっている場合は、ここでも splitter= を省略します。上記の prefit の 呼び出しは例外です。推定器はすでに学習済みで、X と y は テストテーブルです。

mark_as_X の cv は、KFold、GroupKFold、または build で使う 日付ベースのクラスです。translation で cv が指定されていて、 マーカーには設定されていない場合は、build に戻ってください (§ build に戻る)。ここでは split_kwargs を設定しません。 split_kwargs が空で、グループ列が存在する可能性がある場合は、build に 戻ってください。デフォルトで KFold を使ってはいけません。 translation.splitter の prefit は、マーカーの cv ではありません。

クラスの不均衡に Stratified* を使ってはいけません。fold 間の分散が 圧縮されます。

主要な指標は translation.metric です。build-ml-pipeline の skore デフォルトリストにある名前はスコアラー不要です。ただし、 multioutput-regression は例外です。デフォルトの回帰指標は出力ごとに 計算されるため、固定済みの集約指標がすでに .skb.with_scoring(...) になっている必要があります。それ以外の名前は すべて、予測 DataOp 上ですでに .skb.with_scoring(...) になっている 必要があります。そうでなければ、skore.evaluate の前に build に 戻ってください(§ build に戻る)。report.metrics.add は呼び出しません。 スコアラーを設定すると、その名前は report.metrics.summarize().frame() の行になります。 multioutput-regression の場合、このフレームには出力ごとに 1 行も 含まれます。実験ファイルでこれらの行を平均して消してはいけません。 締めくくりでは固定済みの集約指標を引用してもかまいませんが、出力ごとの 行は保存されたレポートに残します。skore.evaluate に scoring= 引数は ありません(references/custom-metrics.md)。名前が設定済みなのに、 そのフレームにまだ表示されない場合は、予測器クラスが間違っています。 ミックスインを継承してから BaseEstimator を継承する必要があります (先に RegressorMixin または ClassifierMixin)。build に戻ってください (§ build に戻る)。BaseEstimator だけを継承する場合も、 ミックスインより先に BaseEstimator を継承する場合も、どちらも失敗します。

固定後にユーザーから追加のチェックを依頼された場合: references/custom-checks.md。experiments/NN_*.py のモジュールレベルで skore.Check をサブクラス化し、evaluate の後、summarize の前に report.checks.add(...) を呼び出します。add は SKD のチェックを拡張します。 チェックを作り上げてはいけません。audit/ から登録してはいけません。 Check と checks.add を api get で確認します。

すべての評価では、evaluate の後、および checks.add を行った場合は その後に、引数なしで report.checks.summarize() を呼び出してから project.put を呼び出します。これによりチェック結果がレポートに保存されます。 fast_mode や ignore を渡してはいけません。checks.summarize を api get で確認します。

report = skore.evaluate(...)
report.checks.summarize()
project.put(STEM, report)
report

ディスパッチャーの粒度が粗すぎる場合に限り、evaluate より先に進みます (references/reports.md)。1 件のホールドアウト適合には EstimatorReport、フォールドごとの成果物には CrossValidationReport を使います。ホールドアウトでは EstimatorReport を使います。このループでは、1 つの学習器を skore.evaluate 1 回、report.checks.summarize() 1 回、 project.put 1 回で評価します。

履歴に依存する特徴量を含むパイプラインでは、交差検証は必要ですが、それだけでは不十分です。skore.evaluate は、1 つの env-dict でグラフを一度だけ具体化し、インデックスを分割します。スモークテストでは、予測時に新しい env-dict を使用します。呼び出し元がステータスを done に変更する前に、スモークテストに合格する必要があります。このスキルから JOURNAL.md の History やデザインノートの Status を done に編集しないでください。

人が扱う実験ファイルには skore.evaluate(...) と project.put(...) が含まれていますが、実行されません。同じ呼び出しを scratch/results/<stem>/materialize.py にコピーします。実行するのはこのファイルだけなので、project.put は 1 回だけ実行されます。監査ファイル、スクラッチプローブ、または実験ファイルに対する notebook convert から、これらを呼び出してはいけません。保存済みレポートは、project.summarize() の後に project.get(id) で読み込みます。get(key) は get が ID による検索のため、KeyError を発生させます。この問題を補うために evaluate を再実行しないでください。

skore がすでに描画するプロット以外のプロットでは、そのスキルがインストールされている場合に plot-ml-figure を読み込みます。

put の後

Project.put は None を返します。materialize.py は、そのキーの最新 ID を scratch/results/<stem>/id.txt に書き込みます。その ID を使ってロケーターを 1 つ作成し、loop locator と loop artifacts の前に、隣接する locator.txt に書き込みます。これらの書き込みを experiments/<stem>.py に入れないでください。次を実行し、 python -m skore_skills loop locator --stem <stem>、JSON の locator をそのまま貼り付けます。ロケーターがない場合は n/a — backend did not expose a locator です。

  • local — local workspace: [reports/](../reports/) · id: <id>、 および絶対パスの reports/ パス。非公開ファイルへのリンクは作成しないでください。
  • hub — 正確な Consult your report at … URL: [Open report](<url>) · hub · id: <id>。Skore が URL を出力しない場合は、 プロジェクトのランディングページに Open project としてリンクします。
  • mlflow — 存在する場合は、正確な View run … URL。存在せず、 tracking_uri が HTTP(S) の場合は、 /#/experiments/<experiment-id>/runs/<run-id> を使います。file:、 sqlite:、databricks、または URL が出力されないその他の URI の場合: mlflow · tracking: <uri> · experiment: <id> · run: <run-id>。ブラウザーリンクを作り出さないでください。

スクリプトは report._repr_html_() を scratch/results/<stem>/report.html に、repr(report) を report.txt に書き込み、checks.html と metrics.html も書き込みます。メモリ内の学習器から Method ビューアーを再生成します。 EstimatorReport では report.estimator_、 CrossValidationReport では report.reports_[0].estimator_ を使います。 api get を使って DataOp.skb.report の eval を確認します。 learner.report はこれを転送します。eval がパラメーターの場合は、 eval=False、open=False、overwrite=True を指定し、 output_dir を scratch/results/<stem>/pipeline に設定して learner.report を呼び出します。environment は指定しません。 これは適合を行いません。full_report を呼び出さず、 eval=False を指定せずに report を呼び出さないでください。eval が存在しない場合、または skrub に対する add-python-package の再試行を 1 回行った後も Graphviz が失敗する場合は、_repr_html_ または sklearn.utils.estimator_html_repr を使って pipeline.html を書き込みます。

ターンの終了

model-ml-pipeline がこのターンをディスパッチした場合は、JSON locator を渡し、上記のライブ実行とチェックポイントの プレビューの後に終了してください。終了時の loop notebooks、 loop artifacts、監査、record-outcome、別のサイトビルド、 git end-turn は実行しないでください。

それ以外の場合、このスキルが終了処理を担当します。まず python -m skore_skills loop artifacts --stem <stem> を実行します。 stop / evaluate_incomplete → 不足しているファイルを明記し、 監査を実行しないでください。audit → インストール済みの場合は audit-ml-pipeline を読み込みます。 record → 監査をスキップします。record はこのコマンドの アクションであり、ノートブックのゲートではありません。監査スキル内で 変換しないでください。

続いて、以下の順序で実行します。順序を入れ替えないでください。 loop notebooks が続行するのは skip の場合のみです。

  1. python -m skore_skills loop notebooks --stem <stem> を実行します。 JSON の action を正としてください。action が convert の間は、 record-outcome、site build、git end-turn を実行しないでください。 not_evaluated は変換しません。
  2. convert の場合、experiments/ または audit/ の各エントリーについて python -m skore_skills notebook fill <source> を実行します。 html が true の場合は --html を付けてください。これらのファイルに notebook convert を実行しないでください。Fill は put を実行しません。 現在のアーティファクトを書き出した実行以降に人間の呼び出し内容が 変わった場合に限り、先に materialize.py を再実行してください。 audit/<stem>.py だけを埋めても終了処理にはなりません。 未適合スナップショットの禁止は適用されません。skore.evaluate を含んでいても、 実験スクリプトを埋めてください。action が skip になるまで 手順 1 を再実行します。jupytext / nbformat / nbconvert が不足している場合は、 add-python-package を明記した 1 行を返してください。
  3. 手順 1 が skip になった後、サイトビルドの前に record-outcome を実行します。 監査を実行した場合は、監査のダイジェストと G-AUDIT-FINDING を、 実験スクリプトが変換されている場合は手順 2 の locator とともに、 manage-ml-backlog がインストール済みなら渡してください。 監査を実行しなかった場合は、その locator と、ユーザーが示した見出し (あれば)、および n/a — audit not run を指定して record-outcome を呼び出します。 backlog スキルが不足している場合は、その旨を 1 行で返してください。 ここでは History に書き込まないでください。smoke が赤の間は、 決して done とマークしないでください。
  4. policy.site が true で、export-ml-site がインストール済みの場合に限り、 次を実行します。 python -m skore_skills site build --if-stale。これは audit/<stem>.nb.html を ## Notebooks の下に埋め込みます。 `` を追加しないでください。site build が mkdocs-material is required でエラーになった場合は、 mkdocs-material(agent)について add-python-package を読み込み、 もう一度ビルドしてください。pixi add / uv add は実行しないでください。 ビルドエラーを明記してください。ターンを失敗扱いにはしないでください。
  5. 以下のチェックポイントを返します。policy.site が true で、 チェックポイントのビルドに成功した場合は、ウェブサイトが更新されたことを述べ、 ブラウザーで開くためのリンクとして report.html を示してください。 デザインノートの Markdown は明記しないでください。サイトをビルドしていない場合は、 更新されたと主張せず、Markdown も明記しないでください。
  6. python -m skore_skills git end-turn --stage evaluate を実行します。 JSON の action が invoke の場合は、インストール済みなら persist-ml-git を読み込み、終了してください。それ以外の場合は、 インストール済みなら triage-ml-task を読み込みます。ここでは git commit を実行しないでください。
チェックポイント

単独で記載してください。見出しを根拠とするか、監査をスキップした場合は report.txt を根拠として、結果を 2〜6 文で述べてください。監査を実行した場合は、 Checks と Metrics を根拠に説明してください。指標を捏造しないでください。

リンク:policy.site が true で、ビルドに成功した場合は、ウェブサイトが 更新されたことを述べ、ブラウザーで開くための [report.html](<workspace>/report.html) を示してください。 html/<stem>.html や journal/<stem>.md は明記しないでください。 サイトをビルドしていない場合は、更新されたと主張せず、 Markdown も明記しないでください。

ナラティブの後に続くトークン:最初に JSON locator、次に G-AUDIT-FINDING (スキップした場合は n/a — audit not run)。

build に戻る

cv がない、スコアラーがない、予測器クラスが誤っている、またはスモークテストがないか失敗している場合は、build-ml-pipeline で修正するパイプラインの問題です。ここに至った経緯は、このスキルを読み込んだ経路によって異なります。

  • ディスパッチ経由 — 今回のターンで model-ml-pipeline または build-ml-pipeline がこのスキルを読み込んだ場合:ここで止め、そのループに戻ってください。修正のために build に戻ります。
  • 直接開始 — ユーザーが評価を依頼した場合、またはエントリースキルがここに振り分けた場合:status.skills.model-ml-pipeline が true なら model-ml-pipeline を読み込み、ステム名を伝えてください。承認済みの設計を再開し、build が宣言するモデルのティアで修正のために build に戻ります。ここから build-ml-pipeline を読み込まないでください。このスキルが読み込むサブステップは、このスキル自身のティア以下で動作します。model-ml-pipeline がない場合は、パイプラインには build での修正が必要だと1行で伝え、そこで終了してください。

どちらの場合も、このターンでは skore.evaluate を記述しないでください。

停止条件

  • セットアップが保留中(status.setup.pending が空でない)→ setup-ml-project を読み込みます。拒否された git を再度尋ねないでください。環境またはワークスペースを拒否された場合は停止します。
  • 履歴に依存するパイプラインでスモークテストがない、または失敗している → build に戻ります(§ build に戻る)。
  • split_kwargs が空で、グループ列の可能性がある → build に戻ります(§ build に戻る)。デフォルトで KFold を使用しないでください。
  • import skore が失敗する → 未設定の場合は G-SKORE-MODE を設定し、その後 add-python-package を読み込みます。cross_val_score に切り替えないでください。
  • ハイパーパラメーター検索、サービング、複数実行のトラッキングは対象外です。
  • 不足しているパッケージがインストール済みの場合は、add-python-package を読み込みます。ここでは env add を実行しないでください。

事前確認 — コードより先に出力

Pre-flight (evaluate-ml-pipeline):
- [ ] sklearn, skrub, skore import
- [ ] frame show is proceed; DataOp cv matches translation
      (or holdout / prefit, and the marker has no cv)
- [ ] skore_mode is set (local | hub | mlflow)
- [ ] evaluate consent is proceed, or the user answered Evaluate
- [ ] Call site is experiments/NN_*.py (not executed)
- [ ] The one run is scratch/results/<stem>/materialize.py
      (not cells in the experiment file)
- [ ] skore.evaluate omits splitter=
      (or splitter="prefit" and only the test table is passed)
- [ ] report.checks.summarize() then project.put
      (no fast_mode, no ignore; after any checks.add)
- [ ] Smoke: passing | n/a (no history-dependent step) | STOP

参照資料

  • references/metadata-routing.md — ロック済みの cv は DataOp に残し、evaluate では splitter= を省略します。
  • references/skrub_interop.md — 環境辞書と (X, y) の使い分け。
  • references/g_skore_mode.md — Project のコンストラクター。
  • references/reports.md — evaluate では大まかすぎる場合。
  • references/custom-metrics.md — with_scoring を使ったデフォルト以外の指標。
  • references/custom-checks.md — ユーザーが依頼したチェック。
  • templates/materialize.py — 唯一の評価実行。scratch/results/<stem>/materialize.py にコピーします。

コメント