JP7565742B2

JP7565742B2 - 意図推定装置

Info

Publication number: JP7565742B2
Application number: JP2020170610A
Authority: JP
Inventors: 昌史高橋; 正明山本
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2020-10-08
Filing date: 2020-10-08
Publication date: 2024-10-11
Anticipated expiration: 2040-10-08
Also published as: JP2022062532A

Description

本発明は、意図推定装置およびその方法に係り、特に、機械学習を用いて発話系列を基に発話者の意図を推定する意図推定技術に関する。

多層構造を有するニューラルネットワークを用いて学習を行う深層学習の登場により、人工知能の進化は急速に加速し、いまや画像、音声、テキストなど多様なメディアに応用され、様々な分野で顕著な効果をあげている。例えば、従来、メディア認識技術を活用できていなかった機械の保守点検現場でも、点検記録をメディア認識技術で行う機運が高まってきている。保守点検現場において、マイクを装着した作業員の発話を音声認識し、認識結果に対してテキスト処理を行うことで、点検結果を推定して記録すると作業効率を大きく向上させることが期待できる。この場合、点検順序や発話の規則などが一律ではない発話系列に対してロバストに点検結果を推定するためには、発話の時系列的な文脈を考慮して意味内容を推定することができるテキスト処理技術が求められる。

発話の意味内容をロバストに推定するためのテキスト処理技術として、発話の時系列特徴を学習するなどの意図推定技術が知られている（非特許文献１）。しかし、非特許文献１の技術では、深層学習により話題の遷移を識別するため、話題（例えば点検項目）の種類が増えると遷移パターンの数が爆発的に増加し、その結果膨大な数の学習データが必要になるなどの問題がある。

また、テキスト処理技術として、テキスト分割技術を利用することが知られている（非特許文献２）。非特許文献２の技術は、テキスト文書を話題ごとに区間分割を行う際、隣接する文章間の類似度に基づいて境界が決定される。しかし、この場合、分割された区間がどういった意味を持つのかを知ることができず、点検結果を推定することはできない。

これに対して、特許文献１には、隣接する２つの話題ブロックの組ごとに線形変換係数ベクトルと重心点を学習しておき、分割する際には隣接する２つの話題ブロックの組ごとに当該話題ブロックの組用の線形変換係数ベクトルと重心点とを用いてテキストを分割するテキスト分割装置が開示されている。

特開2012－93943公報

吉野幸一郎, "音声発話系列からのユーザの意図の理解",電子情報通信学会誌 Vol. 101, No. 9, 2018. Athanasios Kehagias, Pavlina Fragkou, and Vassilios Petridis,"Linear Text Segmentation using a Dynamic Programming Algorithm", In Proceedings of 10th Conference of the European Chapter of the Association for Computational Linguistics, 2003. Sepp Hochreiter and Jurgen Schmidhuber, "Long Short-Term Memory", Neural Computation, 9(8):1735-1780, 1997. Kyunghyun Cho, Bart van Merrienboer, Caglar Gulcehre, Dzmitry Bahdanau, Fethi Bougares, Holger Schwenk, and Yoshua Bengio, "Learning phrase representations using RNN encoder-decoder for statistical machine translation. In Proceedings of the 2014 Conference on Empirical Methods in Natural Language Processing", 2014. Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova, "BERT: Pre-training of deep bidirectional transformers for language understanding", Proc. NAACL-HLT, pp. 4171- 4186, 2019.

特許文献１に開示された、テキスト分割技術によれば、コールセンターにおける通話のような、話題の流れが厳密に決まっている場合(例えば、挨拶⇒要件確認⇒本人確認⇒…のような場合)、テキスト分割して、分割された区間の意味内容を知ることができる。

しかし、この場合、点検の順序を厳密に決めておくなどの制限を設けておかないと、学習時に話題の遷移パターンに組み合わせ爆発が発生することになり、計算量などの問題が発生する。特許文献１の技術ではさらに識別時にも同様の問題が生じる。

また、例えば点検作業において点検結果を推定する際、推定結果に誤りがないかを作業員がリアルタイムで確認し、誤りがあれば手軽に修正することができるインタフェースを実現することが望ましい。推定結果が得られるまでに時間を要する場合、作業員は結果が表示されるまで待たされることになり、心的ストレスを受けることになる。さらに、保守現場では作業員は両手がふさがっている場合が多く、修正作業に行うことができる操作は限定される。

本発明の目的は、より少ない計算量または学習データ量で、発話の順序や規則にロバストな発話を推定する技術を実現することにある。
本発明はまた、発話の推定結果をリアルタイムで算出して提示することにある。

本発明に係る意図推定装置の好ましい例は、入力された発話系列に対し、隣接する発話文をつなげて連結文を生成する発話文合成部と、
前記発話文合成部により生成された前記連結文に対して意図推定を行い、意図推定結果とその尤度を出力する意図推定部と、
前記尤度に基づいて発話系列を意味単位で区間分割する意図区間推定部と、
分割された区間ごとに前記意図推定結果を出力する結果抽出部と、を有する意図推定装置である。
本発明はまた、上記意図推定装置において動作する意図推定方法として把握できる。
さらに、本発明は、上記意図推定装置における機能または上記方法における処理ステップを、コンピュータで実行して実現するプログラムとしても把握できる。

本発明によれば、より少ない計算量または学習データ量で、発話の順序や規則にロバストな推定技術を提供することができる。また、発話の推定結果をリアルタイムで算出して提示することができる。

プリンタの保守点検現場における発話系列と推定結果の例を示す図である。従来技術による発話の時系列特徴に基づく意図推定の概念を示す図である。学習用発話系列データの例を示す図である。識別対象の発話系列の例を示す図である。本実施例に係る学習用発話系列データの推定を概念的に示す図である。識別対象の発話系列の例を示す図である。実施例１に係る意図推定装置の例を示す図である。発話文合成部701による連結文の生成の例を示す図である。意図推定部702による処理の例を示す図である。連結文と尤度を有向グラフとして示す図である。動的計画法を用いて意図区間を推定する手順の一例を示す図である。バッチ処理による意図推定処理のフローを示す図である。リアルタイム処理による意図推定装置の例を示す図である。区間推定情報ＤＢ1312の例を示す図である。リアルタイム処理による意図推定処理のフローを示す図である。実施例２に係る意図推定装置の例を示す図である。点検履歴ＤＢ1603の例を示す図である。 Windowサイズ調整の処理フローを示す図である。 Windowサイズ調整の処理フローを示す図である。 Windowサイズ調整の処理フローを示す図である。実施例２に係るリアルタイム処理による意図推定装置の例を示す図である。実施例３に係る意図推定装置の例を示す図である。点検項目に関する用語辞書の例を示す図である。点検結果に関する用語辞書の例を示す図である。点検結果に関する用語辞書の例を示す図である。実施例３に係るリアルタイム処理による意図推定装置の例を示す図である。実施例４に係る意図推定装置の例を示す図である。モデル化するための行動パターンの一例を示す図である。作業員の点検順序を精緻にモデル化する行動パターンの一例を示す図である。作業員の点検時間をモデル化する場合の行動パターンの一例を示す図である。作業員の点検時間を精緻にモデル化する行動パターンの一例を示す図である。作業員の点検順序と点検時間の関係をモデル化する場合の行動パターンの一例を示す図である。実施例４に係るリアルタイム処理による意図推定装置の例を示す図である。実施例５に係る意図推定装置の例を示す図である。作業支援ユーザインタフェースによる画面の表示例を示す図である。

以下、図面を参照して、好ましい幾つかの実施例について説明する。
図１は、プリンタの保守点検現場における作業員の発話系列例101と、その時に実現したい保守点検結果の推定例102を時系列に示している。ここで、作業者の各発話104に対して、時系列に発話番号(No)103が付けられて、推定が行われるべきタイミングで点検項目105と点検結果106の推定結果が記されている。なお、テキストとして示されている作業員の発話情報101は、例えばマイクを装着した作業員の発話を音声認識することにより取得することができる。

