file：/// C：/ Users / /AppData/Roaming/SAS/JMP/Addins/com.jmp.xgboost/XGBoost%20Add-In.pdf
ページ5：
XGBoost> XGBoost
2番目のレベルのメニューエントリ名は冗長で混乱を招きます。
「フィットモデル」のように、これから取られる行動を明確に示すものを提案します。
ページ6：
「k分割の代わりに単一のホールドアウト分析を実行する場合は、Validation変数のタイプをContinuousに変更し、トレーニングの値が0、検証の値が1であることを確認してください。」
これを機能させる方法があることは素晴らしいことですが、それはそのままでは発見できません。これは、UIで明示的に行う必要があります。たとえば、チェックボックスコントロール。
アドインUI
アドインが、既存のアルゴリズムとともに、[分析]メニューの下に新しいメニューエントリを追加した方が、ユーザーにとってはるかに優れていると思います。つまり、XGBoostは分析>予測モデリング 、後ブーストツリー 。これは、アドイン作成者に公開されたJMPメニューカスタマイズシステムの制限である可能性が高いと理解しています。
XGBoost UIモデルUI
LRTには、「Pythonコードを生成...」オプションがあります。これは、フォーミュラデポで公開されたモデルで使用される名前と同じです。
ただし、生成されたコードは著しく異なり、ユーザーがどちらを使用する必要があるのか明確に示されていません。異なる名前を使用し、ツールチップのテキストでそれらの違いを説明することをお勧めします。
名前が異なると、それらの違いに関する追加情報を提供できるスクリプティングインデックスでそれらを見つけやすくなります。
アドインPython生成コード：
xgboost_jmp.py
「＃russ.wolfinger@jmp.comにコメント、提案、修正を送信してください」
個人アカウントではなく、tech.support @ jmp.comなどの企業アカウントを使用することをお勧めします。
パンダをpdとしてインポート
Pandasは、Python用の一般的な表形式のデータ操作ライブラリとしては良い選択ですが、次のような、より高いパフォーマンスとスケーラビリティを提供する新しいライブラリを使用できないと想定しています。 cuDF そしてダスク 。アダプターインターフェースをコーディングしてPandasのデフォルト実装を提供すると、ユーザーは他の展開オプションの扉を開いたまま、デフォルト実装の恩恵を受けることができます。これらの新しいライブラリは、可能な限りPandas APIに準拠しようとし、ドロップイン置換を提供することさえあるので、難しくありません。特に、メモリが保持できるDaskデータセットをスコアリングする生成コードを示すPOCは、複数のスレッドを使用するか、クラスター全体に分散コンピューティングを使用することでさえ、JMPが最小限の労力でPythonエコシステムを活用できるようにするための優れたセールスポイントになります。
Seabornをインポートする
matplotlib.pyplotをpltとしてインポート
結果を視覚化するためのコードを追加するのは良いことですが、展開シナリオにとっては重荷です。私はその機能を別のモジュールで提供し、依存関係が及ぶ限り、展開コードを可能な限り軽量に保ちます。
つまり、データの視覚化はデモには適していますが、本番環境では役に立たないだけです。生成されたコードは、IMOの運用シナリオ用に最適化する必要があります。
def feature_name_replace（f）
この方法では、2つの異なる機能名を同じ名前にマッピングできるため、潜在的に悪い結果を伴う名前の競合が発生します。たとえば、feature_name_replace（ "A（1）"）== feature_name_replace（ "A.1_"）== "A_1_"などです。
呼び出しコードは、このような競合をチェックしません。
ありそうもないかもしれませんが、ユーザーが変数に名前を付ける方法は制御しないため、チェックする必要があります。
def main（mname、path、df、yvar、xvar、wvar、vvar、cvar、parms、iter、action = 'fit'、
verbose_eval = 100、verbose = True、plot = True）：
＃parms：xgboostパラメーター、デフォルトと異なるパラメーターのみが必要です
辞書「parms」の有効なまたは予期される内容についての文書はありません。
多分それらがどこにあるかへのポインタですか？
＃action = 'fit'：繰り返しk分割交差検証を使用してxgboostモデルを近似
＃action = 'predict'：新しいデータを予測します。バイナリモデルオブジェクトはmodサブディレクトリに既に保存されている必要があります
action = 'predict'のチェックはありません。メイン関数は常にモデルを評価しようとするようです。ユーザーがモデルに適合させたいだけの場合に必要ですか？
また、action = 'fit'がコメント化されている場合にモデルをディスクに保存するコード。そのため、現在action == 'predict'を指定した場合、後で適合モデルを再利用する方法はありません。
＃モデルのバイナリオブジェクトを保存
＃xg.save_model（fname）
＃print（fname）
＃versbose_eval：xgboostイテレーションを出力する頻度
打ち間違え。
＃プロット：action == 'fit'の場合の予測と実際のプロット
プロット機能の有用性については、上記のコメントを参照してください。
Formula Depotが生成したコード：
LRTオプションを使用してFDにパブリッシュし、次にFDオプションを使用してPythonコードを生成しました（メニューアクション名の再利用に関する上記のコメントを参照してください）。
生成されたスコアリングコードファイルは正しいようで、プレースホルダーはありません。理論的には、展開する準備ができています。問題は、お客様がフィールドで生成した同様のモデルのようなものです（ リンク ）モデルが大きすぎて、Pythonインタープリターがクラッシュします。ヘルプで提案されているデフォルト値を使用して、PowderMetarllugy用に生成されたモデルの行数は、82K行に近いコードです。
一時変数の数を減らすことから、生成されたコードを複数の小さなファイル（または少なくとも関数）に分割することまで、この問題に対処する多くの可能な方法があります。すでにあります欠陥そのために開かれましたが、それは優先事項ではありません。
上記のような大規模モデルの一般的な最適化に加えて、欠落値の回避やワンホットエンコーディングの使用などのXGBoostモデルの特殊性を活用して、汎用コード生成エンジン。
スコアリングコードの検証
Pythonインタープリターをクラッシュさせずに実行できるほどモデルを小さくできると想定して、Formula Depotが生成したスコアリングコードのスコアリング結果を、Pythonラッパーが生成したバイナリモデルのスコアリング結果と比較しましたか？生成された数値が実際に同じであることを知っておくことが重要だと思います。このタイプの検証用に構築されたテストツールがPerforceに保存されています。
// depot / main / test / Scoring / Python /。
変更があったとしてもごくわずかな変更で使用できると思います。
xgb_jmp_m1.py
これは、ライブラリの使用方法を示すPOCファイルのようです。
Jupyterノートブックは、この種の「ここに私のライブラリを使用する方法」シナリオの今日の最も一般的な手段であるため、より良い選択です。
また、現在xgboost_jmp.pyの一部であるプロットコードの場所としても適しています。
