Learn more about Search Results モード - Page 55

私たちは、オープンかつ協力的な機械学習のために1億ドルを調達しました 🚀

今日は、素晴らしいニュースをお伝えします！Hugging Faceは、Lux CapitalをリードとするシリーズCの資金調達で1億ドルを調達しました🔥🔥🔥。Sequoia、Coatue、そして既存の投資家であるAddition、a_capital、SV Angel、Betaworks、AIX Ventures、Kevin Durant、Thirty Five VenturesのRich Kleiman、Datadogの共同設立者兼CEOであるOlivier Pomelなどが主要な出資者となっています。 2018年にPyTorch BERTをオープンソース化して以来、私たちは長い道のりを歩んできましたが、まだ始まったばかりです！🙌 機械学習は、技術を構築するためのデフォルトの方法になりつつあります。1日の平均を考えてみると、機械学習はあらゆるところにあります：Zoomの背景、Googleでの検索、Uberの利用、オートコンプリート機能を使用したメールの作成など、すべてが機械学習です。 Hugging Faceは、現在最も急成長しているコミュニティであり、機械学習のための最も使用されているプラットフォームです！自然言語処理、コンピュータビジョン、音声、時系列、生物学、強化学習、化学などのための100,000以上の事前学習モデルと10,000以上のデータセットをホストしており、Hugging Face Hubは、最先端のモデルを作成、共同作業、展開するための機械学習のホームとなっています。 10,000以上の企業がHugging Faceを使用して機械学習による技術を構築しています。彼らの機械学習科学者、データサイエンティスト、機械学習エンジニアは、私たちの製品とサービスの助けを借りて、数え切れないほどの時間を節約し、機械学習のロードマップを加速させています。 私たちはAI分野にポジティブな影響を与えたいと考えています。より責任あるAIの進展は、モデル、データセット、トレーニング手順、評価指標をオープンに共有し、問題を解決するために協力することを通じて実現されると考えています。オープンソースとオープンサイエンスは、信頼性、堅牢性、再現性、継続的なイノベーションをもたらします。これを念頭に、私たちはBigScienceをリードしています。これは、1,000人以上の研究者が集まり、非常に大きな言語モデルの研究と作成を行う協力的なワークショップです。そして、私たちは現在、世界最大のオープンソースの多言語言語モデルのトレーニングを行っています🌸 ⚠️ しかし、まだ大量の作業が残されています。 Hugging Faceでは、機械学習にはバイアス、プライバシー、エネルギー消費などの重要な制約と課題があることを認識しています。オープンさ、透明性、協力を通じて、これらの課題を緩和するための責任ある包括的な進歩、理解、および説明責任を促進することができます。…

最適なパイプラインとトランスフォーマーパイプラインによる高速推論

推論は、Hugging Face TransformersパイプラインをサポートしてOptimumに追加されました。これには、ONNX Runtimeを使用したテキスト生成も含まれます。 BERTとTransformersの採用はますます拡大しています。Transformerベースのモデルは、自然言語処理だけでなく、コンピュータビジョン、音声、時間系列でも最先端の性能を発揮しています。💬 🖼 🎤 ⏳ 企業は、Transformerモデルを大規模なワークロードに使用するため、実験および研究フェーズから本番フェーズに移行しています。ただし、デフォルトでは、BERTおよびその関連製品は、従来の機械学習アルゴリズムと比較して、比較的遅くて大きくて複雑なモデルです。 この課題を解決するために、私たちはOptimumを作成しました。これは、BERTなどのTransformerモデルのトレーニングと推論を高速化するためのHugging Face Transformersの拡張機能です。 このブログ投稿では、次のことを学びます： 1. Optimumとは何ですか？ELI5 2. 新しいOptimum推論とパイプラインの機能 3. RoBERTaの質問応答を加速するためのエンドツーエンドチュートリアル、量子化、最適化を含む 4. 現在の制限事項 5. Optimum推論FAQ 6.…

機械学習の専門家 – Sasha Luccioni

