JP7242585B2 - リコメンデーションシステムおよびリコメンデーション方法 - Google Patents

Description

本発明は、推論モデルを用いて課題に対して推論を行い、解決策を提示する技術に関する。

ＩｏＴ（Internet of Things）が広がる現代の社会において、保守メンテナンス業務に関するＩｏＴソリューションの開発が注目されている。また、人工知能（ＡＩ）を用いた推論により、課題に対して解決策を提示するソリューションが実用化されつつある。ＡＩとしては、例えばＤＮＮ(Deep Neural Network)等を応用した推論モデル（学習モデル）が使用される。推論モデルは機能的には関数近似器の一種である。

ここで、ＩｏＴソリューションの一例となる修理リコメンデーションについて説明する。修理リコメンデーションでは、推論モデルは過去の情報である対象機器の故障・修理履歴から、特定の事象の相関や関係性を導き出すように構成される。推論モデルを構成するために、機械学習や統計的手法（以下、「機械学習等」と称する。）の技術が活用される。そのようなアプリケーションでは、たとえば、ユーザ（修理担当者等）が設備機器の故障状況に関する情報を端末装置に入力して推論モデルを利用すると、推論モデルは修理箇所や修理方法を提案する。

特許文献１には、エレベータコントローラと、保守員が保守端末を操作した一連の操作履歴を記憶する操作履歴記憶手段と、不具合情報を解析し解析結果を出力する不具合情報解析手段と、操作履歴と解析結果を教師データにした学習結果を出力する学習処理手段と、該学習結果を基にして新規の不具合情報に対応する適切な作業手順を推論する推論手段と、を備えるエレベータシステムが開示されている。

特開２０１９－０１８９７９号公報

ＡＩの予測精度向上を目的とした技術開発の進展によって、推論モデルのアルゴリズムのブラックボックス化が加速している。そのため、推論モデルを利用するユーザが推論モデルの予測や判断の妥当性を客観的に評価することが困難になっている。

従来の修理リコメンデーションでは、推論モデルは予測結果を示してはくれるが、それだけでは、修理担当者が次のアクションを起こすための根拠が不足している。すなわち、推論モデルの出力に対して「信頼に足りうる結果が出ているのか」、「実施すれば本当に直るのか」といった観点での納得感を修理担当者に持ってもらうことが、修理担当者の修理に対する意思決定を促すために重要である。

修理担当者に納得感を持ってもらうために、各出力に対して確度を示すことは１つの解決策になる。非常に高い確度の出力が１つあれば、その１つの出力のみを、高い確度の出力が２つあれば、その２つの出力のみを考慮すればよいという感触が得られ、修理作業の目処が立つからである。

しかし、一方で「本当にその確度は信頼に足りるか」という点に関しては、過去の修理履歴による算出結果という点で納得する修理担当者もいれば、納得しない修理担当者もいる。数値のみでは納得感を得られない修理担当者へ、別の形のフォローが必要であるといえる。

推論モデルは過去の修理履歴を用いて、機械学習によって作られるが、「何故この修理を実施すべきか」という根拠については提示しない。修理担当者が過去の作業報告書を自分で参照することで、修理の根拠を得られる可能性はある。しかし、仮に納得感が高い根拠がいずれかの作業報告書に記入されているとしても、出力に対して対応付けられていない作業報告を、修理担当者が限られた修理時間内に自力で見つけ出すことは困難である。

修理の根拠を得るために、過去の作業報告書を検索する方法も考えられるが、どのように検索すればよいかが明確でなかったり、検索によって引用された作業報告書について、記載の実態は所望のものではなかったりする等し、いたずらに修理担当者の意思決定までの時間を延ばしてしまうリスクがある。

そこで本発明の課題は、推論モデルの推論結果に対して、作業担当者が納得感を得るための情報、言い換えれば、作業担当者にとって真に必要な情報が記載されている作業報告書を、迅速に抽出することである。

本発明の好ましい一側面は、推論モデルと、推論モデルの質問を入力する入力部と、推論モデルの回答を出力する出力部と、入力ノードと出力ノードを有し、推論の段階をリンクで表現する推論ネットワークと、推論モデルの回答に基づいて、推論ネットワークの出力ノードを検索するネットワーク検索部と、を備えるリコメンデーションシステムである。

本発明の好ましい他の一側面は、項目分けされたテキストからなる報告書を複数含む事例データベースを準備する、事例データベース生成工程、報告書の各々に対応してラベルを付加する、ラベル付加工程、項目分けされたテキストの少なくとも一部を質問としラベルを回答として教師データセットを生成し、教師データベースを生成する、教師データベース生成工程、教師データセットを用いて推論モデルを学習する、モデル学習工程、報告書の項目毎に、複数の報告書のテキストを類似度に基づいてグルーピングしてグループを生成する、グループ化工程、グループの間にリンクを形成して推論ネットワークを生成する、ネットワーク化工程、推論モデルと推論ネットワークを実装する、実装工程、を実行する、リコメンデーションシステムの構成方法である。

本発明の好ましい他の一側面は、実装した推論モデルで推論を行って回答を得る、推論工程、回答に基づいて、実装した推論ネットワークの出力ノードを抽出する、出力ノード抽出工程、を実行するリコメンデーション方法である。

推論モデルの推論結果に対して、作業担当者にとって真に作業に必要な情報を、迅速に抽出することができる。

