meowの覚え書き

write to think, create to understand

スパイ養成コンテスト!! Open xINT CTF in AVTokyo 2020 write-up と 参加した感想

(私のスコアボード。ブルートフォースしすぎました...)

目次

Open xINT CTFはコンピューターセキュリティのオフラインカンファレンスイベントAVTokyo内の1イベントで、インテリジェンス能力を競うコンテストです。主催はTeam pinjaです。
今年は10月31日に開催されました。前年度に初参加してみてとてつもなく面白かったので、次回開催される日を心より待っていました。
出題ジャンルは例年は現地ならではのSIGINT問やHUMINT問がありますが、今年はAVTokyoがオンライン開催だったこともあり、全問OSINTからの出題でした。

私はチーム名test、ユーザ名emowtetでソロ参加しました。今年は3位に入賞するのが目標で、ふざけたHNが入賞していたら面白いかなと思ってこんな名前にしました。
その結果、700ptで17位(/152チーム)でした。入賞しませんでしたし、HN芸は1位の方がやってのけた感があるので、次回があるならば普通のHNで登録します。

本記事では、私が解けた問題の答案(write-up)を共有します。付録として私の事前対策と他の方々のwrite-up一覧を載せました。


スポンサードリンク

お知らせ(2021年10月23日更新)

xINT CTFのサーバが公開されました!

2021年度のOpen xINT CTFは10/23(土)に開催されます!

  • 参考: AVtokyo2021内のアナウンス
    • 2020年と同じく、参加費無料、オンライン、全てOSINT問、3人までチーム可能です。
  • 参加方法:
    • Open xINT CTFにご興味のある方は、10/23(土曜日) 9:00ごろまでに、
    • AVTokyoに参加登録(AVTokyoのDiscordサーバへ参加)し、
    • Discordに参加した後は、#xint-ctf-generalという名前のチャットルームに集まります(2021/10/21の時点ではまだチャットルームはできていません。)
    • xINT CTFのサーバにアクセスします http://133.242.156.137:2021/

なお、過去の参加報告は↓にまとめています。

meow-memow.hatenablog.com

write-up

問題は7カテゴリ23問あります。私はそのうち5問正解しました。
全問題はスコアサーバにアカウントを作成すれば閲覧、解答できます。スコアサーバのURLはavtokyoのdiscodexint-ctf-generalチャンネルのヘッダを御覧ください。サーバはおそらく11月までの稼働だと思うのでお早めに試されることを推奨します。
(2021/01/23追記)
xINT CTFの問題サーバ3年分が公開されました! 2018年: http://49.212.212.72:2018/
2019年: http://49.212.212.72:2019/
2020年: http://49.212.212.72:2020/
2021/04/04現在、サーバにアクセスできなくなっています。

それでは答案を1つずつ見ていきます1

[BUS] Easy Bus 200

とりあえず、手がかりになるものはないか画像内に映っているものをズームします。

ポールに「山形県」、看板に「ふくの湯」とかいてあるので、検索しました。
すると、場所がヒットしました。あとは、バス停を探すのですが、ふくの湯の近くをストリートビューで調べてもバス停が見つかりませんでした。したがって別の情報を使って解くしかないと判断しました。
尾花沢市のバスを調べると、尾花沢市路線バス時刻表が見つかりました。多分、ここのpdfのバス停のどれかだと踏みました。
そこで、画像内に〇〇温泉というカーペイントがされているバスがあるので、「山形県 温泉」で検索すると銀山温泉というものがあることがわかります。
あとは、銀山温泉へ行くバスを調べればよいのですが、ちょうど銀山線というものがあるようです。 あとは、pdf内のバス停名を総当りでsubmitし、答えを見つけました。

flag: 西原

余談: 解答の後の運営の方のコメント

すみません、少しでも早くポイントが欲しかったので余裕がなかったです^^;

[DarkWeb] Easy Onion 100

私のダークウェブの理解度はほぼ皆無で、耳にしたことこそあれど、実際は何なのか全くわからないレベルです。
ポイントは100ptと少なめなので、頑張れば解けるかもしれないと思い、とりあえずTorをインストールしてみました。

u6ra3igsfurmotk2.onionをTorのフォームに入力すると、一応ページが出てきます。このサーバのipアドレスを突き止めるわけですが、どうやればいいかわかりませんでした。

とりあえず見出しのBIANCO - Plateforme de dénonciation anonyme sécuriséeという単語でchromeで検索すると、大元のhttps://bianco-mg.org/というフランスのサイトが見つかります。内部告発を支援する組織のようです。そのページの中に匿名フォームを用意する主旨で上述のダークウェブへアクセスする手順の載ったページが見つかりました。
このwebサーバがそうなのではないかと思って、$ nslookup bianco-mg.orgで出てくるipをフラグとして提出しましたが不正解でした。

その後は、u6ra3igsfurmotk2.onionnslookup方法をしらべたり、Tor Circuitのipを打ち込んだりといった無知ムーブを繰り返しました。

考えあぐねていましたが、chromeの翻訳機能を使いながらhttps://bianco-mg.org/ブラウジングしていた所、このページからhttps://doleances.bianco-mg.org/というページに行けることがわかりました。このページはTorで見たのと同じレイアウトをしています。

試しに、$ nslookup doleances.bianco-mg.orgした結果を打ち込んだ所、正解しました。

flag: 51.15.97.245

[BASIC] WHOIS 100

問題名の通りですが、$ whois pinja.xyzと叩けばすぐに解けます。
whoisコマンドを使う問題はいつも出題されており、xintctfにおけるwelcome問題の位置付けですね。

フラグ: 2020-10-27T03:28:00.0Z

[BASIC] Aaron 200

まず、兄弟の名前"Aaron Ruben Mordechai"で検索をします。するとBarnett finally closes on $11M Noho portfolioという記事が見つかります。これによると父親のportfolioを巡って3人が争っていたことがわかります。したがって、本名はAaron Muschelということがわかります。
続いて、詐欺事件を検索したいので、"Aaron Muschel fraud New Jersey"で検索します。
すると、Convicted Ponzi-Schemer Indicted On New Fraud And Other Chargesというのがトップに見つかります。ここでテック企業というのがFacebookだというのがわかります。このページに出てくる弁護士の名前をフラグとして提出してみましたが、どれも不正解でした。
2番目の検索結果として、同じような内容のFBIのページが見つかります。しかし、ここにも弁護士の名前は見つかりませんでした。しかし、このページの最後にThis content has been reproduced from its original source.と書いてあり、ニュージャージー州の司法省のサイトへ飛びます。ここの検索フォームで、"Aaron Muschel"と検索すると、Three Arrested, Charged In New Jersey For Multimillion-Dollar Fraud Offering Phony “pre-ipo” Facebook Sharesというページがヒットします。ページ一番下にDefense counselが載っており、そこのAaron Muschel担当の人がフラグでした。

フラグ: James T. Moriarty

[MAP] CG 100

画像リンクはこちら

画像を見た感じ、北朝鮮っぽいなと感じたのですが、URLのドメインがkpなので北朝鮮で確定です。問題は、背景に見えるパフェのような塔と、円盤のついた建物がどこか、なのですが、全く検討が付きませんでした。
とりあえず、ポータルのhttp://www.friend.com.kp/に行き、写真を紹介している場所を探しました。もとのURLからおそらく2019年7月だろうと思い画像ライブラリのバックナンバーをたどりました。その結果、このページで画像が使われていることがわかりました。"Mirae Scientists Street"というタイトルでした。
とりあえず、Mirae Scientists Streetで画像検索すると、パフェのような塔が検索に引っかかり、wikipediaから塔の名前がMirae Unha Towerという名前であることがわかります。
あとはGoogle Mapで"Mirae Unha Tower"で検索して近くの建物を探して終了と思ったのですが、北朝鮮なのでGoogle Mapにインデキシングされていません。

どうするか考えたのですが、Mirae Unha Towerのwikipediaページにはmapが記載されていました。このポイントをもとにしていけばいいと思いました。しかし位置座標のとり方がわからなかったので2wikipedia mapとGoogle Earthを左右に並べて、位置を照らし合わせる行為を行いました。

Mirae Unha Towerの位置をGoogle Earthで特定した後は、円盤のついた建物を見つけ、後は撮影されてそうな位置を総当りで試して正解しました。

