JP7144558B2 - 検索システム、および検索方法 - Google Patents

Description

本発明は、検索システム、および検索方法に関する。

従来、ベクトル化された状況データと、コンテンツデータとを集約させて、新しい集約データを作成し、新しい集約データに基づいてコンテンツ嗜好モデルを更新するコンテンツ推薦システムが知られている（特許文献１参照）。

特開２０１３－６９２６６号公報

しかしながら、従来の技術では、リアルタイムで提供されるサービスに関連したスムーズな検索を実現することができない場合があった。

本発明は、このような事情を考慮してなされたものであり、スムーズな検索を実現することができる検索システム、および検索方法を提供することを目的の一つとする。

本発明の一態様は、第１情報を第１のモデルに入力することで第１特徴情報を生成し、第１の記憶部に記憶させる第１の生成部と、第２情報を、前記第１のモデルと関連性を有する第２のモデルに入力することで第２特徴情報を生成し、第２の記憶部に記憶させる第２の生成部と、前記第１特徴情報を用いて前記第２の記憶部を検索し、前記第１特徴情報に関連する第２特徴情報を取得する検索部と、を備え、前記第１の生成部と前記第２の生成部のそれぞれは、使用されるモデルの世代が異なる複数のチャネルを有し、各チャネルで並行して処理を実行し、前記複数のチャネルから現用系のチャネルを選択する管理部を更に備え、前記現用系でないチャネルで使用されている前記第１のモデルと前記第２のモデルとが、所定タイミングで新たなモデルに更新される、検索システムである。

本発明の一態様によれば、スムーズな検索を実現することができる検索システム、および検索方法を提供することができる。

検索システムの一部を構成するレコメンド管理装置３０の使用環境の一例を示す図である。 ユーザ情報２２の内容の一例を示す図である。 配信記事情報２４の内容の一例を示す図である。 行動ログ２６の内容の一例を示す図である。 検索システムの全体構成図である。 記事ベクトル生成部４２の処理の内容を概念的に示す図である。 ユーザベクトル生成部６２の処理の内容を概念的に示す図である。 チャネルの切り替えに関するタイムスケジュールの一例を示す図である。 レコメンド管理装置３０により実行される処理の流れの一例を示すフローチャートである。

以下、図面を参照し、本発明の検索システム、および検索方法の実施形態について説明する。

［概略］
検索システムは、一以上のプロセッサにより実現される。検索システムは、例えば外部からの問い合わせに応じて、ある特徴情報（第１の特徴情報）に対応する他の特徴情報（第２の特徴情報）を検索するシステムである。

第１の特徴情報は、例えば、ユーザが閲覧した記事の履歴に基づいて、第１のモデルにより生成されるユーザベクトルである。ユーザベクトルは、そのユーザの興味の対象を示すものと考えられる。記事とは、インターネットなどのネットワークを介して提供される電子的な記事であり、テキスト情報を含むものである。記事は、ブラウザによって再生されるウェブページの一部として提供されるものであってもよいし、アプリケーションプログラムによって表示されるアプリページの一部として提供されるものであってもよい。

第２の特徴情報は、例えば、記事に基づいて生成される記事ベクトルである。記事ベクトルは、例えば、記事に含まれる単語を形態素解析等によって抽出した後、word2vec等の手法により分散表現化した単語ベクトルを第２のモデルに入力することで生成される。

ここで、第１の特徴情報であるユーザベクトルは、例えば、第２の特徴情報である記事ベクトルを利用して生成される。例えば、ユーザベクトルは、ユーザが閲覧した記事のそれぞれに対して生成されている記事ベクトルの集合を、第１のモデルに入力することで生成される。ユーザベクトルも、分散表現で表されるベクトルである。

このように、第１の特徴情報であるユーザベクトルと第２の特徴情報である記事ベクトル、並びに第１のモデルと第２のモデルは、意味的な関連性を有するものである。上記の例では、記事ベクトルの定義が変更されると、記事ベクトルからユーザベクトルを生成するモデルも変更する必要があるからである。

ユーザベクトルに対応する記事ベクトルが得られると、検索システムは、得られた記事ベクトルに対応する記事を、当該ユーザに対応するレコメンド記事として問い合わせ元に返す。これによって、ユーザが関心・興味のある内容に近い記事が、当該ユーザに提供されることになり、ウェブページないしアプリページの魅力を維持・向上することができる。

