跳转到主要内容

​
概述

基于提示的抽取允许您使用自然语言指令，借助 LLM 从文档中抽取结构化数据。您无需训练传统的机器学习模型，而只需描述想要抽取的数据以及所需的格式，LLM 会根据您的指令完成抽取。 您将完成以下任务：
  • 创建一个基于提示的抽取活动。
  • 配置 LLM 连接。
  • 编写有效的抽取提示。
  • 定义输出格式和结构。
  • 应用严格性和验证规则。
  • 测试并优化抽取效果。
预计完成时间： 20–30 分钟 使用场景：
  • 从发票中抽取供应商信息
  • 文档表头级数据采集
  • 半结构化文档处理
  • 版式多变的文档

​
先决条件

在开始之前，请确保您已具备：
  1. 对 ABBYY Vantage Advanced Designer 的访问权限。
  2. 已配置的 LLM 连接。请参阅如何配置 LLM 连接。
  3. 一个已加载示例文档的文档技能（Document Skill）。
  4. 对 JSON 结构的基本了解。
  5. 您希望提取的数据的字段定义。
**注意：**本指南侧重于表头级数据提取。表格提取能力可能有所不同。

​
了解基于提示的抽取

​
什么是基于提示的提取？

基于提示的提取使用 LLM，根据自然语言指令来理解并从文档中提取数据。您需要定义：
  • Role：LLM 应该扮演的角色（例如，“data extraction model”）。
  • Instructions：如何提取和格式化数据。
  • Output Structure：结果所需的精确 JSON 格式。
  • Rules：处理不明确或缺失数据的规则。

​
优点

  • 无需训练数据：只需进行提示工程即可使用。
  • 灵活：可以轻松添加或修改字段。
  • 处理差异：LLM 可以理解不同的文档格式。
  • 快速设置：比训练传统机器学习模型更快。
  • 自然语言：可以直接用英语编写指令。

​
限制

  • 成本：每次提取都会发起 LLM API 调用。
  • 速度：对于简单文档，比传统提取方式更慢。
  • 一致性：多次运行之间的结果可能会略有差异。
  • 上下文限制：非常长的文档可能需要特殊处理。

​
步骤 1：添加基于提示的活动

在您的文档技能中创建一个新的基于提示的提取活动。
  1. 在 ABBYY Vantage Advanced Designer 中打开您的文档技能。
  2. 在左侧面板中找到 EXTRACT FROM TEXT (NLP)。
  3. 找到并单击 Prompt-based。
Selecting Prompt-Based Activity
  1. 该活动会出现在您的工作流画布中。
  2. 将其连接在输入活动和输出活动之间。
注意： 基于提示的活动位于活动面板中的 “EXTRACT FROM TEXT (NLP)” 分组下，与其他提取方法（例如命名实体识别 (NER) 和深度学习）一起列出。

​
步骤 2：配置 LLM 连接

选择该活动要使用的 LLM 连接。
  1. 在工作流中选择基于提示的活动。
  2. 在右侧的 Activity Properties 面板中，找到 LLM Connection。
  3. 单击下拉菜单。
Configuring LLM Connection
  1. 从列表中选择你已配置好的 LLM 连接。
    • 示例：Nick-ChatGPT、Microsoft Foundry、Production GPT-4
  2. 确认已选中了正确的连接。
注意： 如果列表中没有显示任何连接，则需要先通过 Configuration → Connections 配置一个 LLM 连接。

​
步骤 3：定义输出字段

在编写提示词之前，先设置要提取的字段。
  1. 在 Activity Properties 面板中，找到 Output 部分。
  2. 您将看到字段组和字段的分层列表。
  3. 在此示例中，我们将提取供应商信息：
    • 供应商
      • 名称
      • 地址
      • TaxID
      • 账户号码
      • Sort Code
      • IBAN
      • BIC_SWIFT
    • 业务单元
      • 名称
      • 地址
      • 发票日期
      • 发票号码
    • 合计
      • 净金额
字段输出结构
  1. 单击 Activity Editor 按钮开始配置提示词。
