Skip to content

人工知能に神を期待すること

03-10月-17

タイトルは釣りみたいなもので内容も中2みたいなエントリーだが、4月ごろからフワフワと考えていて、なかなか文章にできないことをアウトプットしてみる。

人工知能脅威論ってネット上でもよく見かける。たとえば

 > 将来は人工知能が全部決めて人間が従うだけ
 > 人工知能が人間に対抗してくる 

などなど。でもディープラーニングによる画像認識のようなちゃちなソフトを人工知能と言うなら、これはおかしな話だと思う。
なぜこんな認識違いが起こるかというと、実は人工知能が脅威だと思っている人と、そう思っていない人ではそもそも人工知能に求めている「機能」が違うんじゃないかっていう話です。

少し話が飛躍するかもしれないが、どんな組織でもいいので、日本型組織を想像してほしい。
働かないトップがいる。実務家がいる。

トップは必ずしも物事の詳細について詳しいわけではない。実務家ほど仕事ばかりやっているわけでもない。全体の方向性を決めたり、たまに口を挟む程度で、実権はあまりない。単なる偉い人だ。
一方で実務家は現場で指揮を取ってあくせく働く。知識も経験も豊富だ。何か決定したら、トップに奏上する。トップはこれを承認する。

実は、トップは余裕がある組織でないと養うことはできない。実務家だけの組織や、実務家がトップを兼任している組織はたくさんある。
それでも、僕は、働かないトップがいる組織の方がパフォーマンスがいいのを何回も見てきた。働かないトップを支えるのは日本型組織の一つの理想形だと思う(多分)。ただし働かないトップを養うためには組織の余裕がかなり必要になる。ある意味贅沢品である。

ここで、トップの果たしている役割と、実務家の果たしている役割は全く違う。
にもかかわらず、トップは実務家のように知識や実行力が豊富であるべきだとされ、実務家はトップのように品格のある人であるべきだとされる。

トップの果たしている「機能」は明らかに重要だが、その意味・内容は実務家のもたらす「機能」と違って明瞭ではない。トップとは何をしている人なのだろうか。

私は仕事でも、あえてこの「トップ」の持つ役割・機能を意識して振る舞うときがある。つまり自分は何もしなくても、ただ黙って傍らで他者の仕事を眺めているだけで、自分は何らの知識や技能がなくても、何もしないよりはうまく仕事が回転していくことをよくある。本当に何もしていない。ただ横にいて見ているだけなのだ。誠に非科学的な話かもしれないが、この時、私は心理的には上司や同僚や部下の心理的負担に手を差し伸べている。お金に例えると、自分はなにもしていないが精神的に作業に「出資」しているような状態だと思う。私は実際には何も働いていない状況ではあるが、人々は私の精神的な出資率も高いと判断して、私も仕事の完遂を願っていると判断して勝手に行動してくれる。そして、終わったあとなぜかとても感謝される。

一方でこの精神的な出資のことを意図的にまたは無意識のうちに軽視していると、どんなに実務能力があっても、あいつは「未熟」であると影口を叩かれる。

このような状況は誰しも経験するのではないだろうか。

上司がまだ仕事をしている時に、特に用事がなくても居残ってしまう日本人の奇妙な性質もこれで説明ができる。例えシゴトをしていないくても、上司と一緒に居残りしている彼は精神的に出資をしているのだ。そしてこの精神的な出資が、とてもありがたく感じられるのである。(念のために書いておくと、そのような仕事法の総合的な善悪までは私は判断しかねる。)

出資者には当然要件があって、それは「仕事の成功を強く願っている」ということが必要だ。逆に「願う」ことさえできれば実務能力はゼロでも構わない。

では「願う」とは何なのだろうか? 既存の枠組み…たとえば強化学習の延長線上で、それは実現できるのか?

その答えは現状では2通りあると思う。(1)マシーンは願っているふりをすることができる (2)マシーンが願うことは実現できていない。
両方共正解だ。欲望するコンピュータというものがまだ開発できていないので(2)は当然だ(本当かな?)

それより(1)に注目したい。人間は仮想的なマシーンを頭の中に構築することで、願っているふりをするマシーンを作ることができる。え?意味がわからないって?もう少し読み進めてほしい。