🤗 マシンラーニングエキスパートへようこそ – サーシャ・ルッチョーニ 🚀 サーシャのようなMLエキスパートがあなたのMLロードマップを加速する方法に興味がある場合は、hf.co/supportを訪れてください。 こんにちは、友達たち！マシンラーニングエキスパートへようこそ。私は司会者のブリトニー・ミュラーで、今日のゲストはサーシャ・ルッチョーニです。サーシャは、Hugging Faceで研究科学者として、機械学習モデルとデータセットの倫理的・社会的影響に取り組んでいます。 サーシャはまた、Big Science WorkshopのCarbon Footprint WGの共同議長、WiMLの理事、そして気候危機に機械学習を適用する意義のある活動を促進するClimate Change AI（CCAI）組織の創設メンバーでもあります。 サーシャがメールの炭素フットプリントを計測する方法、地元のスープキッチンが機械学習の力を活用するのをどのように手助けしたか、そして意味と創造性が彼女の仕事を支える方法についてお話しいただきます。 この素晴らしいエピソードを紹介するのをとても楽しみにしています！以下がサーシャ・ルッチョーニとの私の対話です： 注：転記はわかりやすい読み物を提供するためにわずかに修正/書式設定されています。 今日参加していただき、本当にありがとうございます。私たちはあなたが来てくれたことを非常に嬉しく思っています！ サーシャ： 私もここにいることを本当に嬉しく思っています。 直接本題に入りますが、あなたのバックグラウンドとHugging Faceへの道を教えていただけますか？ サーシャ：…

TensorFlowとXLAを使用した高速なテキスト生成

TL;DR : TensorFlowを使用した🤗transformersを使ったテキスト生成は、XLAでコンパイルできるようになりました。これにより、以前よりも最大100倍高速化され、PyTorchよりもさらに高速になりました – 以下のコラボをチェックしてください！ テキスト生成 大規模言語モデルの品質が向上するにつれて、そのモデルができることに対する私たちの期待も高まりました。特にOpenAIのGPT-2のリリース以来、テキスト生成機能を持つモデルが注目されています。そして、その理由は妥当です – これらのモデルは要約、翻訳、さらにはいくつかの言語タスクでのゼロショット学習能力のデモンストレーションを行うことができます。このブログ記事では、TensorFlowを使用してこのテクノロジーを最大限に活用する方法を紹介します。 🤗transformersライブラリはNLPモデルから始まりましたので、テキスト生成は私たちにとって非常に重要な要素です。アクセス可能で、簡単に制御可能で効率的であることをHugging Faceの民主化の取り組みの一環として保証することが目的です。テキスト生成のさまざまなタイプについては以前のブログ記事があります。ただし、以下にコア機能のクイックな概要があります – 私たちのgenerate関数に慣れている場合や、TensorFlowの特異性に直接ジャンプしたい場合は、スキップしても構いません。 まずは基本から始めましょう。テキスト生成は、do_sampleフラグによって確定的または確率的になります。デフォルトでは、Falseに設定されており、出力は確定的であるため、Greedy Decodingとも呼ばれます。それをTrueに設定すると、サンプリングとも呼ばれるため、出力は確率的になりますが、seed引数（stateless TensorFlowのランダム数生成と同じ形式）を介して再現可能な結果を得ることもできます。一般的なガイドラインとして、モデルから事実情報を得る場合は確定的な生成を、よりクリエイティブな出力を目指す場合は確率的な生成を望むでしょう。 # transformers >= 4.21.0が必要です # サンプリングの出力は、使用するハードウェアによって異なる場合があります。 from transformers…

TF Servingを使用してKubernetes上に🤗 ViTをデプロイする

