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