フラグ: N38.995 E125.736

参加しての所感

  • 競争の激化
    • 前年度までは、CTFの参加条件がAVTokyo参加者だったこともあり、オンサイト(@渋谷)かつ入場料7,000円という参入障壁がありました。それに加えて、会場のwifiが繋がりにくかったり、パソコンの充電が切れないようにという心配をしながら解く必要がありました。また、オンサイトでアーカイブが残るかわからない中だと、メインホールの講演を聞きながら解かざるを得ず、パフォーマンスを思う以上に挙げられないということもありました。そのため、競争はxINT CTF専門で参加した方たち内の戦いだった気がします。
    • 一方今回は誰でも参加することができ、解くデバイスも用意し放題、また講演もweb配信なのでキャプチャなど使えば保存できることもあり、自分のリソースをCTFに十分に割くことができた方が多かったのではないかと思います。
    • そういう公平な条件でOSINT力が試されるので、必然的に上級者の方々が続々と上位に登られました。特にDarkWebカテゴリは顕著だったと思います。結果として当初楽観的に3位以内に入れると見込んでいた当てが外れました。
  • write-upが充実
    • 競争が激化した反面、競技人口が増えたメリットとしてwrite-upが大量に増えました。
      • 答案の共有があることで、参加者は他人の解答から学ぶことができ、スキルアップに繋げることができます。
    • 過去のxintctfのwrite-upは実はそれほどは多くみつかりません(付録の「事前対策」の項目参照)。したがって、問題の中には解き方はおろか答えすらわからないものもあります。一方今年は、多様な解答が数多く共有されていてOSINTの理解を広げることができました。
    • Discodeで振り返りの時間があったことも大きかったと思います3。テキストチャットに答えが続々投下されました。
  • チームを組んでみたかった
    • 今回はチーム参加が可能だったのですが、総ユーザ数は165で、総チーム数は152だったそうです。1.09人/チームなのでほぼソロ戦ですね。
      • 私はせっかくなので、ツイッターでメンバーをFF内外問わず募集してみましたが、うまくいきませんでした。
    • 各ユーザの回答状況を見てみると、解き方や解くジャンルがバラけていることがわかるので、組むと大きなインパクトがありそうだと思いました。
    • 今回は確かにソロが多かったですが、次回があるならば、オンサイトでの開催であったとしてもチーム参加OKであってほしいと思いました。
  • 問題数が多い
    • 去年は10問だったのですが、チームOKだったからか今年は倍以上になりました。1人では解ききれないと思いますが、問題が多い分だけ解ける問題も増えました。
  • バス問題ガチ勢の存在感
    • 去年もそうでしたが、獲得ポイント最高(故に最難の)バス問題を解くことを至上命題とするかのような猛者が大勢参加されたように見受けられます。時間内に解けた人が9人もいました。他の問題でも3人くらいしか解答できていないのですが...戦慄しました。
  • 総評
    • 初心者でも楽しめて、かつ技術介入度も高く順当に(=変にまぐれ当たりで上位にくることはない)順位が決まるので、よく練られた問題設計だなぁと感じました。
    • 私はセキュリティの専門ではないですが、そのような者から見てxINT CTFは知識無しでもとっつきやすいと思っています。他のCTFジャンルだと前提知識(例えばweb問はwebサーバーの知識、binaryはアセンブリ言語)と問題を解くための知識運用力を身につける必要があり、実際のコンテストで問題が解けるまでに修練を要します。一方で、xINT CTFは検索さえできれば始めることができます。
    • もちろん、「OSINT技術を知っていないと絶対に解けないだろう」という問題もありますが、一方で頑張ればこじ開けられる問題もあるので「難しい、けど解ける。だから楽しい。」といった成功体験を得やすいです。
    • 誰にでも門戸が開かれつつ、強い人のwrite-upを見てOSINTの奥の深さを学べるので、説明文にある"スパイ養成コンテスト"は言い得て妙だと思いました。

改めて運営チームの方々に今年も開催していただけたことを感謝申し上げます。次回の開催を願ってOSINTのスキルアップに励みます!

付録

事前対策

①まず、過去問を見直しました

②また、運営メンバーはTwitterでときどきヒントのようなつぶやきを非公式にあげるので、下記の方々からなるTwitterのリストを用意しました。

③加えて、開催の数週間前に、luminさんがSecurity Days2020にて"ビジネスOSINTでわかる様々なこと"という題で講演されていたので、そちらも視聴しました。

④あと、今年の時事問題が来るかなと予想し、Twitter裏アカウント特定問題が来た時にどうするかのイメトレをしていました。

2020年度の他の方々のwrite-up

私が確認できた範囲でwrite-upを書かれている記事を紹介します。見づらくすみません。o印は記事内で扱われている問題。discodeのチャンネルにも解答が投下されているので併せてご覧いただければと思います。

HN(敬称略) 記事URL
Easy Bus INSIDE BUS Easy Onion 🍳Kyoto-Cool #1 🍳Kyoto-Cool #2 🍳Kyoto-Cool #3 RAMEN DATETIME SUN No.1 No.2 No.3 No.4 No.5 WHOIS Need WiFi Speed Lover Super Easy Aaron Speed Lover Newbie made a mistake CG Star Gazer GATE
solve count→ 69 9 27 5 3 3 3 0 2 6 1 0 0 1 107 4 2 3 2 3 40 1 2
point→ 200 500 100 300 400 400 300 200 300 100 100 200 200 300 100 200 200 200 300 300 100 200 200
o o o o o
chappie https://chapp1e.hatenablog.com/entry/2020/10/31/233739 o o o o o o o
ak1t0 https://medium.com/@ak1t0/open-xint-ctf-2020-darkweb-write-up-17969075228e o o o
_(:3」∠)_ https://st98.github.io/diary/posts/2020-11-01-open-xint-ctf-2020.html o o o o o o o o o
Cyber_ken https://oniyan.hatenablog.com/entry/2020/11/01/085354 o o o o
taru https://github.com/tarugrimoire/Open-xInt-CTF-2020-Writeups o o
f0reachARR https://qiita.com/f0reachARR/items/1044d92b9a071ad564e8 o

同じ問題でも解き方が異なっていて面白いですね。


・『Open xINT CTF 関連ページ 非公式まとめ』へ戻る


  1. 答案だけ見るとスマートに答えを割り出しているように見えますが、裏では試行錯誤を繰り返した末にたどり着いていることを補足します。

  2. 記事を書いている時に気づいたが、普通に右下の"External maps"ボタンから座標を取得できる。

  3. ただ、私はDiscodeの使い勝手がわかっていなかったため、ずっとミュートになっていたようで、気がつけば音声チャンネルでの運営の方々による振り返りが終わっていたのが惜しい所でした。

機械学習のTrainerのクラス図を写経して高解像度にした

f:id:meow_memow:20201010163642p:plain

最近、mediumでWriting a Production-Level Machine Learning Framework: Lessons Learnedという記事を読んだ。
こちらは(PyTorchを使った)機械学習を本番適用する上で心がけるべき6つのポイントを説明した記事である。

その中の1つ"1. Do not reinvent the wheel"で、Trainerの典型的な構成をクラス図(著者いわくhigh-level sketch)としてまとめたものがあるのだが、解像度が低く文字は拡大してやっと読める程度につぶれてしまっていた。
したがって、自分のTrainerに対する知識の整理も込めてこのクラス図をplantumlで写経して、なるべく高解像度な画像した1。なお、元のpumlコードはこちら

コンポネントの位置がオリジナルの画像とずれている理由は、plantumlのコンポネントの位置関係を制御するのが難しかったためである。技術不足で申し訳ない。

EngineクラスがTrainerに当たるものである。論文実装でコードがこの形式で用意されていると嬉しい。 図の中にはPyTorchが提供するクラスもありやや冗長かもしれない。

所感

私は実験でTrainerを作る時は、jupyter notebookで実験したものをリファクタリングする形で作っているが、実験ごとに毎回毎回作ってしまっている。まさしく、元の記事で警告している車輪の再発明状態である。
なので、こういう抽象的な構成のテンプレートコードを持っておいてjupyter notebookのコードをそのテンプレートに適用していったほうが長期的な研究生産性が高まりそうだと思った。世には既にpytorch-lightningみたいな学習ラッパーがあるのでそこら辺を触っていきたい。


  1. なお、この記事トップの画像も同じ画像をアップロードしたのだが、はてなブログ側で勝手に縮小されてしまった。