プリンタの保守点検工程について詳しく見る。まず、発話No.0「プリンタの保守をします。」では、点検結果に関する内容が発せられていないため、推定すべき結果はない。次に、発話No.1「コンセントよし。」では、１つの発話により点検項目（コンセント）と点検結果（OK）が示されており、比較的容易に推定を行うことができる。しかし、点検項目と点検結果を別々に発話される場合は問題が複雑化する。例えば、発話No.2における「問題なし」の対象が、続く発話No.3の「紙詰まり」であることは自明ではない。同様に、発話No.5における「異常」の対象が、その一つ前の発話No.4における「フィルム」であることを推定するのは容易ではない。さらに推定が難しいのは、発話No.6～No.8のように、点検項目と点検結果が発話される間に、独り言のように意味のない発話が行われる場合である。この場合、発話No.8における「よし」の対象は、２つ前の発話No.6における「用紙残量」となる。このように、発話の規則が一律ではない発話系列に対してロバストに点検結果を推定するためには、発話の時系列的な文脈を考慮して意味内容を推定することが必要となる。

例えば、非特許文献１に記載の従来技術は、発話の時系列特徴に基づいて意図推定を行う。図２は、従来技術による推定処理について概念的に示す。ここでは、意図推定の対象となる発話系列201を入力し、単語単位で特有なベクトルを付与する(202)。そして、これら単語ベクトル系列を、RNN（Recurrent Neural Network）やLSTM（Long Short-Term Memory）（非特許文献３参照）といった、発話系列パターンを学習することができるニューラルネットワークのモデルを用いて識別を行い、結果として、意図ベクトル204とその尤度205を取得する。意図ベクトル204は、例えば意図推定結果の次元のみ値が1となり、その他は0であるようなベクトルのことを表す。尤度205は、[0,1]の区間で定義される値で、その値が大きいほど意図推定結果が確からしいものとする。これらの結果は、各発話文の文末記号（EOS）が入力される度に取得される。図２の例では、発話文「プリンタの保守をします。」に対する意図推定結果は「点検以外の発話」でその尤度は0.75、発話文「コンセントよし。」に対する意図推定結果は「コンセントOK」でその尤度は0.93である（上記の尤度は例示である。）。

ここで、上記従来技術の主な課題を２つあげることができる。第１の課題は、発話の順番を考慮して学習を行う必要があるため、学習に必要な発話系列のパターン数が爆発的に増加することである。例えば、図３に示すように、点検項目１、点検項目２、点検項目３、点検項目４、といった順番で点検を行う場合（301）や、点検項目１に関する発話が終わった後に点検以外の発話が続き、その後で点検項目２、点検項目３といった順番で点検を行う場合（302）、さらには、点検項目１、点検項目３、点検項目２、点検項目４、といった順番で点検を行う場合(303)のように、様々な点検項目の遷移パターンに対して発話系列データを用意する必要がある。このため、点検項目数が多くなるとそのパターン数は組み合わせ爆発を起こす可能性がある。

第２の課題は、入力された発話系列に対して一括で意図推定を行うため、対象とする点検の結果が別の点検項目の影響を受けることになり、識別問題が難化し、その結果識別性能の向上を阻害することである。例えば、図４の例では、フィルムを点検している際に発した「異常」という発話401が、用紙残量の点検時に発した「用紙の残量」「よし」という発話402、403に影響を与え、用紙残量の点検結果がOK（適正）なのかNG（不適）なのかの識別を難化させている。

本実施例では、図５に学習用発話系列データの例を示すように、各点検項目の短い発話系列単位で学習を行い、その識別器（意図推定器）を用いて発話系列を意味単位（本実施例では点検項目単位）で分解し（分解された区間を以後「意図区間」という）、それら意図区間（本実施例では各点検項目における発話系列）単位で意図推定を行うことにより、推定精度を向上させる。なお、換言すれば、意図区間は、推定したい意図の区間、或いは推定した正解ラベルが付与される単位ということができる。

図６に示す例のように、フィルム点検時（点検項目：フィルム）の発話と用紙残量点検時（点検項目：用紙残量）の発話が分割されて意図推定が行われるため、フィルムを点検している際に発した「異常」という発話601が、用紙残量の点検時に発した「用紙の残量」「よし」という発話602、603に影響を与えることはなくなり、より精度の高い意図推定が可能になる。

図７は、実施例１による意図推定装置の構成例を示す。意図推定装置は、入力部700と、発話文合成部701と、意図推定部702と、意図区間推定部703と、点検結果抽出部704と、出力部705を有して構成される。なお、ハードウェア資源については図示していないが、本実施例では（実施例２以降も同様）、プログラムを記憶するメモリまたは記憶装置（以下、総じて記憶部ということがある）と、プログラムを実行するプロセッサを有するコンピュータが用いられる。上記の各機能部は、予めメモリ等に用意されたプログラムがプロセッサで実行されることで、それらの機能が実現される。この場合、プログラムは、１または複数の機能部を個別に実現するもの、或いは全ての機能部を一括して実現するものであってよい。

入力部701は、作業員が発声した、音声認識された発話データを発話系列として入力する。
発話文合成部701は、入力された発話系列に対して、移動窓（Moving Window）を用いて連続する発話文をつなげて意図推定部702への入力となる連結文（入力文という）を生成する。Moving Windowの窓サイズ(Windowサイズ)は窓サイズＤＢ（データベース）711に記憶されている。Windowサイズは、発話文合成部701が前後いくつの文まで結合するかを規定する。

意図推定部702は、図５に示すように、予め点検項目ごとに発話系列データを用意して学習させておいた識別器（意図推定器）を用いて連結文の意図推定を行い、各入力に対する意図推定結果と尤度を取得する。
意図区間推定部703は、意図推定部702で取得した尤度を基に発話の意図区間を推定する、すなわち発話系列を意図区間に分割する。点検結果抽出部704は、推定された意図区間に対応する意図推定結果を意図推定部702の出力結果から参照して推定結果を出力する。出力部705は、その推定結果を点検結果として出力する。出力された点検結果は、例えば作業員が所持する端末に表示または音声出力され、また記憶部（不図示）に格納される。なお、この端末は例えば、携帯端末或いは作業員が装着するウェアラブル端末などであり、音声又はタッチキー等による入力部、音声出力部、表示部、メモリ等の記憶部、プログラムを実行して所定の機能を実現するプロセッサ等を有する。

次に、図８乃至図１１を参照して、各部位の機能ないし処理動作を具体的に説明する。
図８は、発話文合成部701によるMoving Windowを用いて連結文を生成する例を示す。ここでは、簡単のため、Windowサイズ（以降、W_Sizeと表示する）を「３」に設定した場合について説明する。

まず、入力された発話系列801に対し、最初の文802に対しては、最初の文そのものを連結文として生成する。続いて、２番目の文803に対しては、２番目の文そのものと、最初の文と２番目の文をつなげた文の２種類を連結文として生成する。この処理を、W_Size番目（すなわち３番目）の文804に達するまで続ける。そして、W_Size番目以降（N番目）の文に対しては（(805)～(806)）、N番目の文そのもの、（N－１）番目の文とN番目の文をつなげた文、…、｛N－（W_Size－１）｝番目からN番目の文をつなげた文、のW_Size種類を連結文として生成する。

このように、Moving Windowを利用する理由は、リアルタイムによる発話文の処理を考慮して、計算量を抑えるため、および推定結果を有限時間内に確定させるためである。一方、バッチ処理により発話文を処理する場合には（図１２のフロー例）、特にMoving Windowを利用する必要はなく（すなわち窓サイズＤＢ711は不要）、隣接する文に対してあらゆるパターンで文を連結すればよい。この場合、Moving Windowの適用については、W_Size＝∞に設定することに相当する。

なお、図７に、窓サイズＤＢ711を図示しているのは、本実施例による意図推定装置を、バッチ処理かまたはリアルタイム処理に切り替えて使用する例が想定され、その場合、Windowサイズを具体的な数値に設定したモード（リアルタイム処理）と、無限大に設定したモード（バッチ処理）に対して予め用意しておくためである。Windowサイズの設定は、意図推定装置が有する入出力操作部（不図示）を用いて、管理者により行うことできる。

