企業可處理各種文件類型,包括發票、採購訂單、法律契約和技術手冊。手動處理速度緩慢、可能發生錯誤,且估計會耗用員工時間的 15–25%。先前的自動化方法 (例如,機器人流程自動化 (RPA)、光學字元識別 (OCR) 和工作流程工具) 減少了部分負擔,但產生了不穩定的管道、高維護負擔,以及個別業務小組間的獨立採用。
文件具有豐富的結構內容 (例如表格階層、空間欄位關係和交叉參照區段),而純文字處理無法保留。將文件取消為純文字會捨棄讓提取精確且實用的業務內容,進而降低下游分析、人工智慧 (AI) 推斷和流程自動化的品質。
為了有效,智慧文件處理 (IDP) 系統必須依類型將文件分類、精確地從變數版面配置提取結構化資料,並以受管理且可查詢的格式將資料傳送至下游系統。IDP 也必須大規模處理文件變異性,而不需要針對每個新文件格式設定每個範本,且必須在業務單位之間集中並可存取。此挑戰加強的是關鍵問題的大量:非結構化資料的帳戶佔所有企業資料的約 80%,大多數是在檔案系統、雲端儲存空間和超出 客戶關係管理 (CRM) 系統、AI 工作人員和分析平台的可用範圍的內容存放庫之間的文件形式累積。
Data 360 Document AI 是 Data 360 內的 Salesforce 文件處理功能,其設計目的為解決此差距。它會使用 大型語言模型 (LLM)、光學字元辨識 (OCR)、自然語言處理 (NLP) 和 機器學習 (ML) 來提取、分類和分析非結構化和半結構化文件內容。輸出是結構化、受管理且可查詢的資料,其會整合至 Data 360 管道中,Agentforce 工作人員、分析工具和自動化工作流程可透過標準介面存取資料,而不需要自訂採取或轉換層。
企業資料平台會處理結構化表格資料。然而,大多數的企業資料會以文件形式傳送,且在有人手動解壓縮之前,CRM、ERP、AI 工作人員和分析管道仍無法存取。這是結構性缺口,不是工作流程問題。
較早方法結合手動重新金鑰、以規則為基礎的 OCR 和 RPA 指令檔。這些方法在小規模運作,但無法處理現代企業產生之文件類型的量、多樣性和速度。以規則為基礎的工具需要每個版面配置變體明確的範本。任何格式變更都會中斷解壓縮,且需要開發人員、新範本和部署週期。
大規模而言,這會產生不具有集中管理、共用結構描述和 AI 整備路徑的脆弱點解決方案。不一致的解壓縮管道會在下游傳播。換句話說,分析會繼承資料不一致,AI 模型會產生不可靠的輸出,且如「個人健康資訊」(PHI) 和「個人可識別資訊」(PII) 等受監管內容缺乏系統化管理。
LLM 會將不含明確範本的欄位解壓縮。單一結構描述組態會管理跨版面配置變體、語言和格式的採取,這會適應文件,而非要求文件符合固定結構。這會將文件處理從維護繁重且隔離的作業轉為受管理的集中化功能。
Data 360 Document AI 透過兩個管道在 Data 360 平台內作業文件處理。
- 「批次銷售管道」 會透過採取、身分解析、已計算洞察、啟用、分析和 Agentforce 啟用來路由已解壓縮的資料。
- _交易處理管道_會顯示以同步方式傳回結構化 JSON 的 REST API,這可讓結構設計師將文件衍生的資料路由至 Salesforce SOobject、Data 360 Data Lake Object/Data Model Object (DLO/DMO) 管道或外部資料庫和倉庫,而無須額外進行批次設定。
在這兩種情況下,已解壓縮的資料會進入受管理、結構描述驅動的模型,而非一組分片的點數工具。
Data 360 Document AI 是 Salesforce Data 360 平台內原生「智慧文件處理」(IDP) 功能。它會將非結構化和半結構化文件內容轉換為受管理且可查詢的資料,以完整參與整個 Data 360 生命週期。
Data 360 文件 AI 是 Data 360 中 Salesforce 原生「 智慧文件處理」(IDP) 功能。系統會使用陳述性結構描述組態,將非結構化和半結構化文件、匯出結構化資料,並將該資料傳送至 Data 360 銷售管道進行調和、身分解析、分析和 Agentforce 啟用。
Data 360 Document AI 支援兩種處理模式:
- **大量批次處理:**以事件驅動為基礎處理在 非結構化資料模型物件 (UDMO) 中定義的大型文件集。
- **交易處理:**透過 REST API 處理單一文件,並同步傳回結構化 JSON 裝載。然後,結構設計師可以透過 MuleSoft、Apex 呼叫或 Einstein Trust Layer (ETL) 管道,將該裝載路由至 Data 360 DLO/DMO 管道、Salesforce SObjects 或外部資料庫和倉庫。目標層級是由延遲、管治和資料落地需求所驅動的結構性決策。
文件 AI 目前支援 PDF 檔案、影像檔案 (JPEG、PNG) 和手寫文件。
Data 360 Document AI 會將四種處理技術組合到單一受管理的管道中。每個元件都會處理文件對資料生命週期的不同階段:
- **光學字元辨識 (OCR):**在 LLM 處理之前,將掃描的影像、手寫內容和以影像為基礎的 PDF 轉換為機器可讀的文字。建議至少使用 150 DPI 以確保可靠的提取。
- **大型語言模型 (LLM):**使用使用者選擇的模型,藉由 Einstein LLM Gateway 路由取用。LLM 會在 JSON 結構描述組態旁接收 OCR 輸出,並傳回結構化解壓縮裝載。正在規劃使用 Gemini 和其他模型以進行未來實作。
- **自然語言處理 (NLP):**透過結構化提示工程,直接在 LLM 內執行內容瞭解、實體辨識、日期剖析和語意欄位解壓—結構描述定義的提示和 OCR 輸出會作為唯一的輸入。所有 LLM 互動都會透過 ETL 路由,這會與模型提供者強制保留零資料,並在其到達模型之前遮蔽文字輸入中的 PII。不會使用個別的 NLP 引擎。
- **多強制回應處理:**將 PDF 內嵌的影像處理為個別的解壓縮輸入,這可讓 LLM 從圖表、影像呈現的表格和 OCR 獨自無法剖析的混合內容頁面中提取資料。
除了四種處理技術外,Document AI 還可處理:
- **Einstein Trust 圖層:**透過 ETL 路由所有 LLM 互動,這會強制與模型提供者保留零資料,並在輸入到達 LLM 之前遮蔽 PII,但多重模式資料 (例如透過 Document AI 處理的附加文件) 除外,目前不支援 PII 遮蔽,且資料會依原狀傳送至外部模型。ETL 僅管理 LLM 互動路徑。寫入至「資料湖物件」(DLO) 的已解壓縮資料會依原狀儲存;靜態欄位級遮蔽必須透過下游資料管理控制來處理。
- 檔案大小限制:Document AI 可處理每個要求最多 10 MB 的檔案。LLM 內容長度限制可能會進一步限制在此邊界內密集且多頁的文件處理。
部署 Data 360 Document AI 的企業結構設計師應先套用這些原則,再認可實作設計。
- 設計結構描述前,請先選取銷售管道。_批次_與 _交易_處理管道的採取模式、結構描述繫結、目標彈性和延遲不同。在定義結構描述之前,確認每個使用個案需要的管道十分重要,因為重新調整會增加可避免的重試。
- **在文件類型層級設計結構描述。**針對每個文件類型使用單一精心設計的結構描述比使用各個使用個案組態更容易維護,而且這也是最大的一個提取品質杠杆。若要正確執行此操作,則需要使用多元化的文件集 (包括邊緣個案),而非從單一範例進行設計。在 欄位、_表格_和 _結構描述_層級以反覆方式使用提示來尋找間隙,然後在完成前對多個文件樣本進行測試和限定。請記住,適用於某一文件的結構描述可能不足於其他文件,因此寬度與迭代是必要的。結構描述彈性 (包括移除在文件類型之間無法可靠地解壓的資料欄) 同樣重要。保留產生雜訊或不一致的欄位會損害整體提取品質,因此將移除資料欄視為一流的設計決策十分重要。
- **選擇每個欄位群組正確的目標層級。**驅動 CRM 工作流程或批准的欄位會寫入至 SObject。增強統一設定檔或摘要分析的欄位屬於 DLO/DMO 銷售管道。提供外部系統的欄位屬於 RDBMS 層級。請記住,單一結構描述可能會同時呈現多個層級。
- **在處理受監管內容前強制執行監管。**受管理的資料在每個層級都需要保護。如此一來,在將解壓縮的資料儲存在輸出「_資料湖物件」(DLO) 中後,設定 PII 遮蔽、資料分類標籤和 以屬性為基礎的存取控制 (ABAC) 很重要。_這會根據資料分類、使用者角色和組織內容提供微調的強制執行與即時存取權。_管治_分成兩個路徑:_ELT _ 會管理 LLM 互動,而儲存在 DLO 中的解壓縮資料必須透過 _資料空間_組態、_權限集_和 ABAC 原則,直接在 DLO 和資料庫層級進行個別管理。這些控制必須維持儲存層的一致性,而不僅限於應用程式層級,因此無論如何存取資料後,存取限制都會保持不變。請記住,即使已正確設定其他資料,任何圖層中的間隙可能會向下顯示受監管的資料。
- **生產前失敗模式的設計。**在第一個生產批次執行之前,請先處理空值欄位處理、OCR 品質值,檔案大小預先驗證、LLM 內容溢出、RDBMS 寫入權限,以及信用額度預算限制。這些並非邊緣個案,這是可預測的失敗面,必須在管道設計中明確處理,且在執行階段不會發現。
- **將信賴分數視為一流的路由訊號,而非診斷後續的考量。**解壓縮結果會帶有從基本模型輸出之記錄機率 (logprobs) 衍生的欄位級信賴值。針對每個解壓縮的欄位、表格或欄,評分會反映模型中所解壓縮值的權杖級確度。這會使信賴分數成為以統計為基礎的訊號,其可靠性足以作為 人類循環 (HITL) 升級門值的主要門戶。使用信賴分數可系統識別低品質的提取,並針對低信賴欄位值、不明確的結構描述比對或重複的銷售管道失敗起始 HITL 檢查點,而不必依賴虛擬分析或手動點檢查。當無法自動復原時,HITL 支援的信賴評分可確保人類判斷完全適用於需要的位置。
- 與結構描述設計並列設計啟用路徑。_Document AI 的_價值來自於能夠在 Salesforce 工作流程和工作人員內啟用已解壓縮的資料。它可讓您設計 Agentforce Actions、Flow 和 Calculated Insights,並排解結構描述設計,而非之後。
Document AI 在兩個管道之內運作:
- 大量 UDMO 支援處理的 _批次_管道
- _交易_式_處理_管道,適用於即時、API 驅動的提取
兩種銷售管道皆共用相同的結構描述組態契約和 ETL 管理,但在文件進入系統的方式,以及解壓資料的到達位置方面不同。
讓我們進一步瞭解每個管道。
_批次_管道會處理由 UDMO 定義的循環文件集。其適用於排程或以事件為導向的使用個案,其中文件會從企業儲存空間中提取,然後通過文件提取,並傳送至 Data 360 DLO/DMO 管道進行調和、身分解析和啟用。
真實世界案例
每天,保險業者會收到來自提供者入口網頁的數千份醫療索賠文件,這些文件會以 PDF 形式上載至 Amazon S3。UDMO 會定義範圍文件集,並在 24 小時內將所有索賠 PDF 傳送至 /claims/incoming/ 分類。
系統會從企業來源系統將文件匯入至 Data 360 中,而不會實際重複。支援的來源包括 Amazon S3、Google Cloud Storage、Salesforce CRM 檔案物件、_MuleSoft 協調的_銷售管道,以及直接 API 上載。在 Headless 360 部署中,系統會透過雲端儲存連接器或略過 CRM 圖層的 「入院 API」 來提取文件。模型內容通訊協定 (MCP) 伺服器會針對外部 AI 工作人員和 LLM 用戶端,顯示為可呼叫工具。
此時,原始文件會儲存為「非結構化資料湖物件」(UDLO),這些物件會對應至每個文件的實體位置和中繼資料,而不會移動或轉換來源檔案。
範例:
索賠 PDF 會透過雲端儲存連接器從 _S3 _ 提取至 Data 360。每份文件都會儲存為指向 S3 物件的 UDLO。不會發生實體重複。
Document AI 會根據結構描述組態處理每個 UDLO,該組態會定義要與其目標資料類型一起解壓縮的欄位。UDMO 會定義哪些文件屬於範圍。LLM (GPT-4o、Gemini 或 Claude) 會讀取每份文件,並傳回結構化解壓縮裝載。
範例:
Document AI 會根據定義欄位的索賠結構描述處理每個 UDLO,例如:ClaimID、PatientName、DiagnosisCode、BillingAmount 和 ServiceDate。接著 LLM 會讀取每個 PDF,並傳回結構化解壓縮裝載。
解壓縮資料後,資料會持續存在於 DLO 中,這是 Data 360 的原始儲存層。DLO 會在不強制執行商業邏輯的情況下保留解壓縮的欄位,進而保留準確的實體呈現,以便進行下游轉換和追蹤。UDLO 會保留來源文件的參照,以在管道中的任何一處啟用欄位級歷程。
範例:
所有解壓縮的欄位都會落在「索賠 DLO」中,這會保留每個索賠的原始準確呈現,並包含可追溯回來源 PDF 的完整歷程。
DLO 欄位會對應至符合標準 Customer 360 Data Model 的 DMO。這是由文件衍生資料從原始且已解壓縮的欄位轉換至具有業務意義實體的邊界。發票 DLO 會對應至 發票 DMO,如 CustomerID 和 BillingAmount 等欄位會成為統一資料模型內的聯結索引鍵和比對屬性。協調文件資料透過與 CRM 和交易資料使用的相同介面參與區隔、_已計算洞察_和啟用。
範例:
索賠 DLO 會對應至 索賠 DMO。PatientID 和 PolicyNumber 欄位會變成聯結索賠記錄連結至統一病患設定檔的聯結索引鍵。
協調的 DMO 資料參與身分解析。解壓縮的欄位 (例如客戶名稱、電子郵件地址或帳戶號碼) 可作為將文件記錄連結至「統一個人」(金級記錄) 的比對索引鍵,進而結束文件對設定檔的間隙。
範例:
解壓縮欄位 (例如 PatientName、DateOfBirth 和 PolicyNumber) 可作為身分解析的比對索引鍵,其會將索賠記錄連結至正確的「 統一個人」。即使同一位病患在文件之間顯示在略有不同的命名拼字下,也會發生此情況。
結構設計師定義了「已計算洞察」,這是跨協調文件資料計算的彙總度量 (例如各種發票條列項目總支出、契約續約風險分數和索賠嚴重性指數)。
範例:
_已計算洞察_會計算 Agentforce 查詢之協調索賠資料的 TotalClaimsPerPatient、AverageClaimAmount 和 HighRiskClaimScore。
Agentforce 工作人員、Tableau、行銷平台和 Salesforce SObject 可以存取已協調的身分解析資料。目標層級是由延遲、管治和資料落地需求所驅動的結構性決策。
範例:
_索賠批准 Agentforce Agentforce 工作人員_會查詢 Data 360 DMO 和 CI,以尋找高風險索賠以供優先順序審查。Tableau 顯示面板會顯示索賠量與異常趨勢。批准的索賠記錄會循環返回至「_索賠 SObject」,_以起始付款工作流程。
在 Headless 360 架構中,啟用會透過 Query API、Pub/Sub API 或 Cloud 資料倉庫啟用目標直接路由至外部系統。接著,MCP 伺服器會找到協調的文件資料和「已計算洞察」,作為外部 AI 工作人員的可呼叫工具。
_交易處理_管道會在執行階段處理單一文件提取,而不含 UDMO 或預先提取的 UDLO,適合以事件為導向的使用個案 (例如,客戶上載表單、工作人員接收 PDF 或外部系統在交易處理工作流程內啟動提取)。ETL 管理會完全套用至這兩個管道。
真實世界案例
申請貸款時,銀行客戶會透過銀行的行動應用程式上載其公用事業帳單的 PDF。事件會即時起始取用,這表示不會涉及預先取用的 UDLO 或 UDMO。
在叫用 API 之前,結構設計師必須先在 _Data 360 中_定義並儲存結構描述,該結構描述以 _JSON 結構描述_格式指定欄位、資料類型和解壓縮指示。每個結構描述都會獲指派唯一的 結構描述識別碼。在執行階段,呼叫應用程式會參照結構描述識別碼,以在 _Data 360 中_集中解壓邏輯,而非將其內嵌在應用程式程式程式碼中。
範例:
銀行的小組在 _Data 360 中_具有預先定義的 ProofOfAddress 結構描述,可指定如 CustomerName、AddressLine1、City、PostCode 和 DocumentDate 等欄位。此資訊會儲存為可由 _結構描述識別碼_參照的版本化組態。
呼叫應用程式會在單一 REST API 要求中提交文件和結構描述識別碼,作為 base64 編碼的裝載或檔案參照。不需要 UDLO 提取。Document AI 會套用文件解壓縮,並根據提供的結構描述傳回結構化輸出。
範例:
行動應用程式會在單一 REST API 呼叫中,將公用程式帳單作為 base64 編碼的裝載與 ProofOfAddress 結構描述識別碼一起提交。此程序不需要 UDLO 採取步驟。
LLM 會根據結構描述處理 OCR 輸出,並同步傳回結構化 JSON 裝載。文件中找不到的欄位會傳回為 空值。呼叫者擁有完整的 JSON 回應,並繼續進行路由。
範例:
文件 AI 會將 OCR 套用至 PDF,而 LLM 會傳回結構化 JSON 裝載,其中包含解壓的地址欄位。找不到的欄位 (例如,如果帳單中缺少 PostCode) 會傳回為 空值。
解壓縮後,JSON 裝載可根據使用個案路由至一或多個目標層級:
- **Salesforce SObject:**透過 CRM 工作流程和批准的 Apex 或 Flow 直接對應至 SObject 欄位。
- **Data 360 DLO/DMO 銷售管道:**路由至 DLO 進行調和、身分解析、_已計算洞察_和 Agentforce 基礎。
- **外部 RDBMS 或資料倉庫:**針對 Salesforce 外部的系統,透過 MuleSoft、Apex 呼叫、平台事件 或 ETL 進行路由。
- **自訂整合:**將結構化 JSON 裝載傳回至呼叫應用程式以儲存在任何外部系統或資料存放區中。
- **下游流程或工作人員:**將結構化 JSON 輸出直接傳送至下游流程或工作人員,而不會持續存在於 SObject 中。這是使用 Document AI 作為在較大自動化或代理工作流程中即時提取步驟的客戶常見模式。
請記住,單一結構描述可能會同時排入多個層級,而不同的欄位群組會從相同的解壓點路由至不同的目標。
範例:
ProofOfAddress 裝載可以一次傳出三個層級 (例如,CustomerName 和 AddressLine1 寫入至 Contact SObject),這會起始地址驗證 流程。接著,完整裝載會路由至 DLO 進行調和和風險評分,複本會透過 MuleSoft 路由至銀行的 KYC 系統進行法規合規性記錄。
一旦寫入後,系統會立即在目標系統內啟用解壓縮資料。針對 SObject 目標,會在更新插入記錄中啟用觸發、流程和批准流程。針對 DLO/DMO 目標,資料會進入 _調和和身分解析_管道和 Agentforce 內容。針對外部 RDBMS 目標,在寫入完成後,資料即可供下游查詢使用。
範例:
_地址驗證流程_會立即在更新插入的「連絡人」 記錄中啟用,進展貸款申請到下一個階段。Agentforce _貸款專員工作人員_會從 Data 360 中尋找已驗證的地址,而 KYC 系統會記錄文件提交以供稽核之用。
Document AI 最適合特定結構條件。在這些條件之外套用會導致不必要的複雜性和額外成本。
身為結構設計師,請務必先評估此條件,再承諾使用「Document AI」作為取用機制。
在下列情況下使用 Document AI:
- **文件是主要資料來源。**必要資訊僅存在於文件格式中,且無法從結構化 API 或資料庫中取得 (例如掃描的契約、實驗室報告、入院表單或保險索賠)。
- **各來源的文件版面配置各不相同。**同一個文件類型來自多個廠商、合作夥伴或具有不同欄位位置和格式的區域。結構描述驅動的 LLM 解壓縮適應,無須依版面配置維護。
- **解壓縮的資料必須提供 Data 360 或 Agentforce。**解壓縮必須參與身分解析、_已計算洞察_或 Agentforce 基礎。文件 AI 會直接傳送至 DLO/DMO 管道,而不需要個別的 ETL 圖層。
- **批量正確地說明受管理的自動化。**文件量高於手動處理可處理的資料量,不含可測量的人工成本或資料品質風險。
- 文件包含受監管的內容。PHI、PII 或財務資料必須先經由零資料保留 PII 遮蔽層路由,才能到達 LLM。ETL 會原生滿足此需求。若客戶不需要在任何時候保留任何解壓縮內容,也應考慮使用 交易 API 流程,此流程會將結構化輸出直接傳回至呼叫應用程式,而無須寫入任何 SObject 或資料存放區。
- **使用個案是以事件為導向。**文件抵達於執行階段 (例如客戶上載、工作人員 PDF 附件或外部系統觸發)。_交易處理_管道會處理同步單一文件解壓縮,無須批次設定。
請勿在下列情況使用 Document AI:
- **來源資料已結構化。**如果上游系統顯示 REST API、資料庫表格或結構化檔案 (例如 CSV、JSON 或 XML),請使用標準 Data 360 連接器。透過 LLM 解壓縮管道執行結構化資料可增加延遲和信用額度成本,而不會帶來額外的好處。
- **文件是使用固定結構描述機器產生的文件。**系統產生的 PDF,來自已知的 ERP 或具有穩定版面配置的帳單平台,更適合決定性剖析器。LLM 解壓縮是針對變數而設計,將其套用至固定結構描述文件會浪費內容和信用額。
- 準確性需求超過「LLM 信賴等級」。Document AI 並不保證 100% 精確率。當遺漏或不正確的欄位值帶來重大財務、法律或臨床風險時,需要 HITL 驗證步驟時,請使用個案。若沒有驗證工作流程,請勿使用 Document AI 作為高利潤率決策的唯一採取層。
- **文件超過平台限制。**目前的 10MB 檔案大小限制和 LLM 內容長度限制,使得 Document AI 不適用於大型或密集文件,而無需預先處理才能在平台外分割和重新組合文件。
- **備註:**在 Salesforce 中,我們正在主動改善這些接受護欄,以擴充支援的檔案大小、頁數和檔案副檔名。限制將繼續進展。
讓我們進一步瞭解使用 UDMO 來源物件支援的 Document AI 批次 管道的數個案例。在這些情況下,已解壓縮的資料會透過 Data 360 DLO/DMO 管道進行調和、身分解析、_已計算洞察_和 Agentforce 啟用。每個使用個案最適合排程或以事件為導向的大量文件處理。
Agentforce Sales:契約與發票情報
契約 PDF 會透過 _批次_管道從雲端儲存空間中提取。結構描述會解壓縮 ContractValue、RenewalDate、PaymentTerms 和 CounterpartyName,然後將其對應至 Account 和 Contract DMO。_已計算洞察_會衍生續約風險分數。Agentforce 會在續約期間關閉前警示帳戶主管,以免手動檢閱契約和遺漏續約。
Agentforce 服務:個案轉移和 Knowledge 基礎
調查 PDF 和個案附件可透過 _批次_管道來採取。結構描述會提取情感指標、問題種類和解決備註,然後將其對應至 _個案_和 Knowledge 文章 DMO。Agentforce 會在個案開啟時查詢協調的 Knowledge 庫,並找出相關的疑難排解步驟,進而減少工作人員搜尋的負擔。
Agentforce 健康狀況:臨床文件處理
系統會透過 批次 管道來採取實驗室報告、入院 PDF 和手寫的臨床表單。結構描述會解壓縮欄位 (包括 PatientID、DiagnosisCode、MedicationName 和 TestResult),然後將其對應至 Health Cloud DMO,其支援符合 HIPAA 的照護協調和臨床研究工作流程。
金融服務:貸款與稅務文件自動化
透過批次銷售管道採取的貸款申請、稅額報稅單和收入對帳單。結構描述會解壓縮欄位 (包括 AnnualIncome、TaxYear 和 EmployerName),然後將其對應至 財務帳戶 DMO。_已計算洞察_會將文件衍生的收入資料與 CRM 資料聯結,以協助自動化信用風險評分。Agentforce 會在客戶服務互動期間,以內嵌方式找出所提取貸款詳細資料。此模式直接支援在 Salesforce Agent Enterprise Solutions 開發人員中心上發佈的「貸款資格前工作人員」使用個案。
HR:人力文件處理
上線文件、稅務表單和認證 PDF 可透過 _批次_管道來獲取。系統會將解壓縮的欄位對應至 員工記錄 DMO,然後連結至「_統一員工」_設定檔。特定 _流程_會根據所得的資料起始上線工作和合規性檢查。此模式直接支援「自動恢復處理工作人員」使用個案。文件 AI 會從恢復 PDF 中提取技能、就業歷程記錄和資格,然後 Agentforce 會用來根據開放式角色條件比對候選項目,並將其路由至雇用工作流程。
專業服務:提案和研究情報
會透過 批次 管道來採取提案組和研究報告。已解壓縮的架構、基準和參與摘要會對應至自訂 DMO,然後為向量搜尋編製索引。Agentforce 會在查詢時從內容相關的建議中提取,這些建議會以解壓的文件內容為基礎。此模式會擴充「網站內容上的 Ground Agentforce」 模式。文件會透過 Document AI 編製索引,並為工作人員回應提供與透過 Data 360 連接器編製索引的網站內容相同的奠基功能。
HIPAA 規範狀態:
本文中描述的 Health Cloud 模式會對文字輸入套用 ETL 控制項 (例如零資料保留和 PHI 遮蔽)。這些控制項本身並不構成 HIPAA 認證。針對受監管臨床環境設計的結構設計師必須先向 Salesforce 合規小組確認目前的 HIPAA 認證狀態,才能在這些內容中認可以 Document AI 為基礎的結構。
讓我們更進一步瞭解使用不繫結至 UDMO 的結構描述,叫用 Document AI REST API 的數個案例。解壓縮的 JSON 裝載會在執行階段同步地直接路由至外部系統。
供應鏈:廠商發票處理至 ERP
當 廠商發票 PDF 傳送到監視的儲存分類或電子郵件中時,事件觸發會呼叫具有發票和預先定義的結構描述識別碼的 Document AI REST API。結構描述會提取 VendorID、InvoiceNumber、LineItems、TotalAmount、TaxAmount 和 DueDate。JSON 裝載會透過 MuleSoft 路由至具有 _空值_欄位驗證和 idempotent 更新插入邏輯的 _ERP 應付帳戶_模組,以免範本維護供應商格式變異。
法律作業:契約審查至 CLM
當上載 契約 PDF 至法律入口網頁時,後端會同步呼叫 Document AI REST API。結構描述會解壓縮 GoverningLaw、IndemnityCapAmount、TerminationNoticePeriod、AutoRenewalClause 和 CounterpartySignatory。JSON 裝載會透過 Apex 呼叫路由至 契約週期管理 (CLM) 系統。找不到的任何欄位都會傳回為 空值,而 CLM 會將預設義務規則套用至遺漏值。
保險索賠:第一次損失通知處理
當保單持有人提交「第一個損失通知」(FNOL) 表單時,後端入口網頁會同步呼叫 Document AI REST API。結構描述會解壓縮 PolicyNumber、IncidentDate、IncidentLocation、DamageDescription、ClaimantName 和 ContactPhone。JSON 裝載會透過 Apex 呼叫或 ETL 路由至 _索賠管理_資料庫,這會建立預先填入的索賠記錄,供調整員在開啟正式索賠前檢閱。
移至生產環境前,您必須先為這些失敗案例建立設計。
- **空值欄位處理:**LLM 會針對其找不到或無法自信地解壓的欄位傳回 空值。在結構描述設計時驗證空值處理邏輯,並在整合層中實作預設值或拒絕邏輯,然後再寫入任何具有 NOT NULL 限制或必要比對索引鍵的目標。
- **OCR 品質降級:**OCR 準確度會在不規則的手寫或雜訊掃描時降級至低於 150 DPI。誤讀會以不含錯誤訊號的損毀輸入形式傳播至 LLM 解壓縮。強制執行採取時的最低掃描品質,並在數值和日期欄位上實作信賴等級檢查。
- **結構描述版本不相符:**排程批次工作後更新結構描述組態會導致流程文件會針對先前版本進行處理,這會產生遺失或重新命名的欄位,進而中斷下游對應。版本會明確規劃並與批次工作排程協調更新。
- **檔案大小限制:**超過 10MB 的文件會遭到拒絕。批次銷售管道失敗會在未設定監視的情況下為靜音,且交易來電者會收到 4xx 錯誤。預先驗證取用時的檔案大小,並實作預先處理,以分割或壓縮定期接近限制的文件。
- **LLM 內容溢出:**密集或多頁文件可能會超過 10MB 限制內的 LLM 內容視窗。LLM 會無聲地捨棄超出內容的內容。實作切分策略,將文件依頁面範圍分割,並在將其轉移至目標前重新組合已解壓縮的欄位。
- **信任層遮蔽會影響解壓縮:**ETL 會在提示層級 (而非文件層級) 作業,因此遮蔽不會套用至通過 Document AI 的文件內容。依據文件中 PII 值的結構描述欄位不會受到 ETL 遮蔽原則的影響。
- 外部 RDBMS 寫入識別碼強度:_交易處理_管道沒有外部 RDBMS 目標的任何內建使用權限。_整合層_重試會建立重複的列,除非寫入邏輯明確處理消除重複。在所有外部寫入路徑上使用文件指紋或外部識別碼實作 idempotent 更新插入。
- **信用額度耗用執行中:**大批次執行可能會在處理所有文件之前耗用 Digital Wallet 信用,這會產生下游步驟檢視為完成的不完整 DLO 資料集。將耗用警示設定為可用信用額的 75% 和 90% 並限制批次大小,以保持在每個週期的信用額度預算之內。
- 結構描述欄位限制 — 結構限制:Document AI 會針對結構描述組態中的根層級欄位強制執行 50 個欄位限制。這是設計時間限制,不是執行階段錯誤,且結構設計師必須在資料模型與結構描述設計期間考量此限制。
- 適用於需要更廣泛解壓的使用個案:
- 無情地排定優先順序。將結構描述縮小至驅動自動化值的欄位,而非詳細的文件涵蓋範圍。
- 利用巢狀物件 (最多 3 個層級;僅含來源物件的批次模式) 來減少根層級欄位計數,而不會犧牲取用深度。
- 將複雜文件解壓縮在鎖定不同文件區段的多個 Document AI 組態之間,並將結果寫入至在 _Data 360 中_下游聯結的個別 DLO。
- 適用於需要更廣泛解壓的使用個案:
- API 比率限制:Document AI 會強制執行每個租戶每分鐘的 50 次取用 API 呼叫限制。理論上限為每分鐘 300 次通話,由 Einstein LLM Gateway 管理。大量交易整合必須以指數反向方式、要求排列和租戶層級輸送量預算來設計。請勿假設突發容量適用於多重租戶生產環境。
- API 延遲設定檔:文件 AI 解壓縮 API 完全同步。一般回應時間範圍為 5–15 秒,會因檔案大小與結構描述複雜度而有所不同。
- 這對整合結構有直接影響:
- 將來電者逾時設定為最少 30 秒。
- 請勿在具有次要 SLA 需求的流程中叫用 Document AI。
- 對照 _批次處理_管道的比率限制上限,輸出計算的係數延遲。
- 將來電者逾時設定為最少 30 秒。
- 這對整合結構有直接影響:
- 加密與受密碼保護的文件:Document AI 不會處理受密碼保護的檔案 (開啟檔案需要使用者密碼) 或使用擁有者/權限密碼加密的 PDF,包括一般開啟但限制在 _PDF 權限層_中複製、列印或編輯的檔案。
- 此限制位於接收的邊界:
- 設計 _文件入院_管道,以在加密檔案到達 Document AI 之前,偵測並路由至_拒絕_或_手動處理_路徑。
- 請勿依賴執行階段錯誤處理作為主要門。
- 此限制位於接收的邊界:
Data 360 Document AI 符合 Salesforce Well-Architected Framework 的數個支柱。
- **Trust:**ETL 會使用 LLM 提供者強制執行零資料保留、在輸入到達模型之前遮蔽 PII 輸入,並掃描敏感內容的輸出。結構設計師必須將此狀態延伸至靜態的已解壓縮資料。ETL 不會套用 DLO 中的欄位級遮蔽,且需要下游 資料空間 原則和 權限集。
- **可靠性:**在「_設計考量事項」_區段中的每個失敗模式—空白欄位提取、OCR 誤讀、結構描述版本不相符、檔案大小缺口、LLM 內容溢出、ETL 遮蔽干擾、RDBMS 寫入效能和信用額度耗用—都代表具有已記錄偵測訊號和解析路徑的獨特失敗類別。
- **傑出作業 (變更管理):**結構描述驅動的解壓縮模型會將解壓縮邏輯與文件版面配置分離。當廠商變更發票格式或更新法規表單時,結構設計師只需要更新一個結構描述組態,而不需要修改整合程式碼。
- **卓越營運 (永續性):**將結構描述組態集中在 Data 360 中,而非將解壓縮邏輯內嵌在應用程式程式碼中,可使解壓縮意圖明確、版本化且可稽核。所有下游目標會耗用相同的結構描述契約,無論其目標層級為何。
- 卓越作業 (整合重複使用):文件 AI 會顯示多個整合表面之間的解壓:REST API、Apex、Flow、MuleSoft、Agentforce Actions 和 MCP 伺服器。單一結構描述組態會同時將風扇排放到多個目標層級,而不會重新建立每個消費者的取用功能。
- **資源和成本最佳化:**銷售管道選取指引、10 MB 檔案大小邊界,以及預先組裝的 LLM 內容長度限制代表認知效能的設計決策。_使用時機_區段會正式定義當「文件 AI」 不是正確工具時的條件 (例如,子秒延遲需求、完整結構化來源資料,以及固定結構的機器產生文件)。
這是在 Sandbox 環境中設定 Data 360 Document AI 的結構化起點。先完成 Sandbox 中的所有階段,再移至生產。
開始設定之前,您必須確認:
- **檔案大小:**驗證代表文件大小低於 10MB。
- **管道:**確認使用個案是否需要 _批次_管道 (UDMO 支援、大量) 或 _交易處理_管道 (API 驅動、單一文件)。這會驅動所有後續組態。
- **目標層級:**確認要移入的資料位於何處—Salesforce SObject、Data 360 DLO/DMO、外部 RDBMS 或組合。
- **Agentforce 相依性:**部署任何 Agentforce 技術支援的文件處理之前,請先確認已透過 ETL 設定在您的組織中啟用支援的 LLM (例如,GPT-4o)。Agentforce 是 Document AI 的硬式平台先決條件。在目標組織中 Agentforce 已啟用之前,無法使用整個 Document AI 功能面板 (包括所有解壓縮 API)。將此因素納入組織整備評估和佈建順序。請保留幾分鐘的時間,讓 API 可用性穩定化後續啟用。
- **Agentforce 停用影響:**如果在設定並部署 Document AI 之後停用 Agentforce,則所有解壓縮處理 (UI 和 API) 將會立即封鎖。同樣的情況也適用於模型停用。停用基本模型會對 Document AI 可用性產生相同的影響。在這兩種情況下,現有結構描述組態會保留並保持可見—不會發生組態或資料遺失—但在重新啟用 Agentforce 和模型之前,功能會完全無法運作。設計作業執行手冊以將 Agentforce 可用性和模型啟用視為 Document AI 健康相依性。
- **信用額度消耗/定價:**針對衍生自代表範例文件的 TCO 估計值,使用 Data 360 Credits 或 Flex Credits。
- **建立結構描述組態。**在 Data 360 Document AI 設定中,以 JSON 結構描述 格式定義解壓縮欄位、資料類型和指示。針對 _批次_銷售管道,將其繫結至 UDMO。針對 _交易處理_管道,請在沒有來源物件的情況下建立該管道。記錄結構描述識別碼。
- **將欄位名稱對齊至目標層級。**將欄位名稱與 DLO 欄定義、SObject API 名稱或 RDBMS 欄名稱進行比對。不一致的名稱會在整合層中建立對應負擔。
- **設定 UDMO 來源物件 (僅限批次)。**在範圍中定義文件,並設定取用來源連線 (例如,S3、Google Cloud Storage、Salesforce Files 或 MuleSoft)。請確認其服務帳戶具有必要的 IAM 或 OAuth 認證範圍。
- **套用 PII 遮蔽原則。**處理任何受監管的內容之前,請先在 ETL 設定中設定 _資料遮蔽_原則。定義要在輸入到達 LLM 之前遮蔽哪些欄位類型 (PHI、PII 和財務識別碼)。請勿延後此步驟。
- **指派「資料空間」範圍與權限集。**將處理範圍定義至適當的 資料空間,並設定 _權限集_以控制結構描述建立、批次工作執行、REST API 叫用和下游啟用。
- **設定 API 驗證 (僅限交易處理管道)。**建立具有 OAuth 範圍 cdp_ingest_api 和 api 的 連線的應用程式。針對組織內呼叫者,請使用連結至「外部認證」的「已命名認證」。針對外部呼叫者,請設定 OAuth 2.0 用戶端認證或 JWT 承載者流程。繼續前先測試和驗證解壓。
- **SObject 寫回:**實作 Apex (@InvocableMethod) 或 Flow 元素,將 JSON 回應欄位對應至 SObject 欄位。將 Database.upsert() 與外部識別碼搭配使用,以避免重複。在目標 SObject 欄位上套用 欄位級安全性。
- **Data 360 DLO/DMO 銷售管道:**將解壓縮的 DLO 欄位對應至符合 Customer 360 資料模型 的 DMO。設定身分解析規則,以將文件記錄連結至「統一個人」。定義「已計算洞察」,並新增 Agentforce 的 DMO。針對交易處理管道,請先透過 入院 API 將 JSON 裝載路由至 DLO。
- **外部 RDBMS 或資料倉庫:**選取整合模式:MuleSoft (現有整合架構)、Apex HTTP 呼叫 (輕量型、組織原生)、具有 Pub/Sub 訂閱者的 平台事件 (事件驅動) 或 ETL (大量批次)。在所有外部寫入路徑上使用文件指紋或外部識別碼實作 idempotent 更新插入。
- **啟用路徑:**將 Agentforce 動作連線至結構描述組態,以供互動式取用。設定自動化處理工作流程的 _流程_或 Apex 觸發,並為每個欄位群組建立啟用目標。
- **錯誤處理 (僅限交易處理管道)。**設定完整的 HTTP 回應表面:200 (成功,包括部分的 _空值_回應)、400 (格式錯誤的要求_或_結構描述識別碼找不到)、413 (檔案超過 10 MB)、5xx (服務錯誤)。實作 5xx 重試的指數反向回應,最多嘗試 3 次。記錄每個通話的原始 JSON 回應和結構描述識別碼。
- **對範例文件測試結構描述。**透過 Document AI 介面或 REST API 提交代表樣本。確認在整個版面配置變化之間採取的準確度、欄位範圍和空值處理。
- **驗證空值欄位處理。**確認所有下游目標都可以處理文件中 _找不到_欄位的 空值。請記住,如果沒有明確的空值處理,NOT NULL 限制會無聲地失敗。
- **預先驗證檔案大小。**確認生產文件保持在 10MB 以下。實作預先處理以分割或壓縮定期接近限制的文件。
- **驗證端對端解壓縮。**針對 _批次_銷售管道,請起始完整執行,並確認已解壓縮的欄位會正確地進入每個目標層級。針對 _交易處理_管道,透過目標的 _整合層_追蹤 JSON 回應。確認 SObject 目標的觸發和流程執行、DLO/DMO 目標的身分解析連結,以及 RDBMS 目標的效能。
- **確認 Trust 圖層行為。**ETL 不會將 PII 遮蔽套用至文件內容,因此 LLM 會依原狀傳回在解壓的欄位中的 PII 資料。確認您的結構描述欄位、資料路由和下游儲存空間已設計為適當處理 PII 承載輸出,並確保在平台外解決任何合規性或保留需求。
- **設定 Digital Wallet 警示。**以 75% 和 90% 的可用信用設定耗用警示。在每個週期的信用預算內建立批次大小限制和臨時匯率估計值。
- **驗證批次監視 (僅限批次銷售管道)。**檢閱在 Data 360 監視主控台中取用成功率、空值欄位率和工作完成率。確認在資料歷程中,從 UDLO 透過 DLO 傳播到 DMO 的標記。
- **驗證 API 錯誤處理 (僅限交易處理管道)。**測試所有錯誤條件:413 (超過 10MB 的文件)、400 (無效的「結構描述識別碼」)、200 (具有部分空值的有效提取)。確認重試邏輯會在模擬的 5xx 回應上觸發,而不會建立重複的寫入。
此文件會醒目提示 Data 360 Document AI: 的結構基礎
- 兩個處理管道及其使用時機
- 結構描述組態模型
- 目標層級決策架構
- 核心技術限制
- 失敗模式
- _結構良好架構_對齊方式
架構師快速開始指南提供 Sandbox 概念證明的組態順序。
核心結構狀態支援在 _結構描述_層管理的文件衍生資料、透過 ETL 強制執行的 LLM 管道處理,並傳送至管理所有其他企業資料的相同 Data 360 資料生命週期。
套用這些原則的結構設計師 (選取正確的銷售管道、在文件類型層級設計結構描述,以及在生產前針對失敗模式進行設計) 會建立可根據受監管產業管治需求調整和持續的解壓功能。
Yugandhar Bora 是 Salesforce 的軟體工程結構設計師,專門在 資料和情報應用程式_平台內進行資料結構。他負責領導重點為資料管理和統一資料模型的_企業結構檢閱委員會 (EARB) 計畫,同時為自動平台佈建解決方案做出貢獻。
Ananth Anto 是 Salesforce Data 360 的產品管理主任,負責領導 _文件 AI 和資料圖形_計畫。他位於邦加羅爾,與企業客戶合作,解決真實世界的文件處理和資料情報挑戰。他喜歡探索 生成式 AI (Gen AI) 的 _企業_使用個案。
Salesforce 的軟體工程結構設計師 Nishan Naseer 處理 非結構化資料處理、RAG 銷售管道和 文件情報。他熱衷於運用 AI 的強大功能來應對現實世界的挑戰,並為複雜的客戶問題尋找創意解決方案。