GANベースの画像変換手法『ACL-GAN』を顔写真→アニメ顔変換タスクを中心に理解する

f:id:meow_memow:20201006215223p:plain

またSelfie2Animeデータセットを扱ったunpairedな画像変換手法が出てきたので「顔写真 → アニメ顔変換」タスクを中心に手法を理解する。おまけで、コードの簡単な実行方法も説明する。
念の為断っておくが、名にACLと冠しているが自然言語処理のトップカンファレンスとは一切関係ない

論文の基本情報

ECCV2020 に採択された論文である。今年の採択率は26%。

論文の概要

ソースドメイン(ここでは人の顔写真)の画像からターゲットドメイン(ここではアニメキャラクターの顔)の画像へ変換することに取り組んでいる。GANベースで、unpairedでも(画像の間で対応が取れていなくても)変換できるようにGeneratorを学習させる手法を提案している。

論文が解決したのは下記のCycle GANの欠点である。

  1. 再構成という制約のために、画像変換時に変換元の画像の情報(ピクセル)を変換先の画像へ埋め込んでしまっている
    • 男性→女性変化の時にひげが残っていたりする
  2. 形状変換能力が弱い
    • 顔写真→アニメ変換だと輪郭を変える必要がある
  3. Cycle Consistency Lossでは決定的な変換しか学習されない
    • ある画像をGeneratorに変換するとき同じ画像からは同じ変換しかされない。これは多様性がない。

そこで、入力画像をピクセルではなく特徴として保持しつつも、多様性が生まれるようなlossであるAdversarial-Consistency Lossを提案している。

lossの全体

トータルの損失関数は下記。

f:id:meow_memow:20201006215558j:plain

\lambdaはlossの重み付けを行うためのハイパーパラメータである。 第1項目がAdversal-Translation Loss、第2項目がAdversarial-Consistency Loss、第3項目がIdentity Loss、第4項目がBounded focus maskのためのlossである。 説明順はメインの第2項目のAdversarial-Consistency Loss、第1項目のAdversal-Translation Loss、第3項目のIdentity Lossである。なお、第4項目は入力画像を変換する部分を制限するためのlossであるが、selfie2animeタスクにおいては\lambda_{mask}は0に設定されているので、説明を割愛する。

Adversarial-Consistency Loss

論文のキーポイントとなるAdversarial-Consistency Loss(ACL)に関して説明をする。
このlossがある意図は2つ。

  1. 1つの画像に対して、多様な変換ができるようにする
  2. ソース → ターゲット変換のGeneratorに対して、ソースドメインの特徴を保持できるようにする

概念図は下図。元のドメインと別ドメインへ行って返ってきた画像を比較するあたりぱっと見Cycle GANと同じ見た目をしている。

f:id:meow_memow:20201006215713j:plain:w400

ACLの具体的な式は下記の通り。

f:id:meow_memow:20201006215814p:plain:w400

式の構成要素の説明

\hat{D}(\cdot, \cdot)ACLのために用意されたDiscriminatorである。画像に対して2値分類する分類器である。引数が2つある件は後述する。
x_Sは入力画像となるソースドメイン側の画像である。これがオリジナルの画像となる。
\bar{x}_T=G_T(x_S,z_1)は、ソースドメインの画像をターゲットドメインへ変換したフェイク画像である。
\hat{x} _ {S} = G_S(\bar{x} _ {T}, z_2)は、ターゲット側のフェイク画像を入力として、ソース側に変換したフェイク画像である。
\tilde{x} _ S=G _ S(x _ {S}, z _ {3})は少しややこしいが、オリジナルのソースドメインの画像に対してターゲットドメインからソースドメインへの画像変換をかけた結果である。Cycle GANでは、これはGeneratorが恒等写像となるように学習されるが、ACL-GANでは下図のように、若干の変化が加わる。このような\tilde{x} _ Sを設ける理由は、データオーグメンテーションの役割ではないかと考える。オリジナルの画像x_Sばかり使うのではなく、そこからノイズでちょっと変換をかけた画像を使う方が多様な変換を獲得できる可能性が高いと著者は考えたのではないだろうか。

f:id:meow_memow:20201006220151p:plain:h400

G_T(x, z)は入力画像をターゲット画像へ変換するGenerator、G_S(x, z)は画像をソース画像へ変換するGeneratorである。画像のGeneratorはMUNITを踏襲している。すなわち、画像をcontentとstyleに分けるエンコーダーをソースとターゲットの2つのドメイン分用意して、変換時に、ターゲット側のスタイルを混ぜてデコーダーに通して画像を生成している。
zN(0, 1)に従うノイズであり、生成器にノイズを混ぜることで画像のスタイルを多様に変換するための乱数である。これにより、同じ画像を入力してもノイズが異なれば生成される画像も異なるようにできる。

ACLの役割

\mathcal{L} _ {ACL}の大雑把な意味としては、ソースドメインの画像(にSrc→Tgt変換をかけた画像)\tilde{x} _ {S}と、ソース→ターゲット→ソースと変換2回行ってソースドメインに戻ってきた画像\hat{x} _ Sの差異をDiscriminator \hat{D}(\cdot, \cdot)で測っているような形である。\hat{D}(\cdot, \cdot)としては、\tilde{x} _ S\hat{x} _ Sとを見分けようとするし、Generatorは\hat{D}(\cdot, \cdot)を騙したいので、これら2つの画像の差異がなくなるように学習していく。
Cycle GANではここを再構成誤差としていたため、1つの画像に対する変換が決定的になってしまう。一方こちらの手法では、識別器\hat{D}で差を測ることで、ソースドメインの画像\tilde{x} _ Sと変換して戻ってきた画像\hat{x} _ Sが異なる画像であっても、同じドメインになっていればOKなのでGeneratorが多様な変換を獲得できるようになる。

\hat{D}(\cdot, \cdot)はどのように実装されているか

\hat{D}(\cdot, \cdot)がxを2つ引数に取る件であるが、これはオリジナルの画像x_Sを連結している。 実際のコードでは、画像をチャネルを軸にして連結している。
例えば画像の入力が[B, C, H, W]として、 一方がtorch.Size([2, 3, 256, 256])で、もう一方もtorch.Size([2, 3, 256, 256])の時、結合時の次元はtorch.Size([2, 6, 256, 256])となる。
画像を連結する意図は、Generatorがソースドメインの元画像の特徴を保持しながら変換する能力を獲得するためのお手本として使用したとのことである(p.6,l.6〜)。
ただ、個人的にはここの設計が不可解である。というのも、G_S(\cdot)x_Sを混ぜるのではなく、Discriminatorで混ぜているからである。確かにDiscriminatorの分類結果をGeneratorが学習するが、やや間接的ではないかと思ってしまう。

Adversarial-Translation Loss

\mathcal{L} _ {adv}=\mathcal{L} _ {adv} ^ {T}+\mathcal{L} _ {adv} ^ {S}

Adversarial-Translation Loss \mathcal{L} _ {adv}はいわゆるGANのloss部分である。すなわちGeneratorとDiscriminatorがいたちごっこしている部分である。
ターゲットドメイン側のloss \mathcal{L} _ {adv} ^ {T}は、下記の通りで、分類器D_Tがrealなアニメ画像x_Tと生成器G_Tが生成したfake画像\bar{x} _ Tを見分ける。

f:id:meow_memow:20201006221048p:plain

ソースドメイン側のloss \mathcal{L} _ {adv} ^ {S}はちょっとだけ違う。fake画像が\tilde{x} _ S\hat{x} _ Sの2つがあるのでlossを折半しているような形。

f:id:meow_memow:20201006221102p:plain

Identity loss

f:id:meow_memow:20201006221137p:plain

ここで x _ {S} ^ {idt}=G _ {S}(x _ {S}, E _ {S} ^ {z} (x _ S)), x _ {T} ^ {idt}=G _ {T}(x _ {T}, E _ {T} ^ {z} (x _ T))

ACLでは、ノイズを加えることで多様な画像を生成できるようにすると言ったが、自分の画像由来で生成したノイズに対しては恒等写像になってほしいようにloss \mathcal{L} _ {idt}で制御する。

