過去兩年只要提到“信息抽取”絕大多數團隊的第一反應都是把文本丟給云端大模型 API等著拿回 JSON。這個流程確實好用但它默認了一個前提——你的數據允許上傳到第三方服務器。一旦數據涉及內部業務、客戶隱私、審計留痕或者干脆要部署在無外網的機房這條路就斷了。于是“本地模型能不能做抽取”成了越來越多團隊必須回答的問題。這篇文章想給一個明確的判斷本地模型做抽取任務已經不是“能不能用”的問題而是“怎么選、怎么調、怎么兜底”的問題。它在隱私、成本、可定制性上有不可替代的優勢但它的坑也很真實——Prompt 稍微寫含糊輸出就不穩定模型選小了準確率直接崩選大了顯存又扛不住。本文會從抽取任務的基礎認知、本地模型選型、部署環境、Prompt 設計與代碼實現、結果驗證和工程落地方案完整展開幫你把這條鏈路走通。如果你正在做文檔信息抽取、結構化數據構建、建筑與地理信息相關的屬性抽取或者只是好奇本地模型和云端 API 到底該怎么選這篇文章值得讀完。1. 這篇文章真正要解決的問題很多人對“本地模型做抽取”有一個誤解以為把云端 API 換成開源的模型權重改一下base_url剩下的事就水到渠成。真正動手后才發現問題不是“模型能不能跑”而是同一個 Prompt 在云端 API 上穩定輸出 JSON換成本地小模型就頻繁漏字段、套殼輸出、甚至直接說“我不會”模型量化版本選錯了回答質量下降明顯但顯存占用少得有限本地模型沒有云端 API 那么好用的函數調用和結構化輸出能力必須自己設計 JSON Schema、做后處理抽取結果沒有置信度錯誤數據直接進數據庫后續校驗成本反而更高。這篇文章要解決的就是這些具體問題。我從結論說起本地模型做抽取真正的價值不在于“模型本身多聰明”而在于它讓抽取這條流水線變得可落地、可審計、可離線、可長期用。它的核心壁壘不是算法而是工程——包括 Prompt 設計、輸出約束、結果校驗和失敗重試機制。什么類型的讀者最應該看做 RPA、文檔數字化、知識圖譜構建的開發者需要批量從非結構化文本里抽實體和關系在地理信息、遙感、建筑行業做數據處理的工程師需要從規劃文檔、勘察報告、GIS 元數據里抽取建筑屬性信息做內部數據平臺數據不允許出內網但希望用上大模型能力的團隊。如果你是這幾類人這篇文章會給你一條完整的落地路徑。2. 信息抽取任務與本地模型的基礎認知2.1 信息抽取到底在抽什么信息抽取Information ExtractionIE是把非結構化或半結構化文本轉換為結構化數據的任務。最常見的子任務包括子任務英文說明命名實體識別NER從文本中識別出人名、地名、機構名、時間、金額等實體關系抽取RE判斷兩個實體之間的關系例如“張偉是項目負責人”事件抽取EE抽取事件觸發詞、事件類型、參與者和時間地點屬性抽取Attribute Extraction抽取實體的屬性例如建筑的面積、層數、建造年份一項現實的抽取任務往往是這些子任務的組合。例如從一份建筑勘察報告里抽取“項目位置、建筑面積、建筑類型、當前狀態”本質上是先做實體識別再做屬性填充最后輸出成 JSON。傳統做法是訓練專門的 NER 模型加規則模板成本高且維護周期長。云端大模型改變了這個局面但引入了數據出域問題。本地模型則是對這兩條路線的一個折中既能靠自然語言 Prompt 快速適配新任務又能把數據留在自己的機器上。2.2 building footprint extraction 到底是什么任務這里要澄清一個常見混淆。網絡上經常會看到 building footprint extraction建筑足跡提取這個熱詞它指的是從遙感影像中提取建筑輪廓屬于計算機視覺里的語義分割或實例分割任務直接產出的是矢量多邊形或掩膜而不是文字。它和信息抽取是兩個方向但都屬于“從原始數據里提取結構化信息”的范疇。在 GeoAI 落地項目里常見的工作流是先用視覺模型從影像中提取建筑輪廓再用 NLP 模型從規劃文本、權屬材料里抽取建筑的屬性信息最終把幾何信息和屬性信息合并成完整的建筑數據庫。所以當你搜索 Local models extraction 相關技術方案時需要先確認自己要做的是圖像輪廓提取還是文本屬性抽取。本文后續內容主要聚焦文本信息抽取方向但在工程架構上這兩條鏈路都適合接入本地模型。2.3 本地模型與云端 API 的對比對比維度云端大模型 API本地開源模型數據安全數據需發送到第三方服務器數據不出本機或內網初始成本按 Token 付費長期累計成本高需要 GPU 硬件投入部署復雜度低幾行代碼接入較高需環境配置和模型管理可定制性依賴平臺功能可微調、可量化、可換模型穩定性平臺維護穩定性較好依賴自身運維能力離線可用不支持支持延遲受網絡和平臺負載影響本地推理延遲可控這個對比想說明一個點本地模型不是全面替代云端 API而是在“數據敏感、成本敏感、需要離線”的場景里成為更優解。很多團隊的做法是云端模型做冷啟動驗證本地模型做生產環境服務兩者通過統一的接口抽象切換。2.4 為什么抽取任務適合本地模型抽取任務有一個特點實體類型和輸出格式高度固定。某個項目里可能只需要抽取“地點、建筑面積、建筑類型、用途狀態”這幾個字段。這類任務對模型的“常識廣度”要求不高但對“指令跟隨能力”和“格式穩定性”要求很高。這正好落在開源本地模型的能力射程內。一個 7B 到 14B 參數量的開源模型經過合適的 Prompt 約束和 JSON Schema 引導完全可以在限定領域的抽取任務上達到可用水平。這也解釋了為什么當前本地模型最活躍的應用方向之一就是結構化抽取——它是“模型能力有限但任務邊界清晰”的最佳組合。3. 本地模型選型從哪個模型開始3.1 開源本地模型的常見選擇目前主流的開源本地模型系列主要有幾個方向我這里不做跑分排名只給選型思路Qwen 系列通義千問開源版中文抽取能力表現出色對中文長文本和結構化輸出支持較好是目前國內團隊最常用的本地模型之一。Llama 系列Meta 開源社區生態最豐富幾乎支持所有推理框架適合作為底座做微調但中文能力通常需要補充訓練。Mistral 系列歐洲團隊開源英文能力強上下文窗口和指令跟隨能力優秀但在中文場景下應用不如 Qwen 方便。如果你處理的是中文文本從 Qwen 系列開始是更穩妥的選擇如果業務面向英文且需要更強的推理能力Llama 和 Mistral 也值得測試。3.2 參數量怎么選這可能是選型中最重要的一個決策。參數量級建議顯存適用場景3B4B4GB8GB簡單實體抽取、格式固定、對準確率要求不極高7B8B8GB16GB大多數信息抽取任務平衡準確率和資源消耗14B16GB32GB復雜關系抽取、長文檔、需要更強指令跟隨32B 以上32GB 以上或需量化高難度抽取、多語言、需要接近云端 API 效果真實項目中我推薦先按“任務復雜度 顯存上限”確定參數量而不是先追求大模型。原因很直接抽取任務通常可以拆成多個小任務拆完之后7B 模型往往就夠用了。如果一開始就上 32B 模型部署成本高不說推理延遲也會制約批處理效率。3.3 量化版本要不要用量化Quantization是把模型參數從 16 位浮點數壓縮到 8 位或更低以減少顯存占用、提高推理速度但會帶來少量精度損失。對抽取任務我的建議是先用原版精度跑通基準測試確認準確率達標再嘗試 Q4 或 Q5 量化對比輸出質量。如果量化后的結果沒有明顯變差就可以用量化版本部署因為它的顯存占用和推理成本會低很多。這里有一個值得注意的坑量化版本在大部分簡單抽取任務上沒有差異但在長文本、復雜指令或多語言混合的場景下可能出現“字段輸出不完整”“格式偶爾跑偏”等問題。因此量化后的效果驗證絕對不能省。4. 本地部署環境準備4.1 推理框架選哪個當前部署本地模型常用的推理方案有三個按易用性排序Ollama安裝簡單模型管理方便自帶 OpenAI 兼容 API適合個人和中小團隊快速驗證。llama.cpp底層的 C/C 推理框架適合嵌入式環境和極致性能調優。vLLM吞吐高適合生產環境大規模并發推理但部署復雜度更高。本文以 Ollama 為主線因為它能最快跑通完整鏈路也最符合“從零到一”演示需求。生產環境需要高并發時可以遷移到 vLLM——代碼改動幅度很有限。4.2 安裝 OllamaOllama 支持 Windows、Linux 和 macOS。Linux 和 macOS 可以執行官方安裝腳本curl -fsSL https://ollama.com/install.sh | shWindows 用戶下載安裝包安裝即可。安裝完成后檢查版本ollama --version啟動服務ollama serve在 Linux 上Ollama 安裝后通常會注冊為 systemd 服務可以通過ollama serve手動啟動方便觀察日志。4.3 下載并運行模型以 Qwen 系列 7B 模型為例在終端執行ollama run qwen2.5:7b首次運行會先下載模型權重完成后進入交互式對話界面可以直接輸入文本測試。到這里本地模型已經跑起來了。這一步的關鍵是確認模型標簽在本機真實存在。可以用以下命令查看已下載的模型ollama list如果你不確定某個標簽是否存在可以在模型庫頁面確認名稱或直接使用ollama pull qwen2.5:7b拉取。5. 核心流程用本地模型做抽取任務5.1 先設計任務再寫 Prompt很多人做抽取任務一上來就寫 Prompt這是一個誤區。先要明確“輸出 Schema”也就是你希望模型輸出什么結構的數據。例如要從建筑勘察文本中抽取屬性最簡單的 Schema 是{ location: 項目地點, building_type: 建筑類型, area: 建筑面積, status: 當前狀態 }Schema 決定了 Prompt 里的“輸出要求”部分。Schema 設計得越清晰后續解析和校驗越簡單。5.2 本地抽取的 Prompt 設計原則針對本地模型Prompt 設計有四個原則第一身份與任務要具體。不要寫“你是一個助手”要寫“你是建筑信息抽取助手負責從文本中抽取指定字段”。第二輸出格式要顯式。直接給出 JSON 示例比單純說“輸出 JSON”有效得多。本地模型對示例的模仿能力很強寧可多花幾行 token也要在 Prompt 里放一個完整的輸出示例。第三指定缺失處理。告訴模型“如果某個字段沒有找到輸出空字符串或 null”避免模型自己編造內容。這一步是抽取任務里最容易出問題的地方。第四保持溫度低。抽取是確定性任務temperature 建議設置為 0抑制隨機性。5.3 Prompt 模板示例下面是一個適合本地模型的抽取 Prompt 模板你是建筑信息抽取助手。請從用戶提供的文本中抽取以下字段 - location項目地點 - building_type建筑類型 - area建筑面積保留數字 - status當前狀態如已建成、在建、規劃中 要求 1. 只輸出 JSON 對象不要輸出任何解釋文字。 2. 字段未找到時輸出 null不要編造。 3. 面積統一使用單位“平方米”。 示例輸出 {location: 上海市浦東新區, building_type: 研發大樓, area: 12000, status: 在建}這個模板的關鍵在于“只輸出 JSON”和“未找到時輸出 null”它們能顯著提高后續解析的成功率。5.4 輸出后處理與校驗即便 Prompt 寫得再好本地模型仍然可能輸出 Markdown 代碼塊、多余解釋、或者字段名跑偏。因此后處理是必須的不能跳過。后處理通常包括三步去掉 Markdown 代碼塊標記用json.loads解析失敗時進入重試用 JSON Schema 校驗字段是否齊全缺失的字段標記為 null。這套后處理邏輯雖然簡單但它決定了整個抽取流水線的穩定性。生產環境下建議把“解析失敗”和“字段缺失”統計成指標用于衡量模型的實際效果。6. 完整示例代碼實現6.1 安裝依賴需要安裝 Ollama 的 Python 庫以及用于測試的 OpenAI SDK。pip install ollama openai如果后續要切換到 vLLM 或其他 OpenAI 兼容服務openai這個依賴會非常有用。6.2 示例一使用 Ollama Python 庫做實體抽取新建文件extract_entities.py代碼如下# 文件路徑extract_entities.py import ollama response ollama.chat( modelqwen2.5:7b, messages[ { role: system, content: ( 你是信息抽取助手。請從用戶輸入文本中抽取實體 并輸出 JSON 對象字段包括person、organization、 location、date。沒有找到的字段輸出空列表。 ), }, { role: user, content: ( 2024年6月綠城建筑公司在杭州完成了智慧園區項目的驗收 項目負責人是張偉驗收日期是6月28日。 ), }, ], formatjson, ) print(response[message][content])運行驗證python extract_entities.py預期輸出是一個 JSON 對象例如{ person: [張偉], organization: [綠城建筑公司], location: [杭州], date: [2024年6月, 6月28日] }這里formatjson參數會讓 Ollama 盡量以 JSON 格式輸出能大幅度降低解析難度。6.3 示例二使用 OpenAI 兼容接口抽取建筑屬性Ollama 啟動后默認在11434端口提供 OpenAI 兼容 API可以用標準 OpenAI SDK 調用方便以后切換后端。新建文件extract_building.py# 文件路徑extract_building.py from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama, # 本地服務不校驗真實 key但字段不能為空 ) resp client.chat.completions.create( modelqwen2.5:7b, temperature0, response_format{type: json_object}, messages[ { role: system, content: ( 你是建筑信息抽取助手。請從文本中抽取字段location、 building_type、area、status。只輸出 JSON不要輸出解釋。 ), }, { role: user, content: ( 上海市浦東新區張江科技園的研發大樓建筑面積約12000平方米 目前正在建設中。 ), }, ], ) print(resp.choices[0].message.content)運行驗證python extract_building.py預期輸出{ location: 上海市浦東新區張江科技園, building_type: 研發大樓, area: 12000, status: 在建 }這個示例的關鍵點是base_url只要指向http://localhost:11434/v1本地模型和云端 API 的切換就只剩配置差異業務代碼基本不用改。6.4 示例三批量抽取與 JSON 解析后處理真實項目中抽取往往面向批量文本。我們把后處理邏輯封裝成一個函數并在循環中批量執行。新建文件batch_extract.py# 文件路徑batch_extract.py import json import ollama def parse_json_response(content: str) - dict: 清理模型輸出并解析 JSON解析失敗時拋出異常。 content content.strip() # 去掉常見的 markdown 代碼塊標記 if content.startswith(): lines content.splitlines() if lines and lines[0].startswith(): lines lines[1:] if lines and lines[-1].strip() : lines lines[:-1] content \n.join(lines) return json.loads(content) def extract_fields(text: str, model: str qwen2.5:7b) - dict: 抽取文本中的建筑字段。 resp ollama.chat( modelmodel, messages[ { role: system, content: ( 抽取以下字段location、building_type、area、status。 只輸出 JSON沒有的信息輸出 null不要編造。 ), }, {role: user, content: text}, ], formatjson, ) return parse_json_response(resp[message][content]) texts [ 北京朝陽區望京 SOHO 塔一寫字樓2014年投入使用。, 成都高新區天府軟件園辦公園區園區面積約100萬平方米。, 武漢東湖新技術開發區的地下綜合管廊項目仍在規劃中。, ] for text in texts: try: result extract_fields(text) print(json.dumps(result, ensure_asciiFalse)) except json.JSONDecodeError as e: print(解析失敗原始輸出, e)運行驗證python batch_extract.py如果某條數據解析失敗程序不會整體中斷而是打印錯誤信息方便后續定位 Prompt 或模型問題。7. 運行結果與效果驗證7.1 驗證步驟本地模型做抽取驗證不能只看一兩條結果要做三件事第一準備一個測試集。至少 20 到 50 條真實業務文本覆蓋正常情況、缺失字段情況、長文本情況。第二統計指標。抽取任務的常用指標是字段級準確率和字段級召回率。字段級準確率衡量“抽出來的字段是否正確”字段級召回率衡量“應該抽到的字段是否被漏掉”。第三檢查失敗案例。對每一條解析失敗或字段錯誤的數據記錄原因是 Prompt 不清晰還是模型能力不足還是后處理有 bug。7.2 簡單評估腳本這里給一個最小評估思路# 文件路徑evaluate.py import json from batch_extract import extract_fields test_cases [ { text: 上海市浦東新區張江科技園研發大樓12000平方米在建。, expected: { location: 上海市浦東新區張江科技園, building_type: 研發大樓, area: 12000, status: 在建, }, }, ] total len(test_cases) correct 0 for case in test_cases: result extract_fields(case[text]) if result case[expected]: correct 1 else: print(期望, case[expected]) print(實際, result) print(f準確率{correct}/{total})這個腳本只做說明實際項目里還需要處理字段級部分匹配和未知字段等問題但思路是一致的。7.3 失敗時先看哪里如果結果不理想按以下順序排查先看原始輸出。用ollama run或腳本直接打印模型輸出確認是“格式不對”還是“內容不對”。格式不對優先修 Prompt 和后處理內容不對優先換模型和調 Prompt。確認是否使用了低溫度。抽取場景 temperature 必須低否則同樣的輸入可能輸出不同結果。8. 常見問題與排查思路本地模型做抽取的坑不少這里把高頻問題整理成表格。問題現象可能原因排查方式解決方案模型輸出不是 JSON而是解釋文字Prompt 約束不夠強查看原始輸出內容在 Prompt 中強調“只輸出 JSON”并加示例開啟 formatjson字段總是丟特別是面積、日期模型參數量小長文本注意力不足檢查缺失字段是否在輸入中出現拆分長文本降低單次抽取字段數或換更大模型同一個樣本多次運行結果不同temperature 設置過高檢查推理參數將 temperature 設置為 0啟動時顯存不足模型量化等級低或并發過高觀察啟動日志和顯存占用換更小參數量模型或啟用 Q4/Q5 量化首次運行很慢卡在下載模型權重未下載完成查看ollama list和網絡狀態確認已執行ollama pull磁盤空間充足批量處理時單條失敗導致整體中斷后處理沒有做異常捕獲查看錯誤堆棧對每條數據捕獲json.JSONDecodeError失敗時記錄日志并繼續本地模型準確率低于云端 API模型能力或 Prompt 設計問題做小規模對比測試先優化 Prompt 和輸出約束仍不達標再換更大模型換模型后行為差異大不同模型對 Prompt 的敏感度不同對比兩個模型的原始輸出針對模型調整 Prompt不要期望一套 Prompt 通吃這組問題里最高頻的還是“輸出不穩定”和“字段缺失”。它們通常不是獨立問題而是 Prompt、模型參數量、任務拆分三者共同作用的結果。建議一次只改一個變量不要同時換模型、改 Prompt、改后處理否則很難定位瓶頸。9. 最佳實踐與工程建議9.1 把抽取任務拆小不要追求一次搞定本地模型的能力上限決定了一個 Prompt 里塞太多字段抽取質量會明顯下降。更穩妥的做法是先抽實體再做關系或屬性匹配最后拼接成結構化結果。看似多跑了幾次模型但每次任務邊界清晰準確率反而更高。9.2 輸出 Schema 先行Prompt 與后處理共用一份定義把字段定義、JSON Schema、Prompt 模板放在一個配置文件里維護避免 Prompt 和后處理各寫一份。這樣字段變更時只改一處不會出現 Prompt 里寫了area后處理卻在找building_area的尷尬。# 文件路徑schema.py EXTRACTION_SCHEMA { location: 項目地點, building_type: 建筑類型, area: 建筑面積, status: 當前狀態, }9.3 建立失敗樣本回收機制生產環境中建議把解析失敗、字段缺失、置信度不高的樣本統一存儲定期人工復核再把這些樣本加入測試集或微調數據。這是本地模型抽取效果持續提升的最可靠路徑。很多團隊用久了效果變差就是因為沒有做失敗樣本回收模型和 Prompt 都停在原地。9.4 用緩存提升批量抽取效率同一段文本被重復抽取的情況很常見。可以按文本內容哈希做結果緩存重復任務直接讀取歷史結果減少 GPU 占用和耗時。對于大體量歷史數據處理這一步能省下大量推理成本。9.5 安全與合規提醒如果處理的數據涉及個人或敏感業務信息請確保部署環境、模型下載渠道和輸出存儲都符合公司內部的安全規范。本地模型雖然解決了“數據不出域”的問題但模型權重本身、Prompt 內容、抽取結果日志都屬于需要管理的數據資產建議做好訪問控制和審計。9.6 從 Ollama 遷移到 vLLM 的時機當單機并發要求提高比如需要同時處理幾十個在線抽取請求時Ollama 的并發能力會逐漸成為瓶頸。此時可以遷移到 vLLM。因為代碼層使用的是 OpenAI 兼容接口遷移時只需要把base_url指向 vLLM 服務地址業務代碼基本不用動。這個架構設計建議在項目一開始就預留。10. 總結與后續學習方向本文圍繞“本地模型做 extraction”這條主線講清楚了幾個關鍵點本地模型適合固定邊界的信息抽取任務選型上按任務復雜度和顯存上限決定參數量Prompt 設計和 JSON 后處理是決定效果的核心工程環節模型能力不夠時靠拆分任務和失敗樣本回收比盲目換大模型更有效。下一步建議你按這個順序實踐先找一個真實業務字段設計 Schema用本地 7B 模型跑通 20 條測試樣本統計準確率針對失敗樣本迭代 Prompt穩定后接入批量處理腳本并發需求出現時再遷移到 vLLM。如果你想繼續深入有三個方向值得關注一是結構化輸出約束許多推理框架已經支持 JSON Schema 級別的強約束輸出這是提升穩定性的關鍵二是針對領域數據的輕量微調用幾百條標注樣本微調底座模型往往比反復調 Prompt 更可靠三是多模態本地模型在 building footprint extraction 這類視覺任務上的應用那是另一條同樣值得投入的技術路線。信息抽取這個領域最終拼的不是單次召回率有多高而是整條流水線在真實數據和長期運維中能有多穩。本地模型把主動權交還給了工程師剩下的就看工程做得夠不夠細了。