u++の備忘録

Windowsにpython-mecab導入(2017年11月)

自分用メモ

mac版はこちら
Macにpython-mecab導入(2017年10月) - u++の備忘録

端末

Windows 10

Python環境

Python 3.6.2 | Anaconda

インストール方法

pipで辞書などを丸ごと導入できるようにしてくださったものを利用する。

qiita.com

事前インストール

landinghub.visualstudio.com

エラー対応

www.gesource.jp

待ち行列モデルを用いてセブンイレブンのコンサルティングをしてみた

2015年に大学の授業で、待ち行列モデルを用いてセブンイレブンコンサルティングをした際の資料が出てきたので、出せる部分のみ編集して共有します。


問題設定

大学の最寄り駅近くにあるセブンイレブンを利便性の都合上よく使うのですが、当時の店員のオペレーションに不満を感じていました。それは二つレジがあるにもかかわらず原則一つのレジしか稼働しておらず、5人程度の列ができないと二つ目のサポートが入らない点です。

今回は「平均来店人数」と「平均レジ処理速度」を定義することで行列の数を再現する「待ち行列モデル」を用いて、①このセブンイレブンでどの程度の待ち時間が生じているか②仮に3人並んだ段階で2人体制になったら待ち時間がどの程度削減されるかーーを調べてみました。

実験

①このセブンイレブンでどの程度の待ち時間が生じているか

最初に実地調査をもとに、「平均来店人数」を1分間に1人、「平均レジ処理速度」を店員1人当たり40秒に1人と定義しました。そして共に指数分布に従うと仮定し、モンテカルロシミュレーションを実行します(理論の詳細は割愛します)。「エクセルのシート関数で処理しましょう」みたいな授業だったので、基本はExcelのシート関数で処理しつつ、難しかった部分はVBAで補っています。

この時の系内人数分布と待ち時間分布は下記のようになりました(グラフはRのggolot2で作成しました)。

系内人数分布

f:id:upura:20171118155356p:plain

待ち時間分布

f:id:upura:20171118155249p:plain

ここで、過去のアンケート結果を引用し、コンビニにおける「許容待ち時間」を3分と設定しました。この場合に、シミュレーション結果からは、許容待ち時間の3分を超える層が9.01%もいると判明しました。

②仮に3人並んだ段階で2人体制になったら待ち時間がどの程度削減されるか

ここでは「平均来店人数」と「平均レジ処理速度」の設定は変えず、3人並んだ段階で2人体制になるようにモデルを変更しました。

この時の系内人数分布と待ち時間分布は下記のようになりました。

系内人数分布

f:id:upura:20171118155850p:plain

待ち時間分布

f:id:upura:20171118155929p:plain

①の場合と比較すると下記のようになります。

系内人数分布

f:id:upura:20171118160050p:plain

待ち時間分布

f:id:upura:20171118160100p:plain

まとめ

f:id:upura:20171118160146p:plain

②の変更によって「許容待ち時間」を超えた層の割合が1.38%にまで削減されました。現実世界はここまで上手くいかないとは思いますが、このオペレーションにしてもらえると、顧客満足度は大幅に上昇する気がします。当時の僕にもう少しコミュニケーション力があれば、この資料をセブンイレブンに持参したかもしれません(???)。

【論文メモ】Learning Document Embeddings With CNNs

論文名

Learning Document Embeddings With CNNs
[1711.04168] Learning Document Embeddings With CNNs

概要

教師なし文書埋め込みのためのCNNを用いたモデルの提案。既存アプローチは、複雑な推論を必要とするか、または並列化が困難なRNNを使用。CNNを用いることで、完全な並列化を実現し、より深いモデルを学習させられる。

『画像認識』(機械学習プロフェッショナルシリーズ)第5章まとめ

某所にて、『画像認識』(機械学習プロフェッショナルシリーズ)の勉強会(輪読形式)があり、第5章「分類」を担当しました。参考書の内容に加え、『パターン認識と機械学習 上』の内容も盛り込み、包括的に「分類」を扱いました。