このような検索サービスを提供する中で、検索システムは、モデル更新をスムーズに行うための処理および仕組みを有している。また、モデル更新の後に古いバージョンのユーザデータを用いて検索を行うことが無いように、特徴的な処理を行っている。これらについては、以下の説明で段階的に開示する。

［構成］
図１は、検索システムの一部を構成するレコメンド管理装置３０の使用環境の一例を示す図である。図示の例では、一以上のユーザ端末１０が、ネットワークＮＷを介してサービスサーバ２０に接続されている。ネットワークＮＷは、例えば、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）、プロバイダ端末、無線通信網、無線基地局、専用回線などを含む。また、レコメンド管理装置３０もネットワークＮＷに接続されており、サービスサーバ２０と通信する。なお、本実施形態に登場する構成要素は、ネットワークＮＷその他のネットワークに接続するための通信インターフェースを備えているものとする。通信インターフェースは、ＮＩＣ（Network Interface Card）などのネットワークカード、無線通信モジュールなどを含む。

［ユーザ端末］
ユーザ端末１０は、例えば、スマートフォンなどの携帯電話、タブレット端末、各種パーソナルコンピュータなどの、入力装置、表示装置、通信装置、記憶装置、および演算装置を備える端末装置である。ユーザ端末１０では、ブラウザやアプリケーションプログラムなどのＵＡ（User Agent）が起動し、ユーザの入力する内容に応じたリクエストをサービスサーバ２０に送信する。また、ＵＡは、サービスサーバから取得した情報に基づいて、各種画像を表示する。

［サービスサーバ］
サービスサーバ２０は、ブラウザからのリクエストに応じてウェブページをユーザ端末１０に提供するウェブサーバ、またはアプリケーションプログラムからのリクエストに応じて画像や音声を提供するユーザ端末１０に提供するアプリサーバである。

サービスサーバ２０の提供するサービスは、例えば、ユーザＩＤとパスワードを入力しログインすることで、より個別のユーザに対してカスタマイズされたサービスとして提供される。なお、サービスサーバ２０がウェブサーバである場合、ログインしなくてもウェブページの提供を受けることはできるが、その場合、ユーザに対するカスタマイズがされていない汎用のウェブページが提供される。

サービスサーバ２０は、ユーザによるログインがなされると、例えば、ユーザＩＤを指定した問い合わせをレコメンド管理装置３０に送信する。レコメンド管理装置３０は、ユーザＩＤにより示されるユーザに推薦する記事の記事ＩＤを、サービスサーバ２０に返信する。サービスサーバ２０は、所定の画面（例えばウェブサイトやアプリページのトップページ）に、レコメンド管理装置３０から受信した記事ＩＤにより示される記事を掲載してユーザ端末１０に送信する。

サービスサーバ２０は、サーバ内あるいは外部の記憶装置（不図示）に、ユーザ情報２２、配信記事情報２４、および行動ログ２６を記憶させている。

図２は、ユーザ情報２２の内容の一例を示す図である。ユーザ情報２２は、例えば、ユーザの識別情報であるユーザＩＤに対し、パスワード、および年齢、性別、誕生日、職業その他のデモグラ情報が対応付けられた情報である。

図３は、配信記事情報２４の内容の一例を示す図である。配信記事情報２４は、例えば、記事の識別情報である記事ＩＤに対し、記事データが対応付けられた情報である。記事データは、例えば、テキストデータ、画像データ、またはこれらの組み合わせ、或いはＵＲＬ（Uniform Resource Locator）などの参照情報である。

図４は、行動ログ２６の内容の一例を示す図である。行動ログ２６は、例えば、ユーザＩＤごとに、閲覧したページの識別情報である閲覧ページＩＤ、閲覧したページに含まれる記事の記事ＩＤ、閲覧時刻などが互いに対応付けられた情報である。

