MANABIYA 2018 DB kinoshita DB for AItech

Copyright 2018 Scigineer Inc. All rights reserved.©
MANABIYA #1 : DB SESSION
AI技術の一般化でDBに求められること
　　
サイジニア株式会社
木下　靖文
2018年3月23日

自己紹介
 ここ十数年はMySQLのInnoDBの性能ハッカー及び中の人でしたが、
今回はMySQLの話はしないので詳細割愛します。
※ブログ：「DB改造屋雑記」 (http://buildup-db.blogspot.jp/)
 二十年くらい前の大学在籍時は主にニューラルネットワーク系の研究
をしていました。
 最近は過去の知見とMySQL開発で培った技術と最近公開されてる　
モノの組み合わせで、意義ある面白いサービスが構築できないかと考
える日々です。
 AI系に関しては、あくまで只の１、２年生ユーザーであって研究者では
ありません。（謙遜）
2

自己紹介
 最近作ったAI系技術絡みの一般向けサービス
3
「PASHALY」：2017年開始
・画像から似た商品画像を探すサービス
・携帯アプリ（iOS 9.3〜 / Android 5.0 ）〜
・とりあえず、言われた方向で作ってみたが…
「画像で旅する」：β版公開中
・類似画像をブラウズして興味のあるモノを
　探せるサイト
・人間とAI系技術とのインターフェース実験
・trip.deqwas.net

概要
 （ガチ）ミドルウェア畑の元MySQL開発者が新技術で新サービス構築しようとし
て判ったことフィードバックしようという内容になります。
 対象は、「新サービスを自分で考えて構築するような人」をなんとなく想定して
います。AI系専門じゃない人を対象にするので前半長目になります。
　・前半：AI系の事情をザックリ
　・後半：システム化を踏まえてザックリ
＜免責事項＞
 内容はあくまで私の主観で一意見です。この内容に基づく損害に対する責任
は誰も取りません。信じる信じないは各人の責任でお願いします。
 20年近いブランクがあるので、AI系の用語・表現が変かもしれませんが主旨は
内容ですのでご容赦を。後で読んでも解るように、文字多めです。 :-)
4

前半： AI系の事情をザックリ
5
〜AI系専門じゃない人が冷静にAI系と向き合うために〜

『AI』ってとりあえず何だと思っておけばよい？
 どうせ時代で変化するのだから…
定義なんて　
放っておきましょう！
処理の実現性に定義は関係ないので。できるかできないかが重要。
 でも、文章・会話で出てきちゃう単語なので整理しておくと…
6

 時代背景で色々違いますが、昔から共通しているのは…
ＡＩ
‖
自分はよく理解できない（！）が
上手く動いている様に見えるプログラム
※だから、「各個人の理解度」「社会の技術的成熟度」によって定義が”異なる”みたい。
 素人ほど、全てのプログラム（表計算マクロをも）がAIに見える。
 開発者ほど、既にできたものからAIではなくなっていく。
7
※研究者の多くはデータ入力を学習とは呼ばずにトレーニングと呼んだりしますよね？　やっているうちに知能ではなくアホな脳筋にしか見えなくなる？

 今現在、色々なものを「AIだAIだ」、と言っていると、後に発言を振り返ると　
アホの子に見えるのでそろそろ注意が必要。「強い」「弱い」？知らん
e.g.)1990年。某「ガンガンいこうぜ」とかは発売当時、「AI搭載」って言ってたような記憶が…
 「AI」と言う名前のコンポーネントがモノづくりの現場に出てはいけない。
※ 「仕様」も「手段」も見失っている状況。さらには「目的」までも…
※ 単語「AI」は売るとき・製品を外向けに分類するときに後で付くかもなだけ。
 「AI」と言うのは「わかっていない」か「説明したくない」か「相手をナメてる」人。
※有識者に向かって不用意に使うと怒られたりします。それは何かを整理して話すこと。
 作る人は、話から「AI」という単語を排除できないと、それは実現しない。
 我々技術者の仕事は、
