非结构化与半结构化数据摄取

发票处理本应是一个已解决的问题。文档到达，字段被提取，数据与现有记录进行验证，结果被路由到正确的系统。现实情况是，仅发票处理每年就让企业在人工劳动上花费数十亿，而那些本应解决这个问题的自动化项目却一再崩溃。

原因在于格式多样性。发票以 PDF、电子邮件附件、扫描图像、电子表格导出，偶尔还以传真形式到达。每个供应商使用不同的布局。行项目出现在表格、自由文本或两者的组合中。税收计算遵循不同司法管辖区的不同规则。货币格式不同。日期格式不同。甚至同一供应商也会在没有任何通知的情况下更改发票模板。

传统 RPA 用模板匹配来处理这个问题：定义发票号出现的坐标、行项目开始的位置、合计所在的位置。对单个供应商的当前模板有效。然后供应商更新了他们的系统，移动了一列，添加了一个标题行，或更换了 PDF 生成器，机器人要么彻底失败，要么提取出垃圾数据，一直传播到下游，直到有人手动发现。

同样的模式在每个非结构化数据工作流中重复上演。当付款方更改表单布局时，保险 EOB 处理崩溃。当新文档类型被添加到流程中时，预授权接收崩溃。当有人使用略有不同的主题行格式时，客户邮件解析崩溃。维护这些自动化的成本往往超过手动完成工作的成本。

Triggerfish 的解决方案

Triggerfish 用基于 LLM 的文档理解取代了基于坐标的字段提取。AI 像人类一样阅读文档：理解上下文、推断字段之间的关系、自动适应布局变化。结合用于流水线编排的工作流引擎和用于数据安全的分类系统，这创建了即使世界发生变化也不会崩溃的摄取流水线。

LLM 驱动的文档解析

当文档进入 Triggerfish 工作流时，LLM 子代理基于文档的含义而非特定像素的位置来提取结构化数据。发票号就是发票号，不管它是在右上角标着"Invoice #"，还是在页面中间标着"Factura No."，或者嵌在一段文字中。LLM 理解"Net 30"意味着付款条款，"Qty"和"Quantity"和"Units"含义相同，而一个带有描述、费率和金额列的表格，不管列的顺序如何都是行项目列表。

这不是"把文档发给 ChatGPT 然后碰运气"的通用方法。工作流定义精确指定了 LLM 应该生成的结构化输出、适用的验证规则，以及当提取置信度较低时的处理方式。子代理任务描述定义了预期的 Schema，工作流的后续步骤在数据进入任何下游系统之前，会根据业务规则验证提取的数据。

用于文档检索的浏览器自动化

许多文档摄取工作流首先需要获取文档本身。保险 EOB 存在于付款方门户。供应商发票存在于供应商平台。政府表单存在于州政府机构网站。传统自动化使用 Selenium 脚本或 API 调用来获取这些文档，当门户发生变化时这些脚本就会崩溃。

Triggerfish 的浏览器自动化使用 LLM 读取页面快照来导航的 CDP 控制 Chromium。代理像人类一样看待页面，而不是将其视为 DOM 树，基于所见而非硬编码的 CSS 选择器进行点击、输入和滚动。当付款方门户重新设计其登录页面时，代理能够适应，因为它仍然可以从视觉上下文中识别用户名字段、密码字段和提交按钮。当导航菜单发生变化时，代理会找到文档下载部分的新路径。

这并不意味着完全可靠。CAPTCHA、多因素认证流程和高度依赖 JavaScript 的门户仍然会造成问题。但失败模式从根本上不同于传统脚本。当 CSS 选择器停止匹配时，Selenium 脚本会悄然失败。Triggerfish 代理会报告它看到了什么、尝试了什么以及在哪里卡住了，给运营人员提供足够的上下文来干预或调整工作流。

分类门控处理

文档具有不同的敏感度级别，分类系统会自动处理这一点。包含定价条款的发票可能是 CONFIDENTIAL。公开的招标响应可能是 INTERNAL。包含 PHI 的文档是 RESTRICTED。当 LLM 子代理读取文档并提取数据时，POST_TOOL_RESPONSE 钩子对提取的内容进行分类，会话 taint 相应升级。

这对下游路由至关重要。分类为 CONFIDENTIAL 的提取发票数据无法发送到分类为 PUBLIC 的 Slack 频道。处理包含 PHI 的保险文档的工作流，会自动限制提取数据的流向。写入降级防止规则在每个边界处执行，LLM 没有任何覆盖它的权限。

对于医疗和金融服务行业，这意味着自动化文档处理的合规开销大幅降低。不需要在每条流水线的每个步骤中构建定制的访问控制，分类系统统一处理。审计员可以追踪每份处理过的文档、提取的数据、发送目的地，并确认没有数据流向不适当的目的地——这一切都来自每个步骤自动创建的血缘记录。

自愈格式适配

当供应商更改发票模板时，传统自动化会崩溃，直到有人手动更新提取规则才能恢复。在 Triggerfish 中，LLM 子代理在下一次运行时就会自适应。因为它读取的是含义而不是位置，所以仍然能找到发票号、行项目和合计金额。提取成功，数据根据相同的业务规则进行验证，工作流完成。

随着时间推移，代理可以使用跨会话记忆来学习模式。如果供应商 A 总是包含其他供应商没有的补货费，代理会从之前的提取中记住这一点，知道要查找它。如果某个特定付款方的 EOB 格式总是将调整码放在不寻常的位置，代理对过去成功提取的记忆会使未来的提取更加可靠。

当格式更改足够重大，使 LLM 的提取置信度降至工作流定义的阈值以下时，工作流会将文档路由到人工审查队列，而不是胡乱猜测。人工修正通过工作流反馈，代理的记忆存储新模式以备将来参考。系统随时间变得更智能，无需任何人重写提取规则。

流水线编排

文档摄取很少只是"提取并存储"。完整的流水线需要获取文档、提取结构化数据、与现有记录进行验证、用其他系统的数据进行丰富、将异常路由到人工审查，并将已验证数据加载到目标系统。工作流引擎用单个 YAML 定义处理所有这些。

一个医疗预授权流水线可能是这样的：浏览器自动化从提供者门户获取传真图像，LLM 子代理提取患者标识符和操作代码，HTTP 调用根据 EHR 验证患者，另一个子代理根据临床文档评估授权是否满足医疗必要性标准，结果被路由到自动批准或临床审查队列。每个步骤都进行分类追踪。每条 PHI 都有 taint 标签。完整的审计追踪自动存在。

实际应用案例

一家地区医疗系统处理来自 40 个不同提供者诊所的预授权请求，每个诊所使用自己的表单布局，有些通过传真，有些通过电子邮件，有些上传到门户。传统方法需要一个八人团队手动审查和录入每个请求，因为没有自动化工具能够可靠地处理格式多样性。

使用 Triggerfish，工作流处理完整的流水线。浏览器自动化或邮件解析获取文档。LLM 子代理不管格式如何都能提取结构化数据。验证步骤根据 EHR 和处方集数据库检查提取的数据。RESTRICTED 的分类上限确保 PHI 不会离开流水线边界。LLM 无法以高置信度解析的文档被路由给人工审查员，但随着代理的记忆构建格式模式库，这个量会随时间减少。

八人团队变成了两人处理系统标记的异常，加上对自动提取的定期质量审计。来自提供者诊所的格式更改被自动吸收。新的表单布局在第一次遇到时就得到处理。曾经消耗大部分传统自动化预算的维护成本降至接近零。