［検索システムの全体構成］
図５は、検索システム１の全体構成図である。検索システム１は、レコメンド管理装置３０の他に、例えば、記事ベクトル生成装置４０（第２の生成部の一例）と、記事ベクトル記憶部５０（第２の記憶部の一例）と、ユーザベクトル生成装置６０（第１の生成部の一例）と、ユーザベクトル記憶部７０（第１の記憶部の一例）と、記事ベクトル検索装置８０（検索部の一例）と、のうち一部または全部を備える。すなわち、検索システム１は、記事ベクトル記憶部５０とユーザベクトル記憶部７０とを含んでもよいし、含まなくてもよい。また、レコメンド管理装置３０は、管理部の一例である。なお、これらの構成要素は、適宜、統合または分散化されてもよい。例えば、レコメンド管理装置３０と記事ベクトル生成装置４０とユーザベクトル生成装置６０は、統合された一つのプロセッサにより実現されてもよい。

レコメンド管理装置３０の構成に先立って、記事ベクトル生成装置４０から順に説明する。ここで、記事ベクトル生成装置４０、記事ベクトル記憶部、ユーザベクトル生成装置６０、およびユーザベクトル記憶部７０は、チャネル１とチャネル２の二つのチャネルを有し、それぞれが並行して処理を進めている。なお、チャネルの数は二つに限らず、三つ以上のチャネルを備えてもよい。以下の説明では、括弧内の数字がチャネルを表すものとし、チャネルを区別しない場合は括弧および括弧内の数字を省略して説明する。

記事ベクトル生成装置４０は、記事ベクトル生成部４２（１）と、記事ベクトル生成部４２（２）とを備える。図６は、記事ベクトル生成部４２の処理の内容を概念的に示す図である。記事ベクトル生成部４２には、記事の内容（テキスト）が入力される。記事の内容は、例えば、配信記事情報２４から取得される。

記事ベクトル生成部４２は、まず、記事の内容に対して形態素解析などを行って、単語（形態素）に分割する。次に、記事ベクトル生成部４２は、各単語に対してword2vecなどの手法を適用して、分散表現化された単語ベクトルを取得する。形態素解析とword2vecとのうち一方または双方は、記事ベクトル生成部４２が自ら処理を行うのではなく、外部装置に処理を依頼することで実現されてもよい。

そして、記事ベクトル生成部４２は、記事から取得された一以上の単語ベクトルを第２のモデルに入力することで、記事ベクトルを導出する。第２のモデルは、例えば、機械学習によって生成されるモデルである。第２のモデルは、例えば、ディープラーニングなどの手法により、既知の単語ベクトルと記事ベクトルとの関係が再現できるような、隠れ層の活性化関数のパラメータを求めることで生成される。

なお、上記の定義に拘わらず、第２のモデルとは、word2vecの特定、すなわち、どのようなコーパスをword2vecに与えるか、までを含んでもよい。

記事ベクトル生成部４２は、生成した記事ベクトルを、記事ＩＤと共に記事ベクトル記憶部５０に格納する。このとき、自身がチャネル１であればチャネル１データとして記事ベクトル記憶部５０に格納し、自身がチャネル２であればチャネル２データとして記事ベクトル記憶部５０に格納する。

記事ベクトル記憶部５０は、例えば、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ、ＲＡＭ（Random Access Memory）などの記憶装置によって実現される。記事ベクトル記憶部５０は、チャネル１データと、チャネル２データとを分けて記憶領域に格納する。チャネル１データと、チャネル２データのそれぞれは、記事ＩＤに対して記事ベクトルが対応付けられたデータである。

ユーザベクトル生成装置６０は、ユーザベクトル生成部６２（１）と、ユーザベクトル生成部６２（２）とを備える。図７は、ユーザベクトル生成部６２の処理の内容を概念的に示す図である。ユーザベクトル生成部６２には、ユーザＩＤと、そのユーザＩＤにより示されるユーザが閲覧した記事の記事ＩＤとが入力される。ユーザが閲覧した記事の記事ＩＤは、例えば、行動ログ２６から取得される。

ユーザベクトル生成部６２は、まず、ユーザが閲覧した記事の記事ＩＤに対応する記事ベクトルを記事ベクトル記憶部５０から取得する。このとき、自身がチャネル１であれば記事ベクトル記憶部５０のチャネル１データから記事ベクトルを取得し、自身がチャネル２であれば記事ベクトル記憶部５０のチャネル２データから記事ベクトルを取得する。

