ＤＢ改造屋雑記

2019年2月7日木曜日

復帰しました。

今月から中の人に復帰しました。よろしくお願いします。

弊害として、このブログの更新が減ると思われます。こちらもよろしくお願いします。

前職は丸４年在籍しましたが、技術的にも社会的にもビジネス的にもその会社でなければできないことはもう無くなったと感じて次の道を考え始めていたところ、復帰のお誘いがありましたので受けました。

ここ数年、データベース以外の分野でのトライアルで培った技術は何らかの形でMySQL/InnoDBの将来のために役立っていくと思います。が、ずっと未来の話で皆さん忘れた頃かもしれないです…

2018年11月4日日曜日

Pythonを突き詰めたらPerlを使ってた話

あ…ありのまま今　起こった事を話すぜ！

「自作Pythonモジュールを使うスクリプトの性能を突き詰めていたと
思ったら　いつのまにかPerlを使っていた」

な…　何を言っているのか　わからねーと思うが
恐ろしいものの片鱗を　味わったぜ…


#!/usr/bin/perl -e$_=$ARGV[0];$ENV{'LD_PRELOAD'}=s|[^/]+$|hogehoge.so|r;exec('python',@ARGV)
import sys
import os
print sys.argv
print os.environ['LD_PRELOAD']

LD_PRELOADで、同じ場所にあるhogehoge.soをpython起動時に直接ぽく読み込みたかった（Cythonからpxdの設定だけで直で呼びたい関数があった）わけです。

shebangは、引数1個までで128バイト以下じゃないといけないのか。初めて知りました^^;。(Linuxだけか？) awkだと引数を再連結して全部拾い直すと128バイトに収まらない…無念。(引数なしなら可能)


#!/usr/bin/awk BEGIN{a=ARGV[1];sub(/[^/]+$/,"hogehoge.so",a);system("LD_PRELOAD="a"\tpython\t"ARGV[1])}

ワンライナー系の課題はPerlが強くてコンパクトなのですね…
私の技量の問題なのかな…

2018年9月26日水曜日

Webサイトの導線について〜大量のコンテンツを興味ある人に効率よく届けるために〜

今回のエントリは、今までと同じことを別の視点から書くことになってるだけかもしれないけど、今まで良く理解できなかった人にも分かりやすくなっていると幸いです。

社内社外問わず、どうも問題意識がサービスの提供側ほど漠然として希薄な印象なので、確認の為にメモを残しておきます。

※以下はあくまで私見であり、所属組織や他のメンバーとは関係ありませんが、一般論として十分な説明となっているかとは思います。 AI系技術は、ちゃんと適用分野の深い理解がないと最適に利用することは難しそうな例でもあります。

＜Webサイトの導線基本構造＞

現在の一般的なWeb上のコンテンツ閲覧と、実世界、例えば実店舗で商品を見て回ることで、Web側がが劣ることは結構ある。現物が見られないことは永遠に超えられなさそうな壁ではあるけども、

「広範囲の俯瞰を伴う自由な導線」これが、Webサイト全般に欠けているものかと思う。訪問者は正に「木を見て森を見ず」の状態を常に強いられるわけです。（私はこれが嫌で、あてのないWebブラウジングはしないのです。）

新着順、人気順など、決まった順番を決めつつ、カテゴリ、価格帯など、検索条件で絞って出力を見る。（まぁ、SQLのSELECT文でORDER BYとWHEREの調整をすることと一緒だが。）

※キーワード検索なども多少自由になった検索条件程度。文字情報が少ないコンテンツの検索の助けにはあまりならない。さらに個々のコンテンツ同士は、各種「売り上げランキング」「個人クリック履歴」「この商品を買った人はこんな商品も買っています」等のレコメンド等の複数のリストで参照し合う。（私は他人の買っていないものを欲しがるので、どれもクリックした記憶は殆ど無い…）

加えて、各種サーチエンジンから直接個々のコンテンツにショートカットしたりもする。

これが、一般的なWebサイトの導線基本構造かと思います。

＜Webサイトの収納力が産む弊害＞

さて、ここで問題になるのは、物理空間配置に縛られないWebサイト特有の膨大な収容能力が産む弊害です。