前の投稿では、TensorFlow Servingを使用して🤗 TransformersからVision Transformer（ViT）モデルをローカルに展開する方法を示しました。ビジョントランスフォーマーモデル内での埋め込み前処理および後処理操作、gRPCリクエストの処理など、さまざまなトピックをカバーしました！ ローカル展開は、有用なものを構築するための優れたスタート地点ですが、実際のプロジェクトで多くのユーザーに対応できる展開を実行する必要があります。この投稿では、前の投稿のローカル展開をDockerとKubernetesでスケーリングする方法を学びます。したがって、DockerとKubernetesに関する基本的な知識が必要です。 この投稿は前の投稿に基づいていますので、まずそれをお読みいただくことを強くお勧めします。この投稿で説明されているコードは、このリポジトリで確認することができます。 私たちの展開をスケールアップする基本的なワークフローは、次のステップを含みます： アプリケーションロジックのコンテナ化：アプリケーションロジックには、リクエストを処理して予測を返すサービスモデルが含まれます。コンテナ化するために、Dockerが業界標準です。 Dockerコンテナの展開：ここにはさまざまなオプションがあります。最も一般的に使用されるオプションは、DockerコンテナをKubernetesクラスターに展開することです。Kubernetesは、展開に便利な機能（例：自動スケーリングとセキュリティ）を提供します。ローカルでKubernetesクラスターを管理するためのMinikubeのようなソリューションや、Elastic Kubernetes Service（EKS）のようなサーバーレスソリューションを使用することもできます。 SagemakerやVertex AIのような、MLデプロイメント固有の機能をすぐに利用できる時代に、なぜこのような明示的なセットアップを使用するのか疑問に思うかもしれません。それは考えるのは当然です。 上記のワークフローは、業界で広く採用され、多くの組織がその恩恵を受けています。長年にわたってすでに実戦投入されています。また、複雑な部分を抽象化しながら、展開に対してより細かな制御を持つことができます。 この投稿では、Google Kubernetes Engine（GKE）を使用してKubernetesクラスターをプロビジョニングおよび管理することを前提としています。GKEを使用する場合、請求を有効にしたGCPプロジェクトが既にあることを想定しています。また、GKEで展開を行うためにgcloudユーティリティを構成する必要があります。ただし、Minikubeを使用する場合でも、この投稿で説明されているコンセプトは同様に適用されます。 注意：この投稿で表示されるコードスニペットは、gcloudユーティリティとDocker、kubectlが構成されている限り、Unixターミナルで実行できます。詳しい手順は、付属のリポジトリで入手できます。 サービングモデルは、生のイメージ入力をバイトとして処理し、前処理および後処理を行うことができます。 このセクションでは、ベースのTensorFlow Servingイメージを使用してそのモデルをコンテナ化する方法を示します。TensorFlow Servingは、モデルをSavedModel形式で消費します。前の投稿でSavedModelを取得した方法を思い出してください。ここでは、SavedModelがtar.gz形式で圧縮されていることを前提としています。万が一必要な場合は、ここから入手できます。その後、SavedModelは<MODEL_NAME>/<VERSION>/<SavedModel>という特別なディレクトリ構造に配置する必要があります。これにより、TensorFlow Servingは異なるバージョンのモデルの複数の展開を同時に管理できます。 Dockerイメージの準備…

Hugging Face TransformersとHabana Gaudiを使用して、BERTを事前に学習する

このチュートリアルでは、Habana GaudiベースのDL1インスタンスを使用してBERT-baseをゼロから事前トレーニングする方法を学びます。Gaudiのコストパフォーマンスの利点を活用するためにAWSで使用します。Hugging Face Transformers、Optimum Habana、およびDatasetsライブラリを使用して、マスクされた言語モデリングを使用してBERT-baseモデルを事前トレーニングします。これは、最初のBERT事前トレーニングタスクの一つです。始める前に、ディープラーニング環境をセットアップする必要があります。 コードを表示する 以下のことを学びます： データセットの準備 トークナイザのトレーニング データセットの前処理 Habana Gaudi上でBERTを事前トレーニングする 注意：ステップ1から3は、CPUを多く使用するタスクのため、異なるインスタンスサイズで実行することができます/すべきです。 要件 始める前に、以下の要件を満たしていることを確認してください DL1インスタンスタイプのクオータを持つAWSアカウント AWS CLIがインストールされていること AWS IAMユーザーがCLIで構成され、ec2インスタンスの作成と管理の権限を持っていること 役立つリソース Hugging Face TransformersとHabana…

Megatron-LMを使用して言語モデルをトレーニングする方法