注意： 请在编写提示词之前定义所有字段。这些字段名称将在提示词结构中被引用。

​
步骤 4：编写角色定义

定义 LLM 在处理文档时应扮演的角色。
  1. 在 Activity Editor 中，你会看到 Prompt Text 界面
  2. 从 ROLE 部分开始：
角色

您是一个数据提取模型。仅从文档中提取指定的供应商相关字段。逐字提取值文本(而非标签)。不要推断或重新格式化任何数据。省略任何未明确显示的字段。
Prompt Text Editor 关键角色指令：
  • 要具体：“data extraction model” 告诉 LLM 它的用途。
  • 定义范围：“vendor-related fields” 限定要提取的内容（与供应商相关的字段）。
  • 设定预期：“value text verbatim” 要求按原文保留文本值，防止重新格式化。
  • 处理缺失数据：“Omit any field that is not clearly present”（省略任何不明显存在的字段）。
最佳实践：
  • 保持角色指令清晰简洁。
  • 使用祈使句式（“Extract”, “Do not infer”）。
  • 明确说明不应执行的操作。
  • 定义如何处理边界情况。

​
步骤 5：定义输出格式

指定提取结果所需的精确 JSON 结构。
  1. 在 ROLE 部分下方添加 OUTPUT FORMAT 标题。
  2. 定义 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> }
  ]
}
JSON Output Format 结构组件：
  • FieldName：必须与您的字段定义完全一致（例如：Vendor.Name）。
  • Text：以 string 类型提取的值。
  • Line：该值在文档中出现的、从 0 开始计数的行索引。
重要说明：
  • 使用 Output 配置中定义的精确字段名称。
  • 包含所有字段，即使其中某些可能为空。
  • 结构必须是有效的 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.

账户号码
1) 识别"Account Number"、"Account No"、"Acct #"。
2) 完全按照打印格式提取数字格式(例如,"12-34-56"或"500 105 17")。
3) 仅限供应商拥有的账户(例如,"Beneficiary"或"Vendor Payment"部分)。
4) 忽略 IBAN — 它有自己的字段。

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.
Extraction Rules 规则结构：
  • 识别模式：为每个字段列出替代标签。
  • 格式规范：描述要提取的精确格式。
  • 位置提示：通常在什么位置可以找到该数据。
  • 排除项：不应提取的内容。
最佳实践：
  • 为规则编号以提高清晰度。
  • 提供多种标签写法。
  • 指明数据归属（供应商方 vs. 客户方）。
  • 在括号中包含格式示例。
  • 明确说明相关字段（例如：“忽略 IBAN —— 它有自己的字段”）。

​
步骤 7：应用严格度规则

添加验证规则以确保数据质量和一致性。 在你的提示末尾添加一个 STRICTNESS 部分： 
STRICTNESS
- Never generate or infer values.
- Omit ambiguous or missing fields.
- If none of the vendor fields are found, return:
  {
    "Fields": []
  }
Strictness Rules 其他严格性规则（可选）： 
通用规则
- 每个字段仅提取一个值。
- 跳过任何无法准确定位的字段——从输出中省略。
- "FieldName" 必须与上述名称完全匹配。
- "Text" 必须从文档中逐字复制——不进行规范化或推断。
- 对于多行值(例如地址),使用转义序列"\n"(反斜杠后跟字母 n)表示每个新行。
- 不要在输出文本中插入 HTML 标签,例如 <br>。
- "Line" 是包含提取值的第一行的从 0 开始的索引;仅在可验证时包含。
严格性为何重要：
  • 防止幻觉：LLM 可能生成看似合理但错误的数据。
  • 确保一致性：清晰的规则可减少多次运行之间的差异。
  • 处理缺失数据：明确定义在未找到字段时应如何处理。
  • 维护数据完整性：逐字提取可保留原始格式。
严格性的关键原则：
  • 绝不生成文档中不存在的数据。
  • 对不确定的提取结果宁可省略也不要猜测。
  • 如果未找到任何字段，则返回空结构。
  • 与字段名称进行完全精确匹配。
  • 保留原始文本格式。