組織や国家は、昔から膨大な予算をかけてこれをやってきた。卑弥呼の時代から、人々は祈祷をしてきた。シャーマンとはひょっとすると、願う力の強い人たちである。膨大な僧侶を雇い、彼らは鎮護国家を祈祷…「願って」きた。僧侶は膨大な知識を使って仏教理論を構築していった。

奈良の大仏様をみてみよう。人々はコレが銅の塊に過ぎないことを知っている。しかしそれは同時に宇宙の真理を人々に照らし悟りに導く仏なのである。平安時代の人々は仏教による鎮護国家を目指して、真面目に国家予算を使ってこの大きなオブジェを作った。

このオブジェは実質的には何の機能も持たないが、「願う」機能を持つと想定されるオブジェであり、人々を何もせずに「見て」いるのである。つまり擬似的に「トップ」の機能を実現したマシーンの一種だと言ってよいかもしれない。

あるいは、本当の意味で作られたものは、「毘盧遮那仏」という概念であり、この仏像はそのガワに過ぎないにしても…
いずれにしろ毘盧遮那仏のオブジェを見たものには、「毘盧遮那仏」という概念が無意識のうちにインストールされていくのである。

神システムのサーバーサイドを僧侶が担うとして、「大仏様」は人々の頭に毘盧遮那仏という概念…つまり神システムのクライアントソフトを無理なくインストールするための装置と考えると面白いではないか。「大仏様」を見た人たちは、その後の生活でで大仏様のことを考えるときは頭の中で、「奈良の大仏様」を思い出せばいいのだ。

つまり、この点でも歴史は繰り返しているのだと思う。作ろうと思えば、「トップ」すなわち「神」の機能を持つ「人工知能」は作れる。なぜならば「人工知能」に求められている機能は、「神のような実務能力」ではなく「神」の能力なのであり、必ずしも高度な実務能力を実装する必要はないからだ。昔から多くの天才的な「神エンジニア」たちがが国家のために働いてきた。そして現在も…

さて君たちも神を作ってみる気になったかな?
一つアドバイスするなら、神を作りたいなら必ずしも人工知能は要らないということだ。

まあ中2的文章を、これ以上書くと自分でも恥ずかしくて恥ずかしくて大怪我しそうなのでこのへんで。でも書かないと気が済まなかった。

bioruby であそぶ

17-9月-17

自分用メモ

古い情報が多いので少しずつ切り貼りしていく。

参照情報

BioRuby の使い方
・独自のシェル機能の説明が続いてなかなか本論に入らない。本当にシェル機能は必要なのだろうか

塩基・アミノ酸配列を処理する (Bio::Sequence クラス)

・Bio::Sequence::NA クラス
・Bio::Sequence::AA クラス

ファイルを開く

今日の落書き bioruby を眺めてみた

07-9月-17

正確にはbiorubyのyard documentをながめてみた。

眺めた感じだと、Bioモジュールの中に、「手法/プログラム」を扱うクラスと、「ファイル」を扱うクラスと、「データベース」を扱うクラスみたいなのがあるっぽい。
ところがクラスのドキュメントにもOverviewやDiscriptionがないのが多くて、どのクラスが何を扱うクラスなのか、理解するのに若干の困難を感じる。

逆にいうとちょっとドキュメント追記するだけで、Pull Requestがはかどりそうである。多分そういうドキュメントが整備されていないクラスはあまり大事じゃないクラスなんだろうけれども、大事じゃないなら大事じゃないことがすぐわかるようになっててほしい。もうひとつOverviewが書かれないクラスが存在する理由は、同一ファイル内の別クラスに、ほぼ同様の記述があるからじゃないかと想像するが確かめてはいない。

ざっと眺めて感じたのは、Biorubyは処理をするための道具ではなく、ワークフローを書くことを意図しているのだろうということ。
速度を必要とする処理に関しては、C言語なんかで書かれた個別のプログラムを利用するべきなのだと思う。

逆にいうと、今後 Bioruby がどれだけ便利に使っていけるかということは、新しい手法/プログラム/ファイル形式が、どれだけ柔軟にBioモジュールに追加できるかどうか、という点にかかってくると思われる。(もちろんそのような公益な作業をしたい人よりも、単に追加されたクラスを使いたいだけの人が多いに決まっている。)