「AI」という空想状態を「そういうプログラム」
という現実に変えていく仕事です！！
8

 なので、よく言われる「AIが人の仕事を奪う」のではなく、
只のプログラムがAIに見えてる人の仕事が無くなる
昔も今後も一緒。多少レベルが変わっただけ。
…という愚痴はさておき、
 モノづくりする技術者向けのこのお話では、
今現在、未来のAIを目指した研究から得られた「副産物」を
現在の「AI系技術」と呼ぶことにして、
　　それを上手く利用して今まで難しかった処理ができるシステムを　　
構築していくことを考える人向けのお話をします。
9

AI研究の副産物？「AI系技術」？
 高度で複雑なプログラムは、大きく分けて２つのアプローチ
- 人間が頑張って理解して試行錯誤で作る
※テスト項目=トレーニングデータと考えれば下記と進行は似ているが…
- とりあえず、理解を諦めて(ぉぃ)、
大まかな形だけ決めて大量のデータをぶつけて調整する
 近年の「AI」という単語の指す方向は後者の機械学習系が主
 中でもこの数年で大きく発展したのがニューラルネットワーク系モデル
（他のモデルは割愛です…ファンの方ごめんなさい…）
生物の脳の神経回路にインスパイアされた計算モデルが
ANN(Artificial Neural Networks)です。
※多分脳の処理の本質を突いていない表面的なものと思います。
今の素子モデルの延長線では脳のレベルにはならないのでは？
（主旨から外れるし事実確認できないのでこの議論は割愛）
10

 （乱暴に説明すると、）基本的にデカい行列演算の方程式
 を、データの組を大量用意して連立方程式にして（いい感じに）解く問題
「AI系技術」：ニューラルネットワーク系モデル
11
(
Y1
Y2
⋮
Yk
)=f
(f
((X1 X2 ⋯ Xi )⋅
(
A11 A12 ⋯ A1 j
A21 A2 j
⋮ ⋮
Ai 1 Ai2 ⋯ Aij
))⋅
(
B11 B12 ⋯ B1 k
B21 B2 k
⋮ ⋮
B j1 Bj 2 ⋯ Bjk
)):
:
i
2
1
j
:
:
2
1
k
:
:
2
1
入力 X
出力 Y
A
B
（単純な３層パーセプトロンの例）
Y =F(X)
Y '=F(X ')
Y ' '=F(X ' ')
Y ' ' '=F(X ' ' ')
⋮
A ? B?
勿論、一意には定まらないので、
他のデータ組でもいい感じに
なるように解く…
いきなりは解けないので、データを提示
しては正解出力に近づくようにパラメー
タを漸化的に微調整するのを繰り返す。

 単純なものは 1960年前後から
1970年台になると畳み込み演算でパターン認識を行ったり、(この時
点で構造的にはCNNと呼んで良いと思います。)構成要素の基礎にな
るものはかなり昔から存在していて、文字識別レベルでは実用化されて
久しい。
 超長年の問題の解決 → ディープラーニング
 層を深く多層にするともっと高度な処理ができそうですが、結局入力側
の層のパラメータチューニングしかできないことが超長年の問題
2000年台中盤に（やっと）オートエンコーダー（後で出てきます）という考
え方で先の層までチューニングできるようになった。　　　　　　　　　　　　
　　→ 力業が効くようになる（大量データと演算能力で解決）
 何が進歩したか？
「AI系技術」：ニューラルネットワーク系モデル
12
→ 『B』
→ 『d』
→ 『犬』
→ 『猫』
入力可能情報量は増えた
が、知的レベルは…
上がってない？！

…で、要するに何？
そ　れ　で　す　！　（ぇ？）
 基本的に「要するに何？」を何か「機械の勘で」処理することができます。
 ゴチャゴチャとした入力データを、何か「機械の勘で」フラグとか、ベクトルとか、座標とか、
