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