在你自己的基础设施之内处理理赔、工单和 KYC 文件的 LLM 管道：抽取、校验、复核与审计

理赔材料、客服工单和 KYC 文件有一个共同的问题：人们阅读它们，是为了填写另一个系统需要的字段。一笔理赔变成保单号、出险日期和明细行项；一条工单变成类别和客户；一份身份证件变成姓名、出生日期和有效期截止日。随这项工作而来的要求，通常在其他一切之前就被提出：这些文档不得发送给 OpenAI 或任何其他外部模型提供方。

模型在哪里运行是另一项决策，本博客此前的一篇文章对此做过比较。本文假定一个在你的基础设施之内提供服务的开放权重模型，描述围绕它的管道，从接收一直到另一个系统所消费的记录。本文讲的是机制，不是案例研究。

七个阶段，每一个都留在内部

让数据远离外部提供方，是整条管道的属性，而不是模型调用的属性：OCR 引擎、复核工具、评估集、审计存储和日志，全都持有文档或由文档派生的东西，此前那篇关于试点的文章对此有完整列举。

接收：在任何环节读取文档之前，先给它分类

后续每个阶段都取决于文档类型：schema、规则、复核人员和保留期限，所以分类排在最前面，并决定路由。一份通过邮件送来的理赔材料，可能包含理赔申请表、发票、照片和医疗报告；每个附件单独分类，并关联到同一个案件。

• 文档到达时记录渠道、发送方和内容哈希，这样被发送两次的文档会在变成两个案件之前被识别出来
• 从一份封闭的类型清单中分类；vLLM 关于结构化输出（structured outputs）的文档列出了 choice 参数，使用它时输出必然恰好是选项之一，因此分类器无法凭空编造类型
• 与任何类型都不匹配、或匹配一致度低的文档，交给人处理，而不是套用最接近的 schema

先文本与版面，后语言模型

由软件生成的 PDF 带有可以直接读取的文本层。扫描件或手机照片只有像素，必须有某个环节把像素变成带位置信息的字符。

这一步所用的开源引擎都在本地运行。Tesseract 的命令行文档展示了带有每个词置信度列的 TSV 输出，以及带有词置信度属性的 hOCR 输出，这是路由阶段可以使用的逐词信号。Docling 是一个采用 MIT 许可证的开源转换库，它把页面版面、阅读顺序和表格结构列为其 PDF 功能，还列出了对扫描 PDF 和图像的 OCR 支持，以及面向敏感数据和物理隔离（air-gapped）环境的本地执行。

• 有文本层就读文本层，没有时才用 OCR，这样干净的文档就不会沾上识别错误
• 保留每个词的页码和边界框，以便之后能在字段所出自的页面上，把每个抽取出的字段展示给复核人员
• 把表格保留为表格：一张发票的各列如果被压平成一行文本，就再也分不清哪个金额属于哪个项目

也可以改由视觉语言模型直接读取页面图像：vLLM 关于多模态输入的文档写明，图像输入按照 OpenAI Vision API 的方式受到支持。哪种方式效果更好，要在你的文档上测量；同时要记住，独立的 OCR 阶段会返回词的位置和置信度，而读取图像的模型不会。

受 schema 约束的输出：形状被强制，内容没有

每种文档类型都有自己的输出 schema，像代码一样做版本管理。vLLM 关于结构化输出的文档列出了五种约束：choice、regex、JSON schema、上下文无关文法和 structural tag；后端包括 xgrammar、guidance、outlines 和 lm-format-enforcer，默认值 auto 会根据请求的具体情况尝试选择合适的后端。

• 为每个字段设一个显式的“未找到”值，让缺失的出险日期被记录为缺失，而不是被猜出来
• 凡是另一个系统要据以分支处理的内容，都用枚举：理赔类型、工单类别、文档类型、国家代码
• 为每个字段加上来源引用，即它取自哪一页、哪些词，这样校验和复核都能拿它与文档对照

在应用代码中再用普通的 JSON Schema 校验器校验一遍输出。后端之间存在差异：同一页面指出，xgrammar、guidance 和 outlines 使用 Rust 风格的正则表达式，而 lm-format-enforcer 使用 Python 的 re 模块；还指出对于启用了推理（reasoning）的 Qwen3 Coder 模型，如果推理内容没有被解析到单独的字段中，结构化输出可能会被禁用。因 token 上限而停止的生成，也会在记录中途结束。第二道检查的成本很低。

校验：把已有的业务规则写成代码

符合 schema 的记录仍然可能是错的。能把它揪出来的检查，就是后台部门今天手工执行的那些检查，按文档类型写成代码：

• 理赔：保单号在保单系统中存在，出险日期落在保险期间之内，发票明细行项加起来等于发票总额
• 工单：客户标识符能对应到一个真实账户，且提到的产品确实是该客户拥有的
• KYC：机读区的校验位正确，有效期未过，机读区中的姓名和出生日期与从视读区读出的相同字段一致

