Amazon Comprehend を使用して、ツイートから通信ネットワークのサービス停止を検出して視覚化する

今日の世界では、ソーシャルメディアは、顧客が消費するサービスの体験を共有する場所になっています。すべての通信プロバイダーは、顧客が不満な点をできるだけ早く理解し、頻繁に NOC (ネットワークオペレーションセンター) 内にソーシャルメディアチームを立ち上げることを望んでいます。このチームは、ツイートなどのソーシャルメディアメッセージを手動で確認し、キャリアのネットワークに特定の問題があることをほのめかす顧客の苦情や問題のパターンを特定するよう務めます。

不満を抱いている顧客はプロバイダーを乗り換える可能性が高いため、オペレーターは顧客体験を改善し、サービスの問題を報告している不満足な顧客に積極的にアプローチします。

もちろん、ソーシャルメディアは非常に大規模に運用されており、通信会社のお客様からはソーシャルメディアデータから顧客の問題を手動で明らかにすることは非常に困難であるとの声が伝わってきます。

この記事では、通信会社が Amazon Comprehend のカスタムマルチクラス分類を使用して、サービス停止を特定し、顧客と積極的に関わることができるように、ツイートをリアルタイムで分類する方法を示します。

ソリューションの概要

通信会社の顧客は、サービス停止についてソーシャルメディアに投稿するだけでなく、提供されたサービスについてコメントしたり、競合他社と比較したりしています。

会社は、それらのタイプのツイートを個別にターゲットにすることで有効活用できます。オプションの 1 つに、顧客からフィードバックをもらうことがあります。これを受けて、カスタマーサービスが顧客に対応することができます。サービス停止の場合、エンジニアが問題を特定できるように、情報を収集して外部システムでチケットを切る必要があります。

この記事のソリューションは、AI 主導型ソーシャルメディアダッシュボードソリューションを拡張したものです。次の図は、ソリューションのアーキテクチャを示しています。

AI 主導型ソーシャルメディアダッシュボードソリューションの実装アーキテクチャ

このソリューションでは、Amazon Virtual Private Cloud (Amazon VPC) で実行される Amazon Elastic Compute Cloud (Amazon EC2) インスタンスをデプロイし、Twitter からツイートを取り込みます。Amazon Kinesis Data Firehose 配信ストリームは、ソリューションの Amazon Simple Storage Service (Amazon S3) バケットの raw プレフィックスにストリーミングツイートをロードします。Amazon S3 は AWS Lambda 関数を呼び出して、Amazon Translate を使用して生のツイートを分析し、英語以外のツイートを英語に翻訳します。そして Amazon Comprehend を呼び出して自然言語処理 (NLP) を行い、エンティティの抽出と感情分析を実行します。

2 番目の Kinesis Data Firehose 配信ストリームは、翻訳されたツイートと感情の値を Amazon S3 バケットの sentiment プレフィックスにロードします。3 番目の配信ストリームは、Amazon S3 バケットで使用する entities プレフィックスの entities をロードします。

このソリューションでは、データ変換用の AWS Glue、データ分析用の Amazon Athena、データ視覚化用の Amazon QuickSight を含むデータレイクもデプロイします。AWS Glue データカタログには、Amazon S3 上のデータのテーブルを整理するために使用する論理データベースが含まれています。Athena はこのようなテーブル定義を使用して、Amazon S3 に保存されているデータをクエリし、その情報を Amazon QuickSight ダッシュボードに返します。

このソリューションを拡張するには、Amazon Comprehend カスタム分類を構築して、サービス停止、顧客フィードバック、競合他社との比較を検出します。

データセットを作成する

ソリューションはツイートの生データを使用します。元のソリューションでは、ソリューションがモニタリングする用語のコンマ区切りのリストを定義する AWS CloudFormation テンプレートをデプロイします。例として、この記事は「BT」 (英国の BT Group) という単語を含むツイートに焦点を当てていますが、どのネットワークプロバイダーでも構いません。

