Anomaly detection using embeddings and GenAI - Databricks Community - 95564の翻訳です。
本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
製造、ユーティリティ、公共セクター機関のように複雑な購買プロセスを持つ業界において、不正な購買の検知が大きな課題となっています。ベンダーは、重大な財務的損失に繋がりうる、過度の請求、偽の請求書、重複したクレームの送信などに関与するかもしれません。従来の手法は多くの場合、大規模なトランザクションボリュームや複雑なサプライチェーンにおける微妙な異常の捕捉に苦戦しています。不正は非常にバランスの悪いものであるため、問題はさらに複雑なものとなります。データのほんの一部にのみ存在しており、製品のデータは通常、微妙な逸脱のみを示す際立った特徴料を持つ多次元なものであり、検知をさらに困難にしています。
機械学習(ML)はこの領域でパワフルなツールであることが立証されていますが、すべてのシチュエーションですべてのテクニックがうまく動作するわけではありません。近年では、エンベディングと大規模言語モデル(LLM)が不正検知の精度改善の助けとなる新たな手法として出現してきています。
この記事では、機械学習のテクニック、特にエンベディングと大規模言語モデル(LLM)を活用することで通常であれば特定が困難な外れ値やパターンを特定し、どのように不正検知を改善できるのかを探索します。従来の機械学習アプローチからスタートし、LLMドリブンの戦略に移行し、両者の強みを組み合わせたハイブリッドアプローチで結論づけます。
すべてのコードセクションを持つ実行可能なノートブックは、DatabricksブログのGithubリポジトリに格納されています。
なぜエンベディング？
エンベディングは、製品説明や購入詳細のような自然言語のような複雑で高次元のデータを密なベクトル表現に変換することで、不正検知において重要な役割を担います。これらのエンベディングは、アイテム間の意味的な関係性を捕捉し、意味に基づいてそれらを比較できるようにしてくれます。
例えば、同じベンダーから購入した製品には類似したエンベディングを持つかもしれませんが、不正あるいは異常な購入には標準から逸脱したエンベディングを示すことでしょう。
図1. 二次元空間における製品エンベディングの可視化: 通常の製品は青で表示していますが、外れ値のある製品は赤で表示しています。
これらのエンベディングに機械学習アルゴリズムを適用することで、パターンや外れ値を検知することができ、期待される挙動から逸脱した不正の可能性があるトランザクションを特定する助けとなります。
エンベディングにおける異常検知のためのML
エンベディングにおける異常検知の分析では、我々はいくつかのアプローチを探索し、主に次元削減、クラスタリングアルゴリズム、アイソレーションフォレストのような従来の不正検知手法にフォーカスしました。
Principal Component Analysis (PCA)やt-distributed Stochastic Neighbour Embedding (t-SNE)のような次元削減手法は、データの次元数を削減することで助けになります。
- PCAは全体的な構造を明らかにし、計算効率が高いですが、データの微妙なパターンを見逃す場合があります。
- t-SNEは詳細な関係性を明らかにすることに優れていますが、大規模データセットでは計算量が多くなります。
クラスタリングアルゴリズムは類似したデータポイントをグルーピングし、外れ値の特定の役に立ちます。例えば、k-Meansは使いやすく、大規模データでもうまく動作しますが、クラスターが円形であることを前提としています。DBSCANは任意の形状のクラスターを特定することができ、外れ値の取り扱いに優れていますが、異なる密度のデータを取り扱う際にはトリッキーになることがあります。アイソレーションフォレストはデータポイントをランダムにパーティショニングすることで動作し、高次元データでも効果的です。しかし、我々の分析においてはこのアルゴリズムのパフォーマンスは最低でした。
それぞれの手法は強みと弱みを持っているので、ベストな選択肢はあなた自身のデータで何を必要とするのかに依存します。
異常な購入を特定するためにMLを適用
この記事では、それぞれのベンダーから購入した製品の異常を検知するために、調達部門から得た過去の購買データを分析します。これを行うために、まず初めに、より広範囲な製品セットが異常検知においてよりリッチな文脈を提供するので、少なくとも2つの固有の製品が購入されたベンダーのみを考慮するようにする必要があります。
エンベディングモデル(gte-largeなど)を用いて、これらの製品を高次元空間にエンベッドすることをからスタートします。エンベディングを作成したら、標準から大きく逸脱している製品を特定するために異常検知アルゴリズムを適用します。このアプローチによって、ベンダーのトランザクション履歴において不正の可能性のある、あるいは標準的ではない通常と異なる購買を特定する助けとなります。
図2. MLを用いた購買データにおける異常検知のためのパイプライン
購買データにおける異常検知のためにエンベディングを用いる方法をデモンストレーションします。このプロセスをシンプルにし可視化するためにPCAを適用します。
PCAはキーとなる情報を保持しながらも、その次元を削減することで高次元データをシンプルにする手法です。PCAは、主成分とよばれる一連の軸にデータを変換することでこれを成し遂げます。これらの主成分はデータが最も変動する方向を示します。最初の主成分は最も高い変位を捕捉し、二番目の主成分は次に高い変位を捕捉し、以降の主成分では同じことを繰り返していきます。そして、これらの主成分からデータを再構成し、オリジナルのエンべディングと比較することで、再構成のエラーを計測します。高い再構成エラーは、いくつかのエンべディングが多数派よりも大きく異なっている可能性があり、潜在的な異常をハイライトしていることを示しています。
以下の例では、あるベンダーから購入した製品のエンべディングの2つの主要なPCAコンポーネントを可視化しています。色の勾配は再構成エラーの度合いを示しています。高いほど悪いことになります。このベンダーCloud Softwareから購入した特定セットの製品は高い再構成エラーを示しており、我々が設定したエラー閾値(99thパーセンタイル)に基づいて異常とみなされます。
図3. 2つの異なるベンダーから購入した製品の再構成エラーと製品エンベディングのPCA。左のCloud Softwareは適切に異常と特定されています。右のBakery ToolsとDelivery Feesが異常と識別されています。
PCAによる異常検知のプロセスにおいては、再構成エラーの閾値の設定が重要であり、結果に重大なインパクトをもたらす場合があります。この閾値はどの再構成エラーを異常と見做すのかを決定します。異常を定義するには、99thパーセンタイルのように再構成エラーの高いパーセンタイルを選択することが一般的なアプローチとなります。しかし、この閾値は非常にセンシティブであり、選択には注意深いチューニングを必要とします。あまり低く設定していまうと、大量の偽陽性を引き起こす音になるでしょう。この閾値を設定する他の手法には、あなた固有のデータセットに最も効果的な閾値を特定するための、実践的な値を設定するためのドメイン固有の知識や、交差検証テクニックの活用などが挙げられます。この閾値のファインチューニングでは、真の異常の見地と偽陽性の最小化のバランスをとることが重要となります。
MLアプローチの限界
PCAはパワフルな異常検知ツールですが限界があります。大きな欠点の一つは、文脈的な要素を考慮することなしに再構成エラーに基づいて異常としてアイテムを判定してしまう場合があるということです。例えば、あるベンダーの製品リストには他の製品とともにdelivery charges(配送料)が含まれているとします。この場合、PCAはベンダーの提供内容の標準的なパーツであるにも関わらず、delivery chargesを異常として特定してしまうことがあります。この潜在的な偽陽性は、PCAが実際の文脈やビジネスロジックを考慮することなしに主にデータの数値的なパターンにフォーカスしていることによるものです。
さらに、PCAを含む従来のML異常検知アルゴリズムは、多くの場合解釈可能性に欠けており、シンプルに閾値を上回った以上の説明については限定的なものとなっています。なぜ特定の製品が異常と判別されたのかに関する明確な理由は提供せず、特に検知された以上が実際には正常かもしれない場合や、コンテキスト固有の変動の場合には結果の理解や検証を困難にします。ここで、生成AIが検知された異常に対して高度に文脈的な理解と、洞察に溢れた説明を提供する能力によって違いをもたらすことになります。
異常検知のための生成AI
大規模言語モデル(LLM)は、高度なテキスト処理能力を活用することで、異常検知に対して洗練されたアプローチを提供します。
文脈的なニュアンスを見落とすことのある従来の手法と異なり、LLMはそれぞれのベンダーの典型的なオファリングに対する深い理解を用いて、製品の説明文とその他のテキストデータを分析することができます。この能力によって、フラグが立てられた製品が本当に異常なのか、あるいはベンダーの通常の製品範囲に収まっているのかどうかをLLMに評価させることができます。
さらに、LLMはなぜ製品が異常と判断されたのかを説明することができ、結果の解釈可能性を高めます。このアプローチによって、複雑なデータに対するより深い分析を可能とし、よりアクション可能な洞察を生成することができます。
PCAモデルは異常な購買を特定しますが、コンテキストや一連の手順を示す、異常ではないと識別された購買もあるかもしれません。PCAモデルのスコアに基づいて異常とみなされたトランザクションを持つベンダーを評価し、それらのベンダーから購入した製品が異常あるいは正常と識別されたのかに関する評価結果に対する理由付けを行うようにLLMに指示することで、このソリューションをさらに改善することができます。
異常な購入を特定するために生成AIを適用
このユースケースでのLLM活用に対するもっともわかりやすいアプローチの一つは、調整したプロンプトを通じたfew-shot学習を用いることです。この手法には、何が異常に寄与し、なにが寄与しないのかに関する幾つかの例をモデルに提供し、新規データにおけるパターンや外れ値をLLMが認識できるようにガイドすることが含まれます。様々なシナリオを説明する特定のプロンプトを用いることで、LLMは製品や挙動が標準から大きく逸脱しているかどうかに関して、情報に基づいた意思決定を行うように事前学習した知識を活用することができます。このアプローチは比較的実装がシンプルで、履歴データとプロンプトで提供された文脈的な例に基づき、潜在的な異常に対してクイックに感知のある洞察を提供することができます。
あるベンダーから購入した製品リストに対するプロンプトの例です:
OUTLIER_PROMPT_TEMPLATE = """Imagine you are analyzing a list of products offered by a fictional company. The company specializes in certain types of products, but the specifics are not given. Use reasonable assumptions about what types of products a company with a given focus might offer. Your task is to identify any outliers in the list—products that do not fit well with what the company would typically provide. If the product list mainly suggests a certain type of product (like furniture or fruit), identify products that significantly differ from the rest. If all products could reasonably fit into a general theme or focus area, do not list any outliers.
*DO NOT consider as outliers any transportation, delivery, courier or freight services or charges as they are usualy related to the delivery of parts a company produces.*
Your output should be in JSON format.
Examples:
- Products: ["apple", "kiwi", "strawberry", "bread", "COURIER SERVICES"], Output: {{"outliers": ["bread"], "reason": "bread is not a type of fruit, which is what the company seems to specialize in."}}
- Products: ["chair", "table", "sofa", "bed", "refrigerator", "tree"], Output: {{"outliers": ["refrigerator", "tree"], "reason": "refrigerator and tree are not typical furniture items, which appears to be the company's focus."}}
- Products: ["blue", "red", "yellow", "green", "freight services"], Output: {{"outliers": [], "reason": "All items are colors, and could plausibly be provided by the company."}}
# Products
{products}
"""
上の製品リストのアウトプットの例です:
この例では、異常な製品購入を特定したことに対して、価値のある洞察と説明をLLMが行っていることを示しています。しかし、時には結果は冗長で構造化されておらず、プロンプトで指定された特定のJSONフォーマットに常に準拠しているとは限りません。このような構造の欠如は、発見を自動化されたシステムやダッシュボードに直接連携する際に問題となることがあります。ここで、tools APIを用いることでアウトプットの品質を改善することができます。アウトプットに対する厳密なJSONスキーマを提供することができ、Foundation Model APIの推論サービスによって、モデルのアウトプットがこのスキーマに準拠することを確実にし、不可能な場合にはエラーを返すようにすることができます。
アウトプットにJSONフォーマットを強制するためにツールを呼び出す関数の活用例です:
tools = [
{
"type": "function",
"function": {
"name": "_outlier_detection",
"description": "Identifies outliers in the list of products",
"parameters": {
"type": "object",
"properties": {
"outliers": {
"type": "array",
"items": {"type": "string"},
},
"reason": {
"type": "string",
"description": "Reason for the item to be identified as an anomaly"
},
},
"required": [
"outliers",
"reason"
],
},
},
},
]
def prompt_with_outlier_tool(products: List[str]):
# Convert the list of products to a string format suitable for the LLM
products_str = "\n".join(products)
prompt = OUTLIER_PROMPT_TEMPLATE.format(products=products_str)
return call_chat_model(prompt, tools=tools)
ツールを呼び出す関数を用いることで、一貫性を持って構造化されたアウトプットを得ることができます:
ハイブリッドアプローチ
従来の異常検知モデルとLLMを組み合わせたハイブリッドアプローチによって、異常検知に対してより包括的なソリューションを提供することができます。
このアーキテクチャでは、統計的な属性やパターンに基づいて潜在的な外れ値を検知するために、エンベディングは初めにPCAやクラスタリングアルゴリズムのような従来の異常検知モデルに引き渡されます。このステップでは、異常を特定するための予備的なフィルターを提供します。そして、より深い文脈的な理解や説明を提供できるLLMによって結果が分析されます。LLMは特定の製品がなぜ異常とフラグ付けされたのかを明確にし、解釈可能性に欠ける場合がある従来のモデルの限界に対応します。この2ステップのプロセスでは、両方のアプローチの強みを活用しています: 従来のモデルの統計的な厳格さとLLMの詳細かつ文脈を考慮した洞察です。
図4. 異常検知ハイブリッドソリューションのパイプライン
購買データによる我々の例では、このハイブリッドアプローチは劇的に偽陽性を削減し、より正確でアクション可能な結果をもたらすことにおける有用性を示しています。配送料、輸送量によって異常な購買製品とフラグがつけられたあるベンダーが、LLMによって偽陽性と識別されているという一例があります。
図5. 従来のML異常検知器による偽陽性をLLMが検知
このソリューションは、評価データセットと人間のフィードバックによって評価されました。ハイブリッドアプローチにおいては、LLMのアウトプット(毒性、トークン数、レーテンシーなど)に対してすぐに利用できるメトリクスとMosaic AIエージェントフレームワークを用いたり、カスタムメトリクス、拡張メトリクスにLLM as a judgeを追加することで、評価を拡張することができます。
なぜLLMを使うだけでなくハイブリッドアプローチを用いるのか？
LLM単体でも強力な異常検知やリッチなコンテキストを提供可能ですが、これらは特に大量の調達購買を取り扱う際には計算量的に高価なものとなります。このハイブリッドアプローチによって、より効率的なモデル(従来のML異常検知モデルなど)が大規模な異常検知に対応しつつも、エッジケースに対して意味のあるコンテキストや説明を追加するためにLLMを活用できるようにします。このバランスによって、コストを低く抑えつつも精度や解釈可能性を維持する助けとなり、このソリューションをよりスケーラブルなものにします。
まとめと次のステップ
この記事では、従来の機械学習モデルと生成AIがどのように互いの強さを補い合うのかを説明しました。従来の異常検知MLモデルとLLMの解釈能力を組み合わせることで、企業は異常な勾配の特定を円滑にすることができます。このアプローチは、潜在的に不正なトランザクションにフラグを立てる時間を劇的に削減し、業界における多数の潜在的なアプリケーションをハイライトするものです。
しかし、すべてのアプリケーションが劇的な効果を出すわけではないので、LLMを異常検知システムに組み込む際には、投資対効果(ROI)を検討することが重要です。偽陽性を削減することが重要なシナリオ、フラグがつけられたトランザクションに対しる明確な説明を提供することが重要なシナリオにおいては、このインテグレーションによって大きなメリットを享受することができます。
次のステップや改善に関しては、オプションの一つには意思決定プロセスを強化するために、ベンダーとの契約や関連ドキュメントから追加の文脈を組み込むことが挙げられます。
他のオプションには、モデルの異常検知能力を強化するために、不正な購買と立証されたデータセットで小規模なLLMをファインチューニングすることが挙げられます。しかし、これには合成データ生成テクニックの活用なしに獲得することが困難な数千のサンプルを持つ高品質データセットが必要となります。
このハイブリッドアプローチについてどう思いますか？これらの技術の実装で課題に直面したことがありますか？以下のセクションのコメントで、あなたの経験や洞察を共有することで会話に参加してください