身份证件自带校验器。机读旅行证件规范 ICAO Doc 9303 规定，机读区中的校验位按模 10 计算，权重 7、3、1 连续循环，字母 A 到 Z 分别计为 10 到 35，填充字符计为零；并写明校验位使读取设备能够验证数据是否被正确解读。

路由：由规则和信号决定人看到哪些字段

路由按字段决定，而不是按文档：一笔理赔如果只有发票总额没通过、其他一切都通过，送到人手里的是一个字段，而不是整份材料。信号包括：

• 任何校验失败，包括 schema 要求必填、而模型标记为未找到的字段
• 构成该字段的词 OCR 置信度低，阈值按字段在评估集上设定
• 两个来源不一致，例如同一本护照的机读区与视读区
• 按决定永不自动化的字段，例如超过设定限额的索赔金额
• 从全部检查都通过的字段中随机抽样，让无人标记的错误率靠测量得出，而不是靠假设

模型对自身确定性的表态被有意排除在外；本博客此前的一篇文章解释了为什么它是一道薄弱的关卡。

复核界面在建议值旁边展示页面，并高亮所引用的词，让复核人员做核对，而不是从头重读。每条更正都按字段存储，附带旧值、新值、复核人员以及从一份简短清单中选出的原因。经第二个人确认后，它进入评估集，但绝不进入据以作出发布决策的冻结部分。

按文档类型、按字段评估，而不是一个总分

整条管道只有一个准确率数字，会掩盖真正要紧的结果，例如某一个国家的身份证上有效期字段出错，而其他字段全都通过。要沿着路由所用的维度来测量：

• 按字段：规范化之后的完全匹配；另外单独统计，在文档包含或不包含该字段时，字段被漏掉或被编造的频率
• 按文档类型和输入种类，例如数字 PDF、扫描件和手机照片，因为每一种都有自己的错误模式
• 按路由：自动化处理的字段占比，以及从中抽取的样本里的错误率
• 按代价加权：银行账号写错和街道名拼错，不是同一种错误

每一次发布，无论是新的模型、提示词、schema、OCR 版本还是校验器，都要在上线之前用冻结集打分，而且关卡按字段设置：任何文档类型上的任何字段都不得跌破其合格线，即使平均分上升也不行。如何建立第一份标注集，见此前那篇关于始终没能投入生产的试点的文章。

审计轨迹：哪个模型和提示词产出了哪个字段

一笔有争议的理赔，或审计师针对某个已被接受的身份提出的问题，针对的都是一份文档上的一个字段。回答它的记录在管道运行时写下，每个字段一条，存放在只追加的存储中：

• 文档标识符和内容哈希，以及该字段所引用的页面和词
• OCR 或版面引擎的版本，以及它对这些词的置信度
• 模型名称和权重校验和、提示词模板版本和 schema 版本
• 每个校验器的结果、所走的路由及其原因
• 如果有人改过该值：复核人员、修改前后的值以及时间

EU AI Act 为其视为高风险的系统规定了日志要求：第 12(1) 条规定，高风险 AI 系统在技术上应当允许在系统生命周期内自动记录事件（日志）。附件 III 列出了高风险用途，其中包括评估自然人的信用状况（用于检测金融欺诈的除外），以及人寿和健康保险中的风险评估和定价；第 6(3) 条规定了列入清单的系统在哪些情况下仍不被视为高风险，例如执行范围狭窄的程序性任务时。某条管道是否属于适用范围，是客户法务团队要回答的问题；无论如何，在运行时写下的按字段记录都有用处。

个人数据：每个阶段只看到其任务所需的内容

管道会把个人数据复制到比原始文件夹更多的地方。GDPR 第 5(1)(c) 条要求个人数据应当充分、相关，并限于处理目的所必需的范围。第 25(2) 条要求采取措施，确保在默认情况下只处理每个特定目的所必需的个人数据，并将这一点适用于所收集数据的数量、处理的范围、存储的期限和可访问性。落到管道上就是：

• 模型收到的是其 schema 所需的页面，而不是整份案卷
• 复核人员看到的是自己队列里的字段，对完整文档的访问按角色授予并记入日志
• 应用日志记录文档标识符、字段名和结果，不记录字段值或提示词
• 提示词和输出的追踪记录，如果为调试而保留，就与文档放在同一个受限存储中，并有自己较短的保留期限
• 评估集是真实文档的副本，适用同样的访问控制

OWASP Logging Cheat Sheet 把敏感个人数据和某些形式的个人可识别信息（例如健康数据和政府颁发的标识符）列为通常不应直接记入日志的数据，并指出这类数据应当改为删除、掩码、清理、哈希或加密处理。

