ISIDのAI特化プロジェクトチーム「AITC」が語る AI検索システムの検討事項、PoCを次に繋ぐプロトタイプ開発

アーカイブ動画

AI検索システムのゴールはユーザーの意図を理解すること

株式会社電通国際情報サービス　
Xイノベーション本部　AIトランスフォーメーションセンター部　
データサイエンティスト　ファイサル・ハディプトラ氏

最初に登壇したのは、ISID XI本部 AITCに所属するファイサル氏。2015年にISIDに新卒で入社し、現在はAITCで日々AI製品開発や研究開発に従事している。

検索システムといえば、多くの人はGoogle検索をイメージするだろう。「他の検索システムを使うときでも、Googleでできることを期待してしまう」と、ファイサル氏は指摘する。Googleの検索には次の6つの特長がある。

ドメインの理解：クエリ内の単語が指定する概念を理解している
文脈とユーザー理解：ユーザーの好みとプロフィールを基に検索結果を出す
対話型：自然言語を理解し、前に検索した内容考慮する
マルチモーダル：テキストに限らず、音声や画像や映像などにも対応する
知能的：誤字や自動補完機能など、繰り返し使うことで自己改善する
支援型：検索以上に自動的に適切なアクションを実行する

「これらの機能を実現するためにはAI技術が必要です。このAIを活用する検索システムをAI搭載検索システムと呼んでいます」（ファイサル氏）

AIには機械学習や深層学習など、様々な手法がある。それぞれのレイヤーで何の技術が検索システムに適用できるのかを表したのが次の図だ。

例えばルールベースAIは、質問応答システムやバーチャルアシスタント、チャットボットなどは検索システムに適用できる。機械学習は協調フィルターリングやランキング学習など。最近話題になっている深層学習はニューラル検索やベクトル検索、画像/音声検索（マルチモーダル）などに適用できる。

コンテンツの理解・ユーザーの理解・ドメインの理解で手法を考える

AI搭載検索システムによる検索のゴールは、ユーザーの意図を理解することだとファイサル氏は語る。ユーザー理解とは入力したキーワードに限らない。検索するときにユーザーが頭の中で探したいと思ったものを理解することである。

ユーザーの意図を理解するためには「コンテンツの理解」「ユーザーの理解」「ドメインの理解」という3つの要素に分けて考えることが必要になる。

コンテンツの理解については、従来の検索システムにも搭載されているキーワード検索でも考慮されている。キーワード検索とは検索対象文書を処理し、転置インデックスというデータ構造に変換すること。転置インデックスは単語とその単語を含む文書たちの一覧をテーブル形式で管理することである。

転置インデックスがあれば、ユーザーがクエリを投げたときに単語に分けて、その単語を含む文書をフィルターリングし、検索結果を順番に表示する。ちなみに順番は関連度計算が必要となり、その手法として「BM25」がよく使われている。

だが、「キーワードだけでは求められる結果が得られないケースが多い」とファイサル氏は指摘する。例えば「iPad」をキーワード検索しても、結果として表示されるのは、iPadのアクセサリがずらりと並ぶケースも珍しくない。

そこで必要になるのが、「推薦システム」である。推薦システムとは、ユーザーがクエリを入力せずとも、システム側がユーザーの求めるものを示すシステムで、これを実現するのが、協調フィルターリングという技術だ。協調フィルターリングは、以下の図のようなシステム改善ループが必要となる。

eコマースでは、商品情報をクリックや購入などを操作ログとして記録する。クエリログと操作ログをもとに協調フィルターリングを適用することで、ユーザーとアイテムの関連度を計算する。そして関連度から、ユーザーにお勧めの商品を推薦していく。

「協調フィルターリングを使うことで、ユーザーの挙動から、ユーザーの好みを定量化するところがポイントです」（ファイサル氏）

協調フィルターリングではユーザーとアイテムの関連度だけではなく、アイテムとアイテムの関連度、クエリとアイテムの関連度も計算できる。このユーザー理解とコンテンツ理解を組み合わせると、パーソナライズド検索が実現する。

