リアクティブ対話システム

(1)

リアクティブ対話システム

Reactive dialogue system

両角

和軌

1

久保寺

誠

1

Kazuki Morozumi

1

and Makoto Kubodera

1

_株式会社

_Nextremer

1

_{Nextremer Co., Ltd}

Abstract: We propose new dialogue system architecture using reactive design, functional design and

microservices.This architecture improves continuous delivery and problem division for dialogue system. For provider side, when we provide some dialogue system we will get feedback from user and should improve own system as soon as possible.Reactive dialogue system make modification & deployment easy. For system side, Reactive dialogue system can change own functionality based on any event.

It means system can change own self based on user request, domain of task and topic of conversation.

1.はじめに

本提案では、対話システムの各機能の結合度を下げ、より柔軟に振る舞いを変更できるリアクティブ対話システムの構成について述べる。リアクティブ対話システムでは、対話システムを構成する各機能を1 つの関数として扱い、それらの関数を合成することで1 つの対話システムを構成する。これにより各関数は独立した環境で動作し、各機能の変更や機能の組み合わせの変更を容易にする。以降、リアクティブ対話システムが解決する課題、システムの構成要素について詳しく解説する。図1. リアクティブ対話システム概要

2.対話システム運用における課題

株式会社 Nextremer ではこれまで多くの音声対話システム、テキストチャットボットシステムを開発・運用してきた。対話システムを利用したサービスの実運用において、ユーザー満足度を向上させるための細かなチューニングが多く発生することが明らかになった。具体的には、ユーザーの発話に対して想定と全く異なる応答をしている場合に、ルールベースの対話シナリオ、辞書、外部知識を更新するような作業である。また、対話システムの効果検証を行うために、複数の対話戦略を比較する場面が多々あり（例えば AB テストなど）、対話システムの振る舞いをいくつかのパターンで変更させる必要があった。弊社のこれまでの対話システム開発では対話システムそのももの実装に重きを置いていたため、重厚で結合度の高い実装となっていた。これにより上記のような運用や実験の際に、結合度の高い実装の影響で意図した変更を柔軟に行えず、場合によっては大部分を実装し直す必要があった。対話システムの領域では、主に対話タスクを解決するアルゴリズムとその精度が関心の対象であるため、昨今のWeb 開発に取り入れられているようなデプロイのサイクルを高速にしたり、変更を容易に可能にするアーキテクチャについてはさほど言及されていない。しかし、対話システムを利用したサービ人工知能学会研究会資料 SIG-SLUD-B508-07 － 35 －

(2)

スの評価は当然ながら利用したユーザーが快適に利用できたか、が焦点となるため、利用ユーザーからのフィードバックを得て柔軟に振る舞いを適用させていく必要がある。ユーザーの状況に合わせた細かな修正や、精度を向上した新機能をオンラインで投入でき、ユーザーからフィードバックを得て更に改善していくようなデプロイと改善のプロセスが対話システム運用では重要となる。リアクティブ対話システムは前述の対話システム運用における課題を解決するために、対話システムを構成する各機能を関数として部品化して、柔軟な機能変更を容易にする。

3.アーキテクチャ

ユーザーからフィードバックを得て柔軟にサービスを改善していくサイクルは、昨今のSNS やソーシャルゲームなどに代表されるWeb サービスの業界で広く認知され、それを可能にするためのシステムアーキテクチャが提案・運用されている。 Web サービスに利用されている柔軟な変更を可能にする概念・技術のうち、リアクティブ対話システムの構成において重要なものをいくつか紹介する。

3.1 マイクロサービス

2014 年に ThoughtWorks 社の James Lewis らが提唱したマイクロサービス[1]は、複数の機能から構成される 1 つの大きな(モノシリックな)アプリケーションを機能毎に開発・運用が行えるように分割することで、迅速な機能のアップデートや、システムのスケーラビリティ・耐障害性を向上させることができると主張している。マイクロサービスの目的は大規模なWeb サービスを安定して運用・改善するための開発組織の構造をシステムアーキテクチャで表現することにある。これは対話システム開発においてもマイクロサービスのアイディアを取り入れることで、新機能を迅速に対話システムに反映させて検証サイクルの速度を上げられるという大きな利点がある。

3.2 Your Server as a Function

2014 年に Marius Eriksen は 1 つ 1 つのサーバーの入出力に対して型を定義することで、サーバー(もしくは機能)を関数として扱うための手法を提唱し、このアイディアを実装したライブラリ Finagle を公開した。[2] Marius Eriksen の主張はマイクロサービスを意識されたものではないが、思想や設計に両者で共通したものがあるためマイクロサービスを実装するためのライブラリとしてFinagle が利用されている。[3]

3.3 リアクティブシステム

2014 年に Jonas Bonér らは自身の経験則に基づいた、システムの可用性・スケーラビリティを高めるための汎用的なシステムアーキテクチャを提唱した。 [4] 上記では主に大規模システムにおける設計のガイドラインを示しているが、ユーザーに対しての応答を主眼に置きシステムの状況に応じて柔軟に振る舞いを変更するという点が、対話システムにおいても有用と考えられる。例えば、モバイル端末に搭載されたパーソナルアシスタントでは、端末の電波・電源状況、保持するデータ、連携する外部サービスの状況など、リアルタイムに状況が変化することが考えられる。それぞれの場合にユーザーにとって適切な応答・アクションを行うためにはいくつかの固定された振る舞いではなく、柔軟にシステムの振る舞いが変更されることが要求される。システムに含まれる各機能がメッセージに応じてリアクティブに動作するようなアーキテクチャはこのような要求を満たすために有用である。

4.リアクティブ対話システム

本提案での、柔軟に振る舞いを変化させるリアクティブ対話システムの構成について技術的な詳細を述べる。リアクティブ対話システムは Function, Selector, Coordinator によって構成されている。図2.システムアーキテクチャ

4.1 Function

対話システムでは主に、言語理解、対話状態の管－ 36 －

(3)

理、対話知識検索、外部システムとの連携、行動選択、応答生成など複数の機能によって構成されている。[5] リアクティブ対話システムではこれらの各機能を WebAPI として独立に実装し、独立した機能として動作させる。この際の 1 つ 1 つの独立した機能を Function と呼ぶ。

4.2 Selector

複数のFunction を組み合わせて動作させる際の呼び出し順序(call graph)を定義する機能を Selector と呼ぶ。

4.3 Coordinator

Selector によって定義された call graph を参照し、その順序に沿って書く Function を呼び出す機能を Coordinator と呼ぶ。

各Function の出力を次の Function への入力として渡すため、Unix/Linux コマンドをパイプで連結させるようにCoordinator は動作する。Selector は call graph を更新すると、Cordinator はリアルタイムに Function の呼び出し順を変更し、対話システム全体の振る舞いが変更されることとなる。前述の対話システム運用の課題に対する適用例としては、例えばある Function A の機能を更新した Function A’を実装したとする。これを稼働中の対話システムにデプロイする場合には、Selector を通して call graph 内の Function A を Function A’に変更することで対話システムの動作を即時に切り替えることができる。また、call graph 内の任意の位置に新たな Function を差し込むことも可能となるため、既存の機能と新機能を並行稼働したり、既存の振る舞いに影響を与えずに内部の機能を追加するような変更も可能となる。上記のような新機能のデプロイの簡易化の他にも、ユーザー毎にcall graph を変化させたり、対話のドメインが変化する毎に call graph を変化させるように利用することができる。これにより対話システムの開発者は、ミクロでは Function の開発に集中し、マクロな視点では利用ユーザーに主眼を置いた対話システムの振る舞いに集中することができるようになる。

5.課題

本提案では対話システムの振る舞いを柔軟に変化させるためのソフトウェアアーキテクチャに対して述べた。一方で、あるユーザー要求に対して対話システムがどのように振る舞うべきか、という点については言及していない。ユーザーの要求を満たすためにどのようなFunction を提供すべきか、どのような call graph が適切か、という Selector の処理がリアクティブ対話システムを利用する際の課題として想定される。単純にFunction のバリエーションを増やしていった場合、Function の種類が増えるほどに幅広い要求に応えられる対話システムの実現が可能となる。また、Function は必ずしもクローズドな環境で提供される必要はないため、一般の開発者が自由に開発・公開できるような発展も考えられる。しかし、Function の種類が非常に多く存在した場合、適切なcall graph を人間が設定することは簡単なタスクではない。リアクティブ対話システムの柔軟な変更の性質を考慮すると、人間が事前に設定した” 固定された” 機能の組み合わせではその利点を十分に活かすことはできないと考えている。

Selector が自動化され 1 アクセス毎に call graph が変更されるような動作をしてよりリアクティブ対話システムらしさが発揮される。また、Function は必ずしもクローズドな環境で提供される必要はなく、一般の開発者が自由に開発・公開できるようにすることも可能となる。図3. リアクティブ対話システムの発展－ 37 －

(4)

6.参考文献

[１] James Lewis , Martin Fowler: Microservices, https://martinfowler.com/articles/microservices.html (2014)

[２] Marius Eriksen: Your server as a function (2013) [３] Phil Calçado: Microservices in Scala and Finagle ,

https://developers.soundcloud.com/blog/building-product s-at-soundcloud-part-3-microservices-in-scala-and-finagle (2014)

[４] Jonas Bonér, Dave Farley, Roland Kuhn, and Martin Thompson.: The Reactive Manifesto,

http://www.reactivemanifesto.org/ (2014)

[５] 中野幹生, 駒谷和範, 船越孝太郎, 中野有紀子,

奥村学: 対話システム (自然言語処理シリーズ)

(2015)