そして、ユーザベクトル生成部６２は、取得された一以上の記事ベクトルを第１のモデルに入力することで、ユーザベクトルを導出する。第１のモデルは、例えば、機械学習によって生成されるモデルである。第１のモデルは、例えば、ディープラーニングなどの手法により、既知の記事ベクトルとユーザベクトルとの関係が再現できるような、隠れ層の活性化関数のパラメータを求めることで生成される。ユーザベクトル生成部６２は、生成したユーザベクトルを、ユーザＩＤと共にユーザベクトル記憶部７０に格納する。このとき、自身がチャネル１であればチャネル１データとしてユーザベクトル記憶部７０に格納し、自身がチャネル２であればチャネル２データとして記事ベクトル記憶部７０に格納する。なお、ユーザベクトルは、閲覧した記事の記事ベクトル以外の要素を反映させて作成されてもよい。記事ベクトル以外の要素とは、例えば、ユーザの入力したクエリ、記事を有さないウェブページの閲覧履歴、ユーザの属性（年齢、性別、職業など）のうち一部または全部である。

以下、レコメンド管理装置３０について説明する。レコメンド管理装置３０は、例えば、チャネル切替部３２と、応答部３４と、ユーザベクトル検索部３６と、検索依頼部３８とを備える。これらの構成要素は、例えば、ＣＰＵ（Central Processing Unit）などのハードウェアプロセッサがプログラム（ソフトウェア）を実行することにより実現される。また、これらの構成要素のうち一部または全部は、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）、ＧＰＵ（Graphics Processing Unit）などのハードウェア（回路部；circuitryを含む）によって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。

チャネル切替部３２は、チャネル１、チャネル２について、現用系と待機系を切り替える。詳しくは、後述する。

応答部３４は、サービスサーバ２０からの問い合わせに応答し、ユーザベクトル検索部３６および検索依頼部３８に動作指示を出力し、検索依頼部３８から返された検索結果（記事ベクトル）を、レコメンド記事としてサービスサーバ２０に返す。サービスサーバ２０からの問い合わせは、例えば、ユーザＩＤを指定して行われる。応答部３４は、検索対象のユーザＩＤをユーザベクトル検索部３６に出力して、検索を行わせる。

ユーザベクトル検索部３６は、入力されたユーザＩＤを用いてユーザベクトル記憶部７０を検索し、ユーザＩＤに対応するユーザベクトルを取得する。このとき、ユーザベクトル検索部３６は、チャネル切替部３２によって現用系に設定されている方のチャネルのデータを検索する。ユーザベクトル検索部３６は、検索の結果として得られるユーザベクトルを検索依頼部３８に出力する。

検索依頼部３８は、入力されたユーザベクトルを用いて記事ベクトル記憶部５０を検索するように、記事ベクトル検索装置８０に依頼する。このとき、検索依頼部３８は、チャネル切替部３２によって現用系に設定されている方のチャネルのデータを検索するように記事ベクトル検索装置８０に依頼する。

記事ベクトル検索装置８０は、依頼に応じて記事ベクトル記憶部５０を検索する。記事ベクトル検索装置８０は、ユーザベクトルとのベクトル間距離が小さい記事ベクトルを探索し、例えばベクトル間距離が最も小さい順に所定数の記事ベクトルを抽出する。この際に、記事ベクトル検索装置８０は、ｋ近傍探索（k-Nearest neighbor search）に類する手法を用いて検索を行ってもよい。記事ベクトル検索装置８０は、検索結果を検索依頼部３８に返す。検索依頼部３８は、これを応答部３４に返す。これによって、一ユーザについてのレコメンド記事の提供が完了する。

［チャネルの切替］
以下、検索システム１におけるチャネルの切り替えについて説明する。図８は、チャネルの切り替えに関するタイムスケジュールの一例を示す図である。チャネル１とチャネル２では、半周期ずらしてモデル（第１のモデルおよび第２のモデル）の更新が行われる。そして、更新完了後、速やかに現用系への切り替えが行われる。モデルの更新とは、学習データを直近のものに更新し、新たにモデルの学習をし直すことをいう。この学習は、瞬時には完了しないため、モデルの更新すなわち機械学習は、現用系への切り替わりタイミングに間に合うように、切り替わりタイミングから想定所要時間に余裕時間を加算した時間を逆算したタイミングで開始される。