パーソナライズド検索はユーザーの操作ログを利用して、ユーザーの好みを考慮しながら検索結果を向上する。だが、すべてのクエリに協調フィルターリングを適用しすぎると、関連のないものも出てくる。そこで必要になるのがドメイン知識だ。

ドメイン知識を理解するために使えるのが、ナレッジグラフである。検索システムにおけるナレッジグラフとは、検索キーワードに関連のある情報を検索結果の画面上にまとめて表示する機能を指す。

5つのナレッジモデルで構成される。一番低いレベルのナレッジモデルは言い換え。完全に同一意味を表現する単語で、例えばチョコレートとチョコ、国際連合と国連などがある。次のモデルは同義語・類義語のリスト。近い意味を表現する単語で、人間と人、食べ物と食材など。第三のモデルは階層的なカテゴリーに分類するタクソノミー（分類体系）。そして、ナレッジグラフはオントロジーをインスタンス化したものである。つまり、ナレッジグラフは他のナレッジモデルを含んでいるのだ。

ナレッジグラフを使う良さは、「Stringsではなく、Things（モノ）で検索すること」だとファイサル氏は語る。例えば「日本」で検索すると国として認識し、首都や人口の情報を返してくれる。しかもナレッジグラフは構造データなのでリンクが張られており、そのまま深掘りすることもできる。

このナレッジグラフと協調フィルターリングを組み合わせると、「マルチモーダル推薦」というナレッジグラフデータとユーザー操作ログを跨いで推薦するシステムが実現する。またナレッジグラフとキーワード検索を組み合わせると、セマンテック検索が実現する。

セマンテック検索はクエリの単語からエンティティと関係を認識して検索する。例えば「ISID近くの中華」というクエリを投げたときに、ISIDは会社、近くは距離、中華は中華レストランとの概念として認識される。

最近話題になったベクトル検索は、BERTなどの事前学習言語モデルを利用してクエリと文書をベクトル空間に変換するという手法を用いる。

「キーワード検索やナレッジグラフとは違い、文脈で潜在的な意味を取得できます」（ファイサル氏）

コンテンツ理解をベクトル検索にすると文書ベクトルが、ユーザーの理解をベクトル検索にするとユーザーベクトルが、ナレッジグラフをベクトル検索にするとエンティティベクトルが取得できるが、ベクトル検索は要素ではなく転置インデックスの代替手法で、埋め込み表現やハイブリッドなどの手法がある。

AI検索システムで大事になるのは、「検索対象データによる組み合わせ方」とファイサル氏は指摘する。例えばニュース検索は人気（ユーザーの理解）と新規性（ドメインの理解）が重要となる。レストラン検索だと位置情報や予算（価格帯）なのでドメイン情報を考慮する。eコマースだと購入頻度なので、ユーザー理解が欠かせない。このようにそれぞれのシステムに合わせて組み合わせることが重要になるというわけだ。

コンテンツ＋ドメイン＋ユーザーの理解を組み合わせる方法としては、検索エンジンスコア（コンテンツ）、ナレッジグラフ（ドメイン理解）、文書ベクトル類似度（コンテンツ理解）ユーザーの好み（ユーザーの理解）という各要素の重み付けを行い、最終的スコアとして計算する。

「重みは試行錯誤で決めることが多いが、大量のデータから学習することもできる、それがLearning to Rank（LTR）です」（ファイサル氏）

LTRはユーザー操作ログから教師データを作成して、その教師データを基にそれぞれの特徴量の重みを学習する。その後で初期の結果から再ランクして適応していくというものだ。

段階的に各技術要素を導入するためのロードマップ

ここまで要素技術について解説してきたが、これらの要素技術を一気に導入するのは難しい。そこでファイサル氏が紹介したのは、段階的に導入するというロードマップ案である。

ステップ1：キーワード検索をきちんと固める
ステップ2：インデックシングパイプラインとクエリパイプラインを機能強化
ステップ3：クエリを分類して、それぞれ適切なパイプラインに渡す
ステップ4：ユーザーの操作ログを収集・活用して自己改善ループを実現する

