JP6792029B2 - 機器修理管理システム、修理方法およびコンピュータ可読媒体 - Google Patents

Description

本発明は、機器修理管理システム、修理方法およびコンピュータ可読媒体の技術に関する。

複雑な機器が故障した場合、故障の原因と、機器を機能状態に戻すための対応する修理処置を判断するのは困難で時間がかかる。さらに、高齢化した技術者がいくつかの業界で労働力を去ると、新しい技術者が失敗の原因を容易に判断するのに十分な経験と失敗を修正するための適切な修理手順を持たないかもしれない知識ギャップが生じることがある。

本発明の目的は、機器の修理を実施するために保守要員に指示を提供する機器修理管理システム、修理方法およびコンピュータ可読媒体を提供することにある。

また、本発明の他の目的は、機器に直接修理を実施するように機器に指示を提供することができる機器修理管理システム、修理方法およびコンピュータ可読媒体を提供することにある。

上記課題を解決する本発明のシステムの一例は、一つ以上のプロセッサと、実行可能命令を保持し、プロセッサによって実行されるとき、プロセッサが以下の動作を実行するよう構成された１つまたは複数の非一時的コンピュータ可読媒体とを有するシステムにおいて、プロセッサは、第１の機器の過去の修理履歴データを受信し、第１の機器の修理履歴データから、第１の機器に関するコメントに関連付けられたフリーテキストの変数、第１の機器に関連する使用属性、第１の機器に関連する機器属性、第１の機器に関連するセンサデータ、及び、第１の機器に関連するイベントデータの内の少なくとも一つを、トレーニングデータとして特徴を抽出し、修理履歴データから、第１の機器に対する複数の修理レベルを含む修理階層を決定し、トレーニングデータを使用して、修理階層の個々のレベルを予測するために複数のタスクを実行するようにトレーニングされた多層モデルとして、ディープラーニングモデルをトレーニングし、第２の機器に関連した修理要求を受信し、受信した修理要求に基づいて少なくとも１つの修理動作を決定するためにディープラーニングモデルを使用する。

つまり、本発明のシステムの一例は、修理動作を決定するために機械学習モデルをトレーニングし使用するための構成および技法を含む。いくつかの例では、コンピュータシステムは、第１の機器に関する修理履歴データを受信し、トレーニングデータとして第１の機器に関する修理履歴データから特徴を抽出する。トレーニングデータは以下の一つ又は複数を含む。第１の機器に関するコメントに関連付けられたフリーテキスト変数を含む最初の機器に関連する使用属性、第１の機器に関連する機器属性、第１の機器に関連するセンサデータ、または最初の機器に関連するイベントデータ。システムは、機器に対する複数の修理レベルを含む修理階層を決定することができる。システムは、修理階層の個々のレベルを予測するために複数のタスクを実行するようにトレーニングされた多層モデルとして機械学習モデルをトレーニングするためにトレーニングデータを使用することができる。システムは、第２の機器に関連する修理要求を受信することができ、受信した修理要求に基づいて少なくとも１つの修理動作を決定するために機械学習モデルを使用する。

本発明によれば、機器の修理を実施するために保守要員に指示を提供することができ、および／または機器に直接修理を実施するように機器に指示を提供することができる機器修理管理システム、修理方法およびコンピュータ可読媒体を提供することができる。

いくつかの実装に従って修理を決定し実装することができるコンピュータシステムの例示的アーキテクチャを示す図である。 いくつかの実施形態によるモデルトレーニングおよび適用のために実行され得るプロセスを示す３つの例示的なフローチャートである。 いくつかの実装形態による、フリーテキスト変数から特徴を抽出するための例示的なプロセスを示すフローチャートである。 いくつかの実装形態による、フリーテキスト変数から特徴を抽出するための例示的なプロセスを示すフローチャートである。 いくつかの実装に従って機器属性から特徴を抽出するための例示的なプロセスを示すフローチャートである。 いくつかの実装に従って機器属性から特徴を抽出するための例示的なプロセスを示すフローチャートである。 いくつかの実装形態に従って使用属性から特徴を抽出するための例示的なプロセスを示すフローチャートである。 いくつかの実装形態による、センサデータから特徴を抽出するための例示的なプロセスを示すフローチャートである。 いくつかの実装形態による、センサデータから特徴を抽出するための例示的なプロセスを示すフローチャートである。 いくつかの実装によるイベントデータからの特徴の予備的抽出のための例示的なプロセスを示すフローチャートである。 いくつかの実装によるイベントデータからの特徴の予備的抽出のための例示的なプロセスを示すフローチャートである。 いくつかの実装によるイベントデータからの特徴の予備的抽出のための例示的なプロセスを示すフローチャートである。 いくつかの実装によるイベントデータからの特徴の予備的抽出のための例示的なプロセスを示すフローチャートである。 いくつかの実装形態による、イベントデータから抽出された特徴の重要度モデリングのための例示的なプロセスを示すフローチャートである。 いくつかの実装形態による、イベントデータから抽出された特徴の重要度モデリングのための例示的なプロセスを示すフローチャートである。 いくつかの実装形態による、イベントデータから抽出された特徴の重要度モデリングのための例示的なプロセスを示すフローチャートである。 いくつかの実装形態による、イベントデータから抽出された特徴の重要度モデリングのための例示的なプロセスを示すフローチャートである。 いくつかの実装によるモデル構築のための例示的なプロセスを示すフローチャートである。 いくつかの実装によるモデル構築のための例示的なプロセスを示すフローチャートである。 いくつかの実装形態による修理処置を決定し実行するための例示的なプロセスを示すフローチャートである。

詳細な説明は添付の図面を参照して説明される。図において、参照番号の左端の数字は、その参照番号が最初に現れる図を識別する。異なる図における同じ参照番号の使用は、類似または同一の品目または特徴を示す。

本明細書におけるいくつかの実装形態は、機器の故障に続く修理要求の受信に応答してなど、１つまたは複数の修理処置を決定するシステムのための技法および構成を対象としている。本明細書における機器故障の例には、機器を動作させることができないときなどの故障イベント、ならびに機器またはその構成要素のうちの１つの部分動作、非効率動作、あるいは異常動作などのソフト故障が含まれる。本明細書のシステムは、修理を実施するために保守要員に指示を提供することができ、および／または機器に直接修理を実施するように機器に指示を提供することができるデータ駆動型システムを提供することができる。場合によっては、システムは、機器が修理のために持ち込まれるときに修理技術を使用して修理計画を決定することができ、それは修理履歴データを使用してトレーニングされたモデルを使用することを含むことができる。

一例として、システムは入力として（１）機器および機器の作業環境に関するデータ、および（２）修理を必要とする故障に関する機器のユーザからの自然言語の苦情または他のコメントを受け取ることができる。システムは、高次元の疎データ成分および高密度データ成分を含むマルチモーダルデータをモデル化することができる。いくつかの例は、一貫した構造化出力予測のためのトレーニング機構を含み、さらに受け取った自然言語のコメントおよび他の機器データに基づいて機器環境の重要な側面に焦点を合わせるための機構を含み得る。これらのメカニズムおよび技術を使用して、システムは、過去の修理記録およびこれらの修理に関連するデータから一連の修理処置をどのように推奨するかを決定し得る。いくつかの例では、修理計画は、修理業者のコンピューティングデバイスまたは機器自体など、機器の場所への命令として送信され得る。他の例では、システム自体が、機器で修理手順を遠隔で開始すること、修理のために１つまたは複数の部品を注文すること、修理を実行するための労力を割り当てること、修理が行われる時間をスケジューリングすることなどによって修理計画を実行等し得る。したがって、本明細書のシステムは、修理を実施し、機器が使用不能になる時間量を減らし、修理プロセスの効率を高め、そして修理ミスの可能性を減らすことができる。

いくつかの例では、コンピュータシステムは機器の入力データを受け取ることができる。システムは、単語、句、トピック、または他の自由形式のテキストなど、入力データ内の自由形式のテキストを識別および抽出することができる。システムはまた、入力データから複数の他の特徴を抽出することができる。複数の他の特徴の例は、機器属性、使用状況データ、センサデータ、構造化テキスト、イベントデータなどを含み得る。システムは、抽出された特徴を用いて少なくとも１つの機械学習モデルをトレーニングすることができる。システムは、機器に関連する修理要求を受信してもよく、少なくとも１つのトレーニングされた機械学習モデルを使用して、受信した修理要求に基づいて少なくとも１つの修理動作を決定してもよい。

本明細書のシステムのユーザは、機器のエンドユーザおよび／またはオペレータ、修理および保守要員および管理者、そして意思決定者と運用管理者を含むが、これらに限定されない。本明細書のシステムは、スタンドアロンソリューションとして使用することができ、あるいは保守管理および保守の最適化および性能のための他の機能を提供する他の既存のシステムと統合することができる。

説明のために、機器の修理行為および修理計画を決定するコンピュータシステムの環境におけるいくつかの例示的な実装形態について説明する。しかし、本明細書における実装形態は、本明細書の開示に照らして、提供された特定の例に限定されず、当業者には明らかなように、他のタイプの機器、他の使用環境、他のシステムアーキテクチャ、他の用途などに拡張することができる。

図１は、いくつかの実装形態に従って修理を決定し実装することができるコンピュータシステム（以下、システムと呼ぶ場合がある）１００の例示的アーキテクチャを示す。システム１００は、１つまたは複数のデータソース１０４と直接的または間接的に通信することができる少なくとも１つのサービスコンピューティングデバイス１０２を含む。例えば、各データソース１０４は、サービスコンピューティングデバイス１０２に直接接続されたストレージ、１つまたは複数のネットワーク１０６を介して接続された記憶装置、各データソース１０４は、データベース、ネットワーク接続または直接接続のような、サービスコンピューティングデバイス１０２によって使用されるデータの他のデータ構造を維持する別のコンピューティングデバイス（図１には示さず）、クラウドストレージロケーション、または格納されたデータを検索するためにサービスコンピューティングデバイス１０２がアクセスする他のネットワークまたはローカルストレージロケーションであり得る。また、明らかなように、前述の任意の組み合わせ、または任意の様々な他の構成であり得る。本明細書中の開示の恩恵を受ける当業者にとっては、当業者にとって明らかである。したがって、本明細書における実装形態は、データまたはその一部をデータソース１０４に記憶するための任意の特定の記憶装置または技術に限定されない。

データソース１０４は、サービスコンピューティングデバイス１０２によって使用されるデータを受信、格納、提供、またはその他の方法で維持することができる。データソース１０４に含まれるデータの例には、修理履歴データ１０８、機器属性１０９が含まれる。修理履歴データ１０８は、過去に機器に対して行われたメンテナンスおよび他の修理に関するデータを含んでもよい。修理履歴データ１０８は、すべての機器タイプおよび修理タイプについての修理データを含み得る。

機器属性１０９は、修理の対象となる機器の属性を符号化する構造化データを含み得る。例えば、機器の製造元とモデル、製造年、機器とそのコンポーネントの容量と定格が含まれるが、これらに限定されない。例えば、同じ症状の場合、機器の種類が異なれば修理作業も異なる。従って、機器属性１０９は、モデル構築プロセスによって使用されて、問題の症状が与えられた場合に各機器タイプについて正しい修理を決定することができる。この機器属性１０９は、カテゴリ変数として扱われてもよく、高次元かつ疎であってもよい。

加えて、使用データ１１０は、例えば、装置が最初に使用された時からの、装置の動作開始以来の、装置の使用量に関する構造化データを含むことができる。例としては、年齢、営業時間、マイレージ、ペイロードなどである。使用状況データは、修正する問題の症状を考慮して適切な修理処置を決定するのに役立つ。いくつかの例では、使用データ１１０は連続変数として扱われてもよく、高次元かつ高密度の表現であってもよい。

さらに、センサデータ１１１は、機器が故障する前および／または修理のために送られた前などに、１つまたは複数のセンサから収集された時系列データを含むことができる。各時系列は、センサからの信号のサンプルなど、経時的なセンサの読み取り値を表すことができる。各センサデータの読み取りは、センサ信号の読み取りの日時を指定するタイムスタンプと関連付けられてもよい。センサデータ１１１は、連続変数として扱われてもよく、高次元で高密度の表現であってもよい。

さらに、イベントデータ１１２は、機器が故障する前および／または修理のために送られた前などに、機器から収集されたイベントに関する情報を含むことができる。イベントデータ１１２に含まれるイベントは、メンテナンス動作、警報、通知などの異なる種類のイベントを含むことができる。イベントデータ１１２に含まれる各イベントは、イベント発生の日時を指定するタイムスタンプと関連付けられてもよい。ただし、他の例では、タイムスタンプが含まれていない場合がある。したがって、本明細書のシステムは、タイムスタンプの有無にかかわらずイベント情報（例えば、順次依存性）を考慮することができる。イベントデータ１１２は、高次元表現および疎表現であり得る。

ユーザコメントおよび／またはエラーメッセージ１１３は、機器のユーザからの自然言語の苦情または他のコメント、ならびに機器または機器の環境内の他のシステムによって発行された任意のエラーメッセージを含み得る。これらの非構造化データまたは半構造化データは、解決されるべき問題の症状（例えば、「装置の背面からの大きな雑音」、「装置の過熱」など）を記述することができる。ユーザのコメントは、修理プロセスの前または最中に受け取ることができ、タイプ付きテキスト、手書きテキスト、音声メモ、ボイスメールなどを含むがこれらに限定されない様々な異なるフォーマットで受け取ることができる。ユーザのコメントおよび／またはエラーメッセージ１１３は、高次元でまばらであり得る。

サービスコンピューティングデバイス１０２はさらに、１つまたは複数のネットワーク１０６を介して、１つまたは複数の修理業者コンピューティングデバイス１１４および／または１つまたは複数の機器コンピューティングデバイス１１６などの１つまたは複数のクライアントコンピューティングデバイス１１５と通信し得る。いくつかの例では、修理業者コンピューティングデバイス１１４および／または機器コンピューティング装置１１６のそれぞれの修理アプリケーション１１８は、同じアプリケーション機能および機能を含むことができるが、他の例では、修理アプリケーション１１８は、修理アプリケーション１１８を備えることができる。使用する個々の修理環境に合わせてカスタマイズできる。

