如何在 Advanced Designer 中使用提示式活動來擷取資料

概觀

提示式擷取可讓您使用自然語言指令，透過 LLM 從文件中擷取結構化資料。您無需訓練傳統機器學習模型，而是直接描述要擷取的資料以及其格式化方式，LLM 會依據您的指示執行擷取。 您將完成的內容：

建立一個提示式擷取活動。
設定 LLM 連線。
撰寫有效的擷取提示。
定義輸出格式與結構。
套用嚴格度與驗證規則。
測試並微調您的擷取。

完成時間： 20-30 分鐘 使用案例：

從發票中擷取供應商資訊
表頭層級的文件資料擷取
半結構化文件處理
版面配置多變的文件

先決條件

在開始之前，請確保您已具備：

存取 ABBYY Vantage Advanced Designer 的權限。
已完成 LLM 連線設定。請參閱如何設定 LLM 連線。
一個已載入範例文件的文件 Skill。
對 JSON 結構有基本認識。
您想要擷取之資料的欄位定義。

**注意：**本指南著重於標頭層級的擷取。表格擷取功能可能有所差異。

了解提示式擷取

什麼是提示式擷取？

提示式擷取運用 LLM，依據自然語言指令來理解並從文件中擷取資料。您可以定義：

Role：LLM 應該扮演的角色（例如：“data extraction model”）。
Instructions：如何擷取與格式化資料。
Output Structure：結果所需的精確 JSON 格式。
Rules：處理模糊或缺漏資料的規則。

優點

無需訓練資料：只要進行提示工程即可運作。
具彈性：容易新增或修改欄位。
能處理變化：LLM 能理解不同的文件格式。
設定快速：比訓練傳統機器學習模型更快。
自然語言：可以用一般英文撰寫說明指令。

限制

成本：每次擷取都會觸發 LLM API 呼叫。
速度：對於簡單文件，比傳統擷取方式更慢。
一致性：不同執行之間的結果可能會略有差異。
上下文限制：篇幅很長的文件可能需要額外處理。

步驟 1：新增提示式活動

在您的文件 Skill 中建立新的提示式擷取活動。

在 ABBYY Vantage Advanced Designer 中開啟您的文件 Skill。
在左側面板中，找到 EXTRACT FROM TEXT (NLP)。
尋找並按一下 Prompt-based。

此活動會出現在您的工作流程畫布中。
將它連接在輸入與輸出活動之間。

注意： 提示式活動位於活動面板中的「EXTRACT FROM TEXT (NLP)」之下，與其他擷取方法（例如 Named Entities (NER) 和 Deep Learning）並列。

步驟 2：設定 LLM 連線

選擇此活動應使用的 LLM 連線。

在工作流程中選取提示式活動。
在右側的 Activity Properties 面板中找到 LLM Connection。
按一下下拉式選單。

從清單中選取已設定好的 LLM 連線。
- 範例：Nick-ChatGPT、Microsoft Foundry、Production GPT-4
確認已選取正確的連線。

注意： 如果您沒有看到任何連線，您需要先透過 Configuration → Connections 來設定 LLM 連線。

步驟 3：定義輸出欄位

在撰寫提示之前，先設定您想要擷取的欄位。

在 Activity Properties 面板中，找到 Output 區段。
您會看到欄位群組與欄位所組成的階層式清單。
在這個範例中，我們要擷取供應商資訊：
- 供應商 (Vendor)
  - 名稱
  - 地址
  - 稅務識別號碼
  - 帳戶號碼
  - Sort Code
  - IBAN
  - BIC_SWIFT
- 業務單位 (Business Unit)
  - 名稱
  - 地址
  - 發票日期 (Invoice Date)
  - 發票號碼 (Invoice Number)
- 總計 (Totals)
  - 淨金額

按一下 Activity Editor 按鈕，以開始設定提示。

注意： 在撰寫提示之前，請先定義所有欄位。這些欄位名稱會在提示結構中被參照。

