跳转到主要内容

概述

基于提示的抽取允许你使用自然语言指令,通过 LLM 从文档中抽取结构化数据。你无需训练传统的机器学习模型,而是描述你想要抽取哪些数据以及它们应如何格式化,LLM 会根据你的指令完成抽取。 你将完成以下内容:
  • 创建一个基于提示的抽取活动
  • 配置一个 LLM 连接
  • 编写高效的抽取提示
  • 定义输出格式和结构
  • 设置严格程度并应用校验规则
  • 测试并改进你的抽取
预计完成时间: 20–30 分钟 使用场景:
  • 从发票中抽取 Vendor 信息
  • 文档头部级数据捕获
  • 半结构化文档处理
  • 版式多变的文档

前提条件

开始之前,请确保已具备:
  1. 访问 ABBYY Vantage Advanced Designer 的权限
  2. 已配置的 LLM 连接(参见 如何配置 LLM 连接
  3. 一个已加载示例文档的 Document Skill
  4. 对 JSON 结构的基本理解
  5. 你希望提取的数据对应的 field 定义
**注意:**本指南侧重于抬头级别的提取。表格提取能力可能有所不同。

理解基于提示的提取

什么是基于提示的提取?

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

优点

  • 无需训练数据:只需进行提示工程即可
  • 灵活:易于添加或修改 field
  • 能处理多样性:LLM 能理解不同的文档格式
  • 快速设置:比训练传统的机器学习模型更快
  • 自然语言:使用简明的英文编写指令

限制

  • 成本:每次提取都会触发 LLM API 调用
  • 速度:对于简单文档,比传统提取方式更慢
  • 一致性:不同处理之间的结果可能会略有差异
  • 上下文限制:篇幅很长的文档可能需要特殊处理

步骤 1:添加基于提示的 Activity

在你的 Document Skill 中创建一个新的基于提示的提取 Activity。
  1. ABBYY Vantage Advanced Designer 中打开你的 Document Skill
  2. 在左侧面板中找到 EXTRACT FROM TEXT (NLP)
  3. 找到并单击 Prompt-based
Selecting Prompt-Based Activity
  1. 该 Activity 会出现在工作流画布中
  2. 将它连接在输入和输出 Activity 之间
注意: 基于提示的 Activity 位于 Activities 面板中的“EXTRACT FROM TEXT (NLP)”下,与 Named Entities (NER) 和 Deep Learning 等其他提取方法并列。

步骤 2:配置 LLM 连接

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

Step 3: 定义输出 fields

在编写提示词之前,先设置要提取的 fields。
  1. Activity Properties 面板中,找到 Output 部分。
  2. 你会看到一个 field 组及其下属 fields 的层级列表。
  3. 在本示例中,我们将提取 Vendor 信息:
    • Vendor
      • Name
      • Address
      • TaxID
      • Account Number
      • Sort Code
      • IBAN
      • BIC_SWIFT
    • Business Unit
      • Name
      • Address
      • Invoice Date
      • Invoice Number
    • Totals
      • Net Amount
field 输出结构
  1. 单击 Activity Editor 按钮,开始配置提示词。
注意: 在编写提示词之前,请先定义所有 fields。这些 field 名称会在你的提示词结构中被引用。

步骤 4:编写角色定义

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

您是一个数据提取模型。仅从文档中提取指定的 Vendor 相关字段。
逐字提取值文本(而非标签)。不要推断或重新格式化任何数据。
省略任何未明确出现的字段。
Prompt Text Editor 关键角色指令:
  • 要具体:“data extraction model” 告诉 LLM 它的用途
  • 定义范围:“vendor-related fields” 限定要提取的内容
  • 设定预期:“value text verbatim” 表示按原文输出文本值,避免重新格式化
  • 处理缺失数据:“Omit any field that is not clearly present” 表示对不明确存在的 field 予以省略
最佳实践:
  • 保持角色指令清晰简洁
  • 使用祈使句(“Extract”、“Do not infer”)
  • 明确说明不要做什么
  • 定义如何处理边界情况

步骤 5:定义输出格式

指定提取结果的准确 JSON 结构。
  1. 在 ROLE 部分下方添加 OUTPUT FORMAT 标题
  2. 定义 JSON 结构:
OUTPUT FORMAT

Return one valid JSON object using this exact structure:

{
  "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:必须与您的 field 定义完全匹配(例如,Vendor.Name
  • Text:提取出的值,类型为 string
  • Line:该值在文档中出现位置的从 0 开始计数的行索引
重要说明:
  • 使用 Output 配置中精确的 field 名称
  • 即使某些 field 可能为空,也要包含在内
  • 结构必须是有效的 JSON
  • 行号有助于验证和排查问题

第 6 步:添加针对各个 field 的特定提取规则

为每个 field 的提取提供详细说明。 在 OUTPUT FORMAT 下方,为每种 field 类型添加特定规则:
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) 识别"Account Number"、"Account No"、"Acct #"。
2) 完全按照打印格式提取数字格式(例如,"12-34-56"或"500 105 17")。
3) 仅限Vendor拥有的账户(例如,"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 规则结构:
  • 识别模式:为每个 field 列出可替代的标签
  • 格式规范:描述需要提取的精确格式
  • 位置提示:通常在文档的什么位置可以找到这些数据
  • 排除项:明确哪些内容不要提取
最佳实践:
  • 为规则编号,方便区分
  • 提供多个标签变体
  • 指明数据归属方(Vendor 端 vs. 客户端)
  • 在括号中提供格式示例
  • 对关联 field 进行明确说明(例如:“忽略 IBAN——它有自己的 field”)

步骤 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 可能生成看似合理但错误的数据
  • 确保一致性:明确的规则可减少多次运行之间的差异
  • 处理缺失数据:明确规定在未找到 field 时应如何处理
  • 保持数据完整性:逐字提取可保留原始格式
严格性的关键原则:
  • 绝不生成文档中不存在的数据
  • 对不确定的提取结果宁缺毋滥,不要猜测
  • 如未找到任何 fields,则返回空结构
  • 严格精确匹配 field 名称
  • 保留原始文本格式

步骤 8:选择文档格式

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

步骤 9:测试您的提取结果

在示例文档上运行此活动以验证结果。

运行 Activity

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

审查结果

处理完成后:
  1. 界面将切换到 Predictive view(预测视图)
  2. Output(输出) 面板中查看已提取的 field
  3. 点击每个 field 以查看:
    • 提取的值
    • 置信度(如有)
    • 文档图像中高亮显示的区域
Reviewing Results 需要检查的内容:
  • ✅ 所有预期的 field 都已填充
  • ✅ 值与文档完全一致
  • ✅ 没有幻觉式(虚构)或推断的数据
  • ✅ 多行 field 已被正确处理
  • ✅ 缺失的 field 被省略(不会被不正确的数据填充)

常见结果模式

成功提取:
{
  "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 }
  ]
}
部分提取(缺少某些 field):
{
  "Fields": [
    { "FieldName": "Vendor.Name", "Text": "ABC Corporation Ltd", "Line": 3 }
  ]
}
未找到任何 Fields:
{
  "Fields": []
}