プログラムで扱いやすく（比較・演算可能）変換します。
「プログラムで扱いやすく変換」？
今までプログラムで扱いづらかったものが扱いやすく ……？！
AI系技術…
13
画像音声
動画
何か大量のデータ
数値配列

 …そうです。「AI系技術を利用した仕事が増えます。」
 できそうなことが増えたから。しかし、AI系技術はプログラムに「直感やそれに基づく判
断」を与えるだけであり、論理的思考の部分（Intelligence?）は依然として人間がプロ
グラムする必要がある（＝人間の仕事）。（多分これからも暫くそう）
 厳密な要件定義とかに基づいて瑕疵担保責任とかAI系利用では実質無理　　
（最後は妥協だから）。厳密に品質担保できないので外注は基本、業務委託か？
 …「AI系技術自体の開発にデータを用意する仕事（？）も増えます。」
 人間の手本データをどうやって死ぬほど多量に用意するか？
 人間が死ぬほど頑張るのか？orz
 「…仕事増えてる？…減らしたい業務より多くない？」（本末転倒注意）
 作ってるうちに「って言うか（高コストの）AIの部分、実は要らない？この残りの
部分、単に人の作業補助に使えば便利。」が最適解のこともある筈。
AI系技術でシステム開発はどうなる
14

勘違いされやすい問題点〜AI系技術開発を事業に利用するために〜
①: 所詮「人間劣化版」である
 人間が手本なので単体精度で人間を超えることは無い。
打つ手も状態も有限離散で勝利条件が明確なゲームプレイだけ見て、
「人間を超える」と勘違いしてる人は、ちゃんと現実問題で考えて欲しい…
 人間に近づけようとすればするほど非線形オーダーで死ぬほど大量の
「人間が手本を示した」データが必要。しかも前進する保証は無い。
※場合によっては、自己生成の勝手な基準を伸ばすことで、「劣化人間感覚」ではな
く人間と感覚が違う変なもの「変人感覚」ができたりはすると思いますが、興味深いだ
けで社会的需要があるかどうか疑問（直感的に違う、成果なし、権威なし）。人間の補
助としての選択肢生成程度か？
15

②: 「底なし沼のギャンブル」である
 人間の入出力データを大量に集めて集計したもので似た入出力の計
算モデルを開発者がよくわからないまま自動チューニングして作ろうと
する博打です。
 この開発における「博打」性がビジネス向けシステム開発事業との親
和性を下げます。
※故に、「AI系技術を使おう」という発想は、それ自体が実は知性的ではあ
りません…。生のAI系技術のモデルは「知性的ではありません。」寧ろ「直感
的（よくわからないけど正解が出る）です。」　意図的に出力を集計しないと
人間には理解できないものもあります。
16

②: 「底なし沼のギャンブル」の構図
 パチンコ的な構図に例えると分かり良いか
※私は、ギャンブルはしません。AI系という博打に首を突っ込むだけでお腹いっぱい…
[a] 研究者（台を選ぶ・作戦を立てる）
[b] AI系演算モデル（機種）
[c] 演算リソース（打つ台数）
[d] 人間の入出力データ（パチンコ玉）
 玉（データ）を台（演算モデル）に沢山打ち込んで、台（演算モデル）か
ら玉（別のデータ）を出せるようにするという構図です。
 大当たりするまで際限なく打ち続けるわけです。（一生出ないかも知れない…）
17

必要なものは何？「〜 AI系技術開発＝ギャンブル」で一山当てるために〜
前述の要素を整理していきます…
[a] 研究者（台を選ぶ・作戦を立てる）
[b] AI系演算モデル（機種）
 パラメータが白紙の状態なら論文などでその結果も含めて各種公開されているので
、只の再現実験から行うことになる。別に特別な人は最初は必要ない。モデル調整
ノウハウは処理・目的に対して固有なものも多いのでやりながら得ていくことになる
。
 まずは論文（≒仕様書）の再現実験ができる程度の腕でいい。何割かは論文著者