なお、記事ベクトルは、毎日、記事が入稿されるのに応じて新たなものが生成され、記事ベクトル記憶部５０に追加される。しかしながら、word2vecの機能と、word2vecにより得られた単語ベクトルから記事ベクトルを導出する規則に関しては、第２のモデルの更新がされない限り同じものが使用される。従って、第２のモデルの更新とは、例えば、word2vecに与えるコーパスの更新と、word2vecにより得られた単語ベクトルから記事ベクトルを導出する規則の更新とを含む。これに限らず、word2vecに与えるコーパスを固定、或いは第２のモデルの更新周期Ｔよりも長い周期で変更し、第２のモデルの更新にはword2vecに与えるコーパスの変更が含まれないものとしてもよい。

また、ユーザベクトルは、ユーザが記事を閲覧した度に、バッチ処理などによって更新される。このとき、新たな判定用情報（後述するように、例えばタイムスタンプ）がユーザベクトルに付与される。しかしながら、記事ベクトルからユーザベクトルを導出する規則に関しては、第１のモデルの更新がされない限り同じものが使用される。従って、第１のモデルの更新とは、記事ベクトルからユーザベクトルを導出する規則の更新を意味する。

第１のモデルおよび第２のモデルは、更新周期Ｔごとに、更新開始日から参照期間Ｘまで遡った日までのデータに基づいて更新される。このとき、更新開始日から参照期間Ｘまで遡った日までに作成されていた記事ベクトルは、新たな第２のモデルによって作成し直される。また、更新開始日から参照期間Ｘまで遡った日までに作成されていたユーザベクトルも、新たな第１のモデルおよび作成し直された記事ベクトルを用いて作成し直される。但し、モデルの更新に伴ってユーザベクトルが作成し直された際に、タイムスタンプは変更されない。図８では、更新周期Ｔと参照期間Ｘが一致しているように示しているが、参照期間Ｘは更新周期Ｔよりも長い期間であってもよいし、短い期間であってもよい。

現用系の切り替えは、例えば、更新周期Ｔの半分の周期Ｔ／２で実行される。例えば、Ｔ／２は二週間程度の期間である。現用系の切り替え日は、予めカレンダー上で定められており、その日に間に合うようにモデルの更新が行われる。また、現用系の切り替え日は、レコメンド管理装置３０の方でも把握しており、その日の例えば午前ゼロ時が到来すると、レコメンド管理装置３０は、参照先のチャネルを切り替える。

このような仕組みによって、実施形態の検索システム１は、現用系と待機系とを遅滞なく切り替えることができ、スムーズにモデルの更新を実現することができる。

［タイムスタンプについて］
ユーザベクトルは、統計的に有用な情報であるため、更新周期Ｔよりも長い期間（例えば一か月程度）、保持される場合がある。この場合、ユーザが何も記事を閲覧しない状態が、参照期間Ｘよりも長い間、継続したとすると、古いバージョンの第１のモデルおよび第２のモデルによって作成されたユーザベクトルがユーザベクトル記憶部７０に格納される可能性がある。この場合、前提としている記事ベクトルが異なるのであるから、記事ベクトル検索装置８０による検索が有意なものとならない場合がある。

そこで、実施形態の検索システム１では、ユーザベクトル生成装置６０が、ユーザベクトルを生成する度に、直近のモデルによって作成された情報であることを確認可能な判定用情報をユーザベクトルに付随させてユーザベクトル記憶部７０に記憶させる。なお、以下の説明では、直近のモデルとは、チャネルごとの直近の第１のモデルおよび直近の第２のモデルを指すものとする。判定用情報とは、例えば、ユーザベクトルを生成した時刻、ユーザベクトルをユーザベクトル記憶部７０に記憶させた時刻など、ユーザベクトルを生成した時刻の近傍の時刻を示すタイムスタンプである。

