從單點 API 到分層管線：文件處理的混合式架構新典範

我認為，單純呼叫雲端大型語言模型（LLM）處理所有任務的時代正在結束。一個更成熟、更有效率的典範正在浮現：混合式文件處理管線（Hybrid Document Pipeline）。它的核心精神是「分工」，讓終端裝置（Edge）與雲端（Cloud）各司其職。與其將原始的、非結構化的文件（如圖片、PDF）直接拋上雲端，不如先在本地進行 OCR、清洗與語義抽取，將其「壓縮」成結構化的精簡資訊，再傳送給雲端 LLM 進行深度分析。這個架構的轉變，不僅是技術上的優化，更是對成本、隱私與分析品質三者權衡下的必然結果。

為什麼純雲端架構不再是唯一解？

過去幾年，AI 文件處理的主流模式相當直接：使用者上傳文件（例如對話截圖、掃描合約），應用程式便將整個檔案傳送到雲端，由一個或多個雲端服務（如 Google Cloud Vision）進行光學字元辨識（OCR），再將辨識出的文字交給 GPT-4 或 Claude 3 等大型模型進行摘要、分析。儘管這種模式簡單直觀，但在實務應用中卻面臨三大挑戰：

• 高昂的傳輸與運算成本：一張手機螢幕截圖可能超過 1MB，而其包含的文字資訊通常不到 2KB。將整張圖片上傳不僅耗費大量頻寬，雲端 OCR 本身也是一筆開銷。若一天有數萬名使用者，這些看似微小的成本將迅速累積成巨額帳單。
• 無法迴避的隱私風險：原始檔案往往包含大量個人可識別資訊（PII）。例如，對話截圖中除了文字，還包含使用者頭像、姓名、時間戳記等。將這些未經處理的原始資料傳送到第三方伺服器，無疑增加了資料外洩與濫用的風險，也讓使用者對產品的信任度大打折扣。
• 分析品質的不穩定：通用型的雲端 OCR 服務未必能完美解析特定格式的內容。例如，它可能難以區分對話中的發話者，或誤判表格的欄位對應。這種「垃圾進，垃圾出」（Garbage In, Garbage Out）的現象，會直接導致後續 LLM 的分析結果出現偏差，因為模型從一開始就收到了錯誤或混亂的輸入。

Relora App 如何巧妙結合本地 OCR 與雲端 LLM？

最近，日本一位獨立開發者打造的 iOS App Relora，為混合式架構提供了一個極佳的實證案例。這個 App 的功能是分析使用者上傳的戀愛對話截圖，並提供心理分析與回覆建議。Relora 的處理流程巧妙地結合了本地與雲端的能力：

1. 本地處理（On-Device）：當使用者上傳一張對話截圖，App 會直接在 iPhone 上，利用蘋果內建的 Vision Framework 進行 OCR。它不僅辨識文字，更重要的是，它會利用文字的座標、顏色等視覺資訊，判斷出哪段話是誰說的，並將對話整理成一個結構化的 JSON 物件，其中包含發話者與訊息內容的序列。
2. 雲端分析（Cloud）：接著，App 只將這個輕量（可能僅 2-3 KB）、乾淨、匿名的 JSON 資料傳送到後端的 AWS Serverless 服務。後端再將此結構化資料提交給雲端 LLM（例如 OpenAI 的 API），請求進行心理分析。

這個設計的優勢顯而易見。首先，超過 99% 的資料量（原始圖片）從未離開過使用者手機，大幅降低了伺服器頻寬成本與隱私風險。其次，本地 OCR 可以針對特定 App（如 LINE 或 Messenger）的對話介面進行特化，確保結構化結果的準確性，為後續 LLM 的高品質分析奠定穩固基礎。這正是分層設計的威力所在。

核心的設計思維，正從「如何把資料餵給 AI」，轉變為「應該將資料壓縮成何種兼具資訊密度與隱私保護的格式，再交給 AI」。

如何設計一個有效的混合式文件管線？

從 Relora 的案例中，我們可以歸納出設計混合式文件管線的幾個關鍵步驟。這不僅適用於對話分析，也適用於合約審閱、履歷篩選、票據辨識等各種文件密集型應用。

第一步是「本地語義抽取」（Local Semantic Extraction）。目標是在終端裝置上，從原始文件中提取出最有價值的結構化資訊。這不只是執行 OCR，更是理解文件的「版面與語義」（Layout and Semantics）。例如，對於一份履歷，本地模型需要辨識出姓名、聯絡方式、學經歷等區塊；對於一張發票，則需抓取品項、單價與總金額。近年來如 LayoutLM 等模型的發展，也讓裝置端執行這類任務變得更加可行。

第二步是「最小化資料傳輸」（Minimal Data Transmission）。本地處理完成後，只將必要的、結構化的、且已做過去識別化處理的資料傳送至雲端。這一步是成本與隱私的關鍵控制點。開發者必須明確定義雲端 LLM 執行任務所需的最小資訊集，任何多餘的資訊都應被過濾掉。

第三步是「雲端專注於高階認知」（Cloud for Higher-Order Cognition）。當雲端 LLM 收到乾淨、結構化的輸入後，它才能真正發揮其強大的推理、歸納與生成能力。此時，我們可以設計更精準的提示（Prompt），讓模型專注於執行無法在本地完成的複雜任務，例如法律風險評估、候選人能力分析或個人化建議生成。這種分工模式，確保了運算資源被用在刀口上。

總結來說，將所有雞蛋都放在雲端 LLM 這個籃子裡，是一種既昂貴又不安全的策略。一個設計精良的混合式架構，透過在邊緣端預先進行智慧過濾與語義壓縮，不僅能打造出更快速、更經濟、更值得信賴的產品，也代表了我們對於 AI 應用工程的理解，正從單純的模型呼叫，走向更為成熟的系統化設計。

延伸閱讀

• スクショ→AI分析アプリの全体設計 ― iOS MVVM + AWSサーバーレスで恋愛分析AIアプリを作る
• Apple Developer Documentation: Recognizing Text in Images
• Edge Intelligence: Paving the Last Mile for Artificial Intelligence

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。