本人や他の人によってプログラムが既に公開されているので、精査して使ってみれ
ば良いと思われる。
 というか、次項目の他にないレベルの計算リソースや、データがあれば、まともに研
究したい人は一般的な給与でも自ずから集まってくると思われる。多分、この２要
素は相当余裕が無い限り、後まわしでいい。
18

[c] 演算リソース（打つ台数）
「玉を沢山打つために沢山要る。」
 技術の進歩もあるし、予算に応じて線形に天井無く増やせます。
※多少のスケーラビリティの問題は純粋な技術の問題なので、　　
　　技術者ならなんとかできる筈 :-)
 人件費ではないので制約は少ないかと。お金でスケール可能。
「純粋にお金の問題」
… 計算力＝お金 …
19

[d] 『人間の』入出力データ（パチンコ玉）
これが大量に無ければ何も始まらない。
 人間にしか生成できない。「人間ができる」＝「解の存在を暗に保証」
 共通の判断基準で作られた精度の高いものでないと後で困る。
 精度を確保するためのデータの精錬もコスト要因。
 判断基準が、人類共通ではなく、日本人限定とか、業種限定とか絞ら
れるほど出力を作れる人口が減るのでコストが上がり作成期間が増え
る…
（以下ひとりごと）
…データも無く、ついでにデータが集まるサービスも持っていないなら、入力データを大量に用意してから、クラウドソーシ
ング等で出力データ作りを依頼することになる。ある程度高度なモデルを白紙状態からビジネス価値があるレベルまでト
レーニングするには、最低でも数千万円。精度のために依頼作業手順見なおして作り直しは結構発生するし、人間の仕
事なので最低賃金等のコンプライアンスも考えると、コストパフォーマンスは物価依存（将来安くなることは無いと見ておく
）だったりするので、「複数年、億単位」の計画が必要かも。「玉」だけで。もう「玉」だけ集めて打たずに直接売ったほうが
いいのかも…
20

＜結局の重要度＞
データ >>> 計算機（＝お金） >> AI系理論・研究者雇用
 人間の一定基準での判断結果を含む大量データは貴重で、　　　　　　
お金ですぐ買える類のものではない。（コールセンターのログ等）
※ コストを考えると、人気の無料サービスを立ち上げてそのついでに集めるほうが速い
のかも…。例えば、Google検索等では非bot認証で公道自動運転のためデータを集め
ている。→ 「広告に次ぐ無料サービスの収入源」になるのかも。
 【最重要？】『そのAI系技術、本当に賭けたぶん回収できる？』
※特に、データのあてが無い思いつき企画はデータ収集のコストで頓挫必至
※「機械がやるサービスレベル劣化処理」にお金を払う人がいるのだろうか…
 「MATR○X」でも作って人間の入出力を集めるか？
※クラウドソーシングで単純作業買い叩くのは最早それっぽいですが…
…そういえばSNSって、人間データ抽出の「M○TRIX」かも？
21
（大切←）
（→そうでもない）
富める者が貧しい者にデータ出力作業を強いて更に富む世界となるのか否か？！
『玉があって台があれば人は自ずから集まる筈』
…でも、そんな儲かるAI系モデルなんてあるのか！？今のところ自慢にしか使え…

…通常の一般企業にそんな余裕は無い！！
独自のAI系技術を開発するには…　　　　　
 まず、十分なデータ（玉）が用意できない。
日本の大企業クラスでも、ゼロからは無理では？
 演算して試行錯誤する費用も時間も馬鹿にならない。
我々、一般人が実用的「に」
AI系技術利用システムを構築するには
どうすれば良いのか…？orz
…というわけで、一般レベルの開発には実質的な制限がある。
22

一般人がAI系技術で開発する実質制限
① 公開されているモデル＆トレーニング済みパラメータを流用
 専門家が突き詰めてトレーニングした公開パラメータは超えられない
• 巨大なモデルを自分のデータだけでトレーニングしても、　　　　　　　　　　
量よりもバリエーションの不足で上手く汎用性の高いものはできない？
• 公開されているデータだけから独自の価値をもつものはできない？
 追加トレーニングには劣化がつきものなので、微調整する程度じゃな
