AI面接ロボットのバックエンドアーキテクチャの実践

01 はじめに

AI面接ロボットは、Lingxiインテリジェント音声セマンティックプラットフォームの人間とコンピューターの音声対話機能を使用して、採用担当者と求職者の間の複数回の音声コミュニケーションをシミュレートし、オンライン面接の効果を実現します。この記事では、AIインタビューロボットのバックエンドアーキテクチャ構成、対話エンジン設計、リソース需要推定戦略、サービスパフォーマンス最適化方法について詳しく説明します。 AI面接ロボットは発売から1年余りで累計100万件の面接依頼を受けており、採用担当者の採用効率と求職者の面接体験が大きく向上しています。

02 プロジェクトの背景

58.comの生活サービスプラットフォームには、不動産、自動車、求人、地域サービス（イエローページ）の4つの主要な確立されたビジネスが含まれています。このプラットフォームは、多数のCエンドユーザーとBエンドマーチャントを結び付けています。Bエンドマーチャントは、プラットフォームに住宅、自動車、求人、生活サービスなどのさまざまな情報を投稿できます（「投稿」と呼びます）。プラットフォームは、これらの投稿をCエンドユーザーに配信して閲覧し、必要な情報を入手できるようにし、Bエンドマーチャントが情報を配信して発信してターゲット顧客を獲得できるようにします。Bエンドマーチャントがターゲット顧客を獲得する効率を高め、Cエンドユーザーのエクスペリエンスを向上させるために、プラットフォームはパーソナライズされた推奨、インテリジェントな接続などの面で製品を革新し続けています。

採用を例にとると、2020年の流行の影響を受け、従来のオフライン採用面接方法は大きな影響を受けました。プラットフォーム上の求職者からのWeChatチャット、ビデオなどを介したオンライン面接のリクエストが急増しました。採用担当者は同時に1人の求職者としかオンラインビデオ面接チャネルを確立できないため、求職者と採用担当者の接続の成功率は低いです。求職者のユーザーエクスペリエンスを向上させ、採用担当者の面接効率を向上させるために、58.com TEG AI Labと採用事業部門を含む複数の部門が協力して、インテリジェントな採用面接ツール「Magic Interview Room」を開発しました。この製品は主に、クライアント、音声およびビデオ通信、AI面接ロボットの3つの部分で構成されています（参照：人物 | 李中：AI面接ロボットがインテリジェントな採用を実現）。

この記事は主に、Lingxiインテリジェント音声セマンティックプラットフォームの人間とコンピューターの音声対話機能を使用して、採用担当者と求職者の間の複数回の音声コミュニケーションをシミュレートし、オンライン面接の効果を実現するAI面接ロボットに焦点を当てます。一方で、1 人の採用担当者が 1 人の求職者のオンライン面接リクエストにしか対応できないという問題を解決し、採用担当者の作業効率を向上させることができます。他方では、求職者がいつでもどこでもビデオ面接を実施したいというニーズを満たすと同時に、個人の履歴書を従来のテキストによる説明から、より直感的で鮮明なビデオによる自己紹介に変換することができます。この記事では、AI インタビュー ロボットのバックエンド アーキテクチャ、人間とコンピューターの音声対話エンジンの設計、トラフィックの拡大に対応するためのリソース要件の見積もり方法、AI インタビュー ロボット サービス全体の安定性と可用性を確保するためのサービス パフォーマンスの最適化方法について詳しく説明します。

03 AI面接ロボットのバックエンドアーキテクチャ

上図に、AI インタビュー ロボットのアーキテクチャを示します。これには以下が含まれます。

1. アクセス層: 主に上流と下流とのインタラクションの処理に使用され、オーディオおよびビデオ端末との通信プロトコルの合意、面接中のユーザーポートレートの抽出、ロボットとユーザーのインタラクションタイムライン情報の抽出と採用部門への送信などが含まれます。

2. 論理層：主にロボットとユーザーとの対話インタラクションの処理に使用され、ロボットの質問テキストを音声データに合成してユーザーに送信したり、ユーザーに質問してロボットが「話す」ことができるようにしたり、ユーザーが返答した後、VAD（音声アクティビティ検出）を通じてユーザーの返答音声データをセグメント化し、ストリーミング音声認識をテキストに変換してロボットが「聞く」ことができるようにしたり、対話エンジンがユーザーの返答テキストと音声図に基づいて返答内容を決定し、音声を合成してユーザーに送信したりすることで、ロボットとユーザー間の「コミュニケーション」を実現します。