いくつかの実装形態では、サービスコンピューティングデバイス１０２は、１つまたは複数のサーバ、パーソナルコンピュータ、組み込みプロセッサ、または任意の数の方法で具現化され得る他のタイプのコンピューティングデバイスを含み得る。例えば、サーバの場合、プログラム、他の機能構成要素、およびデータ記憶装置の少なくとも一部は、サーバのクラスタ、サーバファームまたはデータセンタ、クラウドホストコンピューティングサービス内のような少なくとも１つのサーバ上に実装することができる。そして、他のコンピュータアーキテクチャが追加的にまたは代替的に使用されてもよい。

図示の例では、サービスコンピューティングデバイス１０２は、１つまたは複数のプロセッサ１２０、１つまたは複数の通信インタフェース１２２、および１つまたは複数のコンピュータ可読媒体１２４を含むか、そうでなければそれに関連付けてもよい。ユニットまたは多数の処理ユニットを含み、単一または複数の計算ユニット、または複数の処理コアを含むことができる。プロセッサ１２０は、１つまたは複数の中央処理装置、マイクロプロセッサ、マイクロコンピュータ、マイクロコントローラ、デジタル信号プロセッサ、状態機械、論理回路、および／または動作命令に基づいて信号を操作する任意のデバイスとして実装され得る。例えば、プロセッサ１２０は、本明細書に記載のアルゴリズムおよびプロセスを実行するように特にプログラムまたは構成された任意の適切な種類の１つまたは複数のハードウェアプロセッサおよび／または論理回路とすることができる。プロセッサ１２０は、コンピュータ可読媒体１２４に格納されたコンピュータ可読命令をフェッチして実行するように構成されてもよく、これは、プロセッサ１２０を本明細書に記載の機能を実行するようにプログラムすることができる。

コンピュータ可読媒体１２４は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を記憶するための任意のタイプの技術で実装された揮発性および不揮発性メモリおよび／または取り外し可能および固定の媒体を含み得る。例えば、コンピュータ可読媒体１２４は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、光学記憶装置、固体記憶装置、磁気テープ、磁気ディスク記憶装置、ＲＡＩＤ記憶システム、オブジェクトを含むことができるが、それらに限定されない。コンピュータ可読媒体１２４は、ストレージシステム、ストレージアレイ、ネットワーク接続ストレージ、ストレージエリアネットワーク、クラウドストレージ、または所望の情報を格納するために使用することができ、かつコンピューティングデバイスによってアクセスすることができる任意の他の媒体を含む。サービスコンピューティングデバイス１０２の構成に応じて、コンピュータ可読媒体１２４は、言及されるとき、エネルギー、搬送波信号、電磁気などの媒体を除外する限りにおいて、有形の非一時的媒体であり得る。波および／または信号それ自体、場合によっては、コンピュータ可読媒体１２４はサービスコンピューティング装置１０２と同じ場所にあってもよいが、他の例では、コンピュータ可読媒体１２４はサービスコンピューティング装置１０２から部分的に離れていてもよい。

コンピュータ可読媒体１２４は、プロセッサ１２０によって実行可能な任意の数の機能構成要素を格納するために使用され得る。多くの実装において、これらの機能構成要素は、プロセッサによって実行可能な実行可能命令および／またはプログラムを含む。そして、実行されると、本明細書でサービスコンピューティングデバイス１０２に起因する動作を実行するようにプロセッサ１２０を具体的にプログラムする。コンピュータ可読媒体１２４に格納された機能構成要素は、修理管理プログラム１２６を含むことができる。修理管理プログラム１２６は、ここに記述されているようにさまざまなタスクを実行するため、プロセッサ１２０を実行させるために実行可能な１つまたは複数のコンピュータプログラム、コンピュータ可読命令、実行可能コード、またはその一部を含むことができる。図示の例では、修理管理プログラム１２６は、データ準備プログラム１２８、関連データ抽出プログラム１３０、特徴抽出プログラム１３２、モデル構築およびアプリケーションプログラム１３４、ならびに修理計画実行プログラム１３６を含むか、それらにアクセスすることができる。

これらの機能構成要素１２８−１３６のそれぞれは、修理管理プログラム１２６の実行可能モジュール、またはその一部であり得る。代替として、他の例では、これらの機能構成要素１２８−１３６のうちのいくつかまたはすべては、修理管理プログラム１２６によって呼び出され得る、別々に実行可能なスタンドアロンコンピュータプログラムであり得る。

データ準備プログラム１２８は、ノイズを除去し、異なるデータタイプおよび／またはソースをさらなる分析に有用であり得るフォーマットに変換することによって受信入力データを準備するように１つまたは複数のプロセッサ１２０を構成することができる。関連データ抽出プログラム１３０は、各修理インシデント（履歴または新規）について、修理が必要な問題の症状を含むデータの１つまたは複数のサブセットを抽出するように１つまたは複数のプロセッサを構成することができる。特徴抽出プログラム１３２は、修理の対象となる機器に関連する関連データから特徴を抽出するように１つまたは複数のプロセッサを構成することができる。モデル構築およびアプリケーションプログラム１３４は、修理履歴データから修理決定に使用される１つまたは複数の機械学習モデルを構築するように１つまたは複数のプロセッサを構成し、その後１つまたは複数の機械学習モデルを新しい修理インシデントに適用することができる。さらに、修理計画実行プログラム１３６は、修理計画の実行、修理業者コンピュータ装置への修理指示の送信、機器コンピュータ装置への修理指示の送信など、１つまたは複数の修理計画を決定および実行するように１つまたは複数のプロセッサを構成し得る。

加えて、コンピュータ可読媒体１２４内の機能構成要素は、サービスコンピューティングデバイス１０２の様々な機能を制御および管理することができるオペレーティングシステム（図１には示されていない）を含むことができる。コンピュータ可読媒体１２４のローカルメモリ部分にロードされ、１つまたは複数のプロセッサ１２０によって実行される、コンピュータ可読媒体１２４の記憶部分、本明細書の開示の利点を有する多数の他のソフトウェアおよび／またはハードウェア構成が当業者には明らかであろう。

さらに、コンピュータ可読媒体１２４は、本明細書に記載の機能およびサービスを実行するために使用されるデータおよびデータ構造を記憶することができる。例えば、コンピュータ可読媒体１２４は、１つまたは複数の機械学習モデル１４０を記憶することができ、機械学習モデル１４０をトレーニングするために使用されるトレーニングデータ１４２、ならびにレポート、クライアントデータ、修理要求を記憶することができる。いくつかの例では、コンピュータ可読媒体１２４はデータソース１０４を包含し得るが、他の例では、コンピュータ可読媒体１２４はデータソース１０４から分離し得る。

１つまたは複数の機械学習モデル１４０は、１つまたは複数のクライアントコンピューティングデバイスから受信された情報に応答して１つまたは複数の修理ソリューションを決定するために、モデル構築およびアプリケーションプログラム１３４などの１つまたは複数の機能コンポーネントによって使用され得る。機械学習モデル１４０の例は、ディープニューラルネットワークおよびリカレントニューラルネットワークなどのディープ学習モデルを含み得る。例えば、ディープニューラルネットワークは、入力層と出力層との間に複数の層を有する一種の人工ニューラルネットワークである。ディープニューラルネットワークは、線形関係に基づくか非線形関係に基づくかにかかわらず、入力を出力に変えるための正しい数学的操作を見つける。ディープニューラルネットワークは各出力に対する確率を決定するために層を通過する。そのようなそれぞれの数学的操作はレイヤーと見なされる。明細書のいくつかの例では、ディープニューラルネットワークは多くの層を有することができ、複雑な非線形関係をモデル化することができる。

さらに、本明細書のいくつかの例ではディープラーニングモデルが使用されているが、本明細書のいくつかの例で使用され得る他のタイプの機械学習モデル１４０の追加の例は予測モデル、決定木、線形回帰モデルなどの回帰モデル、確率的モデルを含み得る。マルコフモデルや隠れマルコフモデルなどのモデル。したがって、本明細書におけるいくつかの実装形態は、特定のタイプの機械学習モデルに限定されない。

サービスコンピューティングデバイス１０２はまた、プログラム、ドライバなどを含み得る他の機能構成要素およびデータ、ならびに機能構成要素によって使用または生成されるデータを含むかまたは維持することができる。さらに、サービスコンピューティングデバイス１０２は、他の多くの論理構成要素、プログラム構成要素、および物理構成要素を含むことができ、そのうちの上記のものは、本明細書の説明に関連する単なる例である。

通信インタフェース１２２は、１つまたは複数のネットワーク１０６を介するなど、他の様々な装置との通信を可能にするための１つまたは複数のインタフェースおよびハードウェア構成要素を含むことができる。したがって、通信インタフェース１２２は、データソース１０４、クライアントコンピューティングデバイス１１５、および／または１つもしくは複数のネットワークと通信するためにネットワーク１０６、より多くの外部コンピューティングデバイス１４５への接続を提供する１つまたは複数のポートを含むか、またはそれらに結合することができる。例えば、通信インタフェース１２２は、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、インターネット、ケーブルネットワーク、セルラーネットワーク、無線ネットワーク（例えば、Ｗｉ‐Ｆｉ）、有線ネットワーク（例えば、光ファイバ、イーサネット（登録商標）、ファイバチャネル）、直接接続、ならびにＢＬＵＥＴＯＯＴＨ（登録商標）などの短距離無線通信などのうちの１つ以上、を介した通信を可能にし得る。

さらに、クライアントコンピューティングデバイス１１５および１つまたは複数の外部コンピューティングデバイス１４５は、上述したものと同様の構成およびハードウェアを含むが、修理アプリケーション１１８などの異なる機能コンポーネントと異なるデータとを含み得る。クライアントコンピューティングデバイス１１５は、サーバコンピューティングデバイス、デスクトップコンピューティングデバイス、ラップトップコンピューティングデバイス、タブレットコンピューティングデバイス、スマートフォンコンピューティングデバイス、ウェアラブルコンピューティングデバイス、組み込みコンピューティングデバイス、などのネットワークを介して通信することができる任意のタイプの電子制御装置などのコンピューティングデバイスであり得る。

１つまたは複数のネットワーク１０６は、イントラネットなどのＬＡＮを含む任意の種類のネットワークを含むことができる。任意の種類のネットワークは、インターネットなどのWAN、セルラーネットワークなどの無線ネットワーク、Ｗｉ−Ｆｉ（登録商標）などのローカル無線ネットワーク、ＢＬＵＥＴＯＯＴＨ（登録商標）などの短距離無線通信、光ファイバ、イーサネット（登録商標）、ファイバチャネル、または他の任意のそのようなネットワークを含む有線ネットワーク、直接有線接続、またはそれらの任意の組み合わせである。したがって、１つまたは複数のネットワーク１０６は、有線および／または無線通信技術の両方を含み得る。そのような通信に使用される構成要素は、ネットワークの種類、選択された環境、またはその両方に少なくとも部分的に依存し得る。そのようなネットワークを介して通信するためのプロトコルは周知であり、本明細書では詳細に説明しない。

したがって、サービスコンピューティングデバイス１０２、クライアントコンピューティングデバイス１１５、外部コンピューティングデバイス１４５、およびいくつかの例ではデータソース１０４は、有線または有線を使用して１つまたは複数のネットワーク１０６を介して通信することができる。

いくつかの実装形態では、サービスコンピューティングデバイス１０２は、ストリーミングまたはダウンロードなどによって、１つまたは複数のデータソース１０４からトレーニングデータ１４２を受信することができる。例えば、モデル構築およびアプリケーションプログラム１３４は、修理履歴データ１０８からトレーニングデータ１４２を取得し、トレーニングデータをデータ準備プログラム１２８、関連データ抽出プログラム１３０、および特徴抽出プログラム１３２に提供することができる。モデル構築およびアプリケーションプログラム１３４は、トレーニングデータ１４２を使用して、１つまたは複数の機械学習モデル１４０をトレーニングすることができる。

１つまたは複数の機械学習モデル１４０のトレーニングに続いて、修理管理プログラム１２６は、対応する機器１５２の修理を要求するクライアントコンピューティングデバイス１１５のうちの１つから修理要求１５０を受信することができる。本明細書の機器１５２の例には、故障の可能性があり、その原因となる可能性があるほど十分に複雑であったり、理要員、保守要員などの修理業者１５４には容易に明らかではない、車両、電化製品、建設機器、製造機器、ロボット、電子機器、または他の種類のデバイス、機器、機械などが含まれ得る。したがって、本明細書における実装形態は特定の種類の機器に限定されない。

修理要求１５０の受信に応答して、修理管理プログラム１２６は、以下にさらに説明するように、データ準備プログラム１２８、関連データ抽出プログラム１３０、および特徴抽出プログラム１３２を呼び出して、データ準備プログラム１２８からデータを作成および／または抽出することができる。修理管理プログラム１２６はさらに、モデル構築およびアプリケーションプログラム１３４を呼び出して、抽出された情報を機械学習モデル１４０に適用して、修理依頼のための可能な修理解決策の１つまたは複数を決定することができる。

ありそうな修理解決策があるとき、修理管理プログラム１２６は修理計画実行プログラム１３６を呼び出して、ありそうな修理解決策に基づいて修理計画１５６を決定し実行することができる。いくつかの例では、修理計画１５６またはその一部は、修理要求１５０を送ったクライアントコンピューティングデバイス１１５に送ることができる。修理計画１５６を受信すると、この例では修理業者コンピューティングデバイス１１４などのクライアントコンピューティングデバイス１１５上の修理アプリケーション１１８は、修理業者１５４による閲覧のために修理業者コンピューティングデバイス１１４上に修理計画１５６を提示することができる。次いで、修理業者１５４は、修理計画１５６に含まれる命令に基づいて修理を実行することができる。

代替として、修理計画実行プログラム１３６は、部品注文１５８を外部コンピューティングデバイス１４５に送信すること、機器を修理するための修理業者を計画すること、修理が行われる時間を計画することなどによって修理計画１５６の一部を実行などし得る。例えば、外部コンピューティングデバイス１４５は、部品注文１５８を受信し、修理場所で修理業者１５４に修理部品を提供することができる外部アプリケーション１６０を含むウェブサーバまたは他の適切な計算装置であり得る。さらに、修理計画実行プログラム１３６は、機器コンピューティングデバイス１１６に修理指示１６２を提供することができる。いくつかの例では、修理指示１６２は、機器１５２自体に修理を実行させるか、そうでなければ修理を開始させることができる。例えば、機器コンピューティングデバイス１１６上の修理アプリケーション１１８は、修理指示１６２を受信することができ、修理を実行するために修理指示１６２に従って１つまたは複数の動作を実行することができる。それに加えて、またはその代わりに、場合によっては、修理指示１６２は、修理を実行するかそうでなければ修理を開始するために機器コンピューティングデバイス１１６によって実行され得るコンピュータ実行可能命令を含み得る。したがって、いくつかの例では、修理計画実行プログラム１３６は、対応する機器１５２の修理を実行するために機器コンピューティング装置１１６を介して遠隔で修理作業を開始することができる。

