皆さまこんにちは。あっという間に気温が下がりましたね。季節の移ろいはもうちょっと緩やかに感じていたいものです。

さて、私たちが開発しております MLOps 基盤ツール ”Knitfab” の最新バージョン v1.5.0 を、11/20 にリリースいたしました。今月も無事新しいリリースをお届けできることを嬉しく思います。

v1.5.0 の変更点は次のとおりです。

• Plan 情報に、その隣の Plan の情報を追加しました。
• 機械学習タスクパイプラインを一望できる新コマンド knit plan graph が追加されました。
• (破壊的変更) Data が Run のログとして生成されたとき、その ”upstream” が通常の出力と区別がつかない状態だった問題を解消しました。
• (破壊的変更) Plan 情報の JSON のキーの中に、命名規約が一貫していないものがあったので修正しました。

今回は「WebAPI や CLI 出力に含まれる JSON の構造変更」という破壊的変更を含みます。この「破壊的変更」の影響範囲は「v1.4.0 までの Knitfab が生成した JSON を処理するプログラム」です。

これまでのリネージや実験記録は、v1.5.0 にアップデートしてもそのままお使いいただけます。

Plan 情報に、その隣の Plan の情報を追加しました

knit plan show や knit plan find などで得られる Plan 情報に、その隣の Plan の情報を追加しました。

ここで「Plan A と Plan B が隣である」とは「Plan A に基づいた Run の出力が、Plan B の入力にアサインできる」という関係のことです。このとき、「Plan A は Plan B の上流側の隣にある」「Plan B は Plan A の下流側の隣にある」と捉えます。

この関係を示すために、Plan 情報に新しい要素を追加しました。

