概述
- 创建一个基于提示的抽取活动
- 配置一个 LLM 连接
- 编写高效的抽取提示
- 定义输出格式和结构
- 设置严格程度并应用校验规则
- 测试并改进你的抽取
- 从发票中抽取 Vendor 信息
- 文档头部级数据捕获
- 半结构化文档处理
- 版式多变的文档
前提条件
- 访问 ABBYY Vantage Advanced Designer 的权限
- 已配置的 LLM 连接(参见 如何配置 LLM 连接)
- 一个已加载示例文档的 Document Skill
- 对 JSON 结构的基本理解
- 你希望提取的数据对应的 field 定义
理解基于提示的提取
什么是基于提示的提取?
- Role:LLM 应该扮演的角色(例如,“data extraction model”)
- Instructions:如何提取和格式化数据
- Output Structure:结果所需的精确 JSON 格式
- Rules:处理不明确或缺失数据的规则
优点
- 无需训练数据:只需进行提示工程即可
- 灵活:易于添加或修改 field
- 能处理多样性:LLM 能理解不同的文档格式
- 快速设置:比训练传统的机器学习模型更快
- 自然语言:使用简明的英文编写指令
限制
- 成本:每次提取都会触发 LLM API 调用
- 速度:对于简单文档,比传统提取方式更慢
- 一致性:不同处理之间的结果可能会略有差异
- 上下文限制:篇幅很长的文档可能需要特殊处理
步骤 1:添加基于提示的 Activity
- 在 ABBYY Vantage Advanced Designer 中打开你的 Document Skill
- 在左侧面板中找到 EXTRACT FROM TEXT (NLP)
- 找到并单击 Prompt-based

- 该 Activity 会出现在工作流画布中
- 将它连接在输入和输出 Activity 之间
步骤 2:配置 LLM 连接
- 在工作流中选择基于提示的活动
- 在右侧的 Activity Properties 面板中,找到 LLM Connection
- 单击下拉菜单

-
从列表中选择已配置好的 LLM 连接
- 示例:
Nick-ChatGPT、Microsoft Foundry、Production GPT-4
- 示例:
- 确认已选中该连接
Step 3: 定义输出 fields
- 在 Activity Properties 面板中,找到 Output 部分。
- 你会看到一个 field 组及其下属 fields 的层级列表。
- 在本示例中,我们将提取 Vendor 信息:
- Vendor
- Name
- Address
- TaxID
- Account Number
- Sort Code
- IBAN
- BIC_SWIFT
- Business Unit
- Name
- Address
- Invoice Date
- Invoice Number
- Totals
- Net Amount
- Vendor

- 单击 Activity Editor 按钮,开始配置提示词。
步骤 4:编写角色定义
- 在 Activity Editor 中,将看到 Prompt Text 界面
- 从 ROLE 部分开始:

- 要具体:“data extraction model” 告诉 LLM 它的用途
- 定义范围:“vendor-related fields” 限定要提取的内容
- 设定预期:“value text verbatim” 表示按原文输出文本值,避免重新格式化
- 处理缺失数据:“Omit any field that is not clearly present” 表示对不明确存在的 field 予以省略
- 保持角色指令清晰简洁
- 使用祈使句(“Extract”、“Do not infer”)
- 明确说明不要做什么
- 定义如何处理边界情况
步骤 5:定义输出格式
- 在 ROLE 部分下方添加 OUTPUT FORMAT 标题
- 定义 JSON 结构:

- FieldName:必须与您的 field 定义完全匹配(例如,
Vendor.Name) - Text:提取出的值,类型为 string
- Line:该值在文档中出现位置的从 0 开始计数的行索引
- 使用 Output 配置中精确的 field 名称
- 即使某些 field 可能为空,也要包含在内
- 结构必须是有效的 JSON
- 行号有助于验证和排查问题
第 6 步:添加针对各个 field 的特定提取规则

- 识别模式:为每个 field 列出可替代的标签
- 格式规范:描述需要提取的精确格式
- 位置提示:通常在文档的什么位置可以找到这些数据
- 排除项:明确哪些内容不要提取
- 为规则编号,方便区分
- 提供多个标签变体
- 指明数据归属方(Vendor 端 vs. 客户端)
- 在括号中提供格式示例
- 对关联 field 进行明确说明(例如:“忽略 IBAN——它有自己的 field”)
步骤 7:应用严格规则

- 防止幻觉:LLM 可能生成看似合理但错误的数据
- 确保一致性:明确的规则可减少多次运行之间的差异
- 处理缺失数据:明确规定在未找到 field 时应如何处理
- 保持数据完整性:逐字提取可保留原始格式
- 绝不生成文档中不存在的数据
- 对不确定的提取结果宁缺毋滥,不要猜测
- 如未找到任何 fields,则返回空结构
- 严格精确匹配 field 名称
- 保留原始文本格式
步骤 8:选择文档格式
- 在 Activity Editor 中,找到 Prompt 下拉列表
- 你将看到将文档提供给 LLM 的不同方式选项