步驟 4：撰寫角色定義

定義 LLM 在處理文件時應扮演的角色。

在 Activity Editor 中，您會看到 Prompt Text 介面。
從 ROLE 段落開始：

角色

您是資料擷取模型。僅從文件中擷取指定的供應商相關欄位。逐字擷取值文字(而非標籤)。請勿推斷或重新格式化任何資料。省略任何未明確出現的欄位。

關鍵角色指引：

具體說明：使用「data extraction model」告訴 LLM 其用途。
定義範圍：使用「vendor-related fields」限制要擷取的內容。
設定預期：使用「value text verbatim」以避免重新格式化。
處理遺漏資料：使用「Omit any field that is not clearly present」。

最佳實務：

保持角色說明清楚且精簡。
使用祈使句（「Extract」、「Do not infer」）。
明確說明「不要做什麼」。
定義如何處理邊界案例。

步驟 5：定義輸出格式

指定擷取結果的精確 JSON 結構。

在 ROLE 區段下方新增 OUTPUT FORMAT 標題。
定義 JSON 結構：

輸出格式

返回一個有效的 JSON 物件，使用以下確切結構：

{
  "Fields": [
    { "FieldName": Vendor.Name, "Text": "...", "Line": <FirstLineIndex> },
    { "FieldName": Vendor.Address, "Text": "...", "Line": <FirstLineIndex> },
    { "FieldName": Vendor.TaxID, "Text": "...", "Line": <FirstLineIndex> },
    { "FieldName": Vendor.Account Number, "Text": "...", "Line": <FirstLineIndex> },
    { "FieldName": Vendor.Sort Code, "Text": "...", "Line": <FirstLineIndex> },
    { "FieldName": Vendor.IBAN, "Text": "...", "Line": <FirstLineIndex> },
    { "FieldName": Vendor.BIC_SWIFT, "Text": "...", "Line": <FirstLineIndex> }
  ]
}

結構元件：

FieldName：必須與您的欄位定義完全相符（例如：Vendor.Name）。
Text：擷取出的值，以字串形式表示。
Line：值在文件中出現的位置，其行索引從 0 起算。

重要注意事項：

請使用您輸出設定中的完整欄位名稱。
即使某些欄位可能沒有值，也要全部包含。
結構必須是有效的 JSON。
行號有助於驗證與疑難排解。

步驟 6：新增欄位特定的擷取規則

為每個欄位的擷取提供詳細說明。在 OUTPUT FORMAT 區段下方，為各種欄位型別新增具體規則：

VENDOR NAME
1) Recognize names like "ABC Corporation", "XYZ Ltd", "Acme Inc.".
2) Extract the complete company name including legal suffixes (Ltd, Inc, GmbH, etc.).
3) Vendor name typically appears near the top of the document.

VENDOR ADDRESS
1) Extract the complete address including street, city, postal code.
2) For multiline addresses, represent each new line using "\n".
3) Vendor-side only; exclude customer/buyer addresses.

ACCOUNT NUMBER
1) Recognize "Account Number", "Account No", "Acct #".
2) Extract the numeric format exactly as printed (e.g., "12-34-56" or "500 105 17").
3) Vendor-owned accounts only (e.g., "Beneficiary" or "Vendor Payment" sections).
4) Ignore IBAN — it has its own field.

SORT CODE
1) Recognize "Sort Code", "Sort No.", "BLZ", "Bankleitzahl".
2) Extract the numeric format exactly as printed (e.g., "12-34-56" or "500 105 17").
3) Vendor-side data only; ignore payer/buyer codes.

IBAN
1) Recognize "IBAN", "International Bank Account Number".
2) Extract the full IBAN exactly as printed (include spaces).
3) Vendor-side only, typically under "Bankverbindung", "Coordonnées bancaires", "Payment Details", or "Beneficiary Bank".