はじめに、AI 主導型ソーシャルメディアダッシュボードソリューションを起動します。[スタックの詳細を指定] ページで、デフォルトの TwitterTermList を自分の用語に置き換えます。この例では、「BT」、「bt」がそれに当たります。[スタックの作成] をクリックした後、デプロイが完了するまで 15 分待ちます。ツイートのキャプチャを開始します。

使用できる属性とデータ型の詳細については、「付録 B: 自動生成されたデータモデル」を参照してください。

ツイートデータは Amazon Simple Storage Service (Amazon S3) に保存され、Amazon Athena でクエリできます。次のスクリーンショットは、クエリの例を示しています。

SELECT id,text FROM "ai_driven_social_media_dashboard"."tweets" limit 10;

キーワード BT または bt を含むすべてのツイートをキャプチャしたため、British Telecom についてのツイートではないツイートがたくさんあります。たとえば、「but」という単語のつづりが間違っているツイートなどです。

さらに、データセット内のツイートはグローバルですが、ツイートが British Telecom についてのツイートである可能性が高くなるようにこの記事では英国に焦点を当てたいと思います (それにより、データセットはより正確になります)。たとえば、キーワードを KPN として定義し、データセットを絞り込んでオランダのみに焦点を合わせるなど、他の国でのユースケースに合わせてこのソリューションを応用できます。

既存のソリューションでは、coordinates と geo タイプが関連しているように見えますが、通常はこれらは入力されていません。プライバシー要件により、ツイートには投稿者の位置はデフォルトでは含まれていないのです (ユーザーが許可した場合は除きます)。

user タイプには、ユーザープロファイルから取得した関連するユーザーデータが含まれています。ユーザープロファイルの位置データを使用して、ツイートを対象の国または地域に絞り込むことができます。

user タイプを確認するには、Athena CREATE TABLE AS SELECT (CTAS) クエリを使用できます。詳細については、「クエリ結果からのテーブルの作成 (CTAS) 」を参照してください。次のスクリーンショットは、[作成] ドロップダウンメニューの [クエリからテーブルを作成] オプションを示しています。

ツイートからテキスト、user.location を選択します

ツイートのテキストとユーザーの位置で構成されるテーブルを作成できます。これにより、英国から発信されたツイートのみを表示できます。次のスクリーンショットは、クエリ結果を示しています。

SELECT * FROM "ai_driven_social_media_dashboard"."location_text_02"
WHERE location like '%UK%' or location like '%England%' or location like '%Scotland%' or location like '%Wales%'

ターゲットの位置とツイートのキーワードを含むデータセットができたので、カスタム分類子をトレーニングできます。

Amazon Comprehend カスタム分類

モデルはマルチクラスモードでトレーニングします。この記事では、次の 3 つの異なるクラスにラベルを付けます。

サービス停止 – プロバイダーネットワークでサービス停止を経験または報告している人
顧客フィードバック – プロバイダーから受け取ったサービスに関するフィードバック
競争 – 競争とプロバイダー自体に関するツイート

Athena からデータセットをエクスポートしてトレーニングすることで、カスタム分類子を使用できます。

最初にデータセットを見て、さまざまなツイートにラベルを付けます。ツイートの数が多いため、データを確認してラベルを付けるのに手間がかかり、数時間要する場合もあるかもしれません。ラベルごとに少なくとも 50 のドキュメントでモデルをトレーニングすることをお勧めします。

データセットでは、顧客からサービス停止が報告され、outage ラベルが付いた 71 個のドキュメントが生成されました。競争と顧客フィードバックは 50 ラベル以下でした。

十分なデータを収集した後、新しいモデルをトレーニングすることにより、常に精度を向上させることができます。

次のスクリーンショットは、最終的なトレーニング CSV ファイルのエントリーの一部を示しています。

ツイートにラベルを付ける手作業を取り除く将来の機能拡張として、Amazon SageMaker Ground Truth を使用してプロセスを自動化できます。Ground Truth は、Amazon Mechanical Turk を介してラベラーに簡単にアクセスできるようにし、一般的なラベリングタスク用の組み込みのワークフローとインターフェイスを提供します。

