多模态文档流水线：从 OCR 到可追溯知识库

合同、发票和设备手册往往同时包含文字、扫描图片、表格和签章。把文件直接扔给模型很快能做出 Demo，但无法回答“这条结论来自哪一页”“重跑后为什么变化”。生产方案要把解析、抽取、校验和索引拆成可观测的流水线。

先保存原件和版本

上传文件先写入对象存储，记录 tenant_id、document_id、sha256、来源、权限、解析器版本和上传时间。文件内容不可覆盖，修订产生新版本，后续每个 chunk 和字段都保留 source_page、bbox、parser_version。

异步拆分处理阶段

上传 -> 病毒扫描 -> 文件识别 -> OCR/版面分析
                         -> 表格恢复 -> 字段抽取
                         -> 规则校验 -> 人工复核 -> 索引发布

每个阶段使用队列传递 document_id 和 version_id，不在消息里塞入整份文档。任务状态要有幂等键，worker 重启可以从失败阶段重试。OCR 和视觉模型耗时差异很大，应该分别设置并发上限，避免一类大文件拖垮全部队列。

抽取结果必须能被复核

模型输出采用 JSON Schema 校验，数值字段统一单位和小数精度。每个字段保存原文片段、页码、坐标、置信度和校验错误；金额、日期、税率等高风险字段进入人工复核队列。前端点击字段时直接定位到原 PDF 页面，而不是只展示一句模型回答。

检索与权限要在发布前完成

文档切片时继承租户、部门、密级和 ACL，生成向量前先做敏感信息处理。检索阶段先做权限过滤，再执行向量或关键词召回，不能召回后才在应用层过滤。发布前跑一组固定问题集，检查召回覆盖率、引用准确率和跨租户泄露。

生产多模态系统的核心不是“支持多少种文件”，而是每个结论都能回到原文、每次处理都能重放、每次模型升级都能比较。

参考资料：OpenTelemetry 概念。