BIC_SWIFT
1) Recognize "BIC", "SWIFT", or "BIC/SWIFT".
2) Extract the complete identifier (usually 8 or 11 uppercase letters/numbers).
3) Vendor-side only, near the IBAN or bank name.
4) Exclude customer/payer data.

規則結構：

辨識模式：列出每個欄位的替代標籤。
格式規格：描述要擷取的精確格式。
位置提示：說明通常在哪裡可以找到這些資料。
排除項目：定義不要擷取的內容。

最佳實務：

為規則編號以提升清晰度。
提供多個標籤變化形式。
明確指明資料歸屬（供應商端 vs. 客戶端）。
在括號中加入格式範例。
明確說明相關欄位（例如，“Ignore IBAN — it has its own field”）。

步驟 7：套用嚴格性規則

新增驗證規則，以確保資料的品質與一致性。在提示詞的末尾新增一個 STRICTNESS 區段：

STRICTNESS
- Never generate or infer values.
- Omit ambiguous or missing fields.
- If none of the vendor fields are found, return:
  {
    "Fields": []
  }

其他嚴格性規則（可選）：

一般規則
- 每個欄位僅擷取一個值。
- 跳過任何無法確定位置的欄位 — 從輸出中省略該欄位。
- "FieldName" 必須與上述名稱完全相符。
- "Text" 必須從文件中逐字複製 — 不進行標準化或推斷。
- 對於多行值(例如地址),使用跳脫序列 "\n"(反斜線後接字母 n)表示每個新行。
- 不要在輸出文字中插入 HTML 標籤,例如 <br>。
- "Line" 是包含擷取值的第一行之以 0 為基底的索引;僅在可驗證時包含此項。

為何嚴格性很重要：

防止幻覺生成：LLM 可能產生看似合理但實際錯誤的資料。
確保一致性：明確規則可減少多次執行結果的差異。
處理遺漏資料：定義在找不到欄位時應該怎麼做。
維護資料完整性：逐字擷取可保留原始格式。

嚴格性的關鍵原則：

絕不可生成不存在於文件中的資料。
寧可省略不確定的擷取結果，也不要臆測。
若找不到任何欄位，則傳回空結構。
必須與欄位名稱完全相符。
保留原始文字格式。

步驟 8：選擇文件格式

選擇要傳送給 LLM 的文件呈現方式。

在 Activity Editor 中找到 Prompt 下拉選單。
您會看到多種將文件提供給 LLM 的方式選項。

可用格式：

PDF：原始 PDF 檔案
- 適用於：版面配置很重要的文件
- 注意事項：檔案較大，且部分 LLM 對 PDF 的支援有限
Plain Text：未格式化的文字擷取
- 適用於：單純的純文字文件
- 注意事項：會遺失所有格式與版面資訊
Annotated Text ⭐（推薦）
- 適用於：大多數文件類型
- 注意事項：以文字為基礎，同時保留結構
- 優點：在結構與效能之間提供最佳平衡
Formatted Text：保留基本格式的文字
- 適用於：部分格式仍然重要的文件
- 注意事項：介於 Plain 和 Annotated 之間的折衷方案

選擇 Annotated Text 以獲得最佳效果。

注意： 根據測試結果，Annotated Text 在擷取工作中能提供最一致且可靠的結果。它在保留文件結構的同時，亦能被 LLM 高效率地處理。

步驟 9：測試您的擷取

在範例文件上執行此活動以驗證結果。

執行 Activity

關閉 Activity Editor。
前往 All Documents 分頁。
選擇一份測試文件。
按一下 Test Activity 或 Run 按鈕。

等待 LLM 處理文件。
- 處理時間：通常為 5–30 秒，視文件複雜度而定。
- 等待 API 回應時，您會看到載入指示器。

檢閱結果

處理完成後：

