私はそれを理解しているように、私はたくさんのお菓子を食べるか、アプリケーションのチェックインによる商品の分類

挑戦する


この記事では、小切手およびショッピングアシスタントの会計費用の申請で、領収書から商品名を分類するソリューションを作成した方法について説明します。 スキャンされた領収書に基づいて自動的に収集された購入に関する統計を表示する、つまり、ユーザーが購入したすべての商品をカテゴリ別に配布する機会をユーザーに提供したかったのです。 ユーザーに製品を個別にグループ化するように強制するのは、すでに前世紀です。 この問題を解決するには、いくつかのアプローチがあります。単語のベクトル表現や古典的な分類アルゴリズムのさまざまな方法でクラスタリングアルゴリズムを適用しようとすることができます。 新しいものは何も発明していません。この記事では、問題の可能な解決策、これを行わない方法の例、他の方法が機能しなかった理由の分析、プロセスで発生する可能性のある問題についての小さなガイドを共有したいと思います。

クラスタリング


問題の1つは、小切手から得られる商品の名前が、たとえ人であっても、必ずしも簡単に解読できるとは限らないことでした。 ロシアの店舗で「UTRUSTA krnsht」という名前の商品がどのように購入されたかを知ることはまずありません。 スウェーデンのデザインの真の愛好家は、すぐに私たちに答えます:Utrustのオーブン用ブラケット、しかしそのような専門家を本部に置くことは非常に高価です。 さらに、データに適した既製のラベル付きサンプルがなく、その上でモデルをトレーニングできました。 したがって、最初に、トレーニング用のデータがない場合にクラスタリングアルゴリズムを適用した方法と、それが好きではなかった理由について説明します。

同様のアルゴリズムは、オブジェクト間の距離の測定に基づいています。これには、ベクトル表現または単語の類似性を測定するメトリックの使用(レーベンシュタイン距離など)が必要です。 このステップでの難点は、名前の意味のあるベクトル表現にあります。 製品および他の製品との関係を完全かつ包括的に説明する名前のプロパティから抽出するのは問題です。

最も単純なオプションはTf-Idfを使用することですが、この場合、ベクトル空間の次元は非常に大きく、空間自体は疎です。 さらに、このアプローチでは、名前から追加情報を抽出しません。 したがって、1つのクラスターには、たとえば「ポテト」や「サラダ」などの一般的な単語で結合された、さまざまなカテゴリの多くの製品が存在する可能性があります。


また、どのクラスターを組み立てるかを制御することもできません。 示すことができる唯一のことは、クラスターの数です(空間内の非密度ピークに基づくアルゴリズムが使用されている場合)。 ただし、指定する数量が少なすぎると、1つの巨大なクラスターが形成され、他のクラスターに収まらないすべての名前が含まれます。 十分に大きいものを指定した場合、アルゴリズムが機能した後、数百のクラスターを調べて、それらを手作業でセマンティックカテゴリに結合する必要があります。

以下の表は、ベクトル表現にKMeansおよびTf-Idfアルゴリズムを使用したクラスターに関する情報を提供します。 これらの表から、クラスターの中心間の距離は、オブジェクトとそれらが属するクラスターの中心間の平均距離よりも短いことがわかります。 このようなデータは、ベクトルの空間に明らかな密度ピークがなく、クラスターの中心が円上にあり、ほとんどのオブジェクトがこの円の外側にあるという事実によって説明できます。 さらに、ほとんどのベクターを含む1つのクラスターが形成されます。 このクラスターで最も可能性が高いのは、さまざまなカテゴリのすべての製品の中で他の単語よりも頻繁に見つかる単語を含む名前です。

表1.クラスター間の距離。
クラスターC1C2C3C4C5C6C7C8C9
C10.00.5020.3540.4750.4810.5270.4980.5010.524
C20.5020.00.6140.6850.6960.7280.7060.7090.725
C30.3540.6140.00.5900.5970.6350.6100.6130.632
C40.4750.6850.5900.00.6730.7090.6830.6870.699
C50.4810.6960.5970.6730.00.7150.6920.6940.711
C60.5270.7270.6350.7090.7150.00.7260.7280.741
C70.4980.7060.6100.6830.6920.7250.00.7070.714
C80.5010.7090.6120.6870.6940.7280.7070.00.725
C90.5240.7250.6320.6990.7110.7410.7140.7250.0

表2.クラスターに関する簡単な情報
クラスターオブジェクトの数平均距離最小距離最大距離
C1625300.9990.0411.001
C221590.8640.5270.964
C310990.9340.7560.993
C412920.8790.7330.980
C57460.8750.7310.965
C624510.8470.7190.994
C711330.8660.7240.986
C88760.8630.7040.999
C918790.8490.5260.981


しかし、たとえば下の画像のように、クラスターはかなりまともな場所もあります。ほとんどすべての商品がキャットフードです。



Doc2Vecは、ベクトル形式でテキストを表すことができるもう1つのアルゴリズムです。 このアプローチを使用すると、各名前はTf-Idfを使用するよりも小さな次元のベクトルで記述されます。 結果のベクトル空間では、類似したテキストは互いに近く、異なるテキストは遠くにあります。

このアプローチは、Tf-Idf法によって得られる大きな次元と放電空間の問題を解決できます。 このアルゴリズムでは、トークン化の最も単純なオプションを使用しました。名前を別の単語に分割し、それらの初期形式を取りました。 彼はこの方法でデータのトレーニングを受けました:

