音声・言語系プラットフォームのビルトインなスロット/エンティティタイプを比較してみた

対話モデルを作成する場合、インテントにせよ、スロット/エンティティにせよ、自前で値を用意するのはけっこう大変です。可能な限り、プラットフォーム側で予め定義されたものがあるほうが便利ですよね。

ということで、各音声・言語系サービスのビルトインなスロットやエンティティタイプについて、日本語でサポートされている状況をリストアップ・比較表にしてみました。

・日本語のみです。
・筆者はAmazon Alexaをメインで触っており、それ以外の他社については詳細なところまで把握できていません。
・ざっとドキュメントを見ながら比較しています。詳細は必ず各社のリファレンスを参照してください。
・あくまでも個人の所感です。不備等あればご指摘いただけると助かります。

目次

対象

Amazon Alexa

Amazon Lex

Google Dialogflow CX

Google Dialogflow ES

Google Actions Builder

Microsoft LUIS

比較リスト

まとめたリストはこちら docs.google.com

ざっくり見た感じのあくまでも「個人的」な印象。

Alexa

• 数だけでいうと、Alexaが一番多いです。
• 使用頻度が高い「数」「日付・時間」「名前」といった基本的なスロットタイプは抑えつつ、一般のコンシュマー向けが想定されているためか、特定の分野に特化したリストタイプのスロットが多いのが特徴です。例えば音楽/映画/本などのエンタメ系。このあたりはAmazonのショッピングなどとも強く関連しそうですね。
• Alexaのビルトインスロットタイプの多さは地味に助かるんですよね、拡張もできるし。

Amazon Lex

• 「数」「日付・時間」「名前」といった基本的なスロットタイプはまあ抑えてある。けどAlexaよりは少なめな印象。
• Lexは英語ロケールだとAlexaのスロットタイプがそのまま使えるみたいなんだけど、日本語はこれに対応してないんですね・・・ベースの技術は同じだと思ってるし、英語ではできているわけなので、ここはちょっともったいない。
• Alexaでは音声が全面にあると思っているけど、Lexの場合は音声だけではないので、URLとかメールアドレスのような「音声で認識が難しい」ものもサポートされている。AlphaNumericとかAlexaにも欲しい！
• 真面目にきちんと見たことなかったのだけど、ここまで少ないとは思わなかった。SearchQuery使えないかー、とは正直思ってしまった。

Google Dialogflow CX/ES

• 基本的なところはそつなく抑えてあって、あんまり困ることはなさそうって感じ。ESもCXもそれほど違わない印象です。
• 自由な発話も@sys.anyとかでいけるし、URLやメアドのような「音声で認識が難しい」ものもサポートされているので、スマホやブラウザでのチャットボット利用なんかもしやすそう。
• Alexaのようないろいろなリストタイプのものは少ないけど、そもそも実際に必要になるケースはそれほどなかったりもすると思うし、必要になってから作ればいいと思うし。

Google Actions Builder

• 元々Dialogflowだったものから、こちらに移行されてきて、正直足りなさすぎて辛い・・・これは日本語なので、ということではなく、全ロケールでこんな感じ。
• なので、こういうオープンソースで増やしていこうぜ、みたいな取り組みがあったりする。
  • Solving missing System Entities in Actions Builder: Community Types! - Denis Valášek - Blog
  • GitHub - DenisVCode/aog-community-types: Collection of community types for Actions Builder
  • が、そもそもこのへんを用意して開発者が開発しやすいように務めるのはプラットフォームの責務なんじゃないのか、という気もしてる。
• この辺も意識せずにすべて機械学習でなんとかするぜ！みたいな考え方なのかなぁ・・・と思ったりもするけど、現時点では正直つらいと感じている。

Microsoft LUIS

• こちらもかなり少なくて辛い。
• 英語/中国語だと基本的なところはある程度サポートはされている様子（とはいいつつも他に比べると弱い印象は否めない）なので、これはもうホント日本語のサポートが弱すぎる。
• やはり日本市場の優先度が低いってことなのかなー・・・

まとめ

各社いろいろ違いがありますね。実際に使う場合は、要件や各プラットフォームへの習熟度などに応じて選択することになりますが、やはり英語に比べると、日本語のサポートはどうしても見劣りしちゃいます。このあたりは各プラットフォームに頑張ってほしいし、開発者としてももっとプッシュしていく必要があるかなと思います。

AlexaやGoogle Actions Builderなどのプラットフォームに限定されているものはそれに従うことになるかと思いますが、Dialogflow ES/CXならば基本的なところはきちんと抑えてありつつ、最も汎用的に使えそう、という印象を持ちました。

Dialogflow最近あまり触っていなかったので、少しいろいろ触ってみようかなと思っています。

気が向いたらビルトインインテントも調べよっかな。

Voiceflowではじめる音声アプリ/チャットボット開発〜2022年版〜

2年ほど前に以下のイベントで登壇させていただき、Voiceflowについてご紹介しました。

あれから時間も経ってだいぶ状況も変わっているので、2022年現時点での内容に更新しました。

Googleスライドで公開しています。一部GIFアニ使ってるので動作イメージが多少分かる部分もあります。

PDFでサラッと見たい場合はこちら。GIFアニは動かないです。 speakerdeck.com

一部画面イメージなどの更新が追いついていない箇所もありますが、

• プロトタイプの新機能
• カスタムアシスタント/Dialog Management API

等、新しい機能についての説明を追加しています。

よろしければご覧ください。

Autocodeでセッションを実装してカウンターを作ってみた

Autocodeでセッションを実装してカウンターを作ってみました。

// authenticates you with the API standard library
// type `await lib.` to display API autocomplete
const lib = require('lib')({token: process.env.STDLIB_SECRET_TOKEN});
const cookie = require('cookie');
const { randomUUID } = require('crypto');

const appName = "session_sample";

function gen_sess_id(){
  return randomUUID().split('-').join("");
}

let sess_id;
if (context.http.headers.hasOwnProperty('cookie')){
  let cookies = cookie.parse(context.http.headers.cookie);
  sess_id = cookies.ACSESSID;
} else {
  sess_id = gen_sess_id();
}

let counter = 0;

let sess_data = await lib.utils.kv['@0.1.16'].get({
  key: `${appName}_${sess_id}`
});

if(sess_data){
  counter = sess_data.counter;
}

counter++;

await lib.utils.kv['@0.1.16'].set({
  key: `${appName}_${sess_id}`,
  value: {
    counter: counter
  },
  ttl: 60
});

const body = {
  "sess_id": sess_id,
  "counter": counter
};

return {
  headers: {
    'Content-Type': 'application/json',
    'Set-Cookie': cookie.serialize('ACSESSID', sess_id)
  },
  statusCode: 200,
  body: Buffer.from(JSON.stringify(body))
};

Autocodeのkey-value storeのドキュメントによると、

Because storage is tied to your user account rather than to a specific token or app, you should be wary of conflicts around two different apps relying on the same key for storage. For more examples, check out the API documentation page.

らしいので、キーは、アプリ名とセッションIDを組み合わせています。あと、

You can store a maximum of 1024 key-value pairs at a time. Keys may be up to 1kb in size, and values may be up to 18kb.

あたりもあるので、AirtableなりPostgreSQLなりを使うほうが良さそうな気がします。