修理リコメンデーションの全体像を説明する概念図。 修理リコメンデーションシステムの構成例を示すブロック図。 推論モデルと推論ネットワークの生成と実装の処理を示す流れ図。 報告書の内容の一例を示す表図。 事例ＤＢのデータ構成の例を示す表図。 教師ＤＢのデータ構成の例を示す表図。 教師ＤＢの他のデータ構成の例を示す表図。 教師ＤＢの他のデータ構成の例を示す表図。 報告書の項目のノードの間をリンクで接続した概念図。 報告書の項目のノードとリンクをグルーピングする概念図。 推論ネットワークの概念図。 推論ネットワークの構成を規定するネットワークデータの一例を示す表図。 修理リコメンデーション処理の流れを示す流れ図。 表示される推論モデルの回答および抽出されたノードの例を示すイメージ図。 表示される推論モデルの回答および抽出されたノードの例を示すイメージ図。 表示される推論モデルの回答および抽出されたノードの例を示すイメージ図。 表示される推論モデルの回答および抽出されたノードの例を示すイメージ図。 実施例２の推論モデルと推論ネットワークの生成と実装の処理を示す流れ図。 実施例３の修理リコメンデーション処理の流れを示す流れ図。

以下、実施の形態について図面を用いて詳細に説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。

以下に説明する発明の構成において、同一部分又は同様な機能を有する部分には同一の符号を異なる図面間で共通して用い、重複する説明は省略することがある。

同一あるいは同様な機能を有する要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。ただし、複数の要素を区別する必要がない場合には、添字を省略して説明する場合がある。

本明細書等における「第１」、「第２」、「第３」などの表記は、構成要素を識別するために付するものであり、必ずしも、数、順序、もしくはその内容を限定するものではない。また、構成要素の識別のための番号は文脈毎に用いられ、一つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。

図面等において示す各構成の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面等に開示された位置、大きさ、形状、範囲などに限定されない。

本明細書で引用した刊行物、特許および特許出願は、そのまま本明細書の説明の一部を構成する。

＜１．リコメンデーションシステムの全体像＞
図１は、実施例の修理リコメンデーションシステムを使用する背景を説明する概念図である。顧客・ユーザ１０００の運用部門１００１では、運用担当者１０１１が、設備機器１０１２を点検・監視して、その状況に関する情報を端末装置に入力して、製造業者２０００の販売・保守部門２１２に問い合わせると、販売・保守部門２１２は必要なサービスや部品を顧客・ユーザ１０００に提供する。また、保守実績データは、設計・製造部門２１１にフィードバックされ、品質向上の検討や、設計変更等に反映される。

販売・保守部門２１２内では、顧客・ユーザ１０００からの問い合わせを受付担当者２０２１が受付、保守マネージャに修理依頼を行う。保守マネージャは作業計画を作成し、保守担当者（以下「ユーザ」ということがある）２００に作業を割り当てる。ユーザ２００は、故障原因分析を行い、実際の修理を実施する。

例えば、機器が発するアラームや、機器がある現場の運用担当者１０１１や作業員などからの通報などを受け、ユーザ２００は対象の設備機器１０１２がある現場に駆け付けて、対象機器の事象を把握する。その後、ユーザ２００は、対象機器の事象を説明する情報（現象コメントなど）を端末装置３００に入力する。なお、ユーザ２００は、何らかの方法により事前に機器の事象についての情報を持っていてもよい。また、端末装置３００への入力情報は、現場の運用担当者１０１１や作業員などからのコメントを含んでもよい。端末装置３００としては、タブレット型端末等の携帯可能なものを用いてもよい。

製造業者２０００の販売・保守部門２１２の受付担当者２０２１は、顧客・ユーザ１０００の運用担当者１０１１からの一報を受け付ける。あるいは、販売・保守部門２１２の保守担当者２００からの情報を受け付ける。このとき、受付担当者２０２１において問題を解決できれば、保守マネージャや保守担当者の負担が軽減できる。また、受付担当者２０２１の故障受付の段階で問題解決のための情報が入手できれば、後工程での作業効率が向上する。よって、１次解決率の向上は重要課題といえる。このためのシステムとして、修理リコメンデーションシステムの活用が有効である。

修理リコメンデーションシステム１００は、ユーザ２００により入力された現象コメントなどの入力情報に基づいて、入力情報に対する対処方法（修理）などについてのリコメンド情報（「提案」という）を出力する。修理には、機器の調整や保守も含まれる。そして、修理リコメンデーションシステム１００が、ネットワーク等を介して、リコメンド情報をユーザ２００の端末装置３００に送信し、端末装置３００にリコメンド情報が表示される。ユーザ２００は、端末装置３００に表示されたリコメンド情報を参照して、実施する対処方法（修理）を判断する。

修理リコメンデーションシステム１００は、例えばアプリケーションサーバのような情報処理装置（コンピュータ）で構成される。端末装置３００は、例えば携帯用情報通信端末のような情報処理装置で構成される。修理リコメンデーションシステム１００と端末装置３００の間は、有線もしくは無線のネットワークで接続される。もっとも、修理リコメンデーションシステム１００と端末装置３００を一体として構成してもなんら問題はない。

＜２．リコメンデーションシステムの構成＞
図２は、修理リコメンデーションシステム１００の構成例を示すブロック図である。前述のように、修理リコメンデーションシステム１００はコンピュータであり、コンピュータとして一般的に備える入力装置（キーボード、ポインティングデバイス等）、出力装置（プリンタ、ディスプレイ等）、処理装置および記憶装置（磁気ディスク装置、半導体メモリ等）を備える。

