はじめに
先日、アソシエーションルールマイニングに基づく推薦を民主化するライブラリ「AutoARM」をリリースしました。AutoARMはPythonで実装されており、PyPIで公開されています。
またオープンソースソフトウェア(OSS)としてGitHubで公開されています。
ゼロからアイデアを生み出したことからリリースするところまででさまざまな経験をしました。そこで、さまざまな学びがありました。本記事はAutoARMをリリースするまでの記録です。
開発に至る動機
AutoARMの開発に至る動機は3つあります。
“アソシエーションルールマイニングに基づく推薦”の提案
開発に着手する直前、「今こそ“アソシエーションルールマイニングに基づく推薦”が活きる時代なんじゃないか?」と思っていたことです。詳細については以下のブログを読んでください。
daikikatsuragawa.hatenablog.com
簡単にまとめると以下の点で改めて有用な手法だと思っています。
- 推薦の根拠を説明可能
- 推薦を実施したい相手に紐づく情報がなくても推薦可能
そして、上記2点は、データ提供・活用が実施されていないサービスに対して有効だと考えられます。そして、日本におけるデータ提供・活用をブレイクスルーするひとつのキッカケになるのではないかと期待しています。
また、ライブラリになっていた場合、プライベートにおける取り組みではあるものの、現在所属している組織でも簡単に再利用が可能になります。それゆえ、現在所属している組織における新規サービス・機能の提案の火種になることも期待していました。
過去の自分(=未来の誰か)の支援
学生時代、利用状況、推薦に関する研究をしていました。そこでアソシエーションルールマイニングに基づく推薦を実装していました。
https://ieeexplore.ieee.org/document/8445832ieeexplore.ieee.org
実は当時、実装がとても苦手で、比較的多くの時間をかけて保守の手間を無視する危なっかしいスクリプトを書いていました。というのも、アソシエーションルールマイニングに基づく推薦ってライブラリとして実装されていなかった(もしくは見つからなかった)のです。
もっと前にも似たようなことがありました。テーブルデータを用意した状態で、「こんな手法で予測したい」という方針は決まっているものの、スクリプトを書けないが故に手が止まってしまうということです。この日は状況共有の機会の前日だったこともあり、すぐにでも実現したいと思い、詳しい同期にスクリプトを書いてもらいました。すると一瞬でやりたいことが実現できました。この出来事をきっかけに学術研究、特に機械学習やデータ分析を必要とするものにおいて、技術がなく実現できない、提案できないアイデアがあるんじゃないかと思っていました。ただ近年、AutoMLが提案されており、機械学習という技術は民主化されています。これにより、上述した過去の自分が助かります。過去の自分の悩みは、未来の自分や誰かの悩みです。AutoMLにより未来の誰かの問題の解決に進んでくのではないかと思っています。
AutoML開発の動機についても技術にしてもとても共感していました。そんな中、“アソシエーションルールマイニングに基づく推薦”って実装されていない、つまり民主化されていないと思いました。個人的に有用な手法だと思っているため、過去の自分(=未来の誰か)のためにも実装し、誰もが利用できる状態にすることが望ましい状態と思いました。
(オーナーとして)OSSの開発
ソフトウェアエンジニアとして、意味のあるOSSを、自分がオーナーとして開発したいと思っていました。下記より既にOSSはリリースしたことがあるのですが、やはり、自分が貢献したいと思っているデータ分析、機械学習に関して、取り組みたいと思いました。
daikikatsuragawa.hatenablog.com
とにかく、ひとつを作りきることによって得られる経験値の大きさを期待していたため、単純にやってみたかったということがあります。OSSのスタンスについてもとても共感しています。完璧なものを開発しきるというよりは、「やりたいことの提示」を一番の目的としたいと思いました。自分よりも素晴らしいソフトウェアエンジニアが世界中にいることもあり、自分の思いに共感してくれた人が何かを直してくれたら、それがOSSのあるべき姿なんじゃないかと思ったためです。そのため、Minimum Viable Product(MVP)の考えに基づき、必要最小限の実装で、体験・価値を実現したいと思いました。このような思いを持ってOSS、特にPythonのライブラリを開発したいと思いました。
ライブラリの内容の設定
上述した動機に基づき、「アソシエーションルールマイニングに基づく推薦を民主化する」といったテーマでライブラリを開発しようと考えました。そこで、既存ライブラリを調査し、以下のような内容を定めました。
- アソシエーションルールマイニングに基づく推薦に基づく過程を実装
- テーブルデータの入力
- 頻出パターンマイニング
- アソシエーションルールマイニング
- ルールに基づく推薦
- 過程が首尾一貫しており誰でも簡単に利用可能
- 参考とするインタフェースはAutoGluon*1
既存ライブラリに対する新規性は以下2点です。
- アソシエーションルールマイニングに基づく推薦を対象
- (アソシエーションルールのライブラリに対して)推薦までを実装
以上より、開発に着手しました。
推薦の流れ
新規性としてもアピールしていた「推薦」の流れを紹介します。MVPに基づき、最もシンプルな方法はこれだなと思う方法を実装しました。インプットは推薦対象の現状のアイテムリストと、事前に出力したルール群、推薦の基準とするメトリック(信頼度またはリフト)です。アウトプットは推薦の参考になるルールN件です。流れを以下に示します。
- ルール群の結論部を分割(多:1のルールに)
- 入力したアイテムリストと一致する条件部を持つルールを特定
- 入力したアイテムリストと結論部が一致するルールを除外
- この手順はスキップも可能
- メトリックとして指定された信頼度またはリフトでルールを並び替え
- 上位のルールに対して結論部が重複するルールを除外
- 指定されたサイズ(N件)のルールを出力
詳細や実装についてはREADMEやソースコードを見ていただけると幸いです。
これにより、AutoARMは推薦の参考となるルールを出力します。ミソはアイテムではなく、ルール自体を出力することです。つまり、そのアイテムを推薦する根拠を残しています。これにより、根拠を説明しつつアイテムを推薦するため、相手の行動を促す推薦サービスが実現されます。
AutoARMの紹介
上記のような過程を経て開発を進めてAutoARMが完成しました。ざっくりと紹介します。
まず始めにデータを用意しておきます。サンプルとして適当なものを生成しています。
import pandas as pd sample_dataset = { 'transaction_id': [1, 1, 1, 2, 2, 3, 3, 3, 4, 4, 5, 5, 5, 6, 6, 6, 6, 7, 7], 'item_id': [ "X", "Y", "Z", "X", "B", "Y", "A", "C", "A", "C", "X", "Y", "Z", "X", "Y", "B", "A", "X", "B" ], } df = pd.DataFrame.from_dict(sample_dataset)
つまりこのようなテーブルデータが必要です。transaction_id
列、item_id
列`にあたる列さえあれば他に何かあっても問題はありません。列名は後でしているため、異なっていても問題はありません。
transaction_id | item_id |
---|---|
1 | X |
1 | Y |
1 | Z |
2 | X |
2 | B |
... | ... |
7 | X |
7 | B |
ここからAutoARMについてです。まずはインストールが必要です。Pypiで公開されているため、以下でインストールが可能です。
pip install autoarm
以下により、アソシエーションルールマイニングに基づく推薦を実現するオブジェクトを生成可能です。import文を除くと、4行です。
from autoarm import AssociationRules, Dataset, FrequentItemsets, Recommender dataset = Dataset(df, "transaction_id", "item_id") frequent_itemsets = FrequentItemsets(dataset, min_support=0.01) association_rules = AssociationRules(frequent_itemsets, metric="confidence", min_threshold=0.1) recommender = Recommender(association_rules)
以下により、推薦が可能です。
items = ["X", "Y"] recommend_rules = recommender.recommend(items, n=3, metric="confidence") recommend_rules
以下の表が出力されます。
rank | antecedents | consequents | support | confidence | lift |
---|---|---|---|---|---|
1 | (X, Y) | (Z) | 0.285714 | 0.666667 | 2.333333 |
2 | (X) | (B) | 0.428571 | 0.600000 | 1.400000 |
3 | (Y) | (A) | 0.285714 | 0.500000 | 1.166667 |
例えば、この出力に基づいて「既にあなたが購入を検討しているXとYを購入した人の66%がZも購入しています。Zを購入してみてはどうでしょうか?」といった説明を加えた推薦が実現されます。また、XとYの購入を検討している推薦を実施したい相手に紐づく情報がなくてもこのような推薦が実現されます。良いですね。
以上より、簡単にアソシエーションルールマイニングに基づく推薦が実現されます。
今後の展望
正直なことを言うと、“アソシエーションルールマイニングに基づく推薦を民主化”するためにまだまだ追加することが望ましい機能があると思っています。例えば以下です。
- さまざまな形式の入力データの対応
- パラメータの自動調整
- アソシエーションルールマイニングに基づく別の推薦手法の実装
そして、OSSとしてもっとこんな状態にしたかったと思っていることがあります。例えば以下です。
自分でガンガン開発してしまうのもいいのですが、せっかくGitHubで公開して、指針もあるため、プルリクエストを期待してひとまず手を動かすのは止めようかと思っています。特に、自分にはレビューしてくれる人がいないため、自らバグを混入してしまう可能性もあるためです。また、もっとやりたいこともあるため、世界のソフトウェアエンジニアに任せてみたいと言うこともあります。
そのため、ひとまず開発自体は小休止して、どのようにサービスに組み込むのかなどについて注力して考えようと思います。
最近のお寿司屋さん、タッチパネルでの注文が浸透していますよね。こことかで活躍しそうだなとか妄想しています。
おわりに
アソシエーションルールマイニングに基づく推薦を民主化するライブラリ「AutoARM」をリリースするまでの記録を紹介しました。是非とも使ってください!フィードバックください!コントリビュートしてください!スターください!
おまけ
本文に書くほどではないが、遺しておくべきだと感じた内容について、サクサクと記録します。
- テストはとても大切(ユニットテスト〜運用テスト)
- ユニットテストに何度も救われた
- 運用テストに何度も救われた
- しかしテスト設計はまだまだ未熟
- AIソフトウェアのテストは非常に難しい
- パフォーマンスの担保
- 「AIソフトウェアのテスト」が参考になる?(めどがついたため未読)
- 現実的な利用状況に適した速度およびアルゴリズムに
- プロトタイプ作成時はすごく遅かった(レコメンドに数分…)
- 問題を解決するために別のライブラリ「df4loop」も誕生した
- 初めてのリリース(Pypiへの公開)はすごく緊張する
- 10分ほど精神を統一したのちヤケになって「ポチッ!」
- 多分経験値は大きい
- 社内LT会で少しだけ紹介した
- “サクっと”API作れるようになりたい
- 一回テンプレートみたいなものを作るか…
- 欲を言うとDocker、Kubernetes…
- “サクっと”ウェブアプリケーションを作れるようになりたい
- Django?
- Flask?
- 一回テンプレートみたいなものを作るか…(再)
- 欲を言うとDocker、Kubernetes…(再)
- 開発環境はほとんどGitpod+Colab!
*1:Amazon Web Services - LabsのAutoMLライブラリgithub.com