3. データ層: 音声図、会話記録、注釈情報などの基本データを保存します。

4. Web システム: 音声構造、対話戦略を視覚的に構成し、インタビュー対話データに注釈を付けます。

04 AIインタビューロボットとユーザーとのやりとりの全体プロセス

完全な AI 面接プロセスは上の図に示されており、面接前、面接中、面接後の 3 つの段階に分けられます。

インタビュー前：主なタスクは、通信リンクを確立し、リソースを初期化することです。AIインタビューロボットとオーディオおよびビデオ端末間の音声信号は、UDPを介して送信されます。オーディオおよびビデオ端末とAIインタビューロボット間の通信に必要なIPとポートは、動的に維持する必要があります。オーディオとビデオは、SCFを介したインタビューのリクエストを開始しますロードバランスをサポートし、オーディオとビデオエンドによって開始されたインタビューのリクエストは、このマシンのAIインタビューロボットをランダムにヒットします。初期化され、利用可能なポートペアはキューデータ構造に保存されます）。ポート ペアの取得に失敗した場合、サービスは SCF インターフェイスを介してオーディオおよびビデオ エンドに通信失敗コードを返します。オーディオおよびビデオ エンドは、インタビュー要求を再試行するか、放棄することができます。

コミュニケーションプロセスの確立:

音声信号伝送のプロセスでは、システム内のオーディオ メディア プロトコルとして RTP プロトコルを使用します。 RTP プロトコルは、IP ネットワーク上で音声、画像、ファックスなど、リアルタイムで伝送する必要があるさまざまなマルチメディア データに対してエンドツーエンドのリアルタイム伝送サービスを提供するリアルタイム トランスポート プロトコルです。 RTP メッセージは、ヘッダーとペイロードの 2 つの部分で構成されます。

RTP ヘッダー:

属性の説明:

インタビュー中：このプロセスでは、AIインタビューロボットが最初に冒頭陳述を送信します。冒頭陳述のテキストは、tts（Text To Speech）を介して音声データに合成されます。音声データはエンコード、圧縮され、オーディオおよびビデオ端末の合意されたIPとポートに送信されます。ユーザーは、聞いた質問に基づいて適切な応答を行います。AIインタビューロボットは、受信したユーザーの音声ストリームをデコードし、vadセグメンテーションとストリーミング音声認識を通じてテキストに変換します。対話エンジンは、ユーザーの返信テキストと音声構造状態図に基づいて返信内容を決定します。AIインタビューロボットとユーザーは、スピーチが終了するか、ユーザーがインタビューを切るまで、対話と会話を続けます。

面接後：AI面接ロボットは、面接終了に関する音声またはビデオのリクエストを受信すると、面接準備段階で申請されたポートやスレッドなどのリソースを再利用し、ユーザープロファイル（ユーザーの最速到着時間、職務経験の有無、年齢などの情報を含む）を構築して採用担当者に提供し、マーチャントによる審査を容易にするとともに、面接の会話を録音して保存します。

録音プラン：

05 会話エンジンのコア機能

インタビュープロセス全体を通じて、AIインタビューロボットとユーザーとの対話は、音声フローに基づく対話エンジンによって駆動され、音声は有向非巡回グラフです。初期の音声グラフは2分岐音声（すべてのノードのエッジは<= 2）です。その単純な構造のため、ロボットの対話は機械的であり、ユーザーは質問に答える意欲が低く、インタビュー完了率（ロボットが尋ねたすべての質問に答えたユーザーの割合）はわずか20％です。

そこで、ユーザーの会話意欲を高め、ロボットのインテリジェントな会話機能を強化するために、音声構造を再構築し、以下に示すようにマルチブランチ音声（ノードのエッジ> = 3）を設計しました。ユーザーは、年齢、教育、性格に基づいて、さまざまなユーザーの音声に応答できます。新しい音声構造が開始された後、インタビュー完了率は50％を超えました。

同時に、よりきめ細かな対話戦略を設計するために、戦略チェーン上にノードレベルの戦略チェーンを設計しました。これにより、個々のノードのパーソナライズされた対話戦略をカスタマイズして、パーソナライズされた対話のニーズを満たすことができます。