​
步骤 8：选择文档格式

选择要发送给 LLM 的文档表现形式。
  1. 在 Activity Editor 中，找到 Prompt 下拉列表。
  2. 你会看到将文档提供给 LLM 的不同方式。
文档格式选项 可用格式：
  • PDF：原始 PDF 文件
    • 适用场景：版式至关重要的文档
    • 注意事项：文件体积较大，且某些 LLM 对 PDF 的支持有限
  • Plain Text：无格式的文本提取结果
    • 适用场景：简单的纯文本文档
    • 注意事项：会丢失所有格式和版面信息
  • Annotated Text ⭐（推荐）
    • 适用场景：大多数文档类型
    • 注意事项：在保持文本形式的同时保留结构
    • 优点：在结构保留与处理性能之间取得最佳平衡
  • Formatted Text：保留基本格式的文本
    • 适用场景：对部分格式有要求的文档
    • 注意事项：介于 Plain Text 和 Annotated Text 之间的折中方案
  1. 选择 Annotated Text 以获得最佳效果
注意： 通过测试发现，Annotated Text 在抽取任务中能提供最稳定、最可靠的结果。它既能被 LLM 高效处理，又能保留文档结构。

​
步骤 9：测试提取流程

使用示例文档运行该 Activity 以验证结果。

​
运行 Activity

  1. 关闭 Activity Editor。
  2. 转到 All Documents 选项卡。
  3. 选择一个测试文档。
  4. 单击 Test Activity 或 Run 按钮。
Testing Activity
  1. 等待 LLM 处理文档：
    • 处理时间：通常为 5–30 秒，具体取决于文档复杂度。
    • 在等待 API 响应时，您会看到加载指示器。

​
审核结果

处理完成后：
  1. 界面会切换到 Predictive view。
  2. 查看显示提取字段的 Output 面板。
  3. 单击每个字段查看：
    • 提取值
    • 置信度（如果有）
    • 文档图像中高亮显示的区域
Reviewing Results 需要检查的内容：
  • ✅ 所有预期字段均已填充
  • ✅ 值与文档完全匹配
  • ✅ 不存在幻觉生成或推断的数据
  • ✅ 多行字段得到正确处理
  • ✅ 缺失字段被省略（不会使用错误数据填充）

​
常见结果模式

成功提取： 
{
  "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

​
迭代改进流程

  1. 在多个文档上进行测试：不要只针对单个示例进行优化。
  2. 记录模式：记录哪些规则有效、哪些需要改进。
  3. 添加具体示例：在括号中包含格式示例。
  4. 调整严格程度：根据过度提取/提取不足的模式进行调整。
  5. 测试边界情况：尝试使用缺少字段、布局异常的文档。

​
优化示例

优化前： 
VENDOR NAME
1) Extract the vendor name from the document.
之后： 
供应商名称
1) 识别类似 "ABC Corporation"、"XYZ Ltd"、"Acme Inc." 的名称。
2) 提取完整的公司名称,包括法律后缀(Ltd、Inc、GmbH 等)。
3) 供应商名称通常出现在文档的顶部附近。
4) 排除客户/买方名称 - 重点关注开具发票的实体。

​
理解提取过程

​
基于提示的提取工作原理

  1. 文档转换：将您的文档转换为所选格式（推荐使用 Annotated Text）。
  2. 提示构建：将您的角色、输出格式、字段规则和严格性规则组合在一起。
  3. API 调用：通过您的连接将提示和文档发送给 LLM。
  4. LLM 处理：LLM 阅读文档并根据您的指令提取数据。
  5. JSON 响应：LLM 按指定的 JSON 格式返回结构化数据。
  6. 字段映射：Vantage 将 JSON 响应映射到您定义的输出字段。
  7. 验证：行号和置信度分数（如果提供）有助于验证准确性。

​
Token 使用量和成本

