GenieとAIエージェントを活用した太陽光・風力メンテナンスレポートの変革

メンテナンスPDFからAIエージェントによる実用的なインサイトへ

太陽光や風力発電所の運用・保守（O&M）サプライヤーは、通常、レポートをPDF形式で提供します。そこでは、重要な情報がフリーテキスト、表、画像に分散しています。このフォーマットは閲覧には便利ですが、拡張性がありません。アセットの数が増えるにつれて、チームは障害、傾向、繰り返し発生する問題を把握するために各ドキュメントを手作業で読み込む必要があり、発電所間の比較に時間がかかり、一貫性も失われます。

PlenitudeとDatabricksは、これらのPDFメンテナンスレポートを構造化データに変換するエージェントベースのシステムを構築しました。核となるアイデアはシンプルです。ドキュメントをデータに変換し、AIエージェントを使用してそのデータから実用的なインサイトを導き出すというものです。ユーザーはレポートを1つずつ確認する代わりに、自然言語で質問し、経時的な傾向を分析し、発電所を比較し、構造化された出力をエクスポートできるようになりました。

PDFからデータ分析を行うためのエージェントベースのアーキテクチャ

このソリューションは、発電所レベルのPDFレポートのイベント駆動型取り込みから始まります。新しいレポートが追加されるたびにDatabricksのジョブがトリガーされ、ドキュメントを解析してLLMベースの抽出を適用します。抽出された要素はJSONとしてシリアル化され、Delta Lakeに保存されます。Delta Lakeは、監査や再実行のための完全なバージョン履歴を保持します。

メンテナンス情報がほぼ完全に非構造化PDF内に存在するという根本的な課題に対処するため、PlenitudeはDatabricks Document IntelligenceのAI Functions（具体的にはai_parse_document）を使用して、テキストブロック、表、図、メタデータなど、各ページから複数種類の要素を抽出しています。各要素には、発電所、レポート対象期間、ページ番号、コンテンツタイプなどの属性が付与され、すべてのレコードはトレーサビリティのために元のレポートへの直接リンクを保持します。

この構造により、強力な機能が解放されます。

• 時間、カテゴリ、地域によるフィルタリング。
• コンテンツタイプの特定と空間座標の使用。
• すべてのインサイトを元のPDFまで遡って追跡。
• 元のドキュメントを変更することなく、BIツールやデジタルエージェントと統合。

メンテナンスレポートは、静的なファイルではなく、高度な分析やエージェントによる推論に対応した永続的なデータレイヤーになります。

Databricksでのデータ処理：PDFからDelta Lakeへ

このアーキテクチャは、取り込みと解析、データの構造化、エージェントベースのインタラクションという3つの主要なレイヤーで構成されています。

ステップ1：解析

ai_parse_documentを使用することで、パイプラインは各ページからテキスト、表、メタデータを抽出し、構造化されたJSONオブジェクトとしてシリアル化します。複雑な表であっても、ページ上の位置やHTML表現を含む完全なコンテキストとともにキャプチャされます。

ステップ2：正規化と保存

すべてのページ（page_id）およびオブジェクト（id）について、システムはDelta Lakeテーブルに1つの行を作成します。各行には以下が含まれます。

• 抽出されたJSONコンテンツ。
• ページおよびオブジェクトの識別子。
• ページ上のバウンディングボックスを表す座標（coords）。
• コンテンツタイプ（テキストや表など）。
• 月、年、ファイル名、カテゴリ、国などの価値の高いメタデータ。

この正規化されたモデルにより、PDFは統合されたクエリ可能なデータセットに変換されます。元のドキュメントへの完全なトレーサビリティを維持しながら、透明性が高く、他のデータソースとの結合も容易になります。

ステップ3：Genieスペースとエージェントモード

この整理されたデータレイヤーの上に、Plenitudeは専用のGenieスペースを構築し、Genieのエージェントモードを活用してデータに対するディープリサーチを実行します。Genieは、構造化されたDelta Lakeテーブルを主要なコンテキストとして使用し、ユーザーが自然言語を使用してメンテナンスデータと対話できるようにします。

ユーザーが質問すると、Genieは以下を行います。

• Unity Catalog内のセマンティックメタデータを使用して、利用可能なテーブルと列を特定します。
• 詳細な列の説明、整理されたナレッジストア、SQLサンプルを活用して、クエリ生成をガイドします。
• 構造化レイヤーに対してSQLを生成し、実行します。
• 回答、可視化結果、および必要に応じてエクスポート可能な結果を返します。

この設計により、Genieはメンテナンスデータのビジネスセマンティクスとその基礎となる構造の両方を理解できるようになり、正確でコンテキストを考慮した回答が得られます。

なぜGenieにとってメタデータと指示が重要なのか

複雑なPDF由来のデータセットから信頼性の高い結果を得るには、コンテキストだけでは不十分です。Plenitudeは、豊富なメタデータとGenieスペースに対する明示的な指示という2つの設計パターンが極めて重要であることを発見しました。

エージェントとの契約としてのメタデータ

適切に定義されたテーブルと列の説明は、各フィールドの意味と使用方法をGenieに伝えます。たとえば、page_idは元のレポートのソースページを特定し、typeは要素がテキストか表かを示し、coordsは空間的な位置をエンコードし、contentには抽出されたテキストまたは表の表現が含まれます。このメタデータにより、生のJSONが、Genieが推論できる理解可能な知識に変換されます。

運用の基盤としての一般的な指示