データ レベル: マルチブランチ音声を実装するために、音声関連のデータ構造を再設計し、音声テーブル、音声ノード、音声エッジなどの一部のデータ エンティティを抽象化しました。音声ノードは、音声番号を通じて音声にバインドされ、音声テキストやその他の属性を維持します。音声エッジは、開始ノードと終了ノードを使用して、ノード間のトポロジ関係を維持します。音声エッジは、エッジ番号を通じてこのエッジ上のヒット正規表現、コーパス、およびその他のルールにバインドされ、エッジ ID を使用してこのエッジの独自のルールをカスタマイズできます。ポリシー チェーンはポリシー チェーン番号を通じて異なるポリシーをバインドし、スクリプトとノードはポリシー チェーン番号を通じて異なるポリシー チェーンをバインドします。

コード レベルでは、エッジ、ノード、音声クラス、音声ステータス クラスの概念が抽象化されています。エッジとノードは、データ レイヤーのマッピングです。エッジは、正規表現やコーパスなどのヒット ロジックも保持します。音声クラスは、開始ノードや音声グラフなどの重要な情報を保持します。音声グラフは、音声トポロジ全体のマッピングであり、ノードから始まるノードとエッジ セットのマッピングを維持します。音声ステータス クラスは、音声クラスと現在のノードを含む音声の現在の状態を保持します。システムは、音声の現在のノードに基づいて音声グラフからノードから始まるすべてのエッジを取得し (隣接リストに似ています)、ユーザーの現在の応答に基づいて異なるエッジのルールを一致させることができます。ヒットが見つかった場合、音声グラフはヒット エッジの終了ノードに流れ、ノードからロボットの応答コンテンツが取得され、音声構造が流れ始めます。

ダイアロググラフのデータ構造:

上記のデータ構造により、システム プラットフォームは、カスタマイズされた面接スクリプトに対するビジネス側のニーズに迅速に対応できます。たとえば、採用担当者は、採用ポジションごとに質問をカスタマイズできます。これらの質問を面接スクリプト内の仮想ノードに抽象化し、仮想エッジを使用して仮想ノードを接続することで、さまざまなポジションにパーソナライズされた面接質問を提供し、さまざまな人に合わせて面接スクリプトをカスタマイズする効果を実現します。

06 サービスパフォーマンス最適化の実践

マジックインタビュールームは発売以来効果を上げているため、事業側は規模を急速に拡大したいと考えています。AIインタビューロボットは、同時に1000人以上をオンラインでサポートする必要があります。そのため、リソース管理、リソース推定、パフォーマンステスト、監視の4つの側面から始めました。AIインタビューロボットサービスのパフォーマンスを効果的に向上させました。実際のオンライン使用では、最適化後は最適化前の20倍のインタビューリクエストを同時に処理できます。

リソース管理ソリューション: サービスで使用されるリソースをより適切に管理し、リソースの枯渇を防ぐために、以下に示すリソース管理ソリューションを設計しました。まず、AIインタビューロボットと音声およびビデオは、SCF合意通信プロトコルを介して通信します。SCFは負荷分散されているため、発信者の要求はクラスター内のマシンにランダムにヒットします。たとえば、要求はサービスインスタンス1にヒットします。通信プロトコルは、このインタビューの相互作用をこのインスタンスにバインドできます。次に、セッションの概念が抽象化されます（コードレベルはセッションクラスであり、各セッションはスレッドです）。送受信ポート、コーデッククラス、およびさまざまなスレッドリソースなど、このインタビューで適用されるリソースは、セッションに登録されます。コードは、セッションが解放されると、セッションに登録されたリソースが解放されることを保証します。このように、さまざまなビデオインタビューは、スレッド分離を通じてリソースの分離を実現し、リソース管理を容易にします。

同時に、セッション インスタンスは、セッション ID (通信プロトコルを通じて呼び出し元によって合意され、グローバルに一意) を介してセッション コンテナーにバインドされます。ユーザーが電話を切ると、SCF が呼び出されてリソースが解放されます。SCF のランダム性により、このインタビューに関連するセッションを持たないサービス インスタンス 3 に要求が行われる場合があります。リソースを解放するために、WMB (58.com が独自に開発したメッセージ キュー) を使用してリソース解放メッセージをブロードキャストします。メッセージ本体にはセッション ID が含まれます。すべてのサービス インスタンスがこのメッセージを消費します。サービス インスタンス 1 にはセッション ID が含まれており、セッション ID にバインドされているセッションを見つけて、セッションのリソース解放関数を呼び出して使用済みのリソースを解放します (他のインスタンスはメッセージを破棄します)。

