前陣子接了一個POI數(shù)據(jù)處理的項目核心目標是把散落在一堆報表和接口里的POI興趣點數(shù)據(jù)清洗、補全、統(tǒng)一成一套能直接喂給下游業(yè)務(wù)的干凈數(shù)據(jù)。做了之后發(fā)現(xiàn)傳統(tǒng)規(guī)則清洗在復(fù)雜真實數(shù)據(jù)面前根本不夠看后來把方案改成了“POI-Enhancer LLM4POI集成分析”的組合才真正把數(shù)據(jù)質(zhì)量和整體效率提了上來。這篇文章就把這套方案的核心思路、關(guān)鍵實現(xiàn)和踩過的坑完整記錄一下適合正在做POI數(shù)據(jù)治理、基礎(chǔ)數(shù)據(jù)標準化、或者想用大模型做地址/興趣點增強的朋友參考。1. 項目整體設(shè)計與思路拆解1.1 POI數(shù)據(jù)到底難在哪里POI數(shù)據(jù)表面看就是“名稱地址經(jīng)緯度類別”但真實場景下遠沒有這么簡單。我拿到的原始數(shù)據(jù)來源極雜有老系統(tǒng)的導(dǎo)出表有運營手工填的Excel有地圖SDK回傳的日志還有爬蟲抓的商戶信息。這些數(shù)據(jù)混在一起之后幾個老問題就特別扎眼名稱不規(guī)范同一家店可以叫“老王牛肉面”、“老王牛肉面館”、“老王牛肉面(人民路店)”甚至還有人寫成“老王牛內(nèi)面”這種錯別字版本。地址殘缺有的只有“人民路88號”有的寫“某某大廈B座3樓”有的甚至連市轄區(qū)都沒有只有一句“在火車站附近”。類別混亂不同來源對“餐飲”的分類粒度完全不同有的只有一級大類有的能細分到“川菜-火鍋-重慶火鍋”。坐標漂移一部分數(shù)據(jù)沒有經(jīng)緯度一部分經(jīng)緯度明顯偏移還有一部分是平面坐標沒有做投影轉(zhuǎn)換。屬性缺失營業(yè)時間、聯(lián)系電話、人均消費、評分這些業(yè)務(wù)屬性大量缺失。如果用傳統(tǒng)ETL里的正則匹配、字典映射、規(guī)則判斷去做清洗每一條規(guī)則都要針對具體臟數(shù)據(jù)編寫寫一版跑上去過兩天又來一種新臟格式規(guī)則庫無限膨脹維護成本直線上升。這是我最初用規(guī)則清洗吃到的最大教訓(xùn)。1.2 LLM4POI能解決什么、不能解決什么LLM4POI這個方向本質(zhì)是把大語言模型當(dāng)成一個“懂地理常識的知識處理器”引入到POI處理鏈路中。大模型在名稱糾錯、地址理解、語義分類、屬性抽取這些環(huán)節(jié)上有天然優(yōu)勢因為它不是靠固定規(guī)則去匹配而是靠語義理解去推斷。比如把“老王牛內(nèi)面 人民路88號 張記隔壁”交給LLM它能推斷出這是“餐飲-面館”能糾正“牛內(nèi)面”為“牛肉面”能嘗試解析出地址主體是“人民路88號”還能順帶把“張記隔壁”識別為位置參照信息而不是正式地址。但LLM4POI不是萬能的。它的坐標計算能力幾乎為零不能指望它輸出準確的經(jīng)緯度它的幻覺問題在地址補全場景里很危險尤其當(dāng)原始信息太模糊時它會一本正經(jīng)地編一個不存在的地址它的成本也不是零十萬條POI全部走大模型接口是一筆不小的開銷。所以方案定位是LLM負責(zé)“理解”和“推斷”規(guī)則和外部數(shù)據(jù)負責(zé)“校驗”和“修正”也就是標題里那句“集成分析”的意思。1.3 POI-Enhancer的定位與模塊劃分POI-Enhancer在我的設(shè)計里不是一個單點腳本而是一個可編排的處理框架。它的核心職責(zé)是把臟POI作為輸入輸出一條結(jié)構(gòu)化、標準化的增強POI記錄。整體分四層輸入適配層兼容多種來源數(shù)據(jù)自動識別字段映射做初步去重。LLM推理層對每條POI進行名稱標準化、地址解析、類別映射、屬性抽取。外部校驗層接入行政區(qū)劃庫、坐標反查、業(yè)務(wù)知識庫對LLM結(jié)果做約束和修正。輸出標準化層統(tǒng)一數(shù)據(jù)模型輸出JSON格式的增強結(jié)果附帶質(zhì)量評分和置信度。這樣設(shè)計的好處是每一層可以獨立替換。比如LLM推理層今天用的是通用模型明天某個場景需要換成領(lǐng)域微調(diào)模型只要輸出格式不變其它層完全不用動。外部校驗層也一樣接入新的行政區(qū)劃庫就像換一張表那么簡單。2. 技術(shù)選型與核心原理2.1 為什么采用“規(guī)則LLM知識庫”三層架構(gòu)第一版我試過純LLM端到端直接把原始POI文本塞給模型讓它輸出一個完整的JSON。效果在單個樣本上看非常驚艷但批量跑下來問題就露出來了。一是相同輸入不同輸出帶有溫度參數(shù)時同一家店兩次跑出來的類別可能不一樣二是無法約束邊界模型偶爾會輸出根本沒有依據(jù)的營業(yè)時間三是成本浪費很多已經(jīng)規(guī)則能處理的簡單結(jié)構(gòu)化數(shù)據(jù)沒必要每次都走LLM。后來調(diào)整為三層架構(gòu)后問題基本都解決了第一層用規(guī)則處理所有“確定性”的工作去重、字段映射、非法字符清理、基礎(chǔ)格式校驗。第二層用LLM處理“需要理解”的工作語義糾錯、地址結(jié)構(gòu)識別、類別推斷、屬性補全。第三層用知識庫做“最終裁決”行政區(qū)域合法性檢查、坐標反查驗證、業(yè)務(wù)屬性字典匹配。這樣做最大的收益是確定性。規(guī)則能兜底的絕不讓模型自由發(fā)揮模型只做規(guī)則做不了的事情模型輸出的東西又被知識庫約束著防止它編造出離譜的結(jié)果。2.2 直接調(diào)用通用大模型還是微調(diào)專用模型這個糾結(jié)了很久也對比過兩版效果。通用大模型優(yōu)勢明顯開箱即用、推理靈活、對中文地址的理解能力強但劣勢是單條成本偏高、大批量調(diào)用時延遲不穩(wěn)定、偶爾輸出格式不符合預(yù)期。微調(diào)專用模型呢成本和延遲可控、輸出格式能約束得很穩(wěn)定但需要準備高質(zhì)量訓(xùn)練語料且POI這類數(shù)據(jù)更新迭代快模型一舊又得重新訓(xùn)。我最終的結(jié)論是分場景標準化清洗類任務(wù)名稱糾錯、地址解析、類別映射走通用大模型即可因為不需要業(yè)務(wù)私有知識通用大模型的知識覆蓋已經(jīng)足夠。業(yè)務(wù)持久屬性類任務(wù)比如從POI名稱推斷是否連鎖、是否品牌直營建議用小模型微調(diào)或規(guī)則映射這類任務(wù)一旦理解錯代價很高。高質(zhì)量標注語料充足且有持續(xù)迭代需求時才考慮微調(diào)專用模型。我的項目里L(fēng)LM4POI集成的基座選了調(diào)用通用大模型接口但在鏈路里加了一層輸出Schema約束和知識庫驗證讓模型自由發(fā)揮的空間被限制在可控范圍內(nèi)。2.3 統(tǒng)一數(shù)據(jù)模型與輸出Schema設(shè)計LLM輸出混亂是集成時最容易翻車的點解決辦法是在Prompt里給出強約束的JSON Schema并且解析失敗時自動重試。我的輸出Schema大致長這樣{ poi_id: 原始編號或內(nèi)部生成ID, name_standard: 標準化后名稱, name_original: 原始名稱, name_confidence: 0.95, address: { province: 省, city: 市, district: 區(qū)縣, street: 道路信息, house_number: 門牌號, landmark: 地標/參照物, full_text: 完整標準化地址, confidence: 0.9 }, category: { l1: 一級大類, l2: 二級類別, l3: 三級細分類別, confidence: 0.88 }, attributes: { open_time: , phone: , per_capita: null }, coordinate: { lat: null, lng: null, source: none }, quality_score: 0.85, flags: [address_incomplete, phone_missing] }這個Schema設(shè)計時有幾個細節(jié)要說明confidence不是給業(yè)務(wù)看的而是給自己的質(zhì)量評估系統(tǒng)看的低于某個閾值的記錄進入人工審核隊列。source字段標記坐標來源區(qū)分是原始數(shù)據(jù)帶的、還是反查得到的、還是沒有。flags是異常標記列表方便下游直接過濾處理而不需要重新解析整條JSON。最關(guān)鍵的一點我不知道你會不會踩這個坑Schema必須要求模型只輸出JSON不要輸出任何解釋性文本否則解析時一半的時間都花在清洗Markdown代碼塊上了。3. 核心實現(xiàn)與實操環(huán)節(jié)3.1 原始數(shù)據(jù)預(yù)處理輸入干凈才能輸出干凈很多人一上來就把原始數(shù)據(jù)直接丟給LLM這其實是浪費。我發(fā)現(xiàn)先做一輪“物理清洗”再進LLM效果提升非常明顯。具體做了這幾件事字段映射與類型強制原始表里“地址”列可能有空值有“不詳”有“待定”這些字符串統(tǒng)一轉(zhuǎn)成空值避免LLM被干擾。名稱與地址截斷異常超長文本比如有人把備注都填進名稱里了截斷或拆分因為超長輸入既增加Token成本又稀釋注意力。基礎(chǔ)維度拆分如果原始數(shù)據(jù)有經(jīng)緯度列提前校驗經(jīng)緯度范圍。非法經(jīng)緯度不能直接刪要標記后讓后續(xù)流程決定是否反查。簡單規(guī)則預(yù)清洗全角半角轉(zhuǎn)換、亂碼清理、重復(fù)標點壓縮、emoji過濾對地址字段里真有帶emoji的商戶。預(yù)處理階段我用一個基于Pandas的流水線腳本處理十萬條數(shù)據(jù)跑完大約不到一分鐘性價比極高為后續(xù)LLM調(diào)用省下了大量Token。3.2 LLM結(jié)構(gòu)化輸出實現(xiàn)Prompt構(gòu)建與后處理Prompt構(gòu)建是這個項目里最值得琢磨的部分。我實際試過幾版Prompt發(fā)現(xiàn)單靠一句“請幫我清洗POI數(shù)據(jù)”是不夠的輸出質(zhì)量會很不穩(wěn)定。最終使用的Prompt框架包含四個部分角色設(shè)定明確模型是“POI數(shù)據(jù)增強專家”要求輸出符合行業(yè)標準的結(jié)果。輸出約束只能是JSON且嚴格按照給定Schema不允許添加任何額外字段。具體分析指令名稱糾錯要結(jié)合語義和地域習(xí)慣地址解析要區(qū)分出正式地址和參照描述類別映射要到三級屬性補全寧可留空也不能編造。少量示例給兩三個典型輸入輸出對幫助模型對齊格式。舉個例子Prompt里我固定的指令是你是一個POI數(shù)據(jù)增強專家。請根據(jù)輸入的興趣點信息完成以下任務(wù) 1. 標準化名稱糾正錯別字統(tǒng)一簡稱與全稱去除無意義的品牌后綴詞。 2. 解析地址區(qū)分省/市/區(qū)/街道/門牌號/地標對于不能確認的字段留空不要推斷。 3. 推斷類別輸出三級的品類層次。 4. 補全屬性營業(yè)時間、電話等信息僅從原文中抽取原文沒有就留空。 5. 對結(jié)果給出置信度評分和異常標記列表。 只輸出JSON對象不要輸出任何解釋或Markdown標記。后處理部分我寫了解析函數(shù)優(yōu)先嘗試json.loads直接解析失敗則提取最早出現(xiàn)的{到最后一個}之間的子串再解析還失敗就把模型原始輸出寫入異常隊列不會硬撐。這個隊列在聯(lián)調(diào)階段每天能抓到幾十條模型抽風(fēng)的記錄對排查Prompt缺陷非常有幫助。3.3 外部知識庫校驗給LLM結(jié)果“上把鎖”只靠LLM輸出就落庫還是不放心尤其地址這塊。我接了三類外部知識數(shù)據(jù)做校驗行政區(qū)劃庫省市區(qū)三級標準名稱和編碼表。LLM輸出的地址解析結(jié)果如果區(qū)縣名稱不在庫里直接置為null并打上district_mismatch標記。坐標反查服務(wù)如果原始數(shù)據(jù)帶坐標但地址解析后區(qū)縣與坐標反查的區(qū)縣不一致觸發(fā)警告。寧可保留原始坐標并標記異常也不要盲信LLM的輸出坐標。業(yè)務(wù)知識字典特定類別要求特定屬性比如餐飲必須有經(jīng)營品類酒店必須有星級檔位。如果類別推斷出來但關(guān)鍵屬性缺失則標記為質(zhì)量不合格。知識庫校驗有個妙用用規(guī)則修正LLM的小錯誤而不是全盤推翻。比如模型把“武昌區(qū)”和“洪山區(qū)”搞混了如果坐標反查在洪山區(qū)就把區(qū)縣字段改成洪山區(qū)同時把置信度下調(diào)。這比讓LLM重新生成一遍既省成本又穩(wěn)定。3.4 特征對齊與記錄合并解決“同一實體多條記錄”的難題數(shù)據(jù)源合并后同一家店存在多條記錄是常態(tài)。傳統(tǒng)做法是按名稱地址精確匹配但錯別字問題會讓匹配失效。我設(shè)計了一個分層匹配策略第一層標準化名稱完全一致且區(qū)縣一致直接合并。第二層標準化名稱相似度超過85%且地址要素中街道門牌號一致合并并觸發(fā)沖突檢測。第三層無名稱匹配但坐標距離小于50米且類別一致合并但降低合并置信度。相似度用的是字符編輯距離加一個簡單的語義判斷因為中文地址詞序變化會影響編輯距離所以我在比較前先把地址字符串按“省市區(qū)街牌號參照”拆成要素再逐要素比較實測效果比全文相似度穩(wěn)定得多。合并時還處理了一個細節(jié)屬性沖突。比如一條記錄營業(yè)時間是“10:00-22:00”另一條是“09:30-23:00”不能隨便覆蓋。我的策略是按數(shù)據(jù)源可靠度排序高可靠度覆蓋低可靠度可靠度相同時取更寬泛的時間范圍。3.5 質(zhì)量評估與人工審核閉環(huán)每條輸出都帶quality_score這個分數(shù)綜合了置信度、字段完整度、異常標記數(shù)量。算法很簡單quality_score 0 起步 名稱標準化且有高置信度0.2 地址完整到街道/門牌0.3 類別三級齊全0.2 坐標存在且通過反查0.2 - 每一個異常標記-0.1 - 置信度低于閾值再減0.1跑完下來分數(shù)低于0.5的數(shù)據(jù)進入人工審核池0.5到0.7之間抽樣審核0.7以上自動通過。剛開始人工審核池占將近四成后來Prompt優(yōu)化和知識庫補全后壓到了不到一成這個指標是檢驗整個鏈路效果的硬標尺。4. 實踐中的典型問題與排查實錄4.1 模型幻覺地址補全變成了地址編造最頭疼的問題就是模型編地址。比如輸入“某市人民路附近”模型可能直接補全出一個不存在的“人民路88號”而且看起來很合理。我排查后總結(jié)出規(guī)律模型在低信息量輸入下特別容易產(chǎn)生幻覺因為它在努力“填滿”Schema輸出。解決辦法有幾層在Prompt里明確寫“地址缺省字段一律留空不要推斷”。在知識庫校驗層增加“地址要素合法化校驗”門牌號超過范圍直接標記。在輸出后處理時統(tǒng)計地址完整度凡是關(guān)鍵字段連續(xù)多個由模型推斷且無原始數(shù)據(jù)佐證的直接降置信度并進人工審核池。平靜之后觀察模型確實更“老實”了不敢亂編了。4.2 類別體系漂移不同批次跑出的分類粒度不一致同樣的“牛肉面館”有時候模型輸出“餐飲-快餐-面館”有時候輸出“餐飲-小吃-面條”甚至還有一次輸出“食品-餐飲服務(wù)-正餐”。這就是大模型輸出不穩(wěn)定的直接體現(xiàn)。我用了兩個手段約束預(yù)先給一份類目體系樹的關(guān)鍵節(jié)點放到Prompt里讓模型只能在樹里選。輸出后再做一層類目映射表把模型輸出結(jié)果統(tǒng)一映射到業(yè)務(wù)側(cè)標準三級類目上。有個有趣的現(xiàn)象加了類目體系樹之后模型的分類一致性肉眼可見地提高因為候選空間被收窄了。這個細節(jié)很值得留意。4.3 規(guī)則預(yù)清洗把有效信息誤刪了有一版清洗規(guī)則里我加了“過濾括號內(nèi)容”的邏輯本意是去掉名稱里的無意義注釋。結(jié)果一批連鎖品牌的數(shù)據(jù)大量中招比如“瑞幸咖啡(某某廣場店)”被清成了“瑞幸咖啡”反而丟了門店識別信息合并時大量誤合并。這個教訓(xùn)讓我明白預(yù)清洗規(guī)則必須可審計、可回滾。后來規(guī)則全部記錄處理動作每條清洗數(shù)據(jù)都能查到“誰改了什么、為什么改”并且針對名稱清洗和白名單保護了品牌主體后面的括號內(nèi)門店詞。4.4 成本監(jiān)控十萬條POI的Token消耗如何降下來跑批量那幾天Token賬單漲得比較快不得不認真做一次成本復(fù)盤。優(yōu)化方式主要有三個緩存歷史結(jié)果相同MD5內(nèi)容的原始記錄直接復(fù)用上一次結(jié)果不做重復(fù)LLM調(diào)用這條省下的成本最直觀。優(yōu)先規(guī)則處理能通過字典映射和坐標校驗完成的記錄跳過LLM步驟這類數(shù)據(jù)節(jié)省了大約三成Token。動態(tài)選擇輸入字段某些來源只有名稱沒有地址Prompt里就不放地址任務(wù)只做名稱標準化和類別推斷省略地址部分的輸出Token。優(yōu)化后單條成本下降了一半以上但質(zhì)量分沒有掉說明之前的成本確實有不少花在了無意義的地方。5. 集成過程中的關(guān)鍵經(jīng)驗與可復(fù)用建議5.1 鏈路可觀測性日志字段要提前設(shè)計不管是POI-Enhancer還是LLM4POI集成過程中一定要做好鏈路日志。我在每個處理階段都輸出一條日志記錄輸入原始值、規(guī)則處理結(jié)果、LLM返回結(jié)果、知識庫校驗結(jié)果、最終輸出結(jié)果的差異對比。聯(lián)調(diào)時這些日志是定位問題最快的依據(jù)。比如我遇到過一個問題“某市某區(qū)某路某大廈”在知識庫校驗時區(qū)縣匹配失敗日志顯示規(guī)則清洗階段把這個地址的區(qū)縣字段給覆蓋成別的值了如果沒有日志很難排查到這種跨模塊的數(shù)據(jù)污染。5.2 接口容錯超時、限流、重試策略LLM接口調(diào)用不是百分百可靠項目里出現(xiàn)過高延遲、限流、偶爾5xx錯誤。我設(shè)置了分級重試策略超時類錯誤指數(shù)退避重試兩次限流類錯誤等待后重試一次參數(shù)類錯誤直接終止并告警。同時把并發(fā)數(shù)調(diào)低讓調(diào)用速率穩(wěn)定在服務(wù)方容忍范圍內(nèi)。這個策略跑下來整體成功率穩(wěn)定在99.5%以上其余進入異常隊列第二天重放。5.3 從單機腳本升級到任務(wù)化調(diào)度項目初期就是單機腳本跑全量后來數(shù)據(jù)量變大且需要每日增量更新加調(diào)度框架后好處明顯斷點續(xù)跑、失敗告警、依賴編排、并行分區(qū)處理都順了。我把整個處理流程拆成“原始同步、預(yù)清洗、LLM增強、知識庫校驗、輸出落庫、質(zhì)量報告”六個階段每個階段獨立可跑、可跳過、可重試。這個改造雖然初期花了些時間但后續(xù)每一次調(diào)參都收益明顯。5.4 快速上線建議先跑通一條鏈路再橫向擴展如果你也要做類似的POI增強系統(tǒng)我的建議是別一上來就鋪全量。先拿出一個區(qū)級的數(shù)據(jù)幾百條把所有模塊跑通手工檢驗質(zhì)量分閾值和Prompt效果穩(wěn)定后再擴展到全市數(shù)據(jù)每一次batch處理完都要看質(zhì)量報告而不是只關(guān)心有沒有跑掛。調(diào)Prompt是個玄學(xué)過程觀察幾十條典型case再修改比盲目加規(guī)則和示例更高效。6. 后續(xù)擴展方向當(dāng)前方案解決了POI標準化和增強的主鏈路但還有幾個方向值得繼續(xù)深入。多模態(tài)信息接入POI對應(yīng)的門頭照片、街景圖如果能作為輔助信號配合LLM做名稱和類別的交叉驗證準確率應(yīng)該還能再上一個臺階。增強檢索與自助問答能力增強后的POI數(shù)據(jù)接上向量檢索能支撐更靈活的上游服務(wù)比如用戶發(fā)一句“這附近有沒有適合帶娃吃面的店”能直接定位到對應(yīng)POI集合。構(gòu)建POI數(shù)據(jù)回流閉環(huán)業(yè)務(wù)使用過程中用戶反饋的修正信息收集起來定期更新知識庫字典讓系統(tǒng)越跑越準。我個人在實際操作中的體會是這套方案真正的壁壘不是模型本身而是圍繞模型搭建的校驗、糾錯、反饋體系。通用大模型的能力還在快速升級但POI數(shù)據(jù)治理里的確定性問題——格式、規(guī)則、字典、行政區(qū)劃——始終需要工程化手段去兜底。LLM負責(zé)“創(chuàng)造性理解”規(guī)則和知識庫負責(zé)“確定性約束”兩相結(jié)合才能把一個看起來簡單的數(shù)據(jù)清洗需求真正做出生產(chǎn)級質(zhì)量。最后再分享一個小技巧在寫Prompt時把“不能做什么”比“要做什么”寫得更醒目一些尤其在地址補全和屬性推斷這兩類高風(fēng)險環(huán)節(jié)。這套系統(tǒng)上線到現(xiàn)在質(zhì)量報告里新增的高風(fēng)險異?；径紒碓从诋?dāng)時我沒有在Prompt中約束清楚的場景。