techなるイベント内のAIセッションにて登壇させて頂きました。manabiya.tech大きなスペースでフザけたタイトルで発表するという最悪さでしたが、満員になり立ち見状態でした。ありがとうございました。正当な方向性でいけば登壇スライドを公開して終わりなのですが、会社のアカウントでSlideShareにアップロードするという行為に宗教上耐えきれそうにないため、会社情報を含まない範囲でここに思い出と共に書き残す形にしようかと思います。-登壇では、以下3つをテーマに話をしました。私が仕方なく付けた名称」です。AI企業」「AI部門」と声高らかに語る団体は全て嫌いです。2012年頃から日本にも「人工知能、AIブーム」と一般的に呼ばれる"波"が来ました。2016年後頃になると、ブーム自体が一般的に広く認知され、多くの企業が「我が社もAIをやっている」等と言うようになりました。認知されていくタイミングと私が就職活動に勤しんでいた時期が重なり「私は機械学習がやりたいだけだ!人工知能、AIという単語を出した企業は全部こちらからお断りだ!」と躍起になっていたのを今でも覚えています。それから数年、人工知能、AI、データサイエンティスト、機械学習エンジニアといった単語が広く普及した今になってそれらから逃れ仕事をするというのは、現代で「そもそもオタクの語源は〜」と語りながらオタクを続ける程に生きづらいでしょう。セッションでは、生きづらい人生の歩み方を否定している訳ではなく「こうなったら言葉を潤滑油として利用してやろう」という方向性で、それぞれの言葉を実務に埋め込みながらAI屋の仕事を詳しく世に広める話をつらつら行いました。最初に上記の図で、AI屋の仕事というのは以下の3つに分かれる話をしました。分析モデリング研究この分類で大事な点は「それぞれ基盤となる技術は共通」「アウトプットが違う」という所です。分析し次の行動決定を円滑に進める」「ABテストの効果分析」等があたります。分析業務におけるアウトプットは、企業で言えば「データを分析し可視化された結果で人や施策のアクションを決定する」事です。モデリングの業務とは、「データを学習できるモデルを作成する」「学習したモデルのサービスイン」といった所を指します。モデリングのアウトプットは、「実際のサービスで稼働する」となってきます。モデリング業務は、皆サービスのユーザとしては日々感じている場合が多く、より身近かもしれません。Webサービス等において「オススメ商品がサジェストされてくる」だとか「写真にタグを自動で付けてくれる」といった類の物です。分析、モデリングの2つのアウトプットの違いを理解せず人を雇ったり、プロジェクトメンバーを配置してしまうと悲惨な事になりがちです。広く言われる「データサイエンティストの書くコードは汚い」といった発言は、発言者が身を置く環境が「レベルが低い」か「AI屋の認識にズレがある」という所から来ていると私は考えています。研究業務はさておき、上記の図には、各AI屋さんのそれぞれの中身を少し詳しく書いています。独断と偏見も混じっていますが、概ね正しいと自負しています(刺されそうです)。1つ目のスライド図で、分析は「一般的にデータサイエンティスト」、モデリングは「一般的に機械学習エンジニア」のお仕事であると記載しています。2つ目のスライド図では「データサイエンティスト」「機械学習エンジニア」の位置は、それぞれ分析、モデリングに寄りつつも重なった位置に書いています。"一般的に"という説明から2つ目のスライド図を示した通り、近年における「データサイエンティスト」「機械学習エンジニア」という言葉は、揺らぎが強く、分析、モデリング業務を多岐に行っている場合が多くなっています。分析業務とモデリング業務のアウトプットはかなり違うのに...アウトプットまでの課程が変われば、そこで利用するデータや手法、工数割り振り、考え方が変わってきてしまいます。「分析で出た結果が良いのでそのままサービスインしよう!」「モデリングで出来た物が良いので」というのはかなり厳しい訳です。これは、分析、モデリングの工程における統計に基づくデータの加工や、機械学習モデルの選択が変わってくるからです。業務においてプロジェクトを成功に導くには、「データサイエンティスト」「機械学習エンジニア」という言葉から更に深掘りし、どういったアウトプットを要求するかという点を考え、それぞれの業務の経験、得意不得意から適材適所に人を配置しなければいけません。JAPAN研究所を作り「学会での論文発表」「大学との共同研究」「オープンデータ、ソフトウェアの公開」という業務を行っているようです。企業で利用できるデータを用いた国内外のトップカンファレンスでの発表、オープンデータの公開といった業務以外にも多分社内向けの分析基盤を作ったりもしているでしょう。研究はモデリング、分析とは違い、直接的に事業に貢献できる物ではない場合が多い業務です。アルゴリズム」「分析ソフトウェア」等になってきます。AI屋さんのアウトプット基準で分類を定義しました。...といった専門分野が基盤にあるのに対して、アウトプットで見ると全く違うという点です。皆さんが行いたい「AI」って何ですか?専門性ももちろんなのですが、「データサイエンティスト」「機械学習エンジニア」という言葉から更に深掘りし、どういったアウトプットを要求するかという点を考え、それぞれの業務の経験、得意不得意から適材適所に人を配置しなければいけません。(大事なので2回言っています)ただただ「できる機械学習エンジニアが欲しい!」と言ってる人は、「フロントエンド、バックエンドの何がやりたいのか定義せずJavaScriptエンジニアが欲しい!」と言っている人と同レベルです。実際のAI屋さんの業務AI屋さんの1日を見て、どのように業務を進めているかについても話しました。実際に私の平均的な1日を図として示しています。AI屋さんの1日よくわからない人間とのミーティングや雑務を除いて、Qiitaやはてなブログでバズってくるような「機械学習ライブラリを使ってパラメータをイジって学習〜」「データを可視化〜」という部分はかなり上澄みで、実際の業務で使われる時間はどんどん少なくなっています。いくつかの要因がありますが、主には以下です。おいて最も効果的なのが学習データ、タスクの修正であるという話は、AI屋さんの中では以前より存在するかなり当たり前の話です。実際に学習データが綺麗になればなるほど、機械学習モデルの精度は上がっていきます。精度が上がりきらなければタスク自体をより機械学習に適したタスクに落とし込むという作業も有効です。私は前職現職でもひたすら学習用の画像を見て数日を過ごす事もありました。タスク自体を変更するために、年度やユーザ、特定のルールに基づいてデータを収集しなおしたり、問題設定自体を見直すために正解ラベルが入ったExcelファイルと数週間戦う事もあります。いった「泥臭い作業」は、クラウドソーシングで〜という場合もあるにはありますが、基本的には統計、機械学習に関する知見が必要で「これは機械学習で判断できるであろう」という前提を持たなければ出来ない作業です。加えて、そういった「泥臭くない作業以」はフレームワークやマシンの充実で自動化が進んでいます。パラメータの調整手法の充実、機械学習ライブラリや可視化ツール、分散処理技術、GPU、スパコンの存在がそれらを支えています。Japanにはどうやらkukaiと呼ばれるスパコンもあるらしいです(https://about.yahoo.co.jp/pr/release/2017/06/19b/)。(もちろんこれら基盤にお金が必要だったりという場合もありますがその話はここでは取り上げません)。適切な環境やツール、手法さえ選び使う事ができれば、泥臭く最も効果のある作業に集中しアウトプットの質を上げる事が可能なのです。AI屋さんの仕事のサイクルというのは「泥臭い作業をしながら、泥臭くない作業をガンガン自動化して効率化していく」という所に尽きます。作業の効率化の方法は、研究業務にも近く、研究業務のアウトプットが社内外の分析、モデリング業務を支えているというイメージです。AIプロジェクトを上手く回すにはAIプロジェクトを回すコツを3つ紹介しました。使いたいのは誰か決める泥臭くない作業を自動化する要件を順に詳しく決定していく上2つは、今までの話と関連しています。分析、モデリング、研究とそれぞれ利用する技術は同じでも、アウトプットの形が違います。「データサイエンティスト」「機械学習エンジニア」といった言葉も良いですが、より深めて見ないとプロジェクト毎倒れてしまいます。泥臭くない作業というのは積極的に自動化したい所です。自動化しやすい最適なフレームワークやツール、手法の選定はAI屋さんが行うのですが、インフラ屋さんやDB屋さん、果てはハード屋さんの協力も必要でしょう。時にはお金も必要でしょう。「AI屋さんにGPU買ったけど日の半分画像フォルダとにらめっこしてる」という事が多くあると思いますが、そういった時に特に自動化を進められるような協力体制が出来ているとプロジェクト全体が良く回るようになるでしょう。3つ目の要件の決定ですが、目的が決まる毎にAI屋さんと相談すると良さそうです。大きな理由は以下の2つです。ある目的のために集められたデータが他目的に使えるとは限らないサービス要件を満たせるかどうかわからない例えば、泥臭く集めたデータというのはAI屋さんが目的に応じて特定のルールで集め、目的に応じてクレンジング、加工してある物である場合が多いです。それらのデータをそのまま利用して、他タスクでも成果を出すというのは非常に困難です。別の目的で利用した時に考えられる、エラーや課題を許容できる場合であれば良いですが、それらが想定しきれないようであればでデータ集めからやり直しとなってしまう場合もありますので相談はお早めに。目的によっては、せっかく作ったモデルがサービス要件を満たせないという事もあります。Learningがあります。Learningにおける巨大なニューラルネットワークモデルでは、GPU推論で数秒かかってしまう場合があります。毎日数万アクセスがあるサービスで、1ユーザの利用で数秒消費するというモデルを利用するのは、企業として相当な体力が必要です。蒸留...といった回避策が思い付くのですが、目的が曖昧であるとそれら選択肢から選ぶ事すらできません。目的は徐々に相談しながら決めていくと、プロジェクト全体を見た時に成功しやすいでしょう。登壇中も言いましたが、拡大解釈していくとこれらはAIプロジェクトに限った話ではない部分も多いかと思います。泥臭い作業が多い等、AI屋さんならではの話も含んでいるため、それらを考慮し調整しながらサイクルを回す事で、プロジェクト全体が効率よく回るようになるでしょう。-実際の登壇はもう少し実例を出して話をしたとは言え、かなり広い話になってしまいました。様子を見て、初めてAIという広い表題を扱いました。個人的には今後の登壇について考えさせられる事が多く、良い経験となりました。会社名義で登壇するのは面倒事多すぎるので、自身の技術を自身で強く磨いていかないとと思いました。クロスセッションでは、AI関連の質問を受けて他登壇者とセッションしたのですが、夢も希望もない話をしてしまったので、夢と希望が持てる話もネタとして持っておかないとなと思いました。-他のAIセッションの登壇を紹介しておきます。大体全部オススメです。ブームもあってか他の部屋も盛況だったようです。いうイベントでDeNAにおけるAIの取り組みについてトーク&AIについてパネルディスカッションしてきました。参加者の方が普段の勉強会とかよりかなりエンジニアリングよりで新鮮でした。~教師データ作成から学習・性能評価まで~」で使った資料です。ハンズオンの前に機械学習プロジェクトがどのようなものかを学ぶためのものです。無料のディープラーニングハンズオンをします。-MANABIYAというイベントですが、最初に貰った資料がペラペラで信用できず、突然のクラウドファンディングで登壇予定の人がキレてTwitterで辞退宣言したり、連絡のやり取りがめちゃくちゃ遅かったり、懇親会の2次募集すると言ってされなかったりと、「本当にこれだけのエンジニア集めて成功に持っていけるのか・・・?」という不安がめちゃくちゃありました。当日もバタバタしたスタッフとタイトなスケジュールが組まれていたのですが、何とか全てのタスクが回っていて、大炎上するような人は何とか居なかったようです。イベント初回でこの規模を、レバレジーズという会社の規模で回しきったというのは、素直にすげえなあと思います。元学校という会場で学祭のようなわちゃわちゃ感で、それなりのクオリティのイベントに収まっていました。(クオリティが高いのは登壇者がすごいからか...)このイベントが本当にteratailなるサービスの宣伝になっているのか本当に謎ですが、実際にフォロワーに声をかけてもらったり、AIセッション登壇者内でも交流する事ができ、自分としてはそれなりに良い時間を過ごさせて頂きました。ありがとうレバレジーズ。ありがとうteratail。teratail登録はしてみたけど、質問する事がないのでこれから考えます。追記2:その場で質問を壁に貼って誰かが答える面白コンテンツが思い出深かったです。本を読んで筆者に媚を売る記事シリーズです。-スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。