これにより、期待できることとして下記の4点を上げている。

  1. 特徴を保持
  2. 変換画像の質を向上させ、
  3. 学習プロセスを安定させることを期待する。
  4. mode collapse(?)を避ける(p.6, 3.3)
    • 学習データセットすべてを変換できるようにしようとしてバランスが取れなくて破滅することだろうか?

Generatorのノイズ引数に入れられているE^{z}(\cdot)は画像をノイズに変換するネットワークとのことらしい。実際のコードを見てみると、下記の手順でMUNITのStyelをAdainのパラメータにしていることを表していた。

  1. GeneratorであるMUNITのEncoder側でStyleとContentを生成
  2. Style情報を多層レイヤパーセプトロンに通してAdaINのパラメータを生成
  3. Decoder側でAdaINの正規化をかけながら解像度を増やして画像にする
  4. Generatorの画像とオリジナルの画像を、ピクセル差でL1ノルムをとって誤差としている。

実験

U-GAT-IT論文を出した研究グループ(NCSOFT社?)が独自に集めた、Selfie2anime dataset(どこからか収集してきた人の自撮り画像とアニメ画像)で評価する。
比べる手法は、Unpairedな画像変換では有名な所5つ。CouncilGANが最も最近の手法である。Council GANについて興味があれば解説記事を書いたので読んでいただけると幸いである。

定性的な評価は下図。CycleGANと比べると輪郭のデフォルメや顔の追従ができていると主張している。個人的には、他の手法の生成画像とそんなに大差ないという印象。

f:id:meow_memow:20201006222052j:plain:w500

定量評価結果としてはFID, KIDでどの既存手法にも勝っている。

f:id:meow_memow:20201006222107j:plain:h300

さらに、U-GAT-ITはパラメータが670.8Mある一方ACL-GANは54.9Mであると主張している。パラメータ数が少ないけど定量評価で勝っていることを強調している。

コードの実行方法

pretrained weightは提供されていない模様。

追記: 私がモデル学習させた時のpretrained weightを下記に置きました。ただし論文とは異なるパラメータで学習させたため、論文の再現には至りませんでした。 github.com

所感

unpairedな画像変換手法の研究としては着実な進歩を進んでいるが、顔写真→アニメ変換に絞って見ると、限界を迎えていそう。そもそものselfie2animeデータセット自体、データがそんなにが良くない可能性がある(鏡越しの自撮りで顔の前にスマホがあったりする)ので進歩がわかりにくい。だから、selfie2animeタスクに絞って手法を研究開発してほしいところである。
また、目や顔や顔が大幅にデフォルメされなければならない以上、もとの特徴を保持することが好ましくないかもしれない。そう思うと、アニメ調に変換といった時、どんなふうなアニメのスタイルに変換することを期待しているのかを決めて手法を設計した方がいいと思った。


  1. ただし有志の方のissueによると学習の再現に失敗している模様。著者が原因を調べるといってcloseされている。 https://github.com/hyperplane-lab/ACL-GAN/issues/3

Laradockでの環境構築時のエラー対処メモ

f:id:meow_memow:20200908221034j:plain

Laravelの勉強を、下記の本で取り組み始めました。

環境構築は、HomesteadではなくLaradockの方を選びましたが、私もご多分に漏れず手順通りに動かしてもエラーが出てしまい、最初のララベルの画面を拝むまでに苦戦しました。
私が躓いた箇所を念の為メモしておきます。


スポンサードリンク

ERROR: for nginx Cannot start service nginx: driver failed programming external connectivity on endpoint laradock_nginx_1 (<ハッシュ値>): Error starting userland proxy: listen tcp 0.0.0.0:80: bind: address already in use

コンテナを立ち上げる時($ docker-compose up -d nginx mysql workspace phpmyadmin)に遭遇したエラーです。 メッセージの通りですが、自分のコンピュータですでにポート80番が使用されています。 laladock/.env内の下記の部分を、空いているポート(10000番など)に変えた後、解消されます。

### NGINX #################################################

NGINX_HOST_HTTP_PORT=80

UnexpectedValueException There is no existing directory at "/var/www/storage/logs" and it could not be created: Permission denied

laravelのエンドポイントにwebブラウザでアクセスしたとき、このようなメッセージとともにデバッグ画面が出ました。 原因は、立ち上げているworkspaceコンテナに対し、ルートユーザでプロジェクトを作成してしまったためでした。 一旦、プロジェクトを消した後、laradockユーザでworkspaceコンテナへアクセス($ docker-compose exec --userlaradock workspace bash )して、プロジェクトを作ると解消されます。

【Council GAN】Im2Im論文『Breaking the cycle - Colleagues are all you need』 を 顔写真 → アニメ顔変換タスクを中心に理解する

f:id:meow_memow:20200709081635j:plain:w500

2ドメイン間で画像の対応が不要(unpaired)な GAN ベースの画像変換(Image to Image translation; im2im)手法である Council GAN について見ていく。手法の試し方も一応載せておく。 なお、私の関心は顔写真 → アニメ顔変換タスク(selfie2anime)のみなので、その他のタスク(メガネ除去、男性-女性顔変換)は扱わない。


スポンサードリンク

論文に関して

CVPR2020 に採択された論文である。
2019 年 11 月にプレプリント版が上がっていたが、2020年6月ごろになってプロジェクトページおよびリポジトリ(github)が公開された1

提案手法の要旨

f:id:meow_memow:20200709082021j:plain GAN全体系のLossにCouncil lossを追加しているところが新規性のポイントである。もう少し補足すると、Cycle Consistency Loss の代わりにCouncil loss(後述)を使った所が真新しい。

ちなみに、第1項目のGAN_lossはLSGANで使われているlossである。すなわち、識別器側は本物と生成器が生成した偽物を見分けるように学習し、生成器側は識別器を本物だと騙すように学習する時のlossである2

Council Loss とは

f:id:meow_memow:20200709082220j:plain:w500

counsilというユニットを複数用意し、それぞれのユニットが相互作用を与えるようにユニット内で loss を計算する。
このcounsilは1ユニット3つの要素からなる。画像生成器  {G_i} 、画像の真贋の識別器 D_i、そして、画像(真贋問わず)が自分のcounsilから生成されたものか否かを識別する識別器 \hat{D_i}である。なお、添字の  i i番目のcounsilにおける要素であることを表している。

council lossの定義は下記。

f:id:meow_memow:20200709082911j:plain

\hat{D_i} はGAN全体系のloss  Vを 上げたいので、自分が所属する i番目のcouncilの生成器  {G_i} の出力画像に対する事後確率は0で、他のcouncilが生成した画像に対しては1に近い値を出すように学習する。すなわち、自分のcounsilが生成した画像をfake、他のconsilが生成した画像をrealと判定したい。(なんか直感と反するけど)。
一方で生成器 G_i側は\hat{D_i}を騙したい。すなわち、自分の生成した画像は同じcouncilから生成したものと見なされたいし、他のcounsilには違うと見なされたいので、他の( jと置く) counsil の生成器  G_jが持たないような特徴を生成するように学習する。
これが Counsil loss の役割のようだ。

Council loss のよい点

p.1,col.2,l.20〜にそれっぽいことが書いてある。

  • 各 council ごとの \hat{D_i}の集合的な意見を活用することで、 G_iがより安定し多様に富んだドメイン変換ができる
    • 生成される画像は、counsil 間で共通の特徴があるべき
    • \hat{D_i}によって、 G_iは他の counsil が見分けられるような特徴を生成するように収束する。これはソースとターゲットドメイン間の相互情報量の最大化をしている。
      • これにより、生成された画像がソース側の重要な特徴を維持する

事実なのか意見なのかはわからないが、このような狙いがあるらしい。

どういうことか考えてみた。例えば、council が 3 つあるとして、 \hat{D_1}を騙すために、 G_2 G_3は共通の特徴を持ちうるということ。 \hat{D_1}は髪の毛の部分を見て自分の counsil かどうかを判定しているとすれば、G_2 G_3は髪の毛の部分は似たような画像変換を獲得する、でも \hat{D_2}も騙したいのでG_2 G_3は髪の毛以外の所で差別化を図らざるを得なくなり、最終的にそれぞれの counsil は共通の特徴を持ちつつもそれぞれ異なる画像変換を獲得する的なイメージだろうか。

