本地优先AI推理：一种低成本文档处理的云架构模式

标题：本地优先的AI推理：一种面向成本效益文档处理的云架构模式

来源网址：https://www.infoq.com/articles/local-first-ai-inference-cloud/

发布时间：2026-05-11T11:00:00+0000

关键要点

• 在云AI系统中，最重要的架构决策并非选择哪个模型，而是是否调用模型。本地优先AI推理模式通过置信度过滤路由，将70%到80%的文档交由确定性本地提取处理，无需API成本，使Azure OpenAI调用量减少75%。
• 结合空间、锚点、格式和上下文等多维度的复合评分函数，优于简单的文本存在检查或单一标准方法。多个标准之间的交互能捕捉到单个标准无法识别的误报情况，例如在同一字符上区分得分98的标题块候选和得分66的修订历史候选。
• 模型升级应基于任务特定的验证集进行评估，而非依赖厂商基准。在包含四百个文件的验证集中，GPT-5+相比GPT-4.1未显示出准确率提升，在基于文本、扫描件及非常规布局的各类别中表现相当，从而避免了在Azure上不必要的迁移。
• 生产环境中的提取系统所使用的提示词是工程产物，而非自然语言请求。经过五轮迭代（每轮针对特定错误类型：修订表混淆、网格引用误报、格式偏差、记忆化现象、置信度校准），准确率从89%提升至98%。
• 生产级云AI系统需要明确的故障边界。三层架构（本地确定性处理、云端AI、人工审核）能够控制错误率，这是纯云方案（存在2%的静默幻觉风险）或纯本地方案（完全无法处理扫描文档）都无法独立实现的。

该三层混合架构在处理四千七百份文档的生产负载时，将Azure OpenAI成本降低了75%，处理时间缩短了55%。2026年默认的云文档处理架构是将每份文档发送至托管AI端点并返回结构化数据。这种方式可行，但存在浪费。对于具有结构化布局的文档语料库（如工程图纸、发票或监管申报文件），60%至70%的输入可通过确定性本地方法在毫秒级完成处理，且无API成本。

本文介绍一种我称之为“本地优先AI推理”的可复用模式：一种三层架构，其中确定性本地处理承担大部分输入，云AI服务仅用于边缘情况，人工审核层则限定错误率。在云AI系统中，最重要的架构决策不是使用哪个模型，而是是否调用模型。“本地优先”模式颠覆了默认做法，转而提问：“这份文档真的需要调用云模型吗？”，而不是将所有内容都发送到端点。

我在Azure上部署了该模式，用于从四千七百余份工程图纸PDF中提取元数据。若采用云优先方式，需花费47美元的Azure OpenAI API费用，耗时100分钟，并在每份文档上引入静默幻觉风险。而混合方案将API成本降至10至15美元，处理时间缩短至45分钟，并通过人工审核层限定了错误率。

#### 相关赞助商

• ##### Gartner® 研究：2025年云平台服务技术成熟度曲线™

• ##### Jakarta EE开发者必备的AI工具指南

• ##### 借助具身智能AI构建顶尖应用——融合架构防护以确保确定性结果

• ##### 为未来而设计：高级实践者必须关注的关键软件趋势——下载InfoQ电子杂志

• ##### 基于AWS构建的具身智能AI运维系统

作为替代的人工方式，工程师需逐一打开每个PDF文件，定位标题块，并将修订版本记录到电子表格中，平均每份文档耗时约两分钟，四千七百份文件总计约一百六十人时。按工程师人力成本计算，每次迁移成本超过八千英镑。该系统已在四个站点推广使用。此模式可推广至任何输入结构可预测的云AI工作负载场景：如发票处理、合同信息提取、医疗记录解析。

三层架构

故障模式的数量决定了层级的数量。一个两层系统（本地加云端）要么会静默接受错误的云端结果，要么拒绝这些结果从而失去覆盖范围。而一个四层系统则会增加复杂性，却无法带来相应的可靠性提升。三层系统是覆盖所有三类故障所需的最小配置：规则可处理的文档（第一层），需要视觉解释的文档（第二层），以及两种方法均不足以可信、必须由人工介入的文档（第三层）。

第一层：本地确定性提取