これらのロードマップに従い、各技術要素を搭載した製品をISIDでは開発している。それが「TexAIntelligence（テクサインテリジェンス）」である。同製品は「意味的類似検索」「文章自動分類」「文章要約」という3つの機能を提供している。

AIのPoCを次につなげるためにはプロトタイプが有効

株式会社電通国際情報サービス　
Xイノベーション本部　AIトランスフォーメーションセンター部　
データサイエンティスト　後藤勇輝氏

続いて登壇した後藤氏は、ファイサル氏と同じくISID XI本部 AITCで、機械学習システムの開発・導入、自社のAIソフトウェアの開発など、AzureによるAI関連の研究開発に携わっている。セッションでは、PoCの先に進むために、AI機能を含むアプリケーションのプロトタイプを効率良く開発する方法の紹介を行った。

AIのPoCからシステム導入は増えているものの、とんとん拍子には進まないことが多い。「なぜならAIは不確実性が伴うため」と、後藤氏は語る。顧客の視点に立つと、不確実性が伴うモノを運用に踏み切ることは難しいからだ。

「お客さまの業務に適用する不安を解消するために、具体的な運用イメージを持ってもらうためのプロトタイプを開発しています」（後藤氏）

これまでのプロトタイプ開発環境の多くは、状況に応じてチームにある技術スタックを活用していた。AIモデルの開発部分はノートブックのAIモデルを開発し、要件によってはWeb上にデプロイする必要があるので、そのときはAzure上でバーチャルマシンを立てて、Dockerコンポーネントを活用した開発するという形態を取っていた。

だがこの方法には問題があった。それは「やることが多くて時間がかかること」だ。モデル開発に工数がかかるだけではない。「モデル開発はいろいろ考慮しなければならないことがある」と、後藤氏は指摘する。

例えば、データの準備や管理、モデルを学習するためのコードや推論するコードの記述、モデルを管理するパラメータ管理なども必要となる。バックエンド開発でも推論環境の準備や、ユーザーからのフィードバックなども想定しなければならない。だが、これらを実現しようとするとどうしても時間がかかってしまう。

要素技術も多く、複雑であることも問題だった。モデル開発部分ではPyTorchなどの機械学習ライブラリの知識、バックエンド開発だとPythonのアプリケーションフレームワーク（Django）の知識、フロントエンドはJavaScriptのフレームワーク（Nuxt.js）の知識、さらに、クラウドの知識が必要になる。

「要素技術が複雑になれば、バグが増えやすくなる。属人化も増えて変更が困難となり、機動力のある開発を妨げます」（後藤氏）

プロトタイプを素早く効率的に開発するために必要な要素

プロトタイプは素早く作成し、ユーザーに対する価値を検証することが重要になる。効率的にプロトタイプを作るためのポイントは次の3つ。これらに共通するのは本質的なコードに集中し、コードを書く時間を増やすことである。

開発からデプロイまでのAI/CD基盤の整備
使用する技術要素の削減
PaaSを活用する

まず開発からデプロイまでのCI/CD基盤については、GitHubとGitHub Actionsを使って、Azureにアップロードする。「素早くデプロイするには欠かせない」と後藤氏は語る。

プロトタイプ開発におけるCI/CDの役割は大きく2つある。１つは最低限のコード品質を担保すること。品質をある程度担保することで、結果的に開発スピードが上がり、効率がよくなるからだ。もう1つは、デプロイ作業の自動化ができること。普通にVMに対してデプロイすると時間がかかってしまうので、フィードバックをコードに反映し、素早く変更を確認するためである。

「このようなCI/CD環境を構築することで、開発者が変更を行いやすく、素早く確認できるので、全体的なスピードが上がります」（後藤氏）

現在チームで利用しているCI構成にも3つのポイントがある。1つは、依存関係の解決にはPoetryを使用していること。Poetryはローカルで依存関係を自動追記されるという強みがあるからだ。

「これによりミスを減らして効率化できる」と後藤氏。しかもPoetryならpipより強力な依存関係の解決ができ、開発用パッケージを別で管理できる。「ここもPoetryを使うメリットだと思います」（後藤氏）

