重機メンテナンスへの洞察を革新するGenAI

Published: September 5, 2024

製造1分未満

Trevor Giannetti (Kubrick)、ヤヒヤ・ラディワラ（Kubrick）、ジャロン・ホルム（Kubrick）、神戸陳（キューブリック）、ヤレド・グデタによる投稿

重機械資産、例えば油田、農業用コンバイン、車両のフリートのメンテナンスは、グローバル企業にとって非常に複雑な課題をもたらします。これらの資産はしばしば世界中に広がっており、そのメンテナンススケジュールやライフサイクルは通常、企業全体のレベルで決定されます。主要なコンポーネントの故障は、1日あたり数百万ドルの収益損失をもたらすだけでなく、顧客への下流への影響も生じます。そのため、多くの企業が、これらの資産が毎日生成するテラバイト単位のデータから洞察を得るために、生成的AIに頼っています。これらの洞察は、停電を予測し、メンテナンス、修理、運用（MRO）のワークフローを改善することで、大幅な時間とコストの節約を実現するのに役立ちます。

Kubrickは、Databricksのコンサルティングパートナーとして、業界を問わずクライアントと協力して、重機械のメンテナンス要件を予測し対応する能力を革新しています。これらの組織は、KubrickとDatabricksの技術と専門知識を活用することで、価値チェーン全体のビジネスの結果を改善し、市場リーダーシップを確立し、規制リスクを軽減しています。

MROを再稼働させる

COVID-19パンデミックが世界を停止させたとき、閉鎖された国境と休業した労働力により、私たちの製造供給チェーンをつなぐリンクが断たれました。運送・物流業界は、まず最初にこの混乱の影響を受け、財政的な損失を被りました。その後、エネルギー、農業、製造業が影響を受けました。

しかし、供給チェーン全体のビジネスは、顧客が新たな支出（および旅行）習慣を採用したため、現在、パンデミック前のビジネスレベルを超える寸前にあります。この劇的な回復は、航空会社、貨物、物流などの業界がOEMからの生産遅延による供給制約に直面しているという、パンデミック中に製造業が停止したときの波及効果から、自身の一連の課題をもたらします。これらの超競争的な産業では、修理の遅延を最小限に抑え、車両や機械の能力を最大限に引き出すことが、利益を得るために不可欠です。

重機械に依存する多くの企業は、競争力を維持するために必要な効率向上を達成するために、次世代技術を求めています。データとAIをMROに成功裏に導入するための鍵は、まず具体的な価値を生み出すユースケースを特定し、その後、コストを削減し収益を増加させるロードマップを作成することです。Kubrickは、DatabricksとNeo4jとのパートナーシップで、メンテナンスライフサイクル全体の技術運用を強化する革新的なソリューションを設計しました。

MRO＆供給変革の課題と機会

重機械や車両のフリートを持つ企業にとって、メンテナンス費用は貸借対照表の重要な部分であり、しばしばその結果を決定します。メンテナンス費用は、航空会社、貨物、船舶会社の支出で3番目に高く、燃料と従業員の給与に次ぐものです。一方、MRO業界全体は、限られたツールとリソースを競うビジネスが増えることで、今後数年間で500億ドル増加すると予想されています。

しかし、メンテナンス費用は、データとAIツールを用いて最適化する大きな可能性を持っており、重機を利用するビジネスにとっては、利益率と収益を大幅に変える主要な焦点となっています。データとAIの改善の余地は次のとおりです：

速度と精度：現在のデータログ取得プロセスは最大24時間かかることがあります。
手動データ取得、分析、報告：メンテナンスイベントの手動ログと分析は、根本原因の問題を特定する際の不正確さを生み出し、コストを増加させ、技術者の時間を無駄にする失敗した解決策を引き起こす可能性があります。
データの孤立：MROライフサイクル全体でのデータソース間の接続性の欠如は、供給チェーン、メンテナンス問題、解決文書、規制コードの相互関連する課題への可視性を制限します。
競争リスク：高度な分析がなければ、ビジネスは迅速に対応し、問題を予測するのが難しくなります。

メンテナンス作業の大部分は、車両や機器の安全性と性能に影響を与える欠陥、不規則性、故障の特定に焦点を当てています。これらの欠陥を特定し対処する典型的なプロセスは手動で遅く、課題を予測し対処するのが難しいです。

この課題はMROのライフサイクル全体で複雑化し、欠陥の診断と解決に困難を生じさせます。問題には：

メンテナンス問題の記録処理の遅延（最大24時間）
部品の利用可能性に対する供給チェーンとの限定的な相関
特定の問題に対処するためのメンテナンスエンジニアの可視性の欠如
メンテナンスイベントとその技術的解決策との間にはほとんど相関性がありません。エンジニアは、解決要件を見つけるために、大量の文書を手動で検索しなければならず、応答時間が遅くなります。これは、問題と合わない解決策をもたらし、不必要な複雑さ/コストを追加する可能性があります。
解決策を予測するための限定的な歴史記録