www.kspub.co.jp

下記の記事にまとめた部分など、参考書に具体例が記載されていない部分については、自らPythonで具体例の実装もしています。

upura.hatenablog.com

【論文メモ】AnnexML: Approximate Nearest Neighbor Search for Extreme Multi-label Classification

以下の記事に記載した論文

upura.hatenablog.com

論文名

Yukihiro Tagami: AnnexML: Approximate Nearest Neighbor Search for Extreme Multi-label Classification, KDD’17, pp.455-464, August 13–17, 2017, Halifax, NS, Canada.

どんなもの?

ラベルの種類数が膨大な場合(10^4 - 10^6)のマルチラベル分類問題に対し、高速かつ精度良く予測を行う分類器を提案

先行研究と比べてどこがすごい?

Sparse Local Embeddings for Extreme Classification (SLEEC) [4] の3つの問題点を解決

  • SLEEC only uses feature vectors and does not access label information
  • SLEEC’s optimization process for learning regressors is slightly complicated because of sparsity-induced and rank-constraint regularization terms.
  • Much faster prediction is preferable for scaling up to solve Web-scale classification problems

技術や手法のキモはどこ?

k-nearest neighbor graph (KNNG)

どうやって有効だと検証した?

Extreme Classification Repository [5]のデータを使い検証。予測時間と精度の両者の向上が確認できた。
(At the same level of accuracy, the prediction time of AnnexML was up to 58 times faster than that of SLEEC)
[5] Kush Bhatia, Himanshu Jain, Yashoteja Prabhu, and Manik Varma. 2016. The Extreme Classification Repository. (2016). Retrieved January 15, 2017 from https://manikvarma.github.io/downloads/XC/XMLRepository.html

議論はある?

More complex nonlinear models, such as kernel machines and deep neural networks に取り組みたい

次に読むべき論文は?

[4] Kush Bhatia, Himanshu Jain, Purushottam Kar, Manik Varma, and Prateek Jain. 2015. Sparse Local Embeddings for Extreme Multi-label Classification. In Proceedings of the 28th International Conference on Neural Information Processing Systems.

【補足/論文・動画など】ヤフー/Yahoo!の人工知能(AI)技術「アネックスエムエル」(AnnexML)

下記記事で報じられたヤフーの人工知能(AI)技術「アネックスエムエル」(AnnexML: Approximate Nearest Neighbor Search for Extreme Multi-label Classification)に関する補足。

r.nikkei.com

カタカナで「アネックスエムエル」と表記しているため、本日朝時点でほとんどヒットしなかった。

f:id:upura:20171115094636p:plain

概要

ラベルの種類数が膨大な場合(10^4 - 10^6)のマルチラベル分類問題に対し、高速かつ精度良く予測を行う分類器

発表の動画

www.youtube.com

おわりに

取り急ぎ自分用まとめ。暇な時に見る。

第5回将棋電王トーナメント決勝トーナメントのYorkie辞退騒動の経緯まとめ

認識違いの点などあれば、コメントなどでご指摘ください。詳細は、タイムシフトで確認を。

live.nicovideo.jp

---

経緯

  1. 決勝トーナメントのYorkie VS shotgun戦「256手ルール」の問題の発生しYorkieが敗北
  2. 運営が「ソフトの”独自性”の問題でYorkieが5位決定トーナメント以降の大会を辞退する」と発表
  3. 他ソフトの開発者がYorkieの開発者に対し「Yorkieには十分な”独自性”がある」と辞退撤回を要望
  4. 議論が紛糾するも最終的にはYorkieの開発者の意向が尊重され、Yorkieは5位決定トーナメント以降の大会を辞退

解説

大きく分けて二つの論点がありました。結論から言うと、Yorkieの開発者は1については納得し、2について十分な独自性がないと判断し、自主的に辞退したとのことです。

  1. 「256手ルール」の問題
  2. ソフトの「独自性」の問題

「256手ルール」の問題

第5回将棋電王トーナメントのルール(PDF)には、第22条として以下の規定があります。