{
    "planId": ...
    ...
    "inputs": [
        {
            "path": "/in/1",
            "tags": [ ... ],
            "upstreams": [  // NEW!
              {
                  "plan": {
                      "planId": "...",
                      "image": "...",
                      "entrypoint": [ ... ],
                      "args": [ ... ],
                      "annotations": [ ... ]
                  },
                  "mountpoint": {  // 上流は通常の出力
                      "path": "/out/1",
                      "tags": [ ... ]
                  }
              },
              {
                  "plan": {
                      "planId": "...",
                      "image": "...",
                      "entrypoint": [ ... ],
                      "args": [ ... ],
                      "annotations": [ ... ]
                  },
                  "log": {  // 上流はログ
                      "tags": [ ... ]
                  }
              },
            ]
        }
    ],
    "outputs": [
        {
            "path": "/out/1",
            "tags": [ ... ],
            "downstreams": [  // NEW!
                {
                    "plan": {
                        "planId": "...",
                        "image": "...",
                        "entrypoint": [ ... ],
                        "args": [ ... ],
                        "annotations": [ ... ]
                    },
                    "mountpoint": {
                        "path": "/in/2",
                        "tags": [ ... ]
                    }
                },
            ]
        }
    ],
    ...

Plan の ”inputs” の要素に ”upstreams” という新しいフィールドを追加しました。

”upstreams” に列挙されている各要素は、上流側の隣にある Plan と、隣接関係をつくっている相手方の出力（またはログ）です。「”upstreams” の要素にある出力（またはログ）から書き出された Data は、その入力にアサインされる」というわけですね。

 ”outputs” （と、上の例からは省かれていますが ”log” も）に追加された ”downstreams” はその逆で、下流側の情報、すなわち「その出力（またはログ）が生成した Data がアサインされる入力」が示されています。

これで、Plan について、その上流側・下流側の隣の Plan をたどっていけるようになりました。

機械学習タスクパイプラインを一望できる新コマンド knit plan graph が追加されました

Knitfab においては、機械学習タスクのパイプラインは、先ほど述べた Plan の上流・下流関係にしたがって構築されます。Plan 同士がその入出力の Tag を（Data を介して）参照し合うことで、自動的にタスクの連鎖が進む仕掛けです。

このパイプライン全体を、Plan 同士がつながったグラフ、すなわち「Plan グラフ」として一望するための新しいコマンド knit plan graph が追加されました。

次のように使います。

knit plan graph -n all PLAN_ID | dot -T png > plan-graph.png

こうすると、指定した ID の Plan を起点にして、上流側・下流側に隣接するノードを再帰的にたどっていって、その Plan に関わるパイプラインをグラフに示します。

このコマンドを使うと、たとえば次のようなグラフが得られます。

この図は、Plan 同士の上流・下流関係を矢印の向きで示しています。矢じり側が下流です。

細い黄色い枠が Plan 全体の輪郭を表しています。その中の太い黄色い枠内にその Plan の概要が書かれています。Plan ID の背景に色がついているものが、パイプライン探索の起点となった Plan です（つまり、この例は下流側から Plan グラフを調べた例だ、ということですね）。

輪郭上にある緑の点が入出力やログに対応しています。概要から点に向かって伸びている細い矢印に、その入出力のパスがラベルとしてついています。もしそれがログであるなら、パスの代わりに (log) というラベルがついています。

Plan の間をつないでいる太い矢印が、まさに Plan 同士の上流・下流関係を示しています。

上掲の例はごくシンプルな Plan グラフですが、knit plan graph は、もっと長く、複雑で、分岐・合流を含むような Plan グラフも生成できます。

knit plan graph を使うことで、複雑なパイプラインも、その構造をグラフィカルに確認できるようになりました。

(破壊的変更) Data が Run のログとして生成されたとき、その ”upstream” が通常の出力と区別がつかない状態だった問題を解消しました

knit find data をして得られる Data の情報について、その JSON の構造を一部変更しました。

変更したのは  ”upstream” フィールドです。このフィールドはその Data の生成元である Run の出力やログを示しています。

この変更で、 ”upstream” フィールドは次のようになりました。

Data が通常の出力から生成された場合:

{
    "knitId": " ... ",
    "tags": [ ... ],
    "upstream": {
        "mountpoint": {  // 通常の出力
            "path": "/upload",
            "tags": []
        },
        "run": { ... }
    },
  ......
}

Data がログとして生成された場合:

{
    "knitId": "70c491c1-dffb-4c6c-82c4-b6fcff87b4c8",
    "tags": [ ... ],
    "upstream": {
        "log": {  // ログとしての出力
            "tags": [
                "project:first-knitfab",
                "type:log",
                "type:validation"
            ]
        },
        "run": { ... }
    },
    ......
}

これまでは、”upstream” 要素中の ”mountpoint” や ”log” という要素が存在せず、代わりにその中身がそのまま ”upstream” 要素に書かれていました。さらに、ログの場合は ”upstream”.”path” （出力先のファイルパス）として、”/log” という擬似的な値が書かれていました。この状態だと、Data の ”upstream” を見ただけでは、その Data が本当にログとして書き出されたのか、それとも、単に /log というパスを書き出し先とした通常の出力に書き出されたのか、区別がつきませんでした（Run の情報と突き合わせることで一応確認はとれましたが）。

そこで、これからは、上記のように新しい要素 ”mountpoint” および ”log” を追加して、その Data が何として生成されたか、ということを Data 単体で把握できるようにしました。ただし、そのため、JSON の構造に後方互換性のない変更を加えることとなりました。

(破壊的変更) Plan 情報の JSON のキーの中に、命名規約が一貫していないものがあったので修正しました

これまで、 knit plan show などで得られる Plan 情報のログ情報（”log”）に含まれていた、タグ情報を示すフィールド名は ”Tags” と大文字始まりで書かれていました。

他のフィールド名はすべて小文字始まりの lowerCamelCase で命名されているので、命名規約の一貫性を損なっています。今回の変更では、これを他と同じく小文字始まりの ”tags” としました。

まとめ

以上、Knitfab v1.5.0 のリリースにおける変更点でした。詳細な内容や更新手順、最新版の CLI などは、GitHub のリリースページからアクセスできます。

今回のリリースは、新しいサブコマンドが追加されたことに加え、JSON 構造の破壊的変更を伴うものです。システム側と CLI とを足並みそろえて更新する必要がありますので、ご注意くださいませ。

新機能の knit plan graph と、一貫した Data や Plan の表現が皆さまのお役に立つことを願っています。

著者プロフィール

名前: 高岡陽太

株式会社オープンストリーム／技術創発推進室　

長らく Web 系のシステム開発をしてきたが、2019年頃から機械学習関連の案件に携わり始めた。
ディープラーニングモデルの開発からその API 化、フロントエンド開発まで、必要とあらば一通り手掛ける。
最近は、機械学習それ自体はもとより、機械学習開発を支える技術としての MLOps に興味を持っている。

MLOps 用基盤ツール Knitfab の開発リード。