(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-08-01
(45)【発行日】2024-08-09
(54)【発明の名称】情報処理方法、プログラム及び情報処理装置
(51)【国際特許分類】
G06Q 50/10 20120101AFI20240802BHJP
G06Q 30/0601 20230101ALI20240802BHJP
【FI】
G06Q50/10
G06Q30/0601 330
(21)【出願番号】P 2020111967
(22)【出願日】2020-06-29
【審査請求日】2023-05-29
(73)【特許権者】
【識別番号】000253503
【氏名又は名称】キリンホールディングス株式会社
(74)【代理人】
【識別番号】100114557
【氏名又は名称】河野 英仁
(74)【代理人】
【識別番号】100078868
【氏名又は名称】河野 登夫
(72)【発明者】
【氏名】岡田 理志
(72)【発明者】
【氏名】太田 惣介
(72)【発明者】
【氏名】川橋 綾乃
(72)【発明者】
【氏名】黒川 雄司
(72)【発明者】
【氏名】森木 博之
【審査官】松野 広一
(56)【参考文献】
【文献】特開2019-101667(JP,A)
【文献】特開2020-080156(JP,A)
【文献】特開2018-060431(JP,A)
【文献】特開2019-101578(JP,A)
【文献】特開2019-040267(JP,A)
【文献】特開2019-061525(JP,A)
【文献】特開2020-024504(JP,A)
【文献】特開2019-102068(JP,A)
【文献】特開2020-061053(JP,A)
【文献】特開2019-139663(JP,A)
【文献】中国特許出願公開第101872433(CN,A)
【文献】中国特許出願公開第101872387(CN,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00-99/00
(57)【特許請求の範囲】
【請求項1】
顧客の複数の属性を取得し、
複数の質問に対する回答を取得し、
複数の前記属性及び回答を入力した場合に、提案すべきビール、発泡酒、新ジャンルビールまたはビールテイスト飲料を含むビール飲料に関するビール情報を出力するよう学習済みの第1モデルに、取得した複数の前記属性及び回答を入力して前記ビール情報を出力
し、
前記ビール情報に基づき提案すべき前記ビール飲料を第1領域に表示し、前記ビール飲料を案内するキャラクタを前記第1領域とは異なる第2領域に表示する画面を出力し、
前記第1モデルから出力された前記ビール情報の確からしさを示す確信度を取得し、
前記確信度に応じて前記キャラクタの表示態様を変更する
処理をコンピュータが実行する情報処理方法。
【請求項2】
前記確信度に応じて前記キャラクタの表情を変更する
請求項
1に記載の情報処理方法。
【請求項3】
前記確信度に応じて前記キャラクタのコメントを変更する
請求項
1又は
2に記載の情報処理方法。
【請求項4】
提案すべき前記ビール飲料のビアスタイル、アルコール量、カロリー、製造元、又は製造地域に関する情報を前記第2領域に表示する前記画面を出力する
請求項
1~3のいずれか1項に記載の情報処理方法。
【請求項5】
前記ビール飲料の提供開始日を記憶する記憶部を参照して、提案すべき前記ビール飲料の前記提供開始日が所定期間以内であるか否かに応じて、前記キャラクタの表示態様を変更する
請求項
1~4のいずれか1項に記載の情報処理方法。
【請求項6】
前記ビール情報を入力した場合に、前記ビール飲料の集合である複数のクラスタのいずれかに分類するよう教師なし学習で学習済みの第2モデルに、前記第1モデルから出力された前記ビール情報を入力して前記複数のクラスタのいずれかに分類し、
分類された前記クラスタに属する前記ビール飲料を前記第1領域に表示する前記画面に出力する
請求項
1~5のいずれか1項に記載の情報処理方法。
【請求項7】
過去に前記顧客に提案した前記ビール飲料の履歴を記憶する記憶部を参照して、前記第1モデルから出力された前記ビール情報に対応する前記ビール飲料が提案済みである場合、提案すべき前記ビール飲料を他の前記ビール飲料に変更し、
変更した前記ビール飲料を前記第1領域に表示すると共に、前記ビール飲料の変更の有無に応じて表示態様を変更した前記キャラクタを前記第2領域に表示する前記画面を出力する
請求項
1~6のいずれか1項に記載の情報処理方法。
【請求項8】
前記画面で提案した前記ビール飲料に関する第2の質問への回答を取得し、
取得した前記第2の質問への回答に基づき、前記第1モデルを更新する
請求項
1~7のいずれか1項に記載の情報処理方法。
【請求項9】
前記第2の質問は、提案した前記ビール飲料の評価値を問う質問項目を含み、
前記第1モデルから出力された前記ビール情報に対応する前記ビール飲料について、過去に前記評価値が一定値以下の回答を取得していた場合、提案すべき前記ビール飲料を他の前記ビール飲料に変更し、
変更した前記ビール飲料を前記第1領域に表示すると共に、前記ビール飲料の変更の有無に応じて表示態様を変更した前記キャラクタを前記第2領域に表示する前記画面を出力する
請求項
8に記載の情報処理方法。
【請求項10】
顧客の複数の属性を取得し、
複数の質問に対する回答を取得し、
複数の前記属性及び回答を入力した場合に、提案すべきビール、発泡酒、新ジャンルビールまたはビールテイスト飲料を含むビール飲料に関するビール情報を出力するよう学習済みの第1モデルに、取得した複数の前記属性及び回答を入力して前記ビール情報を出力
し、
前記ビール情報に基づき提案すべき前記ビール飲料を第1領域に表示し、前記ビール飲料を案内するキャラクタを前記第1領域とは異なる第2領域に表示する画面を出力し、
前記第1モデルから出力された前記ビール情報の確からしさを示す確信度を取得し、
前記確信度に応じて前記キャラクタの表示態様を変更する
処理をコンピュータに実行させるプログラム。
【請求項11】
顧客の複数の属性を取得する第1取得部と、
複数の質問に対する回答を取得する第2取得部と、
複数の前記属性及び回答を入力した場合に、提案すべきビール、発泡酒、新ジャンルビールまたはビールテイスト飲料を含むビール飲料に関するビール情報を出力するよう学習済みの第1モデルに、取得した複数の前記属性及び回答を入力して前記ビール情報を出力する
第1出力部と
、
前記ビール情報に基づき提案すべき前記ビール飲料を第1領域に表示し、前記ビール飲料を案内するキャラクタを前記第1領域とは異なる第2領域に表示する画面を出力する第2出力部と、
前記第1モデルから出力された前記ビール情報の確からしさを示す確信度を取得する第3取得部とを備え、
前記第2出力部は、前記確信度に応じて前記キャラクタの表示態様を変更する
情報処理装置。
【請求項12】
顧客の複数の属性を取得し、
複数の質問に対する回答を取得し、
複数の前記属性及び回答を入力した場合に、提案すべきビール、発泡酒、新ジャンルビールまたはビールテイスト飲料を含むビール飲料に関するビール情報を出力するよう学習済みの第1モデルに、取得した複数の前記属性及び回答を入力して前記ビール情報を出力し、
前記ビール情報に基づき提案すべき前記ビール飲料を第1領域に表示し、前記ビール飲料を案内するキャラクタを前記第1領域とは異なる第2領域に表示する画面を出力し、
前記ビール飲料の提供開始日を記憶する記憶部を参照して、提案すべき前記ビール飲料の前記提供開始日が所定期間以内であるか否かに応じて、前記キャラクタの表示態様を変更する
処理をコンピュータが実行する情報処理方法。
【請求項13】
顧客の複数の属性を取得し、
複数の質問に対する回答を取得し、
複数の前記属性及び回答を入力した場合に、提案すべきビール、発泡酒、新ジャンルビールまたはビールテイスト飲料を含むビール飲料に関するビール情報を出力するよう学習済みの第1モデルに、取得した複数の前記属性及び回答を入力して前記ビール情報を出力し、
前記ビール情報に基づき提案すべき前記ビール飲料を第1領域に表示し、前記ビール飲料を案内するキャラクタを前記第1領域とは異なる第2領域に表示する画面を出力し、
過去に前記顧客に提案した前記ビール飲料の履歴を記憶する記憶部を参照して、前記第1モデルから出力された前記ビール情報に対応する前記ビール飲料が提案済みである場合、提案すべき前記ビール飲料を他の前記ビール飲料に変更し、
変更した前記ビール飲料を前記第1領域に表示すると共に、前記ビール飲料の変更の有無に応じて表示態様を変更した前記キャラクタを前記第2領域に表示する前記画面を出力する
処理をコンピュータが実行する情報処理方法。
【請求項14】
顧客の複数の属性を取得し、
複数の質問に対する回答を取得し、
複数の前記属性及び回答を入力した場合に、提案すべきビール、発泡酒、新ジャンルビールまたはビールテイスト飲料を含むビール飲料に関するビール情報を出力するよう学習済みの第1モデルに、取得した複数の前記属性及び回答を入力して前記ビール情報を出力し、
前記ビール情報に基づき提案すべき前記ビール飲料を第1領域に表示し、前記ビール飲料を案内するキャラクタを前記第1領域とは異なる第2領域に表示する画面を出力し、
前記画面で提案した前記ビール飲料に関する第2の質問であって、提案した前記ビール飲料の評価値を問う質問項目を含む第2の質問への回答を取得し、
前記第1モデルから出力された前記ビール情報に対応する前記ビール飲料について、過去に前記評価値が一定値以下の回答を取得していた場合、提案すべき前記ビール飲料を他の前記ビール飲料に変更し、
変更した前記ビール飲料を前記第1領域に表示すると共に、前記ビール飲料の変更の有無に応じて表示態様を変更した前記キャラクタを前記第2領域に表示する前記画面を出力する
処理をコンピュータが実行する情報処理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理方法、プログラム及び情報処理装置に関する。
【背景技術】
【0002】
消費者のニーズに応じて飲料製品を提供する技術がある。例えば特許文献1では、ユーザが入力した言語データから所定のキーワードを抽出し、抽出したキーワードに応じてユーザにレコメンドする日本酒商品を選択し、選択された商品の情報を出力するレコメンド装置等が開示されている。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、特許文献1に係る発明は、人手で作成したルールに従ってキーワードからレコメンド商品を選択するものであり、必ずしもレコメンドの精度が良いものとは言えない。
【0005】
一つの側面では、顧客に適したビール飲料を提案することができる情報処理方法等を提供することを目的とする。
【課題を解決するための手段】
【0006】
一つの側面に係る情報処理方法は、顧客の複数の属性を取得し、複数の質問に対する回答を取得し、複数の前記属性及び回答を入力した場合に、提案すべきビール、発泡酒、新ジャンルビールまたはビールテイスト飲料を含むビール飲料に関するビール情報を出力するよう学習済みの第1モデルに、取得した複数の前記属性及び回答を入力して前記ビール情報を出力し、前記ビール情報に基づき提案すべき前記ビール飲料を第1領域に表示し、前記ビール飲料を案内するキャラクタを前記第1領域とは異なる第2領域に表示する画面を出力し、前記第1モデルから出力された前記ビール情報の確からしさを示す確信度を取得し、前記確信度に応じて前記キャラクタの表示態様を変更する処理をコンピュータが実行する。
【発明の効果】
【0007】
一つの側面では、顧客に適したビール飲料を提案することができる。
【図面の簡単な説明】
【0008】
【
図1】飲料提案システムの構成例を示す説明図である。
【
図4】飲料DB、顧客DB、質問テーブル、及び履歴DBのレコードレイアウトの一例を示す説明図である。
【
図9】第2アンケートの入力画面の一例を示す説明図である。
【
図10】第1モデルの生成処理の手順を示すフローチャートである。
【
図11】飲料提案処理の手順を示すフローチャートである。
【
図12】第1モデルの更新処理の手順を示すフローチャートである。
【
図13】実施の形態2に係るサーバの構成例を示すブロック図である。
【
図15】第2モデルの生成処理の手順を示すフローチャートである。
【
図16】実施の形態2に係る飲料提案処理の手順を示すフローチャートである。
【発明を実施するための形態】
【0009】
以下、本発明をその実施の形態を示す図面に基づいて詳述する。
(実施の形態1)
図1は、飲料提案システムの構成例を示す説明図である。本実施の形態では、顧客が入力したアンケートへの回答等に基づき、顧客の嗜好に適したビール飲料を提案する飲料提案システムについて説明する。飲料提案システムは、情報処理装置1及び端末2、2、2…を含む。各装置は、インターネット等のネットワークNに通信接続されている。
【0010】
情報処理装置1は、種々の情報処理、情報の送受信が可能な情報処理装置であり、例えばサーバコンピュータ、パーソナルコンピュータ等である。本実施の形態では情報処理装置1がサーバコンピュータであるものとし、以下では簡潔のためサーバ1と読み替える。サーバ1は、顧客に提案すべきビール飲料に関するビール情報を推定する推定装置として機能する。具体的には後述の如く、サーバ1は、機械学習により生成された後述の第1モデル51を用いて、顧客の複数の属性、及び複数の質問(アンケート)に対する顧客の回答から、顧客に提案すべきビール飲料の特性値を推定する。サーバ1は、推定した特性値に類似するビール飲料をデータベースから検索し、顧客に提案する。
【0011】
本明細書で云うビール飲料は、ビール以外に、発泡酒、新ジャンルビール(ビール及び発泡酒とは原料又は製法が異なるビール風味の発泡性アルコール飲料)、ビールテイスト飲料(ノンアルコール飲料を含むビール風味の発泡性炭酸飲料)も含む。なお、本システムをビール飲料以外の飲料(ビール飲料以外のアルコール飲料、あるいはアルコール飲料以外の飲料)に応用してもよい。
【0012】
端末2は、各顧客が使用する端末装置であり、例えばスマートフォン、パーソナルコンピュータ、タブレット端末等である。なお、端末2は顧客が所有する端末装置であってもよく、あるいは飲食店や小売店など、ビール飲料の提供施設で顧客に貸与される端末装置であってもよい。サーバ1は、端末2からアンケートの回答等を取得し、提案すべきものと推定したビール飲料の情報を端末2に出力し、表示させる。
【0013】
図2は、サーバ1の構成例を示すブロック図である。サーバ1は、制御部11、主記憶部12、通信部13、及び補助記憶部14を備える。
制御部11は、一又は複数のCPU(Central Processing Unit)、MPU(Micro-Processing Unit)、GPU(Graphics Processing Unit)等の演算処理装置を有し、補助記憶部14に記憶されたプログラムP1を読み出して実行することにより、種々の情報処理、制御処理等を行う。主記憶部12は、SRAM(Static Random Access Memory)、DRAM(Dynamic Random Access Memory)、フラッシュメモリ等の一時記憶領域であり、制御部11が演算処理を実行するために必要なデータを一時的に記憶する。通信部13は、通信に関する処理を行うための通信モジュールであり、外部と情報の送受信を行う。
【0014】
補助記憶部14は、大容量メモリ、ハードディスク等の不揮発性記憶領域であり、制御部11が処理を実行するために必要なプログラムP1、その他のデータを記憶している。また、補助記憶部14は、第1モデル51、飲料DB141、顧客DB142、質問テーブル143、履歴DB144を記憶している。第1モデル51は、所定の訓練データを学習済みの機械学習モデルであり、顧客の複数の属性と、複数の質問に対する回答とを入力として、顧客に提案すべきビール飲料に関するビール情報を出力するモデルである。第1モデル51は、人工知能ソフトウェアの一部として機能するプログラムモジュールとしての利用が想定される。飲料DB141は、各ビール飲料の情報を格納するデータベースである。顧客DB142は、各顧客の情報を格納するデータベースである。質問テーブル143は、後述のアンケートを取る際の質問内容を格納するテーブルである。履歴DB144は、顧客へのビール飲料の提案履歴を記憶するデータベースである。
【0015】
なお、補助記憶部14はサーバ1に接続された外部記憶装置であってもよい。また、サーバ1は複数のコンピュータからなるマルチコンピュータであっても良く、ソフトウェアによって仮想的に構築された仮想マシンであってもよい。
【0016】
また、本実施の形態においてサーバ1は上記の構成に限られず、例えば操作入力を受け付ける入力部、画像を表示する表示部等を含んでもよい。また、サーバ1は、CD(Compact Disk)-ROM、DVD(Digital Versatile Disc)-ROM等の可搬型記憶媒体1aを読み取る読取部を備え、可搬型記憶媒体1aからプログラムP1を読み取って実行するようにしても良い。あるいはサーバ1は、半導体メモリ1bからプログラムP1を読み込んでも良い。
【0017】
図3は、端末2の構成例を示すブロック図である。端末2は、制御部21、主記憶部22、通信部23、表示部24、入力部25、撮像部26、GPS(Global Positioning System)受信部27、補助記憶部28を備える。
制御部21は、一又は複数のCPU、MPU等の演算処理装置を有し、補助記憶部28に記憶されたプログラムP2を読み出して実行することにより、種々の情報処理、制御処理等を行う。主記憶部22は、RAM等の一時記憶領域であり、制御部21が演算処理を実行するために必要なデータを一時的に記憶する。通信部23は、通信に関する処理を行うための通信モジュールであり、外部と情報の送受信を行う。表示部24は、液晶ディスプレイ等の表示画面であり、画像を表示する。入力部25は、メカニカルキー等の操作インターフェイスであり、ユーザから操作入力を受け付ける。撮像部26は、CMOS(Complementary MOS)等の撮像素子を備えたカメラであり、画像を撮像する。GPS受信部27は、GPS信号を受信する受信機であり、端末2の位置情報を取得する。補助記憶部28は、ハードディスク、大容量メモリ等の不揮発性記憶領域であり、制御部21が処理を実行するために必要なプログラムP2、その他のデータを記憶している。
【0018】
なお、端末2は、CD-ROM等の可搬型記憶媒体2aを読み取る読取部を備え、可搬型記憶媒体2aからプログラムP2を読み取って実行するようにしても良い。あるいは端末2は、半導体メモリ2bからプログラムP2を読み込んでも良い。
【0019】
図4は、飲料DB141、顧客DB142、質問テーブル143、及び履歴DB144のレコードレイアウトの一例を示す説明図である。
飲料DB141は、飲料ID列、製品名列、説明列、製品画像列、製造元列、製造地域列、提供開始日列、特性値列を含む。飲料ID列は、各ビール飲料を識別するための飲料IDを記憶している。製品名列、説明列、製品画像列、製造元列、製造地域列、提供開始日列、及び特性値列はそれぞれ、飲料IDと対応付けて、ビール飲料の製品名、ビール飲料の説明文、製品画像、製造元(例えば醸造所)、製造地域(例えば醸造所の所在地)、提供開始日(例えば製品発売日)、及び特性値を記憶している。
【0020】
特性値は、例えばオリジナルエキス、外観エキス、外観最終発酵度、外観発酵度、苦味価、アルコール分、エキス分、残存発酵度、全窒素、pH、色度、酢酸エチル、n-プロパノール、イソブタノール、イソアミルアルコール、イソアミルアセテート、アミルアルコール、活性アミルアルコール、アセトアルデヒド、ダイアセチル、アミノ酸、硫酸イオン、リン酸イオン、クエン酸、コハク酸、リンゴ酸、酢酸、乳酸、イソ酪酸、カプリル酸、カプリン酸、総ポリフェノール、βグルカン、濁度、泡持ち時間、炭酸ガス、リナロール、α酸、イソα酸、S-フラクション等の成分値を含む。また、特性値は、アルコール量、カロリー、使用酵母(上面発酵酵母か下面発酵酵母か)、特定の原材料(麦芽、ホップ、小麦、糖類、香辛料、果物、野菜、米、味噌)の使用有無、及び商品名における日本国内の地域名の有無を含む。
【0021】
顧客DB142は、顧客ID列、顧客名列、属性列を含む。顧客ID列は、各顧客を識別するための顧客IDを記憶している。顧客名、及び属性列はそれぞれ、顧客IDと対応付けて、顧客名、及び顧客の複数の属性を記憶している。顧客の属性は、例えば年齢、性別等のほか、普段の飲酒習慣に関する情報(好みの酒類の銘柄、普段の飲酒量、飲酒場所など)を含む。
【0022】
質問テーブル143は、質問ID列、質問属性列、質問列、回答列を含む。質問ID列は、顧客に対して提示する各質問を識別するための質問IDを記憶している。質問属性列、質問列、及び回答列はそれぞれ、質問IDと対応付けて、質問の属性、質問内容(質問文)、及び回答の選択肢を記憶している。質問の属性は、ビール飲料の提案前に提示する質問であるか、又はビール飲料の注文後に提示する質問であるかを表すメタデータであり、後述の第1アンケート及び第2アンケートのいずれの質問であるかを表す。
【0023】
履歴DB144は、日時列、顧客列、提案前回答列、提案飲料列、注文列、注文後回答列を含む。日時列は、ビール飲料の提案日時を記憶している。顧客列、提案前回答列、提案飲料列、注文列、及び注文後回答列はそれぞれ、提案日時と対応付けて、ビール飲料を提案した顧客の顧客ID、提案前の質問(第1アンケート)に対する回答、提案したビール飲料の飲料ID、提案したビール飲料の注文の有無、及び注文後の質問(第2アンケート)に対する回答を記憶している。
【0024】
図5は、実施の形態1の概要を示す説明図である。
図5に基づき、本実施の形態の概要を説明する。
本実施の形態においてサーバ1は、顧客の属性(年齢、性別等)や後述のアンケートに係る質問への回答に基づき、顧客の嗜好に合致するビール飲料を提案するレコメンドサービスを提供する。当該サービスの利用場面は、例えばビール飲料を提供する飲食店であるが、その他にも小売店やEC(Electronic Commerce)サイトなどに適用してもよい。本実施の形態では一例として、飲食店において本サービスを提供するものとして説明する。
【0025】
例えば本サービスに加盟する飲食店には、所定のURL(Uniform Resource Locator)が記述された二次元コード(QRコード(登録商標)等)が用意されている。端末2は、撮像部26により撮像された画像から二次元コードを読み取ることでWebブラウザを起動し、サーバ1が提供するホームページにアクセスする。そして端末2は、
図6以降の画面を表示する。
【0026】
なお、本実施の形態ではWebページ上で一連の画面表示、操作を行うものとするが、例えば端末2に専用のアプリケーションをインストールし、当該アプリケーション上で一連の処理を行ってもよい。
【0027】
図6は、入力画面の一例を示す説明図である。端末2からアクセスを受け付けた場合、サーバ1は、
図6Aで例示する入力画面に遷移する。
図6Aの画面は、顧客の属性を入力するための入力画面であり、本サービスを利用する上で必要な基本情報を入力するための画面である。端末2は、
図6Aの画面において顧客の年齢、性別等のほかに、普段飲んでいる酒類の銘柄、飲酒量、飲酒場所(自宅で飲酒するか、外食で飲酒するか)などの入力を受け付ける。なお、これらは顧客の属性の一例であって、例えば顧客の所在地、職業、その他の情報を入力してもよい。サーバ1は、入力された顧客の属性を顧客IDと対応付けて顧客DB142に記憶する。また、端末2は、入力された顧客の属性を補助記憶部28に記憶しておき、本サービスを2回目以降に利用する場合は
図6Aの画面における属性入力をスキップしてもよい。
【0028】
次に端末2は
図6Bの入力画面に遷移する。
図6Bの画面は、顧客の嗜好を問う所定のアンケートに対し、顧客から回答の入力を受け付ける入力画面である。端末2は、
図6Bに示すように、本サービス上で案内を行う所定のキャラクタ61(オブジェクト)を画面中央に表示すると共に、当該キャラクタのセリフとして、顧客の嗜好を問う質問文を表示する。また、端末2は、当該質問に対する回答の選択肢を表示し、顧客から回答の選択入力を受け付ける。端末2は、順次質問を切り換えて回答の入力を受け付け、複数の質問それぞれに対する回答を取得する。サーバ1は、取得した回答を顧客IDと対応付けて履歴DB144に記憶する。
【0029】
なお、本実施の形態では基本的にテキスト表示によって顧客との間のやり取りを行うが、例えばチャットボットエンジンを用いて、音声の入出力を行うようにしてもよい。
【0030】
また、後述のように、本実施の形態ではビール飲料の注文後にもアンケートを実施する(
図9参照)。そのため、以下の説明では便宜上、ビール飲料の提案前に実施する
図6Bのアンケートを「第1アンケート」と呼び、注文後に実施するアンケートを「第2アンケート」と呼んで区別する。
【0031】
図5に戻って説明を続ける。サーバ1は、各入力画面で入力された顧客の属性及び回答に基づき、顧客に提案すべきビール飲料に関するビール情報を推定する。具体的には、サーバ1は、機械学習により生成された第1モデル51に、顧客の属性及び回答を入力して、ビール情報を推定(出力)する。
【0032】
第1モデル51は、所定の訓練データを学習することで生成された機械学習モデルであり、各属性及び回答に応じて分岐する決定木モデルである。具体的には、第1モデル51は、アンサンブル学習の一種である勾配ブースティングの手法を用いて生成された決定木モデル(例えばLightGBM)であり、複数の弱識別器を逐次生成することで生成される。
【0033】
例えばサーバ1は、実際にビール飲料を注文した顧客の属性、及び当該顧客による第1アンケートの回答を訓練用の入力データとすると共に、当該顧客が注文したビール飲料に関するビール情報を飲料DB141から読み出し、出力データの正解値として用いる。なお、訓練データは、実際の顧客のデータではなく、人手で作成された架空のデータであってもよい。あるいは訓練データは、GAN(Generative Adversarial Network)等のデータ生成手段によって水増しされたデータであってもよい。すなわち、訓練データは、人物の属性及び質問への回答に対し、正解のビール情報が対応付けられたデータであればよく、そのデータは実際の人物(顧客)のデータに限定されない。
【0034】
サーバ1は、上記の訓練データに基づいて第1モデル51を生成する。すなわち、サーバ1は、訓練データを用いて一の弱識別器(決定木)を生成し、生成した弱識別器によるビール情報の予測値と、訓練データが示すビール情報の正解値との誤差に基づき、次の弱識別器を生成する。サーバ1は、前の弱識別器の学習結果を考慮するように、予測値と正解値との誤差によって定義される損失関数の勾配を参照して次の弱識別器を逐次生成し、最終的な識別器、すなわち第1モデル51を生成する。
【0035】
なお、本実施の形態では学習方法として勾配ブースティングを用いるが、例えば複数の弱識別器を並列的に生成するバギングなど、その他のアンサンブル学習を行ってもよい。また、アンサンブル学習以外の学習方法で第1モデル51を生成してもよい。
【0036】
また、第1モデル51は決定木モデルに限定されず、ニューラルネットワーク、強化学習モデル、SVM(Support Vector Machine)など、その他の機械学習モデルであってもよい。
【0037】
サーバ1は、上記の第1モデル51に端末2から取得した顧客の属性及び回答を入力し、顧客に提案すべきビール飲料に関するビール情報を推定する。ビール情報は、例えばビール飲料の特性値であり、具体的には、外観エキス、外観最終発酵度などの各種成分の成分値である。サーバ1は第1モデル51を用いて、顧客に提案すべきビール飲料の成分値を推定する。その他にもサーバ1は、成分値以外の特性値として、ビール飲料のアルコール量、カロリーなどを推定してもよい。
【0038】
また、例えばサーバ1は、使用される酵母を示す値(ID等)を特性値として推定してもよい。具体的には、サーバ1は、使用酵母が上面発酵酵母か下面発酵酵母かを推定する。なお、推定対象とする酵母に自然発酵酵母を加えてもよい。これにより、いわゆるエールとラガーとの違いを考慮して推定することができる。
【0039】
また、例えばサーバ1は、特定の原材料の使用有無を示す値を特性値として推定してもよい。特定の原材料は、例えば麦芽、ホップ、小麦、糖類、香辛料、果物、野菜、米、味噌などである。これらの原材料の使用有無を考慮することで、顧客の嗜好に適したビール飲料を好適に推定可能であると共に、例えばアレルギー対策にも有用となる。
【0040】
また、例えばサーバ1は、商品名における特定の地域名の有無を示す値を特性値として推定してもよい。具体的には、サーバ1は、商品名における日本国内の地域名の有無を推定する。これにより、例えばクラフトビールを例にした場合、国産のクラフトビールであるか、国内のいずれの地域のクラフトビールであるか等も考慮してビール飲料を提案することができる。なお、推定対象とする地域名は日本国内の地域名に限定されず、他の地域名(日本以外の国の国名、地域名など)であってもよい。
【0041】
また、例えばサーバ1は、提案すべきビール飲料の製造元、製造地域など、製造元を示す値(ID等)を特性値として推定してもよい。これにより、例えばクラフトビールを例にした場合、いずれの醸造所、地域で生産されたクラフトビールを提案すべきか、好適に推定することができる。
【0042】
また、その他にもサーバ1は、提案すべきビール飲料の価格、量などを推定してもよい。このように、第1モデル51から出力される特性値は上記のパラメータに限定されず、その他のパラメータであってもよい。
【0043】
なお、本実施の形態では第1モデル51への入力として顧客の属性及び第1アンケートでの回答を用いるが、他の情報を第1モデル51への入力に用いてもよい。例えばサーバ1は、顧客の現在地周辺の気象情報(天候、気温等)を第1モデル51への入力に用いてもよい。この場合、例えばサーバ1は、端末2から位置情報(GPS信号等)を取得し、取得した位置情報が示す顧客の現在地の気象情報を外部のAPI(Application Programmable Interface)から取得して、第1モデル51に入力する。なお、例えば端末2が店舗設置端末である場合は端末2の位置が固定であるため、端末2から位置情報を取得せずに固定位置の気象情報を取得すればよい。これにより、外部環境も考慮して顧客に提案すべきビール飲料の特性値を推定することができる。
【0044】
また、例えばサーバ1は、第1モデル51への入力に用いる他の情報として、飲食店で提供する食事のジャンル(日本料理、中華、居酒屋、イタリアン等)を示すデータを用いてもよい。例えばサーバ1は、飲食店のレビューを掲載するWebサイトを参照して顧客が利用する飲食店の食事ジャンルを示すデータを取得し、第1モデル51に入力する。これにより、飲食店で提供する食事に適したビール飲料を提案することができる。
【0045】
また、上記では特段説明しなかったが、主成分分析等の手段で入力データ(属性、回答等)の次元数を削減してもよい。
【0046】
サーバ1は、第1モデル51からビール飲料の特性値を取得すると共に、その特性値の確からしさを示す確信度を取得する。確信度は、第1モデル51による推定結果の確からしさを示す値であり、例えば確率値で表現される。なお、ここで言う確信度は、学習時において決定木の分岐(ルーフ)の剪定に用いられる確信度(Confidence Factor)とは異なるので、注意されたい。
【0047】
なお、本実施の形態では第1モデル51においてビール飲料の特性値を推定するものとするが、本実施の形態はこれに限定されるものではない。例えば第1モデル51は、ビール情報として、顧客に提案すべきビール飲料の銘柄(飲料ID)自体を推定してもよい。この場合、サーバ1は第1モデル51での処理を分類問題と捉え、顧客に提案すべきビール飲料の飲料IDを訓練データの正解値として学習させればよい。このように、顧客に提案すべきビール飲料を第1モデル51において直接的に推定可能としてもよい。
【0048】
サーバ1は、第1モデル51で推定した特性値に基づき、顧客に提案すべきビール飲料を飲料DB141から選択して顧客に提案する。具体的には、サーバ1は、第1モデル51で推定した特性値と、飲料DB141に記憶されている各ビール飲料の特性値との類似度(例えばコサイン類似度)を算出し、類似度が高いビール飲料を選択して顧客に提案する。なお、類似度はコサイン類似度以外の指標値であってもよく、各ビール飲料の特性値の近似度合いを適切に評価可能なパラメータであればよい。例えばサーバ1は、算出した類似度を所定の閾値と比較して、類似度が閾値以上のビール飲料を、顧客に提案すべきビール飲料に選択する。なお、サーバ1は閾値の如何に関わらず、例えば類似度が最も高いビール飲料を選択するなどしてもよい。
【0049】
なお、サーバ1は、上記の類似度に加えて、又は類似度に代えて、各ビール飲料の提供開始日、過去に顧客に提案したビール飲料の提案履歴、第1モデル51から取得した確信度等に基づいて、提案すべきビール飲料を選択してもよい。
【0050】
例えばサーバ1は、類似度が閾値未満のビール飲料であっても、提供開始日が現時点から所定期間内であるビール飲料を、顧客に提案すべきビール飲料に選択する。これにより、新製品のビール飲料を顧客に提案し、販売促進を図ることができる。
【0051】
また、例えばサーバ1は、第1モデル51から取得した確信度が所定の閾値未満である場合、類似度の高低に関わらず、提供開始日が所定期間内のビール飲料を優先的に選択するようにしてもよい。これにより、第1モデル51による推定結果が不確実な恐れが高い場合に、好適にビール飲料を提案することができる。
【0052】
また、例えばサーバ1は、第1アンケートに新製品を嗜好するか否かを問う質問(「新商品を試飲しますか?」など)を設け、新製品を所望する旨の回答を得た場合、提供開始日が所定期間内のビール飲料を優先的に選択してもよい。これにより、顧客の要望も加味して新製品を提案することができる。
【0053】
また、例えばサーバ1は、類似度が閾値以上のビール飲料と、提供開始日から所定期間内のビール飲料とを飲料DB141から各々抽出し、抽出した各々のビール飲料群(類似度が閾値以上のビール飲料群、及び提供開始日から所定期間内のビール飲料)から、顧客に提案するビール飲料を一定の割合(例えば1:1)で選択するようにしてもよい。これにより、顧客の嗜好に合致すると思われるビール飲料と、販売促進を図りたい新製品のビール飲料とを合わせて提案することができる。
【0054】
また、例えばサーバ1は、類似度に応じて選択したビール飲料(例えば類似度が最も高いビール飲料)が顧客に対して過去に提案済みのビール飲料である場合に、他のビール飲料(例えば類似度が次に高いビール飲料)に変更してもよい。これにより、何度も同じ製品が提案されることがなくなり、リピーターを増やすことが期待できる。
【0055】
また、例えばサーバ1は、選択したビール飲料について、後述の第2アンケートで顧客が過去に低評価をした場合に、他のビール飲料に変更してもよい。サーバ1は、後述の第2アンケートでビール飲料の評価値を問う質問項目を表示し、例えば5段階で評価値の入力を受け付ける。なお、評価値は点数などで表現されてもよく、「好き」又は「嫌い」などの選択肢で表現されてもよい。サーバ1は、選択したビール飲料について過去に一定値以下(例えば「1」~「5」の5段階で「2」以下)の回答を取得していた場合、他のビール飲料に変更する。これにより、顧客の過去の評価も考慮してビール飲料を提案することができる。
【0056】
サーバ1は、上記で例示した複数の選択手法のうち、一又は複数の選択手法を用いて、顧客に提案するビール飲料を選択する。なお、上記の選択手法はいずれも例示であって、他の選択手法を用いてもよい。また、選択するビール飲料は単一ではなく複数であってもよい。サーバ1は、選択したビール飲料の情報を端末2に出力し、顧客に提案する。
【0057】
図7は、提案画面の一例を示す説明図である。
図7では、顧客にビール飲料を提案する際の画面例を図示している。提案画面は、キャラクタ61、ビール表示欄71、注文ボタン72、キャンセルボタン73を含む。キャラクタ61は、
図6Bと同様に、顧客への案内を行うキャラクタである。端末2は、キャラクタ61を画面上部の表示領域(第2領域)に表示すると共に、そのキャラクタ61のセリフとして、ビール表示欄71に表示するビール飲料を勧める旨のコメント(テキスト)を表示する。
【0058】
ビール表示欄71は、顧客に提案するビール飲料、すなわちサーバ1が選択したビール飲料の情報を表示する表示欄(第1領域)である。例えば端末2は、提案するビール飲料の製品名、説明文、及び製品画像をビール表示欄71に表示する。また、端末2は、提案するビール飲料のビアスタイル(原料、製法、アルコール度数等に応じたビールの分類)、アルコール量(濃度)、カロリー、製造元(ブルワリー)、製造地域など、ビール飲料の詳細なプロフィールを表示する。その他にも端末2は、当該ビール飲料の風味を複数の尺度で表すレーダーチャートを表示する。なお、レーダーチャートは、例えばサーバ1が飲料DB141に記憶されているビール飲料の成分値を加工することで自動的に作成してもよく、あるいは本システムの管理者等が人手で作成してもよい。
【0059】
注文ボタン72及びキャンセルボタン73は、店舗の発注システムと連携が可能な場合、提案されたビール飲料を注文する(飲む)か否かを選択するための操作オブジェクトである。注文ボタン72が操作された場合、提案されたビール飲料が注文される。この場合、例えばサーバ1は当該ビール飲料の注文を店舗スタッフに通知する。キャンセルボタン73が操作された場合、提案されたビール飲料は注文されずに処理を終了する。この場合、例えばサーバ1は別のビール飲料(類似度が次に高いビール飲料等)を選択して提案画面に表示させてもよく、あるいは一連の提案処理を終了してもよい。
【0060】
図8は、提案画面の他例を示す説明図である。例えばサーバ1は、第1モデル51における推定結果の確信度に応じて、提案画面の表示態様を変更させてもよい。
図8では、確信度が低い場合の画面例を図示している。
【0061】
例えばサーバ1は、確信度が所定の閾値以上であるか否かに応じて、キャラクタ61の表示態様を変更させる。具体的には、サーバ1は、キャラクタ61の表情、及びキャラクタ61のコメントを変更する。例えばサーバ1は、
図8に示すように、確信度が閾値未満である場合、
図7の画面からキャラクタ61の表情をネガティブな表情に変更し、提案したビール飲料が顧客の嗜好に合致しているか自信がなく、後述の第2アンケートに協力するよう依頼するコメントを表示させる。これにより顧客は、提案されたビール飲料が自身の嗜好に合致するか、その確からしさを容易に把握することができると共に、第2アンケートへの協力を得やすくなる。
【0062】
また、例えばサーバ1は、確信度が閾値未満の場合、ビール表示欄71に表示されているビール飲料以外の他のビール飲料を候補として表示させ、注文を受け付けてもよい。例えば端末2は、提案画面下部の候補欄81に、一又は複数の他のビール飲料を製品画像、製品名等を候補として表示する。サーバ1は、ビール表示欄71に表示されているビール飲料の次点以降に提案すべきビール飲料を候補欄81に表示させる。なお、次点以降とは、例えばビール表示欄71に表示されているビール飲料の次に類似度が高いビール飲料などであるが、これに限定されるものではない。例えば提供開始日を提案すべきビール飲料の選択基準とした場合、提供開始日が次に新しいビール飲料を候補としてもよく、候補とするビール飲料はその選択手法に依る。確信度が低い場合に他のビール飲料も併せて提案することで、第1モデル51での推定結果を考慮してビール飲料を好適に提案することができる。
【0063】
なお、上記では確信度が閾値未満の場合のみ他のビール飲料を候補として表示したが、確信度が閾値以上の場合も候補欄81を表示し、他のビール飲料を提案してもよい。
【0064】
また、上記では第1モデル51における確信度に応じてキャラクタ61の表示態様を変更したが、本実施の形態はこれに限定されるものではない。例えばサーバ1は、提供開始日をビール飲料の選択基準に用い、提供開始日から所定期間内のビール飲料を選択した場合に、キャラクタ61の表情を変更し、「新商品の○○はいかがでしょうか」といったコメントを表示してもよい。また、例えばサーバ1は、顧客への提案履歴又は過去の評価をビール飲料の選択基準に用い、過去に提案済みのビール飲料、又は過去に低評価だったビール飲料から他のビール飲料に変更して提案した場合に、キャラクタ61の表情を変更し、「○○が一番オススメですが、今回はこちらはいかがでしょうか」といったコメントを表示してもよい。このように、キャラクタ61の表示変更の基準となる情報は確信度に限定されず、他の情報であってもよい。
【0065】
図9は、第2アンケートの入力画面の一例を示す説明図である。注文ボタン72が操作され、ビール飲料が注文された場合、端末2は
図9の画面に遷移する。当該画面は、顧客が注文した(飲んだ)ビール飲料に関する第2アンケートの表示画面であり、ビール飲料の感想等を問う質問と、当該質問に対する回答の選択肢とを表示する画面である。例えば端末2は、
図9に示すようにビール飲料の評価値を問う質問項目を表示し、5段階で回答の入力を受け付ける。そのほか、端末2は、一緒に食べた食事、何杯目であるか等を問う各質問項目を順次表示し、回答の選択入力を受け付ける。なお、第2アンケートの質問内容は上記に限定されず、例えばより好ましい風味(「もっとアルコール度数が高い方が良い」等)など、顧客が要望するビール飲料を問う質問であってもよく、その質問内容は限定されない。サーバ1は、各質問項目への回答を、提案前に取得した第1アンケートの回答、提案したビール飲料等と対応付けて、提案履歴として履歴DB144に記憶する。
【0066】
なお、本実施の形態では、提案されたビール飲料が注文された場合のみ第2アンケートを実施するものとするが、注文されなかった場合にも第2アンケートを実施してもよい。
【0067】
例えばサーバ1は、履歴DB144に記憶された提案履歴を、第1モデル51の再学習に用いる。具体的には、サーバ1は、ビール飲料を提案した顧客の属性と、当該顧客が入力した第1アンケートの回答とを再学習用(訓練用)の入力データとし、提案したビール飲料を再学習用の正解値として学習を行い、第1モデル51を更新する。
【0068】
この場合、サーバ1は、提案したビール飲料の注文の有無、注文後に入力された第2アンケートの回答などに応じて再学習を行うと好適である。例えばサーバ1は、提案したビール飲料を顧客が注文しなかった場合、あるいはビール表示欄71ではなく候補欄81に表示されたビール飲料が注文された場合などは、提案したビール飲料の特性値を修正(例えば顧客が注文した別のビール飲料の特性値に変更)し、修正後の特性値を再学習の正解値として第1モデル51を更新する。また、例えばサーバ1は、第2アンケートにおいて、顧客が飲んだビール飲料が低評価(評価値が一定値以下)であった場合、提案したビール飲料の特性値を修正(例えば次に類似度が高いビール飲料の特性値に変更)し、修正後の特性値を正解値として第1モデル51に与え、第1モデル51を更新する。あるいはサーバ1は、顧客が飲んだビール飲料が高評価(評価値が一定値以上)であった場合、そのビール飲料の特性値をそのまま正解値として与えて第1モデル51を更新してもよい。
【0069】
なお、再学習用の正解値(特性値)は、第2アンケートの回答等に基づいて人手で作成した正解ラベルであってもよい。
【0070】
なお、上記の再学習手法は一例であって、本実施の形態はこれに限定されるものではない。例えばサーバ1は、顧客が要望するビール飲料を問う質問が第2アンケートに含まれる場合、その質問に対する回答(「もっとアルコール度数が高い方が良い」等)に応じて提案したビール飲料の特性値を変更(例えばアルコール量を変更)し、変更後の特性値を再学習用の正解値に用いて第1モデル51を更新してもよい。すなわち、第2アンケートへの回答内容に応じて、再学習に用いるビール情報(特性値)の正解値を変更してもよい。
【0071】
このように、第2アンケートの回答などに基づき、本システムの運用を通じて提案の精度を向上させることができる。
【0072】
図10は、第1モデル51の生成処理の手順を示すフローチャートである。
図10に基づき、機械学習により第1モデル51を生成する際の処理内容について説明する。
サーバ1の制御部11は、第1モデル51を生成するための訓練データを取得する(ステップS11)。訓練データは、人物の複数の属性、及び第1アンケートに係る質問への回答と、ビール情報の正解値とを含む。ビール情報は、例えばビール飲料の特性値であり、ビール飲料の成分値のほか、使用酵母、特定の原材料の使用有無、商品名における特定の地域名の有無などを示す値を含む。例えば制御部11は、実際の顧客の属性及び第1アンケートへの回答を訓練データとすると共に、顧客が実際に飲んだビール飲料の特性値を飲料DB141から読み出し、正解値として用いる。
【0073】
制御部11は訓練データに基づき、第1アンケートにおける複数の回答と、顧客の複数の属性とを入力した場合に、ビール情報を出力する第1モデル51を生成する(ステップS12)。具体的には上述の如く、制御部11は、勾配ブースティングを利用して決定木モデルを生成する。制御部11は、訓練データを用いて一の弱識別器(決定木)を生成し、生成した弱識別器による予測値と正解値との誤差に基づいて次の弱識別器を生成する。制御部11は、予測値と正解値との誤差によって定義される損失関数の勾配を参照して弱識別器を逐次生成し、最終的な識別器、すなわち第1モデル51を生成する。制御部11は一連の処理を終了する。
【0074】
図11は、飲料提案処理の手順を示すフローチャートである。
図11に基づき、顧客にビール飲料を提案する際の処理内容について説明する。
サーバ1の制御部11は、例えば二次元コードの読取により端末2からアクセスを受け付ける(ステップS31)。制御部11は、ビール飲料の提案に必要な情報を入力するための入力画面を端末2に出力し、表示させる(ステップS32)。制御部11は、入力画面において顧客の複数の属性の入力を受け付ける(ステップS33)。なお、顧客DB142に顧客が登録済みである場合、制御部11はステップS33をスキップする。制御部11は、第1アンケートに係る複数の質問を入力画面に順次表示させ、顧客から各質問への回答の入力を受け付ける(ステップS34)。
【0075】
制御部11は、顧客から入力された複数の属性及び回答を第1モデル51に入力し、顧客に提案すべきビール飲料の特性値(ビール情報)を推定する(ステップS35)。制御部11は、推定した特性値と、飲料DB141に記憶されている各ビール飲料の特性値との類似度を算出する(ステップS36)。制御部11は、ステップS36で算出した類似度のほか、提供開始日等に応じて飲料DB141からビール飲料を選択し、当該ビール飲料の情報を表示する提案画面を端末2に出力して表示させる(ステップS37)。提案画面は、選択されたビール飲料を表示するビール表示欄71のほか、ビール飲料を案内するキャラクタ61を含む。例えば制御部11は、第1モデルから出力された特性値の確からしさを示す確信度に応じてキャラクタ61の表示態様(表情、コメント等)を変更する。
【0076】
制御部11は、提案したビール飲料の注文を受け付けたか否かを判定する(ステップS38)。注文を受け付けなかったと判定した場合(S38:NO)、制御部11は一連の処理を終了する。なお、ステップS38でNOの場合、制御部11は処理をステップS37に戻し、別のビール飲料を再提案してもよい。
【0077】
注文を受け付けたと判定した場合(S38:YES)、制御部11は、第2アンケートに係る各質問を端末2に表示させ、顧客から回答の入力を受け付ける(ステップS39)。制御部11は一連の処理を終了する。
【0078】
図12は、第1モデル51の更新処理の手順を示すフローチャートである。
図12に基づき、再学習を行って第1モデル51を更新する際の処理内容について説明する。
サーバ1の制御部11は、再学習用の訓練データを履歴DB144等から取得する(ステップS51)。再学習用の訓練データは、顧客が入力した第1アンケートの回答、当該顧客の属性、顧客に提案したビール飲料の特性値などのほか、提案したビール飲料の注文の有無、注文後に入力された第2アンケートの回答などを含む。
【0079】
制御部11は、再学習用の訓練データに基づいて第1モデル51を更新する(ステップS52)。例えば制御部11は、提案したビール飲料を顧客が注文しなかった場合、顧客が注文したビール飲料の特性値を正解値として第1モデル51のパラメータを更新する。また、例えば制御部11は、提案したビール飲料の評価値が一定値以下であった場合、他のビール飲料の特性値を正解値として第1モデル51のパラメータを更新する。制御部11は一連の処理を終了する。
【0080】
以上より、本実施の形態1によれば、ビール情報(特性値)を学習済みの第1モデル51を用いることで、顧客の嗜好に合致するビール飲料を好適に選択し、顧客に提案することができる。
【0081】
また、本実施の形態1によれば、キャラクタ61を介してビール飲料を好適に提案することができる。特に本実施の形態では、第1モデル51から取得した確信度等に応じてキャラクタ61の表示態様を変更することで、提案されたビール飲料の確からしさを容易に把握することができる。
【0082】
また、本実施の形態1によれば、第1モデル51から出力された特性値と、飲料DB141に記憶されている各ビール飲料の特性値との類似度を算出することで、提案すべきビール飲料を好適に選択することができる。特に本実施の形態では、類似度のほかにも提供開始日や確信度等に応じて選択することで、より好適にビール飲料を提案することができる。
【0083】
(実施の形態2)
実施の形態1では、第1モデル51から出力された特性値との類似度を算出することで、顧客に提案するビール飲料を選択する形態について述べた。本実施の形態では、特性値に応じてビール飲料を分類するよう教師なし学習で構築された第2モデル52を用いて、顧客に提案するビール飲料を選択する形態について述べる。なお、実施の形態1と重複する内容については同一の符号を付して説明を省略する。
【0084】
図13は、実施の形態2に係るサーバ1の構成例を示すブロック図である。本実施の形態に係るサーバ1の補助記憶部14は、第2モデル52を記憶している。第2モデル52は、訓練データを学習済みの機械学習モデルであり、ビール飲料の複数の特性値(ビール情報)を入力して、当該特性値に対応するビール飲料を、複数のクラスタのいずれかに分類するクラスタリングモデルである。第2モデル52は、人工知能ソフトウェアの一部として機能するプログラムモジュールとしての利用が想定される。
【0085】
図14は、実施の形態2の概要を示す説明図である。
図14に基づき、本実施の形態の概要を説明する。
【0086】
本実施の形態においてサーバ1は、第1モデル51から出力された特性値を第2モデル52に入力し、飲料DB141に記憶されている各ビール飲料の集合である複数のクラスタのいずれかに分類する。第2モデル52は、特性値に応じてビール飲料を分類するクラスタリングモデルであり、例えばt-SNE法(t分布型確率的近傍埋め込み法)を用いた教師なし学習で生成される。
【0087】
なお、本明細書で云う「教師なし学習」とは、正解値が未知の訓練データを学習してモデルを生成することを指す。
【0088】
例えばサーバ1は、飲料DB141に記憶されている各ビール飲料の特性値を訓練データとして学習を行う。なお、訓練データは本システムで提供(提案)するビール飲料以外のビール飲料に係る特性値であってもよく、あるいは公知のデータ生成手段によって水増しされたデータであってもよい。また、第2モデル52の訓練データは第1モデル51の訓練データと共通であってもよい。サーバ1は、各ビール飲料の複数の特性値を特徴量と捉え、高次元から低次元(例えば2次元又は3次元)に圧縮しつつ、特性値が近似するビール飲料同士が近づくように特徴量空間へマッピングする。そしてサーバ1は、特徴量空間において距離(例えばユークリッド距離)が近いビール飲料群を集約し、複数のクラスタを生成する。
【0089】
なお、上記ではクラスタリング手法としてt-SEN法を挙げたが、k-means法など、他の手法を用いてもよい。また、本実施の形態では、教師なし学習で生成されたクラスタリングモデルを第2モデル52として用いるが、本実施の形態に係る分類問題をクラス分類と捉え、ビール飲料の集合(クラス)が既知の訓練データから教師あり学習によって第2モデル52を生成してもよい。
【0090】
サーバ1は、第1モデル51から出力された特性値を第2モデル52に入力し、複数のクラスタのいずれかに分類する。そしてサーバ1は、分類されたクラスタに属する一又は複数のビール飲料のうち、いずれかのビール飲料を、顧客に提案すべきビール飲料として選択する。
【0091】
この場合、例えばサーバ1は、クラスタへの分類結果に加えて、実施の形態1で説明した類似度、提供開始日、確信度、提案履歴等に基づき、提案すべきビール飲料を選択してもよい。例えばサーバ1は、分類されたクラスタに属するビール飲料のうち、第1モデル51から出力された特性値との類似度が最も高いビール飲料を選択してもよい。また、例えばサーバ1は、分類されたクラスタに属するビール飲料のうち、提供開始日が所定期間内のビール飲料を選択してもよい。また、例えばサーバ1は、確信度が閾値未満の場合、分類されたクラスタ以外のクラスタに属するビール飲料を選択してもよい。また、例えばサーバ1は、分類されたクラスタのうち、顧客に対して未提案のビール飲料を選択してもよい。このように、本実施の形態においてもビール飲料の選択手法は多数考えられる。
【0092】
サーバ1は、上記で選択されたビール飲料の情報を端末2に出力し、顧客に提案する。以降の処理は実施の形態1と同様であるため、説明を省略する。
【0093】
図15は、第2モデル52の生成処理の手順を示すフローチャートである。
図15に基づき、第2モデル52を生成する際の処理内容について説明する。
サーバ1の制御部11は、飲料DB141から、複数のビール飲料それぞれに対応する複数の特性値を訓練データとして取得する(ステップS201)。制御部11は、各ビール飲料を特性値に応じて複数のクラスタに分類する教師なし学習を行うことで、複数の特性値を入力として、ビール飲料の集合である複数のクラスタのいずれかに分類する第2モデル52を生成する(ステップS202)。制御部11は一連の処理を終了する。
【0094】
図16は、実施の形態2に係る飲料提案処理の手順を示すフローチャートである。第1モデル51を用いてビール飲料の特性値を推定した後(ステップS35)、サーバ1は以下の処理を実行する。
サーバ1の制御部11は、第1モデル51から出力された特性値を第2モデル52に入力して、ビール飲料の集合である複数のクラスタのいずれかに分類する(ステップS221)。制御部11は、分類されたクラスタに応じてビール飲料を飲料DB141から選択し、選択したビール飲料を提案する提案画面を端末2に出力する(ステップS222)。制御部11は処理をステップS38に移行する。
【0095】
以上より、本実施の形態2によれば、特性値に基づいてビール飲料を分類する第2モデル52を用いることで、顧客に提案すべきビール飲料を好適に選択することができる。特に本実施の形態では、人手で正解値のラベル付けをする必要なく第2モデル52を構築することができる。
【0096】
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【0097】
1 サーバ(情報処理装置)
11 制御部
12 主記憶部
13 通信部
14 補助記憶部
P1 プログラム
51 第1モデル
52 第2モデル
141 飲料DB
142 顧客DB
143 質問テーブル
144 履歴DB
2 端末
21 制御部
22 主記憶部
23 通信部
24 表示部
25 入力部
26 撮像部
27 GPS受信部
28 補助記憶部
P2 プログラム