となると、なぜ2016年で開発が急にストップしているように見えるのかが気になる。

正直なにが何なのかよくわからないので今日はこのぐらい。

numo-gnuplot playground

06-8月-17

今日の落書き red-arrowで遊ぶ

05-8月-17

難しそうなので今日まで敬遠していたred-arrowを使ってみた。
公式の通りインストール。手順通りコピペでインストールしているだけなので何もわかっていないけど、そういうアホなユーザーも世の中一定数いるから仕方ないよね。Pythonの方もcondaでPyArrowをインストールした。

難しそうなので公式のexampleを試すだけ

パイソン

ルビー

おお、普通に動くじゃないか…。
/dev/shmというのが何か気になったのでインターネッツでググるとRAMディスクのことらしい(正確には違うらしい)。

ということは…なにこれすごい∑( ゚д゚ )

公式スライド

正直Webサイト製作に関するプロの道具であることを求めなければ、Rubyでデータ解析できる状況は十分に整ってきていると感じる。

機械学習に関してはscikit-learnのようなライブラリの力を借りる必要があり、pycallを呼び出して適宜red-arrowでデータを変換していくような使い方が望ましいのかもしれない。

RubyやPythonといった便利な道具があることを知らない or キャリアをまともにこなしていると学習コストを支払えない制度設計になっているために、プログラムでやった方が早いことも含めてプログラムと縁のない方法で仕事をこなさざるをえない非エンジニアの世界の方が、エンジニアの世界よりも広いのである。。

今日の落書き Rubyでアヤメ(Iris)のデータを眺める

29-7月-17

データを用意する

https://raw.githubusercontent.com/pandas-dev/pandas/master/pandas/tests/data/iris.csv

Jupyter Notebookを起動する

※ホビーでRubyを手軽に使うのにJupyter Notebookが必ずしもベストとは思わない…

ライブラリを読み込む

CSVファイルを読み込む

SepalLength SepalWidth PetalLength PetalWidth Name
0 5.1 3.5 1.4 0.2 Iris-setosa
1 4.9 3.0 1.4 0.2 Iris-setosa
2 4.7 3.2 1.3 0.2 Iris-setosa
3 4.6 3.1 1.5 0.2 Iris-setosa
4 5.0 3.6 1.4 0.2 Iris-setosa
5 5.4 3.9 1.7 0.4 Iris-setosa
6 4.6 3.4 1.4 0.3 Iris-setosa
7 5.0 3.4 1.5 0.2 Iris-setosa
8 4.4 2.9 1.4 0.2 Iris-setosa
9 4.9 3.1 1.5 0.1 Iris-setosa

アヤメの品種を確認する

Name
0 Iris-setosa
50 Iris-versicolor
100 Iris-virginica

基礎統計量を表示してみる

PetalLength PetalWidth SepalLength SepalWidth
count 150.0 150.0 150.0 150.0
mean 3.759 1.199 5.843 3.054
std 1.764 0.763 0.828 0.434
min 1.0 0.1 4.3 2.0
max 6.9 2.5 7.9 4.4

グループにしてみる

SepalLength SepalWidth PetalLength PetalWidth
Iris-setosa 5.006 3.418 1.464 0.244
Iris-versicolor 5.936 2.77 4.26 1.326
Iris-virginica 6.588 2.974 5.552 2.026

アヤメの品種ごとにデータをわける

SepalLengthのヒストグラム DataFrameから

Nyaplotを使う場合

※ Daruから NyaplotやGnuplotrb、Plotlyを通してグラフを描けるらしい. 残念ながらNyaplotの開発は止まっている…

SepalLengthのヒストグラム Statsampleから

StatsampleがDaruと統合する前に独自に持っていたグラフ機能が残っている

setosaの散布図を描く

Nyaplotを使うとき

Numo::Gnuplotを使うとき

Daru::Vector→RubyArrayへの変換が必要。

相関係数を求める

SepalLength SepalWidth PetalLength PetalWidth
SepalLength 1.0 0.747 0.264 0.279
SepalWidth 0.747 1.0 0.177 0.28
PetalLength 0.264 0.177 1.0 0.306
PetalWidth 0.279 0.28 0.306 1.0

