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