本実施例では計算や制御等の機能は、記憶装置に格納されたプログラムが処理装置によって実行されることで、定められた処理を他のハードウェアと協働して実現される。処理装置が実行するプログラム、その機能、あるいはその機能を実現する手段を、「～機能」、「～手段」、「～部」等と呼ぶ場合がある。図２では、コンピュータが当然備える構成は省略し、計算や制御やデータベース等の機能的な構成を中心に示している。また、各部を接続して情報をやりとりするバスを備えているが、図示はしていない。

修理リコメンデーションシステム１００は、入力部１０１と出力部１０２を備える。
入力部１０１は、キーボードやマウス等の他、必要により端末装置３００等外部からのデータを入力するインタフェースの機能を含むものとする。入力部１０１は、例えば端末装置３００を介してユーザ２００からの問い合わせを受信することができる。

出力部１０２は、ディスプレイやプリンター等の他、必要により端末装置３００等外部へのデータを出力するインタフェースの機能を含むものとする、出力部１０２は、例えば端末装置３００を介してユーザ２００への提案を送信することができる。

推論モデル１０３は、例えば学習済みのＤＮＮで構成されており、ユーザ２００からの問い合わせ（質問）を受けて推論を行い、提案（回答）を出力する。修理リコメンデーションシステム１００は、また推論ネットワーク１０４を備える。推論ネットワーク１０４については、後に詳細に説明する。

修理リコメンデーションシステム１００は、磁気ディスク装置等の記憶装置に、事例データベース（ＤＢ）１０５と教師ＤＢ１０６を備える。また、処理装置がソフトウェアを実行することにより実現される、モデル学習部１０７、ベクトル化部１０８、教師データ生成部１０９、グループ化部１１０、代表テキスト生成部１１１、ネットワーク生成部１１２、ネットワーク検索部１１３を備える。

事例ＤＢ１０５には、例えば過去の報告書等を内容とする事例が蓄積されている。教師データ生成部１０９は、事例ＤＢ１０５のデータを基にして教師データを生成する。教師データは、教師ＤＢ１０６に格納される。

モデル学習部１０７は、教師ＤＢ１０６の教師データを用いて推論モデル１０３の学習を行う。ベクトル化部１０８は、推論モデル１０３にテキストデータを入力する際に、テキストのベクトル化を行う。テキストのベクトル化については、種々の公知技術がある。

グループ化部１１０は、事例ＤＢ１０５の過去の報告書等のテキストの内容をグループ化する。代表テキスト生成部１１１は、グループ化したテキストについて代表テキストを生成する。ネットワーク生成部１１２は、グループ化したテキストに基づいて、推論ネットワーク１０４を生成する。ネットワーク検索部１１３は、推論モデル１０３の回答を基にして、推論ネットワーク１０４を検索する。

以上の構成は、単体のコンピュータで構成してもよいし、あるいは、任意の部分がネットワークで接続された、あるいは、オフラインの他のコンピュータで構成されてもよい。

例えば、推論モデル１０３や推論ネットワーク１０４の生成は、オフラインの他のコンピュータで行い、生成した推論モデル１０３や推論ネットワーク１０４を、修理リコメンデーションシステム１００に実装してもよい。その場合には、修理リコメンデーションシステム１００は、入力部１０１、出力部１０２、推論モデル１０３、推論ネットワーク１０４、ベクトル化部１０８、およびネットワーク検索部１１３だけで構成可能である。この場合も、修理リコメンデーションシステム１００はネットワークで相互に接続された複数のコンピュータで構成してよい。

本実施例中、ソフトウェアで構成した機能と同等の機能は、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）などのハードウェアでも実現できる。そのような態様も本願発明の範囲に含まれる。

＜３．推論モデルと推論ネットワークの生成と実装＞
図３は、推論モデル１０３と推論ネットワーク１０４の、生成と実装までの処理の流れを示す図である。

処理Ｓ３０１で、事例ＤＢ１０５を準備する。事例ＤＢ１０５には、例えば過去の報告書等を内容とする事例が蓄積されている。

図４は、報告書の内容の一例を示している。例えばあるパソコンのディスプレイの修理に対する作業報告書４００は、以下のような構成で記載されている。作業報告書４００には、報告書を特定するＩＤあるいは番号４０１が記載される。

依頼内容４０２はパソコンのユーザ（「一般ユーザ」という）からの依頼内容を示す。依頼内容４０２は一般ユーザが確認した事実である。確認内容４０３は、一般ユーザからの依頼を受けて対応したユーザ（修理担当者）が確認した事実を示す。事実の確認の前提として、修理担当者が依頼内容４０２に基づいて必要な確認作業を判断しているため、依頼内容４０２に基づく第１段階の推論と定義できる。原因４０４は、修理担当者が確認内容４０３に基づいて原因を推定したものであり、第２段階の推論と定義できる。修理内容４０５は、修理担当者が原因４０４に基づいて原因の除去のための作業を判断しているため、第３段階の推論と定義できる。

作業報告書という資料の構成上、各項目が論理的な順序に従った構成になっているため、後に図７Ａで説明するように、各項目でノードを構成し、ノードの間をリンクで接続することにより、推論の因果関係を示すことが可能となる。

図４の作業報告書４００の例は一例であり、報告書の書式は任意である。さらに細分化された項目を持っていてもよいし、簡略化されてもよいが、図４に示すように「依頼内容（事実）」「確認内容（推論１）」「原因（推論２）」「修理内容（推論３）」のように、推論の段階ごとに項目分けされることが一般である。項目分けされていない場合でも、構文解析やキーワードの抽出により自動的に項目分けすることも可能である。あるいはオペレータが項目分けして再入力してもよい。