図９は、意図推定部702の処理の例を示す。
ここでは、従来方式（図２）と同様の前提、すなわち、単語ベクトル系列902を、ニューラルネットワーク903を用いて識別を行い、意図ベクトル904とその尤度905を出力する。ただし、たとえ入力が複数の文で構成されていたとしても、１度の入力に対して出力が行われるのは、入力文の最後の1度である。この例では、「プリンタの保守をします。コンセントよし。」という連結文901に対する意図推定結果が「コンセントOK」、その尤度が0.85であることを表している。このように、１入力１出力方式の識別器を利用する理由は、入力された連結区間全体が意図区間として適切かどうかを判定するためである。また、従来方式（図２）の１入力多出力方式に対して、本実施例では１入力１出力方式を用いることにより、図３のように様々な遷移パターンで学習を行う必要がなくなり、図５に示すように、点検項目ごとの学習で済むようになる。なお、識別に用いるニューラルネットワークモデルとしては、RNNやLSTMだけでなく、CNN（Convolutional Neural Network）やGRU（Gated Recurrent Unit）（非特許文献４）、BERT（Bidirectional Encoder Representations from Transformers）（非特許文献５）、Bi-directional RNN、Bi-directional LSTM、Bi-directional GRUや、これらの改良系などでも構わない。また、複数のモデルを組み合わせても良い。例えば、RNNによる識別器とLSTMによる識別器の２種類を用意し、各識別器で算出した尤度の平均値などを最終結果とすると効果的である。また、ニューラルネットワーク以外にも、SVM（Support Vector Machine）やRF（Random Forest）、DT（Decision Tree）、k-近傍法など、多クラス分類が可能な機械学習方法を利用しても良い。

意図区間推定部703は、意図推定部702で算出された尤度を基に、発話系列を意図区間に分割する。図１０は、連結文とその尤度を有向グラフとして示している。本実施例では、意図区間推定を最適経路探索問題として捉え、文頭から文末までの尤度の重み付き和が最大となるような区画の組合せを探索する。すなわち、図１０において、分割文枠の下に記載されている数字が尤度を表しているとすると、これに重みを掛けた数字の累積和が最大となる経路を探索する。文Mから文Nまでつなげた連結文に対する重みW(M,N)は、例えば、数１のように定義するとよい。

ここで、Bias1は連結文中に含まれる文の数に応じて重みの値を制御する実数値であり、Bias1>0の値に設定することが望ましい。また、Bias2は対象とする連結文に対する意図推定結果が「点検以外の発話」であった場合に課せられる重みであり、0<Bias2<1の値に設定することが望ましい。本実施例では、リアルタイムでの処理を考慮し、現実的な計算量で暫定結果の算出が可能な動的計画法を用いて最適経路探索問題を解く。動的計画法は部分構造最適性を利用した最適化手法の一つであり、この場合、文頭から開始して対象文に至るまでの最適解を順に計算することによって、発話系列全体の最適化を行うものである。

図１１は、動的計画法を用いて意図区間を推定する手順の一例を示す。図示の例では、窓サイズW_Size=3に設定した場合で、５つの文（文0～文4）から構成される発話系列1101に対して意図区間を推定する。初期設定1102として、文Mから文Nをつなげた連結文に対する尤度をL(M,N)とし、簡単のため連結文の重みを各区間に含まれる文の数とする。すなわち、上記式1において、Bias1=1、Bias2=1とする。また、最初の文（文0）から各文（文0～文4）に到達するまでの重み付き和が最大となる値を格納するための変数MAX_Wを用意し、それらの要素を全て0に初期化する。このとき、L(M,N)の値は(1103)の通りであるとする。

評価の流れ1104は以下の通りである。まず、文0の評価を行う際、文0から文0に至る経路は１つ（L(0,0)）しかないため、これが最適解MAX_W[0]＝L[0,0]となる。このとき、暫定的な区間分割結果は（[文0]）となる。続いて、文1の評価を行う際、文0から文1に至る経路は、文0経由で文1に至る（MAX_W[0]+L(1,1)）か、文頭から文1に至る（L(0,1)*2）かのどちらかであるため、値が大きくなる後者が最適解MAX_W[1]＝L(0,1)*2となる。このとき、暫定的な区間分割結果は（[文0, 文1]）となる。このような処理を文4まで繰り返すことにより、最適解MAX_Wと暫定的な区間分割結果が各文に対して得られることになり、最終的に２つの意図区間1105が取得される。

本実施例では、リアルタイムでの処理を考慮して動的計画法を用いているが、バッチ処理を行う場合などには、特に動的計画法を用いる必要はない。すなわち、全ての分割区間の組合せに対して重み付き尤度和を計算し、その値が最も高くなった組み合わせを最適解として出力すればよい。

ここで、発話処理を、リアルタイムで行う場合と、バッチ処理で行う場合のそれぞれの利点について述べておきたい。

・リアルタイム処理
実施例１の意図推定方法では、作業員が発話してから推定結果が確定するまでに時間がかかる。そのため、実施例５のARグラスのように、作業員とシステムが双方向にやり取りするＨＭＩ（Human Machine Interface）を実現する場合、推定結果が確定してからそれを作業員に提示すると作業員は結果が出るまでの間長く待たされることになり、心的ストレスが生じる。一方、推定結果が未だ確定していない段階で結果を提示してしまうと、その後の推定結果が変化した場合に作業員は困惑してしまう。そこで、推定結果が今後変化するかもしれない状態（暫定結果）と、推定が完了して今後変化しない状態（確定結果）に分けて出力することにより、作業員は現在の状態を正確に把握できるようになる。

Windowサイズの値が大きければ識別精度は上がる傾向にあるが、計算量が増加してリアルタイム性を損なう。逆に、Windowサイズの値が小さければ識別精度は下がるが計算量も減り、リアルタイム性が向上する。そこで、何らかの規則を用いてWindowサイズの最適値を選択するのが好ましい。リアルタイム処理は、発話文が入力される度に意図推定を行うものであり、１つの連結文に対して１組の結果を出力する。リアルタイム処理による意図推定装置およびその処理動作については、図１３以降を参照して説明する。また、Windowサイズの最適値の選択については、実施例２（図１６以降）で説明する。

・バッチ処理
収集した音声データ（全ての発話文）を一括で解析する場合など、作業員へのフィードバックが必要ない場合には、推定が確定した結果のみを出力すればよい。この場合、暫定結果を出力するための余分な処理（意図区間推定の途中結果の記録・更新など）が必要なく、リアルタイム処理時よりも処理量が減少する。この例については、図１２～図１３を参照して説明する。

＜発話のバッチ処理＞
バッチ処理は、対象とする全ての発話文を一括して処理する。
図１２は、バッチ処理による意図推定処理フローの例を示す。
まず、入力部700が対象とする発話系列を受け入れる(1201)。入力された発話系列（全ての発話文（以下単に文という））は記憶部（不図示）に一時保持される。次に、発話文合成部701が、発話系列に含まれる全ての文に対して、Moving Windowにより隣接する文を連結して意図推定処理の入力文を作成する(1202)。なお、バッチ処理では、Moving Windowが不要である（W_Size＝∞に設定）。
そして、発話系列に含まれる全ての文に対して処理を行ったかを判断して、その結果全てについて行っていなければ(1203：No)、処理1202を繰り返す。

一方、発話系列に含まれる全ての文に対して処理を行ったならば(1203:Yes)、意図推定部702が、作成された全ての連結文に対して意図推定処理を行い、意図推定結果とその尤度を算出する(1204)。その後、作成された全ての連結文に対して処理を行ったかを判断して、全ての連結文の処理を行ったならば(1205:Yes)、意図区間推定部703が尤度に基づいて意図区間を推定する(1206)。そして、点検結果抽出部704が、推定された全ての意図区間に対して、対応する意図推定結果を取得する(1207)。そして、全ての意図区間に対して処理を行ったならば（1208:Yes）出力部705が意図区間と意図推定結果の組合せを出力して(1209)、意図推定処理を終了する。

＜発話のリアルタイム処理＞
図１３は、リアルタイム処理による意図推定装置の構成例を示す。
この意図推定装置は、図７の意図推定装置と同様に、入力部1300と、発話文合成部1301と、意図推定部1302と、意図区間推定部1303と、点検結果抽出部1304と、出力部1305を有して構成される。図７の意図推定装置に比べて、窓サイズＤＢ1311と、区間推定情報ＤＢ1312が追加される。窓サイズＤＢ1311は図７の窓サイズＤＢ711と同様にWindowサイズを記憶する。区間推定情報ＤＢ1312は、意図区間推定部1303の出力である区間推定結果（区間推定情報）を格納する。区間推定情報には、途中の推定結果（暫定結果）と、最終的な推定結果（確定結果）が含まれる。区間推定情報については、図１４を参照して後述する。