-
PDF:原始 PDF 文件
- 适用场景:版面布局至关重要的文档
- 注意事项:文件大小较大,某些 LLM 对 PDF 的支持有限
-
Plain Text:无格式的文本提取结果
- 适用场景:简单的纯文本文档
- 注意事项:会丢失所有格式和版面布局信息
-
Annotated Text ⭐(推荐)
- 适用场景:大多数类型的文档
- 注意事项:在基于文本的同时保留结构
- 优点:在结构保留与性能之间实现最佳平衡
-
Formatted Text:保留基本格式的文本
- 适用场景:对部分格式有要求的文档
- 注意事项:介于 Plain Text 和 Annotated Text 之间的折中方案
- 选择 Annotated Text 以获得最佳效果
步骤 9:测试您的提取结果
运行 Activity
- 关闭 Activity Editor
- 转到 All Documents 选项卡
- 选择一个测试文档
- 单击 Test Activity 或 Run 按钮

- 等待 LLM 处理该文档
- 处理时间:通常为 5–30 秒,具体取决于文档复杂度
- 等待 API 响应期间,您会看到加载指示器
审查结果
- 界面将切换到 Predictive view(预测视图)
- 在 Output(输出) 面板中查看已提取的 field
- 点击每个 field 以查看:
- 提取的值
- 置信度(如有)
- 文档图像中高亮显示的区域

