非結構化與半結構化資料擷取
發票處理本應是一個已解決的問題。文件到達，欄位被提取，資料與現有記錄進行驗證，結果被路由到正確的系統。現實情況是，僅發票處理每年就讓企業在人工勞動上花費數十億，而那些本應解決這個問題的自動化專案卻一再崩潰。
原因在於格式多樣性。發票以 PDF、電子郵件附件、掃描影像、試算表匯出，偶爾還以傳真形式到達。每個供應商使用不同的版面配置。行項目出現在表格、自由文字或兩者的組合中。稅收計算遵循不同司法管轄區的不同規則。貨幣格式不同。日期格式不同。甚至同一供應商也會在沒有任何通知的情況下更改發票範本。
傳統 RPA 用範本比對來處理這個問題：定義發票號出現的座標、行項目開始的位置、合計所在的位置。對單一供應商的目前範本有效。然後供應商更新了他們的系統，移動了一列，新增了一個標題列，或更換了 PDF 產生器，機器人要麼徹底失敗，要麼提取出垃圾資料，一直傳播到下游，直到有人手動發現。
同樣的模式在每個非結構化資料工作流程中重複上演。當支付方更改表單版面配置時，保險 EOB 處理崩潰。當新文件類型被新增到流程中時，預授權接收崩潰。當有人使用略有不同的主旨行格式時，客戶郵件解析崩潰。維護這些自動化的成本往往超過手動完成工作的成本。
Triggerfish 的解決方案
Triggerfish 用基於 LLM 的文件理解取代了基於座標的欄位提取。AI 像人類一樣閱讀文件：理解情境、推斷欄位之間的關係、自動適應版面配置變化。結合用於流水線編排的工作流程引擎和用於資料安全的分類系統，這建立了即使世界發生變化也不會崩潰的擷取流水線。
LLM 驅動的文件解析
當文件進入 Triggerfish 工作流程時，LLM 子代理基於文件的含義而非特定像素的位置來提取結構化資料。發票號就是發票號，不管它是在右上角標著"Invoice #"，還是在頁面中間標著"Factura No."，或者嵌在一段文字中。LLM 理解"Net 30"意味著付款條件，"Qty"和"Quantity"和"Units"含義相同，而一個帶有說明、費率和金額欄的表格，不管欄位順序如何都是行項目清單。
這不是"把文件發給 ChatGPT 然後碰運氣"的通用方法。工作流程定義精確指定了 LLM 應該產生的結構化輸出、適用的驗證規則，以及當提取信心度較低時的處理方式。子代理任務說明定義了預期的 Schema，工作流程的後續步驟在資料進入任何下游系統之前，會根據業務規則驗證提取的資料。
用於文件擷取的瀏覽器自動化
許多文件擷取工作流程首先需要取得文件本身。保險 EOB 存在於支付方入口網站。供應商發票存在於供應商平台。政府表單存在於州政府機構網站。傳統自動化使用 Selenium 指令碼或 API 呼叫來取得這些文件，當入口網站發生變化時這些指令碼就會崩潰。
Triggerfish 的瀏覽器自動化使用 LLM 讀取頁面快照來導航的 CDP 控制 Chromium。代理像人類一樣看待頁面，而不是將其視為 DOM 樹，基於所見而非硬式編碼的 CSS 選擇器進行點擊、輸入和捲動。當支付方入口網站重新設計其登入頁面時，代理能夠適應，因為它仍然可以從視覺情境中識別使用者名稱欄位、密碼欄位和提交按鈕。當導航選單發生變化時，代理會找到文件下載區段的新路徑。
這並不意味著完全可靠。CAPTCHA、多因素驗證流程和高度依賴 JavaScript 的入口網站仍然會造成問題。但失敗模式從根本上不同於傳統指令碼。當 CSS 選擇器停止比對時，Selenium 指令碼會悄然失敗。Triggerfish 代理會回報它看到了什麼、嘗試了什麼以及在哪裡卡住了，給營運人員提供足夠的情境來介入或調整工作流程。
分類閘控處理
文件具有不同的敏感度級別，分類系統會自動處理這一點。包含定價條款的發票可能是 CONFIDENTIAL。公開的招標回應可能是 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 個不同提供者診所的預授權請求，每個診所使用自己的表單版面配置，有些透過傳真，有些透過電子郵件，有些上傳到入口網站。傳統方法需要一個八人團隊手動審查和輸入每個請求，因為沒有自動化工具能夠可靠地處理格式多樣性。
使用 Triggerfish，工作流程處理完整的流水線。瀏覽器自動化或郵件解析取得文件。LLM 子代理不管格式如何都能提取結構化資料。驗證步驟根據 EHR 和處方集資料庫檢查提取的資料。RESTRICTED 的分類上限確保 PHI 不會離開流水線邊界。LLM 無法以高信心度解析的文件被路由給人工審查員，但隨著代理的記憶建構格式模式庫，這個量會隨時間減少。
八人團隊變成了兩人處理系統標記的例外，加上對自動提取的定期品質稽核。來自提供者診所的格式更改被自動吸收。新的表單版面配置在第一次遇到時就得到處理。曾經消耗大部分傳統自動化預算的維護成本降至接近零。