步骤 10:优化提示词

根据测试结果对提示词进行迭代优化。

常见问题与解决方案

问题:LLM 提取了错误的 field
  • 解决方案:添加更具体的位置提示
  • 示例:”仅限 Vendor 端;排除客户/买方地址“
问题:格式被更改
  • 解决方案:强调按原样逐字提取
  • 示例:”按打印内容精确保留数字格式(例如:‘12-34-56’)“
问题:LLM 虚构数据
  • 解决方案:强化严格性规则
  • 示例:”绝不要生成或推断数值。如不存在则留空/省略。“
问题:多行 fields 被连接在一起
  • 解决方案:指定转义序列
  • 示例:”对于多行值,使用 \n 表示换行“
问题:输出中的 field 名称不正确
  • 解决方案:验证 field 名称完全一致
  • 示例:使用 Vendor.Account Number 而不是 AccountNumber

迭代改进流程

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

示例改进

改进前:
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 数量越多
  • 格式选择:相比 PDF,Annotated Text 通常更高效
  • field 数量:field 越多,提示词越长
优化建议:
  • 在提示词中使用简洁但清晰的语言
  • 避免重复说明
  • 删除不必要的示例
  • 对相关数据考虑进行 field 分组

最佳实践

Prompt 编写

应当:
  • ✅ 使用清晰的祈使句(“Extract”、“Recognize”、“Omit”)
  • ✅ 为每个 field 提供多个标签名称变体
  • ✅ 在括号中给出格式示例
  • ✅ 明确说明不应提取的内容(排除项)
  • ✅ 为规则编号以便于引用
  • ✅ 全文使用一致的术语
不要:
  • ❌ 使用含糊的说明(“get the name”)
  • ❌ 假设 LLM 掌握特定领域的惯例
  • ❌ 写过长、过于复杂的句子
  • ❌ 在不同部分自相矛盾
  • ❌ 省略对严格程度的规则说明

Field 定义

高效编写 Field 说明:
  • 从识别模式(备用标签)入手
  • 明确需要保留的精确格式
  • 提供位置提示(典型放置位置)
  • 定义数据归属(Vendor vs. 客户)
  • 说明如何处理多行值
  • 引用相关 field,避免混淆
示例:
IBAN(国际银行账户号码)
1) 识别"IBAN"、"International Bank Account Number"。
2) 完全按照打印格式提取完整的 IBAN(包括空格)。
3) 仅限供应商方,通常位于"Bankverbindung"、"Payment Details"下。
4) 请勿与账户号混淆——IBAN 更长且为字母数字组合。

测试策略

  1. 从简单的文档开始:先测试基础抽取能力
  2. 扩展到各种变体:尝试不同的版式和格式
  3. 测试边界情况:缺失的 field、异常位置、多重匹配
  4. 记录失败案例:保留抽取失败的示例
  5. 系统化迭代:每次只改变一个因素

性能优化

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

故障排除

提取问题

问题: 明明有数据,但 field 仍为空 解决方案:
  • 检查 field 名称拼写是否完全一致
  • 验证数据是否符合所选文档格式
  • 为识别模式添加更多标签变体
  • 暂时降低严格度,查看 LLM 是否能识别到
  • 检查文档质量是否影响 OCR/文本提取