修理に続いて、修理アプリケーション１１８は、修理に関連するクライアントコンピューティングデバイス１１５に修理結果１７０を修理管理プログラム１２６に送信させることができる。それに応答して、修理管理プログラム１２６は受信した結果情報を新しいデータ１７２として格納することができる。新しいデータ１７２は、その後、１つまたは複数の機械学習モデル１４０を再トレーニングするためのトレーニングデータ１４２の一部として使用され、それによって１つまたは複数の機械学習モデル１４０の動作を改善することができる。修理が失敗した場合、いくつかの例では、修理管理プログラム１２６は修理結果１７０を新しい修理要求として適用して、特定の機器１５２に対する新しいまたはそうでなければ追加の修理計画を決定することができる。

図２から図２８は、いくつかの実装による例示的なプロセスを示すフローチャートを示す。プロセスは、一連の動作を表す論理的なフローチャートにおけるブロックの集まりとして示されており、それらの一部または全部は、ハードウェア、ソフトウェア、またはそれらの組み合わせで実施することができる。ソフトウェアの文脈では、ブロックは、１つまたは複数のプロセッサによって実行されると、列挙された動作を実行するようにプロセッサをプログラムする、１つまたは複数のコンピュータ可読媒体に格納されたコンピュータ実行可能命令を表し得る。

一般に、コンピュータ実行可能命令は、特定の機能を実行するかまたは特定のデータタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。ブロックが記載されている順序は、限定として解釈されるべきではない。説明されたブロックのうちの任意の数は、プロセスまたは代替プロセスを実装するために任意の順序でおよび／または並行して組み合わせることができ、すべてのブロックを実行する必要はない。説明のために、プロセスは、本明細書の例に記載されている環境、フレームワーク、およびシステムを参照して説明されているが、プロセスは、多種多様な他の環境、フレームワーク、およびシステムで実施され得る。

図２は、修理管理プログラム１２６によって実行され得るプロセス、および図１に関して上で論じられた他の機能構成要素を示す３つの例示的なフローチャートを含む。第１のフローチャート２０２はモデルトレーニングのためのプロセスを示し、第２のフローチャート２０４はモデル適用段階の間のリアルタイム修理処理のためのプロセスを示し、そして第３のフローチャートはサービスコンピューティングデバイス１０２の１つまたは複数のプロセッサを使用する。２０６は一括修理処理（バッチ処理）の処理を示す。リアルタイム処理およびバッチ処理の動作は多くの点で類似している可能性があるので、以下では、第２のフローチャート２０４と第３のフローチャート２０６との間の相違点のみを説明する。

上述のように、最初にシステムは修理履歴データを使用して１つまたは複数の機械学習モデルをトレーニングすることができる。例えば、修理データは、機械学習モデルが使用される機器の種類またはカテゴリに関して修理要員によって行われた様々な修理事件について、経時的に受信され、データベースなどに格納されていてもよい。

例えば、機械学習モデルがトラックの修理計画を決定するために使用される場合、機械学習モデルをトレーニングするためにトラックの修理履歴データにアクセスすることができる。同様に、機械学習モデルが冷蔵庫の修理計画を決定するために使用される場合、冷蔵庫の過去の修理データのデータベースが使用されてもよい。いくつかの例では、修理履歴データは、同じブランドの機器、場合によっては、同じ機器のモデルまたはモデルラインについてのものであり、修理履歴データの利用可能性および修理履歴データの量に依存する。例えば、修理履歴データは、機器製造業者、機器修理工場などによって維持されているデータベースから取得されてもよい。さらに、機器の特定のブランドまたはモデルについての不十分な量の修理履歴データがある場合、それぞれの類似性に応じて、他のブランドおよび／または機器等のモデルについての修理履歴データが使用されることがある。

修理履歴データおよび／またはクライアントコンピューティングデバイスから受信された修理要求に含まれるデータから取得されたトレーニングデータは、機器の属性、機器の使用など、上述のような複数の異なる種類のデータを含み得る、例えば、データ、機器センサデータ、イベントデータ、ユーザのコメントおよび／またはエラーメッセージ、ならびに他のユーザ障害関連データ、機器および／または機器モデルの修理履歴、ならびに様々な種類のメタデータである。

他の障害関連データは、修理されるべき障害についてのより多くの情報を含み得る他の種類のデータを含み得る。この種のデータの例には、欠陥部品の画像、記録装置または超音波監視装置からの音声ファイル、欠陥機器または欠陥部品のビデオなどが含まれる。このデータは、修理プロセスの前または最中にシステムに送信されることがある。

機器の修理履歴は、以前の故障を修理するために機器に対して既に行われた過去の修理インシデントを含むことができる。各以前の修理インシデントは、日時など、以前の修理が行われた時刻を指定する関連タイムスタンプを有することができる。いくつかの例では、修理履歴はまた、故障の原因となった機器のシステムまたはサブシステム、交換または修理された１つまたは複数の構成要素、関連部品など、修理事故のさまざまな側面を記述する属性を含み得る。そして、修理には、交換、清掃、検査などの修理のために実行された処置が含まれる。

メタデータは、機器が動作している環境に関する追加情報を記述することがある。メタデータは、動作条件、例えば動作時間、場所などの環境条件、温度、湿度、および日付などの保守記録、機器の状態、オペレータノートなどを含むことができるが、これらに限定されない。メタデータは、構造化形式、半構造化形式、または非構造化形式で表示される。

上述のように、コンピューティングデバイスは、最初に修理履歴データを使用して１つまたは複数の機械学習モデルをトレーニングすることができる。この例では、機械学習モデルをトレーニングするためのモデルトレーニング処理２０２は２１０で始まる。

２１０で、コンピューティングデバイスは機器および修理データを受信することができる。例えば、コンピューティングデバイスは、機器属性、使用データ、センサデータ、イベントデータ、ユーザのコメントおよびエラーメッセージ、他の故障関連データ、修理履歴、および修理履歴などの上述の種類のデータのうちのいずれかを含む修理履歴データやメタデータを受信し得る。

２１２で、コンピューティングデバイスは、受信データを準備するためにデータ準備プログラムを呼び出すことができる。例えば、データ準備プログラムを実行して、受信データからノイズを除去し、さまざまな異なるデータタイプをさらなる分析に使用できる１つまたは複数のフォーマットに変換することができる。例えば、カテゴリデータおよび数値データ（機器属性および使用データなど）および時系列データ（センサデータなど）について、コンピューティングデバイスはデータからノイズおよび異常値を除去し、さらに欠落データを排除することができる。

ノイズおよび外れ値の除去は、データ値またはセンサの読みにおけるノイズおよび外れ値を検出すること、およびこれらのデータ値を、類似のまたは近くの記録または同じセンサの他の読みに基づいて計算された値で除去または置換することを含み得る（例えば、最近傍の平均値または中央値を使用する）。さらに、ノイズ除去は、データ入力エラーによるノイズの除去、および修理ミスまたは無効な修理の除去を含み得る。例えば、失敗を解決することにならなかった修理は、機械学習モデルをトレーニングするためには役に立たないとして削除されてもよい。一例として、無効な修理は、最初の修理に続いて短時間内に同様の苦情で修理のために返却された機器を識別することによって検出することができる。さらに、以下で論じるように、無効な修理はまた、修理者のフィードバックによって明示的に識別され得、その後モデルが再トレーニングされるときにトレーニングデータから除去され得る。

さらに、欠損データの代入は、類似のまたは近くのレコードの値を補間することによって欠損値を代入すること、または近くのタイムスタンプにおけるセンサ時系列の他の読みを含むことができる。場合によっては、元の時系列の回帰モデルを使用して共通のタイムスタンプで回帰関数の値を見つけることで代入を実行することができるが、本明細書の開示の恩恵を受ける他の技術も当業者には明らかであろう。

さらに、本明細書で実行されるデータ準備は、受信した任意の自然言語データの自然言語データ準備を含み得る。一例として、機器に関する苦情などのユーザのコメントについては、コンピューティングデバイスは、最初にそのユーザのコメントをテキストフォーマットに変換することができる。例えば、ユーザのコメントが手書きのメモの画像として利用可能である場合、システムは、ユーザのコメントのテキストを認識するために光学式文字認識（ＯＣＲ）アルゴリズムを使用することができる。あるいは、ユーザのコメントが音声メモとして利用可能である場合、コンピューティングデバイスは、音声信号を自然言語のテキストに変換するために音声−テキストアルゴリズムを使用することができる。

ユーザコメントのテキストが抽出された後、抽出されたテキストは、特殊文字の削除、ストップワードの削除、略語の正規化、同義語の正規化、タイプミスの修正、およびステミングの実行などによって、きれいにされ得る。たとえば、特殊文字（たとえば、「;」、「＃」、「！」、「@」）を入力テキストから削除し、テキストをさらに小文字のように単語（トークン）にトークン化することができる。

さらに、ドメイン固有のトークンは、統一フォーマットに正規化されてもよい（例えば、エラーコード「１２３４／５６７」および「１２３４５６７」は、一貫したフォーマットに正規化されてもよく、「３０ｍｐｈ」および正規化された「３０ｍｐｈ」などの測定値も同様である）。

加えて、ストップワード除去は、問題の説明に有用な情報を追加しない一般的なワード（例えば、「in」、「a」、「of」、「the」、「is」）の除去を含む。このステップでは、汎用またはドメイン固有のストップワードのリストを利用できる。さらに、略語の正規化は、「セル」を「エンジンライトのチェック」に変更することなどによって、テキスト内で遭遇する略語を拡張および正規化することができる。さらに、同義語は、ドメイン内の同義語の対を識別および正規化することによって選択された用語に正規化され得る。さらに、テキスト修正は、「漏れ」を「漏れ」に変更するなど、テキスト内のタイプミスを検出して修正することを含むことができる。最後に、ステミングは、入力テキスト内の語彙の変動を減らすためにすべての単語をそれらの語幹に変換することを含み得る（例えば、「漏れ」、「漏れ」、および「漏れ」はすべて「漏れ」という語幹に変換され得る）。

前述のクリーニングステップは、機器の内部または機器の環境内のコンピュータシステムからのエラーメッセージなど、構造化されていないテキストを含む他のデータタイプにも適用できる。さらに、画像、音声ファイル、またはビデオファイルなどの他のデータタイプについては、当技術分野で知られているように、標準のデータクリーニングおよび準備技法を適用することができる。さらに、トレーニングデータを準備するためにデータ準備プログラムによって使用されるパラメータ値２１３は、以下にさらに説明されるようにモデル適用段階中に修理要求と共に受信されたデータを準備するときに記録され、その後データ準備プログラムによって使用され得る。

２１４において、コンピューティングデバイスは、関連データ抽出プログラムを呼び出して、準備されたデータから関連データを抽出することができる。例えば、この操作は、当面の修理に関連するデータのセグメントを抽出することを含み得る。故障時間ｔｆが与えられると、以下のデータセグメントが抽出され得る。

(a) 機器属性：コンピューティングデバイスは、修理の対象となる機器のすべての属性を抽出することができる。

(b) 使用状況データ：コンピューティングデバイスは、障害ｔｆの時点で使用データを抽出することができる。その時点で利用状況データが利用可能でない場合、コンピューティングデバイスは、最新の利用状況データを外挿してtfでの利用状況を推定することができる。

(c) センサデータ：コンピューティングデバイスは、故障時間ｔｆの前の第１の閾値期間Ｔ１内にすべてのセンサ測定値を抽出することができる。

(d) イベントデータ：コンピューティングデバイスは、故障時間ｔｆの前の第２の閾値期間Ｔ２内にすべてのイベントを抽出することができる。

(e) ユーザのコメントおよびエラーメッセージ：コンピューティングデバイスは、障害の前、または修理プロセス中の障害の後に生成されたすべての自然言語のコメントおよびエラーメッセージを使用することができる。

(f) 他の障害関連データ：コンピューティングデバイスは、修理プロセスの前または最中に生成された他のすべての障害関連データファイルを抽出することができる。

(g) 修理履歴：トレーニングデータについては、コンピューティングデバイスは、以前の修理プロセス（例：システム、サブシステム、コンポーネント、部品、および実行された修理処置）、これらの詳細を機械学習モデルによって学習されるターゲットラベルとして使用する。

(h) メタデータ：時変データの場合、コンピューティングデバイスは、故障時間ｔｆの前の第３の閾値期間Ｔ３内にデータインスタンスのみを抽出することができる。静的データの場合、コンピューティングデバイスは機器または環境に関連するすべての属性を抽出することができる。さらに、トレーニングデータを抽出するために関連データ抽出プログラムによって使用されるパラメータ値２１５は、後述するようにモデル適用段階中に修理要求と共に受信されたデータからデータを抽出するときに関連データ抽出プログラムによって記録および使用され得る。

２１６で、コンピューティングデバイスは、マルチモーダル抽出データから特徴抽出を実行するために特徴抽出プログラムを呼び出すことができる。例えば、上述の関連データ抽出操作中に抽出された変数が与えられると、コンピューティングデバイスは、その変数をディープラーニングアーキテクチャなどへの入力として使用することができる。例えば、ディープラーニングアーキテクチャは、マルチモーダル高次元スパースデータおよび高密度データを統合するように構成され得る。さらに、ディープラーニングアーキテクチャは、コンテキスト情報としてユーザのコメント、機器の属性、および使用データを使用して関連イベントデータを抽出するためのイベントの重要度モデリングを可能にすることができる。さらに、本明細書のディープラーニングアーキテクチャは、一貫した正確な構造化された修理を出力するためのトレーニングメカニズムを含む。

例えば、以下でさらに論じるように、図３−図１５を参照すると、コンピューティングデバイスによって抽出された特徴は、それぞれの修理事件についての特徴ベクトルに変換され得る。トレーニングデータの場合、特徴はｎ×ｍ個の特徴行列Ｘに結合されてもよく、ここで（ｉ、ｊ）番目の要素は修理ｉに対する特徴ｊの値を表し、ｎは特徴の数であり、ｍは修理インシデントの数である。

