nokoのブログ

こちらは暫定のメモ置き場ですので悪しからず

MLモデル評価で考えること

はじめに

  • MLモデル評価のまとめ方メモです

メモ

  • 全体を通して、「つまり、現在実践で使えるレベルか?」「課題はどこで、クリアできそうか?それがクリアできたらどれくらい良くなりそうか?」が伝わるようにする
  • 網羅感大事

1. 検証計画再掲

  • スコープ
  • 検証パターン一覧
  • スケジュール、など

2. 定量評価まとめ

  • 前提条件
    • 学習データ、テストデータ
    • 評価方法
  • 混同行列
    • プロジェクトの性質に応じてprecisionとrecallを使い分ける
    • モデルの評価にはF値やIoUを使う
  • 課題の分類は、精度×データ量のマトリクスなど
    • そもそものカテゴリ分類でも

3. 定性評価まとめ

  • 良い例も載せる
  • 課題を書くなら、対応策もセットで書く

4. 考察、ネクストアクション

  • 推論結果の閾値は、妥当な指標が一番高くなるところにするか、あるタグの頻度の妥当性で決めるか
  • 課題を一覧化する。それぞれが、どれくらいの重要度か整理する。(どれくらい精度が上がりそうか)

Macの初期セットアップ手順メモ(vivaldi, vscode, xonsh, etc)(2021)

はじめに

  • Macを初期セットアップしたときのメモ。

キーバインド設定

  • システム環境設定 > キーボード > caps lock -> command(キーボードごとに)
  • ctrlとcmdの入れ替え
  • 入力ソースにローマ字とABC
  • システム環境設定 > キーボード > ショートカット > 入力ソースの変換(英数かな文字変換) command + space (Spotlightは ctrl + space に)
  • 辞書登録

デスクトップ設定

Docks設定

Vivaldi

  • スタートページ登録(新規タブはスタートページ)
  • 設定
    • command + q でタブを閉じる
  • 拡張機能インストール
    • Gmail送信チェッカー
    • Google翻訳
    • Full Page Screen Capture
    • DeepL
    • (switch omega)
  • ダウンロードディレクトリはデスクトップに変更
  • タブは下
  • サイドバーは右。ダウンロード、お気に入り、ウィンドウ

Chrome

Clipy

  • command × 2
  • command + ctrl + R
  • command + ctrl + S

Alfred

Line

Zoom

Slack