每份文档都通过使用 PyMuPDF 的本地提取阶段进入流水线。第一层以零 API 成本和约每份文档三秒的速度处理 70% 到 80% 的文档。其设计追求高精度和低召回率：当系统不确定时，它会选择不返回任何内容，而不是猜测。它极少引入误报，但可能遗漏布局异常的文档——这正是第二层要处理的情况。

第二层：云端 AI 推理

未能通过第一层的文档将被渲染为图像，并发送至 Azure OpenAI 的 GPT-4 Vision 端点。该层以每次调用约一美分、每份文档约十秒的速度处理 20% 到 30% 的文档。它的失败模式与第一层相反：可能会返回一个看似自信但实际错误的答案。

第三层：人工审核队列

当第一层和第二层的结果冲突，或第二层返回低置信度输出时，相关文档将被标记进行人工检查（约占文档总数的 5%）。

/filters:no_upscale()/articles/local-first-ai-inference-cloud/en/resources/1Figure-1-Local-First-AI-Inference-architecture-Three-tier-hybrid-pipeline-1778143383111.jpg)

图 1. 本地优先 AI 推理架构 —— 三层混合流水线

注意图 1 中各层之间的差异：

• 第一层（本地 PyMuPDF 提取，70%–80%，约三秒，零成本），带有置信度过滤机制。
• 第二层（Azure OpenAI Vision 回退方案，20%–30%，约十秒，一美分）。
• 第三层（人工审核，约 5%）。

置信度评分：该架构模式的核心

从第一层升级到第二层的决策由一个置信度评分函数驱动。候选结果首先经过黑名单过滤，然后根据四个加权标准进行评分。

预过滤：黑名单

在评分之前，一个明确的黑名单会排除已知的误报模式：章节标记（“SECTION C-C”）、网格参考字母、页码标识（“OF”）以及修订历史列标题。匹配黑名单的候选结果将被完全移除，不再参与评分。

空间位置

提取器将其搜索范围限制在目标字段预期出现的文档区域（对于工程图纸标题栏而言，通常是页面底部 30%、右侧 40% 的区域）。位于该区域之外的候选结果将被丢弃。这一原则也适用于其他领域：例如发票号位于右上角，合同日期出现在前言部分。

/filters:no_upscale()/articles/local-first-ai-inference-cloud/en/resources/1Figure-2-Annotated-engineering-drawing-1778143383111.jpg)

图 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),

其中：

• spatial 为二值变量（是否在指定区域内），
• anchor 随距最近标签的像素距离衰减，
• format 为二值变量（格式是否有效），
• context 捕获次要信号：包括靠近佐证性标签、与其他元数据一致、且同区域内无冲突候选。

一个具体示例

参考图 2，PyMuPDF 从图纸中提取文本，在三个不同位置发现了字符 “E”：标题栏的 REV 字段中（右下角，紧邻图纸编号）、修订历史表的最新条目中（右上角，附有描述 “New Release”），以及右侧边框的网格参考字母中。这三个都是相同的字符 “E”，这也正是空间评分至关重要的原因。

网格参考“E”立即未能通过空间过滤（它位于标题块边界区域之外，空间得分 spatial=0.0），因此被丢弃。修订历史中的“E”通过了空间过滤（位于页面右侧合适位置，spatial=1.0）和格式检查（有效的单个字母，format=1.0），但由于其旁边是“DESCRIPTION”列标题而非“REV”标签，anchor 得分为 0.2；同时 context 得分为 0.0，因为周围的标签（LTR、REVISION、DPT）与支持性标签集合（SHEET、SCALE、DWG NO）不匹配，最终综合得分为 40 + 6 + 20 + 0 = 66。而标题块中的“E”在空间上得分为 1.0（位于边界区域内），anchor 得分为 1.0（紧邻“REV”标签），format 得分为 1.0（有效单字母），context 得分为 0.8（SHEET、SCALE 和 DWG NO 均在附近出现），总得分为 40 + 30 + 20 + 8 = 98。系统以高置信度选择该标题块“E”，并直接输出结果，无需调用云端 API。如果其得分为 72（例如，“REV”标签损坏或缺失，仅依赖位置推断），则会被送往第二层级进行云端验证。

路由阈值如下：得分 90 及以上直接输出（高置信度），50–89 触发第二层级验证，低于 50 则触发完整云端提取。