max_epochs = 100 vec_size = 20 alpha = 0.025 model = doc2vec.Doc2Vec(vector_size=vec_size, alpha=alpha, min_alpha=0.00025, min_count=1, dm =1) model.build_vocab(train_corpus) for epoch in range(max_epochs): print('iteration {0}'.format(epoch)) model.train(train_corpus, total_examples=model.corpus_count, epochs=model.iter) # decrease the learning rate model.alpha -= 0.0002 # fix the learning rate, no decay model.min_alpha = model.epochs 

しかし、このアプローチでは、名前に関する情報を持たないベクターが得られました-同じ成功で、ランダムな値を使用できます。 アルゴリズムの操作の一例を次に示します。画像は、「n pn 0.45k形式のボロジノパン」によるアルゴリズムに類似した製品を示しています。


おそらく問題は、名前の長さとコンテキストです:名前のパス「__ club。Banana 200ml」は、ヨーグルト、ジュース、または大きなクリーム缶のいずれかです。 名前のトークン化に別のアプローチを使用すると、より良い結果を得ることができます。 この方法を使用した経験はなく、最初の試行が失敗するまでに、製品名の付いたマーク付きセットが既にいくつか見つかっていたため、この方法をしばらくそのままにして、分類アルゴリズムに切り替えることにしました。

分類


データの前処理


小切手からの商品の名前は、必ずしも明確な方法ではありません。ラテン語とキリル文字は言葉で混ざり合っています。 たとえば、文字 "a"はラテン語 "a"に置き換えることができ、これにより一意の名前の数が増えます。たとえば、単語 "milk"と "milk"は異なると見なされます。 名前には、他にも多くのタイプミスや略語があります。

データベースを調べたところ、名前に典型的なエラーが見つかりました。 この段階で、正規表現を使用せずに、名前を整理して特定の一般的なビューを表示しました。 このアプローチを使用すると、結果は約7%増加します。 ツイスターパラメーターを使用したフーバー損失関数に基づく単純なSGD Classifierオプションと合わせて、F1の精度は81%(すべての製品カテゴリーの平均精度)になりました。

 sgd_model = SGDClassifier() parameters_sgd = { 'max_iter':[100], 'loss':['modified_huber'], 'class_weight':['balanced'], 'penalty':['l2'], 'alpha':[0.0001] } sgd_cv = GridSearchCV(sgd_model, parameters_sgd,n_jobs=-1) sgd_cv.fit(tf_idf_data, prod_cat) sgd_cv.best_score_, sgd_cv.best_params_ 

また、人々の一部のカテゴリは他のカテゴリよりも頻繁に購入することを忘れないでください。たとえば、「お茶とお菓子」と「野菜と果物」は「サービス」と「化粧品」よりもはるかに人気があります。 このようなデータの分布では、各クラスの重み(重要度)を設定できるアルゴリズムを使用することをお勧めします。 クラスの重みは、クラス内の製品の数と製品の合計数の比に等しい値で逆に決定できます。 ただし、これらのアルゴリズムの実装では、カテゴリの重みを自動的に決定することができるため、考える必要はありません。


トレーニング用の新しいデータを取得する


私たちのアプリケーションは、競技会で使用されたものとはわずかに異なるカテゴリーを必要とし、データベースからの製品の名前は、コンテストで提示されたものとは著しく異なっていました。 したがって、領収書から商品をマークする必要がありました。 私たちはこれを自分でやろうとしましたが、チーム全体をつなげても非常に長い時間がかかることに気付きました。 そのため、Yandexの「Toloka」を使用することにしました。

そこで、この形式の割り当てを使用しました。


各カテゴリの機能を説明する例とともに詳細な手順を作成し、品質管理方法も使用しました:通常のタスクと一緒に表示される標準的な回答のセット(標準的な回答を自分で実装し、数百の製品をマークアップしました)。 これらのタスクに対する回答の結果によれば、データを誤ってマークアップしたユーザーは除外されました。 ただし、プロジェクト全体では、600人以上のユーザーのうち3人のみを禁止しました。


新しいデータにより、データにより適したモデルが得られ、精度がわずかに(約11%向上)、すでに92%が得られました。

最終モデル


Kaggleのいくつかのデータセットからのデータの組み合わせで分類プロセスを開始しました-74%、その後、前処理を改善-81%、新しいデータセットを収集-92%、最後に分類プロセスを改善:最初に、ロジスティック回帰を使用して、商品の予備確率を取得SGDは、製品名に基づいてカテゴリの精度を高めましたが、損失関数に大きな値が残っていたため、最終的な分類器の結果に悪影響がありました。 さらに、取得したデータを製品の他のデータ(製品の価格、購入した店舗、店舗の統計、チェックおよびその他のメタ情報)と組み合わせ、XGBoostはこのすべてのデータ量でトレーニングされ、98%の精度が得られました(増加さらに6%)。 判明したように、トレーニングサンプルの品質が最大の貢献をしました。

サーバーで実行中


展開を高速化するために、Flaskの単純なサーバーをDockerに上げました。 サーバーから商品を受け取り、既にカテゴリに分類して商品を返品する必要がある商品を受け取りました。 そのため、Tomcatを中心とした既存のシステムに簡単に統合できました。アーキテクチャを変更する必要はありませんでした。もう1ブロック追加するだけです。

発売日


数週間前に、Google Playに分類されたリリースを投稿しました(しばらくするとApp Storeに表示されます)。 次のようになりました。


将来のリリースでは、カテゴリを修正する機能を追加する予定です。これにより、カテゴリ化エラーを迅速に収集し、カテゴリ化モデルを(自分自身で)再トレーニングできるようになります。

Kaggleで言及されたコンテスト:

www.kaggle.com/c/receipt-categorisation
www.kaggle.com/c/market-basket-analysis
www.kaggle.com/c/prod-price-prediction

Source: https://habr.com/ru/post/J430216/


All Articles