いと失われる汎用性のほうが大きい
「あるケースの特化」＝「汎用性の劣化」　なので注意
（参考）「PASHALY」ではトレーニング済みAI系モデルは３個流用（『Faster R-CNN』、
『Convolutional Pose Machines』、『Inception v3』）。追加トレーニングはしていない。あとはAI系じ
ゃないプログラムやパラメータと　パーセプトロン程度の接合部分でできている。
23

一般人がAI系技術で開発する実質制限
② 「少ないデータ」→「小さいモデル」→「低次元な機能」で妥協
 独自に作れるのは、現実的には、
➢ 人間の何らかの作業の補助、一次振り分け程度　または…
➢ 公開モデルを組み合わせる場合に繋ぎ部分だけ作る程度
 とはいえ、それでも試行錯誤は必要。コツとしては…
データのバリエーション（単純量ではない；バランスも重要）に対して、
• 処理モデルが小さすぎるといつまでもできるようにならない
• 処理モデルが大きすぎると未知の入力に対して応用が効かない
適度な「詰め込み」が応用力に大事らしい…。
※「過学習」と勘違いされる状態は、大概がモデルサイズに対するデータのバリエーション不足と思う。
（参考）「PASHALY」でクラウドソーシングでデータ作成した費用は100万円程度。（偶然できただけかも…）
※効果的な依頼データ選定プログラムのためのトレーニングデータを自分で20000件くらい作った…
24

それでもAI系技術を使う価値
 …という感じで、既存のものをビルディングブロックしながら、最小限
のデータで調整して作ったりして最小限のコストで実現することが一般
人の現実解になるわけです。
 そして、そうやってできた「人間劣化版＆既存焼き直し感」の処理に
付加価値を持たせてシステム化するには人間にできないことをする必
要があります。
 それは、「大量データとの大量照合」。すなわちデータベース化です。
 システム化による付加価値のポイントはデータベースにあります。
やっと主旨にたどり着いた！
25

後半：システム化を踏まえたザックリ
26
〜AI系専門じゃないけどAI系技術をちゃんと利用する〜

AI系技術を繋ぐ内部データ
どうやって組み立てるか？ヒントは「オートエンコーダーの考え方」
 オートエンコーダーの「乱暴な」説明
27
j
:
:
2
1
k
:
:
2
1
j
:
:
2
1
i
:
:
2
1
j
:
:
2
1
i
:
:
2
1
k
:
:
2
1
l
:
:
2
1
k
:
:
2
1
入力出力
局所的に逆変換可能を保持するようにパラメータ調整する。
そうすることで、次元圧縮時の情報量の欠落を軽減する。
（あくまで、トレーニングデータの範囲ではあるが…）
→ 層が深くても先まで調整が伝わる？
『元に戻せる凝縮された
情報を次の層に』
『元に戻せる凝縮された
情報を次の層に』
（※余談）word2vecも中間層を利用する
点で、同じ考え方と言える。

少し大きな視野でも当てはまる。『〇〇できる凝縮情報を次の入力に』
 同じ考え方で処理モデルを組み合わせる（直列接続の場合）
28
i
:
:
2
1
入力出力
（特徴量）
　各モデル最終層の分類フラグよりも、一つ手前の
層の方が情報量は多い模様。
　最終出力も手前のベクトルを主に扱えば色々試す
際の可能性の欠落は少なくなるはず。
『分類のための
凝縮された情報を
次の入力に』
j
:
:
2
1
j
:
:
2
1
k
:
:
2
1
k
:
:
2
1
l
:
:
2
1
何
か
分
類
フ
ラ
グ
何
か
分
類
フ
ラ
グ
何
か
分
類
フ
ラ
グ
『分類のための
凝縮された情報を
次の入力に』
※トレーニング済みモデルの途中の層から自分の
処理モデルに引きこんで下層のトレーニングを端
折ったり、畳み込み演算に拡げて空間情報にして
みたり、出力の比較は最後層の手前のベクトルで
行ったり…。