トレーニングデータの場合、特徴はｎ×ｍ個の特徴行列Ｘに結合されてもよく、ここで（ｉ、ｊ）番目の要素は修理ｉに対する特徴ｊの値を表し、ｎは特徴の数であり、ｍは修理インシデントの数である。特徴抽出のさらなる詳細は、図３−１５に関して以下に説明される。さらに、トレーニングデータから特徴を抽出するために特徴抽出プログラムによって使用されるパラメータ値２１７は、モデル適用段階中に修理要求と共に受信されたデータから特徴を抽出するときに、特徴抽出プログラムによって記録および使用される。

２１８において、コンピューティングデバイスは、抽出された特徴を使用して機械学習モデルをトレーニング（訓練）する。例えば、修理動作を推奨するために、ディープニューラルネットワーク、リカレントニューラルネットワーク、または他のディープラーニングモデルなどの機械学習モデルが、抽出された特徴と対応する修理動作との間でマッピングするようにトレーニングされ得る。本明細書の他の箇所に列挙されているように、他のタイプの機械学習モデルを追加的にまたは代替的に使用することができる。機械学習モデルのトレーニングについては、図１６を参照して、以下でさらに説明する。

トレーニングされた機械学習モデル（複数可）２１９は、機器の保守または他の修理のために実行され得る修理行為のための１つまたは複数の選択肢を各出力修理行為の成功確率と共に出力するように構成され得る。成功の確率は、修理動作が修理履歴データに基づいて現在の障害を正常に修理する可能性を示し得る。

２２０で、コンピューティングデバイスは、トレーニングされた機械学習モデル２１９によって出力され得る可能性のある修理動作に対応する修理計画２２１を、学習するか、そうでなければ決定することができる。例えば、モデルトレーニング段階の間、修理計画実行プログラムは、機械修理モデルによって決定され得るそれぞれの異なる修理処置を実施するためにとられるステップを修理履歴データまたは他の情報源から学習することができる。

例えば、機械学習モデルの可能な結果であり得る各修理動作について、修理計画実行プログラムは、例えば抽出されたデータまたは他のデータソースから、修理を実行するために使用されることが示されている修理ステップを取得し得る。さらに、場合によっては、修理計画実行プログラムは、機器製造業者からの機器修理マニュアルなどの他のデータソースにアクセスして、機械学習モデルによって出力され得る各可能な修理動作についての修理ステップを取得することができる。

各修理動作について学習された修理ステップに基づいて、その後、モデル適用段階中に、修理計画実行プログラムは、いくつかの例では、学習された修理計画を使用して前述のステップのうちの１つまたは複数を実行し得る。さらに、特定の故障に対して複数の修理選択肢がある場合、修理計画実行プログラムは、全体的な修理費用が最小になり、機器の利用可能性が最大になるように、選択肢の１つを選択することができる。各修理行為の影響についての情報（費用と時間）は、外部の情報源または過去の修理データから入手することができる。したがって、修理計画実行プログラムは、機械学習モデルによって出力された１つまたは複数の出力された修理動作に基づいて１つまたは複数の修理計画２２１を生成するようにサービスコンピューティングデバイスを構成することができる。

機械学習モデルによってトレーニングされた後、および機械学習モデルによって推奨される可能性がある修理動作のための修理計画を生成するための修理計画実行プログラムの構成に従って、システムは、２０４で示されるようにリアルタイム処理または２０６で示されるようにバッチ処理のいずれかのためにモデル適用段階で実行する準備ができている。前述のように、これらのプロセスは似ている。例えば、修理の要求がサービスコンピューティングデバイスに伝達されるときにリアルタイム処理が行われても良く、バッチ処理は、サービスコンピューティングデバイスに送信後、すなわち修理要求の後のある時点（分、時間、日）に行われ得る。

２３０において、コンピューティングデバイスは、例えば図１に関して上記で論じたように、クライアントコンピューティングデバイスからの修理要求の中などで、機器および修理データを受信することができる。さらに、サービスコンピューティングデバイスはまた、修理履歴データまたは他のソースから特定の機器に関するいくつかの機器および修理データを受信し得る。例えば、機器属性、使用データ、イベントデータ、および修理履歴は、修理履歴データまたは他の情報源から取得され得る。さらに、サービスコンピューティングデバイスは、機器自体から、または機器に関連する１つまたは複数のデバイスからセンサデータおよびエラーメッセージを受信することができる。さらに、サービスコンピューティングデバイスは、クライアントコンピューティングデバイスまたは機器ユーザに関連する他のデバイスからユーザコメントおよび他の障害関連データを受信することがある。

２３２において、コンピューティングデバイスは、修理要求に対応する受信データを準備することができる。例えば、コンピューティングデバイスは、受信データからノイズを除去し、受信データを正規化し、２１２で言及したような更なる分析を行うため、様々な異なるデータタイプをさらなる分析に使用できる１つまたは複数のフォーマットに変換するためにデータ準備プログラムを呼び出すことができる。トレーニング段階中に使用されたパラメータ値２１３は、受信データを準備するために使用されてもよい。さらに、場合によっては、動作２３２−２４０は、リアルタイムステージ２０４とバッチステージ２０６とで同じであり得る。しかしながら、他の場合には、バッチ修理処理段階２０６の間に実行される動作２３２−２４０は、リアルタイム修理処理段階２０４の間に実行される動作２３２−２４０とは異なってもよい。各段階２０４または２０６で機能する場合、２３２で準備されるべき受信データ２３０の性質の違いなどにより、処理ステップは異なってもよい。

一例として、入力ケースのバッチに対して推奨する修理を決定するとき、いくつかの実装は、全ての特徴を並列に構築し、全ての入力ケースに対する全ての特徴を含む特徴行列を渡し、そしてこれを乗算する並列プログラム、を実行し得る。各ケースの成功の可能性が最も高い修理を決定するためのモデルの重みを持つ特徴行列（この特徴行列をモデルの重みで乗算して、各ケースで最高の成功確率で修理を決定）を実行する。一方、リアルタイムのデータ処理を実行するときには、当面の場合の特徴の単一ベクトルを使用して同じ動作を実行することができる。したがって、アルゴリズムロジックは同じでもよいが、たとえばリアルタイムモードのために単一のマシン上でベクトル乗算を使用するのと比較して、バッチモード中に並列マシン上で行列演算を実行するためには実装コードは異なってもよい。場合によっては、リアルタイム操作をバッチ操作の特別な場合にするなどして、同じコードをバッチモードとリアルタイムモードの両方に使用できる。他の場合では、リアルタイムの場合とバッチの場合とで別々のコードを使用することができる。さらに、本明細書の開示の恩恵を受ける他の変形は当業者に明らかであろう。

２３４において、コンピューティングデバイスは、準備されたデータから関連データを抽出することができる。例えば、コンピューティングデバイスは、２１４で上述したように、および以下でさらに説明するように、関連データ抽出プログラムを呼び出して関連データを抽出することができる。モデルトレーニング処理２０２の間に使用されるパラメータ値２１５は、機器属性、使用データ、センサデータ、イベントデータ、ユーザのコメントおよびエラーメッセージ、他の故障関連データ、修理履歴、およびメタデータなどの関連データを抽出するために使用され得る。

２３６において、コンピューティングデバイスは、抽出された関連データから特徴を抽出し得る。例えば、コンピューティングデバイスは、２１６で上述したように、および以下でさらに説明するように、関連データから特徴を抽出するために特徴抽出プログラムを呼び出すことができる。トレーニング段階中に使用されるパラメータ値２１７は、時変変数（例えば、ウィンドウレベルの統計、傾向、相関、およびシーケンシャルパターン）、静的変数、およびフリーテキスト変数など、各変数についての特徴を抽出するために使用され得る。

２３８において、コンピューティングデバイスは、修理動作および成功の可能性を決定し得る。例えば、コンピューティングデバイスは、モデル構築およびアプリケーションプログラムを呼び出して、抽出された特徴をトレーニングされた機械学習モデル２１９に入力することができる。トレーニングされた機械学習モデル２１９は、トレーニングされた機械学習モデルの出力として、１つまたは複数の修理動作および各修理動作の成功確率を決定するための入力として抽出された特徴を使用して実行され得る。

２４０で、コンピューティングデバイスは、モデル出力に基づいて修理計画を決定することができる。例えば、コンピューティングデバイスは、トレーニング済み機械学習モデルの出力に基づいて１つまたは複数の修理計画を決定するために修理計画実行プログラムを呼び出すことができる。上述のように、修理計画実行プログラムは、トレーニングされた機械学習モデルによって決定された修理動作を実施するために、２２０で上述したように、例えば修理履歴データなどから決定された１つ以上の修理計画２２１を選択する。修理処置に複数の選択肢がある場合、修理計画実行プログラムは、より高い成功確率を有するように指示された修理処置を選択するように構成されてもよい。さらに、トレーニングされた機械学習モデルから受信された決定された修理動作のすべてについての成功確率がしきい値の成功確率を下回る場合、修理計画実行プログラムは、推奨することがより有益かどうかを決定するための分析を実行し得る。修理処置の１つ、または修理処置が不明であるという指示を送信する。決定は、全体的な保守費用が最小化され、そして装置の利用可能性が最大化されるかどうかに基づいてもよい。各修理ステップの影響についての情報（例えば、費用および時間）は、外部データソース、ドメイン知識、および／または過去の修理記録から知ることができる。

２４２で、コンピューティングデバイスは、受信した修理要求に関連するクライアントコンピューティングデバイスに、修理計画または修理計画の一部を実行および／または送信することができる。いくつかの例では、修理計画実行プログラムは、機械学習モデルによって決定された修理処置を実施するために修理計画の少なくとも一部を実行することができる。

例えば、修理計画を実行することは、修理を行うための交換部品の注文、修理を行うための修理者の割り当て、機器を修理するための修理時間のスケジューリング、および／または機器の修理を遠隔で行うことを含むことができる。例えば、自動診断の場合、機器の動作条件の変更、遠隔ファームウェアアップグレードの実行、機器の設定の遠隔調整、機器の洗浄の遠隔開始、機器の校正の遠隔開始などがある。さらに、いくつかの例では、修理計画実行プログラムは、修理業者コンピューティング装置上で提示するために修理業者コンピューティング装置に命令を送ることができる。さらに、さらに他の例では、修理計画実行プログラムは、機器コンピューティングデバイスなどの機器自体に命令を送信することができ、機器コンピューティングデバイスは次に、受信した命令に基づいて独立して修理を実行または開始することができる。本明細書の開示の恩恵を受ける当業者には、他の多くの変形が明らかであろう。

図３は、いくつかの実装形態による、フリーテキスト変数から特徴を抽出するための例示的なプロセス３００を示すフローチャートである。例えば、本明細書に記載の技術は、図２に関して議論した動作２１４−２１６および／または２３４−２３６の間に適用することができる。一般に、修理は、複数のデータソースから取得された情報に関連付けられてもよい。例えば、ユーザからの自然言語苦情または他のコメントは、症状と同義語であり得る。本明細書のシステムは、すべての修理がすべての装置や機器タイプに適用できるわけではないので、修理されるべき装置や機器に関する情報を得ることができる。診断情報とイベントは、適切な修理を決定するためのガイドとして役立つかもしれない豊富な情報である。したがって、入力情報は、組み合わされたときに機器に最適な修理を提供することができる様々なモダリティのデータで受信されることがある。しかしながら、複数の情報源は異なるフォーマットでデータを提供してもよい。たとえば、一部のデータがカテゴリカルであり、一部のデータが連続している可能性がある。それぞれの異なる種類のデータから抽出されるべき特徴は、データモダリティに依存し得る。したがって、本明細書における実装形態は、機器に関する最適な修理計画を決定するための適切な情報を抽出するためにマルチモーダルデータを処理するように構成される。

上述のように、フリーテキストは、機器の使用者、修理者、または他の様々な情報源によって書かれたまたは発話されたコメントからなど、システムによって受け取ることができる。フリーテキスト変数の場合は、各単語を辞書にエンコードして数値で表すことができる。いくつかの例では、単語はＯＮＥ−ＨＯＴコード化ベクトルによって表すことができ、ベクトルの長さは対応するコーパス（例えば辞書）内の一意の単語の数に等しい。これにより、フリーテキストコメントおよび／または他のフリーテキスト変数が一連のＯＮＥ−ＨＯＴ符号化ベクトル（例えば、高次元および疎）として表されることになる。

ＯＮＥ−ＨＯＴ符号化は、カテゴリカル変数が、機械学習モデルがトレーニングおよび／または予測のためにそれらの変数をよりよく使用することができるフォーマットに変換されるプロセスである。例えば、ＯＮＥ−ＨＯＴ符号化は、分類された入力が機械学習モデルのための特徴として含まれ得るように、カテゴリの二値化を実行するために使用され得る。一例として、受信された各入力は、カテゴリが満たされる場合には「１」を、カテゴリが満たされない場合には「０」を示すことによって分類され得る。ＯＮＥ−ＨＯＴ符号化は、値として「１」を有するものを除いて、ベクトルのすべての要素が「０」であるベクトルとして表すことができる。たとえば、[0 0 0 1 0 0]は、入力が6カテゴリのベクトルの4番目のカテゴリと一致するＯＮＥ−ＨＯＴベクトルである。ＯＮＥ−ＨＯＴ符号化は、高次元スパース行列をもたらし得る。例えば、１００００ワードを有する辞書の場合、ＯＮＥ−ＨＯＴ符号化後、マトリックスの各行は、一致するワードに対応する１つの位置に「１」を有し、他の９，９９９位置に「０」を有し得る。

図３に示される通り、高次元のスパースフリーテキスト変数は、学習可能な次元削減方法を使用して低次元の連続変数空間にマッピングできる。場合によっては、学習可能次元削減方法は埋め込み行列を使用して実行され得る。例えば、埋め込み行列は、高次元のスパースベクトルを低次元の稠密ベクトルにマッピングすることができる。次元削減の結果は、一連の低次元密ベクトルを含み得る。

フリーテキスト変数は自然言語文に対応し得るので、結果として得られる低次元密ベクトルは互いに逐次従属関係を有し得る。特徴を抽出するために、学習可能な順次特徴抽出方法を適用することができる。適切な逐次特徴抽出方法の一例は、ロングショートタームメモリ（ＬＳＴＭ）ユニットの使用であり得る。適切な順次特徴抽出技術の他の例は、条件付きランダムフィールド（ＣＲＦ）抽出である。特徴抽出プロセスは、（文または句の最初の単語を表す）左側の最初のベクトルから（最後の単語を表す）右側の最後のベクトルまで特徴を抽出することができる。堅牢性のために、本明細書の実装は右から左にも順次特徴を抽出することができ、したがって各フリーテキストコメントから２つの特徴ベクトルが得られる。

