LLM 文字摘要流程的設計與取捨：OpenAI API、Ollama 與 Local Model

Mon, 26 Oct 2026 00:00:00 +0800

自 2022 年起，我開始把 LLM 放進實際產品流程，其中一塊是內部的文字摘要與 AI application 平台：整合 OpenAI API、Ollama、local model 與 batch processing，重點放在可控、可維運的 model usage。

這類內部系統的細節不適合公開，所以這篇不是完整的 case study，而是整理我設計與維運摘要流程時採用的原則與取捨。文中提到的 API 行為都以官方文件為準，寫作時（2026-10）已對照過；實際使用前仍請以最新文件為準。

為什麼摘要不只是呼叫 API

做出一個摘要 demo 很快：把文字丟進 prompt，請模型「幫我摘要」，幾分鐘就能看到結果。真正的工作在 demo 之後：

輸入長度不固定，有些文字會超過模型的 context length。
同一批資料要處理很多筆，會碰到 rate limit、timeout 與部分失敗。
下游系統需要固定格式，但模型輸出不一定每次都長得一樣。
成本、延遲與資料敏感度，會影響每一筆該送到哪個模型。
換模型或改 prompt 之後，需要知道品質是變好還是變差。

所以我會把摘要當成一條資料處理 pipeline 來設計，而不是一個 API call。

流程拆解

我習慣把流程拆成幾個可以各自觀察、各自重跑的階段：

前處理：清掉格式雜訊、重複內容與不需要送進模型的欄位，並在這一步處理不該離開環境的資料。送進模型的內容越乾淨，token 用量與輸出品質都越好控制。
切段：先估算 token 數，超過模型可處理的長度就依段落或語意邊界切段，必要時保留少量重疊，避免重點剛好被切斷。
模型呼叫：短文字直接摘要；長文字用 map-reduce 的方式，先對每一段產生摘要，再把段落摘要合併成最終摘要。這樣每次呼叫的輸入都在可控範圍內，失敗時也只需要重跑單一段落。
驗證：檢查輸出格式、必要欄位、長度與明顯的錯誤，不通過就標記為失敗或進入重試。
輸出：把結果連同使用的模型、prompt 版本與處理狀態一起保存，之後才能追查與比較。

使用 local model 時，context length 要特別留意。Ollama 的預設 context length 會依 VRAM 大小決定，可以用 OLLAMA_CONTEXT_LENGTH 調整，並透過 ollama ps 的 CONTEXT 欄位確認實際配置（Context length 官方文件）。如果沒有確認這個設定，長文字可能沒有被模型完整看到。Ollama 的安裝、指令與環境變數，我整理在 Ollama 指令與設定速查。

OpenAI on Clarence｜Backend、AI、DevOps 與 Infrastructure

LLM 文字摘要流程的設計與取捨：OpenAI API、Ollama 與 Local Model

為什麼摘要不只是呼叫 API

流程拆解