jubatus-algorithm-objects.rst

Jubatusアルゴリズムのオブジェクト関係

現状のdriver以下classifier, recommender, nearest neighbor, anomaly, clusteringにおけるオブジェクトの参照関係を示す。 クラスAのオブジェクトがクラスBのオブジェクトを参照するときに、

• A:
  • B

のように記している（ここでいう「参照」は包含やポインタを含む）。括弧つきでモデルの種類や、実装ごとに異なるものを指定している。

fv converterとそのmixable, mixable holderは以下において共通のため省略した。 また、実装を分割するのが目的の（アルゴリズム・タスク固有の）クラスなども省略した。 Nearest NeighborおよびNN enabledと書かれたものは feature/nearest_neighbor_recommender_and_lof のものである。

Classifier

• driver:
  • algorithm:
    • model (storage)
  • mixable model:
    • model (storage)

Nearest Neighbor

• driver:
  • algorithm:
    • model (table)
  • mixable model:
    • model (table)

Recommender

• driver:
  • algorithm:
    • original data
    • model (storage)
  • mixable model (storage):
    • model (storage)

Recommender (NN enabled)

• driver:
  • algorithm:
    • original data
    • (if recommender not on NN) model (storage)
    • (if recommender on NN) NN algorithm:
      • model (table)
  • mixable model (storage):
    • model (storage)
  • mixable model (table):
    • model (table)

Anomaly

• driver:
  • algorithm:
    • mixable model (storage):
      • model (storage)
    • model (storage):
      • recommender algorithm:
        • original data
        • model (recommender storage)
• recommender algorithmがLOF直下ではなくmodel (storage)以下になってしまっているのは、確かrecommenderのMIXをmodel (storage)内でやらないといけなかったから（詳細忘れた）

Anomaly (NN enabled)

• driver:
  • algorithm:
    • (if LOF on recommender) mixable model (storage):
      • model (storage)
    • (if LOF on recommender) model (storage):
      • recommender algorithm:
        • original data
        • model (recommender storage)
    • (if LOF on NN) mixable model (NN table):
      • mixable model (NN table):
        • model (NN table)
      • mixable model (table):
        • model (table)
      • NN algorithm:
        • model (NN table)
• NNはalgorithmがmixableを持っていないので、mixable model (NN table)はLOF on NNが持たないといけない
• NNではdriverがmixableを持ってしまっている。本来、driverはfv変換とサーバとのインターフェイス提供(e.g. mixable holder)だけをするべき

Driver以下の構成案

• driver:
  • mixable holder
  • fv converter and its mixable (if needed)
  • algorithm:
    • mixable model:
      • model
    • other dependent algorithms

各クラスは以下の役割に責任を持つ

• driver: アルゴリズムに共通のインターフェイスの提供、fv converterを用いたdatum fv変換、mixable holderの提供 (TODO: driverの外に出せない？)
• algorithm: アルゴリズムのロジックを記述する、mixableを登録する
• mixable model: MIX処理のロジックを記述する
• model: MIXされるデータに関するプリミティブな処理を記述する
• other dependent algorithms: アルゴリズムが内部で用いる別アルゴリズム。これ自体もalgorithmと同じ構成を持つ。
• unlearner: 忘却ロジックを記述する、実際の忘却処理はalgorithmのメンバ関数として定義され、それをコールバックとして保持する

この構成に統一すると、以下の利点がある

• 構成が統一されるので、あるdriver以下を読んだ人は別のdriver以下を読みやすくなり、新しいdriverやalgorithmを作る際にも参考にしやすい
• driver, algorithm, modelの役割がタスク間で統一されるので、recommender on NNやanomalyのように別タスクを中で用いるアルゴリズムを書きやすくなる
• 今まではmixableの所有者などがdriver, algorithmごとにバラバラだったため、別タスクを用いる際にそれらを調停するために無理のある設計にせざるを得なかった

fv_converterによる変換処理が毎回必ずある、という様な形を取れば、driverの外に出せる気がしますね。