これらの要素の組み合わせは、問題への対応に数時間から数日かかることを意味し、重機の利用率が低下し、貨物輸送が遅延したり、旅客機が地上に留まったりする結果となります。結局のところ、非効率的な修理ソリューションの底線へのコストは、トップラインの収益も制限することができます。

一方、高度に手動的なデータ収集と分析は、規制当局の要件を満たすために必要な時間を延ばします。航空会社やエネルギー生産者など、メンテナンスの失敗が大々的に報道されている業界に対する公の目が鋭くなる中、規制遵守はこれまで以上に重要になっています。

これらの課題はまた、機会を提供します：最先端のデータとAIの能力は、より良い洞察を提供し、メンテナンスと供給チェーンの混乱を予測し、より迅速な対応を可能にし、フリートの利用を最大化し、高額な計画外の停電を避けることができます。

エンドツーエンドのソリューション

図1：エンドツーエンドのアーキテクチャ — *Figure 1: The End-to-End Architecture*

Kubrickは、複合AIシステムを開発し、Databricks Data Intelligence Platformを活用して、生のデータを価値あるビジネスインサイトにシームレスに変換し、MROライフサイクルの多くの相互接続された課題に対応します。このソリューションは、ダッシュボードのシリーズとメンテナンスチャットボットとのインターフェースを持つ知識グラフによって駆動され、エンドユーザーにインサイトを提供します。高レベルでは、以下の要素で構成されています：

ソースシステム: 設備/車両部品のメンテナンスデータベースからのデータは、欠陥、作業指示、サービス停止イベント、さらには関連する規制/メンテナンスコードやマニュアルなどの関連するライブデータと履歴データと組み合わせられます。
取り込み: Azure Data Factory（ADF）、Fivetranなどのツールが、データの取り込みに使用されます
ストレージ: Microsoft AzureのAzure Data Lake Storage (ADLS) Gen 2がストレージに使用されます。
データ処理:すべての非構造化、半構造化、構造化ソースファイルは、Databricks Data Intelligence Platform上でDelta Live Tables (DLT)とストリーミングジョブを使用して処理され、Unity Catalog内にブロンズ、シルバー、ゴールドのテーブルを構築します。Unity Catalogは、各メダリオンアーキテクチャレベルの確立された基準を通じて、データガバナンス、整合性、系譜、高品質の監視を保証します。Neo4j Apache Spark™ Connectorは、Databricks Platformと知識グラフをリンクし、Unity Catalogから取り込まれたギガバイト単位のデータをシームレスに統合して、グラフに直接書き込まれる数百万のノードとエッジを作成します。これらのノードとエッジは、欠陥、部品、ステーション、メンテナンスエンジニアなどの間の関係です。最後に、関連する修理マニュアルの非構造化テキストは、Databricks Vector Searchに埋め込まれ、LLMsを使用した検索補強生成（RAG）のために使用されます。
データの視覚化: ナレッジグラフは、メンテナンスの問題、歴史的なフリートの健康状態、現在の作業指示、サービス外のイベント、欠陥などについて、上級ステークホルダーに対するビューを提供する複数のダッシュボードをサポートしています。
生成型AI: Databricks Mosaic AIは、エンドツーエンドの複合AIシステムを構築するために使用されます。Mosaic AI Model Servingは、テキストからCypherへの生成と、RAG対応のチャットボット、ResultsToTextモデル、および要約のためのジェネレータモデルを駆動する基本的なLlamaモデルのための微調整されたLlama 3モデルをホストするために使用されます。ユーザーのクエリがチャットボットに入力されると、適切なモデルが知識グラフと/またはMosaic AI Vector Searchをジェネレータモデルで要約し、両方の応答をクエリします。

Databricks Data Intelligence Platformは、データが効率的に処理され、モデルが安全な環境で提供されることを保証します。Kubrickのクライアントは、メンテナンスコストを削減する堅牢でスケーラブルなソリューションから利益を得ています。

メンテナンスソリューションのための生成AIの活用

図2：重機メンテナンスチャットボットアーキテクチャ — *Figure 2: Heavy Equipment Maintenance Chatbot Architecture*

LLMは、複雑な情報を理解しやすい、人間が読めるテキストに蒸留するためのユニークで最先端の機会を提供します。クーブリックの専用に設計されたアーキテクチャには、技術者専用に設計されたチャットボットが搭載されており、欠陥の解決時に時間を節約し、より完全なコンテキストを提供します。通常、チャットボットには、異なるタイプの質問に答えるための複数のエンドポイントがありますが、この機器保守チャットボットには、それぞれが別のエンドポイントに接続する2つの取得モデルがあります。