介面會切換為 Predictive view。
檢閱顯示擷取欄位的 Output 面板。
按一下每個欄位即可檢視：
- 擷取的值
- 信心度（若有提供）
- 文件影像上對應區域的醒目標示

需要檢查的內容：

✅ 所有預期的欄位都已填入
✅ 值與文件內容完全相符
✅ 沒有由幻覺或推測產生的資料
✅ 正確處理多行欄位
✅ 遺漏的欄位被省略（而非以錯誤資料填入）

常見結果模式

成功的擷取：

{
  "Fields": [
    { "FieldName": "Vendor.Name", "Text": "ABC Corporation Ltd", "Line": 3 },
    { "FieldName": "Vendor.Address", "Text": "123 Business Street\nLondon SW1A 1AA", "Line": 5 },
    { "FieldName": "Vendor.IBAN", "Text": "GB29 NWBK 6016 1331 9268 19", "Line": 15 }
  ]
}

部分擷取（缺少部分欄位）：

{
  "Fields": [
    { "FieldName": "Vendor.Name", "Text": "ABC Corporation Ltd", "Line": 3 }
  ]
}

找不到任何欄位：

{
  "Fields": []
}

步驟 10：精煉你的提示詞

根據測試結果反覆調整並改進你的提示詞。

常見問題與解決方案

問題：LLM 擷取到錯誤的欄位

解決方案：加入更明確的位置信息提示。
範例：「僅限供應商端；排除客戶/買方地址」

問題：格式被改變

解決方案：強調必須逐字擷取。
範例：「請完全依照原樣擷取數字格式（例如：‘12-34-56’）」

問題：LLM 杜撰資料

解決方案：強化嚴格規則。
範例：「絕不要產生或推斷值。若不存在則省略。」

問題：多行欄位被串接在一起

解決方案：指定跳脫字元序列。
範例：「對於多行值，使用 \n 作為換行符號」

問題：輸出中的欄位名稱不正確

解決方案：確認欄位名稱完全一致。
範例：使用 Vendor.Account Number 而非 AccountNumber

迭代改進流程

使用多個文件測試：不要只針對單一範例最佳化。
記錄模式：注意哪些規則有效、哪些需要進一步調整。
加入具體範例：在括號中包含格式示例。
調整嚴格程度：根據過度／不足擷取的情況進行調整。
測試邊界案例：嘗試含有缺失欄位、版面異常的文件。

優化前：

VENDOR NAME
1) Extract the vendor name from the document.

之後：

供應商名稱
1) 識別如「ABC Corporation」、「XYZ Ltd」、「Acme Inc.」等名稱。
2) 擷取完整的公司名稱,包括法律後綴詞(Ltd、Inc、GmbH 等)。
3) 供應商名稱通常出現在文件頂部附近。
4) 排除客戶/買方名稱 - 專注於開立發票的實體。

瞭解擷取流程

提示式擷取的運作方式

文件轉換：您的文件會轉換成所選格式（建議使用 Annotated Text）。
提示組合：會將您的角色、輸出格式、欄位規則與嚴格性規則加以整合。
API 呼叫：提示與文件會透過您的連線傳送給 LLM。
LLM 處理：LLM 會讀取文件，並依照您的指示擷取資料。
JSON 回應：LLM 會以指定的 JSON 格式傳回結構化資料。
欄位對應：Vantage 會將 JSON 回應對應到您定義的輸出欄位。
驗證：行號與信心分數（若有提供）可協助驗證正確性。

Token 使用量與成本

影響成本的因素：

文件長度：文件愈長，使用的 token 愈多。
提示複雜度：提示愈詳細，token 數就會增加。
格式選擇：相較於 PDF，Annotated Text 通常更有效率。
欄位數量：欄位越多，提示就越長。

最佳化建議：

在提示中使用精簡但清楚的語句。
避免重複相同指示。
移除不必要的範例。
針對相關資料考慮將欄位分組。

最佳做法

提示撰寫

建議這樣做：