コンポーネント間でのやり取りは、とりあえず、
（情報が凝縮された）多次元ベクトル　　　　　
になると思っておけば齟齬は少ない。
 処理モデルの最終出力がフラグであっても、その手前の層の値の並
びを特徴量とすればそれはベクトル。出力に必要な情報が凝縮されて
いる。…場合が多いと思われる。…そうでないこともある。
（※余談１）出力側のFC層が少ないほど（ギリギリまでCNN）低次高次の特徴の両
方が詰まっている印象か。逆にFC層が多いと高次のもの寄り？トレーニングの課程
の差かも知れないから一概には言えないかも。
（※余談２） TensorFlowと言うネーミングはAI系とシステムと両方分かっている人
がつけたと思う。良い名前。
29

データベース化すると索引が必要
　word2vec等、自然言語の単語の特徴量の例では、多くても100次元、数
万語オーダーなので全走査でもまだ性能は気にならないかも知れないが、高
機能な画像系モデルはスケールが違う…
＜簡単な検証＞
任意の 2048次元単精度浮動小数点型ベクトルに対して同型の大量の
データの中から類似度が近い順トップ100個の近傍ランキングを計算する。
• 「NumPyによる最適化行列演算」 vs 「HNSW(NMSLIB)索引利用」
• データは「画像で旅する」の一部分のデータ、2,149,005件
• ここでの類似度：単位ベクトルの内積が大きい(最大1.0)ほど近い
• 検索に使えるのは１スレッド限定 (環境変数 OMP_NUM_THREADS=1)
• HNSW(NMSLIB)は、私が使っている改造版（後述）
※テストコードを本家で動かすには修正必要。
30

＜テストコード＆索引の使い方例：準備＞
31
import numpy as np
import random
#data : 検索対象はNumPyでdtype=float32で、shapeは(データ数, 次元数)で用意とする
#単位ベクトルに正規化
norm_data = data / np.sqrt((data[i, :] ** 2).sum(-1))
#索引作成
import nmslib_vector as nmslib
index = nmslib.init('cosinesimil', [], 'hnsw', nmslib.DataType.VECTOR, nmslib.DistType.FLOAT)
for idx in xrange(len(data)):
nmslib.addDataPoint(index, idx, data[idx].tolist())
#個人的によく使う設定。作成時間と精度はトレードオフ。
nmslib.createIndex(index, ['M=100', 'efConstruction=1000', 'indexThreadQty=4'])
nmslib.setQueryTimeParams(index, ['efSearch=100'])
#2048次元 x 1000個用意
targets = [np.array([random.uniform(-1,1) for x in xrange(2048)],dtype=np.float32) for y in xrange(1000)]
・前提
・準備
行列演算ケース
索引利用ケース
・テスト検索キー準備

＜テストコード＆索引の使い方例：テスト＞
＜結果（1検索当たり平均）＞
※数万回検索するなら10時間以上かかるので、バッチ処理でも
　数時間かけても索引を一回作ったほうが速いというレベルで違う
32
for target in targets:
norm_vec = target / np.sqrt((target ** 2).sum(-1))
dists = np.dot(norm_data, norm_vec)
best = np.argsort(dists)[::-1][:100]
result = [(x, 1.0 - float(dists[x])) for x in best]
for target in targets:
result = nmslib.knnQueryScore(index, 100, target.tolist())
・検索テスト
行列演算ケース
索引利用ケース
・行列演算ケース：
・索引利用ケース：
1705.75 msec
4.75 msec
※参考cpuinfo
Intel(R) Xeon(R) CPU E5-2637 v4
@ 3.50GHz

多次元索引あれこれ
 NMSLIB (Non-Metric Space Library)
https://github.com/searchivarius/nmslib
に色々実装がある(C++のライブラリで、Pythonのインターフェースも付属)
SWGraph, HNSW など様々な手法を実装
 元SpotifyのErik Bernhardssonのブログ