さらに、決定された特徴ベクトルは、フリーテキストコメントおよび／またはフリーテキスト変数から最終的な特徴ベクトルを決定するために組み合わされるか、そうでなければ集約されてもよい。一例として、特徴ベクトルは、２つの特徴ベクトルの平均を計算することによって集約することができる。学習可能な次元の縮小および逐次的な特徴抽出方法（左から右、および右から左）のパラメータは、誤差／損失関数の最適化などに基づいてモデルトレーニングプロセス中に学習される。

３０２で、サービスコンピューティングデバイスはフリーテキスト変数を受信することができる。例えば、サービスコンピューティングデバイスは、機器のユーザ、機器の修理者、管理者、または機器に関連する他の人員から、機器に関する書面または口頭による苦情または他のコメントを受け取ることができる。

３０４で、サービスコンピューティングデバイスは、受信したフリーテキスト変数に対してONE-HOT符号化を実行することができる。例えば、サービスコンピューティングデバイスは、受信したフリーテキスト内の各単語をＯＮＥ−ＨＯＴ符号化行列内の辞書内の単語のうちの１つと照合することによって、受信したフリーテキスト内の各単語を辞書に従って分類することができる。

３０６において、サービスコンピューティングデバイスは、ＯＮＥ−ＨＯＴ符号化フリーテキスト変数に対して学習可能な次元削減を実行し得る。上述のように、学習可能な次元の縮小は、埋め込み行列などを使用して実行することができる。例えば、埋め込み行列は、高次元のスパースベクトルを低次元の稠密ベクトルにマッピングすることができる。したがって、次元縮小は、複数の低次元密ベクトル、例えば受信されたフリーテキスト内の各単語に対して１つのベクトルを生成することができ、ベクトルは互いに順次依存関係を有することができる。

３０８および３１０で、サービスコンピューティングデバイスは、複数のベクトルに対して学習可能な順次特徴抽出を実行することができる。例えば、学習可能な順次特徴抽出は、各ベクトル１−Ｎについて実行されてもよい。したがって、３０８において、特徴抽出プロセスは、左側の第１のベクトル（文または句の第１の単語を表す）から第２の特徴を表す第２の特徴３１４、第２の特徴を表すＮ番目の特徴３１６までの第１の特徴３１２を抽出する。右（最後の単語を表す）加えて、３１０において、ロバスト性のために、本明細書の実施形態はまた、右から左へ、例えば３１６から３１４から３１２へと順次特徴を抽出することができ、したがって、各フリーテキストコメントから２つの特徴ベクトルをもたらす。

したがって、３０８において、特徴抽出プロセスは、左側（文または句の最初の単語を表す）の第１のベクトルから第２の特徴３１４までの第１の特徴３１２を抽出することができる。加えて、３１０において、ロバスト性のために、本明細書の実施形態はまた、右から左へ、例えば３１６から３１４から３１２へと順次特徴を抽出することができ、したがって、各フリーテキストコメントから２つの特徴ベクトルをもたらす。

３１８で、サービスコンピューティングデバイスは、それぞれ３０８および３１０からの２つの特徴ベクトルを組み合わせることによって抽出された特徴を集約することができる。一例として、２つの特徴ベクトルは、２つの特徴ベクトルの平均を計算することによって集約することができる。

３２０で、サービスコンピューティングデバイスは、モデルトレーニング段階中のモデルトレーニングなどのための機械学習モデルで使用するため、またはモデル適用段階中のモデルへの入力として使用するために、集約された抽出特徴を出力することができる。

この例では、順次特徴抽出方法にLSTMユニットを使用することができる。

４０２で、サービスコンピューティングデバイスはフリーテキスト変数を受信することができる。例えば、サービスコンピューティングデバイスは、機器のユーザ、機器の修理者、管理者、または機器に関連する他の人員から、機器に関する書面または口頭による苦情または他のコメントを受け取ることができる。

４０４で、サービスコンピューティングデバイスは、受信したフリーテキスト変数に対してＯＮＥ−ＨＯＴ符号化を実行することができる。例えば、サービスコンピューティングデバイスは、受信したフリーテキスト内の各単語をＯＮＥ−ＨＯＴ符号化行列内の辞書内の単語のうちの１つと照合することによって、受信したフリーテキスト内の各単語を辞書に従って分類することができる。

４０６で、サービスコンピューティングデバイスは、埋め込み階層を使用して、ＯＮＥ−ＨＯＴ符号化フリーテキスト変数に対して次元削減を実行することができる。上述のように、次元縮小は埋め込み行列などを使用して実行することができる。例えば、埋め込み行列は、高次元のスパースベクトルを低次元の稠密ベクトルにマッピングすることができる。したがって、次元縮小は、複数の低次元密ベクトル、例えば受信されたフリーテキスト内の各単語に対して１つのベクトルを生成することができ、ベクトルは互いに順次依存関係を有することができる。

４０８および４１０で、サービスコンピューティングデバイスは、ＬＳＴＭユニットを使用して、複数のベクトルに対して学習可能な順次特徴抽出を実行することができる。例えば、ＬＳＴＭユニットが各ベクトル１からＮに適用され、そこで各ベクトルから関連する特徴が抽出される。したがって、４０８で、特徴抽出プロセスは、４１２で示すように、左側の最初のベクトル（文または句の最初の単語を表す）から次のベクトル（２番目の単語を表す）へ、４１４で示されるように、（最後の単語を表す）右側のＮ番目のベクトルへ進むことができる。同じＬＳＴＭユニットが各ベクトルから特徴を抽出し、この例では各ベクトルから特徴を抽出するために、複数のそのようなＬＳＴＭユニット、例えばＬＳＴＭ１．１、ＬＳＴＭ１．２、…、ＬＳＴＭ１．ｎがあり得る。結果として、各ＬＳＴＭユニットから抽出された特徴は合成ベクトルを形成する。さらに、４１０で、ロバスト性のために、本明細書の実装は、４１５、４１６、および４１７で示されるように、複数のＬＳＴＭユニット、ＬＳＴＭ ２．１、ＬＳＴＭ ２．２、…、ＬＳＴＭ ２。最終的には2番目の特徴ベクトルになる。したがって、ＬＳＴＭユニットを左から右へ、またその逆に移動すると、各フリーテキストコメントから２つの特徴ベクトルが生成される。

４１８で、サービスコンピューティングデバイスは、２つの特徴ベクトルを組み合わせるために２つの特徴ベクトルの平均を計算することができる。

４２０で、サービスコンピューティングデバイスは、モデルトレーニング段階中のモデルトレーニングなどのための機械学習モデルとともに使用するため、またはモデル適用段階中にモデルへの入力として使用するために、集約抽出された特徴を出力することができる。

図５は、いくつかの実装形態による機器属性から特徴を抽出するための例示的なプロセス５００を示すフローチャートである。例えば、機器属性は、カテゴリカルデータであり得、ＯＮＥ−ＨＯＴコード化ベクトルとして表され得る。各機器属性をＯＮＥ−ＨＯＴコード化ベクトルに変換した後、本明細書のいくつかの例は、抽出されたすべてのベクトルを連結またはそうでなければ結合し、それによって高次元スパースベクトルを形成することができる。上述したフリーテキスト変数と同様に、本明細書におけるいくつかの実装形態は、高次元および疎ベクトルを低次元および密ベクトルに変換するための学習可能な次元削減プロセスを採用することができる。適切な学習可能な次元縮小技法の一例は埋め込み行列の使用を含む。

５０２から５０４で、サービスコンピューティングデバイスは、第１から第ｎの機器属性を受信することができる。上述のように、機器属性は様々な、機器メーカ、機器の履歴データ、ドメイン知識、機器ユーザなどのデータソースから受信されてもよい。

５０６から５０８において、サービスコンピューティングデバイスは、受信された機器属性１からＮに対してＯＮＥ−ＨＯＴ符号化を実行し得る。フリーテキスト変数について上述した例と同様に、ＯＮＥ−ＨＯＴ符号化は、複数の高次元スパースベクトルをもたらし得る。

５１０で、サービスコンピューティングデバイスは、ＯＮＥ−ＨＯＴ符号化機器属性ベクトルを連結することができる。

５１２において、サービスコンピューティングデバイスは、連結された高次元スパースベクトルに対して学習可能な次元縮小を実行し得る。一例として、スパースベクトルの次元縮小のために埋め込み行列を使用することができる。主成分分析（ＰＣＡ）および潜在意味索引付け（ＬＳＡ）は、スパースベクトルの次元削減に使用できる他の技法の例である。

５１４で、サービスコンピューティングデバイスは、モデルトレーニング段階中のモデルトレーニングなどのための機械学習モデルとともに使用するため、またはモデル適用段階中にモデルへの入力として使用するために、抽出された機器属性特徴を出力することができる。

図６は、いくつかの実装に従って機器属性から特徴を抽出するための例示的なプロセス６００を示すフローチャートである。この例では、埋め込み層を寸法縮小のために使用することができる。

６０２から６０４で、サービスコンピューティングデバイスは、第１から第Ｎの機器属性を受信することができる。上述のように、機器属性は様々な、機器メーカ、機器の履歴データ、ドメイン知識、機器ユーザ等のデータソースから受信されてもよい。

６０６から６０８において、サービスコンピューティングデバイスは、受信した機器属性１からＮに対してＯＮＥ−ＨＯＴ符号化を実行することができる。フリーテキスト変数について上述した例と同様に、ＯＮＥ−ＨＯＴ符号化は、複数の高次元スパースベクトルをもたらし得る。

６１０で、サービスコンピューティングデバイスは、ＯＮＥ−ＨＯＴ符号化機器属性ベクトルを連結することができる。

６１２で、サービスコンピューティングデバイスは、埋め込み層を使用して、連結された高次元スパースベクトルに対して次元削減を実行し得る。一例として、スパースベクトルの次元縮小のために埋め込み行列を使用することができる。

６１４で、サービスコンピューティングデバイスは、モデルトレーニング段階中のモデルトレーニングなどのための機械学習モデルとともに使用するため、またはモデル適用段階中のモデルへの入力として使用するために、抽出された機器属性特徴を出力することができる。

図７は、いくつかの実装形態に従って使用属性から特徴を抽出するための例示的なプロセス７００を示すフローチャートである。

７０２から７０４で、サービスコンピューティングデバイスは、使用属性１からＮを受信することができる。上述のように、使用属性は、機器自体から、過去の修理データから、ドメイン知識から、機器ユーザから、機器修理業者等から受信することができる。使用属性変数は連続変数でもよい。

７０６から７０８において、サービスコンピューティングデバイスは、受信した使用属性を正規化することができる。１つの非限定的な例として、正規化することは、受信した使用属性の値を、例えば０から１の範囲内になるように正規化することを含み得るが、他の多数のデータ正規化技法が当業者に明らかであろう。

７１０において、サービスコンピューティングデバイスは、正規化された使用属性変数を連結またはそうでなければ組み合わせて、使用属性特徴ベクトルを決定することができる。

７１２で、サービスコンピューティングデバイスは、抽出された使用属性の特徴を出力することができる。

図８は、いくつかの実装形態によるセンサデータから特徴を抽出するための例示的なプロセス８００を示すフローチャートである。

８０２から８０４で、サービスコンピューティングデバイスは、第１のセンサから第Ｎのセンサまでセンサデータを受信することができる。上述のように、センサデータは、機器自体から、機器に関連付けられたシステムから、過去の修理データから、機器ユーザから、機器修理業者などから受信することができる。センサデータは、高周波または低周波データであり得、連続的で密なベクトルとして表され得る。

８０６から８０８において、サービスコンピューティングデバイスは、受信したセンサデータを正規化することができる。１つの非限定的な例として、正規化することは、受信したセンサデータの値を例えば０から１の範囲に正規化することを含み得るが、当業者には他の多数のデータ正規化技術が明らかであろう。

８１０から８１２で、サービスコンピューティングデバイスは、正規化されたセンサデータに対して学習可能な特徴抽出を実行することができる。一例として、特徴は、ＬＳＴＭユニットなどの学習可能な非順次方法を使用して抽出することができる。学習可能な非順次方法のパラメータは、トレーニングプロセス中に学習される。

８１４から８１６で、サービスコンピューティングデバイスは、抽出されたセンサ特徴を平坦化（Flatten）することができる。例えば、センサデータ特徴を平坦化することは、各センサについて抽出された特徴を一次元（１−Ｄ）特徴ベクトル、例えば各センサについて単一の特徴ベクトルに変換することを含み得る。

８１８で、サービスコンピューティングデバイスは、抽出されたセンサデータ特徴ベクトルを連結またはそうでなければ結合して、単一のセンサデータ特徴ベクトルを決定することができる。

８２０で、サービスコンピューティングデバイスは、モデルトレーニング段階中のトレーニングなどのために、またはモデル適用段階中の入力として、機械学習モデルと共に使用するためのセンサデータ特徴ベクトルを出力することができる。

図９は、いくつかの実装形態によるセンサデータから特徴を抽出するための例示的なプロセス９００を示すフローチャートである。

９０２から９０４で、サービスコンピューティングデバイスは、第１のセンサから第Ｎのセンサまでセンサデータを受信することができる。上述のように、センサデータは、機器自体から、機器に関連付けられたシステムから、過去の修理データから、機器ユーザから、機器修理業者などから受信することができる。センサデータは、高周波または低周波データであり得、連続的で密なベクトルとして表され得る。

９０６から９０８において、サービスコンピューティングデバイスは、受信したセンサデータを正規化することができる。１つの非限定的な例として、正規化することは、受信センサデータの値を正規化して、例えば０から１の範囲内の値を有することを含み得るが、他の多数のデータ正規化技法が当業者に明らかであろう。

９１０から９１２で、サービスコンピューティングデバイスは、正規化されたセンサデータに対して１−Ｄ畳み込み特徴抽出を実行することができる。一例として、特徴は、１−Ｄ畳み込みフィルタを用いるような学習可能な方法を用いて抽出することができる。一組の１−Ｄ畳み込みフィルタは、関連する特徴を抽出するために畳み込みを実行する各センサ信号について時間軸を横断してもよい。例えば、各畳み込みは異なる関連特徴を抽出することができる。この結果として、センサ信号から一組の特徴が抽出される。学習可能な方法のパラメータ、例えば１−Ｄ畳み込みフィルタは、トレーニングプロセス中に学習される。