そして、レコメンド管理装置３０は、サービスサーバ２０からの問い合わせに応じてユーザベクトルをユーザベクトル記憶部７０から取得する際に、判定用情報を合わせて読み出し、判定用情報に基づいて、読み出したユーザベクトルが、直近のモデルによって作成された情報であることを確認する。レコメンド管理装置３０は、タイムスタンプを現在時刻と比較し、その差分の時間が参照期間Ｘを超える場合には、必ずしも直近のモデルによって作成された情報であることが確認できないため、ユーザベクトルを指定した検索依頼を記事ベクトル検索装置８０に出力しない。この場合、レコメンド管理装置３０は、例えば「レコメンド記事なし」を示す応答を、サービスサーバ２０に返す。この結果、サービスサーバ２０では、例えば、アクセス数やＣＴＲ（Click Through Ratio）などの指標値が良好な記事から順に、ユーザに記事を配信する。

このような仕組みによって、実施形態の検索システム１は、不適切なレコメンド記事がユーザに配信されるのを防止することができる。

また、タイムスタンプをユーザベクトルに付与しておくことで、レコメンド管理装置３０は、現用系のチャネルがチャネル１とチャネル２のいずれであるかを知る必要が無くなる。レコメンド管理装置３０は、更新周期Ｔを把握しているため、ユーザベクトル記憶部７０にあるユーザベクトルに付与されたタイムスタンプと現在の時刻を比較することで、どのチャネルが現用系のチャネルであるかを判断することができる。

ここで、タイムスタンプに代えて、第１のモデルおよび第２のモデルのバージョン情報を判定用情報とすることもできる。しかしながら、この場合、ユーザベクトルにタイムスタンプが付与されていないため、レコメンド管理装置３０において、現用系のチャネルの情報と、モデルのバージョン情報とを認識する必要があり、これらの情報を指定してユーザベクトル記憶部７０にデータ取得要求を出力する必要がある。これによって処理負担や通信量が増大するため、タイムスタンプを判定用情報とすることが、より好ましい。

［処理フロー］
図９は、レコメンド管理装置３０により実行される処理の流れの一例を示すフローチャートである。このフローチャートの処理は、レコメンド管理装置３０の応答部３４がサービスサーバ２０から問い合わせを受けたときに開始される。

まず、レコメンド管理装置３０のユーザベクトル検索部３６は、ユーザベクトル記憶部７０からユーザベクトルと判定用情報を取得する（Ｓ１００）。

次に、レコメンド管理装置３０の検索依頼部３８は、判定用情報に基づいて、ユーザベクトルが直近のモデルによって作成された情報であることが確認できるか否かを判定する（Ｓ１０２）。

ユーザベクトルが直近のモデルによって作成された情報であることが確認される場合、検索依頼部３８は、ユーザベクトルを指定して記事ベクトル検索装置８０に検索依頼をする（Ｓ１０４）。ユーザベクトルが直近のモデルによって作成された情報であることが確認されない場合、Ｓ１０４の処理はスキップされる。

そして、応答部３４は、記事ベクトル検索装置８０から取得された記事ベクトル、或いは「レコメンド記事なし」のいずれかの応答を、サービスサーバ２０に返す（Ｓ１０６）。これによって、フローチャートの処理が終了する。

以上説明した実施形態の検索システム、および検索方法によれば、ユーザが閲覧した記事の履歴を第１のモデルに入力することでユーザベクトルを生成し、ユーザベクトル記憶部７０に記憶させるユーザベクトル生成装置６０と、ネットワークを介して配信される記事を第２のモデルに入力することで記事ベクトルを生成し、記事ベクトル記憶部５０に記憶させる記事ベクトル生成装置４０と、ユーザベクトル記憶部７０を検索して問い合わせの内容に対応するユーザベクトルを取得すると共に、ユーザベクトルを指定した検索要求を記事ベクトル検索装置８０に出力するレコメンド管理装置３０と、レコメンド管理装置３０からの検索要求に応じて、指定されたユーザベクトルを用いて記事ベクトル記憶部５０を検索し、指定されたユーザベクトルに関連する記事ベクトルを取得する記事ベクトル検索装置８０と、を備え、第１のモデルは、第２のモデルと関連性を有し、ユーザベクトル生成装置６０と記事ベクトル生成装置４０のそれぞれは、使用されるモデルの世代が異なる複数のチャネルを有し、各チャネルで並行して処理を実行し、レコメンド管理装置３０は、複数のチャネルから現用系のチャネルを選択し、現用系でないチャネルで使用されている第１のモデルと第２のモデルとが、所定タイミングで新たなモデルに更新される。これによって、実施形態の検索システム、および検索方法は、スムーズにモデルを更新することができる。