保留期限因文档类型而异，而在欧盟，KYC 的保留期限由反洗钱法规定。Regulation (EU) 2024/1624 第 77 条自 2027 年 7 月 10 日起适用，它要求义务实体保留在客户尽职调查中获取的文件和信息的副本，并确保这些记录不被遮蔽处理（redact）。它规定保留期为五年，自业务关系结束之日或偶发交易之日起算，期满后个人数据应予删除，但同一条中的例外情形除外。原始 KYC 记录在记录系统（system of record）中保持完整；管道自己的副本，从追踪记录到复核快照，都做最小化处理，并按自己较短的时间表删除。

吞吐量：用队列应对峰值，用容量支撑常态

后台的业务量并不均匀：一次事件可能同时波及大量投保人，一次故障就能塞满工单队列。队列、背压和人工降级方案，已在此前关于试点的文章中讨论过；自托管文档管道特有的是：

• 按紧急程度拆分队列：客户在开户过程中等着的 KYC 核验，不排在一批历史理赔后面
• 让 CPU 上的 OCR worker 和加速器上的模型服务器各自独立扩缩容，因为它们在不同的负载量下达到饱和
• 盯住推理服务引擎自己的队列：vLLM 在其 /metrics 端点暴露 Prometheus 指标，包括等待处理的请求数和键值缓存块的使用比例
• 按队列深度而不是 CPU 负载来扩缩 worker；KEDA 的文档描述了根据待处理事件的数量来扩缩 Kubernetes 中的任意容器，提供包括消息系统在内的多种 scaler，并支持缩容到零（scale-to-zero）

你自己基础设施之内的加速器容量在短期内是固定的，所以哪些队列先让路，要事先定好，而不是在峰值到来时才决定。

理赔、工单与 KYC：同一副骨架，不同的规则

• 理赔：每个案件有多份文档，发票里有表格，而且常常包含健康信息；GDPR 第 9 条将健康信息列入特殊类别，这类数据的处理是被禁止的，除非适用同一条中的某项例外。第 22 条赋予个人不受仅基于自动化处理作出的、对其产生法律效力或类似重大影响的决定约束的权利，例外情形见第 22(2) 条。因此，管道是否只负责抽取和检查、而由理赔员作出决定，是与客户的数据保护官共同作出的设计决策，而不是工程上的默认选项
• 工单：文本短、量大，而且有人在等回复，所以延迟更重要；输出大多是一个类别、一个优先级和几个标识符。工单文本由公司外部的人撰写，是模型的不可信输入，这一风险已在此前关于试点的文章中讨论过
• KYC：文档类型少、格式严格，例如护照和身份证，这让基于规则的校验很有力。用自拍与证件照片比对，会引入生物识别数据；GDPR 第 9 条在其被处理用于唯一识别某人时，同样将其列为特殊类别。保留期限遵循反洗钱法，结果输入由人或成文规则作出的合规决定

文档能否远离外部模型提供方，取决于模型在哪里运行。管道能否被托付这些文档，取决于模型周围的一切：schema、规则、复核队列，以及每个字段由谁产出的记录。

哪些工程公司能在你自己的基础设施之内搭建这类系统？

这个问题有三类答案，它们卖的东西各不相同。文档处理供应商卖的是一个平台，有时可以本地部署，由你针对自己的文档进行配置。云服务商卖的是在他们的基础设施中运行的托管服务。工程公司则用开放组件和你的规则，在你的环境中搭建管道。

无论你在和哪一类公司打交道，下面这些问题都能看出一个团队以前是否做过这件事：

• 哪些阶段会调用你网络之外的任何服务，包括 OCR、监控、错误追踪和标注工具？
• 你的某一种文档类型的输出 schema 是什么样子，“未找到”又是如何表示的？
• 哪些信号会把一个字段送去复核，阈值又是如何选定的？
• 复核人员的更正如何进入评估集，而又不污染用于发布决策的那一部分？
• 对于一份文档上的一个字段，他们能否展示产出其值的模型、提示词、schema 和复核人员？
• 工作结束时，管道代码、各个 schema 和评估集归谁所有，哪些部分仍是厂商的可复用组件？

如果对第一个和第五个问题的回答始终停留在泛泛而谈，就说明数据路径和审计轨迹还没有设计出来。

amBrain 能就自己在这一领域的工作说些什么

除上文摘要中所述的生产集成之外，amBrain 可以公开证实的内容：amBrain 自 2019 年起做软件开发。我们有三种合作方式：整体交付、专属团队，或工程师嵌入你的团队。客户拥有产品与代码的全部所有权，我们的可复用组件除外。

本文讲的是这类管道如何运作；它不是案例研究，不点名任何客户，也不声称 amBrain 构建过理赔、工单或 KYC 系统。上文提到的生产工作，是为交易系统抽取经纪商与交易场所的通知。

所以第一步不是选模型，而是在任何文档进入管道之前，针对一种文档类型，写下它的 schema、检查它的规则，以及始终必须由人过目的字段。