コンテンツが数万件程度なら、ソートとカテゴリ等既存の検索条件（よくある左ペイン）だけで、例えば全検索結果の先頭の数１００件で殆どのコンテンツへの導線を網羅できているかも知れませんが、コンテンツ数が、その１０倍、１００倍、それ以上となったらどうでしょう？

極端な話、コンテンツが数千万件ある場合には、「よくある左ペイン」だけでは殆どのコンテンツが誰も辿りつけない「死にコンテンツ」となってしまいます。

というわけで、コンテンツが多ければ多いほど、個々のコンテンツページにある、ランキングやレコメンド等のリスト表示に期待される導線拡張の役割が大きくなるわけですが…

単純に考えればお分かりの通り、まず、明らかにランキングは「導線拡張」には寄与しません。余程の外的要因が無い限り、左ペインから辿り着ける（ことのあった）コンテンツのみが残っています。このランキング表示に残っていることが原因でクリックされたりしてランキングが維持されたりもします。過去の人気コンテンツへの導線維持の機能しか果たしません。

では、通常のレコメンドリストがその役割を果たせるかというと…
難しいと言わざるを得ません。

レコメンドリスト生成には様々な手法があり、個人のクリック履歴からランダムに出力するだけの単純なものから、各コンテンツや各閲覧端末の関係を有向グラフ状に集計してそれを元に表示するような難しい物までコンテキストの深さは様々です。

しかし、誰かが訪問していないものは表示できない（※）ことに変わりはなく、導線視点で言うと、
ある時期に存在して利用された導線の維持の機能がやはり基本になります。

（※「表示できない」というよりは、当てずっぽうになってしまうのでレコメンドとしての「精度が他の表示より)格段に落ちる」という方が正確かも。）
ここまで説明した導線だけでは、

「登録時に新着リストに載った時期にあまりクリックされないと死にコンテンツ確定」

を避けることができません。

※なので、サイトによっては幾つも同じコンテンツを定期的に新規登録したりとか、意味不明なことが行われたり。。。導線拡張だけに特化して考えると、単純にランダム表示したり、履歴の無いコンテンツまで雑な類推で出力しても、

「なぜ今見てるコンテンツに対してこれらのコンテンツリストが出力されているのか？」

という繋がりが論理的にも直感的にも希薄であれば、訪問者が中身を見る確率・クリックする確率はそれだけ低くなってしまうと考えられます。（例：「おすすめ」というタイトルでランダム表示）

＜AI系技術による導線拡張＞

ここで逆に考えます。

「なぜ今見てるコンテンツに対してこれらのコンテンツリストが出力されているのか？」がある程度、訪問者とコンセンサスが取れれば、ランダムより相当見てもらえるのではないでしょうか。

例えば、

「人気/売り上げランキング」

「この商品を買った人はこんな商品も買っています」等は、その並び方自体に情報があり、あまり興味がなくてもそのタイトルの下のリストの先頭が見える頃には、頭の中はその情報を受け取る準備ができていて、先頭の何個かを見て「ふ〜ん」という程度には脳まで届くと思います。興味があればスクロールしても貰えるでしょう。

しかし「おすすめ」というランダムの場合には、「おすすめ」というタイトルで、（どういう観点だろう？）
と最初は待ち構えますが、ランダムだ(もしくは、意味がわからない並び)と判ったら、基本スキップされるのではないかと予想されます。ニーズに偶然フィットしてクリックされることはあるかも知れませんが、導線の利用率は低いと思います。

つまり、超多数のコンテンツ間の十分な導線確保のためには、

互いに並びが似ていないリストで
見ただけで並び方がタイトルに合っているか確認可能なものを
できるだけ多種類

表示することが有効と考えられます。

「見ただけで並び方がタイトルに合っているか確認可能」としたのは、複雑すぎるのもランダム（無意味）と取られるからです。各リストのタイトルも重要と思われます。

という文脈でいうと、
レコメンドと称して履歴から何らかの範囲のランキングを表示するいう枠組みだけでは、複雑な方法でも異なるリストをそう何個も生成できない（＆タイトルを決められない）ので、別の観点のリスト生成法があると（全コンテンツに行き渡るような）導線の拡張にとても有効です。