ラベル付け作業が完了したら、CSV ファイルを S3 バケットにアップロードします。

トレーニングデータが Amazon S3 にあるので、カスタム分類子をトレーニングできます。次の手順を実行します。

Amazon Comprehend コンソールで、[Custom classification] を選択します。
[Train classifier] を選択します。
[Name] には、分類子の名前を入力します。たとえば、「TweetsBT」などです。
[Classifier mode] では、[Using multi-class mode] を選択します。
[S3 location] には、CSV ファイルの場所を入力します。
[Train classifier] を選択します。

分類子のステータスが Submitted から Training に変わります。ジョブが完了すると、ステータスが Trained に変わります。

カスタム分類子をトレーニングした後、非同期または同期操作でドキュメントを分析できます。非同期操作を使用すると、多数のドキュメントを同時に分析できます。結果の分析は別のファイルで返されます。同期操作を使用すると、1 つのドキュメントしか分析できませんが、リアルタイムで結果を得ることができます。

このユースケースでは、ツイートをリアルタイムで分析することにします。ツイートが Amazon Kinesis Data Firehose を介して Amazon S3 に到達すると、AWS Lambda 関数がトリガーされます。この関数は、カスタム分類子エンドポイントをトリガーしてツイートの分析を実行し、それがサービス停止、顧客フィードバック、または競合他社に関するものかどうかを判断します。

トレーニングデータのテスト

モデルをトレーニングした後、Amazon Comprehend はトレーニングドキュメントの約 10％を使用してカスタム分類子モデルをテストします。モデルをテストすると、モデルが目的のために十分にトレーニングされているかどうかを判断するために使用できるメトリクスが得られます。このメトリクスは、Amazon Comprehend コンソールの [Classifier details] ページの [Classifier performance] セクションに表示されます。次のスクリーンショットを参照してください。

メトリクスは、DescribeDocumentClassifier 操作によって返される [Metrics] フィールドにも返されます。

エンドポイントを作成する

エンドポイントを作成するには、以下の手順を実行します。

Amazon Comprehend コンソールで、[Custom classification] を選択します。
[Actions] ドロップダウンメニューから、[Create endpoint] を選択します。
[Endpoint name] には、名前を入力します。たとえば、「BTtweetsEndpoint」などです。
[Inference units] には、エンドポイントに割り当てる番号を入力します。

各ユニットは、1 秒あたり最大 2 つのドキュメントに対して 1 秒あたり 100 文字のスループットを表します。エンドポイントごとに最大 10 の推論ユニットを割り当てることができます。この記事では 1 を割り当てます。

[Create endpoint] を選択します。

エンドポイントの準備ができると、ステータスが Ready に変わります。

エンドポイントのトリガーと既存の Lambda 関数のカスタマイズ

元のソリューションの既存の Lambda 関数を使用して、次のことを行うように拡張できます。

ツイートごとに Amazon Comprehend カスタム分類子エンドポイントをトリガーする
信頼スコアが最も高いクラスを特定する
追加の Firehose 配信ストリームを作成して、結果が Amazon S3 に戻るようにする

元の Lambda 関数の詳細については、GitHub リポジトリを参照してください。

関数に必要な変更を加えるには、以下の手順を実行します。

Lambda コンソールで、文字列 Tweet-SocialMediaAnalyticsLambda を含む関数を選択します。

コードを追加し始める前に、関数が着信するツイートを読み取り、Amazon Comprehend API を呼び出し、応答を Firehose 配信ストリームに格納して Amazon S3 にデータを書き込めるようにする方法を確実に理解しましょう。

カスタム分類子エンドポイントを呼び出します (次のコード例を参照)。

最初の 2 つの呼び出しでは、ツイートテキストの API を使用して感情とエンティティを検出します。これらは両方とも、公式のソリューションで最初からすぐに使えます。