✅ 使用清楚的祈使句（“Extract”、“Recognize”、“Omit”）。
✅ 為每個欄位提供多種標籤名稱變化。
✅ 在括號中加入格式範例。
✅ 明確說明不要擷取的內容（排除項目）。
✅ 為規則編號以便參考。
✅ 全文使用一致的術語。

避免這樣做：

❌ 使用含糊的指示（“get the name”）。
❌ 假設 LLM 了解特定領域的慣例。
❌ 撰寫過長、過於複雜的句子。
❌ 在文件不同部分前後矛盾。
❌ 忽略嚴格性相關規則。

Field 定義

有效的 Field 使用指引：

從設定辨識樣式開始（替代標籤）。
指定要保留的精確格式。
提供位置提示（典型位置）。
定義資料歸屬（供應商 vs. 客戶）。
說明多行值的處理方式。
參考相關欄位以避免混淆。

範例：

IBAN
1) 識別「IBAN」、「International Bank Account Number」。
2) 完整擷取列印的 IBAN(包含空格)。
3) 僅限供應商端,通常位於「Bankverbindung」、「Payment Details」下方。
4) 請勿與帳戶號碼混淆 — IBAN 較長且為字母數字組合。

測試策略

從簡單文件開始：先測試基本擷取功能。
擴展到各種變化：嘗試不同版面與格式。
測試邊界案例：欄位缺失、非典型位置、多重符合。
紀錄失敗案例：保留擷取失敗的範例。
有系統地反覆調整：一次只變更一個因素。

效能最佳化

針對速度：

讓提示詞保持精簡。
使用 Annotated Text 格式。
將每個活動中的欄位數量降到最少。
考慮切分複雜文件。

針對準確度：

提供完整的欄位規則。
加入格式範例。
新增嚴格的規則設定。
使用多樣的文件樣本進行測試。

針對成本：

最佳化提示詞長度。
使用效率較高的文件格式。
在適當情況下快取結果。
透過 LLM 供應商的儀表板監控 token 使用量。

疑難排解

擷取問題

問題： 儘管資料存在，欄位仍為空白。 解決方案：

檢查欄位名稱拼寫是否完全相符。
驗證資料是否符合所選的文件格式。
在辨識樣式中加入更多標籤變化。
暫時降低嚴格度，以查看 LLM 是否能找到該欄位。
檢查文件品質是否影響 OCR 或文字擷取。

問題： LLM 擷取的是客戶資料而非供應商資料。 解決方案：

強化針對供應商的規格說明。
對客戶/買方資料加入明確的排除規則。
提供位置提示（例如：「文件頂端」、「開立人區段」）。
加入正確與錯誤擷取的對照範例。

問題： 多行內容被連成一行或格式錯誤。 解決方案：

明確指定跳脫序列格式（\n）。
提供正確多行輸出範例。
驗證文件格式是否保留換行。
加入指示：「使用 \n 保留原始換行符號」。

問題： LLM 重新格式化或標準化資料。 解決方案：

強調「逐字」與「與印刷內容完全相同」。
新增嚴格規則：「不得進行標準化或推論」。
提供具體範例，說明需保留原始格式。
加入反面範例：「不要變成 ‘12-34-56’，請保持為 ‘12 34 56’」。

效能問題

問題： 擷取速度太慢。 解決方案：

若使用 PDF，請改用 Annotated Text 格式。
在不犧牲關鍵指示的前提下簡化提示詞。
若影像尺寸非常大，降低文件解析度。
檢查 LLM 服務提供者的狀態與頻率限制。
對於結構較簡單的文件，考慮使用速度較快的模型。

問題： 每次執行的結果不一致。 解決方案：

提高嚴格度設定。
讓指示更具體且不含歧義。
增加更多格式範例。
降低可能造成多種解讀的提示詞複雜度。
使用較高的 temperature 設定進行測試（若連線設定支援）。

問題： API 成本過高。 解決方案：