また、 \hat{D_i}には、ソースドメインの画像も直接入力している。この理由はソースドメインの特徴も学んでほしいと願っている(wish)からとのこと(p.4 Fig.4の説明より)。

生成器G_iの補足

生成器側は、Encoder-Decoderアーキテクチャだが、デコードフェーズ時に、ノイズ z_iを混ぜている。このことで、多様な画像を生成している(Fig.3)。

f:id:meow_memow:20200709083956j:plain:h250

先行手法Cycle Consistency Loss の欠点

これまでの、unpaired な image to image translation を GAN ベースで実現する研究は Cycle GAN で提案された Cycle Consistency Loss が使われていた。一方、Council GAN は以上のような仕組みで Cycle Consistency Loss を使わずに im2im できるようになった。論文タイトルの「Breaking the cycle」の由来である。

じゃあ何でCycle Consistency Loss がよくないとしているのか理由も調べた。

主に論文 p.2,col.2,l.26〜らへん

  • Cycle Consistency Loss は、不要な制約をかけうる。
    • cycle して元に戻そうとする余り、ターゲットの画像にソースドメイン側の特徴を残してしまう(p.1,col2,l.12)
    • 変化の量を制限してしまう(p.3,col.1,l.11)
  • 隠れた情報が残ってしまうことを回避できる
    • ある研究3によると、Cycle GANはターゲットドメインへの変換時にソースドメインの成分を高周波成分に埋め込んでいるので、Adversal Attackの脆弱性があるとのこと。これにより入力画像に細工をすることで任意の変換ができてしまうとのこと。
  • (Cycle GAN に関わらず、既存の画像変換手法は変換結果に多様性がない)

[脱線]そもそもCycle Consistency Loss はunpairedなim2imとどう関係があるのか

個人的な興味から論文の本筋とちょっと脱線する。そもそも、どういう理屈があってCycle Consistency Lossでunpairedなim2imが実現できるのか気になったのでCycle GAN元論文を読んで調べてみた。

p.4,"3.2. Cycle Consistency Loss"の節

Adversarial training can, in theory, learn mappings G and F that produce outputs identically distributed as target domains Y and X respectively (strictly speaking, this requires G and F to be stochastic functions) [15]. However, with large enough capacity, a network can map the same set of input images to any random permutation of images in the target domain, where any of the learned mappings can induce an output distribution that matches the target distribution. Thus, adversarial losses alone cannot guarantee that the learned function can map an individual input xi to a desired output yi . To further reduce the space of possible mapping functions, we argue that the learned mapping functions should be cycle-consistent:

読んでも私には理解できる力がなかった。特にrandom permutationのあたり。
とりあえず部分的に理解すると、「Adversarial trainingは、理論上はXとYのドメイン間の写像を学習できるが、ネットワークに変換能力が十分にある場合、adversarial lossesだけでは、変換候補先がたくさんありすぎてXからYへ移す保証ができない。そこで、写像が移しうる候補を制限するために、Cycle Consistency Lossを入れるべきだと我々は考えた」的な感じか。
大事なのは、Unpaired im2imに必ずしもCycle Consistency Loss がある必要はないということ。写像がちゃんと獲得できるならば lossは何でもいい。Council Lossはそれを実証している。

実験で手法の比較

councilの数は4。4つのcouncilの生成器から出力された結果の一例が示されている。

f:id:meow_memow:20200709084558j:plain

これに対する著者の定性的な評価(p.7,col.1,l.20〜)としては、

  • 表情や顔の構造(つまり、顎の形状)が入力画像によく似ている。これは、councilのメンバーが入力画像中の特徴の方が"同意"しやすいためだと考えられる
    • ※ "同意"の意味がわからなかったが、GAN 学習時、生成器はソースドメイン側の特徴を持っていれば識別器を騙しやすいということだろうか。そうだとすると当たり前のことを言っている気がする。
  • selfie2anime は難しいタスクである。ドメイン間のスタイルが異なるだけでなく、入力と出力で幾何学的構造も大きく異なる。例えば目のサイズ。このせいで、構造の不一致や歪み、アーティファクトを発生させることにつながる。

なお、プロジェクトページには、selfie2animeテストデータ全100件に対する各im2im手法の生成結果を載せた補足資料が公開されている。GAN論文はいい変換例だけ載せる疑惑があるので、こういうのは助かる。ただ、この資料を見るに、論文に載せている例は変換がうまくいったものを図に採用している感は否めない。

また、定量評価(FID, KID)では先行手法よりも良い結果だったとのこと。

f:id:meow_memow:20200709084736j:plain

何番目のcouncilを使ったのかは不明。 見た目的にU-GAT-ITと差がない印象であるが、定量的には差が出ている模様。

Council GAN を手元で試してみる

公式PyTorch実装がgithubで公開されているので試す。
https://github.com/Onr/Council-GAN

実行環境のセットアップ

Anacondaでの実行を想定しているらしくconda_requirements.ymlが用意されている。requirements.txtは用意されていない。なので私は何回かコードを実行して不足しているパッケージを都度入れた。

ちなみに、Dockerfileも用意されている。公式の現在(2020/07/04)のバージョンのDockerfileはビルドが通らないので、有志がプルリクしているDockerfileを使えばビルドできる

データのダウンロード

  • selfie2animeデータセットのダウンロード
    • $ bash ./scripts/download.sh U_GAT_IT_selfie2anime
      • 先行研究の UGATITで使用されていたものを落としてきている。
      • 画像の拡張子はjpgだが、実態のフォーマットはpngである。処理に問題はない。
    • datasets/selfie2animeに落とされる。
    • データサイズはソース、ターゲットドメインそれぞれ、
      • train: 3,400 枚
      • test: 100 枚
    • あと、データは全員女性4なので、このデータで学習したモデルが男性の画像で正常に変換できる保証はない。
  • 学習済みモデルのダウンロード
    • $ bash ./scripts/download.sh pretrain_selfie_to_anime
    • ./pretrain/anime/に4つのgeneratorが落とされる。

実行(コマンドライン)

  • モデル学習
    • $ python train.py --config configs/anime2face_council_folder.yaml --output_path ./outputs/council_anime2face_256_256 --resume
      • 使用GPUメモリはデフォルトで4000MBくらい
      • チェックポイントは10000stepごとに取られる。
      • チェックポイントがある状態でコマンドを実行すると、最後のチェックポイントから学習が再開する
        • ちなみに、前述の学習済みモデルには、識別器とoptimizerのチェックポイントがないので、学習済みモデルで学習を再開することはできない。
    • モデルのファイル名のフォーマットは<ドメインの方向>_<モデルの役割>_<counsilの番号>_<学習で回したステップ数>.pt
      • 例えばb2a_gen_0_01000000.ptは、ドメインBからA、Generator、0番目のcousil、1,000,000step学習したモデルということ
  • 学習済みモデルで評価
    • $ python test_on_folder.py --config pretrain/anime/256/anime2face_council_folder.yaml --output_folder outputs/council_anime2face_256_256 --checkpoint pretrain/anime/256/01000000 --input_folder ./datasets/selfie2anime/testB --a2b 0
    • outputs/test_resに画像ディレクトリができる
      • デフォルトだと10つできる。
        • 4つのcouncilのうちランダムにgeneratorを選んだ後、decodeフェーズでノイズを混ぜて画像生成している。それを10回繰り返している
        • ノイズはランダムに毎回生成しているため、画像は毎回実行結果が異なる。
    • 自分の用意した顔写真で試したい場合は、datasets/selfie2anime/testBに顔写真を入れればよい。

実行(GUI)

PyQtベースのGUIも用意されていたが、私の環境では動かなかった。 こんなエラーが出る。

$ python test_gui.py --config pretrain/anime/256/anime2face_council_folder.yaml --checkpoint pretrain/anime/256/b2a_gen_3_01000000.pt --a2b 0

test_gui.py:56: UserWarning: Filed to import face_recognition, setting use_face_locations to FALSE
warnings.warn("Filed to import face_recognition, setting use_face_locations to FALSE")
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl, xcb.

zsh: abort (core dumped) python test_gui.py --config pretrain/anime/256/anime2face_council_folder.yaml

lennaさん画像で変換を試して比較してみる

f:id:meow_memow:20200709085014j:plain

f:id:meow_memow:20200709085028j:plain