次のコードは、ClassifyDocument API を使用しています。

 sentiment_response = comprehend.detect_sentiment(
                    Text=comprehend_text,
                    LanguageCode='en'
                )
            #print(sentiment_response)
            
            entities_response = comprehend.detect_entities(
                    Text=comprehend_text,
                    LanguageCode='en'
                )
                
            #we will create a 'custom_response' using the ClassifyDocument API call
            custom_response = comprehend.classify_document(
                     #point to the relevant Custom classifier endpoint ARN
                     EndpointArn= "arn:aws:comprehend:us-east-1:12xxxxxxx91:document-classifier-endpoint/BTtweets-endpoint",
                     #this is where we use comprehend_text which is the original tweet text
                     Text=comprehend_text
                   
                )

次のコードは、返された結果です。

{"File": "all_tweets.csv", "Line": "23", "Classes": [{"Name": "outage", "Score": 0.9985}, {"Name": "Competition", "Score": 0.0005}, {"Name": "Customer feedback", "Score": 0.0005}]}

次に、クラスと信頼スコアを含む配列を反復処理する必要があります。詳細については、「DocumentClass」を参照してください。

マルチクラスアプローチを使用しているため、最高のスコアを持つクラスを選択し、配列を反復処理して最大のスコアとクラスを取得する単純なコードを追加できます。

また、tweet[‘id’] も取得します。これは、ソリューションが生成する他のテーブルと結合して、結果を元のツイートに関連付けることができるためです。

次のコードを入力します。

score=0
        for classs in custom_response['Classes']:
         if score<classs['Score']:
             score=classs['Score']
             custom_record = {
                
                'tweetid': tweet['id'],
                'classname':classs['Name'],
                'classscore':classs['Score']
             }

custom_record を作成したら、クラススコア (Amazon S3 に保存する結果の信頼度) に特定のしきい値を定義するかどうかを決定できます。この使用例では、少なくとも 70％の信頼スコアを持つクラスのみを定義することを選択します。

結果を Firehose 配信ストリーム (事前に作成する必要) に配置するには、PutRecord API を使用します。次のコードを参照してください。

if custom_record['classscore']>0.7:
         print('we are in')
         response = firehose.put_record(
                        DeliveryStreamName=os.environ['CUSTOM_STREAM'],
                        Record={
                            'Data': json.dumps(custom_record) + '\n'
                        }
                    )

これで、Amazon Comprehend カスタム分類子出力に基づいて、Amazon S3 にデータセットが作成されました。

出力の探求

これで、Athena のカスタム分類子からの出力を探求できます。次の手順を実行します。

Athena コンソールで、SELECT クエリを実行して以下を確認します。
1. tweetid – これを使用して元のツイートテーブルを結合し、ツイートテキストと追加の属性を取得できます。
2. classname – これは、カスタム分類子が最高レベルの信頼度を持ったツイートであると識別したクラスです。
3. classscore – これは信頼度です。
4. Stream partitions – これは、データが Amazon S3 に書き込まれた時間を知るのに役立ちます。
  1. Partition_0 (月)
  2. Partition_1 (日)
  3. Partition_2 (時間)

次のスクリーンショットは、クエリの結果を示しています。

SELECT * FROM "ai_driven_social_media_dashboard"."custom2020" where classscore>0.7 limit 10;

次のように tweetid を使用してテーブルを結合します。
1. 実際のツイートテキストを取得する元のツイートテーブル。
2. Amazon Comprehend が元のソリューションで生成した感情テーブル。

次のスクリーンショットは、結果を示しています。ツイートの 1 つには否定的なフィードバックが含まれ、他のツイートからは潜在的なサービス停止があったことが分かります。

SELECT classname,classscore,tweets.text,sentiment FROM "ai_driven_social_media_dashboard"."custom2020"
left outer join tweets on custom2020.tweetid=tweets.id 
left outer join tweet_sentiments on custom2020.tweetid=tweet_sentiments.tweetid
where classscore>0.7 
limit 10;

視覚化のためのデータの準備

データの視覚化の準備を行うには、まずパーティションフィールドを連結して timestamp フィールドを作成します。

timestamp フィールドは、特定の期間のサービス停止や特定の日の顧客フィードバックなど、さまざまな視覚化に用いることができます。そのためには、AWS Glue ノートブックを使用して、PySpark でコードを記述します。