以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

１ 検索システム
１０ ユーザ端末
２０ サービスサーバ
３０ レコメンド管理装置
３２ チャネル切替部
３４ 応答部
３６ ユーザベクトル検索部
３８ 検索依頼部
４０ 記事ベクトル生成装置
５０ 記事ベクトル記憶部
６０ ユーザベクトル生成装置
７０ ユーザベクトル記憶部
８０ 記事ベクトル検索装置

Claims (9)

1. 第１情報を第１のモデルに入力することで第１特徴情報を生成し、第１の記憶部に記憶させる第１の生成部と、
   第２情報を、前記第１のモデルと関連性を有する第２のモデルに入力することで第２特徴情報を生成し、第２の記憶部に記憶させる第２の生成部と、
   前記第１特徴情報を用いて前記第２の記憶部を検索し、前記第１特徴情報に関連する第２特徴情報を取得する検索部と、を備え、
   前記第１の生成部と前記第２の生成部のそれぞれは、使用されるモデルの世代が異なる複数のチャネルを有し、各チャネルで並行して処理を実行し、
   前記複数のチャネルのうち現用系でないチャネルで使用されている前記第１のモデルと前記第２のモデルとが、所定タイミングで新たなモデルに更新される、
   検索システム。
2. 前記複数のチャネルから現用系のチャネルを選択する管理部を更に備える、
   請求項１記載の検索システム。
3. 前記第１特徴情報および前記第２特徴情報のそれぞれは、ベクトルデータである、
   請求項１または２記載の検索システム。
4. 前記第１の生成部は、前記生成した第１特徴情報を、直近の前記第１のモデルおよび前記第２のモデルによって作成された情報であることを確認可能な判定用情報と共に前記第１の記憶部に記憶させ、
   前記管理部は、前記判定用情報に基づいて、前記第１の記憶部から取得した第１特徴情報が、直近の前記第１のモデルおよび前記第２のモデルによって作成された情報であることが確認される場合、前記第１特徴情報を指定した検索要求を検索部に出力する、
   請求項２記載の検索システム。
5. 前記判定用情報は、タイムスタンプであり、
   前記管理部は、前記タイムスタンプを現在時刻と比較し、前記タイムスタンプと現在時刻との差が、前記所定タイミングにおいて前記第１のモデルおよび前記第２のモデルの更新に利用されるデータの参照期間以内である場合、前記第１特徴情報を指定した検索要求を検索部に出力する、
   請求項４記載の検索システム。
6. 前記第１情報は、ユーザが閲覧した記事の履歴であり、
   前記第１特徴情報は、前記ユーザの特徴を示す情報であり、
   前記第１の生成部は、前記第１特徴情報をユーザＩＤに対応付けて前記第１の記憶部に記憶させる、
   請求項１記載の検索システム。
7. 前記第２情報は、ネットワークを介して配信される記事であり、
   前記第２特徴情報は、前記記事の特徴を示す情報であり、
   前記第２の生成部は、前記第２特徴情報を記事ＩＤに対応付けて前記第２の記憶部に記憶させ、
   前記第１のモデルは、前記ユーザが閲覧した記事に対応する前記第２特徴情報に基づいて前記第１特徴情報を生成する点で、前記第２のモデルと関連性を有する、
   請求項６記載の検索システム。
8. 第１の生成部が、第１情報を第１のモデルに入力することで第１特徴情報を生成し、第１の記憶部に記憶させ、
   第２の生成部が、第２情報を、前記第１のモデルと関連性を有する第２のモデルに入力することで第２特徴情報を生成し、第２の記憶部に記憶させ、
   検索部が、前記第１特徴情報を用いて前記第２の記憶部を検索し、前記第１特徴情報に関連する第２特徴情報を取得し、
   前記第１の生成部と前記第２の生成部のそれぞれは、使用されるモデルの世代が異なる複数のチャネルを有し、各チャネルで並行して処理を実行し、
   前記複数のチャネルのうち現用系でないチャネルで使用されている前記第１のモデルと前記第２のモデルとが、所定タイミングで新たなモデルに更新される、
   検索方法。
9. 管理部が、前記複数のチャネルから前記現用系のチャネルを選択することを更に含む、
   請求項８記載の検索方法。

Images