何らかの理由で解放要求が実行されない場合、セッション コンテナにはセッション コンテナ内のすべてのセッションのライフ サイクルをスキャンし、セッションの最大ライフ サイクル (たとえば、10 分) を設定できるセッション監視スレッドがあります。セッションの有効期限が切れると、セッション リソースのリサイクルがアクティブにトリガーされ、セッション リソースが解放されます。同時に、セッションで申請されたスレッドやポートなどの限られたリソースについては、集中管理を採用しています。スレッドプールを使用してスレッドを集中管理し、利用可能なポートをすべてキューに入れ、キュー内の残りのポートを監視することで、サービスの安定性と可用性を確保しています。

マシンリソースの見積もり:

パフォーマンス実験:

上図に示すように、1. システム アーキテクチャを整理し、限られたリソースを見つけ出し、ストレス テスト プランを編成します。2. マルチスレッドを使用してオンライン環境をシミュレートします。3. さまざまな強度の強度テストを実行し、ボトルネック リソースを分析し、サービスを分析します。 4. ボトルネックを特定し、しきい値アラームを上げて再テストします。5. これは、実際のシナリオにおけるサービスの安定性パフォーマンスです。

ストレス テスト: 次に、ストレス テストを実行し、さまざまな要求強度テストを試しました。2500 リクエスト/分を使用してインターフェイスのストレス テストを行ったところ、サービスの主なボトルネックはサービスのヒープ メモリであることがわかりました。下の図から、サービス ヒープ メモリがすぐに 100% に達し、インターフェイスが応答しなくなることがわかります。ヒープメモリをダンプすると、ヒープメモリに数百の DialingInfo オブジェクトがあり、それぞれが 18.75MB を占めていることがわかりました。コードを見ると、このオブジェクトは AI インタビュー ロボットとユーザー間の会話内容を格納するために使用されていることがわかります。2 つのオブジェクト allRobotVoiceBuffer と allUserVoiceBuffer はそれぞれメモリ サイズの半分を占めています。allRobotVoiceBuffer はロボットの音声情報を格納し (格納形式: バイト配列)、allUserVoiceBuffer はユーザーの音声情報を格納します。

コードを見ると、サービスの初期化時に allRobotVoiceBuffer と allUserVoiceBuffer の 2 つのオブジェクトが合計 18.75MB を占めていることがわかります (この値は 5 分間の音声データを保存する必要があるためです)。この初期化サイズが妥当かどうかを検討する必要があります。マジック インタビュー ルームの過去の通話データを分析すると、63% のユーザーがロボットの最初の質問に答えず、直接インタビューを切ったことがわかります。そのため、これら 2 つのオブジェクトの初期化メモリ サイズを削減し、allRobotVoiceBuffer を 0.47MB (この値はロボットの最初の質問の音声のサイズ) に変更し、allUserVoiceBuffer を 0MB に変更しました。同時に、allRobotVoiceBuffer と allUserVoiceBuffer の 2 つのオブジェクトは ms レベルで拡張できるため、会話の内容がオブジェクト サイズを超えた場合は、サービスに影響を与えることなく拡張できます。変更後も、ストレス テストには 2500 分/リクエストを使用し、サービスは安定したガベージ コレクションを実現できます。

きめ細かな監視:

07 結論

この記事では、主にAIインタビューロボットのバックエンドアーキテクチャ、AIインタビューロボットとユーザー間の対話プロセス全体、対話エンジンのコア機能、およびサービスパフォーマンスの最適化の実践について紹介します。 今後も、Magic Interview Roomプロジェクトの機能反復とパフォーマンス最適化をサポートし、AI面接ロボットをさまざまな業務にさらに実装していきます。

参考文献

1. RTP: リアルタイム アプリケーション用のトランスポート プロトコル。H. Schulzrinne、R. Frederick、S. Casner、V. Jacobson

著者について

58.com AI Labのシニアバックエンド開発エンジニアである張志は、2019年12月に58.comに入社し、現在は主に音声インタラクションに関するバックエンドの研究開発に従事しています。 2016年に華北理工大学で修士号を取得し、Convenience BeeとChina Electronicsでバックエンド開発業務に従事しました。