验证方法与提示词迭代

四百份文件的验证集通过分层抽样构建，涵盖 PDF 格式（基于文本 vs 扫描件，反映语料库中 70/30 的比例）、REV 格式（五类均覆盖）以及文档年代（1995–2024 年，涵盖扫描质量和标题块布局的变化）。真实标签由工程师手动建立：打开每份文档并记录 REV 值。对于模糊情况（如扫描损坏、布局异常），由第二位工程师独立复核。分歧案例（约占样本的 3%）通过查阅实体图纸档案解决。

系统提示词经历了五轮迭代，每次均由特定错误类型触发：

| 迭代次数 | 准确率 | 主要错误 | |--------|-------|--------| | 第1轮（基线） | 89% | 模型从修订历史表中提取而非标题块 | | 第2轮 | 93% | 添加修订表排除规则；新错误：将网格参考字母误作 REV 值 | | 第3轮 | 95% | 增加空间指令和黑名单；新错误：对数字 REV 存在格式偏见（即使图纸显示“A”，仍输出“2-0”） | | 第4轮 | 97% | 扩展至十二个涵盖所有格式的示例，加入防记忆化警告和自检清单 | | 第5轮 | 98% | 增加置信度校准（高/中/低），使不确定结果可进入第三层级处理 |

每次迭代均在完整的四百份文件集上测试后才部署上线。若某项修改提升了某一格式类别的表现却降低了其他类别，则视为退化而被拒绝。准确率从 89% 提升至 98% 共经历五轮，耗时三周，每轮聚焦于当前最大单一错误类别，而非追求广泛改进。

权衡分析

| 方法 | API 成本（n=4,700） | 处理时间 | 准确率（审前） | 实际准确率（审后） | 失败模式 | |------|---------------------|----------|----------------|--------------------|----------| | 纯云端 | ~$47 | ~100 分钟 | 98% | 98%（无审核层级） | 静默幻觉（2% 错误未被发现） | | 纯本地 | $0 | ~25 分钟 | 85–90% | 85–90%（无审核层级） | 无法处理扫描件 | | 混合模式（本地优先 AI） | ~$10–15 | ~45 分钟 | 96%（+5% 审核） | ~99%+（经 5% 人工审核后） | 受限于审核层级 |

若脱离上下文，纯云端与混合模式在审前准确率之间 2% 的差距具有误导性。纯云端的 98% 意味着有 2% 的文档会静默接收错误值，且无任何检测机制。对于工程图纸而言，错误的版本号可能导致按过时规范制造零件，因此静默错误比已知缺陷更危险。混合模式的审前准确率为 96%，虽较低，但通过将 5% 的文档送入人工审核捕获剩余错误，最终实现审后有效准确率超过 99%。关键问题不在于哪个审前数值更高，而在于你的错误是静默发生还是被暴露出来。

云端部署与运维

应将云端推理视为异常路径，而非默认路径。本节中的每一项架构决策皆源于此原则。

Azure OpenAI 治理

我使用 Azure OpenAI 服务（而非直接调用 OpenAI API），以确保文档内容保留在组织的 Azure 租户内。速率限制被主动管理（按配额限流，而非重试 429 错误）。图像载荷在 150 DPI 下渲染，此前在 400 文件验证集上的测试表明：72 DPI 会降低扫描件识别准确率，而 300 DPI 会使载荷大小翻倍却无精度提升。预调用验证（旋转校正、空白页检测）避免了约 5% 的无效 API 调用。

可观测性

结构化日志记录每份文档的层级路由、置信度得分、处理时间和 Azure OpenAI 的 token 使用量。漂移检测持续监控第一层级的成功率：若成功率持续下降，则表明语料库格式发生变化。第二层级失败任务采用指数退避重试（最多三次），之后转入第三层级。对于幻觉结果，绝不会使用相同提示词重复请求。

将模型升级视为基础设施迁移