報告書ではこのように「事実」および「事実に基づく多段階の推論」が記述され、最終的な結論が導かれることが多い。すなわち、報告書のテキストは、前提（事実）、該前提から導かれる第１の推論、および該第１の推論を前提として導かれる第２の推論を含むことが多い。

図５は、図４に示すような作業報告書４００を格納した事例ＤＢ１０５のデータ構成の例を示す表図である。作業報告書４００の一つが１行に相当する。各行には、作業報告書４００を特定するＩＤあるいは番号４０１、依頼内容４０２、確認内容４０３、原因４０４、修理内容４０５が格納される。依頼内容４０２、確認内容４０３、原因４０４、修理内容４０５は、テキストデータとして格納することができる。

事例ＤＢ１０５は、入力部１０１から作業報告書４００のデータを入力して、修理リコメンデーションシステム１００の記憶装置に格納する。あるいは、事例ＤＢ１０５は、修理リコメンデーションシステム１００がアクセス可能な他のデータサーバ等に格納してもよい。

＜３－１．推論モデルの生成と実装＞
図３に戻り、処理Ｓ３０２で、報告書のそれぞれにラベルを付加する。ラベルは後に教師データの回答として用いるものであり、推論モデル１０３の運用時には、ユーザ２００からの問い合わせ（質問）に対して出力される提案（回答）となる。

ラベルは、熟練した修理担当者や他の推定モデルによって付加される。作業時には、例えば出力部１０２が報告書内容を修理担当者に表示し、修理担当者が入力部１０１を用いてラベルを入力する。ラベルの種類や定義は任意であるが、例えば「故障の原因」「故障の部位」「修理方法」「修理用部品」などがある。例えば、図５の報告書「Ｎｏ.０１」の例では、作業報告書４００の修理内容４０５を参照して、「故障の部位」として「ディスプレイ出力先」、「修理方法」として「出力先の変更」をラベルとする。あるいは、作業報告書４００の原因４０４を参照して、「故障の原因」として「ディスプレイ出力の設定」をラベルとする。

処理Ｓ３０３で、推論モデル１０３を学習するための教師ＤＢ１０６を生成する。教師ＤＢ１０６に格納する教師データとしては、回答として前述のラベルを用いる。質問としては、修理リコメンデーションシステムの場合、事実を用いるのがよい。例えば、図４、図５において、ユーザが確認した事実である依頼内容４０２および、修理担当者が確認した事実である確認内容４０３の少なくとも一つを用いる。

図６Ａは、図４に示す作業報告書４００を用いた教師ＤＢ１０６のデータ構成の例を示す表図である。作業報告書４００の一つが１行に相当する。各行には、作業報告書４００を特定するＩＤあるいは番号６０１、質問６０２として作業報告書４００の依頼内容４０２と確認内容４０３のテキスト、ラベル６０３として「故障の部位」と「修理方法」が格納されている。

図６Ｂは、図４に示す作業報告書４００を用いた教師ＤＢ１０６のデータ構成の他の例を示す表図である。質問６０２として依頼内容４０２のテキスト、ラベル６０３として「故障の原因」が格納されている。

図６Ｃは、図４に示す作業報告書４００を用いた教師ＤＢ１０６のデータ構成の他の例を示す表図である。質問６０２として依頼内容４０２のテキスト、ラベル６０３として「故障の部位」と「修理方法」が格納されている。

図３に戻り、処理Ｓ３０４で、ベクトル化部１０８は、教師ＤＢ１０６の質問６０２のテキストデータをベクトル化する。テキストのベクトル化については、公知の手法を用いてよいので詳細説明は割愛する。

処理Ｓ３０５で、モデル学習部１０７は、教師ＤＢ１０６の教師データを用いて推論モデル１０３の教師有り学習を行う。推論モデル１０３としては、ＤＮＮその他のモデルを使用することができ特に制限するものではない。教師有り学習の手法としても種々の手法を使用することができ特に制限するものではない。学習にあたっては、教師ＤＢ１０６の質問６０２を質問としラベル６０３を回答とした教師データセットを通常複数適用して、推論モデル１０３を学習する。

処理Ｓ３０６で、学習が終了した推論モデル１０３を修理リコメンデーションシステム１００に実装する。推論モデル１０３は、ＦＰＧＡのようなハードウェアでもよいし、ソフトウェアでもよい。適切に学習された推論モデル１０３は、保守担当者２００からの問い合わせ（質問）に対して、適切な提案（回答）を行うことができる。

＜３－２．推論モデルの結果に対してユーザが納得感を得るための情報＞
実施例の一つの特徴である推論ネットワーク１０４を説明する前に、推論モデルの推論結果に対して、ユーザが納得感を得るための情報の意義について説明する。

例えば図６Ｃの教師データを用いて学習した推論モデル１０３は、入力として作業報告書４００の依頼内容４０２を用い、出力として修理内容４０５から抽出した「修理の部位」と「修理方法」のラベルを得ることになる。適切に学習された推論モデル１０３は、適切なラベル（回答）を出力することができるはずである。しかし、推論モデルの入出力を考えると、作業報告書４００の項目である依頼内容４０２、確認内容４０３、原因４０４、修理内容４０５のうち、確認内容４０３と原因４０４が欠落していることがわかる。

すなわち、ユーザから見ると、「依頼内容４０２」「確認内容４０３」「原因４０４」「修理内容４０５」で構成されている推論の連鎖のうちの一部が欠落していることになる。発明者らは、推論モデル１０３の入出力から欠落している推論の部分をユーザに提示することにより、推論モデルの推論結果に対して、ユーザが納得感を得ることができるのではないかと考えた。推論ネットワーク１０４は、このための手段を提供する。