PyTorchで大規模な言語モデルをトレーニングするには、単純なトレーニングループだけでは不十分です。通常、複数のデバイスに分散しており、安定した効率的なトレーニングのための多くの最適化技術があります。Hugging Face 🤗 Accelerateライブラリは、トレーニングループに非常に簡単に統合できるように、GPUとTPUを跨いで分散トレーニングをサポートするために作成されました。🤗 TransformersもTrainer APIを介して分散トレーニングをサポートしており、トレーニングループの実装を必要とせずにPyTorchでの完全なトレーニングを提供します。 大規模なトランスフォーマーモデルを事前トレーニングするための研究者の間でのもう一つの人気ツールはMegatron-LMです。これはNVIDIAのApplied Deep Learning Researchチームによって開発された強力なフレームワークです。🤗 AccelerateとTrainerとは異なり、Megatron-LMの使用は直感的ではなく、初心者には少し抵抗があるかもしれません。しかし、これはGPU上でのトレーニングに最適化されており、いくつかの高速化を提供することができます。このブログ記事では、Megatron-LMを使用してNVIDIAのGPU上で言語モデルをトレーニングし、それをtransformersと一緒に使用する方法を学びます。 このフレームワークでGPT2モデルをトレーニングするためのさまざまなステップを紹介します。これには以下が含まれます。 環境のセットアップ データの前処理 トレーニング モデルの🤗 Transformersへの変換 なぜMegatron-LMを選ぶのか？ トレーニングの詳細に入る前に、他のフレームワークよりもこのフレームワークが効率的である理由を理解しましょう。このセクションは、Megatron-DeepSpeedでのBLOOMトレーニングについての素晴らしいブログから着想を得ています。詳細については参照してください。このブログ記事はMegatron-LMへの優しい入門を提供することを目的としています。 データローダー Megatron-LMには、データがトークン化され、トレーニング前にシャッフルされる効率的なデータローダーが付属しています。また、データは番号付きのシーケンスに分割され、それらは計算が必要な場合にのみ計算されるようにインデックスで保存されます。インデックスを作成するために、エポック数はトレーニングパラメータに基づいて計算され、順序が作成され、その後シャッフルされます。これは通常の場合とは異なり、データセット全体を繰り返し処理してから2番目のエポックのために繰り返すというものです。これにより、学習曲線が滑らかになり、トレーニング中の時間が節約されます。 組み込みCUDAカーネル GPU上で計算を実行する場合、必要なデータはメモリから取得され、計算が実行され、結果がメモリに保存されます。簡単に言えば、組み込みカーネルのアイデアは、通常はPyTorchによって別々に実行される類似の操作を、単一のハードウェア操作に統合することです。そのため、複数の個別の計算で行われるメモリ移動の回数を減らします。以下の図は、カーネルフュージョンのアイデアを示しています。これは、詳細について説明しているこの論文からインスピレーションを受けています。 f、g、hが1つのカーネルで結合された場合、fとgの中間結果x’とy’はGPUレジスタに保存され、hによって即座に使用されます。しかし、フュージョンがない場合、x’とy’はメモリにコピーされ、hによって読み込まれる必要があります。したがって、カーネルフュージョンは計算に著しいスピードアップをもたらします。Megatron-LMはまた、PyTorchの実装よりも高速なApexのFused…

DeepSpeedとAccelerateを使用した非常に高速なBLOOM推論