左上が元画像(ちょっとクロップしている)、上真中が私がlennaさん用にガッチガチにチューニング5したCycleGANの結果。 右上がU-GAT-IT6。形状のデフォルメはされていない。attentionをいれているので形状に注目するはずなのだが。
下がCouncil GAN 10パターン。良いものが出るまで生成ガチャを回した。かなりアニメっぽい。とくに1行5列目のlennaさんはアニメっぽくて気に入っている。

所感

いい画像が生成できるかは確率次第だったので、平均的な性能はU-GAT-ITとあまり変わらないと思う。
タイトルで"all you need" と言っているが、selfie2animeタスクに関しては必要な要素はまだまだありそう。


  1. CVPR2020の開催時期に合わせたものと思われる。

  2. LSGAN の識別器,生成器の学習のコードはこんな感じで実装する。

  3. CycleGAN, a Master of Steganography, https://arxiv.org/abs/1712.02950

  4. このご時世、見た目だけで"女性"というのはポリコレ事案な気がするが、どう言えばいいのかわからないので、とりあえず女性と言っておく。

  5. 詳しくはこちらのスライドで説明: CycleGANで顔写真をアニメ調に変換する

  6. U-GAT-ITの私の解説もよろしければご参照いただければと思います。: 【論文紹介】U-GAT-IT

"Full Stack Deep Learning - Setting up Machine Learning Projects"のメモ

f:id:meow_memow:20200621121307p:plain

What Does it Mean to Deploy a Machine Learning Model? (Deployment Series: Guide 01) - ML in Productionを読んでいたら途中で引用されていたスライド。興味があったので読んでみた。

スライドでは、機械学習プロジェクトのうち、プロジェクトの外観と、プロジェクト計画(目標設定、達成基準の決め方、ベンチマークの決め方)の説明をしている。

英語苦手なのでどのページにどういうこと書いてあったかインデックスがわりにメモっとく。理解できないところは先頭に?マークつけとく

講義の目的(p.2)

  1. MLプロジェクトを理解するためのフレームワークを紹介する
  2. ML prj.の企画と立ち上げのためのベストプラクティスを説明する

この講義で考えるケーススタディ(p.3)

  • grasp model(ロボットアームがものを掴むために)pose estimationをする
  • センサ情報からあるものがどこにあって、どの方角を向いているかを推定する

MLプロジェクトのフレームワーク(p.6)

ML prjのライフサイクル

f:id:meow_memow:20200621121601p:plain

  • ①企画と立ち上げ
    • 内容:
      • pose estimationすることを決める
      • そのための要件と目標を決める
      • リソースを割り当てる
  • ②データ収集とラベリング
    • 内容
      • 学習データを集める
      • センサ(カメラなど)のセットアップ
      • 画像をキャプチャ
      • ラベリングする
    • ②をやってみて①へ戻ることも(p.10~11)
      • 要因
        • データ取得が難しい
        • ラベル付けが難しい
  • ③ 学習とデバッグ(p.12)
    • 内容
      • OpenCVをベースラインにする
      • 既存研究のSoTAモデルの再現
      • 自分の実装したモデルのデバッグ
      • タスクのための改善活動(モデルとかデータ集めとか)
    • ③をやってみて②へ戻ることも(p.14~15)
      • 要因
        • データをさらに集める必要があった。
        • Realize data labeling is unreliable(データが信用できないことに気づく)。
    • ③をやってみて①へ戻ることも(p.16~17)
      • 要因
        • タスクが難しいと気づく。
        • 要件同士のトレードオフがあった。(一番重要な手戻りの要因)
  • ④デプロイとテスト(p.18)
    • 内容
      • 開発(実験)環境でパイロット版を立ち上げてみて、システムがどう動くか把握する
      • 回帰テストを書く
      • 本番環境へデプロイ
    • ④から③へ戻ることも(p.19)
      • 要因: 開発環境の段階で(期待した通りに)動かないので、精度改善を継続
    • ④から②へ戻ることも(p.20)
      • 要因
        • 実験時のデータと、本番データに差異があった。
      • データをもっとあつめる。
      • Mine hard cases(多分、推論が難しいデータを探す こと。)
    • ④から①へ戻ることも(p.21)
      • 要因
        • 設定したメトリクスは実際のユーザの行動に適ったものではなかった(The metric you picked doesn’t actually drive downstream user behavior. )ため、考え直す。
        • 本番環境でのモデルの性能が良くないので、要求を見直す。(例えば、より速さが必要だったり、より精度が必要だったり)

※↑は、個々のプロジェクトにおける進め方。プロジェクト横断するとなると、企画にはチーム編成や採用活動、それ以降ではインフラ構築やツールの開発を考える必要がある。(p.22~24)

  • 他に知っておく必要のあること(p.25)

    • 自分の取り組んでいるドメインにおけるSoTA技術を知ること: 何ができるのかを理解し、次に何を試すべきかを知る
  • ①~④実際にはもっと詳細なステップがある(p.27)

    • ①企画と立ち上げ
      1. プロジェクトのゴールを設定
      2. メトリクスの選択
      3. ベースラインはどれだけかを調べる
      4. set up codebase(リポジトリを作ること?)
    • ②データ収集とラベリング
      1. データの収集戦略を考える
      2. データを集める
      3. ラベル付け
    • ③学習とデバッグ
      1. 一番シンプルなモデルを選んで
      2. それを実装する→モデルをデバッグ
      3. train/val/testを実行
      4. 改善活動案の列挙と優先順位付け
    • ④デプロイとテスト
      1. ステージング?本番環境の準備(pilot)
      2. 受け入れテスト
      3. 本番環境へモデルのデプロイ
      4. 監視
  • 今回の講義では①に関して扱っていく。

    1. プロジェクトの優先順位決め、目標の選定
    2. メトリクスの選定
    3. ベースラインの選定

1. プロジェクトの優先順位決め、目標の選定

優先順位決めに大事なポイント(p.31)

f:id:meow_memow:20200621122014p:plain

  • A インパクトの大きいMLの問題
    • 低コストで予測できることが価値のある
    • 複雑なパイプライン
  • B 実現可能性(Feasibility)
    • ML pro.にかかるコストは、データがどれだけ使えるかによる。しかし、精度の要求も大きな要素である。

A. インパクトの大きいMLの問題

インパクトが大きくて、実現可能性があるところが、取り組む優先順位が高い場所である。(p.32)

影響の大きいMLプロジェクトのためのメンタルモデル(p.33,34 )

  1. predictionを安価にすることがメリットがある場所はどこか
  2. 手作業でやっている複雑な作業のパイプラインのうち、どこが自動化できるか

  3. The economics of AI

    • AIは予測のコストを下げる
    • 予測は意思決定の中心的存在
    • 低コストで予測できることが意味するのは
      • どんな問題にでも予測が使える
      • それまでコストが高かった問題でさえも。(例えば、hiring a driver (?ドライバーを雇う?))
    • すなわち:予測コストを安価にできるとビジネスのインパクトがでかい場所を探そう
  4. Karpathyのツイート(p.35)
    • 「悪いね、勾配降下法は君よりいいコードを書くんだ。」
      • 訳注: 複雑なルールベースの推論ロジックを人がコーディングするよりも、MLモデルで推論をさせた方が結果がいい、みたいな意味だと思う。
  5. ソフトウェア2.0(p. 36)
    • ソフトウェア1.0は従来の、明示的にロジックをコーディングをしたプログラムのこと。
    • ソフトウェア2.0は人間がある目標を定め、(学習)アルゴリズムがその目標を満たすプログラムを探す
    • ソフトウェア2.0におけるプログラマは、データセットを用い、optimizerでコンパイルする(実行プログラムを作る)
    • Why? Works better, more general, computational advantages(? なぜ2.0がいいか。それは、より良く動作し、より一般的で、計算的なアドバンテージがあるから)

まとめ: 複雑なルールベースのソフトウェアを探し、それをMLに置き換えよう。

B. 実現可能性(Feasibility)

機械学習プロジェクトの実現可能性をコストの面で見積もる(p.38〜44)

f:id:meow_memow:20200621121351p:plain

  • プロジェクトにかかるコスト要因は3層。
    • 下がData availability
    • 真ん中がAccuracy requirement:
      • 間違った推論をするとどれだけコストがかかるか。
      • (? 何回くらいシステムを正せば使い物になるか)
    • 上がproblem difficulty
      • すでに類似の問題を解く良い方法が世に出回っているか(問題は新しいほど、リスクが高く、技術開発面で骨が折れる)
      • (? 学習は必要?)
      • (? デプロイできる?)

