3

テキスト分類用に大規模な SVC モデル (~50Mb cPickles) があり、実稼働環境でそれらを使用するさまざまな方法を試しています。ドキュメントのバッチの分類は非常にうまく機能します ( と の両方predictを使用して、1 分あたり約 1,000 ドキュメントpredict_proba)。ただし、この質問へのコメントで説明されているように、単一のドキュメントの予測は別の話です。

バッチで予測を行っていますか? 残念ながら、SVC.predict メソッドは、トレーニング アルゴリズムが生成したものと同様の LibSVM データ構造を再構築し、サポート ベクターを浅いコピーし、テスト サンプルを LibSVM 形式に変換する必要があるため、多くのオーバーヘッドが発生します。 NumPy/SciPy 形式とは異なる場合があります。したがって、単一のサンプルの予測は遅くなります。– ラースマンズ

私はすでにSVCモデルをFlask Webアプリケーションとして提供しているため、オーバーヘッドの一部はなくなりましたが(unpickling)、単一ドキュメントの予測時間は依然として高い側(0.25秒)です。メソッドのコードを見てきましたがpredict、サーバーの起動時にLibSVMデータ構造を事前に再構築して、それらを「事前にウォームアップ」する方法があるかどうかわかりません...何かアイデアはありますか?

def predict(self, X):
    """Perform classification on samples in X.

    For an one-class model, +1 or -1 is returned.

    Parameters
    ----------
    X : {array-like, sparse matrix}, shape = [n_samples, n_features]

    Returns
    -------
    y_pred : array, shape = [n_samples]
        Class labels for samples in X.
    """
    y = super(BaseSVC, self).predict(X)
    return self.classes_.take(y.astype(np.int))
4

2 に答える 2

3

考えられる解決策は 3 つあります。

カスタムサーバー

何かを「温める」ということではありません。簡単に言えば、libSVMはCライブラリであり、データを正しい形式にパック/アンパックする必要があります。このプロセスは、各行を個別に処理するよりも、行列全体に対して効率的です。これを克服する唯一の方法は、本番環境と libSVM の間により効率的なラッパーを作成することです (サービスである種の共有メモリを使用する libsvm ベースのサーバーを作成できます)。残念ながら、これは既存の実装で解決できるカスタムの問題です。

バッチ

クエリをバッファリングするような単純なアプローチもオプションです (数千のクエリを含む「高性能」システムの場合は、単純にそれらを N 要素のバッチに格納し、そのようなパックで libSVM に送信できます)。

独自の分類

最後に、SVM を使用した分類は非常に単純な作業です。分類を実行するために libSVM は必要ありません。トレーニングだけが複雑な問題です。すべてのサポート ベクター (SV_i)、カーネル (K)、ラグラジアン乗数 (alpha_i)、および切片項 (b) を取得したら、次を使用して分類します。

cl(x) = sgn( SUM_i y_i alpha_i K(SV_i, x) + b)

libsvmに実際に何かをパック/アンパック/送信する必要なく、この操作をアプリで直接コーディングできます。これにより、桁違いに高速化できます。明らかに、プラットのスケーリングが必要なため、確率を取得するのはより複雑ですが、それでも可能です。

于 2014-01-29T17:39:22.213 に答える
1

事前に LibSVM データ構造を構築することはできません。ドキュメントを分類する要求が届くと、ドキュメントのテキストを取得し、if からベクトルを作成してから、LibSVM 形式に変換して決定を下すことができます。

LinearSVCSVCを使用するため、線形カーネルを使用したよりもかなり高速になるはずliblinearです。パフォーマンスがあまり低下しない場合は、別の分類子を使用してみてください。

于 2014-01-29T10:39:05.723 に答える