影响成本的因素：
  • 文档长度：文档越长，使用的 token 越多。
  • 提示复杂度：提示越详细，消耗的 token 越多。
  • 格式选择：Annotated Text 通常比 PDF 更高效。
  • 字段数量：字段越多，提示越长。
优化建议：
  • 在提示中使用简洁但清晰的语言。
  • 不要重复说明。
  • 删除不必要的示例。
  • 考虑对相关数据进行字段分组。

​
最佳实践

​
提示词编写

请遵循以下做法：
  • ✅ 使用清晰的祈使句（如 “Extract”、“Recognize”、“Omit”）。
  • ✅ 为每个字段提供多个标签名称变体。
  • ✅ 在括号中给出格式示例。
  • ✅ 明确指定不应提取的内容（排除项）。
  • ✅ 为规则编号，便于引用。
  • ✅ 全文使用一致的术语。
请避免以下做法：
  • ❌ 使用含糊不清的指令（如 “get the name”）。
  • ❌ 假设 LLM 了解特定领域的约定。
  • ❌ 编写过长、结构复杂的句子。
  • ❌ 在不同部分出现自相矛盾的说明。
  • ❌ 忽略严格性相关规则。

​
Field 定义

高质量 Field 说明要点：
  • 从识别模式（替代标签）开始。
  • 明确需要保留的精确格式。
  • 提供位置提示（常见位置）。
  • 定义数据归属（供应商 vs. 客户）。
  • 说明如何处理多行值。
  • 引用相关 fields 以避免混淆。
示例： 
IBAN
1) 识别"IBAN"、"International Bank Account Number"。
2) 完全按照打印格式提取完整的 IBAN(包括空格)。
3) 仅限供应商侧,通常位于"Bankverbindung"、"Payment Details"下。
4) 请勿与账户号码混淆 — IBAN 更长且为字母数字组合。

​
测试策略

  1. 从简单文档开始：先测试基础提取效果。
  2. 扩展到不同变体：尝试不同的版式和格式。
  3. 测试边界情况：字段缺失、位置异常、多处匹配等。
  4. 记录失败案例：保留提取失败的示例。
  5. 系统化地迭代：每次只更改一个因素。

​
性能优化

速度优化：
  • 保持提示词简洁。
  • 使用 Annotated Text 格式。
  • 将每个活动中的字段数量降到最少。
  • 考虑拆分复杂文档。
准确性优化：
  • 提供全面的字段规则。
  • 包含格式示例。
  • 添加严格的约束规则。
  • 使用多样化的文档样本进行测试。
成本优化：
  • 优化提示词长度。
  • 使用高效的文档格式。
  • 在合适的情况下缓存结果。
  • 通过 LLM 提供商的控制面板监控 token 使用量。

​
故障排除

​
提取问题

问题： 尽管文档中存在数据，但字段为空。 解决方案：
  • 检查字段名称拼写是否完全一致。
  • 验证数据是否存在于所选文档格式/类型中。
  • 为识别模式添加更多标签文案变体。
  • 暂时降低规则严格度，查看 LLM 是否能找到数据。
  • 检查文档质量是否影响 OCR/文本提取效果。
问题： LLM 提取的是客户数据而不是供应商数据。 解决方案：
  • 强化供应商侧的规格/约束说明。
  • 为客户/买方数据添加明确的排除规则。
  • 提供位置信息提示（例如：“文档顶部”、“开票方区域”）。
  • 包含正确与错误提取结果的示例。
问题： 多行值被拼接在一起或格式异常。 解决方案：
  • 明确指定换行转义序列格式（\n）。
  • 提供正确多行输出的示例。
  • 验证文档格式是否保留换行。
  • 添加指令：“使用 \n 保留原始换行”。
问题： LLM 重新格式化或规范化数据。 解决方案：
  • 强调“原样输出”（verbatim）和“与打印内容完全一致”（exactly as printed）。
  • 添加严格规则：“不得规范化或推断”。
  • 提供保留原始格式的具体示例。
  • 包含反例：“不要改为 ‘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) 验证其以 2 个字母的国家/地区代码开头。