散布図行列

現状では簡単に描く方法は存在していないとおもわれる。

単回帰分析を行う

Numo::Gnuplotで回帰直線を描く

多分Nyaplotでも描ける

重回帰分析

【Daru】Rubyでデータ分析【Statsample】

13-7月-17

Rubyのデータサイエンスに関するコミュニティはまだ小さいです。これはPythonのような、成熟して手の入る余地の少ないプロジェクトよりも遥かに将来性があり、あなたが貢献する余地がたくさん残されているということを意味します。ワクワクしませんか?
このページは素人がテキトーに書いています。まああれだ。頑張れ。

このページで使うライブラリ

Numo::NArray
数値計算
Numo::Gnuplot
グラフ作成
Statsample
統計
Daru
データフレーム

このページで使わないが重要なライブラリ

・red-arrow
・pycall
・rb-libsvm
・liblinear-ruby

便利なので使っているが好きではないライブラリ

・Jupyter-notebook(Jupyterが嫌いなのではなくて、JupyterでRubyを動かすのが何となく嫌)
・IRuby

人気はあるが本当は性能が低いと感じられるライブラリ

・NMatrix
(性能は低いが、作者の政治力と顕示欲は高い。糞味噌に書いたがScirubyへの貢献は大きく、みんな気を使っていると思われる。※個人の意見です)

ライブラリを読み込む

長いので短縮する

いわゆるやりたい放題。SFloatやDataFrameがトップスペースから呼べたらもっと楽しいが…

楽に配列を作成する

棒グラフを描く

折れ線グラフを描く

ベクトルを生成する

NArray配列を生成する

平均値(mean)

中央値(median)

分散(V:variance)

標準偏差(SD:standard deviation)

歪度・尖度

※Numo::GSLを使えば、NArrayでも求められる

範囲

ターミナル上で基礎統計量を表示する

ターミナル上にヒストグラムを表示する

ヒストグラムをSVG形式で保存する

1標本T検定

F検定

U検定

2標本T検定

箱ひげ図を描く

χ二乗検定

散布図

散布図その2

3D散布図

相関係数を求める

Spearmanの相関係数

単回帰分析

重回帰分析

主成分分析

データフレームを作成する

配列からデータフレームを作成する

行や列の情報を取得する

データフレームに行を追加する

CSVファイルからデータフレームをつくる

Microsoft Excelファイルの読み込み

ActiveRecordから読み込み

データフレームの最初と最後を表示する

データフレームの”列”にアクセスする

データフレームの”行”にアクセスする

データフレームの列名を取得する

ソートする

条件によって行を抽出する

行を削除する

列を削除する

データフレームの行⇔列を入れ替える

欠損値のある行を取り除く

グルーピング/集約

データフレームのマージ

※2017年7月時点ではindexによるjoinは開発中らしい
※mergeはpandasのconcatのaxis=1のような動きをするメソッド(vectorをマージするの意味らしい)

軸による連結

数値ベクトルのみのデータフレームを取り出す

時系列のベクトルを作る

時系列ベクトルからグラフを描く


※ GnuplotRBを使用する

データフレームをCSVに書き込む

ロジスティック回帰

statsample-glmを使用する。信頼性はいまひとつか。

【Ruby】 Numo::Gnuplot で箱ひげ図 (boxplot)

09-7月-17

忘れないうちにメモ

1.配列をさっと比較したいとき

2.ラベル付きのデータのとき

using の設定がややこしいけど、丸暗記するしかないっぽいね

なぜゲノムの分野に楽観的な気持ちになれないのか考えた

06-7月-17

漠然とした話。IT系の人達と一部の医療関係者はゲノム解析の分野に大きな期待を寄せているが、どうも個人的にはゲノムにそこまで強い希望を持てない。特に分子標的治療薬によるガンの個別化治療に対してはかなり否定的な気持ちを持っている。どうして自分がゲノム解析にそこまでポジティブな気持ちにならないのか、その理由が少しだけ自分でもわかってきたのでメモしておく。(あまりこういう分野について考えたこともないので用語は変だと思う)

まず、一般化した話から。
技術の進歩を2つに分けて考えてみる

