re:Invent 2024: S&P GlobalのAI活用 - Foundation ModelでのWeb情報分析事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - S&P Global: Scaling data insights with fine-tuned foundational models (FSI313)
この動画では、S&P GlobalがAmazon SageMakerを使用してFoundation Modelをファインチューニングし、Amazon EKSにデプロイして週600万件の推論を処理した事例を紹介しています。非公開企業の信用リスク評価において、財務諸表が入手できない6,000万社以上の企業を対象に、Webスクレイピングで得られたテキストデータから信用シグナルを抽出する取り組みを解説しています。Llama-2-7BモデルにLoRAを適用し、パラメータの0.1%のみを更新する手法や、GPUでFine-tuningしたモデルをCPUで実行するための量子化など、コスト効率を重視した実装方法の詳細が語られています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
S&P GlobalのFoundation Modelファインチューニングプロジェクト：概要と背景
みなさん、お元気ですか？素晴らしい。本題に入る前に、簡単なアンケートを取らせていただきます。AIの実装にあたって、Foundation ModelやLarge Language ModelのFine-tuningを行っている方は何人いらっしゃいますか？素晴らしいですね。何人かの手が挙がりましたね。本日のセッションでは、S&P Globalが Amazon SageMakerを使用してFoundation Modelをどのようにファインチューニングし、Amazon EKSにデプロイし、大規模に運用して、1週間で600万件もの推論を処理しながら、コストを効率的に最適化したかについてご紹介します。私はAWSのSolutions ArchitectのPrasanth Ponnothです。本日は、S&P GlobalのDushyanth SekharとSaeed Shoaraeeをお迎えして、彼らの取り組みについてお話しいただきます。
金融サービス業界における彼らのビジネス上の課題について詳しく説明する前に、 そしてなぜその課題解決のためにFine-tuned Foundation Modelをデザインパターンとして選択したのか、そしてAWS上でどのように分散アーキテクチャを構築したのかについて説明する前に、まず、お客様が Generative AIソリューションを構築する際に私たちが見てきた傾向について、少しお時間をいただきたいと思います。
お客様は、自社の重要な差別化要因であるデータ基盤の上に、Generative AIソリューションを構築しています。 AWS上に構築されたこの基盤は、スケーラブルで安全性が高く、耐障害性のある価格性能比の優れたストレージオプションと、様々なデータ統合ソリューションを提供し、お客様が迅速にGenerative AIアプリケーションを大規模に構築できるようサポートしています。お客様は、特定のビジネス課題に対してGenerative AIが実用的なユースケースとして必要だと判断し、適切な価格でスケールさせる必要があると判断すると、パターン選択の旅に乗り出します。Prompt Engineering、Retrieval Augmented Generation、Fine-tuning、あるいはContinued Pretrainingから始める方々もいらっしゃいます。
みなさんもご経験からお分かりの通り、このグラフが示すように、 左から右に進むにつれてモデルの品質は向上していきます。より領域特化型になり、ドメインコンテキストを意識するようになります。その分野でよりスマートになっていくわけですが、そのトレードオフとして、それを実現するための複雑さ、時間、コストが増加します。S&P Globalでは、複雑なビジネス課題を解決するために、Fine-tuned Foundation Modelをデザインパターンとして選択しました。彼らの取り組みについてお聞きしましょう。
非公開企業の信用評価：課題とS&P Globalのアプローチ
Prasanth、ご紹介ありがとうございます。まず、ビジネスユースケースについて少し背景をご説明させていただき、その後、同僚が具体的な実装の詳細についてご説明いたします。 S&P Globalにとって、データがビジネスそのものです。私たちの行うすべてのことがデータを中心に展開されており、Big Dataという言葉が生まれる前から、私たちはBig Dataを扱っていました - ただ、そう呼んでいなかっただけです。データは私たちの行うすべての基盤となっています。
私たちの格付け事業とこのユースケースを区別するために、少し背景を説明させていただきます。信用格付けとは、平たく言えば、債務者が財務上の義務を果たす確率のことです。債務者は企業や政府などの機関となります。S&Pの信用格付け事業は150年以上の歴史があり、現在、約46兆ドルの債務に関わる約100万件の信用格付けを市場に提供しています。これは独立した部門です。これらの格付けは主に財務分析に基づいていますが、Market Intelligenceが担当する非公開市場という大きな領域があり、これは私たちにとって大きなビジネスチャンスとなっています。非公開企業の信用格付けは難しい仕事です。というのも、様々な法域で、これらの非公開企業の多くは財務諸表の提出を義務付けられていないからです。そのため、これらの非公開企業と取引をしているお客様のニーズに応えるために、他のシグナルを見る必要があります。私たちはこれらをSMB（中小企業）と呼んでいます。売上高が100万ドル未満の企業もありますが、お客様の中には、このような企業を10万社もサプライヤーや取引先として抱えているところもあります。そのため、規制上入手可能な財務報告書がない場合、
他のシグナルを見て、Risk Gauge Reportと呼ばれるものを作成し、お客様がこれらのSMBとの取引について迅速な判断を下せるようにしています。この問題は業界で長年存在してきましたが、Generative AIなどの最新技術や、そもそものデータの入手可能性の問題により、これらの企業の信用スコアリングは困難でした。つまり、財務情報がないため、よりシグナルベースのシステムに頼っているわけです。
ここで主な課題をご説明します。お客様は大規模なSMBポートフォリオを迅速に評価する必要があるため、すぐに使える評価方法が必要です。米国でさえ、非公開企業は規制当局に財務諸表を提出する義務がありません。欧州では、イギリスのCompanies Houseのような機関や地域の機関からこうした情報を入手できますが、これらは最新のものではありません。イベントが発生してから実際に財務情報が入手できるまでに3～4ヶ月かかることもあり、リアルタイムでの信用評価を必要とするお客様のニーズには適していません。
財務情報の代わりに、経営陣の変更が頻繁に行われていないか、支払い履歴はどうか、先取特権や法的申し立てはないかなど、他の情報を見ることができます。これらの情報をシグナルとして使用し、定量的な信用評価方法を確立することができます。タイミングは非常に重要で、情報の遅れはお客様に受け入れられません。より早く提供できることは、私たちの大きな競争優位性にもなります。S&P Ratingsの信用管理者として言えば、少ない情報よりも、より多くの情報を素早く得られる方が良いのです。これが私たちが直面している課題であり、財務諸表はないものの、多くのお客様と取引を行っている6,000万社以上の企業がこの対象となっています。
この問題を解決するには、いくつかの方法があります。Webを調査して、企業のテキストフットプリントなどのファーストパーティ情報を確認することができます。ただし、これには技術的な課題があります。5,000万から6,000万のWebサイトを追跡する必要がある場合、各サイトにスパイダーを設定するような従来型のWeb監視アプローチでは、非常に労力がかかります。次にセカンドパーティ情報がありますが、これはジャーナリスティックな記事からより多く得られます。場合によっては、ファーストパーティ情報に財務情報が含まれることもありますが、今回は財務情報がないケースについて話しています。ファーストパーティ情報は最も信頼性が高く、企業から直接得られる情報は、他のどの情報よりも階層的に上位に位置づけられます。また、ソーシャルメディアを利用してサードパーティ情報を追跡するという選択肢も常にあります。
これらのタスクをMicroservicesとして捉えるという戦略を取っています。例えば、私企業の業種分類を作成するというのがその一例です。金融業界の方々はGICS分類をご存知かと思いますが、これは新時代のビジネスを想定していなかったため、ほとんどの私企業には適用できません。まず業種のクラスを確立する必要があります - 例えば、BlockchainはそもそもGICS分類には存在しません。また、現代の企業の多くは複数の分類を持っています - 例えばAmazonをどのように分類すればよいでしょうか？複数のクラスを持つことができます。業種を確立した後は、定量的に業種リスクスコアを設定できます。これは分類のタスクとなり、さらにイベントを追跡するタスクもあります。例えば、企業の経営陣に変更があった場合、私たちの定量モデルで特定のスコアリングができます。
大きな空母を建造するのではなく、これらは独立して運用される小型の船舶のようなものです。Prasadが言及した通り、アーキテクチャ面での複雑さもあります - これらをシームレスに連携させるにはどうすればよいのでしょうか？これらのパイプラインは毎日実行され、完全に人手を介さずに動作します。信用アナリストが確認することはありません。モデルがすべてのデータ収集、分類、解析を行い、定量モデルに投入し、レポートが発行されます。
このリアルタイムモニタリングの頻度は柔軟に設定できます。理論的には、望めば1時間ごとにWebを追跡することも可能ですが、あまりに頻繁に行うとコストが法外になるため、適切なバランスを見つけることが重要です。最終的なリスクレポートは、企業レベルで出力することも、自社のポートフォリオに対して実行することも可能です。
大規模Webスクレイピングとデータ抽出：技術的課題と解決策
私の講演は3つの主要なセクションで構成されています。まず、企業のテキストデータをどのようにスクレイピングしているかを紹介します。次に、それらのWebページから関連する信用シグナルを抽出するために、Fine-tunedされたLLMをどのように活用しているかを説明します。最後に、これらのモデルをProductionに展開する中で得られた知見を共有します。DushyanthがS&P Globalで説明したように、私たちは様々なソースからデータを収集しています。
私たちのグループは主に、ドキュメントやWebからデータを収集するための自然言語処理の活用に焦点を当てています。Dushyanthが紹介したプロダクトでは、いくつかの課題を解決する必要があります。私企業のURLが与えられた場合、特定のドメイン内でその企業に関連するすべての子URLをマッピングする必要があります - これを私たちはDomain Graphと呼んでいます。そのDomain Graph内で、私たちのユースケースに関連性のある子ページを特定する必要があります。それらの子ページを特定した後、HTMLファイルの中から関連するリスクシグナルを含むセクションを見つけ出し、それらのセクションを特定する必要があります。また、これらのシグナルは私たちのCredit Modelに反映されるため、それらのセクションを週次でモニタリングする必要があります。最後に、これらすべてを1億社の私企業をカバーするスケールで実行する必要があります。
私たちの最初のステップは、ドメイングラフの作成です。企業のURLから始めて - それはホームページでも他のページでも構いません - そのURLから3階層まで探索していきます。これは有向グラフとして表現でき、各ノードがURLを、エッジがURL間のつながり、つまりハイパーリンクを表しています。このグラフ表現を見ることで、NLPを使用することなく処理の優先順位を特定できます。グラフの中心性指標を使用して、最も多くの接続を持つページを特定し、そこから処理を開始します。その後、それらの子ページの中から、実際に重要なものを分類する必要があります。この分類の部分が、プレゼンテーションの後半で説明するLLMを活用する主要なトピックとなります。
重要な子ページを特定した後は、HTMLファイル内で私たちのユースケースに関連するシグナルを含むセクションを特定する必要があります。これらのセクションには、例えば企業の経営陣について言及しているセクションなどが含まれ、時間の経過とともにそれらを追跡する必要があります。具体的には、企業の経営陣がどの程度変化しているかを追跡する必要があります。
HTMLファイルからの抽出が実際になぜ難しいのか疑問に思われるかもしれません。HTMLはマークアップ言語で、どのWebブラウザでも綺麗に表示されるはずですから。その答えは、HTMLが非常に柔軟で寛容な設計になっているからです。HTMLファイルでは、テーブルをspanとdivだけで定義することもできれば、proper tableタグやTR、TDを使って定義することもできます。非上場企業に関しては、各社のWebサイトの構築方法に膨大なバリエーションが存在します。これらの要因すべてが、HTMLファイルからの抽出を困難にしています。現代のWebはJavaScriptで溢れており、モダンブラウザでは多くのコンテンツが動的にロードされます。これらの要因により、HTMLからの抽出は時としてPDFからの抽出よりもはるかに困難になることがあります。
Dushyanthが紹介したように、HTMLからの抽出における従来のアプローチは通常、ルールベースの手法に依存しています。HTML要素への参照であるXPathにアンカーし、そのXPathの変更を時間とともに追跡します。これらの従来のアプローチの主な問題は、大量の誤検知が発生することです。ページの幾何学的な変更が警告をトリガーする可能性がありますが、それは必ずしも企業に関連するシグナルがあったことを意味しません。
では、どのように解決するのでしょうか？これは私たちのチーム内でのイノベーション領域となっています。HTMLファイルから始めて、そのHTML DOMをツリー構造に変換します。より正確には、異種グラフに変換します。そのグラフの各ノードに対して、効果的にフィーチャースペースを拡張していきます。これらのフィーチャースペースは、H2の人名やテーブルのTR TD製品IDや製品説明といった一連の特徴として考えることができます。このプロットで見られるようなボックスがそれにあたります。これは実質的にEmbeddingのようなものであり、この先どうなるか想像できると思います。そのグラフ内のメタパスを使って、私たちが関心を持つクラスにそのメタパスを分類する機械学習モデルを訓練することができます。これが、従来のWebクローラーのスケールアップに関する課題を解決する方法です。XPathにアンカーする代わりに、メタパスを分類するのです。
オーケストレーションについてご説明しますと、これは週次で実行されるパイプラインで、最大1億社の企業をカバーしています。Amazon Managed Workflows for Apache Airflow (MWAA)を活用しており、Airflowでは実質的にサイトマッパー、スクレイパー、エクストラクターという3つの主要コンポーネントを持つDAGを使用しています。Airflowは単にAPIコールを通じてパイプラインを起動し、それらのAPIコールはキューに登録されるタスクとなります。Redisを活用してキューを管理し、ジョブが投入されるたびにそのステータスを保持します。Amazon EKSのPodで実行されているワーカーノードがこのキューをリッスンし、ジョブが現れると処理を開始します。このユースケースでは、Redisが大きなメリットをもたらしています。
これはインメモリデータベースで、キュー管理に使用でき、ドメイングラフを巡回する際のWebクローラーのステータスを非常に低いレイテンシーで保存できます。SQSと S3での永続化のような異なるサービス間を行き来する必要がなく、多数のI/O操作も不要です。
必要なレベルまでスケールできるよう、広範なエンジニアリングを行いました。ピーク時には、スクレイピングだけで約400個のPodを同時に実行しており、これらは4 CPUで64の並列ジョブを実行する小規模なPodです。重いスクレイパーと軽いスクレイパーを分離しており、重いスクレイパーは大量のJavaScriptコンポーネントを含むページを担当します。データを動的にロードするために、これらのページでは長く待機する必要がある場合もあります。ストレージとモニタリングについては、実行しているプロセスの規模が膨大なため、一般的なスタックを使用しています。ログ管理にはAmazon OpenSearch Serviceを使用しており、大きな価値を実感しています。
LLMのファインチューニングと実装：効率的なアプローチと得られた教訓
ここまでは企業のサイトマップを作成する話でしたが、次は信用リスクに関連するシグナルを含むページを特定する必要があります。このユースケースには、複数の複雑な分類と抽出のケースが存在します。例えば、非公開企業のビジネス活動を特定するのは簡単ではありません。企業は主要事業の説明方法がそれぞれ異なり、ホームページと下層ページの説明が必ずしも一致しないなど、かなりの曖昧さが存在します。
Large Language Modelは言語理解と曖昧なテキストの処理に非常に強力です。この分類のユースケースでは、私たちのグループで使用してきた従来のNLPアプローチと比較して、本当に優れた性能を発揮します。また、LLMは特に信用リスクのような特定のドメインに対してFine-tuningを行うと、優れたマルチタスク処理能力を発揮します。従来のNLPを使用する場合、様々な分類や抽出タスクに対して複数の異なるモデルを訓練する必要があり、そのモデルのライフサイクル管理は容易ではありません。LLMは優れたマルチタスク処理能力を持つため、1つのモデルで複数の異なる抽出や分類タスクを実行でき、ライフサイクル管理の複雑さを軽減できます。
LLMのFine-tuningは高コストで非常に難しく、本番環境での運用も大変だと、私たちは皆聞いています。次のセクションでは、私たちが実際に何をして、どのように解決したのかをご説明します。 まず、Large Language Modelのfine-tuningとは何かについてお話しします。Fine-tuningとは、事前学習済み言語モデルの隠れ表現を更新するプロセスで、特定のタスクに対してそのモデルの性能を向上させることを目的としています。Full fine-tuningを行う場合、すべてのモデルパラメータを更新することになり、その結果として隠れ表現も更新されます。
すべてのパラメータを更新する必要があるため、複数のGPUを並列で使用する大量の計算リソースが必要になります。パラメータ数の多いモデルの場合、70億のパラメータを更新する必要があるため、複数のGPUを並列で使用する大規模な計算能力と大量の学習データが必要となり、非常にコストがかかります。Full fine-tuningには、異なる下流タスクを扱う際にもう一つの実践的な課題があります。例えば、3つの異なるタスクがある場合、各fine-tuned modelは元の事前学習モデルと同じサイズになります。私たちが使用したLlama-2-7Bの場合、約14ギガバイトのサイズです。3つの異なるタスクに対してfull fine-tuningを行うと、本番環境で維持管理が必要な14ギガバイトのモデルが3つできてしまいます。
Parameter-efficient fine-tuningは、シンプルなアイデアでこの問題を解決します。事前学習モデルの隠れ表現を更新することが目的であれば、すべてのモデルパラメータを更新する必要はないという考え方です。モデルのアーキテクチャに注入されるAdapterと呼ばれる小さなモジュールを学習することで、同じような表現の更新を実現できます。これにより、fine-tuningの複雑さが大幅に軽減されます。例えば、Llama-2-7Bの場合、Parameter-efficient fine-tuningではモデルパラメータの約5%のみを更新すれば良く、95%は固定されたままです。もう一つの利点として、Adapterモジュールのみを更新するため、14ギガバイトのベースモデル1つと、数十メガバイト程度のサブモジュールがいくつかあるだけで済みます。これにより複雑さは軽減されますが、Parameter-efficient fine-tuningでも1つのGPUでは実行できず、クラスターが必要です。
私たちは、LoRA（Low-rank adaptation of pre-trained models）という手法を使用しました。LoRA Adapterはフィードフォワード層と並列に配置され、低ランク行列を使用するため、更新が必要なパラメータ数はParameter-efficient fine-tuningよりもさらに少なくなります。Llama-2-7BにLoRAを適用した場合、モデルパラメータのわずか0.1%（700万個）の更新で済みます。これは4年前でも扱えた規模ですが、事前学習モデルに含まれる豊富な知識ベースを活用できるという利点があります。
Parameter-efficient fine-tuningと量子化を組み合わせる研究も盛んに行われています。量子化とは、モデルの性能を大きく損なうことなく、16ビットから4ビットに変換することです。量子化を行うと、モデルのサイズは4分の1になります。Llama-2の場合、14ギガバイトが3.5ギガバイトになり、扱いが非常に楽になります。最近では、ほぼエッジでも実行できるようになっています。
Fine-tuningは、質の高いデータがあってこそ成功します。今回のユースケースでは、S&Pにはアノテーションデータがあまりありませんでした。これは私たちにとって新しい領域だったため、Waterfallアプローチを活用しました。Waterfallアプローチでは、シンプルなケースはルールベースのパターンマッチングエンジンで処理し、そのルールベースのアプローチで分類できないものは、自己採点パイプラインに送られます。
この自己採点パイプラインには、上位に大規模な言語モデルがあり、下位に自己採点機能があります。これは学習データを作成するためのエージェント的なアプローチです。実質的に、700億パラメータの大規模な事前学習モデルの知識を蒸留し、その学習セットに基づいて、より小規模なモデルにそのドメインを理解させます。自己採点機能は、別のプロンプトを送信し、分類の確信度について大規模モデルに問い合わせます。回答の確信度が非常に高い場合は、直接学習データベースに送ることができます。確信度が低い場合は、人手によるアノテーションパイプラインに送ります。
ここでの重要なポイントが2つあります：リソースが限られていて、このようなユースケースがある場合は、自己採点アプローチを使用するのが常に良い選択です。また、言語モデルに一度にたくさんの質問をするのは避けましょう。質問を小分けにする方が、大きなプロンプトで一度に多くのことを要求するよりも、通常うまく機能します。モデルのFine-tuningには、Amazon SageMakerを活用しました。私たちの出発点は、QuantizationとLow-Rank Adaptationに関する設定でした。質の高い指示と回答を作成することが、成功するFine-tuningの鍵となります。
言語モデルのFine-tuningには、戦略スライドに戻りますが、もう1つの利点があります。それは、言語モデルの出力形式に対する追加の制御レベルが得られることです。例えば、プロンプトテンプレートでは、言語モデルから出力されるトークン数を制限しています。なぜなら、ここでは分類のみを行っており、生成タスクは行わず、モデルから複数段落のテキストを返すことも期待していないからです。このトークン数の制限により、モデルのハルシネーションを大幅に制御できます。特定のダウンストリームタスク用に学習させることで、既製の事前学習モデルを使用する場合と比べて、はるかに多くの制御が可能になります。また、これらのモデルの初期プロンプトテンプレートを維持することも良い考えです。Llama-2を使用している場合は、最初に使用されたプロンプトテンプレートを確認し、大きく変更しないようにしましょう。なぜなら、ユースケースに対してモデルの性能を向上させたいだけで、最初に学習したことをすべて忘れさせたくはないからです。
SFT Trainerの部分では、モデルのハイパーパラメータチューニングが行われます。学習効率とモデル性能の最適な組み合わせを得ることが目標です。私たちには従来のNLPに基づく多くの社内モデルがあり、それらをChallengerモデルとして活用しています。分類と抽出を行う部分については、アーキテクチャは以前見たものとほぼ同じです。 Amazon EKSのWorker Podは、Amazon ElastiCacheの別のキューをリッスンし、これらの分類と抽出のジョブを取得して結果を返します。私たちが行った1つの工夫は、 GPUでモデルをFine-tuningし、実行時にCPUに変換したことです。llama.cppという非常に優れたオープンソースライブラリがあり、この変換を可能にしています。
事前学習済みモデルのGPUからCPUへの変換と、量子化もサポートしています。私たちは、以前のステップで使用していたのと同じCPUクラスターで実行できるようにモデルを変換しました。これまでに学んだ教訓をいくつかご紹介させていただきます。
シンプルに始めることが常に非常に重要です。本日のKeynoteでも聞かれましたが、それが主なメッセージでもありました。シンプルに始めて、徐々に複雑さを増やしていくのです。まずは70-80億パラメータの小規模なLLMを選び、LoRAのような手法を活用してモデルのパラメータの1%未満を Fine-tuning し、ユースケースでどのように機能するかを確認します。そして、本当に必要な場合にのみ、複雑さを増やしていきます。パラメータのごく一部だけを更新する場合、過学習のリスクが大幅に低減されます。また、Fine-tuning プロセスの一環として、モデルが初期学習を忘れてしまう破局的忘却も防げます。これは、モデルに対して細かすぎる調整を行うことで起こります。
通常、小規模な Fine-tuning を行うことで、モデルのコンテキスト外でのパフォーマンスが大幅に向上します。ドメインが拡大するにつれて、モデルの反応が改善され、コストも大幅に削減されます。私たちが行っているようなユースケースであれば、SageMaker の単一のGPUマシンで、エンドツーエンドのトレーニング1回を16-17時間程度で完了できます。
基本的な分類や抽出のユースケース（業界で必要とされる作業の80%を占める）のための従来のNLPからの移行を検討している場合で、LLMによる大量の生成を必要としない場合は、CPUとGPUの価格対性能比を比較検討してください。私たちのケースでは、CPUを使い続けることが非常に理にかなっていました。確かに、単一のGPUインスタンスの方がはるかに高速ですが、1回の推論を実行できる単一のCPUインスタンスと比べて3〜4倍のコストがかかります。そのため、CPUで前処理や後処理のステップを実行する場合は、モデルの推論もCPUで行い、コストの観点から最適かどうかを計算してみることをお勧めします。
RiskGauge Desktop：統合された信用リスク評価ソリューション
以上が私が共有したかった主なポイントです。では、これらすべてがRiskGauge レポートでどのように統合されているかを見てみましょう。RiskGauge Desktop は、企業の信用リスクワークフロー向けに設計された集中型エクスペリエンスです。ビジネスにとって最も重要な詳細情報を表示する単一のダッシュボードで、ポートフォリオ全体を確認できるようになりました。
集計された RiskGauge スコアをチェックすることで、全体的なリスクエクスポージャーとその傾向を把握することができます。重要な市場要因に連動した早期警戒シグナルによって、信用力の変動を予測することができます。ナレッジハブにアクセスして、タイムリーで有用な洞察を得ることができます。より広い視点をお求めの場合は、グローバルな経済動向 や国別リスクがポートフォリオ全体にどのような影響を与えるかを理解することができます。さらに、早期警戒システムが提供する洞察を深く掘り下げるために、国や業界ごとにエクスポージャーを層別化することができます。
また、個別企業にズームインして、重要な詳細情報や主要なビジネスドライバーを明らかにすることもできます。当社の豊富な非公開・公開企業データベースを活用することで、企業の信用評価 やピア比較を即座に生成することができます。何百万社もの企業の包括的なビジネス信用レポートにアクセスし、重要なポイントを絞った実用的な洞察を提供するカスタマイズされた RiskGauge ビジネス信用レポートを作成することができます。顧客の信用リスクを明確に把握することができます。 S&P Capital IQ で利用可能になった RiskGauge Desktop をご活用いただき、顧客の信用リスクの評価、モニタリング、管理の方法を革新してください。 ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion