docomoの発話理解APIからLUISの扱い方を学ぶ
はじめに
この記事は「Microsoft Cognitive Services & Bot Framework - Qiita」の8日目になります。
概要
LUIS(Language Understanding Intelligent Service)は非常に優秀な自然言語解析ツールですが、日本語ではサンプルモデルが存在せず、どのようなIntentとそのパラメータ、および、Entityを扱えばよいか困っている人もいることでしょう。
そこで本記事、『docomo Developer support | NTTドコモ』で提供している発話理解APIを元に学んでいきます。
LUISの基本知識はある程度省略しますので、
本記事を読み進める前に以下の記事を読んでいただけると理解が深まります。
docomoの発話理解API
発話理解APIは発話文をテキストでインプットすると、文脈を解析し、その意図に沿った『コマンド名』及び『スロット名』に該当する値を返却するAPIです。
LUISですと『コマンド』がIntent、『スロット』がパラメータにあたります。
発話理解APIで取得できるコマンド
発話理解APIのリファレンスで紹介しているコマンド一覧は以下になります。
commandID | commandName | 説明 | スロット名 |
---|---|---|---|
BC00101 | 雑談 | あいさつなど雑談 | |
BK00101 | 知識検索 | Q&Aの検索 | |
BT00101 | 乗換案内 | 乗り換え案内を検索 | stationTo, stationFrom |
BT00201 | 地図 | 地図の表示 | searchArea, hereArround, facilityName |
BT00301 | 天気 | 天気の検索 | searchArea, hereArround, date |
BT00401 | グルメ検索 | 飲食店の検索 | gourmetGenre, searchArea, hereArround |
BT00501 | ブラウザ | ブラウザアプリの起動 | browser, website |
BT00601 | 観光案内 | 観光地の検索 | searchArea, hereArround, sightseeing |
BT00701 | カメラ | カメラアプリの起動 | |
BT00801 | ギャラリー | ギャラリーアプリの起動 | |
BT00901 | 通話 | 電話アプリの起動 | phoneTo |
BT01001 | メール | メールアプリの起動 | mailTo, mailBody |
BT01101 | メモ登録 | メモの生成 | memoBody |
BT01102 | メモ参照 | メモの参照 | memoBody |
BT01201 | アラーム | アラーム設定 | time |
BT01301 | スケジュール登録 | スケジュールの登録 | date, time, scheduleBody |
BT01302 | スケジュール参照 | スケジュールの参照 | date, time |
BT01501 | 端末設定 | 端末設定の起動 | setting |
BT01601 | SNS投稿 | SNSへの投稿 | snsSource, snsBody |
BT90101 | キャンセル | キャンセルコマンド | |
BM00101 | 地図・乗換 | 地図・乗換いずれかのタスク | searchArea |
BM00201 | 通話・メール | 通話・メールいずれかのタスク | phoneTo |
SE00101 | 判定不能 | 判定不能 | |
SE00201 | サーバエラー1 | サーバエラー | |
SE00202 | サーバエラー2 | サーバエラー | |
SE00301 | ライブラリエラー | ライブラリエラー |
余談ですが上記の表はdocomoの公式のHTMLからExcelにコピーし、以下のアドインを使ってExcelからMarkdown形式に変換しています。便利です。
発話理解APIで取得できるスロット
スロット一覧は以下になります。
スロット名 | 説明 | タイプ |
---|---|---|
browser | ブラウザ名を格納 | browser |
date | 日付,曜日,相対日付を格納 | date, datePnoun, dateWeek, dateRelative |
facilityName | 検索対象の施設名を格納 | gpoi |
gourmetGenre | グルメ検索ジャンルを格納 | food, drink |
hereArround | 現在地周辺を表す言葉を格納 | hereArround |
mailBody | メール件名を格納 | mailBody |
mailTo | メール宛先を格納 | fullName, lastFirstName, firstName, lastName, postName, otherAddress, upoi, gpoi |
memoBody | メモの本文を格納 | memoBody |
phoneTo | 電話宛先を格納 | phoneNumber, fullName, lastFirstName, firstName, lastName, postName, otherAddress, upoi, gpoi |
scheduleBody | スケジュール内容を格納 | scheduleBody |
searchArea | 検索対象の地名を格納 | address, upoi |
setting | 設定項目を格納 | setting |
sightseeing | 観光関連用語を格納 | sightseeing |
stationFrom | 乗車駅を格納 | stationFrom, hereFrom, station, here |
stationTo | 降車駅を格納 | stationTo, hereTo, station, here |
snsBody | SNSの本文を格納 | snsBody |
snsSource | SNSの投稿先を格納 | snsSource |
time | 時刻,または相対時間を格納 | time, timeRelative, timeHour |
website | Webのサイト名を格納 | website |
余談ですが上記の表は(ry
発話理解APIの実行例
docomo Developer support ではAPIを実行するコンソールが提供されています。
ユーザ登録をすると利用できます。
実行例を示します。
「品川で焼肉を食べたい」の結果
「品川で焼肉を食べたい」で実行した結果の一部が以下になります。
この場合、コマンド名として「グルメ検索」、ジャンルとして「焼肉」、対象エリアとして「品川」が抽出できました。
ちなみに「現在地周辺の焼肉屋は?」としたときはhereArroundに「現在地」が格納されました。
LUISへの応用
グルメ検索をLUISで同じようなことを実現しようとした場合、あらかじめ「groumetGenre」、「searchArea」、「hereArround」をパラメータとした、「searchGroumet」というIntentを作成することとなります。
Entityの作成
ここでEntityを作成する際は一工夫必要です。
「groumetGenre」はおそらくグルメのジャンルで他と被ることもなさそうです。なので、「groumetGenre」というEntityを作成してよいでしょう。
「searchArea」は検索目的でなくてもエリアという概念はあるので、「Area」というEntityを作成したうえで「searchArea」というchildrenを作るとよいでしょう。
こうすることで検索目的ではないAreaのchildren作成時にも学習効果が期待できます。
「hereArround」は現在地周辺ということなので、hereだとかhereArroundのままでよいと思います。
Intentの作成
先ほど作成したEntityを元に「searchGroumet」というIntentを作成します。
学習
作成したIntentを学習させます。
学習を繰り返して、このIntentの精度を高めます。
まとめ
いかがでしたでしょうか。
今回はAdventCalendarの空きが出ないために急いで作ったためグルメ検索のみの紹介でした。
docomoの発話理解APIには、よくあるポータル検索ではなくスマートフォンの機能を使用するためのコマンドをそろえているのが特徴的です。
もし、LUISを使ってスマートフォンのコンシェルジュ的なアプリを作成するときは、この発話理解APIのスマートフォン向けコマンドが参考になるかもしれません。
docomoの発話理解APIは無料で使えますが、自分が好きなように学習させる機能はありません。
発話理解のノウハウをdocomoから学んで自分好みの学習をLUISで実現してみてはいかがでしょうか。
ちなみにdocomo Developer SupportではAPIを活用したサービスを考案された方には事業化支援金の提供も含めた支援プログラムがあります。
docomoのAPIとMicrosoft Bot Frameworkを組み合わせたサービスでも支援してもらえるかもしれませんね。
以上です。
LUISとAzure Bot Serviceを利用してMicrosoft Teamsで在庫管理ボットを動作させる
はじめに
この記事は「Microsoft Cognitive Services & Bot Framework - Qiita」の6日目になります。
概要
自身の前記事のいい加減さに反省して、もう一件記事を書きます。
LUISとAzure Bot Serviceを利用してMicrosoft Teamsで在庫管理ボットを動作させる例を紹介します。
LUISの構築やAzure Bot Serviceの構築はある程度省略しますので、
本記事を読み進める前に以下の記事を読んでいただけると理解が深まります。
LUISの設定
Phrase Listの設定
在庫管理対象となるものをPhrase Listに登録します。
今回はProductという名前で以下のように登録しました。
Entityの設定
製品のEntityとしてProductを登録します。
実際にはもっと子要素を増やすべきですがサンプルなので割愛します。
Intentの登録
製品の在庫数を取得するためのIntentをGetZaikoとして作成しました。
Actionパラメータには先ほど作成したPhraseやEntityのProductを指定し、NameもProductとしています。
(※違う名前にしたほうがわかりやすかったです。)
LUISを学習させる。
GetZaikoとなる文章パターンを覚えさせます。
何パターンかSubmitし、Trainで学習させ、Publishします。
「レモンの残りは?」のQueryの結果は以下のようになりました。
Azure Bot Serviceの実装
LUIS向けのAzure Bot Serviceの初期構築が完了している想定で進めます。
LUIS向けで構築する際に作成されるBasicLuisDialog.csxの末尾に以下のメソッドを登録します。
記事の可視性のためにメソッド内に処理をすべてまとめています。
実際はDBやWebAPI等からデータを取得することとなります。
今回、Entityが一つである前提のため、result.Entities[0].Entity という取得方法を実施していますが、通常はtypeやscoreの値をみて判断すべきだと思います。
Azure Bot Serviceのチャットウィンドウで動作を確認します。
期待通り動作しました。
Microsoft Teamsへの登録
https://dev.botframework.com/ にアクセスしてログインします。
Azure Bot Serviceでは作成した時点でMyBotsに登録されているところが便利だと思います。
Add another channel から Microsoft Teamsの行のAddを選択します。
Microsoft Teamsとの連携を有効にし、「I'm done configuring Microsoft Teams」のボタンをクリックします。
ChannelsにMicrosoft Teamsが加わりました。
Test linkの「Add to Teams」をクリックするとTeamsのアプリケーションが起動し、chatbotとのチャット画面が開きます。
以上でTeamsとの連携まで完了しました。
まとめ
在庫管理っぽいことをするボットを作成してみました。
例えば製品販売店であれば、実際の在庫管理システムとリンクさせたボットを公開し、顧客の購買部のメンバーが参加するTeamsに登録いただくなんてことも考えられます。
ボットを活用して問い合わせに対する時間が削減できるとよいですよね。
余談
なぜ、今回の記事の連携先にMicrosoft Teamsを選んだかというと、個人でOffice365 Business Premiumを契約しているけど、契約人数が一人のため、Teamsのチャットがつまらなかったからです。
もうこれで1人じゃないよ! このボットは自分自身への最高の誕生日プレゼントです。
Microsoft Bot Framework と docomo Developer Support 雑談対話APIの連携
はじめに
この記事は「Microsoft Cognitive Services & Bot Framework - Qiita」の5日目になります。
概要
Bot Frameworkと連携できるのはCognitive Serviceのみではありません。
本記事ではdocomo Developer Supportで提供されるAPIを使用して、Botアプリケーションを作成することで、チャットボットの可能性を広げて行きたいと考えています。
と大層なことを言っている割に雑談対話APIとの連携のみとなってしまいました。
docomo Developer Supportとは
docomo Developer supportをご存知でしょうか
サイトには以下のように紹介されています。
docomo Developer supportは、ドコモやパートナー企業が持つ様々なアセットを「API」として汎用化して提供し、開発者へ展開することで、新たな事業の創出を推進する協創プラットフォームです。ドコモは、中期目標に向けた取り組みとして、世の中の様々なパートナーの皆さまとのコラボレーションにより新たな付加価値を創造する「協創」を進めていきます。
どのようなAPIがあるか
| docomo Developer support | NTTドコモ
対話AI向けとして以下を提供しています。
雑談対話APIとの連携
パラメータは以下のページで紹介しています。
発言したいテキストのみをパラメータに渡しても問題ありませんが、botに話しかけるユーザの属性を付与することで、雑談の内容が変わるようです。
リクエスト
Bot Frameworkを利用したアプリケーションから以下の形式でリクエストを投げるようにしました。
- リクエストURL
- メソッド : POST
- 文字コード : UTF-8
- リクエストヘッダ:Content-Type:application/json
- リクエストクエリパラメータ
- APIKEY(ユーザ登録後発行されるキーです)
- リクエストボディ(JSON形式)
{
"utt": "こんばんは",
"context": "100001",
"nickname": "なかしょ",
"nickname_y": "ナカショ",
"sex": "男",
"bloodtype": "A",
"birthdateY": "1978",
"birthdateM": "12",
"birthdateD": "6",
"age": "37",
"constellations": "射手座",
"place": "東京",
"mode": "dialog",
"t": "20"
}
utt(発言内容)はBotFrameworkを利用したactivity.Textから取得したものを当てはめています。
contextはレスポンスから取得した値を次の発言時に含めることで意味のある会話を継続できるようです。特にしりとり機能を使用時では必要となります。
今回はuttとcontext以外は固定値を使用しています。
modeは何も選択しなければ「dialog」が適用されて通常の会話になります。「srtr」を指定するとしりとりのモードになります。
tはキャラクタ選択で今回は「20:関西弁キャラ」を選択しています。
レスポンス
以下のようにレスポンスを受け取りました。
{
"utt":"こんありやけど",
"yomi":"こんありやけど",
"mode":"dialog",
"da":"0",
"context":"100001",
}
uttの値を返信テキストとして、ReplyToActivityAsyncに渡してBotから返信させるようにしています。
連携例
エミュレータのキャプチャを以下に示します。
簡単ですが以上です。
Microsoft Cognitive Servicesでは雑談対話の仕組みはなく、LUISで雑談できるまで学習させるのも大変です。
例えばLUISでintentのscoreが低いものばかりの時は的外れな回答をしてしまう可能性が高いです。そういう場合は条件に該当しないと判断して、この雑談対話APIで返信内容をゲットするのもありかなぁと思っています。
正直雑談対話が成り立っていない時も多々見受けられますが...
.NETラボでConnect();2016についてLTしてきました。
11月26日の.NETラボ勉強会で以下の資料をLTしてきました。
5分間のLTで、ガンガン進めていったので、トピック的には以下のような感じ。
前半
- MicrosoftがLinux Foundationに加わり、Googleが.NET Foundationに加わり、どんどんオープンになっていくMSに期待できますね。
- Azure Functionsはサーバレスアーキテクチャとして期待しています。
- Visual Studio for MacはWindows版に慣れている人は同じ操作感でコーディングできるので助かります。
- Visual Studio Mobile CenterはHockyAppやXamarinTestCloudなどモバイル開発に必要なものが統合されて使いやすくなりますね。
- Xamarin for VisualStudioで紹介されたものはEnterpriseエディションのみなのでComunity版で使用できなくて残念です。
後半
- このマークは何か知っていますよね?
- Congratulations Samsung!
- Tizen.netのPreview版がリリースされました。
- 発表前まではフロントエンドはWebアプリケーションかNativeアプリケーションしかありませんでした。
- 今はXamarin.Formsで開発が可能になりました。
- Xamarin.Formsは99%対応しているとはいえ、WebViewがないのでハイブリッドアプリは作れません。ListViewはあるけど使えない機能が多いです。
- Tizen固有のAPIはUI周りが未対応でXamarin.Forms頼り。そのため、Xamarin.Formsで表現できないことをNativeに頼れません。
- これからブログ等で継続的にTizenネタを発信しますのでご期待ください。
以上。
Tizen.NETにおけるXamarin.Formsの制限事項
Xamarin.Tizenチョットデキルのなかしょです。
前回の記事ではプラットフォーム固有APIの制限事項について説明しました。
今回はTizen.NETにおけるXamarin.Formsの制限事項について説明します。
Tizen.NETではXamarin.Formsへの対応状況を以下のように説明しています。
『Tizen .NET supports 99% of Xamarin.Forms.』
99%か、Preview版にしてはなかなかのものです。(と実際の制限事項を見るまでは思っていました...)
では、具体的にどのような機能が制限されているかは以下のページで説明しています。
Ignored, No Action, Never triggered など、様々な制限が記載されています。
中でもListViewの制限が多い印象です。
特にGroupDisplayBindingでListViewをグループ化して表示できないとか、IsPullToRefreshEnabledで引っ張って画面更新などのスマフォっぽい動作ができないとか、色々とつらそうです。
デザインを調整するための要素が使えず、プラットフォーム固有のAPIにはUI系が存在せず、Custom Rendrerを実装できないとなると、デザインを重視したTizenアプリにはまだまだXamarin.Formsは使えないのではと懸念しています。
今日はここまで。
2016/11/24 追記
前述の制限は対応しているクラスに対してのものです。クラスそのものが非対応なものは以下になります。
- AppLinkEntry
- PinchGestureRecognizer
- PanGestureRecognizer
- OpenGLView
- WebView
- OnPlatform
- PlatformEffect<TContainer, TControl>
WebViewがないとか、ちょっとしたWebサイトをアプリ内で表示したいときに困りますね。
Tizen .NETのプラットフォーム固有APIの制限事項
Xamarin.Tizenチョットデキルのなかしょです。
以前も紹介しましたが、Tizen .NET Architectureは以下のようになっています。
これだけ見ると、「Platform specific API」使えば、Xamarin.Forms使わずにTizen用アプリ作れるんじゃね、という印象があります。
でも、Tizen.NETでは「The C# APIs provide support for 60% of Tizen Mobile APIs.」と説明があり、Nativeで使用できる60%しか.NETのAPIを用意していないようです。では、対応しているものは何かというと以下が列挙されています。
- Tizen.Applications
- Provides the Tizen application framework, including, for example, application state change events, inter-application messaging, and notification services.
- Tizen.Content
- Provides content management services, such as file and media downloads, storing and indexing audio and video content, and associating content types with helper applications.
- Tizen.Location
- Manages geographical location services and geofencing.
- Tizen.Multimedia
- Interacts with media services, including audio playback, recording, and device policy.
- Tizen.Network
- Provides APIs to control connectivity devices, as well as providing various network information.
- Tizen.Security
- Provides access to secure storage for passwords, keys, certificates, and other sensitive data.
- Tizen.System
- Provides device-specific services, including status, system information and settings, feedback, and sensor control and access.
以上です。Nativeには他にどのようなAPIがあるというと前述のアーキテクチャ図から以下だと見て取れます。
- Base
- Messaging
- Social
- Telephony
- UI
- Web
なんということでしょう。
UIがTizen.NETにはないです。
ということはXamarin.FormsでTizenの画面が乱れたときに、Custom Rendrerなどで解決したくてもできません。
Xamarin.Forms標準のUIでできることしかUIが表現できないようです。
闇が深そうだと分かったところで今日はここまで。
TizenでXamarinForms(XAML)を実行してみた。
Xamarin.Tizenチョットデキルのなかしょです。
前回は「Visual Studio Tools for Tizen」で用意されたテンプレートからサンプルを起動してみました。
そのテンプレートではXAMLが利用されていなかったので、今回はXAMLを使ったプログラムを動かしてみましょう。
でも、ただXAMLで動かすよりかはクロスプラットフォームで動作することがわかるプログラムを動かしたいですよね。
そこで、今回はJXUG主催者の田淵さんが公開されているテンプレートから作成したXamarinForms(XAML)のプロジェクトにTizenの環境を加えることを試してみました。
ここからテンプレートを取得します。
テンプレートの適用方法も同ページに記述されているので参考にしてください。
github.com
テンプレート適用後、新規プロジェクトで「Xamarin.Forms App(JXUG)」を選択し、ソリューションを作成します。
ここでは「XFApp3」としています。
ここで、「ファイル→追加→既存のプロジェクト」で、前回の記事で作成したプログラムのPortableでないTizen側のプロジェクトを選択します。
この時はXamarinApplicationTizenというソリューションを作成し、PortableがXamarinApplicationTizen、Tizen側がXamarinApplicationTizen.Tizenというプロジェクトでした。
取り込むと以下のように表示されます。Nugetパッケージの復元も忘れずに。
「参照」を開くと元のソリューションで参照していた「XamarinApplicationTizen」が見つからないので右クリックして削除します。
そこで、「参照→参照の追加」で「XFApp3」をチェックしOKを選択します。
そして、「XamarinApplicationTizen.Tizen.cs」を開き、namespaceを「XamarinApplicationTizen.Tizen」から「XFApp3.Tizen」に変更します。
この変更により、ポータブルであるXFApp3のAppクラスを参照するようになります。
あとは「XamarinApplicationTizen.Tizen」をスタートアッププロジェクトに設定し、「Launch Tizen Emulator」でエミュレータ起動、「Emulator (tizen-3.0_mobile_x86_64_hd)」でプログラムを起動します。
いかがでしたでしょうか。
これで、今回利用したテンプレートで対応しているAndroid、iOS、UWP、Windows8.1、Windows Phone8.1に加え、Tizenにも対応するソリューションができました。
クロスプラットフォーム開発の幅が広がりますね。