- ✅ 所有预期的 field 都已填充
- ✅ 值与文档完全一致
- ✅ 没有幻觉式(虚构)或推断的数据
- ✅ 多行 field 已被正确处理
- ✅ 缺失的 field 被省略(不会被不正确的数据填充)
常见结果模式
步骤 10:优化提示词
常见问题与解决方案
- 解决方案:添加更具体的位置提示
- 示例:”仅限 Vendor 端;排除客户/买方地址“
- 解决方案:强调按原样逐字提取
- 示例:”按打印内容精确保留数字格式(例如:‘12-34-56’)“
- 解决方案:强化严格性规则
- 示例:”绝不要生成或推断数值。如不存在则留空/省略。“
- 解决方案:指定转义序列
- 示例:”对于多行值,使用
\n表示换行“
- 解决方案:验证 field 名称完全一致
- 示例:使用
Vendor.Account Number而不是AccountNumber
迭代改进流程
- 在多份文档上测试:不要只针对单个示例进行优化
- 记录模式:标注哪些规则有效、哪些需要进一步改进
- 添加具体示例:在括号中包含格式示例
- 调整严格程度:根据过度提取或提取不足的模式进行调节
- 测试边界情况:尝试包含缺少 field、布局异常的文档
示例改进
理解提取流程
基于提示的抽取工作原理
- 文档转换:您的文档会被转换为所选格式(推荐使用 Annotated Text)
- 提示构建:您的角色、输出格式、字段规则和严格程度规则将被组合在一起
- API 调用:提示和文档通过您的连接发送到 LLM
- LLM 处理:LLM 阅读文档,并根据您的指令抽取数据
- JSON 响应:LLM 按指定的 JSON 格式返回结构化数据
- 字段映射:Vantage 将 JSON 响应映射到您定义的输出字段
- 验证:行号和置信度评分(如果提供)有助于核验结果的准确性
Token 使用量和成本
- 文档长度:文档越长,消耗的 token 越多
- 提示词复杂度:提示词越详细,token 数量越多
- 格式选择:相比 PDF,Annotated Text 通常更高效
- field 数量:field 越多,提示词越长
- 在提示词中使用简洁但清晰的语言
- 避免重复说明
- 删除不必要的示例
- 对相关数据考虑进行 field 分组
最佳实践
Prompt 编写
- ✅ 使用清晰的祈使句(“Extract”、“Recognize”、“Omit”)
- ✅ 为每个 field 提供多个标签名称变体
- ✅ 在括号中给出格式示例
- ✅ 明确说明不应提取的内容(排除项)
- ✅ 为规则编号以便于引用
- ✅ 全文使用一致的术语
- ❌ 使用含糊的说明(“get the name”)
- ❌ 假设 LLM 掌握特定领域的惯例
- ❌ 写过长、过于复杂的句子
- ❌ 在不同部分自相矛盾
- ❌ 省略对严格程度的规则说明
Field 定义
- 从识别模式(备用标签)入手
- 明确需要保留的精确格式
- 提供位置提示(典型放置位置)
- 定义数据归属(Vendor vs. 客户)
- 说明如何处理多行值
- 引用相关 field,避免混淆
测试策略
- 从简单的文档开始:先测试基础抽取能力
- 扩展到各种变体:尝试不同的版式和格式
- 测试边界情况:缺失的 field、异常位置、多重匹配
- 记录失败案例:保留抽取失败的示例
- 系统化迭代:每次只改变一个因素
性能优化
- 保持提示词简洁
- 使用 Annotated Text 格式
- 将每个 activity 中的 field 数量降到最少
- 考虑拆分复杂文档
- 提供全面的 field 规则
- 包含格式示例
- 添加严格的约束规则
- 使用多样化的文档样本进行测试
- 优化提示词长度
- 使用高效的文档格式
- 在合适情况下缓存结果
- 通过 LLM 提供方的控制台监控 token 使用量
故障排除
提取问题
- 检查 field 名称拼写是否完全一致
- 验证数据是否符合所选文档格式
- 为识别模式添加更多标签变体
- 暂时降低严格度,查看 LLM 是否能识别到
- 检查文档质量是否影响 OCR/文本提取
- 强化针对 Vendor 的规范说明
- 为客户/买方数据添加明确的排除规则
- 提供位置提示(例如:“文档顶部”、“开票方区域”)
- 提供正确与错误提取的对比示例
- 明确指定转义序列格式(
\n) - 提供正确多行输出的示例
- 验证文档格式是否保留换行符
- 添加说明:“保留原始换行符,并使用
\n”
- 强调“逐字输出”和“完全按打印内容”
- 添加严格规则:“禁止任何规范化或推断”
- 提供保留原始格式的具体示例
- 包含反例说明:“不要写成 ‘12-34-56’,保持为 ‘12 34 56’”
性能问题
- 如果使用 PDF,切换为 Annotated Text 格式
- 在不丢失关键指令的前提下简化提示词
- 如果图像分辨率非常高,降低文档分辨率
- 检查 LLM 提供商的状态和速率限制
- 对于简单文档,考虑使用更快速的模型
- 提高规则的严格程度
- 将指令写得更具体、更清晰
- 增加更多格式示例
- 降低提示词复杂度,避免产生歧义理解
- 使用更高的 temperature 参数设置进行测试(如果当前连接中可用)
- 优化提示词长度
- 使用 Annotated Text 替代 PDF
- 在非高峰时段以批处理方式处理文档
- 对于简单文档,考虑使用更小/更低成本的模型
- 在 LLM 提供商控制台中监控并设置预算告警
高级技巧
条件提取
多语言支持
校验规则
Field 关系
限制与注意事项
当前功能
- ✅ 页眉级别 field 提取
- ✅ 单行和多行值
- ✅ 每个文档包含多个 field
- ✅ 条件提取逻辑
- ✅ 多语言文档
- ✅ 文档版式多变
- ⚠️ 表格提取(因实现方式而异)
- ⚠️ 嵌套的复杂结构
- ⚠️ 超大文档(受 token 数量限制)
- ⚠️ 实时处理(API 延迟)
- ⚠️ 严格确定性结果保证
何时使用基于提示的抽取
- 布局多变的文档
- 半结构化文档
- 快速原型设计和测试
- 小到中等规模的文档处理量
- 缺乏训练数据的场景
- 多语言文档处理
- 大规模生产环境(传统机器学习可能更快)
- 高度结构化的表单(基于模板的抽取)
- 对成本敏感的应用(传统方法可能更便宜)
- 对时延敏感的应用(LLM API 存在网络延迟)
- 需要离线处理的场景(传统方法可在无网络环境下运行)
与 Document Skill 集成
使用提取的数据
- 验证活动:对提取的值应用业务规则
- 脚本活动:处理或转换提取的数据
- 导出活动:将数据发送到外部系统
- 复核界面:对已提取字段进行人工验证
与其他活动结合使用
字段映射
"FieldName": "Vendor.Name"→ 映射到输出字段Vendor.Name- 字段层级在输出结构中得以保留
- 行号有助于验证和故障排查
总结
- ✅ 创建基于提示的提取活动
- ✅ 配置 LLM 连接
- ✅ 编写包含角色、格式和规则的全面提取提示
- ✅ 选择最佳文档格式(Annotated Text)
- ✅ 应用严格规则以确保数据质量
- ✅ 测试提取并审查结果
- ✅ 学习提示工程的最佳实践
- 基于提示的提取是通过自然语言指令实现的
- Annotated Text 格式能够提供最佳效果
- 清晰、具体的提示可以带来一致的提取结果
- 严格规则可防止模型幻觉并保持数据质量
- 通过迭代测试和优化可提高准确性
后续步骤
- 使用多种类型的文档进行测试:验证在不同布局和格式下的效果
- 优化你的提示词:根据结果持续迭代改进
- 监控成本:在 LLM 提供商的控制台中跟踪 token 使用量
- 优化性能:为速度和准确性微调提示词
- 探索表格提取:尝试提取明细行(如果支持)
- 集成到工作流中:与其他步骤组合以实现端到端处理
其他资源
- ABBYY Vantage Advanced Designer 文档: https://docs.abbyy.com
- LLM 连接设置指南: 如何配置 LLM 连接
- 提示工程最佳实践: 请参阅您的 LLM 提供商的文档
- 支持: 如需技术支持,请联系 ABBYY 支持团队
