Knitfab v1.5.0 をリリースしました
皆さまこんにちは。あっという間に気温が下がりましたね。季節の移ろいはもうちょっと緩やかに感じていたいものです。
さて、私たちが開発しております 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 の表現が皆さまのお役に立つことを願っています。