そこで、AI系技術による何らかの特徴量抽出＆類似性ランキングで整理することにより、お手軽に導線拡張ができます。例えば、画像を何らかのベクトルに変換するものを使ってトップ画像の類似性ランキングを各コンテンツ基準で生成して「似た画像の商品」みたいなタイトルを付けて表示するだけで、並びにある程度の納得性があれば、意外と見てもらえると思います。

違う学習済みモデルでも同じようにやってみて、その数種の画像類似リストの観点にそれぞれふさわしいタイトルをつけて差別化することができれば、それだけで導線がかなり増やせるわけです。

画像に内容の特徴がそれほど現れないテキストメインのコンテンツでも、リストに並べたタイトル等に納得性があれば、「似た内容の記事」みたいなタイトルでリスト表示しても良いと思いますが、画像ほどの直感的説得力は無いかも知れません。

下手に混合するよりも、単純化して納得できるタイトルのリストに分離したほうが訪問者に伝わりやすいでしょう。

そして、私がこの記事を書いている現在在席しているサイジニアでは、上記のレコメンドリストの提供サービスを事業の一つとしています。加えて、画像の特徴量ベースにしたリスト毎日生成もサービスラインナップに加えているので、自分では特徴量類似性ベースのリストをですぐには試せないサイトさんは試験導入してみても良いかも知れません。

＜その先のコンテンツブラウズ導線の模索＞

前述の余談にあるような、

直感的納得度の高い特徴量空間を持つAI系の学習済みモデルが一般的に利用されることによる、Webサイト周りの関連事業の技術再編可能性については私は専門じゃないので語れませんが、コンテンツブラウズへのAI系技術利用を既存の「タイトル付きリスト羅列」からもう少し深めるトライアルは行っています。

つまり、冒頭で述べた、
「広範囲の俯瞰を伴う自由な導線」
の一部的でも、この特徴量空間を利用して上手く提供できないかというものです。

画像で旅する https://trip.deqwas.net
というサイトを立ち上げています。

とりあえずは、リストの後半ほど意図的により遠くの特徴的なコンテンツをピックアップすることで、少しでも俯瞰範囲を広めようとしています。

この興味深い使い心地を言語化するのが今度は難しくなってしまうのですが、真似してやってみるでもいいので、新しいインターフェースの可能性を拡散して皆で議論していきたいです。

Webサイトに限らず、個人の画像ライブラリをデータベース化して閲覧するツールなんか作ってみて公開するほうが分かりやすいでしょうか？

いつか時間ができたら…
DBの一般機能として超多次元ベクトルが扱えるようになったら、サンプルとして作ってみるとか？

ではまた。

2018年9月5日水曜日

groonga-httpdで公開用全文検索WebAPI突貫工事

今回は急に細かい小さい話です…

groongaには、groonga-httpd という nginx と融合したプログラムがあり、デフォルトではhttpでフルアクセスで管理からできるようになっていますが、検索部分だけを外出しするのは簡単です。

/etc/groonga/httpd/groonga-httpd.conf
を


@@ -51,18 +51,37 @@
   # You must specify base path on memory file system for performance.
   # groonga_cache_base_path /dev/shm/groonga-httpd-cache;