この記事では、176BパラメータのBLOOMモデルを使用してトークンごとのスループットを非常に高速に取得する方法を紹介します。 モデルは352GBのbf16（bfloat16）ウェイト（176*2）を必要とするため、最も効率的なセットアップは8x80GBのA100 GPUです。また、2x8x40GBのA100または2x8x48GBのA6000も使用できます。これらのGPUを使用する主な理由は、この執筆時点ではこれらのGPUが最大のGPUメモリを提供しているためですが、他のGPUも使用できます。たとえば、24x32GBのV100を使用することもできます。 単一のノードを使用すると、通常、最速のスループットが得られます。なぜなら、ほとんどの場合、ノード内のGPUリンクハードウェアの方がノード間のものよりも速いためですが、常にそうとは限りません。 もしハードウェアがそれほど多くない場合でも、CPUやNVMeのオフロードを使用してBLOOM推論を実行することは可能ですが、もちろん、生成時間は遅くなります。 また、GPUメモリの半分の容量を必要とする8ビット量子化ソリューションについても説明します。これにはBitsAndBytesとDeepspeed-Inferenceライブラリが必要です。 ベンチマーク さらなる遅延なしでいくつかの数値を示しましょう。 一貫性を保つために、この記事のベンチマークはすべて同じ8x80GBのA100ノードで実行され、512GBのCPUメモリを持つJean Zay HPCで行われました。JeanZay HPCのユーザーは、約3GB/sの読み取り速度（GPFS）で非常に高速なIOを利用しています。これはチェックポイントの読み込み時間に重要です。遅いディスクは読み込み時間が遅くなります。特に複数のプロセスでIOを同時に行っている場合はさらに重要です。 すべてのベンチマークは、100トークンの出力を貪欲に生成しています： Generate args {'max_length': 100, 'do_sample': False} 入力プロンプトはわずかなトークンで構成されています。以前のトークンのキャッシュもオンになっています。常にそれらを再計算すると非常に遅くなるためです。 まず、生成の準備が完了するまでにかかった時間（つまり、モデルの読み込みと準備にかかった時間）を見てみましょう： Deepspeed-Inferenceには、事前にシャードされたウェイトリポジトリが付属しており、読み込みに約1分かかります。Accelerateの読み込み時間も優れており、わずか2分です。他のソリューションはここでははるかに遅いです。 読み込み時間は重要であるかどうかは、一度読み込んだら追加の読み込みオーバーヘッドなしに繰り返しトークンを生成できるため、場合によります。 次に、トークン生成の最も重要なベンチマークです。ここでのスループット指標は単純であり、100個の新しいトークンを生成するのにかかった時間を100で割り、バッチサイズで割ったものです。…

最適化ストーリー：ブルーム推論