2つ目のポイントはコードチェック。ここにはPysenを使っているという。PysenはPreferred Network社が開発したPythonのlinter/formatterツール。Pysenはisortやblackなどのツールを1コードで実行できるため、CLIを覚える必要がない。しかもCIのyamlの記述量も減るので書きやすい。さらに、pyproject.tomlに設定を集約でき、設定ファイルが散らからないなどのメリットも得られる。

ここで「エディター設定にもこだわる」という小ネタが紹介された。エディター設定で開発効率が変わるからだ。

「私たちはVSCodeを使っています。VSCodeで保存時にコードの自動整形や型チェック、インポートのソート順整形を行うなど、CIで指摘される内容と同等。わざわざCIをプッシュして開発中に回さなくても、ある程度のコード品質は担保できることになります」（後藤氏）

2つ目のポイントは、使用する技術要素の削減。ここで後藤氏は、過去の失敗例を紹介。Dockerのフロントエンドのフレームワーク、非同期処理を行うライブラリなど、とりあえず使えそうな技術要素を取り入れて使っていたところ、「使い方を覚えるのが大変」「新しく人をアサインしづらい」「準備や開発に時間がかかる」という問題が発生した。

そこで思い切って、必要最低限なシンプルな構成に改善。新しい構成はフロントエンドにフレームワークを使わずに、Django templateで解決、バックエンドはDjango、非同期処理はPythonのsubprocessもしくはAzure Machine Learningを使って解決している。アプリの起動、デプロイ時間が短縮されたなどのメリットが得られた。

3つ目のポイントはPaaSの活用だ。PaaSとはアプリケーション開発に必要なものがすべて構築済みのサービスである。IaaSと比較すると、OSやアプリケーション実行環境の管理が要らなくなるので、純粋にアプリケーション開発に集中できるようになる。

後藤氏たちが使ったPaaSサービスは、「Azure App Service」。Webアプリケーションを簡単にホストでき、WebアプリケーションをVMの管理なく簡単にデプロイできる。自動スケールに対応し、豊富なデプロイ方法がサポートされている。

選んだ理由は大きく3つ。まずは「デプロイまでが素早く簡単に構築できる」こと。次に「Easy/Authで簡単ログイン」が可能なこと。社内ユーザーだけがアクセス可能なアプリを簡単に実現でき、しかもアプリケーション側で追加のコードは必要ない。そして、「App Service Planに収まる範囲なら複数のアプリをデプロイできる」こともプロトタイプには向いている。

機械学習関連は、Azure Machine Learningを活用。機械学習ライフサイクル全体をサポートするマネージドサービスだ。学習用データの管理、学習済みモデルの管理、実験管理、柔軟な計算リソース調達、推論エンドポイントの作成など、機能も多い。AutoMLや説明性、公平性の表示など多数の機能が提供されている。

「再びの小ネタ」として後藤氏が紹介したのは、より簡単にプロトタイプが使えるようになるという「Cognitive Serviceの利用」である。また簡易なデモで十分な場合は「Mercury」がお勧めされた。Mercuryではライブラリ特有の記法が少なく、モデル開発用ノートブックに少し追記するだけでデモができるからだ。

新しいプロトタイプ開発方法を導入して良かったこととして、後藤氏は「CI/CD基盤やローカル開発環境を見直す機会となったこと」を挙げている。今回、使用したCI/CDワークフローや開発環境設定は他のプロジェクトでも活用されており、開発効率化も実現しているからだ。また、PaaSの便利さも実感したという。

「機械学習系のシステムではPaaSを活用するのは一つの手だと思います」（後藤氏）

一方、課題になっていることとして後藤氏が挙げたのは、「PaaSはIaaSとは異なり、問題が起きたときに原因を調べるのが難しいこと」。ドキュメントをよく読み理解する必要がある。もう1つは、AIエンジニアはどうしてもバックエンドの能力が偏りがちなため、「フロントエンドの知見が不足」してしまうことだ。

PoCの先に進むためには具体的な業務イメージを想起できるプロトタイプが有効であることは間違いない。そのためには、「本質的なコードを書く時間をいかに増やすかが重要になる」と後藤氏はまとめ、セッションを締めた。