意図区間推定部1303は、発話文合成部1301で用いたMoving WindowのWindowサイズ1311と、意図推定部1302の出力結果である意図推定結果を参照し、意図区間推定の途中結果である区間推定情報ＤＢ1312を参照又は更新する。そして、点検結果抽出部1304は、意図区間推定結果に応じて、暫定的な推定結果と確定した推定結果を出力する。出力部1305は、暫定推定結果または確定推定結果に対応して、暫定的な点検結果1306または確定済みの点検結果1307を出力する。例えば、作業員が所持する端末に音声および又は表示して点検結果を提示する。

図１４は、区間推定情報ＤＢ1312の一例を示す。
図示は、図１１において動的計画法により意図区間推定を行った場合、文4の評価が終わった時点での内容を示している。区間推定情報ＤＢ1312は、意図区間の区間推定結果1401と、各文に関して評価を行った（評価文に対する）最適値MAX_W(1402)を格納する。ここで、区間推定結果1401は、各文を評価する際に推定した、意図区間と、区間ごとの意図推定結果と、その状態（対象区間の推定結果が暫定かまたは確定か）を記録する。本実施例のように、Moving Windowと動的計画法を利用した場合、文Mの評価が終わった時点では、区画内に含まれる文の番号が全て{M－(W_Size－１)}以下である意図区間が確定区画となる。

図１５は、リアルタイムによる意図推定処理フローの一例を示す。
図１３に示す、意図推定装置による意図推定処理は以下のように行われる。
まず、入力部1300が対象とする発話系列から時系列順に発話文の入力を受け入れる(1501)。発話合成部1301が、入力された発話文に対して、Moving Windowにより隣接する文を連結して意図推定処理の入力文を作成する(1502)。
続いて、作成された全ての連結文に対して意図推定処理を行い(1505)、意図推定結果とその尤度を算出する(1504)。その後、尤度に基づいて意図区間を推定する(1506)。そして、結果が未確定である全ての意図区間に対して(1508)、対応する意図推定結果を取得する(1507)。

さらに、区間内の発話文が全て(W_Size-1)よりも前に入力されたものである場合、それらの意図区間とその意図推定結果の組合せを確定結果として出力する(1509)。そして、確定結果以外の意図区間に対する結果を暫定結果として出力する(1510)。以上の処理を発話文が入力される度に行い、発話系列に含まれる全ての文の入力に対して処理が完了すれば(1511)、意図推定処理を終了する。
ここで、推定結果を出力する処理(1509、1510)に関しては、例えば、区間推定情報ＤＢ1312において、文４が入力された時点では、｛意図区間：[文0, 文1]、意図推定結果：「フィルムNG」｝が確定結果として、｛意図区間：[文2, 文3, 文4]、意図推定結果：「用紙残量OK」｝が暫定結果として記録される。

本実施例では、Moving Windowと動的計画法を利用しているため、W_Sizeの値によって意図推定結果の状態（確定か暫定）が一意に決定されるが、その決定方法については特に問わない。例えば、区画内の発話文が全てNよりも前に入力されたものである意図区間を確定結果としてもよく、或いは、Nよりも前に入力された発話文に対する推定結果を確定結果としてもよい。何れにしてもどのような規則を用いて状態を決定しても良い。

また、本実施例による意図推定技術は保守点検分野に限らず、例えばコミュニケーションロボットやQA対話システム、文書解析、などの幅広い分野で適用可能である。
本実施例の意図推定装置によれば、「発話文」を入力して「意図カテゴリ」（保守点検では、「点検項目」と「点検結果」の組合せ。例えば「用紙残量：NG」など。）を出力できる。この手法をコミュニケーションロボットに適用する場合、「意図カテゴリ」を、「相手の要求している内容」（例えば、「挨拶をしたい」、「道を聞きたい」など）に設定すれば良い。QA対話システムであれば「データベースの中のどの回答を返せばよいか」に設定すればよく、文書解析であれば「文書のジャンル」に設定すれば良いことになる。「発話文」と「意図カテゴリ」の入出力関係は、意図推定部702によって変わってくるので、これを学習する際のデータを適用分野に合わせて用意すれば他の分野にも容易に適用できる。

実施例２は、過去の点検履歴を参照し、発話文合成部にて利用するMoving Windowのwindowサイズの調整、および意図区間推定部にて利用する重みの値の調整について述べる。この調整により、推定精度がさらに向上して、リアルタイム性を向上させることができる。その結果、作業員にとってより使い易いシステムを構築することが可能となる。

図１６は、実施例２による意図推定装置の構成例を示す。この意図推定装置は、実施例１（図７）に示す意図推定装置に対して、Windowサイズ調整部1601、重み調整部1602、および点検履歴ＤＢ（単に点検履歴といってもよい）1603が追加されている。Windowサイズ調整部1601は、点検履歴ＤＢ1603を参照して、Moving Windowのサイズ（W_Size）を調整する。発話文合成部は、調整されたWindowサイズを用いて発話文を繋げて連結文を生成する。重み調整部1602は、点検履歴ＤＢ1603を参照して、重みの値を調整する。意図区間推定部は、尤度と重み（すなわち調整された重み）に基づいて意図区間を決定する。ここで、尤度に重みを掛けた数値を評価値と定義する。意図区間推定部は、各区間に与えられた評価値に基づいて発話系列を意味単位で区間分割する。

ここで、図１７を参照して、点検履歴ＤＢ1603の構成について説明する。点検履歴ＤＢ1603は、発話文ごとに付与される発話番号に対応して、発話系列171と推定結果172を含む点検履歴情報を格納する。発話系列171には、発話開始時刻と発話終了時刻のような時間情報、および作業者の発話が含まれ、推定結果172には点検項目1721と点検結果1722（すなわち意図区間と意図推定結果の組合せ）が含まれる。なお、図１７に示す点検履歴情報は、点検対象ごと（すなわちプリンタの機体ごと）に作成されることが望ましい。

Windowサイズ調整部1601によるW_Sizeの調整は、以下のように行なわれる。
意図区間が全体的に長い場合は、点検中に作業員が多く発話していることを意味するため、W_Sizeの値を大きくして（長いWindowサイズを用いて）、推定精度を高くすることができる。この場合、例えば図１８に示す処理フローにて、W_Sizeの調整を行うのが好ましい。

まず、W_Sizeを適当な値W_Size_Initで、変数Countを0で初期化する(1801)。そして、意図推定部が意図推定処理を行う(1802)。意図推定の結果、出力された意図区間のうち、区間内に含まれる発話文数がN_High以上のものが存在すれば(1803)、W_Sizeをインクリメントして変数Countを0にリセットする(1804)。N_Highはどのような値でも良いが、例えば図１８に示すように、W_Size-1などの値に設定すると効果的である。

一方、全ての意図区間内の発話文数がN_Highより少なければ、変数Countをインクリメントする(1805)。そして、変数CountがCount_Max以上になれば(1806)、W_Sizeをデクリメントして、変数Countを0にリセットする(1807)。以上の調整を全ての意図推定処理に対して実施すれば(1808)、処理を完了する。

なお、W_Sizeをインクリメントする条件(1803)としては、上記例の他にも、「過去N個の意図区間に含まれる発話文数の平均値が一定の値以上であれば」、「過去M個の意図区間のうち、区間内に含まれる発話文数が一定の値以上のものがN個以上あれば」、「現在の意図区間に含まれる発話文数が、過去の値の平均値よりも一定割合以上大きければ」など、区間内に含まれる発話文の数に関するものであれば何でも良い。また、実施例２による意図推定処理(1802)としては、図１５の処理フローにおける1発話文の処理（(1501)～(1510)）としても良いし、複数発話文の処理をまとめた単位（(1501)～(1511)）で行っても良い。また、特に実施例１による意図推定処理でなくても、Moving Windowを用いて区間を推定する処理であればどのようなものでも構わない。