最佳化提示詞長度。
使用 Annotated Text 取代 PDF。
在離峰時段以批次方式處理文件。
對於結構較簡單的文件，考慮使用較小／較便宜的模型。
在 LLM 服務提供者的主控台中監控並設定預算警示。

進階技巧

條件式擷取

您可以指示 LLM 僅在滿足特定條件時才擷取特定欄位：

帳戶號碼(條件式)
1) 僅在文件包含銀行付款詳細資訊時擷取。
2) 如果出現「付款方式:支票」或類似內容,則省略此欄位。
3) 識別「Account Number」、「Account No」、「Acct #」。

多語言支援

提示式擷取在多語言文件上運作良好：

供應商名稱(多語言)
1) 英文識別:"Vendor Name"、"Supplier"、"Seller"
2) 德文識別:"Verkäufer"、"Lieferant"、"Anbieter"
3) 法文識別:"Fournisseur"、"Vendeur"
4) 無論使用何種語言,皆提取完整的公司名稱。

驗證規則

將驗證邏輯加入您的提示詞：

IBAN(含驗證)
1) 完全按照列印內容擷取完整的 IBAN。
2) 驗證開頭為兩個字母的國家代碼。
3) 如果格式不符合 IBAN 模式,則省略該欄位。
4) 請勿自行編造檢查碼或國家代碼。

欄位關係

指定欄位之間的關聯方式：

帳戶號碼 vs IBAN
- 帳戶號碼:通常較短、數字格式、國內格式。
- IBAN:字母數字混合,以國家代碼開頭(例如「GB29 NWBK...」)。
- 如果兩者都存在,則將兩者提取到不同的欄位中。
- 如果只有一個存在,則提取到相應的欄位中。
- 不要在兩個欄位中重複相同的值。

限制與考量

目前功能

支援：

✅ 標頭層級欄位擷取
✅ 單行與多行值
✅ 每份文件可擷取多個欄位
✅ 條件式擷取邏輯
✅ 多語系文件
✅ 多變的文件版面配置

受限或尚未支援：

⚠️ 表格擷取（依實作而異）
⚠️ 巢狀複雜結構
⚠️ 超大型文件（token 限制）
⚠️ 即時處理（API 延遲）
⚠️ 結果完全可重現的保證

何時應使用提示式擷取

最適用於：

版面配置多變的文件
半結構化文件
快速原型設計與測試
小到中等規模的文件量
無可用訓練資料時
多語言文件處理

下列情況建議考慮其他做法：

大規模正式環境（傳統機器學習可能較快）
高度結構化表單（以範本為基礎的擷取）
對成本敏感的應用程式（傳統方法可能較便宜）
對延遲極度敏感的應用程式（LLM API 會有網路延遲）
需要離線處理的情境（傳統方法不需網際網路連線）

與文件 Skill 整合

使用擷取的資料

完成擷取後，欄位資料可在整個文件 Skill 中使用：

驗證活動：將商業規則套用至擷取的值。
指令碼活動：處理或轉換擷取的資料。
匯出活動：將資料傳送到外部系統。
檢閱介面：手動驗證擷取的欄位。

與其他活動搭配使用

基於提示的擷取可與其他活動一同運作：

Workflow Example:
Classification (identify document type)
OCR (extract text)
Prompt-based extraction (extract structured data)
Validation rules (verify data quality)
Script (format for export)
Output (deliver results)

欄位對應

擷取的 JSON 欄位會自動對應到您定義的輸出欄位：

"FieldName": "Vendor.Name" → 對應到輸出欄位 Vendor.Name。
在輸出結構中會保留欄位階層。
行號有助於驗證與除錯。

摘要

你已成功：

✅ 建立一個提示式擷取活動。
✅ 設定 LLM 連線。
✅ 撰寫包含角色、格式與規則的完整擷取提示。
✅ 選擇最佳的文件格式（Annotated Text）。
✅ 套用嚴謹規則以確保資料品質。
✅ 測試擷取並檢閱結果。
✅ 學習提示工程的最佳實務。