+  server_tokens off;
+
+  #検索部分だけ公開するエントリ
+  server {
+    listen 50054;
+    server_name _;
+
+    # Only select command
+    location / {
+      if ($arg_q = "") {
+        return 404;
+      }
+
+      add_header Access-Control-Allow-Origin *;
+      proxy_pass http://127.0.0.1:10041/d/select?table=Item&match_columns=Terms.texts&limit=100&output_columns=_key,brand,iname,img&sort_keys=-_score&query=$arg_q;
+    }
+  }
+
+  #ここから元のエントリ（非公開ポート）
   server {
     listen 10041;
-    server_name localhost;
+    server_name localhost 127.0.0.1;

     location /d/ {
       groonga on;
....

という風にして「?q=[検索クエリ]」のURIオプションを受け入れるようにできます。

嵌ったのは、proxy_passに変数が入ってると、「localhost」の名前解決が上手く行かないので直接IPアドレスを使わなければいけない点だけでした。(nginxの何か固有の仕様？)

というわけで、とりあえず

「画像で旅する」

に全文検索機能を付けてみたメモでした。
え、mroonga？出力時に必要な項目も一緒に入れてしまったらMySQLまで使う必要が無…

2018年7月23日月曜日

画像で旅する『あの流域』

いずれ、データベースに取り込まれるような一般的な機能になりそうな新技術を探って色々実践している日々です。

ニューラルネットワークや、その中間層を特徴量ベクトルとして抜き出して扱う場合に現在のMySQLでは上手く扱えないのですが、そういうものが人間のデータ閲覧インターフェースとして一般化する場合には、データベースもそういったものを効率的に扱えないといけません。

その、人間とデータの新しい接点を模索していくサービスとして、

画像で旅する https://trip.deqwas.net

というサイトを昨年12月から立ち上げています。

しかし、掲載しているものは、他の目的(PASHALY)でネットから自動収集したものや、偶々入手できるデータフィードをかき集めて表示してきましたが、どうも内容が全体として偏ったり、怪しくなったりしてしまって…

怪しくなく、実用的にして、
「実験としての意義も高めていきたい！」
ことと、なにより、
「本人が買い物に使う気にならない。」（ぉ）
ということが問題でしたが、苦節半年以上、遂に！！！

許可とデータを頂いて、あのサイトの商品を掲載できるようになりました！

そして、先程データを入れ替えました。

量が多いのでまだ４分の１程度ですが、絶賛処理中で来週には出す予定のものは全部出せると思います。（その後、元のデータで需要があったものも順次復活させる予定です）

お楽しみに！
というか楽しみだ。

2018年3月19日月曜日

MANABIYA でお話する資料

今週末、MANABIYA というイベントでお話させてもらう予定です。話したいことを筋道立てて並べたら結構濃くなってしまったので、とりあえず事前に公開しておきます。タイトルは『AI系技術の一般化でデータベースに求められること』です。

『AI』という言葉はAI系以外の人にとってとても曖昧で、具体的モノづくりの現場で出てくると困ってしまうわけですが、ちゃんと整理して取り扱い、適切な道具と組み合わせたら面白くなるのではないか。という話（のつもり）です。
内容が多いので、とりあえず話すことは全部、後から読んでも解るように読み物として作っていたら、逆にこれを読めば当日来なくても大丈夫になってしまったかも知れないです。 :-)
話したいことや商談などありましたら、登壇当日は会場のどこかに居ると思いますので。

2017年12月14日木曜日

人工知能系技術の利用法

「知能」という単語に振り回されて応用を考えると実現性との乖離が大きくなり、完成できないか若しくは、コストが目的に対してかかり過ぎるという事態を往々にして引き起こすと思います。そこで、「知能」ではなく「直感」と考えて適用を考えたほうが良いと昨年からここで書いています。

人工知能系技術の処理内容は基本的に人間の劣化版になります。機械ですので一定の品質で処理量を増やすことは可能でそこが人間と比較した長所となります。

「直感」という単純なものなので、人間の入出力を補う形で利用するのが最も素直な利用法で、大量のデータの近傍探索（というか徘徊）に使うことが良いのではないかと考えていて、最近、会社で実験的なサイトを立ち上げてみました。

画像で旅する（β版） http://trip.deqwas.net

です。12月現在、240万以上のEC商品画像を収録しています。

とりあえずトップページはある程度ランダムに出力していますが、商品画像をクリックすると、特徴の近い順に他の商品が表示されます。近い方(上の方)は密に、遠い方(下の方)は疎にピックアップして並ぶように作ってあります。別の画像をクリックするとその画像起点で表示されます。そうして延々と辿ることができます。

「もっとこういうの」とか「この感じが良いとか」非言語でインタラクティブな画像検索（探索）を主眼に調整しています。

どうでしょうか？

実際使ってみると、一切言語情報を入力すること無く、結構幅広い商品探索ができているでしょう？

こんな感じのシステムを気軽に組むための機能がこれからのデータベースに求められているのかも知れません。

余談ですが、先日紹介したアプリ、PASHALYから画像を提示してそれの特徴量を起点にこの「画像で旅する」が利用できるようにしました。検索結果に「画像で旅する」タブが出てくるので、そこからスタートすることもできます。

これからも自然な形で現状の人工知能技術を利用することについて考えていきましょう。

さらに余談。2018年3月23、24日の「MANABIYA -teratail Developer Days-」( https://manabiya.tech ) にDBセッションとして登壇することになった様なので詳しい話はその中でできるかと思います。

登録: 投稿 (Atom)