一种三层混合架构可将 Azure OpenAI 的成本降低 75%，并在 4700 份文档的生产级工作负载中把处理耗时缩短 55%。2026 年云文档处理的默认架构是将每份文档都推送给托管 AI 端点，然后接收返回的结构化数据。这种方式虽然可行，但效率低下。在工程图纸、发票、监管文件这类具有固定结构化版式的文档语料中，有 60% 至 70% 的输入内容都可以通过确定性本地算法在毫秒级完成处理，且无需产生任何 API 调用成本。
本文介绍了一种我称之为本地优先 AI 推理（Local-First AI Inference）的可复用模式：这是一种三层架构，由确定性本地处理器处理大部分输入内容，云端 AI 服务仅用于应对边缘情况，人工审核层则用来限制错误率。云 AI 系统中最重要的架构选择不在于选用哪款模型，而在于何时调用模型。本地优先模式打破了固有的默认做法，提出了一个核心问题：“这份文档是否真的需要调用云端模型？”而不是不加区分地将所有内容都发送给端点。
我在 Azure 上部署了这种模式，用于从 4700 多份工程图纸 PDF 文件中提取元数据。采用纯云端方案需要花费 47 美元的 Azure OpenAI API 调用费用，耗时 100 分钟，且每份文档都会存在幻觉风险。采用混合架构方案后，API 成本降至 10 至 15 美元，处理时长缩短至 45 分钟，同时人工审核层有效控制了错误率。
手动替代方案需要工程师逐份打开 PDF、查找标题栏，并把修订信息录入电子表格，每份文档大约耗时 2 分钟，4700 份文件合计约 160 个工时。按照工程人力费率计算，每次迁移流程的成本超过 8000 英镑。这个系统已在四个站点投入使用。这种模式可推广至所有输入结构可预测的云 AI 工作负载场景：发票处理、合同信息提取、医疗记录解析等。
层级数量由失败模式的数量决定。双层系统（本地加云端）要么默认采信存在幻觉的云端结果，要么直接拒绝这类结果并丢失覆盖率。四层系统会增加复杂度，但可靠性不会获得相应的提升。三层架构是覆盖全部三类失败场景所需的最少层级：可通过规则直接处理的文档（第 1 层）、需要通过视觉解析的文档（第 2 层），以及以上两种方式都不足以可靠处理、必须依靠人工介入审核的文档（第 3 层）。
每份文档都经过 PyMuPDF 本地提取环节进入处理流水线。第一层能以零 API 成本、单文档约 3 秒的耗时处理 70% 至 80% 的文档。这个层级采用高精准度、低召回率的设计原则：当无法确定结果时，会直接返回空值而不是猜测。它几乎不会产生误报，但会漏掉版式特殊的文档，而这类文档恰好可以交由第二层处理。
未能通过第一层处理的文档会被渲染成图像并发送给 Azure OpenAI 的 GPT-4 Vision 端点。这一层以每次调用约 1 美分、每份文档约 10 秒的耗时处理 20% 至 30% 的文档。它的失败模式与第一层恰好相反：有可能给出看似笃定实则错误的结果。
第一层与第二层产出结果存在冲突的文档或是第二层返回低置信度输出的文档都会被标记为人工审核，这类文档约占总量的 5%。
图 1. 本地优先 AI 推理架构——三层混合流水线
注意图 1 中各层之间的差异：
第 1 层（本地 PyMuPDF 提取，占比 70% 至 80%，耗时约 3 秒，零成本），有置信度门控。
第 2 层（Azure OpenAI Vision 兜底处理，占比 20% 至 30%，耗时约 10 秒，单次花费 1 美分）。
第 3 层（人工审核，占比约 5%）。
从第一层升级至第二层的决策由置信度评分函数驱动。候选内容先经过黑名单过滤，再根据四项加权标准进行打分。
在进行评分之前，显式黑名单会剔除已知的误报模式：截面标记（“SECTION C-C”）、网格参考字母、页码标识（“OF”）以及修订历史列标题。凡是匹配黑名单的候选项都会被直接剔除，不再参与后续评分。
提取器将搜索限制在预期目标字段所在的文档区域内（工程图纸标题栏位于页面底部 30%、右侧 40% 的范围）。该区域以外的候选项都会被舍弃。同样的原则也适用于其他场景：发票号码通常在右上角，合同日期则出现在序言部分。
图 2：带注释的工程图纸
图 2 是一份代表性图纸，包含标题栏（右下角）及 REV 值“E”、修订历史表（右上角，常见误报来源），还有网格参考字母（边框位置，极易被误判为单字母修订值）。
靠近已知标签（“REV:”、“DWG NO”、“SHEET”）的候选项会获得更高分。与标签精确相邻（例如 “REV: E”）的得分最高；在同一区域内共同出现的得分则相对更低。
候选项会按照合规格式进行校验：带连字符的数字编号（1-0、2-0）、单个英文字母（A-Z）、双字母组合（AA、AB）以及特殊值（EMPTY、NO_REV）。凡是不符合格式的候选项都会被做降分处理。
证实候选项有效性的次要指标包括：邻近佐证标签（SHEET、SCALE、DWG NO 在附近出现）、与其他已提取元数据的一致性，以及同一区域内不存在相互冲突的候选项。
综合得分计算如下：
score = (40 * spatial) + (30 * anchor) + (20 * format) + (10 * context),
其中空间维度为二元判定（在边界区域内/不在边界区域内），锚点权重随着与最近标签的像素距离衰减，格式维度同样为二元判定（格式有效/格式无效）；上下文则用来捕获次要信号：邻近佐证标签（SHEET、SCALE、DWG NO 在附近出现）、与其他已提取元数据的一致性，以及同一区域内不存在冲突候选项。
参考图 2，PyMuPDF 从图纸中提取文本，并在三个不同位置识别出字符“E”：位于右下角标题栏的 REV 字段内（紧邻图纸编号）、右上角修订历史表的最新条目处（附带备注“New Release”），以及右侧边框上的网格参考字母。三处字符完全一致，这也正是空间评分机制至关重要的原因。
网格参考字符“E”会因为无法通过空间过滤（处在标题栏边界区域之外，空间得分为 0.0）立即被舍弃。修订历史处的“E”通过了空间过滤（位于页面右侧区域，空间得分为 1.0）与格式校验（为合法单字母，格式得分为 1.0），但锚点得分仅为 0.2，原因是它处在 DESCRIPTION 列标题旁，而非 REV 标签旁；上下文得分为 0.0，因其周边标签（LTR、REVISION、DPT）与佐证标签集合（SHEET、SCALE、DWG NO）并不匹配，综合得分为 66。标题栏处的“E”空间得分为 1.0（处于边界区域内），锚点得分为 1.0（与“REV”标签直接相邻），格式得分为 1.0（合规单字母），上下文得分为 0.8（SHEET、SCALE、DWG NO 均在周边区域），综合得分为 98。系统以高置信度选定标题栏的“E”，直接输出结果，无需调用云端 API。倘若它的得分为 72（例如 REV 标签破损或缺失，仅能依靠位置做推断），则会被送入第二层进行云端核验。
路由阈值设置如下：90 分及以上直接输出结果（高置信度），50 至 89 分触发第二层校验，低于 50 分则启动完整云端提取。
通过分层抽样构建了包含 400 份文件的验证集，涵盖 PDF 格式（含文本型与扫描型，贴合语料库 7:3 的比例）、版本格式（五个类别均有样本覆盖）以及文档年份（1995 至 2024 年，包含扫描质量与标题栏布局的各类变化）。真实标签由工程师手动标定，工程师逐份打开文档并记录版本 REV 值。对于模糊样本（扫描破损、版式特殊的文档），由第二位工程师独立复核数值。存在分歧的样本（约占整体的 3%），通过查阅实体图纸档案最终裁定。
系统提示词经过了五轮迭代，每一轮迭代均由一类特定错误触发：
每轮迭代都会在部署前对完整的 400 份文件数据集进行测试。仅优化某一类格式但会导致其他类别性能下降的更改会作为性能回归予以驳回。整体准确率从 89% 提升至 98%，历时三周、历经五个迭代周期，每个周期都专门针对当前占比最高的单一错误类型，而非盲目进行大范围泛化优化。
纯云方案与混合方案之间 2% 的准确率差距在脱离上下文的情况下具有误导性。纯云方案 98% 的准确率意味着仍有 2% 的文档会默认接收错误结果，且没有任何机制能够识别这类疏漏。对于工程图纸而言，错误的版本修订号可能会导致按照过时规格生产零部件，这类静默错误远比已知遗漏风险更高。混合方案的预审核准确率略低，仅有 96%，但由人工审核的 5% 文档可捕获剩余的错误，最终审核后的实际准确率可超 99%。核心问题不在于预审核数值谁更高，而在于产生的错误是静默隐藏还是被主动暴露。
云推理应该被视为异常处理路径，而非默认的路径。本节中的每一项架构设计决策均遵循这一原则。
我使用 Azure OpenAI 服务（而非直接调用 OpenAI API），确保可以将文档内容保留在组织的 Azure 租户环境内。系统主动管理速率限制（严格控制在配额上限内，而不是等到触发 429 错误后重试）。图像以 150 DPI 分辨率渲染，因为针对 400 份文件验证集的测试表明，72 DPI 会降低扫描件的识别准确率，而 300 DPI 使会负载体积翻倍，却不会带来效果提升。预调用验证（旋转校正、空白页检测）防止了约 5% 的 API 调用被浪费。
结构化日志会记录每层路由去向、置信度得分、处理耗时，以及每份文档的 Azure OpenAI 词元消耗量。漂移检测用于监控运行过程中第一层的成功率：若数值持续下降，说明语料库中的文档格式已发生变化。第二层调用失败时，采用指数退避策略进行重试（最多重试三次），之后再路由至第三层。对于产生幻觉的结果，绝不使用相同提示词进行重试。
在 GPT-4.1 上运行稳定后，我使用相同的生产提示词在 GPT-5+ 上进行基准测试，针对相同的 400 份文件验证集且未对新模型做任何修改。整体准确率表现持平，两者均达到 98%。我按照文档类别对结果做了细分：文本清晰且标题栏规整的 PDF、打印质量欠佳的扫描件，以及过往易产生误报的特殊布局图纸。三类文档的表现均相差无几。GPT-5+ 既没有识别出 GPT-4.1 遗漏的文档，也未出现新的失败类型。提取任务本质是在限定文档区域内进行受空间约束的模式匹配，性能上限取决于系统能否锁定正确识别区域并设置合理判定规则，而非大模型自身的推理能力。
Azure 上的模型迁移工作（包含新部署、提示词重新验证、API 版本更新、速率限制测试以及完整验证套件测试）只在新模型能够为实际业务负载带来可量化的提升时才有价值。本次场景中新模型并无实质提升，因此我继续使用 GPT-4.1，规避了不必要的迁移成本与工作量。
该系统已从单站点命令行工具扩展为部署在四个工程站点上的内部 Web 应用。
用户通过 Azure AD 安全组进行身份验证。Azure OpenAI 服务主体采用权限受限的独立应用注册，与用户会话解耦。API 密钥存储在 Azure Key Vault 中，运行时通过托管身份进行读取，任何站点均无法直接访问凭证信息。
图 3. 多站点部署架构
图 3 展示了进行本地第一层提取的各站点节点，这些节点通过 Azure AD、密钥保管库及托管身份接入共享的 Azure OpenAI 环境。系统同时配备了站点本地文档存储，并支持元数据统一输出。
本地提取任务（第 1 层）在每个站点自己的计算资源上运行。Azure OpenAI 端点是共享的，并在各站点之间分配速率限制配额，防止某一个站点的大批量作业挤占其他站点资源。每次提取任务均以批处理作业形式提交；Web 应用程序先验证上传的文件，将其写入暂存区域并加入作业排队。作业在每个站点内按顺序执行，但在各站点之间是独立并行运行的。上传的文档保留在站点本地存储中，只有结构化元数据（CSV 输出）传给下游资产管理系统所用的共享网络路径。因此，原始文档永远不会离开它们所在的站点。新站点上线需要部署 Web 应用程序、添加 Azure AD 安全组并分配速率限制配额，无需修改提取逻辑或 Azure OpenAI 部署配置。
当三个条件同时满足时，本地优先 AI 推理模式就会奏效：目标字段具备可预测的空间位置、语料库包含大量文本类文件，且任务仅涉及单一且定义明确的数值。若无法满足以上条件，则采用替代架构会更为合适。
对于自由格式文档（会议记录、普通信函），第 1 层不存在相关锚点，所有文档都会进入第 2 层。此时运行的是有额外开销的纯云架构。在这些情况下，可以直接跳过本地层，并投入精力设计结构化提示词，对输出结果进行模式验证。
如果 80% 或更多的文档是扫描图像，本地提取几乎无法处理。此时应转向纯云架构，同时采用高效批处理、请求并行化，以及重复文档模板的缓存层方案。
提取相互依赖的字段（发票行项目，其中数量、价格和总额必须一致）会让置信度阈值更难校准。采用结构化输出验证的云优先方案，由模型将所有字段以 JSON 格式返回，再通过后处理步骤校验内部一致性，这种方式远比依靠脆弱的跨字段规则做本地提取更为可靠。
黑名单与空间启发式规则均针对已知语料库做了适配调整。若文档格式频繁变动（如新供应商、新标题栏布局），第一层的识别成功率会下降，维护成本也随之增加。对于高度异构的文档来源，结合少样本提示词、并以格式检测分类器作为路由层的云优先处理方案，相比人工调校的空间规则，能够更平稳、顺畅地自适应适配。
查看英文原文：https://www.infoq.com/articles/local-first-ai-inference-cloud/
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。