９１４から９１６で、サービスコンピューティングデバイスは、抽出されたセンサ特徴を平坦化することができる。例えば、センサデータ特徴を平坦化することは、各センサについて抽出された特徴を１‐Ｄ特徴ベクトル、例えば各センサについて単一の特徴ベクトルに変換することを含み得る。

９１８で、サービスコンピューティングデバイスは、抽出されたセンサデータ特徴ベクトルを連結またはそうでなければ結合して、単一のセンサデータ特徴ベクトルを決定することができる。

９２０で、サービスコンピューティングデバイスは、モデルトレーニング段階中のトレーニングなどのための機械学習モデルとともに使用するための、またはモデル適用段階中の入力として、センサデータ特徴ベクトルを出力することができる。

図１０Ａは、いくつかの実装形態による、イベントデータから特徴を予備的に抽出するための例示的なプロセス１０００を示すフローチャートである。いくつかの例では、イベントデータは互いに連続した依存関係を有し得るが、他の例では、イベントデータは互いに独立していてもよい。例えば、いくつかのイベントは互いに関連しているかもしれないが、他のイベントは完全に独立しているかもしれない。図１０Ａのプロセス１０００は、イベント間に連続的な依存関係がない場合、例えば、イベントが互いに独立している場合に採用され得る。

１００２で、サービスコンピューティングデバイスはイベント変数を受信することができる。例えば、イベント変数は、機器から、機器に関連付けられたシステムから、機器ユーザから、機器修理者から、または様々な他のソースから受信され得る。各イベント変数は、カテゴリカル変数である。

１００４において、サービスコンピューティングデバイスは、各イベント変数をＯＮＥ−ＨＯＴ符号化ベクトルとして符号化するためにＯＮＥ−ＨＯＴ符号化を実行することができ、ベクトルの長さはデータコーパス内の一意のイベントの数に等しい。一旦符号化されると、各データポイントについて、イベント変数は一連のＯＮＥ−ＨＯＴ符号化ベクトルを含み得る。

１００６において、サービスコンピューティングデバイスは、学習可能な次元の縮小を実行し得る。例えば、図１０に示されるように、受信されたイベント変数間に順次依存関係がないかもしれない。イベントデータが互いに独立している場合、学習可能な順次特徴抽出を実行する必要はない。次元縮小の間、高次元スパースＯＮＥ−ＨＯＴ符号化ベクトルは、学習可能な次元縮小方法を使用して低次元連続空間にマッピングされる。学習可能次元削減方法の一例は、その重みがモデルトレーニングプロセス中に学習される埋め込み行列の使用を含み得る。したがって、次元削減方法の結果は、複数の低次元密ベクトルであり得る。イベント間に逐次的な依存関係がないため、学習可能な次元の縮小方法の結果を直接機能として使用することができる。

図１０Ｂは、いくつかの実装によるイベントデータからの特徴の予備抽出のための例示的なプロセス1010を示すフローチャートである。この例では、イベントデータは互いに順次依存関係を有することができる。

１０１２で、サービスコンピューティングデバイスはイベント変数を受信することができる。例えば、イベント変数は、機器から、機器に関連付けられたシステムから、機器ユーザから、機器修理者から、または様々な他のソースから受信され得る。各イベント変数は、カテゴリカル変数である。

１０１４において、サービスコンピューティングデバイスは、各イベント変数をＯＮＥ−ＨＯＴ符号化ベクトルとして符号化するためにＯＮＥ−ＨＯＴ符号化を実行することができ、ベクトルの長さはデータコーパス内の一意のイベントの数に等しい。一度符号化されると、各データ点について、イベント変数は一連のＯＮＥ−ＨＯＴ符号化ベクトルである。

１０１６で、サービスコンピューティングデバイスは、学習可能な次元の縮小を実行し得る。例えば、高次元スパースＯＮＥ−ＨＯＴ符号化ベクトルは、学習可能な次元縮小方法を用いて低次元の連続空間にマッピングされる。学習可能次元縮小方法の一例は、その重みがモデルトレーニングプロセス中に学習される埋め込み行列の使用を含み得る。したがって、次元縮小法の結果は、一連の低次元密ベクトルである。

１０１８で、サービスコンピューティングデバイスは、学習可能な順次特徴抽出を実行することができる。例えば、サービスコンピューティングデバイスは、図３に関して上記で論じたものと同様の方法で順次特徴抽出を実行することができる。したがって、イベント変数間に逐次従属関係がある場合、逐次特徴抽出方法を用いて特徴を抽出することができ、第１の特徴１０２０に対応する最も左のベクトルはシーケンス内の第１のイベントを表し、第２の特徴１０２２はシーケンス内の第２のイベントを表し、Ｎ番目の特徴１０２４に対応する最も右のベクトルはシーケンス内の最新のイベントを表す。

１１０２で、サービスコンピューティングデバイスはイベント変数を受信することができる。例えば、イベント変数は、機器から、機器に関連付けられたシステムから、機器ユーザから、機器修理者から、または様々な他のソースから受信され得る。各イベント変数は、カテゴリカル変数である。

１１０４で、サービスコンピューティングデバイスは、各イベント変数をＯＮＥ−ＨＯＴ符号化ベクトルとして符号化するためにＯＮＥ−ＨＯＴ符号化を実行することができ、ベクトルの長さはデータコーパス内の一意のイベントの数に等しい。一旦符号化されると、各データポイントについて、イベント変数は一連のＯＮＥ−ＨＯＴ符号化ベクトルを含み得る。

１１０６で、サービスコンピューティングデバイスは、次元縮小を実行するために埋め込み層を使用することができる。例えば、図１０Ａの場合と同様に、受信されたイベント変数間に順次の依存関係はないかもしれない。次元削減の間、高次元スパースＯＮＥ−ＨＯＴ符号化ベクトルは埋め込み行列を用いて低次元連続空間に写像され、その重みはモデルトレーニングプロセスの間に学習される。したがって、次元削減方法の結果は、複数の低次元密ベクトルであり得る。イベント間に逐次的な依存関係がないため、次元削減の結果を直接機能として使用することができる。

図１１Ｂは、いくつかの実装によるイベントデータからの特徴の予備的抽出のための例示的なプロセス1110を示すフローチャートである。この例では、イベントデータは互いに順次依存関係を有することができる。

１１１２で、サービスコンピューティングデバイスはイベント変数を受信することができる。例えば、イベント変数は、機器から、機器に関連付けられたシステムから、機器ユーザから、機器修理者から、または様々な他のソースから受信され得る。各イベント変数は、カテゴリカル変数である。

１１１４で、サービスコンピューティングデバイスは、各イベント変数をＯＮＥ−ＨＯＴ符号化ベクトルとして符号化するためにＯＮＥ−ＨＯＴ符号化を実行することができ、ベクトルの長さはデータコーパス内の一意のイベントの数に等しい。一度符号化されると、各データ点について、イベント変数は一連のＯＮＥ−ＨＯＴ符号化ベクトルである。

１１１６で、サービスコンピューティングデバイスは、次元縮小を実行するために埋め込み層を使用することができる。次元削減の間、高次元スパースＯＮＥ−ＨＯＴ符号化ベクトルは埋め込み行列を用いて低次元連続空間に写像され、その重みはモデルトレーニングプロセスの間に学習される。したがって、次元削減方法の結果は、複数の低次元密ベクトルであり得る。

１１１８において、サービスコンピューティングデバイスは、ＬＳＴＭユニットを使用して順次特徴抽出を実行し得る。例えば、サービスコンピューティングデバイスは、図４に関して上記で論じたものと同様の方法で順次特徴抽出を実行することができる。したがって、イベント変数間に逐次従属関係がある場合は、逐次特徴抽出方法を用いて特徴を抽出することができる。例えば、ＬＳＴＭユニットを各ベクトル１からＮに適用して、各ベクトルから関連する特徴を抽出することができる。したがって、特徴抽出プロセスは、シーケンス内の第１のイベントを表す１１２０で示されるような左側の第１のベクトルから、シーケンス内の第２のイベントを表す１１２２で示される次のベクトルへ、１１２４で示されるように、シーケンス内の最新のイベントを表す、右側のＮ番目のベクトルへ進むことができる。同じＬＳＴＭユニットが各ベクトルから特徴を抽出し、この例に示すように、各ベクトルから特徴を抽出するために、複数のそのようなＬＳＴＭユニット、例えばＬＳＴＭ １、ＬＳＴＭ １、…、ＬＳＴＭ ｎがあり得る。

一連のイベントでは、コメントや機器情報に関してすべてのイベントが重要というわけではない。したがって、コメントに基づいて、重要なイベントのみからの機器情報（例えば、属性、使用法）の特徴が考慮されるべきである。イベントの重要性をモデル化するためのメカニズムは、以下にさらに説明される。

図１２は、いくつかの実装形態による、イベントデータから抽出された特徴の重要度モデリングのための例示的なプロセス１２００を示すフローチャートである。この例では、イベント変数間に順次依存関係はない。上記のように、特定の修理にすべてのイベントが重要というわけではない。したがって、この例では、各イベントの重要性をモデル化し、関連するイベントに高い重み付けを行う。

１２０２−１２０６は、図１０Ａのブロック１００２−１００６に対応し得る。

１２０８で、サービスコンピューティングデバイスは、例えば図３−図７に関して上述したように、フリーテキストコメント、機器属性、および使用変数から抽出された特徴を決定または他の方法で受信することができる。

１２１０で、サービスコンピューティングデバイスは、フリーテキストコメント、機器属性、および使用法変数から抽出された特徴を連結するか、そうでなければ組み合わせることができる。この連結ベクトルは事前情報のコンテキストベクトルを表す。

１２１２で、サービスコンピューティングデバイスは、コンテキストベクトルを各それぞれのイベントから決定されたそれぞれの特徴ベクトルと連結またはそうでなければ結合して、複数のコンテキスト−イベント特徴ベクトルを生成することができる。

１２１４で、サービスコンピューティングデバイスは、それぞれのスコアを割り当てるために各コンテキスト−イベント特徴ベクトルを処理することができる。例えば、各コンテキスト−イベント特徴ベクトルは、それぞれのコンテキスト−イベント特徴ベクトルに対するそれぞれのスコアを決定するために非線形関数を通過してもよい。適切な非線形関数の一例は双曲線正接（ｔａｎｈ）関数を含み得る。例えば、tanh関数が使用される場合、各コンテキスト−イベント特徴ベクトルは−１から１の範囲のスコアに変換される。したがって、１２１４での演算の結果は−１から１の範囲の複数のスコアであり得る。

１２１６で、サービスコンピューティングデバイスは、学習可能な関数を使用して複数のスコアを確率分布にマッピングして、それぞれのコンテキスト−イベント特徴ベクトルの重要度を判断することができる。スコアを確率分布にマッピングするための適切な学習可能関数の一例は、ソフトマックス関数である。ソフトマックス関数は、任意の実数値のK次元ベクトルzを実数値のK次元ベクトルσ（z）に縮小するロジスティック関数の一般化である。ここで、各エントリは０と１の間の値に正規化される。すべてのエントリの合計が１となる。関数の出力クラスの数は、シーケンス内のイベントの数と同じである。関数から取得された値は、各イベントの相対的な重要性に対応する。したがって、この例では、重要度値は０から１の間の範囲とすることができるが、本明細書の開示の恩恵を受ける他の様々なスコアリングおよび重み付け技法が当業者には明らかであろう。

１２１８で、サービスコンピューティングデバイスは、各コンテキスト−イベント特徴ベクトルについて決定されたそれぞれの重要度値をそれぞれのイベント特徴ベクトルと乗算し、それによって複数の重み付きイベント特徴ベクトルを決定し、生成することができる。
重要度値は、重み付き事象特徴ベクトルを形成するそれぞれの事象特徴ベクトルと乗算されるので、事象が重要でない場合（つまり、重要度は０）、事象特徴ベクトルは最終的に０に減少され、したがってニューラルネットワーク内のそれ以上の情報に寄与しない。

１２２０で、重要度重み付きイベント特徴ベクトルは、重み付き特徴ベクトルを１‐Ｄ特徴ベクトル、例えば単一の特徴ベクトルに変換することによって平坦化することができる。

１２２２で、イベント特徴ベクトルは、トレーニング段階中にモデルをトレーニングするため、またはモデル適用段階中に入力として使用するためなど、機械学習モデルとともに使用するために出力される。

図１３は、いくつかの実装形態による、イベントデータから抽出された特徴の重要度モデリングのための例示的なプロセス１３００を示すフローチャートである。この例では、イベント変数間に順次依存関係がある。上記のように、特定の修理にすべてのイベントが重要というわけではない。したがって、この例では、各イベントの重要性をモデル化し、関連するイベントに高い重み付けを行う。

１３０２−１３０７は、図１０Ｂのブロック１０１２−１０１８に対応し得る。

１３０８において、サービスコンピューティングデバイスは、例えば図３および図７に関して上述したように、フリーテキストコメント、機器属性、および使用変数から抽出された特徴を決定するか、そうでなければ受け取ることができる。

１３１０で、サービスコンピューティングデバイスは、フリーテキストコメント、機器属性、および使用法変数から抽出された特徴を連結するか、そうでなければ組み合わせることができる。この連結ベクトルは事前情報のコンテキストベクトルを表す。

１３１２で、サービスコンピューティングデバイスは、コンテキストベクトルを、各それぞれのイベントから決定されたそれぞれの特徴ベクトルと連結またはそうでなければ組み合わせて、複数のコンテキスト−イベント特徴ベクトルを生成することができる。

１３１４で、サービスコンピューティングデバイスは、それぞれのスコアを割り当てるために各コンテキスト−イベント特徴ベクトルを処理することができる。例えば、各コンテキスト−イベント特徴ベクトルは、それぞれのコンテキスト−イベント特徴ベクトルに対するそれぞれのスコアを決定するために非線形関数を通過してもよい。適切な非線形関数の一例は双曲線正接（ｔａｎｈ）関数を含み得る。たとえば、ｔａｎｈ関数が使用されている場合、各コンテキストイベント特徴ベクトルは−１から１の範囲のスコアに変換される。したがって、１３１４での動作の結果は、−１から１までの範囲の複数のスコアであり得る。

