概要：前にそれらの面白いシリーズ2における広告業界：BERT本物のNLPテキスト分類タスク（添付githubのソースコード）、我々はBERT分類器で2を構築しました。マルチBERTタグ付けモデルを構築するために使用される実際の商品のニーズは、タグの多くの種類が大幅にモデル化効率を向上させる、モデルによって識別することができます。実際のプロジェクトでは、ビジネスニーズに基づいて、バイナリと複数のタグ付けモデルの完全なテキスト認識タスクを使用します。
Benpian学習することで、少しの友人は、マルチBERTのタグ付けタスクを解決するためのモデルを使用することができます。データマイニング、データ解析と自然言語処理は、多くの注目することができ、小さなパートナーに興味を持っています。
ディレクトリ
以上の01のタグ付けタスクの背景
以上の02のタグ付けタスクVS二分タスク
03 BERTビルドマルチモデルの戦闘タギング
以上の01のタグ付けタスクの背景
話をBERTビルド2つの分類プロジェクトの戦闘前に、我々は興味伝説のゲームならば、ユーザーの検索を特定する必要があります。実際のプロジェクトのカテゴリシステムにおける当社の関心は非常に複雑であり、かつ厳密な階層があります。私たちは今、カテゴリのシステムを持っている場合は、次のように：
- ゲーム
- 伝説のゲーム
- 除去ゲーム
- マジックゲーム
- 車
- スター
- 金融取引を行います
通常、ラベルのみ関心がある場合のためのユーザーの検索、同時により多くの興味深いラベルで、あるいは単に無効検索に興味を持っていません。たった2つの分類多くの珍しいワークロードこの場合。私たちは、ラベルの数百あるいは数千を持っている場合は、我々は2つの分類器の数百あるいは数千を必要としないのか？これは明らかに不合理です。
いくつかの小さなパートナーは、我々は、複数の分類器を使用することができることを、言いました。はい、複数の分類器を使用することはよくこの問題を軽減することがあります。しかし、データのクラスへのマルチ分類器は、相互に排他的であり、様々な種類の間で分割される、または複数のラベルに対応することができ、ユーザーの検索状況を解決することはできません。必要なのは、マルチタグ付けモデルです。
我々は、マルチタギングモデルを構築する必要があるので、概要の下では、複雑なシステムへの関心のカテゴリは、ユーザーは、複数の検索関心タグに対応してもよいです。
以上の02のタグ付けタスクVSマルチ分類タスク
ここでは良いマルチタスクとの違いや接続マークマルチラベル分類タスクを説明するための図によります。注バイナリ分類タスクは、マルチ分類タスクの単なる特殊なケースです。
マルチ分類タスク機能のみのラベルに属していることをユーザーに問い合わせることです。私たちが今、ユーザーのクエリは、最も単純なバイナリ分類課題の一つである伝説的なラベルの一部ではない識別するために使用されている場合二分分類は、マルチタスクの特殊なケースです。覆われており、それぞれLABEL1とLABEL2を表現することができるカバーされていません。
モデルのマルチタグ付け機能では、ユーザーのクエリはまた、noneに属していてもよい、複数のラベルに属してもよいです。「どのような楽しい伝説のナイフのジャッキーの裏書」、例えば、取る、またスターラベルに属し、システムへの関心のカテゴリに両方の伝説的なゲームのラベルに属していてもよいです。
最も人気の理解二分、マルチマルチラベル分類・表示方法は、多くの場合、子供の試験問題私たちの作業になることがあります。二つの分類は、私たちが真または偽の質問、複数の選択肢（つ以上の候補者）、及びマルチタグ付けモデルに対応する複数の分類器、対応する複数の選択肢の質問を行い対応するが、ここではマルチタグ若干異なっていることができますタグ付けモデルが選択することはできません。小さなパートナーは、違いを理解し、この例を介してそれらを連絡することができます。
マルチタグ付けモデルを使用する利点は、我々は、データソースをフルに活用することができ、また、モデリングの効率を向上させることができるだけでなく、複数のタグを特定のモデルを構築することができるということです。不利な点は、マルチタグの評価モデルは、2つの分類として良いようではないかもしれないということです。これは非常に簡単に理解することは実際にあるので、あなたは、複数の選択肢と真偽の質問を行い、ほとんどの人はそれを行うには良い判断ポイントのタイトルです。
実際のプロジェクトは、一般的に、バイナリと複数のタグ付けモデルの両方を使用します。元のユーザークエリのための3つの人気の2つの分類に通して濾過することができます。3つの一般的なデータ品質の注釈データのリフトウェルの濾過後。スリー人気のデータモデリングは、対象それ自体に意味がありません。フィルタがなければ、ラベルデータの効率を低下させます。例えば、ユーザは今、クエリデータ10Wをマークする必要があります。10Wのデータは通常、3つの一般データで20％以上でドープされます。我々はより多くのフィルタリングこれらのデータの2Wより進めることができる3つの人気の2分類することで、その後、唯一のチームの残りの部分はマークの20％以上の効率を高めるために、8Wデータをラベル提出する必要があります。
人気の3は、ユーザーのクエリデータは、個々のカテゴリを分類するために、マルチラベルラベリングモデルのカテゴリに基づいて分類器を構築した後、最後のテキスト認識は、さまざまなビジネスニーズに応じて行われます。ここではいくつかのマルチタグ付けモデルは、いくつかのラベルでは満足のいくものではないために少しトリックは両方とも効率的なマルチタギングモデルを楽しむことができ、分類器は、2つの高を楽しむことができるように、2つの分類で識別に焦点を合わせることができるさ精度。下に示すように、ポリシーを使用して、特定のアイテム。
03 BERTビルドマルチモデルの戦闘タギング
モデルによるマルチタギングBERTモデルの構築。ここではgithubのプロジェクトへのリンクは次のとおりです。
https://github.com/wilsonlsm006/NLP_BERT_multi_label。また、小型のパートナーにフォークの多くは、私に多くの注目を歓迎しています。
プロジェクトのディレクトリ構造は次のとおりです。
そして、2つの類似した分類モデルは、マルチタギングプロジェクトは4つの部分に分かれています。
1. BERT事前トレーニングモデル
第二のキャンペーンは、BERTは微調整の事前研修+ 2段階モデルであると述べています。事前トレーニングプロセスは、我々はBERTモデルは言語知識の多くを学ぶためにそうすることを、トレーニングコーパスを大量に使用したテキストと同等であることをここで簡単な言及。この部分は言語知識を得、関連するパラメータを学習しています。
TensorFlowグーグルkeras_bertの2に基づいて使用する分類器モデルの前に二つのフレーム分類器を完了しました。このマルチタギングモデルはpytorchフレームワークfast_aiに基づいているので、バックにゆっくりと移行のpytorchフレームワークへの実際のプロジェクトでは、開発を完了したので。私たちのNLPタスクのBERTモデルをすることができ、非常に単純なコード構造を使用してfast_ai同様のkeras_bert、。
Pytorch BERTモデルは、ルートの各バージョンを変換し、次のアドレスをダウンロードされます。
- BERT-ベースuncased https://s3.amazonaws.com/models.huggingface.co/bert/bert-base-uncased.tar.gz
- BERT-大uncased
https://s3.amazonaws.com/models.huggingface.co/bert/bert-large-uncased.tar.gz - BERT-ベースケース入り
https://s3.amazonaws.com/models.huggingface.co/bert/bert-base-cased.tar.gz - BERT塩基多言語
https://s3.amazonaws.com/models.huggingface.co/bert/bert-base-multilingual.tar.gz - BERT-ベース-中国
https://s3.amazonaws.com/models.huggingface.co/bert/bert-base-chinese.tar.gz
私は私達の前のトレーニングモデルの一部として「BERT塩基中国の」BERT最後の1を選んだので、実際のプロジェクトなので、私たちは主に、中国を認識しています。ダウンロードbert_config.jsonとpytorch_model.bin 2つのファイルが解凍が完了した後になり、その後、bert_modelディレクトリvocab.txtたちの語彙に添加する前に一緒にコピーします。このプロセスを完了することができます。
2.トレーニングデータセット
二分モデル入力データフォーマットは、ラベルスタイルOCRである前に、我々は言いました。ユーザーのクエリOCRでなく、私たちは、目標を特定する必要があります。ラベルには、フレーズのクエリが特定のタグには興味がない表し、値が0または1、1金利の代表である、無利子のための0。
複数のタスクタグ付け、データ入力フォーマットは、2つの部分に分け、最初の部分は、OCRであり、我々は、ユーザクエリを識別する必要があります。複数のフィールドの第2の部分は、いくつかの識別タグを必要とする、いくつかのフィールドがあります。たとえば、私たちは今、ユーザーのクエリは、5つのタブの一部ではありません特定する必要があります。だから今、私たちはトレーニングセットフォーマットは、OCR、lable1、LABEL2、LABEL3、Label4から、label5である持っています。例えば、実際のデータを次のように
「どのような楽しい伝説のナイフのジャッキーの裏書？」1,0,0,1,1。このデータは、このタグ1、タグラベル4と5に属するユーザクエリを表します。
トレーニングとテストセットに設定されたデータをトレーニング。私たちは、トレーニングモデルのトレーニングを完了するために、鉄道模型セットを使用します。そして、モデル検査のセットを識別するための訓練を受けた能力をテストするには、このモデルを使用しています。ここで、トレーニングおよびテストセットはそうある程度ライン後のモデルの認識を反映するためにテストセットの効果を見て、完全に相互に排他的です。試験データセットとデータ分配ラインが異なるかもしれないので、そうテストセットの効果と異なる線の影響であってもよいです。
3.モデルコードとスクリプト
プロジェクトの2つのだけ分類コードの前に。文字を変更する必要があり、多くの小さなプライベートのパートナーは、トレーニング、検証およびテスト工程における反応パラメータは、あまりにも面倒であると述べました。ここでは、マルチタグモデルのシェルスクリプトによってこの問題を解決することができるのpythonコードを呼び出します。長い上記データ入力形式と同じと同じ話します。あなただけがモデルを完了するために、さまざまなタスクのためのシェルスクリプトを変更する必要があります。
モデルのコードは、3つの部分に分かれています。
multi_label_train.py：モデル訓練コード。
ここでは詳細にモデルの訓練ミッションを使用することにより、入力と出力モデルトレーニング、特定のスクリプトコードを説明するためのものです。対応train_multi_tag.shスクリプト：
入力：事前に訓練を受けたモデルとトレーニングセットを必要とするモデル訓練BERT、パラメータは、トレーニングデータパスTRAIN_DATAパスと事前に訓練されたBERTタスクBERT_MODEL_NAMEで構成します
出力は：あなたはパラメータがMODEL_SAVE_PATHを持って設定する必要がありますので、 '、研修終了後のxxxx.pthモデルファイルを取得するでしょう。モデルのトレーニング段階は、より多くの数回を訓練することができるので、彼らは別のストレージ・モデルを必要とするので、この実験はLAB_FLAGを構成することによって識別されます。
ミッションを訓練開始train_multi_tag.sh直接SHによってのみ、サーバー内の特定のモデルのトレーニング。
multi_label_validate.py：モデル検証コード。
モデルの検証は、モデルの効果を検証するため、私たちは主に、F1スコア精度、高精度、リコールを使用してモデルを評価するための主要な指標の一部です。
入力：モデルの検証ニーズに訓練された取得するためにモデルのセットとテストプロセス。TEST_DATAとMODEL_LOAD_PATH対応するスクリプト設定するためのパラメータがあります。
出力：モデル予測データとテストセットのインデックスデータモデル、および対応するスクリプトTEST_PREDICT_DATA MODEL_EVALUATE_DATAの出力。
multi_label_predict.py：モデル予測コード。
モデル全体の開発が完了した後、我々は最終的なモデルを得るために、モデルを訓練するために新しいトレーニングセットと同時にトレーニングおよびテストセットを使用します。また、このモデルでは、ラインの稼働を取得する予定です。
入力：これは、データモデルとオンライン予測のための本当の必要性、および対応するスクリプトTEST_DATA MODEL_LOAD_PATHを結果する必要があります。
出力：予測ラインの出力部には、真の予測結果データ、対応するスクリプトTEST_PREDICT_DATAパラメータです。
得られたトレーニングモデル4.完了
トレーニングプロセスのこの部分は、上記の結果です。私たちは、訓練を受けた上で、オンライン予測のラインデータを展開するために、このモデルを使用する必要があります。ここでは2つの異なる分類の前に、2つの分類器が取得XX.hdf5ファイルで、マルチタギング結果として得られるモデルはXX.pthファイルです。他のバイナリが類似している前に、ここではそれらを繰り返すないについて話しました。
要約下で、我々は、モデルからモデル検証の訓練に、そして最終的にオンライン予測プロセスに、プロジェクトの戦闘をタグ付けすることによって、複数のモデルを完了しました。ユニバーサルモデルが強い、我々はオンラインのみですぐに完了したタスクにスクリプトコードを変更する必要があります。
概要および予測
実際のプロジェクトからBenpianの出発は、複数のタグ付けモデルを完了しました。実際のテキスト分類タスクは、我々はまた、複数のタグ付けモデルと特定のビジネスニーズに基づいて2つの分類器を使用します。NLPタスクと伝統的な機械学習タスクが異なるため、我々はそうではないプロジェクトの、あまりにも多くの機能を必要とするが、それは前のテキストコーパスのために非常に重要です。また、また、非常にトリッキーなサンプルを選択しました。私たちは、ビジネスの実際のニーズに基づいてモデルを調整するために、経験を蓄積し続けなければなりません。
ピックアップによってデータ：小さなパートナーのこのタイプのような記事は私のマイクロチャネル公共数に焦点を当てることができます。私は最初の公開のマイクロチャンネル番号にリリースされる任意の乾燥は、またほとんどの同期、見出し、ジェーンの本、CSDNプラットフォームで知られています。小さなパートナーはまた、より多くの交流を歓迎します。質問があれば、私はカザフスタンの数は常にQマイクロ手紙公衆ことができます。