また、作業員の発話間隔が長い場合や、単位時間当たりの発話時間の割合が低い場合には、作業員が発話をしてから推定結果が確定するまでに時間を要してしまい、リアルタイム性を損なってしまう。そのため、W_Sizeの値は小さく設定することが望ましい。この場合、例えば図１９の処理フローによる方法にて、W_Sizeの調整を行うと効果的である。図１９は、W_Sizeをインクリメントする条件(1901)以外は図１８と同様であり、同じ処理を行うものとする。W_Sizeをインクリメントする条件(1901)としては、図１９に示す「全ての発話の時間間隔がT_High 以下であった場合」の他、「過去N発話の時間間隔の平均値がT_High 以下であった場合」、「意図区間どうしの時間間隔の平均値がT_High 以下であった場合」、「同じ意図区間に含まれる発話の時間間隔の平均値がT_High以下であった場合」、「単位時間中に発話していた時間の割合がT_High以下であった場合」など、発話間隔や発話時間の割合に関するものであれば何でも良い。ここで、時間間隔とは、ある発話が終了した時刻から、次の発話が始まる時刻までの時間間隔を言う。また、発話の時間間隔に基づいてW_Sizeを決定する別の方法としては、評価対象とする発話文との時間間隔がTwindow以内の全ての文がWindow内に含まれるようにW_Sizeの値を調整する方法が挙げられる。例えば、図１７において、発話No.8「よし」に対して評価を行う場合、発話No.7との時間間隔は0:17、発話No.6との時間間隔は0:37、発話No.5との時間間隔は2:30、となるため、例えばTwindow=2:00に設定した場合は発話No.6、発話No.7をWindow内に含むようにW_Size=3の値に設定される。

さらに、意図推定結果が「点検以外の発話」である意図区間が多い場合には、作業員が点検中に行う雑談が多いことを意味する。この場合、W_Sizeの値を大きくした方が、推定精度が高くなるため、例えば図２０の処理フローの方法にてW_Sizeの調整を行うと効果的である。図２０は、W_Sizeをインクリメントする条件(2001)以外は図１８と同様であり、同じ処理を行うものとする。W_Sizeをインクリメントする条件(2001)としては、図２０に示す「推定結果が「点検以外の発話」である割合がEX_High以上である場合」の他、「過去M個の推定結果のうち、N個以上が「点検以外の発話」である場合」、「推定結果「点検以外の発話」が連続してN回以上出力された場合」など、特定の推定結果（本実施例では「点検以外の発話」）の頻度に関するものであれば何でも良い。

次に、重み調整部1602による重みの値を調整する方法について述べる。
未点検の検査項目に関する尤度に対して重みを高く設定すると、推定精度が高くなる。ここで、未点検とは、出力された意図推定結果が、図１７に示す点検履歴情報の点検履歴の点検項目1721に含まれない状態であることを言う。この場合、例えば数１による重みW(M,N)に対して、数２のように調整した重みW₂(M,N)を利用すると効果的である。

ここで、Bias3は文Mから文Nまでをつなげた連結文に対する意図推定結果が未点検項目に関するものであった場合に課せられる重みであり、Bias3>1に設定すると効果的である。

また、各発話の時刻情報に基づいてクラスタリングを行い、区間分割（以後、分割された区間を時間区間という）した結果を用いると効果的である。すなわち、連結文に含まれる発話文が同じ時間区間に含まれる場合に重みを大きく設定すると、推定精度が高くなる。この場合、例えば数１による重みW(M,N)に対して、数３のように調整した重みW₃(M,N)を利用すると効果的である。

ここで、Bias4は文Mから文Nまでの全ての文が同じ時間区間に含まれる場合に課せられる重みであり、Bias4>1に設定すると効果的である。上記クラスタリングはどのように行っても良いが、例えば発話間隔に閾値Tclusterを用いた方法を用いると効果的である。すなわち、発話系列の先頭文から順に評価を行い、発話間隔がTcluster以下である発話文どうしを同じ時間区間に、発話間隔がTclusterより大きな発話文どうしを別々の時間区間に含めるという方法を用いればよい。この方法によると、例えば図１７の点検履歴情報において、Tcluster=1:00に設定した場合、[文0, 文1, 文2, 文3]、[文4, 文5]、[文6, 文7, 文8]の３つの区間が、時間区間として得られる。また、この枠組みを用いてリアルタイムで意図区間推定を行いたい場合は、例えば数１による重みW(M,N)に対して、数４のように調整した重みW₄(M,N)を利用すると効果的である。

ここで、Bias5は文Mから文Nまでの全ての文の発話間隔が短い場合に課せられる重みであり、Bias5>1に設定すると効果的である。
なお、実施例２によるWindowサイズと重み調整は、実施例１による意図推定処理に限らず、Windowサイズや重みを用いて区間を決定するどのような手法に対しても適用可能である。

図２１は、実施例２に係る、リアルタイム処理による意図推定装置の一例を示す。このリアルタイム処理に係る意図推定装置は、図１３に示す意図推定装置に、Windowサイズ調整部2101、重み調整部2102、および点検履歴2103が追加された構成である。図２１の各部位は、図１３及び図１６における意図推定装置の部位と同様の機能および処理を有する。

実施例３は、保守点検時に用いる用語の辞書を参照し、発話文合成部にて利用するMoving Windowのwindowサイズの調整、および意図区間推定部にて利用する重みの値の調整について述べる。これにより、推定精度をさらに向上させることができる。

図２２は、実施例３による意図推定装置の構成例を示す。この意図推定装置は、実施例１（図７）に示す意図推定装置に対して、Windowサイズ調整部2201、点検用語辞書ＤＢ（単に点検用語辞書と言ってもよい）2202、および重み調整部2203が追加されている。Windowサイズ調整部2201は、点検用語辞書ＤＢ2202を参照し、Moving Windowのサイズ（W_Size）を調整する。重み調整部2203は、点検用語辞書ＤＢ2202を参照して、重みの値を調整する。

図２３乃至図２５は、点検用語辞書ＤＢ2202の一例を示す。図２３は点検項目に関する用語辞書を示しており、点検項目名の一覧が記述されている。図２４は点検結果に関する用語辞書を示しており、点検項目名2401ごとに、点検結果として用いる用語2402の一覧が記述されている。この例では、点検項目間で点検用語が被らないように設計されている。図２５は、図２４と同様に点検結果に関する用語辞書を示しており、点検項目名2501ごとに、点検結果として用いる用語2502の一覧が記述されているが、この例では、点検項目間で点検用語の被りを許容している。

Windowサイズ調整部2201によるW_Sizeの調整は、以下のように行なわれる。
発話文の中に、点検用語辞書ＤＢ2202に含まれる用語が存在する場合は、W_Sizeを大きく設定（長いWindowサイズを利用）することにより、意図区間を適切に推定できる。逆に発話文の中に、点検用語辞書ＤＢ2202に含まれる用語が存在しない場合、W_Sizeを小さく設定（短いWindowサイズを利用）することで、計算量を節約できる。そのため、例えば、数５のように、W_Sizeを決定すると効果的である。実施例２によるWindowサイズの調整は、特に実施例１による意図推定処理でなくても、Moving Windowを用いる手法であればどのようなものに対しても適用できる。また、実施例２では点検用語辞書を利用したが、文章内に存在する用語の種類によって最適なWindowサイズが決定できる場合には、どのような種類の辞書を利用しても同様の方法で調整を行うことができる。

ここで、W_Size_LongとW_Size_ShortはW_Size_Long>W_Size_Shortを満たす値である。

次に、意図区間推定部で用いられる重みの値の調整は、以下のように行われる。
正しく推定された意図区間では、同じ辞書に含まれる複数種類の用語が同一区間に存在することは稀である。そこで、このような場合にはその区画の重みを小さく設定することにより、推定精度を高めることができる。例えば、図２３の点検項目に関する用語辞書に関しては、対象区画内に複数の辞書用語が含まれるかどうかを調べる。例えば、区間内に「コンセント」「フィルム」の両方の用語が含まれる場合は、複数の辞書用語が含まれるとして、重みを調整する。ここでは、数１による重みW(M,N)に対して、数６のように調整した重みW₅(M,N)を利用すると効果的である。

ここで、Bias6は文Mから文Nまでをつなげた連結文に複数の辞書用語が存在した場合に課せられる重みであり、0<Bias6<1に設定すると効果的である。

