本地優先 AI 推理：高性價比文檔處理云架構模式

作者 | Obinna Iheanachor

譯者 | 明知山

一種三層混合架構可將 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 層）。

第 1 層：本地確定性提取

每份文檔都經過 PyMuPDF 本地提取環節進入處理流水線。第一層能以零 API 成本、單文檔約 3 秒的耗時處理 70% 至 80% 的文檔。這個層級采用高精準度、低召回率的設計原則：當無法確定結果時，會直接返回空值而不是猜測。它幾乎不會產生誤報，但會漏掉版式特殊的文檔，而這類文檔恰好可以交由第二層處理。

第 2 層：云 AI 推理

未能通過第一層處理的文檔會被渲染成圖像并發送給 Azure OpenAI 的 GPT-4 Vision 端點。這一層以每次調用約 1 美分、每份文檔約 10 秒的耗時處理 20% 至 30% 的文檔。它的失敗模式與第一層恰好相反：有可能給出看似篤定實則錯誤的結果。

第 3 層：人工審核

第一層與第二層產出結果存在沖突的文檔或是第二層返回低置信度輸出的文檔都會被標記為人工審核，這類文檔約占總量的 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 治理

我使用 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/

聲明：本文為 AI 前線編譯，不代表平臺觀點，未經許可禁止轉載。

會議推薦

Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發體系不重構，還能撐多久？

AICon 上海站 2026，13 大重磅專題已上線，誠摯邀請你登臺分享實戰經驗。AICon 2026，期待與你同行。快來掃碼鎖定 8 折專屬席位或提交演講議題

今日薦文

你也「在看」嗎？