この記事では、bloomをパワーアップする効率的な推論サーバーの裏側について説明します。 数週間にわたり、レイテンシーを5倍削減し（スループットを50倍に増やしました）、このような速度向上を達成するために私たちが経験した苦労やエピックな勝利を共有したかったです。 さまざまな人々が多くの段階で関与していたため、ここではすべてをカバーすることはできません。また、最新のハードウェア機能やコンテンツが定期的に登場するため、一部の内容は古くなっているか、まったく間違っている可能性があることをご了承ください。 もし、お好みの最適化手法が議論されていなかったり、正しく表現されていなかったりした場合は、お詫び申し上げます。新しいことを試してみたり、間違いを修正するために、ぜひお知らせください。 言うまでもなく、まず大きなモデルが最初にアクセス可能でなければ、それを最適化する理由はありません。これは、多くの異なる人々によってリードされた信じられないほどの取り組みでした。 トレーニング中にGPUを最大限に活用するために、いくつかの解決策が検討され、結果としてMegatron-Deepspeedが最終的なモデルのトレーニングに選ばれました。これは、コードがそのままではtransformersライブラリと互換性がない可能性があることを意味します。 元のトレーニングコードのため、通常行っていることの1つである既存のモデルをtransformersに移植することに取り組みました。目標は、トレーニングコードから関連する部分を抽出し、transformers内に実装することでした。この取り組みには「Younes」が取り組みました。これは、1ヶ月近くかかり、200のコミットが必要でした。 後で戻ってくるいくつかの注意点があります: 小さなモデルbigscience/bigscience-small-testingとbigscience/bloom-560mを用意する必要があります。これは非常に重要です。なぜなら、それらと一緒に作業するとすべてが高速化されるからです。 まず、最後のログがバイトまで完全に同じになることを望むことをあきらめる必要があります。PyTorchのバージョンがカーネルを変更し、微妙な違いを導入する可能性があり、異なるハードウェアでは異なるアーキテクチャのため異なる結果が得られる場合があります（コストの理由から常にA100 GPUで開発したくはないでしょう）。 すべてのモデルにとって、良い厳格なテストスイートを作ることは非常に重要です 私たちが見つけた最高のテストは、固定された一連のプロンプトを持つことでした。プロンプトを知っており、決定論的な結果が得られる必要があります。2つの生成物が同じであれば、小さなログの違いは無視できます。ドリフトが見られるたびに調査する必要があります。それは、あなたのコードがやるべきことをしていないか、または実際にそのモデルがドメイン外であるためにノイズに対してより敏感であるかのいずれかです。いくつかのプロンプトと十分に長いプロンプトがあれば、すべてのプロンプトを誤ってトリガーする可能性は低くなります。プロンプトが多ければ多いほど良く、プロンプトが長ければ長いほど良いです。 最初のモデル（small-testing）は、bloomと同じようにbfloat16であり、すべてが非常に似ているはずですが、それほどトレーニングされていないか、うまく機能しないため、出力が大きく変動します。そのため、これらの生成テストに問題がありました。2番目のモデルはより安定していましたが、bfloat16ではなくfloat16でトレーニングおよび保存されていました。そのため、2つの間にはエラーの余地があります。 完全に公平を期すために言えば、bfloat16→float16への変換は推論モードでは問題なさそうです（bfloat16は主に大きな勾配を扱うために存在しません）。 このステップでは、重要なトレードオフが発見され、実装されました。bloomは分散環境でトレーニングされたため、一部のコードはLinearレイヤー上でテンソル並列処理を行っており、単一のGPU上で同じ操作を実行すると異なる結果が得られていました。これを特定するのにかなりの時間がかかり、100％の準拠を選択した場合、モデルの速度が遅くなりましたが、少しの差がある場合は実行が速く、コードがシンプルになりました。設定可能なフラグを選択しました。 注：この文脈でのパイプライン並列処理（PP）は、各GPUがいくつかのレイヤーを所有し、各GPUがデータの一部を処理してから次のGPUに渡すことを意味します。 これで、動作可能なtransformersのクリーンなバージョンがあり、これに取り組むことができます。 Bloomは352GB（176Bパラメーターのbf16）のモデルであり、それに合わせるために少なくともそれだけのGPU RAMが必要です。一時的に小さなマシンでCPUにオフロードすることを検討しましたが、推論速度が桁違いに遅くなるため、それを取り下げました。 次に、基本的にはパイプラインを使用したかったのです。つまり、ドッグフーディングであり、これがAPIが常に裏で使用しているものです。 ただし、pipelinesは分散意識がありません（それがその目的ではありません）。オプションを簡単に話し合った後、新しく作成されたdevice_map="auto"を使用してモデルのシャーディングを管理するためにaccelerateを使用することにしました。いくつかのバグを修正し、transformersのコードを修正してaccelerateが正しい仕事をするのを助ける必要がありました。 これは、transformersのさまざまなレイヤーを分割し、各GPUにモデルの一部を与えて動作させることで機能します。つまり、GPU0が作業を行い、次にGPU1に引き渡し、それ以降同様に行います。 最終的には、上に小さなHTTPサーバーを置くことで、bloom（大規模なモデル）を提供できるようになりました！…

🤗変換器を使用した確率的な時系列予測