Accuracy requirement(p.44~p.46)

  • 要求する精度を高くするほどプロジェクトのコストが高くなる。増え方は線形では済まない(super linear)
  • Product design can reduce need for accuracy(p.47)
    • (正直、画像だけで何も書かれていないが、多分言いたいのは次のようなこと)
      • AIによる作業の完全な自動化(それ故の高い精度)を目指すのではなく、人に任せる部分も設けることで、精度の要件をへらすようにサービスをデザインする。
      • MLに何をどこまでさせるか(逆にどこからは人が)を設計すれば精度要件の負担を減らせるかを考えよう。
    • Designing Collaborative AI - Ben Reinhardt - Medium -https://medium.com/@Ben_Reinhardt/designing-collaborative-ai-5c1e8dbc8810
  • 実現可能性を見積もるにあたってのヒューリスティクス(p.48)
    • Andrew Ng「普通の人が1秒未満でできることのほとんどは今のAIで自動化できる」
      • 1秒でできる例:
        • 画像の認識
        • 音声の認識(理解)
        • 音声翻訳
        • 物体認識
      • できない例 -ユーモア、皮肉の理解
        • 手を使う作業をロボットにさせること
        • Generalize to new scenarios(Scenario Generalizationというタスクがあるらしい)

自分のpose estimationプロジェクトの見積もりをやってみる(p.49)

  • Impact
    • 目的はロボットがものをつかめるようになること
    • 従来のロボティクスパイプラインでは、ヒューリスティックとオンライン最適化を用いられていた。それ故、動作が遅く、変化にもろい。それ故、ソフトウェア2.0にすることでインパクトがある!
  • Feasibility
    • Data availability
      • データは集めやすい
      • アノテーションはchallengeな課題だけど、実験部屋にセンサーを取り付けることはできる
    • Accuracy requirement
      • ものをつかむには高いaccuracyが必要。誤差0.5cm以内。
      • だけど、失敗は低コスト。単位時間あたりのつかむ回数が大事。掴むのに成功した回数はそれほど重要ではない。
  • Problem difficulty
    • 既存研究が自分のところに流用できない

2. メトリクスの選定(p. 51)

f:id:meow_memow:20200621122343p:plain

メトリクスの選び方、組み合わせ方

  • メトリクスの選定に重要なこと
    1. 実世界は乱雑(messy)。つねに多くのメトリクスを気を払っておくこと。
    2. とはいっても、MLシステムは一つのメトリクスを最適化する時はbest
    3. 結果として、数あるメトリクスを組み合わせて一つのメトリクス(formula)をつくればいい
    4. この式は変えることができるし、変わるだろう。
  • どうメトリクスを組み合わせるか
    • 相加平均、重みつき平均、など。
    • Thresholding metrics
      • nつのメトリクスがある時に、n-1つのメトリクスはしきい値を設けて足切り用に使い、残りの1つのメトリクスの良し悪しでモデルを評価する(p.66も参照されたし)
  • Thresholding metricsで考えるべきこと(p.64)(ここ、意味がわからなくて訳が思い浮かばなかった。)
    • どのメトリクスを足切りに使うか
      • Domain judgment (e.g., which metrics can you engineer around?) (? ドメインに応じて決める、的な意味か? 工夫できるメトリクスってどういうこと?)
      • Which metrics are least sensitive to model choice? (? モデル選定にあまり影響を及ぼさない的な意味か?)
      • Which metrics are closest to desirable values? (? モデルの要件に望ましい値に最も近いものを選ぶということか? 見逃しが少ない方がいいからrecallで足切りする、的な。)
    • しきい値はどのあたりに定めるか
      • Domain judgment (e.g., what is an acceptable tolerance downstream? What performance is achievable?) (? これもドメインで決める的な意味か。モデルを後の処理で(downstream)使う時の許容範囲で決める、的な。)
      • ベースラインがそのメトリクスでどれだけの値を出すか
      • メトリクスがその時、どれくらい重要かに応じて
  • Thresholding metricsの例(p.66)
    • recallのしきい値を0.6より大きいとする。
    • そのうえで、Precisionを代表的なメトリクスとすると、model1はrecallが届いておらず足切りされる。
  • より複雑、ドメイン固有なメトリクスを作る。(p.69~74)
    • より複雑、ドメイン固有なメトリクスを作る。例えばmAP(なぜ、mAPがドメイン固有なのかは書いていなかった)

メトリクス選定の例として自分のpose estimationタスクにあてはめてみる(p.75~p.81)

  • 要件
    • 最終的にはロボットが現実世界でものをつかめるようになりたい。
    • 位置の誤差は 一旦<1cmとする。このしきい値が本当に適切かはわからない。
    • 角度の誤差は5°以内。
    • 現実世界で100ms以内で動く
  • 実験:
    • いくつかモデルを学習
  • 今のパフォーマンスを要件と比べる
    • 位置エラーは0.75cm~1.25cmある(ハイパーパラメータによる)。
    • 角度誤差は60°くらいある。
    • 推論時間は最大300ms
      • → 角度誤差の対策が優先。位置エラーのしきい値は1cm。実行時間の遅さはここでは無視する。
  • 数値が改善したら、メトリクスを見直す(予定)

3. ベースラインの選定(p.82)

f:id:meow_memow:20200621122400p:plain

  • Key points for choosing baselines(p.83)
    1. ベースラインを決めることで、MLモデルに期待する性能の下限を決める事ができる
    2. 下限が厳しいほど。ベースラインとして有用
      1. 既存の研究結果
      2. 念入りにチューニングされたパイプライン
      3. human baselineなど)
  • なぜベースラインは重要か(p.85)
    • 定めるベースラインが異なれば。自分のモデルの性能とベースラインの差も異なり、その差に応じて次に打つ試作も異なるから。
  • ベースラインをどこで見つけるか(p.86)
    • External ベースライン:
      • ビジネス
      • エンジニアリングの要件
      • 既存の研究結果← フェアに比較していることを確認して!
    • Internal ベースライン:
      • スクリプトベースの方法(OpenCVとか、ルールベースとか)
      • シンプルなMLモデル(標準的な特徴量のモデル bag-of-wordsとか。)
      • 人手で特徴設計された線形分類器(基本的なDNNモデル(batch normarizationのないVGGとか))
  • human baselineをどう作るか(p.92)
    • human baselineのリスト。下に行くほどベースラインの質は高く、また、そのためのデータ入手が困難
      • 無作為に選んだ(一般の)人(例 Amazon Turk)
      • 複数人の無作為に選んだ人
      • ドメインにおけるエキスパート(例 医者)
      • より深くドメインに特化したエキスパート(例 specialists)
      • 複数人のエキスパート
    • How to create good human baselines(p.93)
      • Highest quality that allows more data to be labeled easily(? 最上級品質のベースラインはより多くのデータのアノテーションを楽にしてくれる)
      • ドメインが特化するほど、アノテーターにスキルが必要
      • モデルの性能が低下するケースを見つけ、(そのケースを解決するような)データ収集に絞る

"More on labeling in data lecture" (? より詳しくはデータ回の講義で述べる)

MLCT#12 聴講メモ(特に質疑パート)

Machine Learning Casual Talks(MLCT)は、機械学習技術をプロダクションで動かす際のプラクティスや苦労話を議論する場です。 今回はオンライン開催だったため、動画のアーカイブが残っています↓。


発表もそうなのですが、発表者へ寄せられる質問も実務課題に沿ったものが多く、自分が業務を進めていく上でもリファレンスにできそうなため、質疑のメモを重点的に残しました。

発表 ①: "Cost-efficient and scalable ML-experiments in AWS with spot-instances, Kubernetes and Horovod"の紹介と感想

発表者: 服部 圭悟((元)ABEJA)
スライド URL: https://speakerdeck.com/keigohtr/cost-efficient-and-scalable-ml-experiments-in-aws-with-spot-instances-kubernetes-and-horovod-falseshao-jie-togan-xiang

要旨