Boost Note(EverNote

ToDoist

iTerm2

  • カラー
    • Tango Dark
  • 文字サイズ
    • 16
  • ホットキー設定+デスクトップ上に被せてフルスクリーンで表示
    • iTerm2 > Preferences > General > Window > Native full screen windowsのチェックを外す
    • iTerm2 > Preferences > Profiles > Window > Settings for New Windows > Style, Screen, Space
    • iTerm2 > Preferences > Keys > HotKey > Show/hide iTerm2 with a system-wide hotkeyにチェック
    • command 2回をホットキー設定(Profilesの方から)
    • pin hotkey

ssh設定

  • .ssh/config設定
Host own-dev-app01
    HostName 3.14.15.92
    Port 22
    User ec2-user
    IdentityFile ~/.ssh/own-dev-key.pem
    IdentitiesOnly yes
    TCPKeepAlive yes

vim

# 事前にbrewのインストール
# echo 'export PATH="/opt/homebrew/bin:$PATH"' >> ~/.zshrc
brew install vim
~/.vimrc
"----------------------------------------
" setting
"----------------------------------------
"文字コードをUFT-8に設定
set fenc=utf-8
" バックアップファイルを作らない
set nobackup
" スワップファイルを作らない
set noswapfile
" 編集中のファイルが変更されたら自動で読み直す
set autoread
" バッファが編集中でもその他のファイルを開けるように
set hidden
" 入力中のコマンドをステータスに表示する
set showcmd

"----------------------------------------
" 見た目系
"----------------------------------------
" 行番号を表示
set number
" タイトルを表示
set title
" 現在の行を強調表示
set cursorline
" 行末の1文字先までカーソルを移動できるように
set virtualedit=onemore
" 括弧入力時の対応する括弧を表示
set showmatch
" ステータスラインを常に表示
set laststatus=2
" コマンドラインの補完
set wildmode=list:longest
" 折り返し時に表示行単位での移動できるようにする
nnoremap j gj
nnoremap k gk
" シンタックスハイライトの有効化
syntax enable
" コメントの色を水色
hi Comment ctermfg=3

"----------------------------------------
" Tab系
"----------------------------------------
" 不可視文字を可視化(タブが「▸-」と表示される)
set list listchars=tab:\▸\-
" Tab文字を半角スペースにする
set expandtab
" 行頭以外のTab文字の表示幅(スペースいくつ分)
set tabstop=4
" 行頭でのTab文字の表示幅
set shiftwidth=4

"----------------------------------------
" 検索系
"----------------------------------------
" 検索文字列が小文字の場合は大文字小文字を区別なく検索する
set ignorecase
" 検索文字列に大文字が含まれている場合は区別して検索する
set smartcase
" 検索文字列入力時に順次対象文字列にヒットさせる
set incsearch
" 検索時に最後まで行ったら最初に戻る
set wrapscan
" 検索語をハイライト表示
set hlsearch

Python3

$ brew install pyenv 
$ pyenv install 3.9.2 
$ pyenv global 3.9.2 
$ mkdir -p ~/opt/python_env 
$ cd python_env; pwd 
# 上記でセットアップしたpythonを利用
# /Users/<USER>/.pyenv/versions/3.9.2/bin/python -V
$ python -m venv py392env 
$ source /Users/username/opt/python_env/py392env/bin/activate 
$ pip install numpy 
$ pip install Pillow 
$ pip install jupyter 
$ jupyter notebook --notebook-dir=~/pj/ & 
# Tabnineのインストール

xonsh

  • xonshインストール
# python仮想環境activate後に実施
$ pip install xonsh
$ pip install gnureadline

$ brew install bash-completion2
$ brew install peco

$ which xonsh
->iTerm各プロファイルのCommandを上記パスに修正
  • xonshrcの設定
# python
# source-bash source /Users/username/opt/python_env/py364env/bin/activate

# path
$PATH.append("/usr/local/bin/")

# prompt
$PROMPT = "{INTENSE_RED}{user}{INTENSE_GREEN}@{INTENSE_BLUE}{hostname}{INTENSE_YELLOW} [ {cwd} ] {GREEN}$ "

# tab
$INDENT = "    "

# completion
$COMPLETIONS_CONFIRM = True

# ls
$LS_COLORS="di=34:ln=35:so=32:pi=33:ex=31:bd=46;34:cd=43;34:su=41;30:sg=46;30:tw=42;30:ow=43;30"

# alias
aliases["lt"] = "ls -ltr"
aliases["la"] = "ls -la"
aliases["ll"] = "ls -l"

# complement command and ssh
import os
import json
from collections import OrderedDict
from operator import itemgetter
from prompt_toolkit.keys import Keys
from prompt_toolkit.filters import (Condition, IsMultiline, HasSelection, ViInsertMode)
from prompt_toolkit import print_formatted_text
from prompt_toolkit.styles import Style

@events.on_ptk_create
def custom_keybindings(bindings, **kw):
    # ctrl+rで過去の実行コマンドをpeco
    @bindings.add('c-r')
    def select_history(event):
        sess_history = $(history).split('\n')
        hist = _get_history(sess_history)
        selected = $(echo @(hist) | peco)
        event.current_buffer.insert_text(selected.strip())

    # ctrl+sでssh_config内のhost先をpeco
    @bindings.add('c-s')
    def select_ssh(event):
        hosts = _get_host(True)
        selected = $(echo @(hosts) | peco)
        if selected:
            event.current_buffer.insert_text('ssh ' + selected.strip().split(', ')[0])

    # ctrl+fで今いるディレクトリのfileをpeco
    @bindings.add('c-f')
    def select_file(event):
        r = lambda x: './'+x if os.path.isdir(x) else x
        files = '\n'.join([r(x.split(' ')[-1]) for x in $(ls -l).split('\n')])
        selected = $(echo @(files) | peco)
        event.current_buffer.insert_text(selected.strip())

inquirer_style = Style.from_dict({
    'qa': '#5F819D',
    'qu': '#FF9D00',
    'dp': '#000'
})

def _get_history(session_history=None, return_list=False):
    hist_dir = __xonsh__.env['XONSH_DATA_DIR']
    files = [ os.path.join(hist_dir,f) for f in os.listdir(hist_dir)
              if f.startswith('xonsh-') and f.endswith('.json') ]
    file_hist = []
    for f in files:
        try:
            file_hist.append(json.load(open(f))['data']['cmds'])
        except:
            pass
    cmds = [ ( c['inp'].replace('\n', ''), c['ts'][0] )
                 for cmds in file_hist for c in cmds if c]
    cmds.sort(key=itemgetter(1))
    cmds = [ c[0] for c in cmds[::-1] ]
    if session_history:
        cmds.extend(session_history)
    # dedupe
    zip_with_dummy = list(zip(cmds, [0] * len(cmds)))[::-1]
    cmds = list(OrderedDict(zip_with_dummy).keys())[::-1]
    cmds = reversed(cmds)
    if return_list:
        return cmds
    else:
        return '\n'.join(cmds)

def _get_host(color=False):
    all_text = ''
    text = ''
    for x in $(cat ~/.ssh/config).split('\n'):
        if 'LocalForward' in x:
            text += ', ' + x.strip().split(' ')[1]
        if 'HostName' in x:
            text += ', ' + x.strip().split(' ')[1]
        elif 'Host ' in x:
            if text!='':
                all_text += text + '\n'
            text = x.split(' ')[1]
    all_text += text + '\n'
    if not color:
        all_d = []
        for x in all_text.split('\n'):
            for i,y in enumerate(x.split(', ')):
                if i==0:
                    all_d.append(('class:qu', y))
                if i==1:
                    all_d.append(('', ', '))
                    all_d.append(('class:qa', y))
                    if len(x.split(', '))==2:
                        all_d.append(('','\n'))
                if i==2:
                    all_d.append(('', ', '))
                    all_d.append(('class:qp', y))
                    all_d.append(('','\n'))
        print_formatted_text(FormattedText(all_d),
                style=inquirer_style)
        return
    return all_text

aliases['host']=_get_host

Docker

VS Code

  • font 16
  • Color theme Solalized Dark-
  • [表示]  > [コマンドパレット] > install coと入力 > シェルコマンドを・・・を選択 : code <ファイル名>で開けるように設定
  • venvpathに上記でインストールしたvenvのパスを記載
  • [表示]  > [コマンドパレット] > select intと入力 > インタプリターを・・・を選択 : インタプリタを設定
  • 拡張機能

    • Vim
    • vscode-icons-mac
    • trailing spaces
    • Bracket Pair Colorizer
    • Rainbow CSV
    • Output Colorizer
    • Indenticator
    • indent-rainbow
    • Python
    • Tabnine
    • YAML
    • Remote Development
    • Terraform
    • Docker
    • Markdown All in One
  • キーボードショートカット

// Place your key bindings in this file to overwrite the defaults
[
{
    "key": "cmd+t",
    "command": "workbench.action.files.newUntitledFile" },
{
    "key": "cmd+q",
    "command": "workbench.action.closeActiveEditor"
},
{
    "key": "cmd+h",
    "command": "editor.action.startFindReplaceAction"
},
]

おわりに

  • とりあえず上記で始めて、使いながら追加していこうと思います。

fluentdとKinesisDataFirehostとlogrotateでログの収集とローテをする

はじめに

  • fluentd(EC2→CloudWatchLogs) + Kinesis Data Firehose(EC2→CloudWatchLogs → S3) でログの収集
  • logrotateでログのローテ・改廃(EC2)

fluentdでログの収集

fluentdの仕組み

  • 1つのメッセージは、[tag, time, record]で構成される
  • 流れ
    • Inputプラグイン: 各種データソースからのログにタグを付けて収集する
    • Filterプラグイン: フィルタ(データの加工)を行う
    • Outputプラグイン: 各種データ保存先へ出力する
  • ディレクトリ構成
    • /etc/td-agent/td-agent.conf
    • /var/log/td-agent/
  • ディレクティブ
      • ディレクティブで指定したプラグインを経由してログ収集を始める
      • Inputプラグインを指定
        • tail が多い
          • pos_fileオプションの利用を推奨(再起動しても続きから)
          • formatが特になければnone
      • @type: プラグイン
      • tag: 出力タグ
      • 指定したタグパターンに該当するディレクティブで、タグの書き換えや外部へのデータ出力を行う
      • ログの出力先を決めるディレクティブ
      • @type: プラグイン
        • cloudwatch_logs
          • log_stream_nameをつける代わりに use_tag_as_stream true でも良い

fluentdの設定例

  • 下記のようにS3に直接送る場合もあるが、他サービスと合わせてCloudWatchLogsからS3に送る場合もある
<source>
  @type tail
  path /var/log/httpd/access_log
  pos_file /var/log/td-agent/httpd.access.log.pos
  format apache
  tag td.apache.access
</source>

<match td.apache.**>
  @type cloudwatch_logs
  region ap-northeast-1
  auto_create_stream true
  log_stream_name ${hostname}
  log_group_name ${tag}
  retention_in_days 8
  flush_at_shutdown true
</match>

<match td.apache.**>
  @type s3
  s3_region ap-northeast-1
  s3_enpoint s3-ap-northeast-1.amazonaws.com
  s3_bucket s3-bucket-log
  path ec2/
  time_slice_format ${hostname}/${tag}/${tag}-%Y%m%d%H
  flush_at_shutdown true
</match>
  • (参考)Slack通知バージョン
<source>
  @type tail
</source>

<match td.syslog.**>
  @copy
  <store>
    @type cloudwatch_logs
  </store>

  <store>
    @type s3
  </store>

  <store>
    @type grepcounter
  </store>
</match>

<filter slack.td.syslog.**>
  @type record_transformer
</filter>

...

<match slack.**>
  @type slack
</match>

Kinesis Data Firehoseでログの転送

Kinesis Data Firehoseの仕組み

  • CloudWatchLogsからS3へLambdaでの定期実行をしてはいけない理由
    • Export taskは1アカウント/regionで同時に一つしか実行できない
    • 対象となるデータにはタイムラグがあり、ニアリアルタイムのExportができない
    • 古いログの欠落に繋がる。久しぶりに起動したEC2から古いタイムスタンプのログが送られてきたり
  • 主な構成要素
    • 配信ストリーム(Delivery Stream)
      • データ配信の単位
    • データプロデューサー
      • Kinesis Data Firehose へのデータの送信元
  • Subscription Filterとは

Kinesis Data Firehoseの設定例

  • Kinesis Data Firehose のIAMロールを作成する
  • Kinesis Data Firehose の配信ストリームを作成する
    • データ変換(Lambdaをかます)もできる
    • 配信先を指定(S3など)
    • 上記で作成したロールを指定
  • CloudWatch Logs のIAMロールを作成する
    • CloudWatch Logs が Kinesis Data Firehose にデータを送信するためのIAMロールを作成
  • CloudWatch Logs から Kinesis Data Firehose にデータを送信するためのサブスクリプションフィルタを作成する
    • log-group-name
    • filter-pattern(今回は指定なし)
    • destination-arn
    • role-arn
  • → 概要としては、 kinesis firehose delivery stream とそのIAMロールを作る + CloudWatchの subscription filter とそのIAMロールを作る

logrotateでログのローテ・改廃

logrotateの仕組み

  • /etc/logrotate.confに全ての設定を記載することも可能だが、/etc/logrotate.d以下もincludeされているので、ここにサービスごとの設定ファイルを作成し、記載する。
  • dry run
    • logrotate -dv /etc/logrotate.conf

logrotateの設定例

/var/log/sample/access.log { # 対象のログファイル
    ifempty                  # ログファイルが空でもローテーションする
    daily                    # 毎日ローテートする
    # dataext                # dailyと組み合わせ、元のファイル名 + -YYYYMMDD のファイル名で生成
    dateformat .%Y%m%d       # dateフォーマットを任意のものに変更する
    missingok                # ログファイルがなくてもエラーを出さない
    compress                 # 圧縮する
    delaycompress            # ログの圧縮作業を次回のローテーション時まで遅らせる。compressと共に指定
    rotate 10                # 10世代分古いログを残す
    # create 0644 fuga fuga  # ローテーションを行った後、代わりに空の新規ログファイルを作る。権限・グループ・ユーザを指定可能
    postrotate               # ローテート後にsyslogを再起動
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

参考

MLSE機械学習基盤本番適用と運用の事例・知見共有会参加レポート

はじめに

メモ

ゼロから始めるKubeflowでの機械学習パイプライン構築

  • Reproさん
  • Cloud Composer → Kubeflow
  • プロセスに「実験デザイン」の手法を導入
    • 試行錯誤の手続きを標準化
    • 生命科学の実験デザイン」
  • TFXを導入
    • 機械学習を利用するシステムの設計思想
    • コンポーネントはストレージからデータを読み込み、処理結果をストレージに格納する
  • 実験基盤、検証基盤、サービス基盤
  • 机上実験 → パイプライン実装(FS)
  • Kubeflow Pipelines(AI Platform Pipelines)を選定
    • マネージド、スケーラビリティ、BQ、利用ライブラリを柔軟に選べる(コンテナ)
  • 可視化
    • Feature Importance
    • AUC
    • 損失
  • 通知
    • OOMとか
  • Terraform, CI/CDパイプライン
  • 残課題
    • データ取得のために似たようなコードを書いている
    • 「データサイエンスから秘密のベールを引き剥がし、退屈な仕事にする」
    • サービス基盤は「Human in the loop」
    • Feature Storeの導入
      • ただ、ハードル高い?(費用対効果)
  • 再現性
    • ノートブックの実装とパイプラインの実装は別
  • Apache Airflowはデバックが辛かった?
    • PodのOOMとか。Kubeflowなら検知できる?
    • AI Platformなら、DockerのログがCloud Monitoringに出力される?

リーガルテックにおけるMLOps構築事例の紹介

  • 研究開発チームは、マイクロサービスなAPIを提供するところまで
  • 機械学習のフローだいたいインフラ関わる説
  • 課題
    • マイクロサービス化されたAPI
    • 学習を回す場所がない
    • 実験管理・再現性の問題
      • 再度モデルを作ることができない
      • 問題が起きたときに前の状態に戻れない
      • API開発と機械学習の分離
    • →学習、評価・実験管理→デプロイ に絞って改善
  • 実験管理、モデル/データ管理はMLflow
  • 学習はAI Platform Training Job
  • モデルサービングはSeldon Core
  • 学習基盤の拡張性
    • 学習リソース管理
    • 導入・維持コスト
    • ドキュメント
    • 拡張性
  • MLflow Model Registry
    • Stageを設定し、モデルのバージョンを切り替えることが可能
  • Seldon Core
    • GKEにHelmで入る
    • 推論のPipeline化が特徴
      • エンドポイントを組み合わせ(前処理できる)
    • Dockerfile内でエンドポイント起動ができる
  • MLOpsの効果
    • アジリティ
    • 再現性
    • 自動化・非属人化
  • レポジトリ・コードの雛形化
  • MLを含んだインテグレーションテスト
  • アノテーションはツール使って人手
  • MLflowは小規模でも使いやすい

PLAIDにおけるリアルタイム予測基盤

  • KARTEの解析データはPB級
  • 予測結果は前のeventで予測済みの結果をDBから取ってくる
  • 非同期に渡しておく
  • 連続性のある事象を取り扱う場合は、過去のデータを利用することでサービス提供におけるレイテンシを守る、という事例
  • 推論APIに直接データを渡す訳ではなく、APIにDBのキャッシュを渡す
  • Cloud Spannerを利用
    • (もちろん)BQと全く同じSQLとはならない
    • Bigtableなども検討中
    • TTLがなく、キャッシュが貯まり続ける
    • 実行計画は見える
  • Prediction APIにはCloudRunを利用
    • イメージを指定すればコマンド一つでデプロイ可能
    • 切り戻しもしやすい

モバイル向け機械学習モデル管理基盤

  • サーバで推論を行う場合、1secとかかかる。滑らかな体験のためには、100msec未満が必要。
  • クライアント側で実行すれば、セキュアでもある
  • TF Liteへの変換で軽くなる
    • 情報量は落ちたり
    • モデルの蒸留に加えて、変数の型を小さくしてメモリサイズをコントロールしたり
  • Edgeモデル検証用プラットフォーム
    • モデルごとやデバイスごとの精度・性能評価などを自動化
    • 物理デバイスでのテストをパイプラインに組み込む
  • Firebase Test Lab
    • カバーできないリアルデバイスもある
  • チームとして、Kubeflowを運用している

大規模・複雑な機械学習プロダクトの継続的な改善を支える実験プラットフォーム

  • ドライブチャート
    • エンジニア30名体制
  • エッジデバイスが収集したカメラデータ、センサデータがインプット
  • エッジ時点で、ディープラーニングモデルが特徴量を抽出
  • エッジとレポートの一貫したテスト
    • 結合テストの実施
    • → Kubeflowでパイプラインを
    • Feature Storeを内製
  • Kubeflow Pipeline
    • パラメータのセット、テストデータの準備、実行環境の構築
    • 実験の実行をWeb UIで完結できる
  • feature store
    • テストで抽出した特徴量をFeature Storeに保存
    • テストパイプラインと開発者の間で特徴量を共有する
      • 必要な機能が限定的なため、内製
    • 各データがバージョンを持つ
    • バージョンが同じ特徴量をテスト間で再利用する(キャッシュ)
    • dfをそのまま入出力できるインターフェイスを提供
  • データセット生成はETL Systemへ集約
    • データガバナンスを担保
    • テストで用いたデータは永続化する

ポイント

  • 実験デザインの手法
  • TFXの思想
  • Kubeflow Pipelines(AI Platform Pipelines)でできること・利用コスト
  • Human in the loopを上手く導入するには
  • OOMの通知
  • サービングのSanity Check
  • training-servinng skew対応として、DataflowとTFTを用いた変換(Google
  • delegation
  • Feature Storeに求める役割

監視を復習してみた

はじめに

  • 監視を復習してみたときのメモです

参考

検討項目とポイント

1. データ収集

  • 一般的にプルよりプッシュ(スケールしやすい)
  • とりあえずOSのメトリクスとかを監視しがちだが、監視の目的から逆算すると、「動いているか」の監視が重要
    • HTTP200やリクエストのレイテンシ
  • 設定追加は自動でされるようにするべき
  • 60sに1回はメトリクスを取得する
  • syslogでリモートに転送したり
  • ログの収集は、syslogデーモンを中心に考える
  • 監視サーバ自体の監視を忘れない

2. データストレージ

  • 時系列DB
    • 一定期間後に間引きしてくれたり
    • →ディスク容量、グラフ描画のため

3. 可視化

4. 分析とレポート

  • ペナルティ事項の存在しないSLAは、むしろ「目指すべき目標」

5. アラート

  • 「監視は、質問を投げかけるためにある」
  • メトリクスとアラートが一対一である必要はない
  • 固定の閾値だけでなく、変化量で検知してもよい
  • 全てのアラートが、誰かの対応必須のものになっているか定期的に見直す
  • 自動復旧を目指す
    • 特定の条件で落ちた場合、再起動するなど

監視設定書の項目例

監視項目

  • No
  • 分類
  • メトリクス名
  • 比較演算子
  • 閾値
  • 単位(Count/Percent,etc)
  • 説明

監視対象

監視詳細

  • レベル(error/warn/info)
  • 取得間隔
  • 評価間隔
  • 統計(Minimum/Maximum,etc)
  • 欠落データ(igonre,etc)
  • 方式概要(別ページへのリンク)
  • 通知メッセージ例
  • 有効/無効

監視対象例

ビジネスKPI監視

  • 現在サイトに滞在しているユーザ
  • ログイン

フロントエンド監視

アプリケーション監視

  • 関数の実行時間
    • StatsDを仕込んでおく
    • 特にサーバレスなどだと
  • デプロイタイミング、ビルドデータ、デプロイを実行した人
  • healthエンドポイントパターン

サーバ監視

  • CPU使用率
  • メモリ使用率
  • スワップ使用量
  • OOMKillerの発生
  • インターフェイスに対するイン・アウトのオクテット数、エラー数、ドロップ数
  • ディスク使用率
  • IOPS
  • マウントカウント
  • プロセスカウント
    • sshd
    • crond
    • vsftpd
    • ミドル
  • SSL証明書
  • 秒間リクエスト数
  • リクエスト時間
  • DBコネクション数
  • キューの長さ
  • 秒間メッセージ数
  • キャッシュから追い出されたアイテム数(evicted items)
  • ヒット・ミス率(hit/miss ratio)
  • NTP
  • ログ
    • /var/log/messages
    • HTTPレスポンス
    • sudoの使用
    • SSHログイン
    • cronジョブの結果
    • スロークエリ
    • auditd

実装例

実験管理の現実的な導入ステップを考えてみた

WIP f:id:noko_htn:20210107004403p:plain

3. 【MLパイプラインの導入】

解決できる課題

  • ノートブックのみだと、処理が複雑に分岐するときなどに記述し辛い(バッチ処理として自動化し辛い)
    • (前処理/後処理は共通だが、モデル学習部分は並行して色々な処理を試す、など)

MLOps勉強会Tokyo(Online)#3参加レポート

はじめに

メモ

異音検知プラットフォーム開発におけるMLOpsの実際と考察

  • リサーチャ、ソフトウェアエンジニア、ユーザのそれぞれの目的
    • → 結局、ユーザが課題を解決するためにみんな動いている
    • ResDevOpsでモデルを作っていく
  • リサーチャはクラウド前提の開発をしない
  • ソフトウェアエンジニアは、運用コストを最小限にするため、クラウドが前提
  • ソフトウェアエンジニアが前処理ロジックも学習モデル生成ロジックも移植する
  • PoCの進捗速度が速いとソースコードと結果の関連管理が乱雑になりがち
  • リサーチャが求めた精度が出ない場合があるとは?
    • 開発のデータとの差分
    • PyTorchのバージョンが変わっただけで精度が変わったり
  • 実験管理はGASとスプレッドシートでやったり
  • 本番はSageMakerで動かしている
  • モデルデプロイのタイミングでは、本来は精度比較のテストをするべき
  • コンテナで固めればバージョン固定できるが、SageMakerを使ってるからこそ固定できない
  • PMがリサーチャをまとめる。リードエンジニアがSWEをまとめる。という体制
コードの移植について、
リサーチャのコードをソフトウェアエンジニアが書き直しているとのことですが、
リサーチャが継続的に頻繁にコードを修正する場合、修正点のソフトウェアエンジニアへの連携が難しそうですが、
何か工夫している点はありますでしょうか。(ツールを利用しているなど)

プロダクトの更新スケジュールは決めている
それに向けて、いつ時点のリサーチャのコードを使うよ、と宣言