はじめに 時系列予測は重要な科学的およびビジネス上の問題であり、従来の手法に加えて、深層学習ベースのモデルの使用により、最近では多くのイノベーションが見られています。ARIMAなどの従来の手法と新しい深層学習手法の重要な違いは、次のとおりです。 確率予測 通常、従来の手法はデータセット内の各時系列に個別に適合させられます。これらはしばしば「単一」または「ローカル」な手法と呼ばれます。しかし、一部のアプリケーションでは大量の時系列を扱う際に、「グローバル」モデルをすべての利用可能な時系列に対してトレーニングすることは有益であり、これによりモデルは多くの異なるソースからの潜在表現を学習できます。 一部の従来の手法は点値（つまり、各時刻に単一の値を出力するだけ）であり、モデルは真のデータに対するL2またはL1タイプの損失を最小化することによってトレーニングされます。しかし、予測はしばしば実世界の意思決定パイプラインで使用されるため、人間が介在していても、予測の不確実性を提供することははるかに有益です。これは「確率予測」と呼ばれ、単一の予測とは対照的です。これには、確率分布をモデル化し、そこからサンプリングすることが含まれます。 つまり、ローカルな点予測モデルをトレーニングする代わりに、グローバルな確率モデルをトレーニングすることを望んでいます。深層学習はこれに非常に適しており、ニューラルネットワークは複数の関連する時系列から表現を学習することができ、データの不確実性もモデル化できます。 確率的設定では、コーシャンまたはスチューデントTなどの選択したパラメトリック分布の将来のパラメータを学習するか、条件付き分位関数を学習するか、または時系列設定に適応させたコンフォーマル予測のフレームワークを使用することが一般的です。選択した方法はモデリングの側面に影響を与えないため、通常は別のハイパーパラメータと考えることができます。確率モデルを経験的平均値や中央値による点予測モデルに変換することも常に可能です。 時系列トランスフォーマ 時系列データをモデリングする際に、その性質上、研究者はリカレントニューラルネットワーク（RNN）（LSTMやGRUなど）、畳み込みネットワーク（CNN）などを使用したモデル、および最近では時系列予測の設定に自然に適合するトランスフォーマベースの手法を開発しています。 このブログ記事では、バニラトランスフォーマ（Vaswani et al., 2017）を使用して、単変量の確率予測タスク（つまり、各時系列の1次元分布を個別に予測）を活用します。エンコーダーデコーダートランスフォーマは予測に適しているため、いくつかの帰納バイアスをうまくカプセル化しています。 まず、エンコーダーデコーダーアーキテクチャの使用は、通常、一部の記録されたデータに対して将来の予測ステップを予測したい場合に推論時に役立ちます。これは、与えられた文脈に基づいて次のトークンをサンプリングし、デコーダーに戻す（「自己回帰生成」とも呼ばれる）テキスト生成タスクに類似して考えることができます。同様に、ここでも、ある分布タイプが与えられた場合、それからサンプリングして、望ましい予測ホライズンまでの予測を提供することができます。これは、NLPの設定についてのこちらの素晴らしいブログ記事に関しても言えます。 第二に、トランスフォーマは、数千の時系列データでトレーニングする際に役立ちます。注意機構の時間とメモリの制約のため、時系列のすべての履歴を一度にモデルに入力することは実現可能ではないかもしれません。したがって、適切なコンテキストウィンドウを考慮し、このウィンドウと次の予測長サイズのウィンドウをトレーニングデータからサンプリングして、確率的勾配降下法（SGD）のためのバッチを構築する際に使用することができます。コンテキストサイズのウィンドウはエンコーダーに渡され、予測ウィンドウは因果マスク付きデコーダーに渡されます。つまり、デコーダーは次の値を学習する際には、前の時刻ステップのみを参照できます。これは、バニラトランスフォーマを機械翻訳のためにトレーニングする方法と同等であり、「教師強制」と呼ばれます。 トランスフォーマのもう一つの利点は、他のアーキテクチャに比べて、時系列の設定で一般的な欠損値をエンコーダーやデコーダーへの追加マスクとして組み込むことができ、インフィルされることなくまたは補完することなくトレーニングできることです。これは、トランスフォーマライブラリのBERTやGPT-2のようなモデルのattention_maskと同等です。注意行列の計算にパディングトークンを含めないようにします。 Transformerアーキテクチャの欠点は、バニラのTransformerの二次計算およびメモリ要件によるコンテキストと予測ウィンドウのサイズの制限です（Tay et al.、2020を参照）。さらに、Transformerは強力なアーキテクチャであるため、他の手法と比較して過学習や偽の相関をより簡単に学習する可能性があります。 🤗 Transformersライブラリには、バニラの確率的時系列Transformerモデルが付属しており、それを単純にTime Series Transformerと呼んでいます。以下のセクションでは、このようなモデルをカスタムデータセットでトレーニングする方法を示します。 環境のセットアップ…

Find the right Blockchain Investment for you

Web 3.0 is coming, whether buy Coins, NFTs or just Coding, everyone can participate.

Advertising with us