予選リーグ、決勝トーナメント共に、256 手を超えて、対局が続く場合、立会人がどちらのソフトの負けとも判定せず、千日手でもないときは、その対局を引き分けとする。

昨日の予選リーグのPonanza VS 平成将棋合戦ぽんぽこ戦では、257手時点でPonanzaが「宣言勝ち」できる状況でしたが、上記の通称「256手ルール」が適用され、立会人の判断の元で引き分けを判定されました。

そして今日の決勝トーナメントでは、Yorkie VS shotgun戦で257手目で詰むという勝負になりました。解説者含め多くの方は昨日通りに「256手ルール」が適用され引き分け→再戦になると思いましたが、今回は(昨日とは別の)立会人の判断の元、Yorkieの負け判定が下されました。

この裁定のブレについては、さまざま議論がありましたが、Yorkieの開発者の方は「事前にルールを把握しており、256手では勝負がつかないと分かった際にも、対戦相手のshotgunの開発者と”どうなるのかなあ”と話していた」というようなコメントをしており、この件については納得しているとのことでした。

ソフトの「独自性」の問題

「256手ルール」とは別の軸で、ソフトの「独自性」の問題があります。第5回将棋電王トーナメントのルール(PDF)の第2章「参加資格」第3条には、以下の規定があります。

参加ソフトは、思考部について、自力で十分な工夫を施したものに限る。

「思考部」は以下のように定義されています。

指し手生成部、および、学習部のうち、使用可能ライブラリと定跡データを除いた部分
ただし、使用可能ライブラリを改造して用いる場合は、その改造した部分も含む

参加申し込み時点のYorkieのPR文書(PDF)では「KKPPT形式の手番ありの4駒関係」が「独自性」として記載されていました。また「その他」の部分には「なるべくconstexpr化して、コンパイラによる高速化に期待する」とも書いてありました。

運営による1の問題発生後の”独自性”確認

なぜこのタイミングだったのかが議論を紛糾させる要因だったと思います。1の問題発生後の5位決定トーナメント開始前に、運営によりYorkieの”独自性”確認が実施されたそうです。その場において、YorkieのPR文書内に記載されていた「KKPPT形式の手番ありの4駒関係」が実装に至っておらず、Yorkieは「探索部:やねうら王+評価部:elmo」という構造で、十分な独自性がないと判明。運営とYorkieの開発者の話し合いの結果、Yorkieの開発者から5位決定トーナメント以降の大会辞退の申し出があったそうです。

しかし運営からその発表があった直後、平成将棋合戦ぽんぽこの開発者を中心に「探索部を高速化している件(PR文書の「その他」に記載あり)は、十分な”独自性”ではないのか」という意見が出ました。「実際に第3回大会では、Aperyの探索部の高速化が”独自性”として認められた前例もある」と根拠を示しています。

探索部「やねうら王」の開発者のツイート

議論は続きましたが最終的には、Yorkieの開発者が「高速化には一定の独自性があると思うが、定量的な評価はできておらず、参加できる十分な”独自性”があるとは言えない」という姿勢を崩さず、辞退のまま大会が続行されることになりました。

憶測

コメントなどでは「1の問題をうやむやにするため、運営がこのタイミングでYorkieの”独自性”確認を実施し、Yorkieに辞退させようとしたのでは」という憶測が出ています。この憶測は憶測の域を出ませんが、凄く筋が通っているように見えます。

所感

個人的には、二つの問題を明確に切り分けて議論すべきだと思います。前者については、ルールの解釈問題で難しいですが、個人的には予選と同様に引き分けの処理をすべきだったと思います。そして後者については、運営が実際の大会予選開始前に、「独自性」の確認タイミングを設けなかったのが最大の問題かと思います。またそもそも論ですが、こういった強いソフトを目指す大会に「独自性」を求める規定が必要なのかも疑問です。強さだけが正義なのではないかなと。何が「独自性」かという定義も難しいですしね……。

今回浮かび上がった問題を受けてルールや運営方針を見直し、今後より良い大会として存続していってほしいと思っています。