1. 手間(工数)を増やすことによって品質を向上するもの
2. 品質は据え置き〜低下させて、手間(工数)を減少させるもの

 暗黙の了解として、昭和の日本では、実行可能な工数は増え続けるという前提があった。エネルギー革命により石油資源から電気を生み出し、電化製品が家庭でも使われるようになった。労働人口も増加し続けた。その結果1の、工数を増やして品質を向上させる技術がもてはやされるようになった。

 しかし、ついに生産年齢人口は減少し、旧来の方法を漫然と続けるだけでは品質を保つのも困難な時代になってきた。コンプライアンスの強化が叫ばれており、現場は過剰なコンプライアンスに疲弊しているといわれている。これは、本当はこのような活動をしなければ、すぐにでも品質が維持できない状況に陥りそうだということを意味する。

 したがって、今後の日本で評価されるべきなのは、2品質は据え置き〜低下させて、手間(工数)を減少させる技術であると予想される。つまり、技術の評価軸を変える必要がある。

 先進国では、これから日本のような少子高齢化が問題になると予想され、工数を減らす技術が品質を向上させる技術よりも高く評価されるのは、世界的なトレンドになっていくと考えられる。(※個人の意見です)

一般的な話おわり。ここでゲノムの話に戻る。

 ゲノム解析に展望は、個別化医療によって、分子標的薬の治療の品質を上げていくというものであった。個人や病気に最適化された分子治療薬を開発し、それを使う。それは確かに素晴らしいことだと思う。しかし、これは工数を増やしながら品質を向上させる技術である。

 しかし個別化医療をルールベースで行うと多くの思考をともない現場がもたない。これを圧縮するために、人工知能を使用する。なぜならば、人工知能の世界では、今後も計算力の増加が見込まれており、実行可能な工数=計算力は増加し続けると考えられているからである。

 ゲノムによる個別化治療とは、工数を増やすことによって品質を向上させるタイプの医療である。その追求は大変おもしろいだろうし、患者さんにも大きな効果を発揮するだろう。しかし、それはわずかな品質向上のために、莫大な計算力を費やすタイプの医療かもしれないのである。
 そしてそのような医療は、解決しなければならなない社会問題のトレンドや、社会的な要請からは本当は少しずれているかもしれないと考える。

 もちろん僕の考えが間違っている可能性もあるが、正直にそう書いておく。これが僕がゲノム医療に感じる違和感の正体で、そこまでポジティブになれない理由なのだと思う。

 ここまで書いた違和感のほかに、ゲノム研究そのものに対する不満もある。

 そもそも素人考えでは、がん遺伝子がすべて解明できたとしても癌のことが理解できるとは思わない。癌細胞を眺めている人たちは、がんは成功者であるという発想に陥りがちだ。つまり、がん細胞はいくつかの遺伝子を変えて、自ら無限に増殖できるように変身したしたずる賢い成功者だと。癌の本態は遺伝子なのだから、そのような遺伝子をみつけて叩けばいいのだと。

 しかし、私にはそのような腫瘍観は、時代遅れだと思う。癌の本態は本当に遺伝子だろうか。偉い先生は心から本当にそう思っているだろうか。それとも癌全体を理解することは難しいので諦めてしまっているのだろうか。それとも研究費が貰うためにそう言っているだろうか。

 私のなかでは癌は成功者というよりは、貧困地帯に広がるスラム街のようなイメージである。きっと多くの人はそのようなイメージを持っているのではないだろうか。華々しい成功者のイメージは癌にふさわしくない。

 それでも癌を成功者と見なしたいのなら、個別の成功者よりも、そのような成功者を生みだし、許容し、成長させるに至った背景や仕組み、条件に着目したいところだ。個々の成功者のキャラクターや特色、それは成功者を構成するパーツではあるけれども、そればかりに「成功」の原因を帰着するのは狭い考え方だと思う。

 癌を遺伝子病とみる立場は、それと同じような視野狭窄があると感じられる。遺伝子を調べる技術は手元にある。しかし癌をうみだす背景である加齢現象を理解する方法はない。だから癌を治したいという気持ちを強く持って、わかることを一生懸命に調べていると、自然と「癌は遺伝子疾患」という気持ちが過剰になりすぎてしまうのだと思う。その気持ちはわかる。気持ちはわかるのだが、賛成はしない。

 そのほかの意見も、免疫ががん細胞を排除するといった話ばかりで、世知辛い気持ちになる。若年者に癌が生じないのは本当に免疫のためばかりなのだろうか?(直感的には違うと思うけれども、何の根拠もない)

 時代のブームは、物事をみる目を曇らせるし、私達の頭の中を少し不自由にする。
 だからせめて、妄想日記の頭の中ぐらいは、役に立たないことばかり考えて自由にしていたいと思う。