问题: LLM 提取的是客户数据而不是 Vendor 数据 解决方案:
  • 强化针对 Vendor 的规范说明
  • 为客户/买方数据添加明确的排除规则
  • 提供位置提示(例如:“文档顶部”、“开票方区域”)
  • 提供正确与错误提取的对比示例
问题: 多行值被连在一起或格式异常 解决方案:
  • 明确指定转义序列格式(\n
  • 提供正确多行输出的示例
  • 验证文档格式是否保留换行符
  • 添加说明:“保留原始换行符,并使用 \n
问题: LLM 会重新格式化或规范化数据 解决方案:
  • 强调“逐字输出”和“完全按打印内容”
  • 添加严格规则:“禁止任何规范化或推断”
  • 提供保留原始格式的具体示例
  • 包含反例说明:“不要写成 ‘12-34-56’,保持为 ‘12 34 56’”

性能问题

问题: 抽取速度过慢 解决方案:
  • 如果使用 PDF,切换为 Annotated Text 格式
  • 在不丢失关键指令的前提下简化提示词
  • 如果图像分辨率非常高,降低文档分辨率
  • 检查 LLM 提供商的状态和速率限制
  • 对于简单文档,考虑使用更快速的模型
问题: 多次运行结果不一致 解决方案:
  • 提高规则的严格程度
  • 将指令写得更具体、更清晰
  • 增加更多格式示例
  • 降低提示词复杂度,避免产生歧义理解
  • 使用更高的 temperature 参数设置进行测试(如果当前连接中可用)
问题: API 成本过高 解决方案:
  • 优化提示词长度
  • 使用 Annotated Text 替代 PDF
  • 在非高峰时段以批处理方式处理文档
  • 对于简单文档,考虑使用更小/更低成本的模型
  • 在 LLM 提供商控制台中监控并设置预算告警

高级技巧

条件提取

你可以让 LLM 仅在满足特定条件时才提取某些 field:
账户号(条件性)
1) 仅当文档包含银行支付详情时才提取。
2) 如果出现"支付方式:支票"或类似内容,则省略此字段。
3) 识别"Account Number"、"Account No"、"Acct #"。

多语言支持

基于提示的提取在处理多语言文档时效果良好:
VENDOR NAME (MULTI-LANGUAGE)
1) Recognize in English: "Vendor Name", "Supplier", "Seller"
2) Recognize in German: "Verkäufer", "Lieferant", "Anbieter"
3) Recognize in French: "Fournisseur", "Vendeur"
4) Extract the complete company name regardless of language.

校验规则

在提示词中添加校验逻辑:
IBAN (WITH VALIDATION)
1) Extract the full IBAN exactly as printed.
2) Verify it starts with a 2-letter country code.
3) If format doesn't match IBAN pattern, omit the field.
4) Do not invent check digits or country codes.

Field 关系

指定 fields 之间的关系:
ACCOUNT NUMBER vs IBAN
- Account Number: Usually shorter, numeric, domestic format
- IBAN: Alphanumeric, starts with country code (e.g., "GB29 NWBK...")
- If both are present, extract both to separate fields
- If only one is present, extract to the appropriate field
- Do not duplicate the same value in both fields

限制与注意事项

当前功能

支持:
  • ✅ 页眉级别 field 提取
  • ✅ 单行和多行值
  • ✅ 每个文档包含多个 field
  • ✅ 条件提取逻辑
  • ✅ 多语言文档
  • ✅ 文档版式多变
受限或不支持:
  • ⚠️ 表格提取(因实现方式而异)
  • ⚠️ 嵌套的复杂结构
  • ⚠️ 超大文档(受 token 数量限制)
  • ⚠️ 实时处理(API 延迟)
  • ⚠️ 严格确定性结果保证

何时使用基于提示的抽取

最适合用于:
  • 布局多变的文档
  • 半结构化文档
  • 快速原型设计和测试
  • 小到中等规模的文档处理量
  • 缺乏训练数据的场景
  • 多语言文档处理
在以下情况下请考虑采用其他方案:
  • 大规模生产环境(传统机器学习可能更快)
  • 高度结构化的表单(基于模板的抽取)
  • 对成本敏感的应用(传统方法可能更便宜)
  • 对时延敏感的应用(LLM API 存在网络延迟)
  • 需要离线处理的场景(传统方法可在无网络环境下运行)

与 Document Skill 集成

使用提取的数据

一旦提取完成,field 数据即可在整个 Document Skill 中使用:
  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 提供商的控制台中跟踪 token 使用量
  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 配额。 问:我可以在一个 Skill 中使用多个 LLM 连接吗? 答:可以,不同活动可以使用不同的连接。这样可以为不同的抽取任务使用不同的模型。 问:如何处理多种语言的文档? 答:在 field 规则中添加多语言标签变体。LLM 通常能够很好地处理多语言内容。 问:文档的最大大小是多少? 答:这取决于你的 LLM 提供商的 token 限制。非常长的文档可能需要拆分或分段处理。