https://erikbern.com/2016/06/02/approximate-nearest-news.html
に色々な手法の大まかな比較がある。（多分ライセンス的に使いやすいもの）
 彼自身もSpotify時代に Annoy (Approximate Nearest Neighbors Oh
Yeah) という多次元近傍探索プログラムを開発し、公開している。
https://github.com/spotify/annoy
 彼がメンテナンスしているベンチマーク＆結果（上記比較の最新版？）
https://github.com/erikbern/ann-benchmarks
勿論パラメータ設定で大きく結果は変わる。精度・性能以外の使い勝手も考慮すべき。
33

オススメ多次元索引 HNSW
 私はHNSW。※勿論（？）改造済み。
※1000次元超えで幾つか使ってみた中では索引の作成も速い方
参考論文：
Malkov, Y.A., Yashunin, D.A.. (2016). Efficient and robust approximate nearest neighbor search
using Hierarchical Navigable Small World graphs. CoRR, abs/1603.09320. [BibTex]
( http://arxiv.org/abs/1603.09320 )
 俺のNMSLIB+HNSW （木下改造版）
https://github.com/kinoyasu/nmslib
 1.6をPythonインターフェースを1.5仕様に戻して改造したもの。
 HNSWに特化して最適化し、未定義領域など勝手に使っています…
 ファイルフォーマットも本家と違うかも知れないので注意
 各コミットのコメントで軽い説明があるので、分かる人はビルドして使うなり移植するなり
お好きに…
※1.7系はまだ使ってないのでよく分かりません。悪しからず。
34

HNSWのポイント
Annoyも含めてNMSLIB内の他のものも幾つか試した結果…　※NMSLIB v1.6の話
 検索の精度と速度のバランスが現状最高レベル
それでも基点となる近いデータが索引に無い場合は少し不正確になる。
 索引作成の速さ (面倒くさくない単純なアルゴリズム；次ページ)
 データの追加はある程度できそうだが、削除・移動は無理
とはいえ、その他の手法に比べたらマシ
 データ内容変更は非最適化状態のみ。セーブ＆ロードは最適化状態のみ対応。本家は最適
化は不可逆。
※（済）非最適化を実装して、データを削除・追加してまた最適化（再作成専用のメソッドをつかうこと！）
しなおせるよう改造 (木下版)
 オンメモリ最適化処理時にメモリを倍喰う。
※（済）メモリ上は非最適化状態のまま最適化状態でセーブできるように機能追加（木下版）
 メモリリークっぽい処理がある…NMSLIBとHNSWが遠慮し合っている?
※（済）バッサリ最適化（木下版）
 オンメモリのみ
数千次元&数千万データだと数百GB…。ゆくゆくはディスクベース化必要。
 SSE系命令を利用しているので利用環境でビルドしたほうが良いかも。
35

HNSWの動作
 構造、検索時の動作、索引作成時の動作
36
Lv0：
全データ
Lv1：
1/M 個
Lv2：
1/M2
個
Lv毎に、同Lv他データのTOP(M)ラン
キングを「片方向」リンクで保持。
※空間位置関係によっては片
方向のみになることもある。
検索は、最近傍に着くたびに下Lvへ。
Lv0ならそこが全体最近傍。
その他の近傍はそこから辿って収集。
追加（作成時も一緒）は、
まず最大レベルを確率で決定。
各レベルのランキングリンクを
作成し、同時に参照先のランキ
ングにも参戦し更新する。

AI系技術と多次元索引でできた例①
 「PASHALY」
※個人的には…
　実現が難しい割に、誰にも
　不要なサービスと思っている…
「似てる画像」＝「似てる商品」？
…収録してないものは出ないので、
　あるものを検索する人は凄いと言い、
　無いものを検索する人には意味不明…
普通、珍しい物を検索すると思うのだが…
37
SelectiveSearch
（候補領域分割） Faster R-CNN
（人体検出）
Convolutional Pose Machines
（人体姿勢推定）
Inception v3
（画像特徴量）
特徴量判別NN
商品カテゴリトラッキング
画面上の商品画像の例
NMSLIB (HNSW)
（類似特徴検索）
Inception v3
（画像特徴量）
類似画像検索
※独自トレーニング部分

AI系技術と多次元索引でできた例②
 「画像で旅する」 ( trip.deqwas.net )
言語情報に依らずに画像を自由に探索する〜〜
- あるものから探す :-)
- HNSW索引作成時の上位Lv選択を調整
確率ではなく、特徴量に基づいて代表データを選定
→ 上位Lvの近傍データを利用した効率的移動可能
38
Lv0：
全データ
Lv1：
1/M 個
Lv2：
1/M2
個