一方、図２４の点検結果に関する用語辞書に関しては、複数の点検項目に関する点検用語が含まれるかどうかを調べる。例えば、区間内に「外れ」「断線」の両方の用語が含まれる場合は、単一の点検項目「コンセント」に関する用語であるとして重みは調整しないが、区間内に「外れ」「汚れ」の両方の用語が含まれる場合は、複数の点検項目「コンセント」「フィルム」に関する用語が含まれるとして、重みを調整する。ここでは、例えば数１による重みW(M,N)に対して、数７のように調整した重みW₆(M,N)を利用すると効果的である。

ここで、Bias7は文Mから文Nまでをつなげた連結文に複数の点検項目に関する点検用語が含まれる場合に課せられる重みであり、0<Bias7<1に設定すると効果的である。

一方、正しく推定された意図区間では、同じ辞書に含まれる同一用語が区間内に複数存在することも稀である。そのため、このような場合にはその区画の重みを小さく設定することにより、推定精度を高めることができる。例えば、図２３の点検項目に関する用語辞書に関しては、対象区画内に同一の辞書用語が複数含まれるかどうかを調べる。例えば、区間内に「コンセント」の用語が複数回含まれる場合は、複数の辞書用語が含まれるとして重みを調整する。ここでは、数１による重みW(M,N)に対して、数８のように調整した重みW₇(M,N)を利用すると効果的である。

ここで、Bias8は文Mから文Nまでをつなげた連結文に複数の点検項目に関する点検用語が含まれる場合に課せられる重みであり、0<Bias8<1に設定すると効果的である。

一方、図２５の点検結果に関する用語辞書に関しては、同一の点検項目に関する点検用語が複数含まれるかどうかを調べる。例えば、区間内に「外れ」「汚れ」の両方の用語が１つずつ含まれる場合は、別々の点検項目「コンセント」「フィルム」に関する用語であるとして重みは調整しないが、区間内に「外れ」「断線」の両方の用語が含まれる場合は、同一の点検項目「コンセント」に関する用語が複数含まれるとして、重みを調整する。ここでは、例えば数１による重みW(M,N)に対して、数９のように調整した重みW₈(M,N)を利用すると効果的である。

ここで、Bias9は文Mから文Nまでをつなげた連結文に同一の点検項目に関する点検用語が複数含まれる場合に課せられる重みであり、0<Bias9<1に設定すると効果的である。

点検用語辞書を利用して重みを調整する際、数６～数９を組み合わせて利用すると効果的である。その際、0<Bias6<Bias8<1、0<Bias7<Bias9<1に値を設定すると特に効果的である。なお、実施例３による重み調整は、実施例１による意図推定処理に限らず、重みを用いて区間を決定するどのような手法に対しても適用可能である。また、実施例３では点検用語辞書を利用したが、区間内に存在する用語の種類や出現頻度が限定的である場合には、どのような種類の辞書を利用しても同様の方法でWindowサイズや重みの調整を行うことができる。

図２６は、実施例３に係る、リアルタイム処理による意図推定装置の一例を示す。このリアルタイム処理に係る意図推定装置は、図１３に示す意図推定装置に対して、Windowサイズ調整部2601、点検用語辞書2602、および重み調整部2603が追加された構成である。図２６の各部位は、図１３及び図２２におけるにおける意図推定装置の部位と同様の機能および処理を有する。

実施例４は、過去の点検履歴や点検用語辞書を参照して作業員の行動パターンを学習し、その結果を用いて発話文合成部にて利用するMoving WindowのwindowサイズW_Sizeの調整、および意図区間推定部にて利用する重みの値の調整について述べる。これにより、推定精度をさらに向上させることができる。

図２７は、実施例４による意図推定装置の構成例を示す。この意図推定装置は、実施例１（図７）に示す意図推定装置に対して、Windowサイズ調整部2701、重み調整部2702、点検履歴ＤＢ2703、行動パターンＤＢ2704、行動パターンモデル化部2705、および点検用語辞書ＤＢ2706が追加されている。行動パターンモデル化部2705は、点検履歴ＤＢ2703および点検用語辞書ＤＢ2206を参照して、作業員の行動パターン2704´をモデル化する。行動パターンＤＢ2704はモデル化された行動パターン2704´を格納する。Windowsサイズ調整部2701は、作成された行動パターン2704´のモデルを用いてWindowサイズを調整する。重み調整部2702は、点検履歴2703´と行動パターン2704´のモデルを用いて、重みの調整を行う。

図２８は、行動パターンモデル化部2705が、作業員の点検順序をモデル化して生成する行動パターン2704´の一例を示す。例えば、行動パターン2704´は、点検履歴ＤＢ2703を参照し、各点検項目2801に対する最も可能性の高い点検順序2802を計算して表にまとめたものである。一例では、「O(点検項目)=最も可能性の高い点検順序」と記載することにする。

次に、意図区間推定部にて利用する重みの値の調整について述べる。例えば、数１による重みW(M,N)に対して、数１０のように調整した重みW₉(M,N)を利用すると効果的である。

ここで、itemcurrは文Mから文Nまでをつなげた連結文に対する意図推定結果（検査項目）、ordercurrは現在の点検順序を表す。すなわち、Bias10は、連結文に対する意図推定結果が、現在の順番で点検されやすい場合に課せられる重みであり、Bias10>1に設定すると効果的である。なお、現在の点検順序とは、これまで推定された点検項目数に１を足したものである。

図２９は、作業員の点検順序をより精緻にモデル化するための行動パターン2704´の一例を示す。例えば、各点検項目(item)がn番目に点検される確率（または尤度）がPitem(n)として記述されている(2901)。この場合、例えば、数１による重みW(M,N)に対して、数１１のように調整した重みW₁₀(M,N)を利用すると効果的である。

ここで、Pitem(n)の値に関しては、図２９のように、点検履歴ＤＢ2703を参照して計算した確率の値を参照してもよいが、これに相当する値をベイズ推定などを用いて統計的に計算しても良い。また、HMM(Hidden Marcov Model)や深層学習など、時系列パターンをモデル化できる機械学習方式を用いてこれに相当する値を計算しても良い。

図３０は、行動パターンモデル化部2705が、作業員の点検時間をモデル化する際に生成する行動パターン2704´の一例を示す。例えば、点検履歴ＤＢ2703を参照し、各点検項目3001に対する点検時間3002を計算して表にまとめたものである。点検時間3002としては、例えば過去の点検にて要した時間の平均値や中央値、最大値、最小値、一定期間内の累積値など、どのような値を設定してもよい。この場合、「T(点検項目)=点検時間」と記載することにする。

次に、意図区間推定部にて利用する重みの値の調整について述べる。例えば、数１による重みW(M,N)に対して、数１２のように調整した重みW₁₁(M,N)を利用すると効果的である。

ここで、itemcurrは文Mから文Nまでをつなげた連結文に対する意図推定結果（検査項目）、Tcurrはその連結文を発話するのに要した時間、MINは最小値を返す関数であるとする。これにより、作業員にとって発話時間が通常よりも長い連結文に対して重みを小さく設定することができる。これは、文章構造が複雑な発話系列に対しては、短い区画単位で推定することが望ましいという考えの下での設定方法であり、逆に長い区画単位で推定する方が望ましい場合には、例えば数１３による調整を行えばよい。

ここで、MAXは最大値を返す関数であるとする。

図３１は、作業員の点検時間をより精緻にモデル化するための行動パターン2704´の一例を示す。例えば、各点検項目(item)に対して、意図区間内にn個の発話文が含まれる場合に要する点検時間がTitem(n)として記述されている(3101)。この場合、例えば数１による重みW(M,N)に対して、数１４のように調整した重みW₁₂(M,N)を利用すると効果的である。

なお、数１１と同様に、長い区画単位で推定する方が望ましい場合には、例えば数１５による調整を行えばよい。

図３２は、行動パターンモデル化部2705が、作業員の点検順序と点検時間の関係をモデル化する際に生成する行動パターン2704´の一例を示す。例えば、点検履歴ＤＢ2703を参照し、点検順序3201と点検時間3202の関係を計算して記録する。一例では、「T2(点検順序)=点検時間」と記載することにする。また、1発話に要する時間の平均値(3203)も計算して記録されており、Taveと記載する。この場合、W_Sizeの調整は以下の通りである。W_Sizeを、例えば数１６のように設定すれば効果的である。