１３１６で、サービスコンピューティングデバイスは、学習可能な関数を使用して複数のスコアを確率分布にマッピングして、それぞれのコンテキスト−イベント特徴ベクトルの重要性を判断することができる。スコアを確率分布にマッピングするための適切な学習可能関数の一例は、ソフトマックス関数である。ソフトマックス関数は、任意の実数値のK次元ベクトルzを実数値のK次元ベクトルσ（z）に縮小するロジスティック関数の一般化である。ここで、各エントリは０と１の間の値に正規化される。すべてのエントリの合計が１になる。関数の出力クラスの数は、シーケンス内のイベントの数と同じである。関数から取得された値は、各イベントの相対的な重要性に対応する。したがって、この例では、重要度値は０から１の間の範囲とすることができるが、本明細書の開示の恩恵を受ける他の様々なスコアリングおよび重み付け技法が当業者には明らかであろう。

１３１８で、サービスコンピューティングデバイスは、各コンテキスト−イベント特徴ベクトルについて決定されたそれぞれの重要度値をそれぞれのイベント特徴ベクトルと乗算し、それによって複数の重み付きイベント特徴ベクトルを生成することができる。
重要度値は、重み付き事象特徴ベクトルを形成するそれぞれの事象特徴ベクトルと乗算されるので、事象が重要でない場合（重要度０の場合）、事象特徴ベクトルは最終的に０に減少され、したがってニューラルネットワーク内のそれ以上の情報に寄与しない。

１３２０で、重要度重み付きイベント特徴ベクトルは、重み付き特徴ベクトルを１−Ｄ特徴ベクトル、例えば単一の特徴ベクトルに変換することによって平坦化することができる。

１３２２で、イベント特徴ベクトルは、トレーニング段階中にモデルをトレーニングするため、またはモデル適用段階中に入力として使用するためなど、機械学習モデルとともに使用するために出力される。

図１４は、いくつかの実装形態によるイベントデータから抽出された特徴の重要度モデリングのための例示的なプロセス１４００を示すフローチャートである。この例では、イベント変数間に順次依存関係はない。

１４０２−１４０６は、図１１Ａのブロック１１０２−１１０６に対応し得る。

１４０８−１４２２は、図１２に関して上述したブロック１２０８−１２２２に対応し得る。

図１５は、いくつかの実装形態による、イベントデータから抽出された特徴の重要度モデリングのための例示的なプロセス１５００を示すフローチャートである。この例では、イベント
１５０２−１５０７は、図１１Ｂのブロック１１１２−１１１８に対応し得る。

１５０８−１５２２は、図１３に関して上で論じたブロック１３０８−１３２２に対応することがある。

フリーテキストコメント、機器属性、使用データ、センサデータ、およびイベントデータから抽出された特徴は、情報融合層を形成するために組み合わされ／連結され得る。組み合わされた情報はその後、複数の完全に接続されたニューラルネットワークに下流に渡されてもよい。最終的に完全に接続されたニューラルネットワークの出力は、最高の成功確率を有する１つまたは複数の修理動作である。

図１６は、いくつかの実装形態によるモデル構築のための例示的なプロセス１６００を示すフローチャートである。例えば、モデル構築およびアプリケーションプログラムを実行して、一貫した正確な構造化修理命令を出力するように構成することができる１つまたは複数の深層学習ニューラルネットワークモデルを構築することができる。いくつかの場合では、図１８に示すように、指示された修理が適用された場合、出力は成功の可能性の表示を含み得る。

いくつかの実装形態では、本明細書の修理命令モデルは、各クラスが修理を表す分類タスクとしてモデル化され得る。各修理は、システムの階層として、そして最後にアクションとして表すことができ、したがって修理は（システムの階層によって表される）ロケーションおよび修理アクションである。さまざまな修理アクションのクラス数が非常に多い可能性がある。従来、このような階層的クラスは、システムレベルクラスがサブシステムレベルクラスの優先順位として機能する階層的分類モデルを構築することによって取り扱われてきた。しかしながら、従来技術は、２つの問題をもたらす：（１）モデルの数が非常に多く、管理が困難である可能性があり、（２）出力が誤差伝播のために矛盾する可能性がある。

一方、本明細書における実装形態は、修理動作決定問題を分類問題としてだけでなく、マルチタスク分類問題としてもモデル化することができる。この場合、各タスクは修理階層の各レベルを表すことができる。

一例として、「サブシステムレベル１」、「サブシステムレベル２」、および「アクション」が３つのタスクであると仮定する。ニューラルネットワークからの出力、例えば修理命令は、タプル（サブシステムレベル１、サブシステムレベル２、…、サブシステムレベルｎ、アクション）として表すことができる。本明細書のいくつかの例におけるニューラルネットワークのモデルトレーニングは、バックプロパゲーションアルゴリズム、およびナイーブ勾配降下法、確率勾配降下法、ネスタフ運動量を伴う確率勾配降下法、アダム最適化アルゴリズム、アダグラド、ＲＭＳＰｒｏｐなどの最適化アルゴリズムを含み得る。

逆伝播アルゴリズムは、損失関数を使用してニューラルネットワーク内の各学習可能変数に関する勾配を計算する。一般に、分類技術の場合の損失関数はクロスエントロピー損失関数である。本明細書における修理動作決定の場合、それはマルチタスク分類問題としてモデル化されるので、最初に修理階層内の各レベルのクロスエントロピー損失が計算され、最後にすべてのクロスエントロピー損失が形成される。ジョイントロス関数次に、ジョイント関数を使用して、バックプロパゲーションアルゴリズムを使用して勾配を計算する。最適化関数は、各反復において計算された勾配がネットワークのパラメータを更新するために使用される場合に、結合損失関数を最小化するために使用される。したがって、修理動作を決定する場合、最適化アルゴリズムは、修理階層のレベルで同時に損失を最小化する。これにより、本明細書では単一のディープラーニングモデルが複数のタスクを実行するように学習するか、そうでなければトレーニングされる（この場合、修理階層の各レベルを予測する）。さらに、損失は互いに独立しているため、階層の上から下へのエラー伝播はない。このトレーニング／モデル構築方法論は、適切な修理を決定するために多数の修理クラスを取り扱うことができる単一のモデルをもたらす。

図１６に示されるように、プロセスは、モデル構築およびアプリケーションプログラムの実行によってサービスコンピューティングデバイスによって実行され得る。

１６０２で、サービスコンピューティングデバイスは、フリーテキスト変数にアクセスするか、そうでなければ受け取る。たとえば、フリーテキストの変数は、上で説明したソースのいずれかから受け取ることができる。

１６０４で、サービスコンピューティングデバイスは、例えば、図３−図４に関して上述したように、受信したフリーテキスト変数から特徴を抽出することができる。

１６０６で、サービスコンピューティングデバイスは機器属性にアクセスするか、そうでなければ受信する。例えば、機器属性は、上で論じられたソースのうちの任意のものから受信され得る。

１６０８において、サービスコンピューティングデバイスは、例えば、図５および図６に関して上述したように、受信した機器の属性から特徴を抽出することができる。

１６１０で、サービスコンピューティングデバイスは、使用法属性にアクセスするか、そうでなければ受信する。例えば、使用属性は、上記で論じられたソースのうちのいずれからも受信され得る。

１６１２で、サービスコンピューティングデバイスは、たとえば図７に関して上で説明したように、受信した使用属性から特徴を抽出することができる。

１６１４で、サービスコンピューティングデバイスは、センサデータにアクセスするか、そうでなければ受信する。例えば、センサデータは、上述の情報源のうちの任意のものから受信されてもよい。

１６１６で、サービスコンピューティングデバイスは、例えば、図８−図９に関して上述したように、受信したセンサデータから特徴を抽出することができる。

１６１８で、サービスコンピューティングデバイスは、イベントデータにアクセスするか、そうでなければ受信する。例えば、イベントデータは、上で論じられたソースのうちの任意のものから受信され得る。

１６２０で、サービスコンピューティングデバイスは、例えば、図１０Ａ−図１５に関して上記で説明したように、受信したイベントデータから特徴を抽出することができる。

１６２２で、サービスコンピューティングデバイスは、フリーテキストコメント、機器属性、使用データ、センサデータ、およびイベントデータから抽出された特徴を連結または他の方法で組み合わせることによって情報融合層を形成することができる。組み合わされた情報はその後、１つまたは複数の完全に接続されたニューラルネットワークに下流に渡され得る。

１６２４で、サービスコンピューティングデバイスは、組み合わされた情報を１つまたは複数の深層学習ニューラルネットワークに適用することができる。例えば、組み合わされた情報は、ディープラーニングニューラルネットワークをトレーニングするために使用されてもよく、または適用段階では、組み合わされた情報はディープラーニングニューラルネットワークへの入力として使用されてもよい。

１６２６から１６２８で、サービスコンピューティングデバイスは、システムの階層内の各修理動作および対応する修理動作を表すことができる。したがって、修理動作は、システムの階層内の位置および対応する動作であり得る。システムの階層と、フリーテキスト変数、機器属性、使用属性、センサデータ、およびイベントデータに対する対応する修理動作は、例えば図１に関して上述した修理履歴データから取得することができる。修理処置の推奨は分類問題としてモデル化されているため、過去の修理から取得された階層レベルがモデルの構築に使用される目標変数になる場合がある。例えば、１６２６の階層レベル１はシステムによって表されてもよく、１６２８の階層レベルＮはそのシステム内の特定の部分として表されてもよい。一例として、階層レベル１が自動車エンジンを表し、階層レベル３（図１６には示されていない）が自動車エンジンのキャブレターを表していると仮定する。対応する修理動作もまた階層の一部であり得る。修理における階層関係の例は、自動車エンジン→キャブレター→交換であり得、自動車エンジンは階層レベル１であり、キャブレターは階層レベル２であり、「交換」（修理行為である）は階層レベル３である。階層関係は修理処置（カーエンジン内のキャブレターの交換）に対応する。

１６３０から１６３２で、サービスコンピューティングデバイスは、バックプロパゲーションアルゴリズムなどの損失関数を適用することができる。例えば、バックプロパゲーションアルゴリズムを用いて、損失関数を用いてニューラルネットワーク内の各学習可能変数に関する勾配を計算することができる。いくつかの例では、損失関数はクロスエントロピー損失関数であり得る。本明細書における修理動作決定の場合、それはマルチタスク分類問題としてモデル化される。

１６３４で、サービスコンピューティングデバイスは、複合損失関数を適用することができる。例えば、１６３０−１６３２で修理階層内の各レベルのクロスエントロピー損失を計算した後、サービスコンピューティングデバイスは、クロスエントロピー損失を足し合わせて、結合損失関数または他の結合損失関数を形成することができる。結合損失関数は次に、逆伝播アルゴリズムを用いて勾配を計算するために使用されてもよい。結合損失がLで表され、モデルのパラメータがｘで表される場合、モデルパラメータに対する損失の勾配∂Ｌ／∂ｘが計算される。計算された勾配を使用して、最適化アルゴリズムは、例えば、更新規則ｘ ＝ ｘ −α∂Ｌ／∂ｘを使用してモデルパラメータｘを更新する。ここで、αは学習率である。更新規則は、使用されている最適化アルゴリズムによって異なる。最適化アルゴリズムの例としては、Stochastic Gradientとその変種がある。結合損失関数の計算、勾配計算、モデルパラメータの更新は、損失が最小化されている結合損失に収束するまで続ける。

１６３６で、サービスコンピューティングデバイスは、計算された損失が最小化されているかどうかを判断することができる。そうであれば、プロセスは１６３８に進む。そうでなければ、プロセスは１６４０に進む。

１６３８で、損失がまだ最小化されていない場合、サービスコンピューティングデバイスは、逆伝播アルゴリズムを使用して勾配計算を実行することができる。例えば、組合せ損失関数は、逆伝搬アルゴリズムを使用して勾配を計算するために使用され得る。

１６４０で、サービスコンピューティングデバイスは、１６４０で計算された勾配を適用し、モデルパラメータを更新する。次にプロセスはブロック１６０４、１６０８、１６１２、１６１６および１６２０に戻り、更新されたモデルパラメータを適用する。したがって、プロセスは、各損失において計算された勾配がニューラルネットワークのパラメータを更新するために使用される場合に、結合損失関数を最小化するために１つまたは複数の最適化反復を実行することができる。

１６４２で、損失が最小化されると、プロセスは終了し、モデルパラメータが保存される。例えば、プロセス１６００は、損失が最小化される場合に結合損失に収束するまで継続してもよい。

図１７は、いくつかの実装形態によるモデル構築のための例示的なプロセス１７００を示すフローチャートである。例えば、モデル構築およびアプリケーションプログラムは、一貫した正確な構造化された修理命令を出力するように構成され得る、深層学習ニューラルネットワークモデルを構築するためにサービスコンピューティングデバイスによって実行され得る。

いくつかの場合では、図１８に示すように、指示された修理が適用された場合、出力は成功の可能性の表示を含み得る。

図１７において、ブロック１６０２−１６２４は、図１６に関して上述したブロック１６０２−１６２４と同じかまたは類似している。

１７０２から１７０４で、サービスコンピューティングデバイスは、システムの階層内の各修理動作および対応する動作を表すことができる。したがって、修理動作は、システムの階層内の位置および対応する動作であり得る。システムの階層、およびフリーテキスト変数、機器属性、使用属性、センサデータ、およびイベントデータに対する対応する修理動作は、修理履歴データから取得することができる。修理処置の推奨は分類問題としてモデル化されているため、過去の修理から取得された階層レベルがモデルの構築に使用される目標変数になる場合がある。

例えば、階層レベル目標変数は、各階層レベル出力１７０２−１７０４に対応し得る。この例では、階層レベル１の目標変数１７０６は、階層レベル１の出力１７０２に対応し、階層レベルＮの目標変数１７０８は、階層レベルＮの出力に対応する。

１７１２−１７１４で、サービスコンピューティングデバイスは、対応する階層レベル１目標変数１７０６−１７０８に基づいて、各階層レベル出力１７０２−１７０４についてクロスエントロピー損失を決定することができる。例えば、各階層レベルについてクロスエントロピー損失関数は、各階層レベルについてのモデルの出力と対応する目標変数１７０６−１７０８を使用して計算される。