(クラウドの)ML プラットフォームを実現するにあたってソフトウェア(サービス)を組み合わせるという課題に対して、"Cost-efficient and scalable ML-experiments in AWS with spot-instances, Kubernetes and Horovod"という記事で紹介されたアーキテクチャコスパもスケーラビリティもよかったので紹介するという趣旨。記事によると、データの読み書きは EFS/EBS、ML バッチマネジャーには k8s、コンテナは AWS のスポットインスタンスを使う。(データ並列な)分散学習をする際には深層分散学習フレームワーク Horovod の API をつかって、単一ノードマルチ GPUインスタンスで学習をするという構成を提案している。

質疑

  1. Q: ML プラットフォームサービスはビジネス的に利益が出るのか。 インフラコストが高くて利益があまり期待できない印象がある。
    • A: クラウドのコストで割高になるが、ML プラットフォームを自力で組もうとすると大変なこと(エージェントの管理、クオーターの管理など)がたくさんあるのでサービスとして価値がある
  2. Q: ML に k8s を使うメリットは何か
    • A: ML エンジニアでも簡単に使えるところ。インフラ知識なくても 自分で計算クラスタを用意できる。また、MLOps 関係の文脈で k8s ベースのツール(kubeflow, horobod)がさかんに開発されており k8s 使った MLOps のエコシステムが整いつつある。その結果 k8s の上で TF、PyTorch の分散学習がしやすくなっている。
  3. Q: 服部さん(or ABEJA)では学習フェーズの厳密な再現も重要視されているか?
    • A: 学習の再現のプライオリティは比較的重要度が低い。世の中的にも重視している事例はそんなに出ていない。PoC や案件を回す方を優先している。ABEJA の顧客では、気にしている人はそこまで多くない。一方で学習の再現性が必要になる分野は人命がかかわるところ(医療、自動運転など)や金融
  4. Q:kubernetes を使った機械学習基盤のアーキテクチャで参考になる文献などありますか。
  5. Q: ABEJA では、生の k8s を使って training 環境を作っているのでしょうか。それとも kubeflow などを使っているのでしょうか。
    • A: 生の k8s の上でホストするサービスを作っている。kubeflow は試したがサービス用途で使っていくには辛いと感じた。

発表 ②: データマネジメントなき ML は、破綻する。〜こんなデータじゃ機械学習できねぇよ問題の処方箋〜

発表者: yuzutas0
スライド URL: https://speakerdeck.com/yuzutas0/20200528
参考: 『データマネジメントが 30 分でわかる本』 (amazon)
yuzutas0 さんが、DMBOK を噛み砕いて平易に解説した電子書籍。500 円という破格なので、ぜひチェックいただきたい。今回の発表もこの書籍の話を ML プロジェクトを例として説明されたものである。

要旨

機械学習ではデータの質が良いことが重要であるが、実際の業務で提供されるデータは(ML で使えるほど)品質がよくない。その理由は業務全体におけるデータマネジメントがなされていないためである。本発表では、書籍 DMBOK の 12 領域を(ML の)業務に照らし合わせて、どのようなデータをどう管理・活用すべきか考察する。
ちなみに時間の都合上発表はされなかったが、スライドの appendix に、ML 関係の業務コンサルをした時の話がある。その中には、ML 側がアプリ側にいくらデータ要件の改善を起票してもアプリ側にチケットの優先順位を下げられていつまでたってもデータの品質改善がされない場合の裏技が載っていたりする。

質疑

  1. Q: データマネジメントの 11 領域どれもとても大切に感じるのですが、どれもこれもできていない場合は、まずどの領域を優先してとりかかるのが良いでしょうか?(すでにある程度データが集まっていて使っている状態の場合)
    • A: 教科書的解答は 1(アーキテクチャ)と 11(ガバナンス)。理由は全体像がわかれば関係者とデータアーキテクチャレベルで会話できるし、ガバナンスルールを作れば、担当者や役割分担され責任者が決まるため。ただし、ML エンジニア的にはデータを作る側の話は見えにくいかもしれないので 8 データの品質管理をおすすめする。すなわち、自分が何が困っていて、なぜ困っているのかか言語化することで、他部門 ML チームがどういうデータ(品質、及びそのギャップ)をほしいのかを伝える際の指針となる。
  2. Q: 現場で「業務整理 → データ整理 →ML→ ビジネス価値」の優先順位について共通認識を得るためにどのような伝え方をしていますか?
    • A: 相手の経験・理解度によるので一概にいえない。素直にデータの品質が悪かったら ML タスクは取り組めないことを言った方が話が進むと思う。
    • A(司会上田さん) 関係者に「(ビジネスの成功/失敗の)再現性得たい場合は、データ整理に投資しないといけないよ、ビジネスの良し悪しのメトリクスを決めるには、まともなデータがないと評価できないよ」、と伝える。
  3. Q: 業務でトランザクションテーブル作るべきか
    • A: 打診してみてもいい。履歴がないとトラブル・法令違反につながることがある。例: EC サイトで商品をカートを入れた後に商品の値段が変わったという苦情がおきたりした時の、証拠として持っておく必要がある。
  4. Q: 成功した ML プロジェクトは 11 領域はどの程度実現できているのか
    • A: 成功という意味では、短期的には勢いでやっても金額でいうと成功する。ただし、その後のいろんな変動要因(担当者の変更)があったり、スケールしようとした瞬間に(11 領域のできていないところから)課題が噴出する。

発表 ③: 使われる機能目指して 測ったり試したり

発表者: 大嶋 悠司(メルカリ)
スライド URL: https://www.slideshare.net/Oshima0x3fd/mlct12
補足: Google Developers Japan: メルカリ : TensorFlow Lite で、気付きにくい便利機能をユーザーに提唱
今回の発表で紹介された取り組みの詳細が載っている。

要旨

メルカリではエッジ AI の適応先の 1 つとして、メルカリアプリ内のバーコード出品推薦機能(カメラで撮られた物体が本かどうか画像分類し、本だったらバーコード出品ができる旨のメッセージを出す)をリリースした。企画からリリースまでに行った取り組み(主にモデル量子化)と機能改善活動に関して述べる。

質疑

  1. Q: 実務でサーバーサイドも tflite で行こうという機運はありますか?
    • A: サーバサイドならば、TF serving で動かしたほうが TFLite よりも早い、なので使う予定はない。
  2. Q: ML を使うという施策はどのように決定されたのか。MLを使わずともUI/UXの改善でバーコード機能を使う人を増やせそうなものだが。
    • A: もちろん UI/UX のみで使う政策も並行で走らせていた。試験した結果、ML と UI/UX を組み合わせたほうが、バーコード出品の増加率がたかいので ML も組み込んだ。
  3. Q: full quantizationの大変な点を伺いたいです。
    • A: 活性化関数のマップをつくるところ。represent dataset(実データを表現するデータ)のサブセットを入れて、活性化関数の値を記録する作業がある。ちゃんとした represent dataset 作らないと精度でない。また、出品される画像のドメインが変化したときモデルのメンテコストが上がって大変になる。今回の機能は full quantization しなくても速度要件は満たしたのでその段階をスキップした。
  4. Q: uint8 に変換したモデルの場合、速度はどれくらい向上するか?
    • A: (自分の記憶でしかないが、)40%くらいは速くなる。
  5. Q: TFLiteはスマホの違いを吸収してくれるか
    • A: すべて吸収してくれるわけではない。iOS はバージョンのしきい値を決めている。android は CPU がばらついているので、CPU アーキテクチャの指定をして推薦機能をオンにするかきめている
  6. Q: TFLite のせいでアプリがおちるとかメモリリークするとかあるか
    • A: 今回の開発では、TFLite 起因のものはおきなかった。ただし、デモ開発の段階でカメラをストリーミング形式で認識しようとするとメモリリークをおこした。
  7. Q: エッジ側モデルを更新する際に気をつけるべきことはあるか
    • A: アプリにモデルを同梱して配布しているが、これは良くない。アプリインストールした後、CDN からモデルを配布したい。今後は、この端末はこのバージョンみたいにして、端末に合ったモデルの配布を考えている。
  8. Q: mixedprecision で学習試したか
    • A: やっていない。キャッチアップできてない。

所感

  • オンライン開催
    • 個人的に非常に助かった。参加抽選はないし、動画アーカイブは残るし、質疑のインタラクション手段(sli.do)も用意されており、いたれりつくせりだった。

改めて運営メンバー、発表者の方々、ありがとうございました。