ここで、ordercurrは現在の点検順序を、CLIPは小数値を整数値に丸める関数であり、Bias11は整数値であるとする。

実施例４によるWindowサイズの調整は、特に実施例１による意図推定処理でなくても、Moving Windowを用いる手法であればどのようなものに対しても適用できる。また、実施例４による重み調整は、実施例１による意図推定処理に限らず、重みを用いて区間を決定するどのような手法に対しても適用可能である。また、これらは保守点検分野だけでなく、文書解析や対話制御など、様々な分野に適用可能である。

図３３は、実施例４に係る、リアルタイム処理による意図推定装置の一例を示す。この意図推定装置は、図１３に示す意図推定装置に対して、Windowサイズ調整部3301、重み調整部3302、点検履歴ＤＢ3303、行動パターンＤＢ3304、行動パターンモデル化部3305、および点検用語辞書ＤＢ3306が追加された構成である。図３０の各部位は、図１３及び図２７における意図推定装置の部位と同様の機能および処理を有する。

実施例５は、推定された点検結果をリアルタイムで作業員に提示するユーザインタフェース（ＵＩ）について述べる。好ましい例では、推定が完了した確定結果だけでなく、推定が未完了である暫定結果も含めて提示する。さらに、作業員は、暫定結果として表示された点検項目に対し、発話や顔の動きなどにより修正作業を行うことができる。

図３４は、実施例５による意図推定装置の一例を示す。図示の例は、図１３の意図推定装置に対して、作業支援UI3401が追加された構成である。作業支援ＵＩ3401では、区間推定情報ＤＢ3402を参照し、最新の推定結果（暫定、確定）を作業員の端末の表示部に表示する。一方、作業員が発話や顔の動きなどで、入力部を介して推定結果の修正の入力を促すと、作業支援UI3401は区間推定情報ＤＢ3402の内容を書き換える。なお、図３４の区間推定情報ＤＢ3402および各部位は、図１３における意図推定装置の各部位と同様の機能および処理を有する。

図３５は、作業支援ＵＩ3401による画面の表示例を示す。
作業員の端末は、作業支援ＵＩ3401による画面を提示する、例えばAR/MRグラス、スマートグラスなどの作業員が装着する端末を想定している。なお、これに限らず、スマートウォッチや液晶ディスプレイなどを利用して視覚的に情報を表示し、或いはヘッドフォンなどを利用して音声で情報を出力するなど、情報の提示手段は特に問わない。

図３５において、作業員が実際に見ている光景3501に重畳させる形で、最新の推定結果3502を表示させる。この場合、推定結果が確定した点検項目だけでなく、推定結果が未確定な点検項目に関する暫定結果も併せて表示する。これにより、作業員が結果を待たされることがなくなり、作業員の心的ストレスを軽減することができる。例えば、図３５において、点検結果がOK（適格）で確定した項目に対しては〇印にて表示し(3503)、NG（不適）で確定した項目に対しては×印にて表示する(3504)。また暫定結果に対しては、OKの場合は△印にて(3505)、NGの場合は▲印にて表示する。

さらに、作業員は、表示された推定結果に対して修正を行うことができる。ここで、修正対象は、暫定結果が表示されている項目（△ または ▲）に限られる。これらの暫定結果に対して、作業員の発話（特定の言葉を発する）や顔の動き（うなずく、首を振る、口や目を動かす）などにより修正を行う。これは、例えば、作業支援ＵＩ3401が画像認識機能や音声認識機能を備えて、取得した発話や動きをこれらの機能を用いて認識することで実現できる。これにより、修正対象を選択する作業コストを削減することができ、作業員は両手がふさがれた状態でも容易に暫定結果の修正を行うことができる。この場合、暫定結果に対しては、暫定結果の確信度（尤度）や、結果を修正するためには何と発話すればよいのか、結果が確定するためには何と発話すればよいのか、などの情報を追記すると、さらに効果的である。

なお、本実施例では、修正対象を暫定結果に限定しているが、暫定結果が複数存在する場合には、その中で最も新しく推定された結果を修正対象として設定しても良い。また、複数ある暫定結果の中から修正対象のとなる項目を発話や顔の動きなどにより選択できるようにしてもよい。また、暫定結果とは逆に確定結果を修正対象として限定してもよい。

以上、幾つかの実施例を説明したが、本発明は上記した幾つかの実施例に限定されず、いろいろと変形や応用して実施できる。例えば、リアルタイムによる意図推定技術は、上記実施例に限らず、暫定結果と確定結果が別々に得られるようなあらゆる技術や手法にも適用できる。また、本発明による意図推定技術は、上記実施例に係る機械の保守点検分野だけでなく、接客業、製造業、建設業、農林水産業、電気・ガス・水道業、エンターテインメントなど、様々な分野に適用可能である。
また、本発明は、意図推定装置およびその方法として把握したが、発話処理装置およびその方法として把握することもできる。

７００、１３００：入力部７０１，１３０１：発話文合成部
７０２，１３０２：意図推定部７０３，１３０３：意図区間推定部
７０４，１３０４：点検結果抽出部７０５、１３０５：出力部
１３１１：WindowサイズＤＢ１３１２、３４０２：区間推定情報ＤＢ
１３０６：点検結果（暫定）１３０７：点検結果（確定）
１６０１、２１０１、２２０１、２６０１：Windowサイズ調整部
１６０２、２１０２、２２０３、２６０３、３３０２：重み調整部
１６０３、２１０３、２７０３、３３０３：点検履歴ＤＢ
２２０２、２６０６、２７０６、３３０６：点検用語辞書ＤＢ
２７０４、３３０４：行動パターンＤＢ
２７０５、３３０５：行動パターンモデル化部
３４０１：作業支援ＵＩ

Claims