これからAI系技術を組み込んで何ができるか
 実現性とコストを決める大きなポイントは
「直感的なAI系技術と人間とのインターフェースをどうするか」
 人間の論理的なコンテキストに合わせようとするところで無理が出る。
→ コストが増大 or 不可能
 でも、共感できる直感はどこまで行っても部分的。一致は多分無理。
AI系技術：入力データとフラグの組を大量に提示されて調整
人間：五感と肉体を持ち現実世界で何年も生活し認識を調整
 実現性には…
妥協が必須
39

これからAI系技術を組み込んで何ができるか
ここは特に私見が強いですが…
 「直感を取り扱う」という意識が重要？
論理的でない、「なんとなく…」/「もっとこう…」のやりとりができると価値か？
 人間の新しい直感的入出力の拡張に使う方が簡単だし、ユーザーも技術
の限界を理解して折り合いを上手くつけて使えるのでは？
そのための入出力は「羅列と選択のインタラクション」ブラウジングが基本？
「機械は羅列で提示し、人間は提示空間内の移動と選択」
※画像は羅列しやすいが他のデータはどうやって人間に大量提示するのが良いか？？
 人間側が新しい感覚（悟り？）を開いて使う直感的な情報探索補助インタ
ーフェースを模索したほうが実現性があるかも。
音声会話等人間同士のインターフェースの情報の欠落を補うもの？
40

システム化するポイントまとめ
 中間ベクトル（＝直感？）を抽出して取り扱う・組み合わせる意識。
「分類器を作って中間出力を抜き出す」（多分基本）
「中間出力同士の類似性やアナロジー(？)で判断」
 勝手に知性的にはならない。諦めて地道にプログラミング。
 人間の直感の拡張が最短用途。
• AIのIが Interigence(知性)だと思って人間と接するから齟齬がある。
• AIのIはこれからも暫く Inspiration(直感)レベル。
直感でAI系技術と人間がつながるインターフェースが重要になるかも
羅列？何かVRで？
41

おまけ：多次元索引以外のキモは？
 GPUリソース制御のチューニング
• GPUへのタスク割り振り、GPUメモリの割り振り… 計画的手作業
処理が軽いとバスの転送ネックになるので、CPU側でやったほうが
速いことも多い
• GPUがシステムの新しいボトルネックとなる可能性
※PASHALYでは偶々比較的均等に２GPUに分散できているが… (1: セグメンテ
ーション(只の画像処理) & FasterRCNN & CPM、2: Inception-v3)
 (将来的には)連携できる商用AI系サービス
現状、知る限りの商用サービスは全てフラグベースの入出力で、ユーザー自前のモ
デルとの連携では情報量が大きく欠落すると思われ、拡張性が低い。トレーニングし
た後の内部情報が利用できるよう改善が望まれる。
42

多次元データを上手く扱って、
AI系技術で新しいモノを作ってみましょう！
43
おわり

MANABIYA 2018 DB kinoshita DB for AItech

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie MANABIYA 2018 DB kinoshita DB for AItech

Ähnlich wie MANABIYA 2018 DB kinoshita DB for AItech (20)

MANABIYA 2018 DB kinoshita DB for AItech