＜３－３．推論ネットワークの生成と実装＞
図３に戻り、処理Ｓ３０７で、ベクトル化部１０８は、事例ＤＢ１０５の依頼内容４０２、確認内容４０３、原因４０４、修理内容４０５のテキストデータをベクトル化する。

処理Ｓ３０８で、グループ化部１１０は、依頼内容４０２、確認内容４０３、原因４０４、修理内容４０５の項目ごとに、ベクトル化されたテキストをグルーピングする。グルーピングは公知の手法を採用してよい。一般に、近似するベクトル値を持つテキストをグループ化するクラスタリングの手法が知られている。グループの大きさは任意であるが、細分化すると推論ネットワーク１０４が複雑化して扱いにくくなる一方、グループが大きすぎると後の検索結果にノイズが増えるので、適切な大きさに調整する。

処理Ｓ３０９で、各グループにおいてベクトル値の平均値に最も近いベクトル値を持つテキストを代表テキストとして抽出する。代表テキストでグループを代表させることにより、ユーザが推論ネットワーク１０４の構成を理解しやすくなる。もっとも代表テキストの生成は省略してもよい。代表テキストを省略した場合には、各グループに含まれるテキストを順次参照できるようにすればよい。

処理Ｓ３１０では、各報告書の項目をネットワーク化する。各報告書の項目である依頼内容４０２、確認内容４０３、原因４０４、修理内容４０５をノードとする。

図７Ａに示すように、同じ作業報告書４００の依頼内容４０２、確認内容４０３、原因４０４、修理内容４０５の各項目でノードを構成し、ノードの間をリンク７００で接続する。図７Ａの例では報告書が１～１００までの１００件あり、夫々の報告書がＡ，Ｂ，Ｃ，Ｄの多段的な推論を含んでいる。例えばＡが依頼内容４０２に相当し、Ｂが確認内容４０３に相当し、Ｃが原因４０４に相当し、Ｄが修理内容４０５に相当する。ここでは報告書１の依頼内容を「１Ａ」、報告書３の修理内容を「３Ｄ」のような記号で表している。そして、グループ化部１１０でグループ化した同一グループに属するノードを一つに纏める。

図７Ｂは、図７Ａのノードをグルーピングしてネットワーク化した概念を示す概念図である。報告書３と４の修理内容「３Ｄ」と「４Ｄ」がひとつのグループ７０１でグルーピングされている。報告書１と２と３の原因「１Ｃ」「２Ｃ」「３Ｃ」がひとつのグループ７０２でグルーピングされている。報告書４の原因「４Ｃ」が単独でグループ７０３を構成している。

このとき、グループ７０１と７０３には同じ報告書４の項目が含まれるので、グループ間リンク７０４が形成される。また、グループ７０１と７０２にも同じ報告書３の項目が含まれるので、グループ間リンク７０５が形成される。このようにして推論ネットワーク１０４を生成する。

なお、推論ネットワーク１０４が複雑になることを避けるため、所定以下の大きさのグループとそれにつながるグループ間リンクを削除してもよい。例えば、２以下のノードしか含まないグループを削除することにし、「４Ｃ」のみを含むグループ７０３とグループ間リンク７０４を削除する。

あるいは、所定以下の数のリンクで接続されているグループ間ではグループ間リンクを削除してもよい。例えば、リンク７０７でしか繋がっていないグループ７０１とグループ７０２の間のグループ間リンク７０５は削除する。

以上のようにして適当な閾値を設けて推論ネットワーク１０４の一部を簡略化することで、ユーザが推論ネットワーク１０４を理解しやすくなる。

図８は、グループ化によってネットワーク化された推論ネットワーク１０４の概念を示す図である。Ａの階層が依頼内容４０２に相当し、Ｂの階層が確認内容４０３に相当し、Ｃの階層が原因４０４に相当し、Ｄの階層が修理内容４０５に相当し、４階層で構成される。階層は２以上であれば、基になる作業報告書４００の分野や項目に応じて変えてもよい。

推論ネットワーク１０４において、図中の円で示すノードは図７Ｂで示したグループ化されたノードであることに留意されたい。すなわち、推論ネットワーク１０４の１つのノードには、１または複数の作業報告書４００の項目が纏められている。最上位（ここではＡ）の階層のノードは入力ノードであり、最下位（ここではＤ）の階層のノードは出力ノードである。

１つのノードには、１または複数の報告書の類似する項目が纏められている。各ノードからは、ノードに属する項目と同じ報告書の項目が属するノードに対してリンクが形成される。

図９は、推論ネットワーク１０４の構成を規定するネットワークデータ９００の一例である。グループを一意に特定するグループＩＤ９０１に対し、当該グループに属するノードの報告書番号９０２と、当該グループとグループ間リンクで接続されるグループのリンク先グループＩＤ９０３を格納する。また、グループを代表する代表テキスト９０４を格納してもよい。

＜４．修理リコメンデーションシステムによるリコメンデーション＞
図１０は、修理リコメンデーションシステム１００による、修理リコメンデーション処理の流れを示す図である。

処理Ｓ１００１で、入力部１０１は推論モデル１０３への入力となる質問を取得する。質問は、例えばユーザ２００が端末装置３００を経由して送信してくる質問文のテキストデータである。音声入力を音声認識してテキスト化するなどの他の方法でもよい。

処理Ｓ１００２で、質問文のテキストをベクトル化部１０８でベクトル化する。
処理Ｓ１００３で、ベクトル化した質問を、推論モデル１０３に入力して推論を行う。推論モデル１０３の回答は、ラベル６０３の形で得られる。

