Communitygithub.com

ErtasAI/open-model-skills (オープンモデルスキル)

オープンモデルを使用して構築するためのエージェントスキル:モデルの検査、デバッグ、評価、コスト計算、そして微調整されたモデルを実際のプロジェクトにデプロイします。

open-model-skills (オープンモデルスキル) とは?

このスキルは、カスタムモデルトレーニングを検討する前に、実際の制約を特定し、より安価な代替案を評価するための体系的なアプローチを提供します。コスト、レイテンシ、プライバシー、オフライン操作、動作の一貫性という5つの主要な制約を明確にし、プロンプト改善、検索拡張生成(RAG)、小規模なホストモデル、モデルルーティングという4つの代替案を順に検討することで、不要なトレーニングを回避します。プロンプトエンジニアリング、検索、小規模モデル、ルーティングの各代替案がいつ十分で、いつ不十分かを明確に定義し、トレーニングが適切な場合には、タスク、品質基準、レイテンシ目標、デプロイ環境、成功指標を文書化することを要求します。また、関連する8つのスキル(モデルバンドルの調査、不良ファインチューンのデバッグ、モデル評価、API vs モデルのコスト比較、React Native/Android/iOS/Flutterアプリへのデプロイ)への明確なリンクと、MODEL-DECISION.mdファイルへの意思決定プロセスの記録機能を提供します。完全な日本語で書かれたSKILL.mdは、Claude Code、Cursor、CodexなどのAIエージェントが、ユーザーのプロジェクトでモデル関連の意思決定を行う際に必要な、具体的かつ実践的なガイダンスを提供します。

対応~Claude Code~Codex CLI~Cursor
npx skills add ErtasAI/open-model-skills

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

カスタムモデルのスコープ定義

問題の解決策がカスタムトレーニング済みモデルであるかどうかがまだ明確でない場合に、ここから始めます。多くの場合、ユーザーは実際の制約を明確にしないまま、ファインチューニングをしたい、何かをオフラインで実行したい、または請求額を削減したいと考えています。このスキルは、そのプロセスを一段階遅らせるために存在します。制約を明確にし、より安価な修正を除外し、その後に初めてトレーニングが提供すべきものを定義します。

最初に制約を特定する

人々が制約を最初に口にすることはほとんどありません。彼らは解決策を提示します。「モデルをファインチューニングしたい」「これをオフラインで実行したい」「自分のモデルが欲しい」。これらのそれぞれは、5つの実際の制約のうちの1つを代理しています。先に進む前に、それが実際にどの制約なのかを明らかにしてください。このスキルの残りの部分、そして次に進むべき他の8つのスキルのうちどれかは、その答えに依存します。

ユーザーの発言通常の意味
「コストが高すぎる」コスト
「遅すぎる」「ラウンドトリップが問題だ」レイテンシ
「データが外部に出せない」プライバシー
「接続なしで動作する必要がある」オフライン操作
「間違った結果が続く」「一貫性がない」動作の一貫性

これらのいずれにも該当しない場合は、直接質問してください。根底に制約のない「自分のモデルが欲しい」というだけの要望は、通常、要件というよりも熱意であり、熱意に対してトレーニングを行うと、誰も実際には求めていないモデルが生まれます。

トレーニングに同意する前に試すべき4つのこと

トレーニングは、モデルの動作を変えるための最も遅く、最も高価な方法です。まずはより安価なオプションを排除します。詳細、それぞれのおおよそのコスト、そしてそれがもはや十分でないことを示す正確なシグナルは、references/alternatives-to-training.md にあります。簡略版は以下の通りです。

  1. より良いプロンプト。 モデルがすでに答えを知っていて、表現、フォーマット、または適用が一貫していない場合に有効です。よく練られたプロンプトでも、現実の入力のかなりの割合で間違った結果を出す場合は不十分です。
  2. 検索(RAG)。 問題が不足または古い知識であり、動作自体ではない場合に有効です。正しい事実がすでにコンテキスト内にあり、モデルがそれらを無視または誤って適用する場合は不十分です。
  3. より小規模なホストモデル。 タスクが現在のモデルが想定しているものよりも狭く、同じプロンプトを持つより小規模なホストモデルが、より低いコストまたはレイテンシで同じ品質基準を満たす場合に有効です。どのサイズのホストモデルも品質基準をまったく満たさない場合は不十分です。
  4. モデル間のルーティング。 ワークロードが簡単なリクエストと難しいリクエストの混合であり、安価なモデルがすでに簡単なリクエストを正しく処理している場合に有効です。難しいリクエストが実際にコスト、レイテンシ、または品質の苦情の原因である場合は不十分です。

この順序で検討してください。それぞれを試す方がトレーニングよりも安価で、除外も迅速です。

トレーニングが誤った答えである場合

