Python または Java で、段階的に使用できる決定木分類子の実装を推奨できる人はいますか?
私が見つけたすべての実装では、分類を取得するために、分類器にすべての機能を一度に提供する必要があります。ただし、私のアプリケーションには何百もの機能があり、一部の機能は評価に時間がかかる関数です。ツリーのすべてのブランチがすべての機能を使用するわけではないため、分類器にすべての機能を一度に与えることは意味がありません。エントロピーを最大限に削減し、最終的な分類を提供するために必要な順序で、分類器に一度に 1 つずつ機能を要求してもらいたいと思います。
そのような実装はないと思いますが、決定木は非常に簡単に実装できるので、自分でそのようなプログラムを作成しても問題はありません。
一方、その場で機能をカウントするという考えは速度を上げることができるとは思いません。なぜなら、一部の機能が以前の分割を行うために使用されたとしても、残りの部分で考慮する必要があるため、多くのレコードでは何度も再計算されます（ただし、メモリを節約できます）。これは、ランダムで限定された機能のサブセットのみが各分割で考慮されるランダム フォレストの場合に意味があります。それでも、RF は分類器としてのみ使用でき、人間が解釈できる適切な決定木は構築されません。
通常、そのようなパッケージ (特に Weka の J48 ツリー) では、機能値の代わりに欠損値を指定できます。これは、C4.5 アルゴリズムが行うのと同じ方法で処理されます。
値が欠落しているその属性によって分割されているノードに到達すると、それらのブランチを下るトレーニング インスタンスの数に比例して重み付けされた各可能なブランチにインスタンスを送信し、最終的にリーフ ノードで結果を蓄積します。
もちろん、より積極的なアプローチを取り、トレーニング フェーズ中にツリーが分割する属性を選択する方法を変更することもできます。単純な方法は、属性に重みを割り当て、分割基準 (エントロピー、情報利得など) にその重みをペナルティ係数として掛けることです。これにより、「高価な属性」が分割ノードとして選択される可能性が低くなります。
トレーニング時または分類時にこれについて心配していますか? これらの期間は別々であるため、遅い場合は非常に遅くなるまで評価を避けるためにトリックをすることができます。練習時間中にできるトリックはありません。トレーニング時にすべての機能を提供する必要があります。ただし、これはプログラムの外部で発生する可能性があるため、計算時間についてそれほど気にする必要はありません。ツリーのトレーニングは最も集中的な部分です。
したがって、すべてのデータをまとめてトレーニングし、トレーニングから製品を取得してから、オブジェクトをツリーに送信するときに遅延評価を使用することをお勧めします。コードを使用して物事を遅延評価できる値を取得するためのインターフェイスをオブジェクトに実装させます。高価な値を必要とするノードにオブジェクトがヒットしない場合は、それを評価する必要はありません。
高価な計算は、分割するピックとして選択されない可能性があるため、分類時にそれらを評価する必要がなくなります。ツリーをトレーニングして剪定すると、統計的に関連性のある特徴はおそらく 3 ～ 5 個しかないでしょう。次に、キャッシュなどを使用してそれらの機能のみを最適化できるため、分類が高速になります。
まったく別のワックス ボールであるインクリメンタル トレーニングが必要な場合は、そのためのアルゴリズムがあります。しかし、それらはあまりよく説明されておらず、研究論文を掘り下げて入手する必要があります.
これが私がすることです。私の前の質問への答えを考えると、次のようなものがあると思います。アプローチのような 20 の質問を実装したいようです。
20 の質問では、はい/いいえの答えがあるため、二分木が最適に機能します。ただし、複数の選択肢を重ねることもできますが、ユーザーは 1 つの選択肢を選択します。したがって、このアルゴリズムは、事前にツリーをトレーニングし、使用するデータセットから構築されていることを前提としています。
たとえば、医療診断を行おうとしているとします。そのため、データは次のようになります。
Disease Name Head Ache Fever Back Pain Leg Pain Blurry Vision Hearing Loss
Common Cold Yes Yes No No No No
Migraine Yes No No No Yes No
Herpes No Yes No No No No
この例では、頭痛、発熱、背中の痛み、足の痛みなどがインフルエンサーであり、疾患名がターゲットです。各行は 1 人の患者の実際の診断であるため、データ内で病気が複数回繰り返される可能性があります。
リーフノードでは、その場所に到達した実際の行が必要になるため、次のいずれかがある可能性があるとユーザーに表示できます。
頭痛 片頭痛 切断された頭
処方箋は：何とか何とか何とか。
100 万人のインフルエンサーがいるため、ツリーを構築するにはしばらく時間がかかります。それを下げたい場合は、yes/no の代わりに複数の値を持つインフルエンサーを使用できる可能性があります。どんな病状であっても、100 万通りの「はい/いいえ」のユニークな質問を考えるのは非常に困難です。ツリーを構築すると、必要な数の診断を提供できます。