重點整理：

提示式擷取使用自然語言指令。
Annotated Text 格式可提供最佳結果。
清楚、具體的提示能帶來一致的擷取結果。
嚴謹規則可避免幻覺並維持資料品質。
透過反覆測試與調整可提升準確度。

你現在的提示式擷取活動現已可以用於處理文件！

後續步驟

使用多樣化的文件進行測試：在不同版面與各種變體上進行驗證。
優化你的提示詞：根據結果持續改進。
監控成本：在 LLM 供應商的主控台中追蹤 token 使用量。
最佳化效能：為速度與準確度微調提示詞。
探索表格擷取：嘗試擷取明細項目（若有支援）。
與工作流程整合：與其他作業結合以完成端到端處理。

其他資源

ABBYY Vantage Advanced Designer 說明文件： https://docs.abbyy.com
LLM 連線設定指南： 如何設定 LLM 連線。
提示工程最佳實務： 請參閱您的 LLM 供應商的說明文件。
支援： 如需技術協助，請聯絡 ABBYY 支援團隊。

常見問題

問：提示式擷取與傳統擷取有什麼差別？ 答：提示式擷取使用 LLM 的自然語言指令，不需要訓練資料；傳統方法則需要訓練範例，但在大規模運行時速度更快、成本更具效率。 問：我可以用提示式活動來擷取表格嗎？ 答：標題層級的擷取支援良好。表格擷取能力可能會有所差異，並且需要特定的提示結構。 問：為什麼要使用 Annotated Text 而不是 PDF？ 答：Annotated Text 在結構保留與處理效率之間提供了最佳平衡，並且已在測試中證明最為可靠。 問：如何降低 API 成本？ 答：最佳化提示長度、使用 Annotated Text 格式、提升處理效率，並透過 LLM 供應商的儀表板監控 token 使用量。 問：如果我的 LLM 連線失敗怎麼辦？ 答：在 Configuration → Connections 中檢查連線狀態。測試連線、驗證認證資訊，並確認沒有超出 API 配額。 問：我可以在一個技能中使用多個 LLM 連線嗎？ 答：可以，不同活動可以使用不同連線。這讓你能針對不同的擷取任務使用不同的模型。 問：如何處理多語言的文件？ 答：在欄位規則中加入多語言的標籤變體。LLM 通常能夠很好地處理多語言內容。 問：文件的最大大小限制是多少？ 答：這取決於 LLM 供應商的 token 上限。非常長的文件可能需要拆分或分段處理。

概覽

處理文件

使用大型語言模型（LLM）

​概觀

​先決條件

​了解提示式擷取

​什麼是提示式擷取？

​優點

​限制

​步驟 1：新增提示式活動

​步驟 2：設定 LLM 連線

​步驟 3：定義輸出欄位

​步驟 4：撰寫角色定義

​步驟 5：定義輸出格式

​步驟 6：新增欄位特定的擷取規則

​步驟 7：套用嚴格性規則

​步驟 8：選擇文件格式

​步驟 9：測試您的擷取

​執行 Activity

​檢閱結果

​常見結果模式

​步驟 10：精煉你的提示詞

​常見問題與解決方案

​迭代改進流程

​優化範例

​瞭解擷取流程

​提示式擷取的運作方式

​Token 使用量與成本

​最佳做法

​提示撰寫

​Field 定義

​測試策略

​效能最佳化

​疑難排解

​擷取問題

​效能問題

​進階技巧

​條件式擷取

​多語言支援

​驗證規則

​欄位關係

​限制與考量

​目前功能

​何時應使用提示式擷取

​與文件 Skill 整合

​使用擷取的資料

​與其他活動搭配使用

​欄位對應

​摘要

​後續步驟

​其他資源

​常見問題

概觀