データが断片化している場合や複数ページにわたる場合、Genieスペースのローカルなナレッジストアに追加されるドメイン固有の指示が不可欠になります。Plenitudeは、複数ページの表の処理、HTMLアーティファクトの無視、ヘッダー行の除外、発電所固有のフィルターの適用に関するルールをエンコードしています。

具体的な例として、完全なメタデータがあっても、GenieがYTD（年初来）の列を合計したり、欠落している月を無視したりすると、誤った四半期合計を計算してしまう可能性があります。「YTDフィールドは使用せず、月レベルの列のみを使用すること」、「合計する前に必要なすべての月が存在することを確認すること」といった明確な指示を追加することで、チームはGenieに運用のガードレールを提供し、一貫した結果を保証します。

これらのGenieスペース固有の指示は、Unity Catalogからのメタデータと組み合わせることで、Genieが正しいロジックを適用してデータを正確に解釈するのに役立ちます。

拡張可能なエージェントワークフローのためのGenieとAgent Bricksの活用

Genieは構造化されたメンテナンスレイヤーの上で強力なリサーチエージェント体験を提供しますが、Plenitudeは、増え続けるユースケースをサポートするために、再現可能なワークフローとオーケストレーションも必要としています。Agent Bricksは、その進化における次のステップです。

Agent Bricksを使用することで、Plenitudeは「LLM＋プロンプト」のパターンから、メンテナンスアナリストやエンジニアに代わって一連のアクションを実行するエージェント型ワークフローへと移行できます。Genieを動かすものと同じ、整理されたDelta Lakeテーブル、メタデータ、指示は、Agent Bricksで構築されたスーパーバイザー型のエージェントによって再利用され、以下のことが可能になります。

• 複雑な質問をより小さな分析タスクに分解する。
• Genieのツールフローを呼び出してSQLを生成し、実行する。
• レポート作成やアラート生成などのダウンストリームアクションをトリガーする。

これまでプロンプト、ツール、検証ロジックの手動での連携が必要だった作業を、データを管理するのと同じDatabricksプラットフォーム上のAgent Bricksに一元化できるようになりました。

自動リキッドクラスタリングによるパフォーマンスの最適化

エージェント駆動型のクエリは探索的かつ動的であるため、従来のZ-ORDERベースのチューニングが常に最適とは限りません。Plenitudeは、新しいレポート、ユーザー、質問が登場するにつれてアクセスパターンが変化するため、手動でのクラスタリングの維持が困難になることに気づきました。

対照的に、自動リキッドクラスタリングはテーブルが実際にどのように使用されているかを学習し、それに応じてレイアウトを適応させます。これにより、事前のインデックス設計や継続的なチューニングの必要性が減ります。これは、概念実証や初期の稼働フェーズにおいて特に重要です。このような状況において、Deltaテーブル上のエージェントおよびLLM駆動型のワークロードには、自動クラスタリングが推奨される選択肢となります。

Genie Roomのデータアクセスの保護

メンテナンスデータには、国や地域固有のアクセス要件が存在することがよくあります。これらのルールを一貫して適用するために、PlenitudeはUnity Catalogおよびテーブルと組み合わせて行レベルのセキュリティを使用しています。

Unity Catalogの関数が、現在のユーザーがアクセスできる国を判定し、リスト、または完全な閲覧権限がある場合はキーワード「ALL」を返します。その後、テーブルがその関数に基づいて行をフィルタリングするため、各ユーザーにはアクセスを許可された国のデータのみが表示されます。

ユーザーがGenie Roomを介してやり取りする場合、すべてのクエリはフィルタリングされたテーブル上で実行されるため、行レベルのセキュリティが自動的に適用されます。つまり、ユーザーは自然言語で質問できますが、閲覧を許可されているデータからのみ結果を受け取ることができます。同じデータセットがGenie、エージェント、BIツールを駆動し、閲覧権限はユーザーごとに調整されます。

今後の改善：予知保全に向けて

メンテナンスレポートには未解決のインシデントや障害の詳細が含まれているため、構造化データモデルは予知保全の強力な基盤となります。インバーターが良い例です。故障が発生すると1台あたり数メガワット時の損失につながる可能性があり、繰り返し発生する問題は多くの場合、最初にメンテナンスノートに現れます。

経時的な障害パターンを分析することで、Plenitudeは以下を行うことができます。

• 記録に関する潜在的な問題を特定する。
• 早期警告シグナルを検出する。
• より詳細な調査が必要なプラントを優先する。
• より高品質なインシデント履歴を予測モデルに提供する。

エージェントベースのシステムは、これらのシグナルをアクセスしやすい分析、トレンド、可視化に変換するため、チームは単に対処するだけでなく、問題を予測できるようになります。

主なメリットと機能

以前のアプローチでは、分析はレポートを個別に読むことに限定されていたため、過去のトレンドの構築、プラントの比較、構造化された出力の生成が困難でした。チャートの作成、結果のエクスポート、または複数のレポートからのインサイトの統合は、よくて手動で行う必要があり、多くの場合、実現不可能でした。

Databricks上のGenieエージェントモードとエージェントフレンドリーなデータモデルにより、Plenitudeは以下を行うことができます。

• 時間やプラントを横断してメンテナンスデータを探索する。
• 可視化を生成し、PDF出力を含む結果をエクスポートする。
• 早期シグナルや繰り返し発生するパターンを検出する。
• 手動の労力を増やすことなく、分析をスケールさせる。

構造化データ、ビジネスメタデータ、AI推論を組み合わせることで、システムは単なる事後報告にとどまらず、問題の早期検出と予測をサポートする分析、トレンド、可視化を生成します。

Databricks GenieおよびAgent Bricksの詳細をご覧ください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事