非構造化データおよび半構造化データの取り込み
請求書処理はもう解決済みの問題であるべきです。文書が届き、フィールドが抽出され、データが既存レコードに対して検証され、結果が適切なシステムにルーティングされる。現実には、請求書処理だけでも企業が年間数十億ドルを手作業に費やし、それを解決するはずの自動化プロジェクトが絶えず壊れています。
理由はフォーマットの多様性です。請求書は PDF、メール添付ファイル、スキャン画像、スプレッドシートエクスポート、時にはファクスとして届きます。各ベンダーは異なるレイアウトを使用します。行項目はテーブル、フリーテキスト、またはその組み合わせで表示されます。税計算は管轄によって異なるルールに従います。通貨フォーマットも異なります。日付フォーマットも異なります。同じベンダーでも予告なく請求書テンプレートを変更します。
従来の RPA はテンプレートマッチングでこれを処理します。請求書番号が表示される座標、行項目の開始位置、合計金額の場所を定義します。単一ベンダーの現在のテンプレートには機能します。そしてベンダーがシステムを更新し、列をずらし、ヘッダー行を追加し、PDF ジェネレーターを変更すると、ボットは完全に失敗するか、誰かが手動で気づくまで下流に伝播するゴミデータを抽出します。
同じパターンがあらゆる非構造化データワークフローで繰り返されます。ペイヤーがフォームレイアウトを変更すると保険の EOB 処理が壊れます。新しい文書タイプがプロセスに追加されると事前承認受付が壊れます。誰かが少し異なる件名フォーマットを使うと顧客メール解析が壊れます。これらの自動化を維持するコストは、手動でその作業を行うコストを上回ることがよくあります。
Triggerfish の解決方法
Triggerfish は座標ベースのフィールド抽出を LLM ベースの文書理解に置き換えます。AI は人間が読むように文書を読みます:コンテキストを理解し、フィールド間の関係を推論し、レイアウトの変化に自動的に適応します。パイプラインオーケストレーション用のワークフローエンジンと、データセキュリティ用の分類システムと組み合わせることで、世界が変わっても壊れない取り込みパイプラインが作られます。
LLM 駆動の文書解析
文書が Triggerfish ワークフローに入ると、LLM サブエージェントは特定のピクセルの位置ではなく文書の意味に基づいて構造化データを抽出します。請求書番号は、右上隅に「Invoice #」というラベルがついていても、ページ中央に「Factura No.」というラベルがついていても、テキストの段落の中に埋め込まれていても、請求書番号です。LLM は「Net 30」が支払条件を意味し、「Qty」「Quantity」「Units」が同じ意味であり、説明・レート・金額の列を持つテーブルは列の順序に関係なく行項目リストであることを理解します。
これは「文書を ChatGPT に送って期待する」という汎用的なアプローチではありません。ワークフロー定義は LLM が生成すべき構造化出力、適用される検証ルール、抽出の信頼度が低い場合の処理を正確に指定します。サブエージェントのタスク説明は期待されるスキーマを定義し、ワークフローの後続ステップは抽出されたデータが下流システムに入る前にビジネスルールに対して検証します。
文書取得のためのブラウザ自動化
多くの文書取り込みワークフローはまず文書を取得することから始まります。保険の EOB はペイヤーポータルにあります。ベンダー請求書はサプライヤープラットフォームにあります。政府フォームは州機関のウェブサイトにあります。従来の自動化は Selenium スクリプトや API 呼び出しを使ってこれらの文書を取得し、ポータルが変更されるとそれらのスクリプトが壊れます。
Triggerfish のブラウザ自動化は、LLM がページスナップショットを読んでナビゲートする CDP 制御の Chromium を使用します。エージェントは DOM ツリーとしてではなく、人間と同じようにページを見て、ハードコードされた CSS セレクターではなく見えるものに基づいてクリック、入力、スクロールします。ペイヤーポータルがログインページをリデザインすると、エージェントはビジュアルコンテキストからユーザー名フィールド、パスワードフィールド、送信ボタンを特定できるため適応します。ナビゲーションメニューが変わると、エージェントは文書ダウンロードセクションへの新しいパスを見つけます。
これは完全に信頼性があるわけではありません。CAPTCHA、多要素認証フロー、JavaScript への依存度が高いポータルは依然として問題を引き起こします。しかし、失敗モードは従来のスクリプトと根本的に異なります。CSS セレクターのマッチングが停止すると Selenium スクリプトは無言で失敗します。Triggerfish エージェントは何を見たか、何を試みたか、どこで詰まったかを報告し、オペレーターが介入またはワークフローを調整するのに十分なコンテキストを提供します。
分類ゲートによる処理
文書はさまざまな感度レベルを持ち、分類システムは自動的にこれを処理します。価格条件を含む請求書は CONFIDENTIAL かもしれません。公開 RFP レスポンスは INTERNAL かもしれません。PHI を含む文書は RESTRICTED です。LLM サブエージェントが文書を読んでデータを抽出すると、POST_TOOL_RESPONSE フックが抽出されたコンテンツを分類し、セッション taint がそれに応じてエスカレーションします。
これは下流ルーティングにとって重要です。CONFIDENTIAL に分類された抽出請求書データを PUBLIC に分類された Slack チャネルに送ることはできません。PHI を含む保険文書を処理するワークフローは、抽出されたデータが流れることができる場所を自動的に制限します。書き下し防止ルールはすべての境界でこれを適用し、LLM にはそれを上書きする権限が全くありません。
医療や金融サービスにとって特に重要なのは、自動化された文書処理のコンプライアンスオーバーヘッドが劇的に減少することです。すべてのパイプラインのすべてのステップにカスタムアクセス制御を構築する代わりに、分類システムが均一に処理します。監査担当者は、処理されたすべての文書、抽出されたデータ、送信先、不適切な宛先にデータが流れなかったことを、すべてのステップで自動的に作成されるリネージ記録から追跡できます。
自己修復によるフォーマット適応
ベンダーが請求書テンプレートを変更すると、従来の自動化は壊れて、誰かが手動で抽出ルールを更新するまで壊れたままになります。Triggerfish では、LLM サブエージェントが次の実行で適応します。位置ではなく意味を読んでいるため、請求書番号、行項目、合計金額を引き続き見つけます。抽出は成功し、データは同じビジネスルールに対して検証され、ワークフローは完了します。
時間をかけて、エージェントはクロスセッションメモリを使用してパターンを学習できます。ベンダー A が他のベンダーにはない再在庫手数料を常に含む場合、エージェントは以前の抽出からそれを記憶し、それを探すことを知っています。特定のペイヤーの EOB フォーマットが常に調整コードを珍しい場所に置く場合、過去の成功した抽出のエージェントのメモリが将来のものをより信頼性高くします。
フォーマット変更が十分に重大で LLM の抽出信頼度がワークフローで定義された閾値を下回ると、ワークフローは推測する代わりに人間レビューキューに文書をルーティングします。人間の修正はワークフローを通じてフィードバックされ、エージェントのメモリは将来の参照のために新しいパターンを保存します。抽出ルールを書き直す人なしに、システムは時間をかけて賢くなります。
パイプラインオーケストレーション
文書取り込みは単に「抽出して保存」ではありません。完全なパイプラインは文書を取得し、構造化データを抽出し、既存レコードに対して検証し、他のシステムからのデータで補完し、例外を人間レビューにルーティングし、検証済みデータをターゲットシステムにロードします。ワークフローエンジンはこれすべてを単一の YAML 定義で処理します。
医療事前承認パイプラインは次のようになります:ブラウザ自動化がプロバイダーポータルからファクス画像を取得し、LLM サブエージェントが患者識別子と処置コードを抽出し、HTTP 呼び出しが患者を EHR に対して検証し、別のサブエージェントが臨床文書に基づいて承認が医学的必要性基準を満たすかどうかを評価し、結果は自動承認または臨床レビューキューのどちらかにルーティングされます。すべてのステップが分類追跡されます。PHI のすべての部分が taint タグ付けされます。完全な監査証跡が自動的に存在します。
実際の使用例
ある地域医療システムは、40 の異なるプロバイダー事務所からの事前承認依頼を処理しています。各事務所は独自のフォームレイアウトを使用し、一部はファックス、一部はメール、一部はポータルにアップロードします。従来のアプローチでは、フォーマットの多様性に信頼性を持って対応できる自動化ツールがなかったため、8 人のチームが各依頼を手動でレビューして入力する必要がありました。
Triggerfish では、ワークフローが完全なパイプラインを処理します。ブラウザ自動化またはメール解析が文書を取得します。LLM サブエージェントがフォーマットに関係なく構造化データを抽出します。検証ステップが抽出されたデータを EHR と処方集データベースに対してチェックします。RESTRICTED の分類上限により PHI がパイプライン境界外に出ないことが保証されます。LLM が高信頼度で解析できない文書は人間レビューにルーティングされますが、そのボリュームはエージェントのメモリがフォーマットパターンのライブラリを構築するにつれて減少します。
8 人のチームは、システムがフラグを立てた例外を処理する 2 人になり、自動化抽出の定期的な品質監査が加わります。プロバイダー事務所からのフォーマット変更は自動的に吸収されます。新しいフォームレイアウトは初回に対応されます。従来の自動化予算のほとんどを消費していたメンテナンスコストがほぼゼロになります。
