代替データ、人工知能、生成系 AI の融合が、信用スコアリングの基盤を再構築している仕組みを学びます。
ユースケース: Gen AI
製品およびツール: Atlas、Spark Streaming Connector、ベクトル検索
パートナー: LgChuin 、 Fireworks.AI
ソリューション概要
このソリューションでは、代替データ、人工知能、生成系AIの融合が、クレジットスコアの基盤をどのように変革しているかを学びます。従来のモデルの挑戦は、信用力をより包括的かつ微細に評価する代替クレジットスコアリング方法の採用によって克服されています。このソリューションは、オンラインクレジットカードアプリケーションプロセスのサンプルを通じて、MongoDB がどのようにクレジットスコアリングをサポートできるかを示します。個人ローン、住宅ローン、企業ローン、貿易金融クレジットラインなど、他のクレジット商品にも同様のアプローチを使用することができます。
従来のクレジットスコアリングの課題
従来のクレジットスコアリング モデルの課題と限界の一部を次に示します。
クレジット履歴の不足：多くの人々は、クレジット履歴が限られている、または存在しないという障害に直面し、過去のデータがないため、信用力を証明することが困難です。
一貫性のない収入: パートタイムの仕事やフリーランスによく見られる不規則な収入によって、個人をよりリスクが高いと分類する従来の信用評価モデルにおいて懸念事項となり、申請の却下や与信限度額の制限につながります。
既存のクレジットの利用率の高さ：既存のクレジットへの依存度が高く、クレジットの利用率が高くなると、申請者が審査で不承認となるか、不利な条件での承認となる可能性が高まり、クレジット申請の障害となります。
却下理由の不明確さ：却下理由の透明性が欠如しているため、顧客は根本的な原因に対処し、今後のアプリケーションにおける信用力を高めることが困難です。
ソリューションのビルド
次のソリューションでは、プロセスの主要な側面で MongoDB がクレジットアプリケーションをどのように変革できるかを学びます。
データのキャプチャとプロセシングを簡素化します。
AI でクレジットスコアリングを強化する。
クレジットアプリケーションの却下について説明する。
代替クレジット商品を提案する。
データの取得とプロセシングの簡素化
クレジット商品の申請は、次のような理由から困難なプロセスになることがよくあります。
申請手続きの複雑さ：クレジットカードを取得するには、いくつかの時間のかかる手順が必要です。プロセスの概要は次のとおりです。
カードの選択：まず、ニーズに合ったクレジットカードを選択する必要があります。これには、さまざまなカードを調査し、機能を比較し、その条件と期間を理解することが含まれます。
適格性チェック: 次に、銀行が設定した適格基準を満たしているかどうかを確認する必要があります。これらの基準は通常、信用格付け、年齢、収入、負債などの要素を考慮します。
ドキュメントの提出：身分証明書（社会保障番号、パスポート、運転免許証など）、住所証明書（賃貸契約書、公共料金の請求書）、収入証明書（銀行取引明細書、給与明細書、フォーム16）などのドキュメントを提出する必要があります。
アプリケーションフォーム：クレジットカードアプリケーションフォームへの記入は面倒な場合があります。この手続きは、銀行のウェブサイト、ネットバンキング、または支店窓口でオンラインで行うことができます。デジタルプロセスが一般的になりつつありますが、一部の銀行では物理的なドキュメントを要求するところもあります。
検証と参考資料：銀行はドキュメントの信憑性を検証し、提供された情報を照合します。このステップでは、AI/機械学習アルゴリズムを使用して滞納確率を計算することも含まれます。
冗長な情報収集：銀行は多くの場合、次のような冗長なデータ収集を行います。
KYCの詳細情報：こうした機関はカスタマーのKYC（顧客確認）情報にアクセスできるにもかかわらず、繰り返しその提出を求めます。
収入の確認：顧客の給与、銀行取引履歴、公共料金、家賃、携帯電話料金、買い物支出などの情報がある場合でも、銀行はこれらの詳細を確認するために追加の証明書類をリクエストすることがあります。
冗長なリクエストを排除し、既存のデータを活用することでこのプロセスを効率化し、ユーザーエクスペリエンスを向上させることができます。
これらのクレジットカードの申請フォームは比較的簡単かもしれませんが、自動車ローン、住宅ローン、株式取引などの他のクレジット商品では複雑さが増します。申請フォーム内には、所有者によって許可されたサードパーティのデータソースから提供される可能性のある代替データを含め、入力する必要がある表形式だけでなく階層的な情報も存在する場合があります。MongoDB の柔軟な開発者データプラットフォームは、JSON データをネイティブにサポートし、ドキュメントが同じスキーマを持つ必要がないため、さまざまな種類のデータを処理する能力が向上します。
データ取得プロセスを簡素化し、申請のパフォーマンスを向上させるために、オンラインクレジット申請フォームに JSON を使用することができます。JSON には構造化されたデータ表現があり、保存する必要があるさまざまな詳細を整理できます。柔軟なデータモデルは、クレジットカード申請要件の動的な性質にうまく適応し、データの形状が完全に一致しなくても関連データを一緒に保存することができます。JSON は他の開発者にも一般的に理解されているため、コラボレーションが可能になり、データが一目で簡単に理解できるようになります。
MongoDB は JSON に似た BSON 形式をネイティブにサポートしているため、クレジット申請での JSON ドキュメントのプロセシングに適しています。データベースの柔軟性により、クレジット申請フォームの進化する性質にうまく対応して、スキーマを動的に調整することができます。MongoDB の階層データ構造を処理する能力と、堅牢なクエリおよびインデックス作成機能を組み合わせることで、複雑なクレジット申請情報を効率的に検索および整理できます。スケーラブルなソリューションとして、MongoDB はパフォーマンスを維持しながらクレジットデータの増加に対応します。
AI でクレジットスコアリングを強化する
MongoDB の開発者向けデータプラットフォームである Atlas を活用することで、関連するデータポイントを組み合わせて包括的なユーザーバンキングプロファイルを作成できます。
これは、延滞の可能性とクレジットスコアリングを予測するためのデータ処理パイプラインのアーキテクチャ図です。
図1。クレジットスコアリング用データ処理パイプラインの図
顧客のクレジットスコアリングのためのデータパイプラインには、次のステップが含まれます。
データ収集：まず、このプロセスでは、クレジット調査機関、オープンバンキング、不正検出システム、その他の関連情報源など、さまざまな情報源からデータを収集します。
データ処理：収集されたデータは、Spark Streaming Connectors などのツールを使用して処理され、カスタマーの財務プロファイルの統合ビューが作成されます。同じデータが MongoDB Atlas に単一ビューとして保存されます。
リスクプロファイルの生成: この統一ビューから、リスクプロファイルや製品提案が生成されます。これには、統計メソッドを使用して記述的分析を実行する方法と、リスク傾向スコアリングを実行するにあたりデータ内のパターンを識別するための人工知能（AI）または機械学習（ML）の技術を使用することが含まれます。
モデル開発：クレジットスコアリングと意思決定に使用できるさまざまな機械学習アルゴリズムがあります。例として、ロジスティック回帰、決定木、サポートベクターマシン、ニューラルネットワークなどを検討することができます。
このチュートリアルでは、予測性能で一般的に使用される機械学習アルゴリズムである XGBoost（Extreme Gradient Boosted Trees） モデルを使用しています。このアルゴリズムは、関数近似に基づく教師あり学習手法です。このアルゴリズムには以下の機能があります。
特定の損失関数を最適化してください。
いくつかの正規化手法を適用する。
高次元データを処理します。
分類と回帰のために複雑なパターンをキャプチャする。
モデルはその推論結果をサポートしており、この予測モデルの結果を説明するのに役立ちます。
データ変換：リスクプロファイルのスコアリングが実行される前に、未加工のユーザーデータはSpark（または同様のマネージド分析フレームワーク）を使用して変換されます。データは複数のソースから集約され、単一のマテリアライズドビューが作成されます。このビューは MongoDB Atlas コレクションから直接取得され、モデル開発やさまざまな記述分析タスクに使用できます。このステップには、モデル推論が含まれることもあります。
意思決定コレクション：最終的に変換されたデータは、意思決定コレクションに格納されます。これは、銀行や金融機関が財務上の意思決定と監査の目的をサポートするのに役立ちます。
目的は、カスタマーの信用度を正確に評価し、情報に基づいた融資の決定や金融商品の推奨を行うことです。このパイプラインは、組織が維持している既存のリスクスコアリングパイプラインのデモンストレーションです。
クレジットアプリケーションの却下について説明する
クレジット申請の却下の理由を理解することは、申請の重要な部分です。MongoDB と大規模言語モデル (LLM) が XGBoost モデルの予測 (このチュートリアルで使用されるモデル) を説明する方法を学びます。
以下は、LLM を使用したクレジット スコアリングを説明するアーキテクチャ図です。
図2。LLMを使用したクレジットスコアリングアーキテクチャ図
採用されているリスクプロファイリング機械学習パイプラインは、商品推奨のプロファイルに関連するリスクを定義する確率スコアを提供します。このメッセージは標準化された方法でユーザーに返され、申請の最終ステータスのみがエンドユーザーに伝えられます。LLM を含む提案されたアーキテクチャでは、プロンプトエンジニアリングを使用して、最終的に承認された商品のステータスの理由をエンドカスタマーに正当な理由と共に説明することができます。
ここで、コードと応答例を閲覧できます。同様のメッセージを生成するコードは、Jupyter Notebook で Python を使って実行できます。MongoDB Atlas の設定と接続文字列の取得の詳細については、このリンクをご覧ください。
以下は、却下の説明の一例です。
図 3. 却下理由の説明例
カスタマーへのこのメッセージは、説明可能な AI の形式であり、リスクプロファイリングを実行するためにモデルで使用される機能がランク付けされ、LLM へのカスタムプロンプトの一部として使用されます。これにより、上記のように、エンドカスタマーがユーザープロファイルを説明する際に、より具体的な理由を示すことができます。LLM は、説明理由のリストを要約し、説明の簡略化されたビューを提供するのにも役立ちます。この用途では、カスタマーがクレジットプロファイルとユーザーエクスペリエンスを向上させたい場合に、詳細を掘り下げることができます。
このデモでは、クレジット申請をスコアリングするために2つのアプローチが使用されています。クレジット申請のステータスは、前のセクションで説明したように、20以上のクレジット関連の機能を使用した機械学習アプローチによって決定されます。最も重要な上位15の機能の一部を以下にご紹介します。
図 4. 機能重要度チャート
このデモで使用されている機能の詳細については、クレジットスコア GitHub リポジトリで提供されているソースコードをご覧ください。
機械学習と従来のクレジットスコアリングアプローチの違いを示すために、一般的な従来のクレジットスコアリング方法では、同じクレジット申請を評価する際に、通常は限られた数の次元しか使用しないことを考えてみましょう。このデモでは、主要なクレジットスコアプロバイダーが通常使用するいくつかの機能を使用しました。
クレジット申請者の返済履歴
クレジット使用
クレジット履歴
クレジット照会の未処理件数と回数
代替クレジット製品を提案
信用機関は、顧客がすでに手続きやアプリケーションポータルを利用している状況において、顧客のニーズに合った関連商品をクロスセルするよう常に努めるべきです。
金融機関は、新しい推奨の根拠を人にわかりやすく説明する商品推奨システムを実装できます。これにより、現在のレガシーシステムにはない新たな収益機会が開かれます。理論的根拠を提供することで、クライアントとよりパーソナライズされた関係を築き、推奨製品の受け入れをさらに増加させられます。以下は、これを実現するために使用されるデータアーキテクチャの一例です。
図 5. レコメンデーションシステム アーキテクチャ
Atlas Vector Search は、あらゆる種類のデータに対してセマンティック検索と生成系AIを実行できる機能です。運用データベースとベクトル検索を、MongoDB ネイティブインターフェースを備えた単一の、統合された、完全管理プラットフォームに統合します。機械学習モデルを使用してベクトル埋め込みを作成し、それらを MongoDB Atlas に保存およびインデックス化して、検索拡張生成（RAG）、セマンティック検索、推奨エンジン、動的パーソナライゼーション、その他のユースケースに利用できます。
RAG は、入力クエリに基づいて関連するドキュメントをベクトル検索で検索するパラダイムです。次に、検索されたドキュメントをコンテキストとして LLM に提供し、より情報に基づいた正確な応答の生成に役立てます。
上記のチュートリアルでは、クレジットカード商品の推奨のユースケースを解決するために使用できるテクノロジーについて説明しています。プロセスに含まれる手順を以下に説明します。
個人データを読み込む：クレジットカード商品ごとに提供内容は異なります。これらの商品は随時変更されます。また、映画チケットやコンシェルジュサービスなどのさまざまなライフスタイル特典の料金も変更されます。商品データを MongoDB にオペレーショナルデータストア（ODS）として保存することで、変更を維持しながらベクトルインデックスを同時に構築することができます。
大規模なデータポイントは、ニーズに応じて適切に更新、削除、挿入、または置換することができます。
クレジットカード商品の説明は非常に長いため、小さなチャンクに分割すると、それに応じて関連情報を検索するのに役立ちます。
LLM を活用すると、製品の説明を短縮し、製品の主要な機能とコストをすべて含む要約を作成することができます。この変更により、関連する商品をすばやく検索して提案することが可能になります。
LLM を活用したレコメンデーション: このユースケースでは、LLM をレコメンダー システムとして使用し、前の段階で生成されたユーザープロファイルを入力として使用し、MongoDB Atlas に保存されている製品ベクトルに対してセマンティックな類似性検索を実行するためのサブクエリを生成できます。
パーソナライズされたメッセージ付き商品推奨：その後、推奨商品をLLMへのカスタムプロンプトで使用して、エンドユーザーに関連する商品推奨の概要を生成できます。
これにより、金融機関は推奨をパーソナライズし、カスタマーに関連する推奨を提供できるため、コンバージョン率が向上します。
商品の推奨は、提供する商品の「推奨する可能性が高い」スコアを向上させることで、顧客エンゲージメントを高め、ユーザーエクスペリエンスを向上させます。
ここで、代替製品の推奨コードと例を閲覧できます。以下にいくつかの例を示します。製品推奨を生成し、製品推奨の説明をカスタマイズするコードは、Jupyter Notebook で Python を使用して実行できます。
図 6. 承認済み申請の例
結論として、クレジットスコアリングは、生成系AIの統合により、変革の段階にあります。伝統的なモデルのダイナミクス、借り手が直面する課題、そして生成系AIによって描かれる未来を探求する中で、透明性、効率性、パーソナライズが、進化するクレジットスコアリングの分野において最優先課題であることが明らかになっています。テクノロジーと金融の相乗効果により、クレジット判断が正確であるだけでなく、借り手にも力を与える未来が形作られています。
このようなソリューションを構築するための MongoDB のすべての機能を示すコードは、この Github リポジトリで入手できます。私たちは、生成 AI を用いたイノベーションをより迅速に、効率的に、安全に行うため、MongoDB の主要な AI パートナーである Fireworks.AI 上でアプリケーションを開発し、展開しました。
キーポイント
提案されたソリューションの機能的および非機能的な特徴は以下の通りです。
GenAIの機能を理解：多様なデータセットを統合して、従来のクレジットスコアリングモデルの主な制限に対処します。
説明可能なクレジットステータス：LLM を通じて、プロンプトエンジニアリングを効果的に活用し、クレジットステータスの理由を正当な理由とともにエンドカスタマーに伝えることができます。
従来の信用スコアリング モデルの課題: 進化する金融行動に適応し、従来とは異なるデータソースを処理し、信用力をより包括的かつ正確に評価できる代替の信用スコアリング モデルの必要性を認識すること。
代替データ：クレジットスコアリングをより正確にするための代替データの利点を理解します。たとえば、このクレジットスコアリングモデルは、公共料金、携帯電話料金、教育履歴などの代替データポイントを使用することでさらに改善できます。
ハルシネーションへの対処：RAG を活用して、モデルの応答を最新のソースからの事実情報に基づかせ、モデルの応答が最も最新かつ正確な情報を反映するようにすることで、ハルシネーションのリスクを軽減します。
作成者
Ashwin Gangadhar、提携ソリューション部門、MongoDB
Wei You Pan、業界ソリューション部門、MongoDB
Julian Boronat、業界ソリューション、MongoDB