在稳定使用 GPT-4.1 后，我使用完全相同的生产提示词（未对新模型做任何修改），在相同的四百个文件验证集上对 GPT-5+ 进行了基准测试。总体准确率两者均为 98%。我按文档类别进一步细分了结果：具有清晰标题块的文本型 PDF、印刷质量退化的扫描图像，以及布局异常且历史上容易产生误报的图纸。在所有三类文档中，性能表现相当。GPT-5+ 并未找回 GPT-4.1 遗漏的文档，也没有引入新的失败模式。该提取任务本质上是在明确定义的文档区域内进行空间受限的模式匹配；其性能上限取决于系统是否查看了正确的位置并提出了正确的问题，而非模型本身的推理能力。

在 Azure 上进行模型迁移（新建部署、重新验证提示词、更新 API 版本、测试速率限制及完整验证套件）只有在新模型能为实际工作负载带来可衡量的提升时才值得。而我的情况并非如此。因此我继续使用 GPT-4.1，避免了一次不必要的迁移。

多站点架构

该系统从单一站点的命令行工具扩展为部署在四个工程站点的内部 Web 应用程序。

认证与治理

用户通过 Azure AD 安全组进行身份验证。Azure OpenAI 服务主体使用独立的应用注册，并具备作用域权限，与用户会话解耦。API 密钥存储在 Azure Key Vault 中，并在运行时通过托管身份获取。没有任何站点可以直接访问凭证。

/filters:no_upscale()/articles/local-first-ai-inference-cloud/en/resources/1Figure-3-Multi-site-deployment-architecture-1778145418454.jpg)

图 3. 多站点部署架构

图 3 展示了各站点节点运行本地 Tier 1 提取，通过 Azure AD、Key Vault 和托管身份连接到共享的 Azure OpenAI 部署。同时每个站点拥有本地文档存储，并生成共享的元数据输出。

计算、存储与作业编排

本地提取（Tier 1）在各站点的计算资源上运行。Azure OpenAI 端点为共享资源，速率限制配额在各站点间划分，防止某个站点的大批量请求影响其他站点。每次提取任务以批处理作业形式提交，Web 应用验证上传的文件，将其写入暂存区并排队执行。作业在每个站点内顺序运行，但各站点之间相互独立。上传的原始文档保留在本地存储中；只有结构化元数据（CSV 输出）被推送至下游资产管理系统所消费的共享网络位置。因此，原始文档永远不会离开其上传所在的站点。新增一个站点仅需部署 Web 应用、添加 Azure AD 组并分配速率限制配额，无需更改提取逻辑或 Azure OpenAI 部署。

此模式的局限性

当满足以下三个条件时，“本地优先 AI 推理”模式有效：目标字段具有可预测的空间位置、语料库中包含大量基于文本的文件、任务涉及单一明确的值提取。若这些条件不成立，则更适合采用其他架构。

缺乏空间规范

对于自由格式文档（如会议纪要、普通信函），Tier 1 无法找到锚点，所有文档都会落入 Tier 2。此时你实际上是在运行纯云端架构，却承担了额外开销。在这种情况下，应完全跳过本地层级，转而投入于结构化提示词设计，并结合模式验证输出。

扫描文档占主导的语料库

如果 80% 或以上的文档为扫描图像，本地提取几乎无法处理任何内容。此时经济性更倾向于纯云端架构，配合激进的批量处理、请求并行化以及针对重复文档模板的缓存层。

多字段依赖关系

提取相互依赖的字段（如发票明细项中的数量、单价和总价必须一致）时，置信度阈值更难校准。相比在本地提取中使用脆弱的跨字段规则，采用云端优先方法更为可靠：模型以 JSON 格式返回所有字段，再通过后处理步骤检查其内部一致性。

文档格式快速演变

当前的屏蔽列表和空间启发式规则是针对已知语料库调优的。如果文档格式频繁变化（如新增供应商、标题块布局更新），Tier 1 的成功率将下降，维护成本上升。对于高度异构的来源，采用云端优先流水线，结合少样本提示（few-shot prompting）和用于路由的格式检测分类器，比手动调优的空间规则更具适应性。

关于作者

#### Obinna Iheanachor

Obinna Iheanachor 是一位常驻英国利兹的高级 AI/数据工程师。他为工业环境构建文档智能与生产级 AI 系统，并部署于 Microsoft Azure 平台。他在 YouTube 的 Wisabi Analytics 频道 和 X 平台上的 Datasenseiobi 分享实用的 AI 工程实践内容。工作之余，他热爱徒步、拳击、萨尔萨舞和桌游。

显示更多 显示更少