処理Ｓ１００４で、ネットワーク検索部１１３は、得られたラベル６０３により、推論ネットワーク１０４の出力ノードを検索する。図３に示したように、ラベルを付加した事例データで推論ネットワークを生成している場合には、推論ネットワーク１０４の出力ノードにはラベルが対応しているので、回答のラベルで出力ノードのラベルを検索すればよい。あるいは、ラベルの元になっている報告書の項目のテキストを、ラベルをキーワードとして検索してもよい。

出力ノードを構成する報告書のグループが複数の報告書の内容を含んでいる場合には、そのうちの一つの報告書のラベルがヒットしたとき、当該グループを抽出する。あるいは、所定割合以上の報告書のラベルがヒットした場合、当該グループを抽出してもよい。あるいは、代表テキストとした報告書のラベルがヒットした場合、当該グループを抽出してもよい。

処理Ｓ１００５で、ネットワーク検索部１１３は、抽出された出力ノードに直接あるいは間接的に接続されるノードを抽出する。

処理Ｓ１００６で、出力部１０２は、推論モデル１０３の回答および抽出されたノードを出力する。出力部１０２は、推論モデル１０３の回答および抽出されたノードの情報を、例えば端末装置３００に送信してそのディスプレイに表示する。

図１１Ａは、端末装置３００のディスプレイに表示される、推論モデル１０３の回答および抽出されたノードの例である。データ構成は、図４、図５、図８、図９に示したものを例とし、推論モデル１０３の入出力は、図６Ｃに示すものとした。すなわち、推論モデル１０３への質問は図４、図５の依頼内容４０２であり、回答は修理内容４０５に対応するラベル６０３である。

表示されたネットワーク１１００において、入力ノード１１０１は、図６Ｃに示す質問６０２（図４、図５の依頼内容４０２）に相当する。出力ノード１１０２は、図６Ｃに示すラベル６０３（およびラベルに対応する図４、図５の修理内容４０５）に相当する。ラベルは修理内容４０５に対応しているので、「修理の部位」として「ディスプレイ出力先」が、「修理方法」として「出力先の変更」が回答１１０３として表示されている。ネットワーク１１００では、出力ノード１１０２に直接あるいは間接的に接続されるノード（図中円で示す）が示される。

一般に、推論モデル１０３によるリコメンデーションでは、回答１１０３が示される。また、ユーザ２００は推論モデル１０３への入力は知ることができるので、入力ノードのいずれかが依頼内容４０２に相当する蓋然性が高いことを認識することができる。

しかし、ユーザ２００は、示された回答１１０３だけではリコメンデーションに納得しない場合があり、そのため意思決定に躊躇する場合がある。そこで、本実施例では推論ネットワーク１０４を用いて、回答１１０３に至る推論の経緯（図１１Ａ中斜線で示すノード）を可視化することで、ユーザ２００がリコメンデーションに納得できる情報を提供する。

具体的には、例えば端末装置３００のディスプレイに、図１１Ａに示すようなネットワーク１１００を表示する。出力ノード１１０２が、推論モデル１０３の回答１１０３に対応し、これに接続されているノードが推論ネットワーク１０４から抽出して示されている。

図１１Ｂに示すように、回答１１０３を見たユーザ２００は、回答の根拠を知りたいと思ったとき、例えば出力ノード１１０２に接続されている中間ノード１１０４を指定する。指定された中間ノード１１０４は、事例ＤＢ１０５のデータ構成（図５）の、原因４０４の項目に対応する。ネットワーク検索部１１３は、ネットワークデータ９００で、指定された中間ノードのグループＩＤ９０１に対応する代表テキスト９０４を抽出する。代表テキスト９０４は、出力部１０２により原因コメント１１０５として表示される。

ユーザ２００が、提示された原因コメント１１０５に納得した場合には、回答１１０３に従って作業を開始できる。あるいは、ユーザ２００が、提示された原因に納得できない場合には、ユーザはさらにリンクを辿ることで、ネットワーク１１００から原因コメント１１０５の根拠を知ることができる。

図１１Ｃに示すように、中間ノード１１０４の原因コメント１１０５を見たユーザ２００は、さらにその根拠を知りたいと思ったとき、中間ノード１１０４に接続されている中間ノード１１０６を指定する。指定された中間ノード１１０６は、事例ＤＢ１０５のデータ構成（図５）の、確認内容４０３の項目に対応する。ネットワーク検索部１１３は、ネットワークデータ９００で、指定された中間ノードのグループＩＤ９０１に対応する代表テキスト９０４を抽出する。代表テキスト９０４は、出力部１０２により確認内容コメント１１０７として表示される。

この例では確認内容４０３は、一般ユーザからの依頼を受けて対応した修理担当者が確認した事実を示す。よって、ユーザ（修理担当者）２００が自分で行った確認内容と整合する内容を確認内容コメント１１０７に見出した場合、中間ノード１１０４の原因コメント１１０５に納得しやすいと思われる。

例えば図１１Ｃの例では、「ディスプレイ出力の設定」という原因について、関連する「ログイン後、しばらくするとディスプレイが真っ暗になり、何も表示されなくなった。」という現象をユーザ（修理担当者）２００が確認済みの場合、ユーザは原因コメント１１０５に納得しやすいと思われる。ユーザ２００が、提示された内容に納得した場合には、回答１１０３に従って作業を開始できる。あるいは、ユーザ２００が、提示された内容でも納得できない場合には、ユーザはさらに他のリンクを辿ることで、事例データから原因コメント１１０５の根拠を知ることができる。