3) 如果格式与 IBAN 模式不匹配,则省略该字段。
4) 不要编造校验位或国家/地区代码。

​
字段关系

指定字段之间的关系： 
账户号码 vs IBAN
- 账户号码:通常较短,为数字格式,国内格式。
- IBAN:字母数字格式,以国家/地区代码开头(例如,"GB29 NWBK...")。
- 如果两者都存在,则将两者提取到单独的字段中。
- 如果仅存在其中一个,则提取到相应的字段中。
- 不要在两个字段中重复相同的值。

​
限制和注意事项

​
当前功能

支持：
  • ✅ 页眉级字段提取
  • ✅ 单行和多行值
  • ✅ 每个文档可包含多个字段
  • ✅ 条件提取逻辑
  • ✅ 多语言文档
  • ✅ 多变的文档布局
受限或不支持：
  • ⚠️ 表格提取（取决于具体实现）
  • ⚠️ 嵌套的复杂结构
  • ⚠️ 超大文档（令牌/token 限制）
  • ⚠️ 实时处理（API 延迟）
  • ⚠️ 对结果完全确定性的保证

​
何时使用基于提示的提取

最适合用于：
  • 布局多变的文档
  • 半结构化文档
  • 快速原型设计和测试
  • 小到中等规模的文档处理量
  • 无法获得训练数据的场景
  • 多语言文档处理
建议考虑其他方案的情况：
  • 大规模生产环境（传统机器学习可能更快）
  • 高度结构化的表单（基于模板的提取）
  • 对成本敏感的应用（传统方法可能更便宜）
  • 对延迟敏感的应用（LLM API 存在网络延迟）
  • 需要离线处理的场景（传统方法不需要互联网）

​
与文档技能集成

​
使用提取的数据

提取完成后，字段数据可在整个文档技能中使用：
  1. 验证活动：对提取的值应用业务规则。
  2. 脚本活动：处理或转换提取的数据。
  3. 导出活动：将数据发送到外部系统。
  4. 审核界面：对提取字段进行人工核查。

​
与其他活动配合使用

基于提示的提取可以与其他活动配合使用： 
Workflow Example:
1. Classification (identify document type)
2. OCR (extract text)
3. Prompt-based extraction (extract structured data)
4. Validation rules (verify data quality)
5. Script (format for export)
6. Output (deliver results)

​
字段映射

提取的 JSON 字段会自动映射到您定义的输出字段：
  • "FieldName": "Vendor.Name" → 映射到输出字段 Vendor.Name。
  • 字段的层级结构会在输出结构中保留。
  • 行号有助于进行验证和排查问题。

​
总结

你已经成功完成了以下操作：
  • ✅ 创建了基于提示词的提取活动。
  • ✅ 配置了 LLM 连接。
  • ✅ 编写了包含角色、格式和规则的完整提取提示词。
  • ✅ 选择了最优的文档格式（Annotated Text）。
  • ✅ 应用了用于保证数据质量的严格规则。
  • ✅ 测试了提取并审核了结果。
  • ✅ 学习了提示词工程的最佳实践。
关键要点：
  • 基于提示词的提取通过自然语言指令来工作。
  • Annotated Text 格式能够提供最佳结果。
  • 清晰、具体的提示词可以带来一致的提取效果。
  • 严格规则可以防止幻觉并保持数据质量。
  • 通过迭代测试和优化可以持续提升准确性。
你基于提示词的提取活动现已准备就绪，可用于文档处理！

​
后续步骤

  1. 使用多样化文档进行测试：在不同版式和变体上进行验证。
  2. 优化你的提示语：根据结果持续改进。
  3. 监控成本：在你的 LLM 提供商控制台中跟踪令牌使用量。
  4. 优化性能：针对速度和准确性微调提示语。
  5. 探索表格提取：尝试提取明细项（如果支持）。
  6. 集成到工作流中：与其他步骤组合以实现端到端处理。

​
其他资源

  • 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 限制。非常长的文档可能需要拆分或分段处理。