医療とAIの未来について再び妄想する

04-6月-17

頭の整理をするために、また医療とAIの未来について考えている。

医療データサイエンス 1.0

これは、近い将来にきっと起きる変化だ。AIの医療応用を考える多くの人が思い描いている未来だ。
具体的には
・CTやMRI画像などが、Deep Learning技術で自動的に診断できるようになる
・医療用のデータセットを作成する患者団体や、病院、学会が現れる
・APIを用いて医療データを取得する手段が整備されはじめる
・データセンタを持つ企業が医療データを低価格で診断するサービスを始めてデータを収集・蓄積しはじめる 
・対抗して、よりオープンな医療データセットやオープンなモデルも公開される
・大病院が工学技師としてデータサイエンティストを雇いはじめる
・もしくは医者がデータサイエンスをかじりはじめる
・少しずつ人工知能が普及しはじめる
・画像診断の精度、血液検査の精度、内視鏡の精度、遺伝子の解析、心電図モニタリングetc
 すべてでコンピュータが人間を上回る
・個別化された医療が行われるようになる
・診断だけではなく、治療にロボットの活用がはじまる
・確実にどんどん成果を生まれ、治療成績も激的に向上していく
・にもかかわらず、不思議なほど医療そのものには何らの変化がない なんでだろう?
・保険点数が厳しく減額され、利益が減少したりする
・IT企業に対する患者の医療訴訟が多発するようになる。高額の賠償が請求される事例も発生する
・IT企業も、次第に状況を理解して(最初は不合理だと思っていた)製薬会社のやり方を真似するようになる
・もしくはもともと無料でサービスを提供できる体力のあるところだけが他の会社を焼き払う形で生き残る
・最初からこうなることを見越していた老舗企業もしぶとく生き残る
・患者とエンジニアの間にゆっくりと失望が広がっていく
・業界の熱気が冷めて、少しずつ落ち着いてくる
・なんかいい感じになる
といった感じだろうか。とってもワクワクしないよね。あまりにも想像するのが容易だ。
妄想にしても陳腐だ。
こういったことに無邪気に夢を感じるには、少し歳をとりすぎた気がする。

問題は、ここからだと思っている。上記の筋書きはちゃんと考えれば誰もが見通せる素直な未来だ。
未来は、だいたい思い描いた通り素直には歩いてくれない。

医療データサイエンス 2.0

上で描いた1.0は人工知能は、あまり医療の本質に触れていない。
つまり1.0は来るが、そのままの形ではこない。

僕が思いつくだけで大きな焦点は2つあると思う。
1つ目の焦点は、割と簡単だ。簡単だということは、乗り越えうるということである。
乗り越えた先は、たとえばアルファ碁のあとの囲碁界みたいな事になっていると思う。ある意味楽しい世界である。

2つ目の焦点も簡単だが、もう少し医療の本質に関わる問題である。
この問題が乗り越えられるかどうかはわからない。乗り越えるとしたら、人工知能は俺が考えているよりもやばい。
少なくとも、今の段階では人工知能がこういった問題を乗り越えることは想像できないな。多分、人工知能はこの問題を乗り越えられずに迂回すると思う。
少なくとも人間は、こういう問題を直接乗り越えるよりは迂回することを好む。

この問題について、ちょうどいいツイートがあったので引用しておく

そしてその根本にある問題や、その他の問題もおぼろげに見える気がする。

いつものことだが妄想日記にしても考えがよくまとまらない。

考えれば考えるほど、やっぱり人工知能も今までの技術革新と同じで、結局は医療は変わらないという説の方を採用したくなるね。