このスキルにおいて最も重要な段落です。カスタムモデルのトレーニングは、少しコストがかかるだけのデフォルトの良いアイデアではありません。それはしばしば誤った答えであり、ここで明確に述べておくことで、後続の無駄な労力を大幅に削減できます。以下のいずれかに該当する場合は、トレーニングを行わないでください。

  • タスクが知識検索であり、動作ではない場合。 モデルが正しい事実をコンテキストに持っていれば正しく動作する場合、ギャップは重みではなく検索にあります。トレーニングは、実行終了後に変化する事実をモデルに教えることはできず、データが変更されるたびに再トレーニングするのは、検索よりも遅く、高価です。
  • 利用可能なサンプルが数百未満の場合。 モデルは、わずかなサンプルから新しい動作を確実に学習することはできません。その閾値を下回る場合は、まずラベル付きデータの作成に投資するか、より良いプロンプト、少数ショットの例セット、または検索など、それを必要としないアプローチを使用してください。
  • 品質基準がフロンティアレベルのオープンエンドな推論である場合。 真にオープンエンドな推論、新しい問題解決、または幅広い一般知識は、トレーニングが小さなオープンモデルに追加するものではありません。トレーニングはモデルを特定のタスクとフォーマットに絞り込みます。小さなモデルをオープンエンドな推論でフロンティアモデルに変えるわけではありません。

これらのいずれかが当てはまる場合は、明確に述べて、「どのベースモデルをファインチューンすべきか」という議論に陥るのではなく、実際に適合する代替案に戻ってください。

トレーニングが適切な場合、目標を定義する

上記のいずれも該当せず、4つの代替案のどれも品質基準を満たさない場合、トレーニングは妥当な次のステップです。ベースモデルやデータセットに触れる前に、以下の5つを書き留めてください。

定義内容
タスク一文で:モデルが実際に行うべきこと、どのような入力に対してか
品質基準具体的で確認可能な合格条件。「良い」や「フロンティアより優れている」ではない
レイテンシ予算数値と、その数値を達成する必要があるランタイム
デプロイ先オンデバイス、ローカル、エッジ、またはマネージドGPUクラウド。制約が実際に存在する場所で決定
成功の測定方法トレーニング後、誰かがジョブが完了したと呼ぶ前に実行される評価

このステップをスキップすることは、トレーニングプロジェクトが、誰も以前よりも改善されたと判断できないモデルを生み出す最も一般的な理由です。その評価を構築する方法については evaluating-a-tuned-model を参照してください。

トレーニングが決定されたら、references/training-options.md に、実際にどこで実行するかについての正直なオプションセット(自前のGPUから複数のホスト型プラットフォームまで、それぞれに実際の選択基準)が記載されています。記憶ではなくそのリファレンスから推奨を行い、テーブル全体を読み返すのではなく、指定された基準が指し示す1つの行を具体的に挙げてください。「どれが最も使いやすいか」という質問に直接答えます。

他の8つのスキル

これは、スイートの残りの部分への入り口です。

スキルステージここに進むタイミング
inspecting-a-model-bundle調査モデルファイルまたはディレクトリがすでに存在するが、その内容が不明な場合
debugging-a-bad-fine-tuneデバッグトレーニング済みモデルが繰り返し、停止しない、またはトレーニングを無視する場合
evaluating-a-tuned-model評価ファインチューンが実際にベースラインを上回ったかどうかを知る必要がある場合
costing-a-model-vs-an-apiコスト計算所有がAPIよりも有利になる使用レベルを計算する必要がある場合
shipping-a-model-in-a-react-native-app出荷React NativeまたはExpoにデプロイする場合
shipping-a-model-in-an-ios-app出荷Swift、MLX、またはCore MLにデプロイする場合
shipping-a-model-in-an-android-app出荷Kotlin、MediaPipe、またはLiteRTにデプロイする場合
shipping-a-model-in-a-flutter-app出荷Flutterにデプロイする場合

決定を文書化する

ユーザーのプロジェクトルートに MODEL-DECISION.md を作成し、この会話を超えて推論が存続するようにします。以下のセクションをこの順序で正確に使用してください。

# モデル決定

## 制約
<コスト | レイテンシ | プライバシー | オフライン操作 | 動作の一貫性。理由を1行で>

## 検討したオプション
<代替案ごとに1行:プロンプト、検索、小規模ホストモデル、ルーティング。それぞれについてなぜ十分だったか、または不十分だったか>

## 決定
<トレーニングする、またはトレーニングしない。トレーニングする場合:上記で定義された目標>

## 成功の確認方法
<これを判断する評価、または evaluating-a-tuned-model へのポインタ>

決定が「トレーニングしない」場合でも、ファイルを作成する価値はあります。それはその理由の記録であり、3週間後に答えを記憶していない状態で同じ質問が再議論されるのを防ぎます。

引き継ぎ先

  • 決定が「トレーニングしない」場合:ここで停止するか、実際に適合する代替案に戻る
  • 決定が「トレーニングする」で、作業に使用するモデルファイルがすでに存在する場合:inspecting-a-model-bundle
  • 決定が「トレーニングする」で、実行する時が来た場合:references/training-options.md からプラットフォームを選択する
  • トレーニングがすでに行われ、評価が必要な場合:evaluating-a-tuned-model

関連スキル