図１１Ｄに示すように、中間ノード１１０４の確認内容コメント１１０７を見たユーザ２００は、さらに他の根拠を探そうとする場合、中間ノード１１０４に接続されている他の中間ノード１１０８を指定する。指定された中間ノード１１０６は、事例ＤＢ１０５のデータ構成（図５）の、他の報告書の確認内容４０３に対応する。ネットワーク検索部１１３は、ネットワークデータ９００で、指定された中間ノードのグループＩＤ９０１に対応する代表テキスト９０４を抽出する。代表テキスト９０４は、出力部１０２により確認内容コメント１１０９として表示される。

ユーザ２００は、確認内容コメント１１０９を見て、その内容を確認していない場合は確認作業を行う。確認作業の結果が、確認内容コメント１１０９と整合している場合は、別の観点で原因コメント１０５の根拠が得られたことになり、納得感を補強することができる。

例えば図１１Ｄの例では、「ディスプレイ出力の設定」という原因について、関連する「新品のディスプレイに繋ぎ変えても、何も表示されない。」という現象をユーザ（修理担当者）２００が確認すれば、ユーザはさらに原因コメント１１０５に納得しやすいと思われる。

図１１Ａ～図１１Ｄでは、リンクを確認内容の階層の中間ノード１１０６，１１０８まで遡っているが、入力ノード１１０１まで遡って依頼内容を確認することも有効である。また、推論ネットワーク１０４のリンクを遡る使用例を示しているが、例えば、リンクを入力ノード１１０１や確認内容の階層の中間ノード１１０６，１１０８まで遡った後、再びリンクを原因の階層の方向に下がることもできる。リンクで接続されたノードの内容を確認することで、意思決定に有益な情報を得ることができる。

なお、図１１Ａ～図１１Ｄでは、ラベルあるいは各ノードに属する報告書のテキストのうち代表テキストを表示している。さらに当該ノードの詳細な情報を知るために、ラベルや代表テキストのみではなく、図５に示すような報告書内容を示すこともユーザ２００の意思決定上有益である。そのためには、図９のネットワークデータ９００の報告書番号９０２を用いて、図５の事例ＤＢ１０５の報告書番号４０１を参照して、該当する報告書のテキストデータを抽出すればよい。

以上の実施例では、修理リコメンデーションを例としているが、ソフトウェアのデバッグ等他の分野に適用することも可能である。以上の実施例では、推論ネットワーク１０４は４階層で、それぞれの階層は作業報告書４００の項目に対応して、依頼内容４０２、確認内容４０３、原因４０４、修理内容４０５としているが、階層の数や内容は適用分野に応じて変更することも可能である。

本実施例によれば、推論モデル１０３の推論結果だけではなく、推論結果に至る段階的な推論の経緯をユーザに提示できるので、ユーザが納得感を得るための情報を、迅速に抽出することができる。推論ネットワーク１０４を用いることにより、事例ＤＢ１０５を直接回答のラベル等で検索するよりも、ノイズの少ない有益な情報を得ることができる。例えば、上記図１１Ａ～図１１Ｄの例で単純に「ディスプレイ出力先」「出力先の変更」のキーワードで事例ＤＢ１０５全体を検索した場合、図５の「ディスプレイ出力先を変更する設定を行ったら、表示される画面の大きさが変わってしまってもとに戻せない。」のような、関係のない依頼内容を抽出してしまう。

このように本実施例では、例えば「原因」に出てくる語と同じ語が「依頼内容」に出てくるというのみでは、その「依頼内容」を抽出しないように構成することが可能である。その結果、推論の因果関係で連結された、ユーザが真に所望する情報が掲載された項目や報告書を迅速に入手できるという効果がある。以上のように本実施例では、検索のノイズを減らすことが可能である。

実施例１では同じ事例データで推論モデル１０３の教師データ生成と、推論ネットワーク１０４の生成を行っている。しかし、全く同じデータを用いる必要はなく、一部のみが同じデータでもよい。また、教師データと同一の事例データでなくても、同一または類似の分野の事例データであれば、推論ネットワーク１０４の生成に用いることができる。

図１２は、教師データ生成のために用いた事例データとは異なる事例データで、ネットワーク用事例ＤＢ１２１１を準備して、推論ネットワーク１０４を生成した例である。

修理リコメンデーション処理の流れは図１０に示すものと同様でよい。ただし、ネットワーク用事例ＤＢ１２１１を用いた場合には、推論ネットワーク１０４には教師データのためのラベルが付されていない。そこで、推論ネットワークから出力ノードを抽出する処理Ｓ１００４において、推論モデル１０３の回答のラベルで、推論ネットワーク１０４の出力ノードの項目のテキストを直接検索する。あるいは、推論モデル１０３の回答のラベルの元になっているテキストと推論ネットワーク１０４の出力ノードのテキストを、共にベクトル化して比較することにより検索する。

実施例１では推論モデル１０３の回答のラベルで、推論ネットワーク１０４の出力ノードを抽出し、出力ノードに接続されるノードを抽出している。しかし、ユーザ２００は推論モデル１０３の質問も知ることができるので、さらに推論モデル１０３の質問で、推論ネットワーク１０４の入力ノードを抽出してもよい。

図１３に実施例３の修理リコメンデーション処理の流れを示す。図１０のフローに比べ、モデルの入力により推論ネットワーク１０４の入力ノードを抽出する処理Ｓ１３０１が追加される。処理Ｓ１３０１では、推論モデル１０３の質問のテキストをベクトル化し、推論ネットワーク１０４の入力ノードの代表テキストをベクトル化し、両者を比較して類似するものを抽出すればよい。