Neo4jエンドポイント：最初の取得モデル、TextToCypherは、Neo4jグラフデータベースから機器データを取得します。このモデルのコンポーネントは、テキストからCypherへの変換を容易にするために、Cypherデータで事前に訓練されたLlama 3モデルを活用します。Databricks Mosaic AIを利用することで、モデルは Databricks内のエンドポイントとしてデプロイされ、それを DsPy関数で呼び出します。DsPyは、シンプルで効果的なプロンプトエンジニアリングの利点を提供します。エンドポイントから生成されたcypherを取得した後、モデルはこのcypherコードを私たちのNeo4jデータベースで実行します。結果のデータは次にResultsToTextモデルに渡され、エンドユーザーが読める形式に変換されます。この出力は、欠陥、部品、ステーション、メンテナンスエンジニアなどの関係についての文脈を提供し、メンテナンスエンジニアにより多くの洞察を提供します。
RAGエンドポイント：2つ目の検索モデルは、RAG対応のチャットボットを使用する別のDatabricksエンドポイントです。チャットボットは、メンテナンスマニュアルや車両や機器に関連する他の書面による文書を含むMosaic AI Vector Searchインデックスに接続されています。提供される洞察は、機器、その部品、マニュアルに記載されたベストプラクティスに関する知識です。

これらのエンドポイントは両方とも明確な使用事例を持っています。例えば、メンテナンスチャットボットに特定の機器や車両についての質問があったとき、それはTextToCypherエンドポイントを問い合わせます、なぜならこの質問は知識グラフを使用して答えることができるからです。部品の規制についての質問の場合、マニュアルのテキストがこの質問に答えるために必要なので、RAG対応のエンドポイントが問い合わせられます。

しかし、メンテナンス作業員が特定の機器や車両の特定の問題を修正する手順について尋ねる場合、マニュアルには推奨される手順が記載されているかもしれませんが、グラフデータベースにはその機器や同じ問題を抱えた類似の機器に対して以前に取られた手順に関する有用な情報があるかもしれません。この場合、チャットボットはユーザーの質問を両方のモデルに送信し、包括的な情報を収集します。そして、両方のソースから関連情報が得られたら、別のエンドポイントが結果をエンドユーザーにとって読みやすく有用な形式に結合します。

このプロセスは、複数のエンドポイントを調整して、最も正確な洞察を保守エンジニアに提供し、複数のエンドポイントを呼び出す際の遅延を最小限に抑えます。まず、エンドポイントが互いの出力に依存していないため、クエリを同時にエンドポイントに送信します。これにより、両方が同時に実行できます。二つ目に、これはキャッシュを作成し、以前に質問がされ、正しく回答されたかどうかを確認し、そのキャッシュから結果を返すことで、将来のクエリの時間を短縮します。

Databricksを使用してFAQのキャッシング技術を実装することができます。最初のステップは、Deltaテーブルに保存されたFAQを収集し、頻度と関連性に基づいて質問をカテゴライズし、ランク付けするためにNLP技術を使用します。次に、ランク付けされたFAQはオンラインテーブルに保存され、ユーザーの行動や新しい質問の変化を定期的に反映するように更新され、UIに統合されてユーザーがカテゴリごとの最も頻繁に尋ねられる質問を見ることができます。最後に、技術者は新しい質問を提出する前にUIで関連するFAQカテゴリを確認することができ、重複した質問を減らし、ユーザーエクスペリエンスを向上させます。

モデルのパフォーマンスは、2つの重要な方法で評価されます。まず、別のLLMが、人間が読むことができるテキストを生成するすべてのモジュールの判断者として機能します。このLLM-as-a-judgeモデルは、生成された応答が質問に正確に答え、幻覚を避け、期待される出力形式に一致することを保証します。2つ目の評価方法は、TextToCypherモジュールを使用します。このモデルはコードを生成するため、人間が読むことができるテキストではないため、同じ方法で別のLLMによって評価することはできません。代わりに、Databricksの Managed MLflowでカスタム評価関数を使用します。この関数は、生成されたコードをKubrickのデータベースで実行してその機能を確認し、その結果を真実のコードが生成した結果と比較します。一致すると評価は正となり、不一致すると評価は負となります。

まとめ

Databricks Data Intelligence Platformを活用することで、Kubrickはクライアントの重機メンテナンス費用を数百万ドル削減できると見込んでおり、3年間の展開を通じて9桁を超える節約が見込まれます。Kubrickのソリューションの価値は、Delta Live Tables (DTL)、ストリーミングジョブ、Unity Catalog、Mosaic AIなどのDatabricksツールを適用することで、その全体がより効率的で強力になることから生まれます。クライアントと密接に連携し、メンテナンスの課題を理解し解決することで、KubrickはMROプロセスの大規模な変革を推進しています。KubrickのDatabricksとのパートナーシップによる提供能力とリソースについて詳しくは、[email protected]