PySpark コードを使用して、データを準備するだけでなく、データを CSV から Apache Parquet 形式に変換することもできます。詳細については、GitHub リポジトリをご覧ください。

これで、Parquet 形式の timestamp フィールドを含む新しいデータセットが作成されるはずです。これにより、クエリの効率とコスト効率が向上します。

このユースケースでは、Amazon QuickSight の geospacial charts を使用して、地図上で報告されたサービス停止を判別できます。ツイートの位置を取得するには、以下を使用できます。

元の tweets データセットの経度と緯度の座標。残念ながら、プライバシーのデフォルト設定のため、座標はないのが通常です。
Amazon Comprehend entity データセット。これは、位置をツイートテキスト内のエンティティとして識別できます。

このユースケースでは、tweets、custom2020 (カスタム分類子出力に基づく新しいデータセット)、および tweetsEntities データセットを組み合わせた新しいデータセットを作成できます。

次のスクリーンショットは、クエリ結果を示しています。クエリ結果は、位置を含むツイートを返し、サービス停止も特定しています。

SELECT distinct classname,final,text,entity FROM "ai_driven_social_media_dashb
oard"."custom2020"."quicksight_with_lat_lang"
where type='LOCATION' and classname='outage'
order by final asc

特定のウィンドウでサービス停止を特定し、その位置を判別しました。

特定の場所の地理位置情報を取得するには、公開されているさまざまなデータセットから選択して Amazon S3 にアップロードし、データと結合できます。この記事では、無料オプションがある World Cities Database を使用しています。これを既存のデータと結合して、位置座標を取得できます。

Amazon QuickSight でサービス停止場所を視覚化する

Amazon QuickSight で停止場所を視覚化するには、次の手順を実行します。

Athena で作成したデータセットを追加するには、Amazon QuickSight コンソールで、[データの管理] を選択します。
[新しいデータセット] を選択します。
[Athena] を選択します。
データベースまたはテーブルを選択します。
[保存して視覚化] を選択します。
[ビジュアルタイプ] では、[地図上のポイント] を選択します
lng および lat フィールドをフィールドウェルにドラッグします。

次のスクリーンショットは、英国の地図上でサービス停止場所を示したものです。

特定のツイートのテキストを表示するには、地図上のドットの 1 つにカーソルを合わせます。

データの分析にはさまざまなオプションがあり、このソリューションをさらに強化できます。たとえば、潜在的な貢献者でデータセットを充実させ、特定のサービス停止場所を深掘りして詳細を調べることができます。

まとめ

これで、顧客が報告しているサービス停止を検出できるようになりました。また、ソリューションを活用して、顧客フィードバックや競争を調べることもできます。そしてソーシャルメディアの主要なトレンドを大規模に特定できるようになりました。このブログ記事では、通信会社に関連する例を示しましたが、このソリューションは、ソーシャルメディアを使用する顧客がいるどの会社でもカスタマイズして活用できます。

近い将来、このソリューションを拡張して、エンドツーエンドのフローを作成したいと考えています。このフローでは、顧客がサービス停止を報告すると、Amazon Lex チャットボットからツイーターで自動的に返信を受け取ります。安全なチャネルを介して苦情を申し立てた顧客に詳細情報を要求し、この情報を Amazon Connect と統合することでコールセンターエージェントに送信するか、外部チケットシステムでチケットを作成してエンジニアが問題に対処できるようにします。

ソリューションを試して、さらに拡張できるかどうかをご確認ください。コメント欄にフィードバックやご質問をお寄せください。

著者について

Guy Ben-Baruch は、AWS UKIR のニュース & コミュニケーションチームのシニアソリューションアーキテクトです。Guy は 2016 年 3 月に AWS に入社して以来、企業顧客と緊密に連携し、通信業界に焦点を当て、企業のデジタル変革とクラウドの採用をサポートしてきました。仕事以外では、天気がいい日にバーベキューをしたり、公園で子供たちとサッカーをしたりするのが好きです。

Amazon Web Services ブログ