この場合の表示は、例えば図１１Ａに示したように、該当する入力ノード１１０１と出力ノード１１０２を明示することで可能である。あるいは、該当する入力ノードと出力ノードの間のノードのみ表示してもよい。実施例１に比べて、関連するノードを絞り込み安くなるという効果がある。

修理リコメンデーションシステム１００、ユーザ（修理担当者）２００、端末装置３００、入力部１０１、出力部１０２、推論モデル１０３、推論ネットワーク１０４、事例ＤＢ１０５、教師ＤＢ１０６、モデル学習部１０７、ベクトル化部１０８、教師データ生成部１０９、グループ化部１１０、代表テキスト生成部１１１、ネットワーク生成部１１２、ネットワーク検索部１１３

Claims (10)

1. 項目分けされたテキストからなる事例データベースのデータを利用して機械学習したニューラルネットワークで構成される推論モデルと、
   前記推論モデルの質問を入力する入力部と、
   前記推論モデルの回答を出力する出力部と、
   入力ノードと出力ノードを有し、推論の段階をリンクで表現するネットワークであって、前記ネットワークの各階層は、前記項目分けされたテキストの各項目に対応し、前記ネットワークのノードが、前記各項目内で内容が類似するテキストをグルーピングして生成されている推論ネットワークと、
   前記推論モデルの回答に基づいて、前記推論ネットワークの出力ノードを検索するネットワーク検索部と、
   を備え、
   前記ネットワーク検索部は、
   前記推論モデルの回答に基づいて、前記推論ネットワークのノードのテキストを参照して検索するとともに、検索したノードと直接または間接的に接続されるノードを抽出するリコメンデーションシステム。
2. 前記推論ネットワークは、
   少なくとも３階層のネットワークであり、前記入力ノードと前記出力ノードの間に、中間ノードの層を備える、
   請求項１記載のリコメンデーションシステム。
3. 前記テキストは、前記推論モデルの学習に用いた教師データを生成するために用いたテキストの一部を含むものである、
   請求項１記載のリコメンデーションシステム。
4. 前記項目分けされたテキストの項目は、
   前提、該前提から導かれる第１の推論、および該第１の推論を前提として導かれる第２の推論を少なくとも含む、
   請求項１記載のリコメンデーションシステム。
5. 前記項目分けされたテキストは作業報告書であり、
   前記前提は製品の利用者による前記製品の状態に関するコメントであり、前記第１の推論は製品の保守作業員による前記製品の状態に関するコメントであり、前記第２の推論は前記製品の故障の原因あるいは故障の修理に関するコメントである、
   請求項４記載のリコメンデーションシステム。
6. 前記出力部は、
   前記推論モデルの回答、前記検索した出力ノード、および該出力ノードと直接または間接的に接続されるノードを表示するための情報を出力する、
   請求項１記載のリコメンデーションシステム。
7. 前記出力部は、
   前記テキストの項目の内容を表示するための情報を出力する、
   請求項１記載のリコメンデーションシステム。
8. 前記ネットワーク検索部は、
   前記推論モデルへの入力に基づいて、前記推論ネットワークの入力ノードを検索する、
   請求項１記載のリコメンデーションシステム。
9. 入力装置、出力装置、処理装置、および記憶装置を備えるシステムを用い、前記記憶装置に格納されたプログラムが前記処理装置によって実行されることで以下の各工程を実行する方法であって、
   項目分けされたテキストからなる報告書を複数含む事例データベースを準備する、事例
   データベース生成工程、
   前記報告書の各々に対応してラベルを付加する、ラベル付加工程、
   前記項目分けされたテキストの少なくとも一部を質問とし前記ラベルを回答として教師データセットを生成し、教師データベースを生成する、教師データベース生成工程、
   前記教師データセットを用いて推論モデルを学習する、モデル学習工程、
   前記報告書の項目毎に、複数の報告書のテキストを類似度に基づいてグルーピングしてグループを生成する、グループ化工程、
   前記グループの間にリンクを形成して推論ネットワークを生成する、ネットワーク化工程、
   前記推論モデルと推論ネットワークを実装する、実装工程、
   を実行し、
   前記項目分けされたテキストの項目は、前提、該前提から導かれる第１の推論、および該第１の推論を前提として導かれる第２の推論を少なくとも含み、
   前記ラベルは、前記第１の推論および前記第２の推論の少なくとも一つに基づいて付加され、
   前記質問は、前記前提および前記第１の推論の少なくとも一つのテキストに基づいて生成され、
   前記推論ネットワークは、前記ラベルを付加する基となった前記第１の推論および前記第２の推論の項目の少なくとも一つに対応する出力ノードを持ち、
   前記推論ネットワークは、前記質問を生成する基となった前記前提および前記第１の推論の項目の少なくとも一つに対応する入力ノードを持ち、
   前記推論モデルと前記推論ネットワークを用い、
   前記推論モデルで推論を行って回答を得る、推論工程、
   前記回答に基づいて、前記推論ネットワークの出力ノードを抽出する、出力ノード抽出工程、
   を実行し、
   抽出した前記推論ネットワークの出力ノードに直接または間接的に接続されているノードを抽出する、接続ノード抽出工程、
   を実行する、
   リコメンデーション方法。
10. 抽出した前記出力ノードおよび前記ノードの少なくとも一つに関係するテキストを出力する、
    請求項９記載のリコメンデーション方法。

Images