入力された発話系列に対し、隣接する発話文をつなげて連結文を生成する発話文合成部と、
前記発話文合成部により生成された前記連結文に対して意図推定を行い、意図推定結果とその尤度を出力する意図推定部と、
前記尤度に基づいて発話系列を意味単位で区間分割する意図区間推定部と、
分割された区間ごとに前記意図推定結果を出力する結果抽出部と、
分割された区間（分割区間）ごとに、前記意図推定結果と、該意図推定結果が確定しているか否かを表す情報とを対応させて記憶する記憶部と、を有し、
前記発話文合成部は、移動窓を用いて隣接する発話文をつなげて前記連結文を生成し、
前記意図区間推定部は、前記移動窓のサイズと、前記記憶部に記憶されている情報（区間推定情報）を参照して、動的計画法を用いて意図区間を推定し、
前記結果抽出部は、前記意図区間推定部による推定結果に応じて、該推定結果が確定かまたは暫定かを示す情報を出力する
ことを特徴とする意図推定装置。
請求項１記載の意図推定装置において、前記意図推定部は１つの連結文に対して1組の意図推定結果を出力する。
入力された発話系列に対し、隣接する発話文をつなげて連結文を生成する発話文合成部と、
前記発話文合成部により生成された前記連結文に対して意図推定を行い、意図推定結果とその尤度を出力する意図推定部と、
前記尤度に基づいて発話系列を意味単位で区間分割する意図区間推定部と、
分割された区間ごとに前記意図推定結果を出力する結果抽出部と、を有し、
前記意図区間推定部は、移動窓を用いて発話系列を意味単位で区間分割し、分割された区間（分割区間）に含まれる発話文の数に関する履歴に基づいて該移動窓のサイズを決定する
ことを特徴とする意図推定装置。
請求項３記載の意図推定装置において、前記分割区間に含まれる発話文の数が多い場合、前記移動窓のサイズを大きく設定する。
入力された発話系列に対し、隣接する発話文をつなげて連結文を生成する発話文合成部と、
前記発話文合成部により生成された前記連結文に対して意図推定を行い、意図推定結果とその尤度を出力する意図推定部と、
前記尤度に基づいて発話系列を意味単位で区間分割する意図区間推定部と、
分割された区間ごとに前記意図推定結果を出力する結果抽出部と、を有し、
前記意図区間推定部は、移動窓を用いて発話系列を意味単位で区間分割し、発話の時間間隔または単位時間中に発話していた時間の割合に関する履歴に基づいて該移動窓のサイズを決定する
ことを特徴とする意図推定装置。
請求項５記載の意図推定装置において、発話の時間間隔が大きい場合または単位時間中に発話していた時間の割合が低い場合に前記移動窓のサイズを小さく設定する。
入力された発話系列に対し、隣接する発話文をつなげて連結文を生成する発話文合成部と、
前記発話文合成部により生成された前記連結文に対して意図推定を行い、意図推定結果とその尤度を出力する意図推定部と、
前記尤度に基づいて発話系列を意味単位で区間分割する意図区間推定部と、
分割された区間ごとに前記意図推定結果を出力する結果抽出部と、を有し、
前記意図区間推定部は、移動窓を用いて発話系列を意味単位で区間分割し、分割された区間に対する意図推定結果に関する履歴に基づいて該移動窓のサイズを決定する
ことを特徴とする意図推定装置。
請求項７記載の意図推定装置において、特定の意図推定結果に関する履歴が多い場合に前記移動窓のサイズを大きく設定する。
入力された発話系列に対し、隣接する発話文をつなげて連結文を生成する発話文合成部と、
前記発話文合成部により生成された前記連結文に対して意図推定を行い、意図推定結果とその尤度を出力する意図推定部と、
前記尤度に基づいて発話系列を意味単位で区間分割する意図区間推定部と、
分割された区間ごとに前記意図推定結果を出力する結果抽出部と、を有し、
前記意図区間推定部は、各区画に与えられた評価値に基づいて発話系列を意味単位で区間分割し、分割された区間に対する意図推定結果に関する履歴に基づいて該評価値の重みを変化させる
ことを特徴とする意図推定装置。
請求項９記載の意図推定装置において、前記評価値の高い区画（または低い区画）が分割区間として選択される可能性が高い場合、履歴に存在しない意図推定結果が得られる区画に対する該評価値を高く（または低く）設定する。
入力された発話系列に対し、隣接する発話文をつなげて連結文を生成する発話文合成部と、
前記発話文合成部により生成された前記連結文に対して意図推定を行い、意図推定結果とその尤度を出力する意図推定部と、
前記尤度に基づいて発話系列を意味単位で区間分割する意図区間推定部と、
分割された区間ごとに前記意図推定結果を出力する結果抽出部と、を有し、
前記意図区間推定部は、各区画に与えられた評価値に基づいて発話系列を意味単位で区間分割し、発話時刻に基づいて発話文をクラスタリングした結果、該結果に基づいて該評価値の重みを変化させる
ことを特徴とする意図推定装置。
入力された発話系列に対し、隣接する発話文をつなげて連結文を生成する発話文合成部と、
前記発話文合成部により生成された前記連結文に対して意図推定を行い、意図推定結果とその尤度を出力する意図推定部と、
前記尤度に基づいて発話系列を意味単位で区間分割する意図区間推定部と、
分割された区間ごとに前記意図推定結果を出力する結果抽出部と、を有し、
前記意図区間推定部は、各区画に与えられた評価値に基づいて発話系列を意味単位で区間分割し、該評価値の高い区画（または低い区画）が分割区間として選択される可能性が高い場合、区画内の発話間隔が小さい場合に該評価値を高く（または低く）するように重みを設定する
ことを特徴とする意図推定装置。
入力された発話系列に対し、隣接する発話文をつなげて連結文を生成する発話文合成部と、
前記発話文合成部により生成された前記連結文に対して意図推定を行い、意図推定結果とその尤度を出力する意図推定部と、
前記尤度に基づいて発話系列を意味単位で区間分割する意図区間推定部と、
分割された区間ごとに前記意図推定結果を出力する結果抽出部と、を有し、
前記意図区間推定部は、移動窓を用いて発話系列を意味単位で区間分割し、推定結果に関わる用語を集めた辞書に基づいて該移動窓のサイズを決定する
ことを特徴とする意図推定装置。
請求項１３記載の意図推定装置において、前記意図区間推定部は、辞書用語が含まれる文を評価する際に前記移動窓のサイズを大きく設定する。
入力された発話系列に対し、隣接する発話文をつなげて連結文を生成する発話文合成部と、
前記発話文合成部により生成された前記連結文に対して意図推定を行い、意図推定結果とその尤度を出力する意図推定部と、
前記尤度に基づいて発話系列を意味単位で区間分割する意図区間推定部と、
分割された区間ごとに前記意図推定結果を出力する結果抽出部と、を有し、
前記意図区間推定部は、各区画に与えられた評価値に基づいて発話系列を意味単位で区間分割し、推定結果に関わる用語を集めた辞書に基づいて該評価値の重みを変化させる
ことを特徴とする意図推定装置。
請求項１５記載の意図推定装置において、前記意図区間推定部は、前記評価値の高い区画（または低い区画）が分割区間として選択される可能性が高い場合、辞書用語が共起している区間または同一用語が複数存在している区画に対する該評価値を低く（または高く）設定する。
入力された発話系列に対し、隣接する発話文をつなげて連結文を生成する発話文合成部と、
前記発話文合成部により生成された前記連結文に対して意図推定を行い、意図推定結果とその尤度を出力する意図推定部と、
前記尤度に基づいて発話系列を意味単位で区間分割する意図区間推定部と、
分割された区間ごとに前記意図推定結果を出力する結果抽出部と、を有し、
前記意図区間推定部は、各区画に与えられた評価値に基づいて発話系列を意味単位で区間分割し、意図推定結果の出力順序に関する履歴に基づいて該評価値の重みを変化させる
ことを特徴とする意図推定装置。
請求項１７記載の意図推定装置において、前記評価値の高い区画（または低い区画）が分割区間として選択される可能性が高く、かつ、対応する意図推定結果が現在の順序で出力される確率が高い場合に、対象区画に対する該評価値を高く（または低く）設定する。
入力された発話系列に対し、隣接する発話文をつなげて連結文を生成する発話文合成部と、
前記発話文合成部により生成された前記連結文に対して意図推定を行い、意図推定結果とその尤度を出力する意図推定部と、
前記尤度に基づいて発話系列を意味単位で区間分割する意図区間推定部と、
分割された区間ごとに前記意図推定結果を出力する結果抽出部と、を有し、
前記意図区間推定部は、各区画に与えられた評価値に基づいて発話系列を意味単位で区間分割し、分割された区間における発話時間に関する履歴に基づいて該評価値の重みを変化させる
ことを特徴とする意図推定装置。
請求項１９記載の意図推定装置において、前記評価値の高い区画が分割区間として選択される可能性が高く、かつ、発話時間が履歴よりも短い（または長い）場合に、対象区画に対する該評価値を高く設定する。
入力された発話系列に対し、隣接する発話文をつなげて連結文を生成する発話文合成部と、
前記発話文合成部により生成された前記連結文に対して意図推定を行い、意図推定結果とその尤度を出力する意図推定部と、
前記尤度に基づいて発話系列を意味単位で区間分割する意図区間推定部と、
分割された区間ごとに前記意図推定結果を出力する結果抽出部と、を有し、
前記意図区間推定部は、移動窓を用いて発話系列を意味単位で区間分割し、意図推定結果の出力順序と、それぞれの区間における発話時間に関する履歴に基づいて該移動窓のサイズを決定し、かつ
前記意図区間推定部は、現在の順序における履歴中の発話時間が長い場合に、前記移動窓のサイズを大きく設定する
ことを特徴とする意図推定装置。
入力された発話系列に対し、隣接する発話文をつなげて連結文を生成する発話文合成部と、
前記発話文合成部により生成された前記連結文に対して意図推定を行い、意図推定結果とその尤度を出力する意図推定部と、
前記尤度に基づいて発話系列を意味単位で区間分割する意図区間推定部と、
分割された区間ごとに前記意図推定結果を出力する結果抽出部と、を有し、
前記結果抽出部は、前記意図推定結果を暫定結果と確定結果を分けて出力し、
ユーザが有する端末に該意図推定結果をリアルタイムで提示し、ユーザの操作により該端末から該暫定結果または該確定結果に対して修正の入力を行うことができるユーザインタフェースを有する
ことを特徴とする意図推定装置。