１７１６で、各階層レベル１−Ｎの計算されたクロスエントロピー損失関数を使用して、サービス計算装置は、計算された損失関数を一緒に足し合わせて組み合わせた損失を決定することによって、組み合わせた損失関数を計算することができる。上述したように、結合損失がＬによって表され、モデルのパラメータがｘによって表される場合、モデルパラメータに対する損失の勾配∂Ｌ／∂ｘが計算される。計算された勾配を使用して、最適化アルゴリズムは、例えば、更新規則ｘ ＝ ｘ −α∂Ｌ／∂ｘを使用してモデルパラメータｘを更新する。ここで、αは学習率である。更新規則は、使用されている最適化アルゴリズムによって異なる。最適化アルゴリズムの例としては、Stochastic Gradientとその変種がある。結合損失関数の計算、勾配計算、モデルパラメータの更新は、損失が最小化されている結合損失に収束するまで続けられる。

図１７において、ブロック１６３４−１６４２は、図１６に関して上述したブロック１６３４−１６４２と同じまたは類似である。

図１８は、いくつかの実装形態による修理処置を決定し実行するための例示的なプロセス１８００を示すフローチャートである。いくつかの例では、プロセス１８００は、プロセス１８００に記載されているオペレーションを実行するため、データ準備プログラム１２８、関連データ抽出プログラム１３０、特徴抽出プログラム１３２、モデル構築およびアプリケーションプログラム１３４、ならびに修理計画実行プログラム１３６のうちの１つまたは複数を呼び出して、それらのうちのいくつかを実行することができる。

したがって、本明細書のいくつかの例は、関連するデータと共に修理履歴に基づいてトレーニングおよびディープラーニングモデルを使用することによって修理動作を決定するためのシステムを含む。システムによって提供される機能は、機器が故障したときの修理動作のコースを決定することを含み得るがこれに限定されない、例えば、診断と修理の時間を減らす、設備の可用性を高める、修理ミスの数を減らす等を提供する。本明細書の実装形態は、スタンドアロンソリューションとして使用することができ、あるいは保守管理および最適化のための他の機能を提供する既存のシステムと統合することができる。

１８０２で、トレーニングデータとしての第１の機器に対する修理歴データから特徴を抽出する。トレーニングデータは、第１の機器に関するユーザのコメントに関連付けられているフリーテキストの変数、第１の機器に関連付けられている使用属性、第１の機器に関連した機器属性、第１の機器に牽連するセンサデータ、或いは、第１の機器に関連付けられたイベントデータである。コンピューティングデバイスは、トレーニングデータとして機器の修理履歴データを使用して、ディープラーニングモデルをトレーニングすることができる。トレーニングの詳細は、図１から図１６に関して上述した。

１８０４で、マルチタスクを実行するため修理階層の各レベルの予測に対して、トレーニングデータを用いて、多層モデルとしてのディープラーニングモデルの訓練をする。コンピューティングデバイスは機器に関連する修理要求を受信することができる。例えば、図２に関して上述したモデル適用段階の間、図２に示すように、コンピューティング装置は、図１に関して上述したクライアントコンピューティング装置のうちの１つから修理要求を受け取ることができる。

１８０６で、コンピューティングデバイスは、以下のうちの１つまたは複数から特徴を抽出することができる。機器に関するユーザのコメントに関連付けられたフリーテキスト変数、機器に関連する使用属性、機器に関連する機器属性 機器に関連するセンサデータ、機器に関連するイベントデータ。

１８１０で、コンピューティングデバイスは、１つまたは複数の修理動作を決定するために、抽出された特徴をトレーニングされたディープラーニングモデルへの入力として使用することができる。

１８１２で、コンピューティングデバイスは、1または複数の修理を決定するため、ディープラーニングモデルへの入力として抽出された特徴を使用する、つまり、１つまたは複数の修理動作の成功の確率がしきい値確率を下回るかどうかを判断することができる。例えば、場合によっては、成功の可能性が低い場合、修理要求に応答して修理動作が提供されないことがある。したがって、成功の確率が閾値を超えない場合、プロセスはブロック１８１４に進み得る。あるいは、成功の確率がしきい値を超えている場合、プロセスはブロック１８１６に進むことができる。

１８１４で、成功の確率が閾値を超えない場合、コンピューティングデバイスは、修理要求が、修理アクションを決定するのに十分な情報を提供しなかったことを示す「わからない」メッセージの指示を送信することができる。

１８１６で、成功確率がコストを超える場合、コンピューティングデバイスは、１つまたは複数の機械学習モデルの出力に基づいて修理計画および／または修理指示を決定することができる。

１８１８で、コンピューティングデバイスは、機器に対して修理動作を実行することに関して修理者に指示するように修理者コンピュータに命令を送信することができる。

１８２０で、コンピューティングデバイスは、機器を修理するための遠隔操作を開始することができ、および／または修理計画の実行を開始することができる。

１８２２で、コンピューティングデバイスは、修理者が計画を見て修理を開始できるように修理計画を修理者のコンピュータに送信することができる。

本明細書に記載の例示的なプロセスは、説明の目的で提供されたプロセスの単なる例である。本明細書の開示に照らして、多数の他の変形が当業者に明らかであろう。さらに、本明細書の開示は、プロセスを実行するための適切なシステム、アーキテクチャ、および環境のいくつかの例を説明しているが、本明細書の実装形態は、示し説明した特定の例に限定されない。さらに、本開示は、説明され図面に示されるように、様々な例示的実装形態を提供する。しかし、本開示は、本明細書で説明および図示された実装形態に限定されず、知られるように、または当業者に知られるようになるように、他の実装形態に拡張することができる。

本明細書に記載の様々な命令、プロセス、および技法は、コンピュータ可読媒体に格納され、本明細書のプロセッサによって実行されるプログラムなど、コンピュータ実行可能命令の一般的な文脈で検討することができる。一般に、プログラムは、特定のタスクを実行するため、または特定の抽象データ型を実装するためのルーチン、モジュール、オブジェクト、コンポーネント、データ構造、実行可能コードなどを含む。これらのプログラムなどは、ネイティブコードとして実行されてもよく、または仮想マシンまたは他のジャストインタイムコンパイル実行環境などでダウンロードされ実行されてもよい。通常、プログラムの機能は、様々な実装形態で望まれるように組み合わせるか分散させることができる。これらのプログラムおよび技術の実施は、コンピュータ記憶媒体に格納されてもよく、または何らかの形態の通信媒体を介して送信されてもよい。

主題は構造的特徴および／または方法論的行為に特有の言語で説明されてきたが、添付の特許請求の範囲に定義された主題は必ずしも説明された特定の特徴または行為に限定されない。そうではなく、特定の特徴および行為は、特許請求の範囲を実施する例示的形態として開示されている。

Claims (14)

1. 一つ以上のプロセッサと、
   実行可能命令を保持し、前記プロセッサによって実行されるとき、前記プロセッサが以下の動作を実行するよう構成された１つまたは複数の非一時的コンピュータ可読媒体とを有するシステムにおいて、
   前記プロセッサは、
   第１の機器の過去の修理履歴データを受信し、
   前記第１の機器の修理履歴データに含まれる、前記第１の機器に関するコメントに関連付けられたフリーテキスト変数から、前記コメントに対応する複数のベクトルを集約して第１の特徴を抽出し、
   前記フリーテキスト変数から抽出された前記第1の特徴と、前記第１の機器の修理履歴データに含まれる前記第１の機器に関連する使用属性、前記第１の機器に関連する機器属性、前記第１の機器に関連するセンサデータ、及び、前記第１の機器に関連するイベントデータから抽出された第２の特徴と、を連結し、
   ディープラーニングモデルのトレーニングデータとして、前記連結された特徴が入力されると、各階層における各損失レベルを計算し、各損失レベルを足し合わせて求められる結合損失が最小となるモデルパラメータを保存して前記ディープラーニングモデルをトレーニングし、
   第２の機器に関連した修理要求を受信し、
   受信した修理要求に基づいて修理動作を決定するために前記ディープラーニングモデルを使用することを特徴とする機器修理管理システム。
2. 請求項１に記載の機器修理管理システムにおいて、
   前記プロセッサは、
   前記第２の機器に関連するフリーテキスト変数、使用属性、及び機器属性のうちの少なくとも１つから抽出された特徴に基づいてコンテキストベクトルを決定し、
   前記コンテキストベクトルに少なくとも部分的に基づいてイベントデータ特徴ベクトルを重み付けすることを特徴とする機器修理管理システム。
3. 請求項１に記載の機器修理管理システムにおいて、
   前記プロセッサは、
   前記ディープラーニングモデルのトレーニング中に、損失関数を使用して前記ディープラーニングモデル内の各学習可能な変数に関して勾配を計算するためにバックプロパゲーションアルゴリズムを使用することを特徴とする機器修理管理システム。
4. 請求項１に記載の機器修理管理システムにおいて、
   前記プロセッサによって実行される前記ディープラーニングモデルは、ディープラーニングニューラルネットワークまたはリカレントニューラルネットワークのいずれかであることを特徴とする機器修理管理システム。
5. 請求項１に記載の機器修理管理システムにおいて、
   前記プロセッサは、
   １つまたは複数の修理行為および各修理行為について決定されたそれぞれの成功確率に基づいて修理計画を決定することを特徴とする機器修理管理システム。
6. 請求項５に記載の機器修理管理システムにおいて、
   前記プロセッサは、
   修理部品の注文を送信、
   修理を実施するための労働力を割り当てるための通信を送信、
   修理の修理時間をスケジュールするための通信を送信、及び、
   少なくとも部分的に修理を実施するために機器上で遠隔的に手順を開始の少なくとも一つに基づいて、修理計画を実行することを特徴とする機器修理管理システム。
7. 一つ以上のプロセッサと、
   実行可能命令を保持し、前記プロセッサによって実行されるとき、前記プロセッサが以下の動作を実行するよう構成された１つまたは複数の非一時的コンピュータ可読媒体とを有する機器修理管理システムによる修理方法において、
   前記プロセッサは、
   第１の機器の過去の修理履歴データを、第１の計算装置によって受信し、
   前記第１の機器の修理履歴データに含まれる、前記第１の機器に関するコメントに関連付けられたフリーテキスト変数から、前記コメントに対応する複数のベクトルを集約して第1の特徴を抽出し、
   前記フリーテキスト変数から抽出された前記第1の特徴と、前記第１の機器の過去の修理履歴データに含まれる前記第１の機器に関連する使用属性、前記第１の機器に関連する機器属性、前記第１の機器に関連するセンサデータ、及び、前記第１の機器に関連するイベントデータから抽出された第２の特徴と、を連結し、
   ディープラーニングモデルのトレーニングデータとして、前記連結された特徴が入力されると、各階層における各損失レベルを計算し、各損失レベルを足し合わせて求められる結合損失が最小となるモデルパラメータを保存して前記ディープラーニングモデルをトレーニングし、
   第２の機器に関連した修理要求を受信し、
   受信した修理要求に基づいて少なくとも１つの修理動作を決定するために機械学習モデルを使用することを有することを特徴とする機器修理管理システムによる修理方法。
8. 請求項７に記載の機器修理管理システムによる修理方法において、
   さらに、前記第２の機器に関連付けられている、前記第２の機器に関するコメントに関連付けられたフリーテキストの変数、前記第２の機器に関連する使用属性、前記第２の機器に関連付けられている機器属性、前記第２の機器に関連するセンサデータ、及び前記第２の機器に関連するイベントデータの少なくとも一つを含むデータから特徴を抽出し、
   前記抽出された前記第２の機器に関連付けられた特徴を前記機械学習モデルに適応して少なくとも一つの修理動作を決定することを特徴とする機器修理管理システムによる修理方法。
9. 請求項８に記載の機器修理管理システムによる修理方法において、
   前記第２の機器に関連するイベントデータから複数のイベントデータ特徴ベクトルとして特徴を抽出し、
   前記第２の機器に関連するフリーテキスト変数、使用属性、及び機器属性のうちの少なくとも１つから抽出された特徴に基づいてコンテキストベクトルを決定し、
   前記コンテキストベクトルに少なくとも部分的に基づいてイベントデータ特徴ベクトルを重み付けすることを特徴とする機器修理管理システムによる修理方法。
10. 請求項７に記載の機器修理管理システムによる修理方法において、
    前記機械学習モデルのトレーニング中に、損失関数を使用して前記機械学習モデル内の各学習可能な変数に関して勾配を計算するためにバックプロパゲーションアルゴリズムを使用することを特徴とする機器修理管理システムによる修理方法。
11. 請求項７に記載の機器修理管理システムによる修理方法において、
    前記プロセッサによって実行される前記機械学習モデルは、ディープラーニングニューラルネットワークまたはリカレントニューラルネットワークのいずれかであることを特徴とする機器修理管理システムによる修理方法。
12. 請求項７に記載の機器修理管理システムによる修理方法において、
    １つまたは複数の修理行為および各修理行為について決定されたそれぞれの成功確率に基づいて修理計画を決定することを特徴とする機器修理管理システムによる修理方法。
13. 請求項１２に記載の機器修理管理システムによる修理方法において、
    修理部品の注文を送信、
    修理を実施するための労働力を割り当てるための通信を送信、
    修理の修理時間をスケジュールするための通信を送信、及び、
    少なくとも部分的に修理を実施するために機器上で遠隔的に手順を開始の少なくとも一つに基づいて、修理計画を実行することを特徴とする機器修理管理システムによる修理方法。
14. １つまたは複数のプロセッサによって実行されたときに、１つまたは複数のプロセッサに以下の動作を実行するようにプログラムする命令を格納する１つまたは複数の非一時的コンピュータ可読媒体において、前記動作は、
    第１の機器の過去の修理履歴データを受信し、
    前記第１の機器の修理履歴データに含まれる、前記第１の機器に関するコメントに関連付けられたフリーテキスト変数から、前記コメントに対応する複数のベクトルを集約して第１の特徴を抽出し、
    前記フリーテキスト変数から抽出された前記第1の特徴と、前記第１の機器の過去の修理履歴データに含まれる前記第１の機器に関連する使用属性、前記第１の機器に関連する機器属性、前記第１の機器に関連するセンサデータ、及び、前記第１の機器に関連するイベントデータから抽出された第２の特徴と、を連結し、
    ディープラーニングモデルのトレーニングデータとして、前記連結された特徴が入力されると、各階層における各損失レベルを計算し、各損失レベルを足し合わせて求められる結合損失が最小となるモデルパラメータを保存して前記ディープラーニングモデルをトレーニングし、
    第２の機器に関連した修理要求を受信し、
    受信した修理要求に基づいて少なくとも１つの修理動作を決定するために前記ディープラーニングモデルを使用することを有することを特徴とするコンピュータ可読媒体。

Images