新ソリューションアクセラレータ：顧客エンティティ解決

[New Solution Accelerator: Customer Entity Resolution \- Databricks Blog](https://databricks.com/blog/2022/08/04/new-solution-accelerator-customer-entity-resolution.html)の翻訳です。

:::note warn
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
:::

# Zinggを用いたMLベースのCustomer360の構築

> 詳細を確認しノートブックをダウンロードするには、[顧客エンティティ解決のソリューションアクセラレータ](https://d1r5llqwmkrl74.cloudfront.net/notebooks/nightly/RCG/Customer_ER/index.html#Customer_ER_1.html)をチェックしてみてください。

今では、多くの顧客が自分の購買体験の中でパーソナライズされたインタラクションを期待しています。アプリの中でブラウズしたり、電子メールによるオファーを受け取ったり、オンライン広告で追跡されたりしているなかで、彼等自身のニーズを認識し、それに応じてエンゲージメントを仕立て上げるブランドをより多くの人々が期待しています。実際、[顧客の76%](https://www.mckinsey.com/business-functions/growth-marketing-and-sales/our-insights/the-value-of-getting-personalization-right-or-wrong-is-multiplying)はパーソナライズをするブランドから購入する可能性が高いと言われています。そして、企業がオムニチャネルの素晴らしさを追求することで、これらと同等の高い期待値は、デジタルによって支援された従業員とのインタラクションによる店舗内体験、特定の対面サービスなどの提供にまで拡張されています。購買者が選択する時代においては、顧客の消費を惹きつけ、維持するためには、パーソナライズされたエンゲージメントが重要になっているというメッセージを、これまで以上に小売業者は受け取っています。

適切にパーソナライズされたインタラクションを行う鍵となるのは、顧客に関して収集可能なすべての情報からアクション可能な洞察を導き出すことです。セールストランザクション、ウェブサイトの閲覧、商品のレーティングと調査、顧客調査やサポートセンターへの連絡を通じて生成されるファーストパーティデータ、データ収集者やオンライントラッカーから購入されるサードパーティデータ、そして、顧客自身から提供されるゼロパーティデータでさえも、顧客の360度のビューを形成するためにまとめ上げられます。Customer-360に関する議論は、企業が取り扱うべきデータのボリュームや種類、よく適用されるデータサイエンスのユースケースにフォーカスする傾向がありますが、現実のCustomer-360は、分散するデータセットにある顧客のレコードをリンクさせる共通の顧客IDを確立しない限り実現できません。

# 顧客レコードのマッチングは困難です

表面的には、システムをお横断する共通顧客IDを決定するというアイデアは非常にわかりやすいものです。しかし、異なるデータタイプの異なるデータソースの間で、レコードのリンクをサポートするユニークなIDがあることは稀です。多くの場合、データセット横断のレコードマッチングをサポートするためには、基本的な氏名や住所情報への変換が必要な自身のIDを持っています。顧客属性、すなわちデータが時間と共に変化するという課題を傍に置いたとしても、標準化されていないフォーマット、共通データ解釈、エラーエントリーによって、氏名と住所の自動マッチングは非常に困難なものとなっています。

我々著者の名前である*Bryan*の例を見てみます。この名前はさまざまなシステムに*Bryan*、*Brian*、*Ryan*、*Byron*さらには*Brain*として登録されています。仮に*Bryan*が*123 Main Street*に住んでいるとしたら、彼の住所はさまざまなシステムにおいて、*123 Main Street*、*123 Main St*、*123 Main*と入力されており、これらすべてに一貫性がなくても完璧に適切なものとなります。

人間の解釈者にとっては、顧客名の一般的なバリエーションを持つレコードや、一般的に受け入れられる住所のバリエーションをマッチさせることは非常に簡単です。しかし、多くの小売業者が立ち向かう数百万の顧客IDに対しては、プロセスを自動化するためにソフトウェアで学習を行う必要があります。最初の試みの多くは、これらのレコードにおける既知のバリエーションに対する人間の知識をルールとパターンとしてとらえるというものですが、これは多くの場合、管理不可能そして時には予測できないソフトウェアロジックが絡まり合うものになってしまいます。これを避けるために、バリエーションのある属性に基づいて顧客をマッチングする際の課題に直面している多くの企業が、機械学習に切り替えています。

# 機械学習がスケーラブルなアプローチを提供します

エンティティ解決に対する機械学習(ML)アプローチにおいて、氏名、住所、電話番号のようなテキスト属性は、任意の2つの属性値の類似度を定量化するために使用される数値表現に変換されます。そして、レコードのペアがマッチするのかどうかを決定する際、これらのスコアそれぞれの相対的な重要度に重みをつけるためにモデルがトレーニングされます。

例えば、電話番号が完全に一致する場合、ファーストネームのスペルの些細な違いには低い重要度が与えられます。何かしらの方法で、このアプローチは人間がレコードを確認する際の自然な傾向を模倣しつつも、大規模データセットに対して適用する際によりスケーラブルかつ一貫性のあるものとなります。

とはいえ、このようなモデルをトレーニングする能力は、例えば、エキスパートによってレビューされたレコードのペアが*マッチする、マッチしない*というように、正確にラベル付けされたトレーニングデータにアクセスできるかどうかに依存します。極端なことを言えば、我々が正しいということ知っているデータから我々のモデルが学習できるのです。エンティティ解決に対する多くのMLベースのアプローチの初期フェーズでは、互いにマッチする可能性が高い比較的小規模なペアのサブセットが集められてアノテーションされ、モデルアルゴリズムに与えられます。これは時間のかかるエクササイズですが、これを適切に行うことで、モデルは人間のレビュアーの判断を反映することを学ぶことができるのです。

トレーニング済みのモデルが手に入ると、次の課題は比較する価値のあるレコードのペアを効率的に特定することになります。シンプルなアプローチは、それぞれのレコードをデータセット内のすべてのレコードと比較するというものです。わかりやすいものではありますが、このブルートフォースアプローチは、計算時間がとてつもなく膨大なものとなる比較の爆発を引き起こします。

よりインテリジェントなアプローチは、属性に割り当てられた数値のスコアが類似する類似レコードを認識するというものです。特定の(これらのスコアの差分に基づく)*距離*内にあるこれらのレコードにのみ比較を限定することで、価値のある比較対象、すなわち候補ペアを迅速に特定することができます。繰り返しになりますが、これは我々が*Thomas*や*William*というファーストネームのレコードや完全に違う州のレコードがある際に詳細な比較からクイックに除外できるという人間の直感を再現しています。

我々のアプローチのこれら2つの要素をまとめることで、比較する価値のあるレコードのペアをクイックに特定し、それぞれのペアのマッチ度合いをスコアづけする手段を手に入れたことになります。これらのスコアは、2つのレコードが同じ個人を示すモデルの信頼度を意味する0.0から1.0の確率として表現されます。確率レンジの両端では、多くの場合、モデルの判断をシンプルに受け入れて次に進むのかの境界となる閾値を定義します。しかし、中央部分のいくつかの(望ましくは小規模の)ペアに関しては、最終的な判断に人間の知識が必要となります。

# ZinggがMLベースのエンティティ解決をシンプルにします

エンティティ解決の領域は技術、これらの技術のバリエーション、そして、研究者が異なるデータセットにおいて高品質なマッチを行えると発見した進化し続けるベストプラクティスで溢れています。多くの企業は、顧客ID解決のような課題に対して最新の学術的発見を適用する専門知識を維持するのではなく、アプリケーションやワークフローを構築するためにこれらの知識をカプセル化したライブラリを頼りにしています。

このようなライブラリの一つが、インテリジェントな候補ペア生成とペアのスコアリングに対する最新のMLベースのアプローチをまとめ上げているオープンソースライブラリである[Zingg](https://www.zingg.ai/)です。カスタムワークフローの構築という目的に対して、Zinggはトレーニングデータラベルの割り当て、モデルトレーニング、データセットの重複排除、そして(データセット横断)レコードマッチングのように一般的に用いられるステップのコンテキストの中でこれらの機能を提供しています。

ZinggはネイティブなApache Sparkアプリケーションとして構築されているので、エンタープライズ規模のデータセットに対してもこれらの技術をうまく適用することができます。そして、企業はバックエンドから人間が介在するワークフローアプリケーションを提供するために、DatabrikcsのようなプラットフォームとZinggを組み合わせて活用することができます。このアプリケーションは大量のエンティティ解決の作業を自動化し、解釈が必要なエッジケースをより管理可能な形でデータエキスパートに提示します。アクティブな学習ソリューションとして、将来の予測を改善するために追加の人間によるインプットを活用してモデルを再トレニーングし、エキスパートのレビューを要するケースをさらに削減します。

どのように動作するのかに興味がありますか？であれば、Databricksの[顧客エンティティ解決のソリューションアクセラレータ](https://d1r5llqwmkrl74.cloudfront.net/notebooks/nightly/RCG/Customer_ER/index.html#Customer_ER_1.html)をチェックしてみてください。このアクセラレータでは、500万人の個人を表現するレコードの重複排除をこなうために、ZinggとDatabricksを活用してどのように顧客エンティティ解決のベストプラクティスを適用できるのかを説明しています。提供されるステップバイステップの指示に従うことで、ユーザーは自身の企業規模の顧客エンティティ解決ワークフローアプリケーションを構築するために、どのようにこれらのテクノロジーによって提供されるビルディングブロックを組み合わせればいいのかを学ぶことができます。

### Databricks 無料トライアル

[Databricks 無料トライアル](https://databricks.com/jp/try-databricks)