設(shè)計(jì)與實(shí)現(xiàn))
城市遙感變化檢測這幾年幾乎是所有測繪院、規(guī)劃院和衛(wèi)星應(yīng)用公司的剛需。但凡是做過實(shí)際項(xiàng)目的人都清楚傳統(tǒng)流程是把兩期影像丟進(jìn)模型里出一張差分圖再人工看一遍寫報(bào)告過程又慢又費(fèi)人。我這兩年一直在琢磨一件事能不能把“變化在哪”和“為什么變、影響多大、該不該管”這一整條鏈路交給一個(gè)智能體去組織把那些固定套路的事自動(dòng)化讓人只做判斷和決策。于是就有了這個(gè)基于LLM智能體框架的城市遙感圖像變化分析系統(tǒng)。這篇文章把我從架構(gòu)設(shè)計(jì)到落地實(shí)現(xiàn)的過程、踩過的坑、調(diào)過的參都整理出來給想做這個(gè)方向的同行一個(gè)參考。1. 先想清楚LLM智能體到底解決了遙感變化檢測的什么問題1.1 傳統(tǒng)變化檢測流程的五個(gè)真實(shí)痛點(diǎn)先說傳統(tǒng)流程。以前做一個(gè)城市變化監(jiān)測項(xiàng)目大概是這個(gè)節(jié)奏拿兩期影像做輻射歸一化、幾何配準(zhǔn)然后跑一個(gè)變化檢測網(wǎng)絡(luò)輸出二值圖或者差異圖再人工目視解譯圈出變化斑塊核實(shí)屬性最后整理成報(bào)告。聽起來不復(fù)雜但實(shí)際做起來至少有五個(gè)痛點(diǎn)非常要命。第一語義碎片化。像素級的檢測結(jié)果往往是一片一片的噪聲同一個(gè)真實(shí)變化被切成好幾塊或者不同性質(zhì)的微小變化混在一起。每次都要靠人去合并、去分類規(guī)則寫著寫著就成了一堆沒人敢動(dòng)的補(bǔ)丁邏輯。第二后處理鏈條太長。柵格轉(zhuǎn)矢量、小斑塊過濾、形態(tài)學(xué)運(yùn)算、邊界平滑、屬性賦值每一步都有參數(shù)參數(shù)之間還互相耦合。項(xiàng)目換了數(shù)據(jù)源整套參數(shù)就得重新調(diào)一遍。第三閾值選擇靠拍腦袋。變化檢測模型輸出的概率圖定多少算變化不同傳感器、不同季節(jié)、不同城市都不一樣。很多項(xiàng)目直接取0.5結(jié)果不是漏檢就是誤報(bào)。第四結(jié)果不可解釋。深度學(xué)習(xí)模型的輸出就是一張圖領(lǐng)導(dǎo)問“這個(gè)地方為什么算變化”你只能說“模型這么判斷的”這在業(yè)務(wù)上沒法落地的。第五報(bào)告寫作費(fèi)人力。圖斑統(tǒng)計(jì)表、位置描述、面積匯總、合規(guī)性初判這些工作看起來簡單批量起來極其消耗人天。一個(gè)城市級項(xiàng)目全手工整理報(bào)告大概要占掉三分之一的人力。這些痛點(diǎn)其實(shí)指向同一個(gè)方向變化檢測這個(gè)事真正值錢的不是“找出變化”而是“理解變化”。而理解變化恰好是LLM智能體最擅長的事。1.2 LLM智能體切入的三個(gè)核心環(huán)節(jié)LLM智能體不是來替代變化檢測模型的它是來接管“組織、理解、輸出”這三個(gè)環(huán)節(jié)的。第一個(gè)環(huán)節(jié)叫工具編排。智能體可以根據(jù)用戶的一句話需求自己決定調(diào)哪個(gè)數(shù)據(jù)預(yù)處理工具、跑哪個(gè)檢測模型、做什么后處理而不是像傳統(tǒng)pipeline那樣寫死流程。比如用戶說“看看東片區(qū)近兩年有多少新增建筑”智能體就會(huì)規(guī)劃先按行政區(qū)劃裁剪影像調(diào)用建筑變化模型再做矢量化和面積統(tǒng)計(jì)最后結(jié)合規(guī)劃數(shù)據(jù)判斷合規(guī)性。第二個(gè)環(huán)節(jié)是語義解讀。變化檢測模型輸出的是柵格和矢量這些幾何數(shù)據(jù)本身沒有語義。智能體能結(jié)合地理知識(shí)、城規(guī)知識(shí)甚至網(wǎng)絡(luò)公開信息把“這里有個(gè)圖斑”翻譯成“該地塊存在疑似新增工業(yè)廠房面積約1.2公頃位于生態(tài)控制線內(nèi)需進(jìn)一步核實(shí)”。第三個(gè)環(huán)節(jié)是報(bào)告生成與交互。智能體可以把表格、圖例、文字描述、風(fēng)險(xiǎn)提示組織成一份結(jié)構(gòu)化報(bào)告并且允許用戶追問比如“這個(gè)變化區(qū)域周邊的路網(wǎng)情況怎么樣”智能體可以繼續(xù)調(diào)工具查數(shù)據(jù)而不是重新跑一整套流程。1.3 適用邊界別指望它什么都干我必須先潑一盆冷水。LLM智能體不是萬能的有些場景它真不適合。適合的場景包括變化檢測結(jié)果的后處理與語義化、點(diǎn)對點(diǎn)的問答式查詢、多源數(shù)據(jù)的匯總研判、報(bào)告草稿生成、閾值的自適應(yīng)解釋等等。不適合的場景也有高精度的像素級定位、實(shí)時(shí)視頻流變化檢測、對模型推理速度有硬性要求的在線系統(tǒng)。這些事還是乖乖用傳統(tǒng)CV和專用深度學(xué)習(xí)模型。我現(xiàn)在的產(chǎn)品定位就是“面向分析研判的半自動(dòng)系統(tǒng)”模型負(fù)責(zé)干活智能體負(fù)責(zé)組織干活并解釋結(jié)果。這個(gè)定位切得越清楚落地越順。2. 系統(tǒng)總體架構(gòu)與技術(shù)選型2.1 核心架構(gòu)規(guī)劃—工具—記憶—反思四層我最終采用的智能體架構(gòu)本質(zhì)上是一個(gè)帶工具調(diào)用能力的多輪對話系統(tǒng)分為四層。第一層是規(guī)劃層。智能體接收用戶意圖后把任務(wù)拆解成若干子步驟。這里我初始用的就是ReAct模式的改寫版讓模型顯式地輸出“當(dāng)前目標(biāo)、下一步動(dòng)作、調(diào)用參數(shù)”每一步都落在結(jié)構(gòu)化的JSON里方便程序解析和校驗(yàn)。第二層是工具層。典型工具包括影像檢索、柵格裁剪、變化檢測推理、矢量后處理、面積統(tǒng)計(jì)、地類標(biāo)簽映射、圖斑報(bào)告生成。每個(gè)工具都是獨(dú)立服務(wù)通過統(tǒng)一的OpenAPI規(guī)范注冊給LLM。實(shí)測下來工具命名和描述寫得清不清楚直接決定智能體會(huì)不會(huì)調(diào)錯(cuò)工具這塊后面細(xì)講。第三層是記憶層。短期記憶用對話上下文長期記憶我引入了兩塊一塊是業(yè)務(wù)知識(shí)庫存城市規(guī)劃控制線、地類分類標(biāo)準(zhǔn)、歷史項(xiàng)目報(bào)告模板另一塊是會(huì)話存檔同一個(gè)地塊的多次分析結(jié)果可以復(fù)用避免重復(fù)計(jì)算。第四層是反思層。每次工具調(diào)用的返回值會(huì)經(jīng)過一個(gè)校驗(yàn)器。比如矢量數(shù)據(jù)面積明顯不合理或者坐標(biāo)系對不上就觸發(fā)重新規(guī)劃。這個(gè)反思機(jī)制在真實(shí)項(xiàng)目中救了我很多次。2.2 底層變化檢測引擎選型智能體調(diào)用的是變化檢測引擎引擎本身還是要選對的。我測試過好幾條路線。最簡單的是像素級差分法比如影像差值加閾值分割優(yōu)點(diǎn)是快、無需標(biāo)注缺點(diǎn)是對輻射差異極其敏感兩期影像光照稍有不同整個(gè)城市都在“變化”。除非數(shù)據(jù)源高度一致否則不做首選。實(shí)用路線是孿生網(wǎng)絡(luò)。兩期影像經(jīng)過共享權(quán)重的編碼器提取特征再對特征做差異增強(qiáng)最后解碼成變化概率圖。代表性的結(jié)構(gòu)有SiamCRNN、SiamU-Net這類。我在項(xiàng)目里用的基線是SiamU-Net的改進(jìn)版在自建的城市變化數(shù)據(jù)集上mIoU大概能到0.71左右基本滿足業(yè)務(wù)初篩要求。如果想追求精度更高可以換基于Transformer的ChangeFormer或者帶注意力融合的模型對小目標(biāo)變化敏感度會(huì)高一些但是計(jì)算量也上來了。一個(gè)1024×1024的影像patch在單張消費(fèi)級顯卡上可能要跑2-3秒全城推理要算好時(shí)間預(yù)算。我在真實(shí)項(xiàng)目里做了一個(gè)折中先用SiamU-Net出概率圖再用一個(gè)輕量的地物分類模型給變化區(qū)域打標(biāo)簽比如區(qū)分建筑、道路、植被、水體。這樣一個(gè)模型管“變沒變”一個(gè)模型管“變成什么”配合起來效果好過單模型硬train。2.3 GIS工具層與數(shù)據(jù)格式中樞整個(gè)系統(tǒng)里最容易被低估的就是GIS工具層。很多做AI的人把精力放在模型上結(jié)果數(shù)據(jù)格式一塌糊涂最后分析結(jié)果根本導(dǎo)不進(jìn)ArcGIS。我的建議是統(tǒng)一用GeoJSON作為矢量交換格式柵格統(tǒng)一用GeoTIFF投影信息在每一步都要保留。所有后端處理工具輸入輸出都走這兩個(gè)格式。坐標(biāo)系我內(nèi)部統(tǒng)一用EPSG:4326的經(jīng)緯度前端展示再動(dòng)態(tài)轉(zhuǎn)Web墨卡托。為什么不用投影坐標(biāo)系因?yàn)橛跋裨紨?shù)據(jù)五花八門有的地方是高斯投影有的是UTM統(tǒng)一轉(zhuǎn)WGS84經(jīng)緯度最保險(xiǎn)雖然面積計(jì)算要重新?lián)Q算但不會(huì)出大錯(cuò)。工具層還用到了PostGIS做空間查詢。變化圖斑入庫后跟控制線、用地紅線、生態(tài)保護(hù)區(qū)做空間疊加分析這一步交給空間數(shù)據(jù)庫比讓模型自己算靠譜得多。2.4 LLM選型與工具調(diào)用方式LLM選型我前前后后測了三種路線。第一是純閉源大模型直接調(diào)API效果最好函數(shù)調(diào)用能力最穩(wěn)但是數(shù)據(jù)出域很多政務(wù)客戶不接受項(xiàng)目直接斃掉。第二是私有化部署開源模型數(shù)據(jù)不出域但函數(shù)調(diào)用能力弱稍微復(fù)雜一點(diǎn)的參數(shù)嵌套就漏參數(shù)比如讓它調(diào)一個(gè)裁剪工具五個(gè)參數(shù)能漏倆。第三是混合模式本地部署一個(gè)小模型做意圖識(shí)別和參數(shù)洗牌核心分析調(diào)用云端大模型。這個(gè)方案數(shù)據(jù)合規(guī)性可以解釋效果也過得去我目前部署默認(rèn)用這個(gè)。不管哪種模式工具調(diào)用的核心機(jī)制都差不多把每個(gè)工具的入?yún)?、出參、用途寫成一個(gè)JSON Schema塞進(jìn)上下文里讓模型輸出結(jié)構(gòu)化的調(diào)用指令然后由程序去執(zhí)行執(zhí)行結(jié)果再回傳給模型。這塊比讓模型直接生成Python代碼要穩(wěn)得多因?yàn)榇a執(zhí)行風(fēng)險(xiǎn)高還要多一道沙箱收益卻不明顯。3. 關(guān)鍵實(shí)現(xiàn)細(xì)節(jié)與代碼級拆解3.1 數(shù)據(jù)準(zhǔn)備裁剪、對齊、輻射歸一化三步走影像預(yù)處理這個(gè)階段80%的變化檢測效果都取決于它。很多模型精度不夠其實(shí)是數(shù)據(jù)沒對齊。第一步裁剪。原始影像動(dòng)不動(dòng)就是上萬像素寬直接丟進(jìn)模型顯存直接爆掉。要按512×512或者1024×1024的patch切patch之間保留50像素的重疊防止變化目標(biāo)恰好被切在邊界上。第二步對齊。兩期影像要用同名點(diǎn)做二次配準(zhǔn)我用的是基于特征匹配的自動(dòng)配準(zhǔn)再檢查像元級對齊精度。如果配準(zhǔn)誤差超過一個(gè)像元后續(xù)像素級對比就基本沒意義。第三步輻射歸一化。這個(gè)坑太典型了。兩期影像拍攝季節(jié)不同、傳感器不同灰度分布差異巨大。我用的是直方圖匹配加線性回歸校正把參考影像的輻射特征調(diào)整到與基準(zhǔn)期一致。做完這步識(shí)別出的“變化”才是真實(shí)變化而不是光照變化。代碼上核心就是兩段。一段做配準(zhǔn)我是用rasterio讀取影像、OpenCV提取特征、計(jì)算單應(yīng)矩陣重采樣這個(gè)流程不多說。一段做輻射校正我直接貼個(gè)簡化版示意import numpy as np from skimage.exposure import match_histograms def radiation_normalize(base, target): # 將target影像的直方圖匹配到base影像 matched match_histograms(target, base, channel_axis-1) return matched.astype(np.uint16)實(shí)際項(xiàng)目里我還會(huì)加一個(gè)掩膜把云、云影和水體區(qū)域先摳出來不參與校正不然這些地物的直方圖會(huì)拖累全局統(tǒng)計(jì)。3.2 變化檢測推理與后處理從概率圖到干凈圖斑模型推理本身沒什么特別就是把兩期影像patch喂進(jìn)去拿到變化概率圖。真正的功夫在后處理。我后處理的順序是概率圖閾值分割→連通域分析→小斑塊過濾→形態(tài)學(xué)平滑→柵格轉(zhuǎn)矢量→邊界簡化。閾值這塊我不用固定0.5而是用Otsu算法自適應(yīng)確定或者根據(jù)類別頻率動(dòng)態(tài)調(diào)整。一個(gè)我總結(jié)的小經(jīng)驗(yàn)城市區(qū)域建筑變化概率圖的分布往往呈雙峰Otsu的效果遠(yuǎn)好于固定閾值而道路變化概率圖是單峰長尾需要人工指定一個(gè)較低的閾值比如0.35否則漏檢嚴(yán)重。后處理核心代碼示意import cv2 import numpy as np from shapely.geometry import shape from rasterio.features import shapes def postprocess(prob_map, threshold0.5, min_area_px200): binary (prob_map threshold).astype(np.uint8) # 形態(tài)學(xué)開運(yùn)算去噪 kernel cv2.getStructuringElement(cv2.MORPH_RECT, (3, 3)) binary cv2.morphologyEx(binary, cv2.MORPH_OPEN, kernel, iterations2) # 連通域過濾 num, labels, stats, _ cv2.connectedComponentsWithStats(binary) keep np.zeros_like(binary) for i in range(1, num): if stats[i, cv2.CC_STAT_AREA] min_area_px: keep[labels i] 1 return keep這一步之后我才把柵格轉(zhuǎn)成矢量。轉(zhuǎn)矢量用rasterio的shapes函數(shù)輸出GeoJSON然后做坐標(biāo)轉(zhuǎn)換把像素坐標(biāo)轉(zhuǎn)換為地理坐標(biāo)。這里要注意輸出的多邊形邊界往往是鋸齒形的我會(huì)用Douglas-Peucker做一次簡化容差根據(jù)出圖比例尺設(shè)一般設(shè)3到5米。3.3 智能體工具注冊與分析鏈路實(shí)現(xiàn)工具注冊是整個(gè)智能體框架能不能跑通的關(guān)鍵。在每個(gè)工具的定義里描述要寫得像給實(shí)習(xí)生下指令一樣清楚包括它做什么、輸入輸出是什么、常見誤區(qū)是什么。比如裁剪工具的描述我這么寫{ name: crop_raster_by_geojson, description: 用GeoJSON范圍裁剪GeoTIFF影像返回裁剪后的GeoTIFF路徑。注意GeoJSON必須為EPSG:4326坐標(biāo)影像路徑須來自影像檢索工具。, parameters: { type: object, properties: { input_path: {type: string, description: 輸入GeoTIFF路徑}, aoi: {type: object, description: GeoJSON Polygon對象}, output_path: {type: string, description: 輸出GeoTIFF路徑} }, required: [input_path, aoi, output_path] } }畫重點(diǎn)描述里一定要寫“從哪里拿這個(gè)參數(shù)”比如“路徑須來自影像檢索工具”這樣能顯著減少LLM亂傳路徑的問題。這是我從一個(gè)真實(shí)bug里悟出來的當(dāng)時(shí)模型把用戶隨口說的一句地名當(dāng)成了文件路徑分析直接跑飛加了這句約束后類似問題少了很多。智能體的主循環(huán)核心邏輯如下def agent_loop(user_query, available_tools, max_steps8): messages [{role: system, content: SYSTEM_PROMPT}] messages.append({role: user, content: user_query}) for step in range(max_steps): resp llm_chat(messages, toolsavailable_tools) if resp.tool_calls: for call in resp.tool_calls: result execute_tool(call.name, call.arguments) messages.append(tool_result_message(call.id, result)) else: return resp.content return 已達(dá)到最大步驟數(shù)中止。每一步工具結(jié)果回傳后模型會(huì)決定是繼續(xù)調(diào)用下一步工具還是直接生成最終回答。我在幾個(gè)月度項(xiàng)目里觀察平均一個(gè)完整的地塊變化分析任務(wù)需要4到7次工具調(diào)用。3.4 提示詞設(shè)計(jì)與多輪狀態(tài)管理提示詞設(shè)計(jì)這事容易被當(dāng)成寫作文其實(shí)它是工程。我的系統(tǒng)提示詞固定分四塊角色設(shè)定、工具使用規(guī)則、分析流程規(guī)范、輸出格式規(guī)范。角色設(shè)定不要寫“你是遙感專家”這種空話要寫“你是城市遙感變化分析助手負(fù)責(zé)組織工具完成分析并解釋結(jié)果”。工具使用規(guī)則里有一條很關(guān)鍵一次只調(diào)用一個(gè)工具等結(jié)果返回后再?zèng)Q定下一步。如果讓它一次并行調(diào)多個(gè)工具參數(shù)混亂的概率會(huì)直線上升。輸出格式規(guī)范也要明確。我對變化分析報(bào)告規(guī)定了固定的markdown結(jié)構(gòu)摘要、變化區(qū)域列表、圖斑明細(xì)表、風(fēng)險(xiǎn)研判、建議復(fù)核清單。模型如果自由發(fā)揮報(bào)告格式每次都不一樣下游沒法接。多輪狀態(tài)管理我踩過一個(gè)坑用戶意圖變化后上一輪的工具結(jié)果還堆在上下文里模型容易串。解決方案是每輪對話前做一次歷史壓縮把已經(jīng)完成的工具調(diào)用結(jié)果摘要化只保留關(guān)鍵數(shù)值比如“建筑新增總面積3.2公頃已提取圖斑12個(gè)”而不是堆完整的GeoJSON。這樣既省token也防止串?dāng)?shù)據(jù)。4. 實(shí)操過程一個(gè)城市地塊的完整變化分析演示4.1 場景設(shè)定與數(shù)據(jù)情況拿一個(gè)我做過測試的模擬項(xiàng)目X來說。數(shù)據(jù)是某城市高新區(qū)一塊約4平方公里的區(qū)域兩期高分影像間隔兩年。一期是六月份拍的二期是同年份另一天的不同時(shí)段包含云量很少地物有建筑新建、裸土翻整、道路拓寬等變化。我要求智能體完成以下任務(wù)識(shí)別新增建筑區(qū)域、評估對周邊生態(tài)控制線的影響、生成變化分析簡報(bào)。用戶原始輸入就一句話“高新區(qū)西北片區(qū)兩年內(nèi)新增了哪些建筑有沒有越線的給我出一份簡報(bào)。”4.2 智能體完整工作流演練整套工作流我一步步拆給你看。第一步意圖解析。LLM把用戶問題拆成子任務(wù)清單檢索兩期影像、裁剪AOI區(qū)域、執(zhí)行變化檢測、提取新增建筑類變化圖斑、與生態(tài)控制線疊加分析、生成簡報(bào)。這六步會(huì)被動(dòng)態(tài)編排而不是全部執(zhí)行。第二步影像檢索。LLM調(diào)用imagery_search工具范圍設(shè)置為高新區(qū)西北片區(qū)、獲取時(shí)間為兩個(gè)年份。影像檢索返回兩個(gè)GeoTIFF路徑。這里注意LLM自己不會(huì)判斷影像是否含云工具層在返回時(shí)自動(dòng)帶上云量檢查結(jié)果。第三步裁剪與預(yù)處理。LLM調(diào)用crop工具和normalize工具。normalize返回的輻射統(tǒng)計(jì)信息顯示兩期影像直方圖相關(guān)性0.92符合處理要求。第四步變化檢測推理。LLM調(diào)用change_detect工具模型輸出概率圖后后處理模塊自動(dòng)生成圖斑矢量。工具返回的信息不是完整GeoJSON而是摘要圖斑數(shù)27個(gè)總面積3.8公頃置信度均值0.86。第五步地類分類。LLM發(fā)現(xiàn)用戶關(guān)心“建筑”所以接著調(diào)用land_cover_classify工具給27個(gè)圖斑打地類標(biāo)簽。結(jié)果顯示新增建筑類圖斑13個(gè)面積2.4公頃。第六步疊加分析。LLM調(diào)用spatial_overlay工具把這些圖斑與生態(tài)控制線疊加。工具返回其中有2個(gè)圖斑面積0.3公頃與生態(tài)控制線范圍相交屬于疑似越線。第七步生成簡報(bào)。LLM整合所有結(jié)果輸出一份帶表格的markdown報(bào)告。這一步一步你可能會(huì)問是不是太慢了實(shí)測下來從提問到拿到完整簡報(bào)耗時(shí)約1分20秒。其中變化檢測推理占了大頭大約50秒LLM規(guī)劃加工具調(diào)用本身只占20多秒。和人工流程相比這個(gè)速度已經(jīng)快了一個(gè)數(shù)量級。4.3 輸出內(nèi)容形式與人工復(fù)核閉環(huán)智能體最終生成的簡報(bào)長這樣開頭一段摘要概述區(qū)域內(nèi)新增建筑主要分布方向中間是變化圖斑明細(xì)表每一行包含圖斑編號、面積、地類、是否越線再往下是空間分析結(jié)論重點(diǎn)標(biāo)出越線風(fēng)險(xiǎn)區(qū)域最后是一份建議人工復(fù)核清單列出需要現(xiàn)場拍照驗(yàn)證的3個(gè)圖斑。這里我特別想強(qiáng)調(diào)人工復(fù)核閉環(huán)。智能體不是替代人做最終決策的它是把人的注意力引導(dǎo)到真正需要看的地方。我見過很多團(tuán)隊(duì)把目標(biāo)定成“全自動(dòng)檢測、全自動(dòng)報(bào)告”結(jié)果模型一出錯(cuò)沒人發(fā)現(xiàn)最后領(lǐng)導(dǎo)問責(zé)。我的方案是所有智能體生成的結(jié)論都必須標(biāo)注置信度低于閾值的圖斑自動(dòng)進(jìn)入“待現(xiàn)場核實(shí)”列表。這樣模型有錯(cuò)也只會(huì)漏在明面上不會(huì)被無聲無息地掩蓋。5. 常見問題與排查技巧實(shí)錄5.1 LLM幻覺編造不存在的圖斑或面積這個(gè)問題在最開始幾乎天天碰到。模型在總結(jié)時(shí)會(huì)一本正經(jīng)地寫出“新增建筑面積5.6公頃”之類的數(shù)字但你回頭對賬所有圖斑加起來只有2公頃。原因很簡單模型不是在計(jì)算它是在“生成一個(gè)像樣的數(shù)字”。我的解決辦法是強(qiáng)約束工具結(jié)果的傳遞。所有統(tǒng)計(jì)數(shù)字不從LLM對話里提取而是工具結(jié)果里帶一段machine-readable的JSON摘要顯示給用戶看的文本由模板生成。LLM只負(fù)責(zé)解釋和分析不負(fù)責(zé)編數(shù)字。另外我在反思層加了一個(gè)校驗(yàn)器每次LLM生成最終回答前會(huì)檢查它引用的數(shù)字是否與工具計(jì)算結(jié)果一致不一致就打回重寫。5.2 坐標(biāo)對不上圖斑飛到十萬八千里外這個(gè)坑我印象太深了。第一次聯(lián)調(diào)時(shí)模型生成的圖斑疊加在底圖上竟然漂到了幾萬公里外的海上。排查后發(fā)現(xiàn)是工具返回GeoJSON時(shí)坐標(biāo)沒做轉(zhuǎn)換一個(gè)環(huán)節(jié)輸出的是投影坐標(biāo)另一個(gè)環(huán)節(jié)按經(jīng)緯度解析空間關(guān)系全部錯(cuò)亂。從此我立了一個(gè)鐵律所有工具接口的GeoJSON一律EPSG:4326并且在工具描述里高亮強(qiáng)調(diào)。另外我在后處理服務(wù)的邊界上加了個(gè)合理性檢查輸出坐標(biāo)范圍如果超出城市邊界范圍一定會(huì)彈告警。5.3 大影像處理顯存不夠和推理時(shí)間失控城市級影像動(dòng)輒幾十GB直接整景推理根本不現(xiàn)實(shí)。我測試過幾種切patch的方式最優(yōu)方案是按固定瓦片網(wǎng)格切而不是滑動(dòng)窗口切。瓦片網(wǎng)格的好處是結(jié)果可緩存下次分析同一區(qū)域就不用重算。每個(gè)瓦片1024×1024檢測模型推理一次2-3秒整個(gè)高新區(qū)大概400個(gè)瓦片并行8卡約15分鐘出完整底圖。這個(gè)速度對離線監(jiān)測足夠用了。實(shí)時(shí)性需求更強(qiáng)的場景可以降采樣到512×512或者干脆只分析用戶框選的重點(diǎn)區(qū)域不跑全城。5.4 漏檢和誤檢閾值與樣本的雙重博弈漏檢和誤檢是變化檢測永恒的話題。智能體排錯(cuò)時(shí)我發(fā)現(xiàn)誤檢的圖斑往往集中在影像配準(zhǔn)誤差大的邊緣地區(qū)尤其是建筑物立面傾斜產(chǎn)生的鬼影。解決辦法是分區(qū)設(shè)置閾值影像中心區(qū)域閾值0.45邊緣區(qū)域閾值調(diào)到0.6。漏檢問題更麻煩頻繁發(fā)生在小目標(biāo)變化上比如一棟小房子拆除。這類變化像素占比可能只有幾十個(gè)像素后處理最小圖斑面積參數(shù)設(shè)大了直接過濾掉。我的調(diào)試思路是把最小圖斑面積參數(shù)做成可配置項(xiàng)由智能體根據(jù)任務(wù)類型自動(dòng)選擇做建筑監(jiān)測時(shí)設(shè)300像素做細(xì)碎變化監(jiān)測時(shí)設(shè)80像素。樣本層面實(shí)在的辦法是持續(xù)標(biāo)注。每季度用智能體篩選出的低置信度圖斑做一次人工標(biāo)注回流微調(diào)。我見過很多項(xiàng)目忽略了這一步模型效果隨著城市變化越來越差還不自知。5.5 長上下文與工具調(diào)用沖突對話一長上下文里堆了幾輪工具結(jié)果后LLM開始出現(xiàn)“忘事”明明前面已經(jīng)算過總面積后面又調(diào)一次工具重算或者干脆把歷史圖斑號張冠李戴。我做了三件事一是上文說過的歷史摘要壓縮二是限定工具調(diào)用步驟不超過8次超過就強(qiáng)制輸出階段性小結(jié)三是輪次結(jié)束時(shí)清理臨時(shí)文件避免臟數(shù)據(jù)殘留影響下一輪分析。這三板斧加上去長會(huì)話穩(wěn)定性改善非常明顯。至少在我現(xiàn)在的壓力測試?yán)镞B續(xù)10輪對話不串線、不重復(fù)計(jì)算已經(jīng)能做到。最后分享一點(diǎn)個(gè)人體會(huì)做這個(gè)系統(tǒng)最大的體會(huì)是LLM智能體在遙感里的價(jià)值不是讓模型變得更強(qiáng)而是讓整個(gè)分析流程變得像人一樣會(huì)思考和會(huì)溝通。以前做變化檢測用戶拿到的是一張圖和一堆參數(shù)現(xiàn)在用戶拿到的是能看懂、能追問、能直接輔助決策的結(jié)論。這套東西后續(xù)還能往兩個(gè)方向延伸一個(gè)是把多源數(shù)據(jù)接入比如把夜間燈光、POI、路網(wǎng)數(shù)據(jù)一起喂給智能體做綜合研判另一個(gè)是端到端微調(diào)一個(gè)小參數(shù)模型把工具調(diào)用和領(lǐng)域知識(shí)內(nèi)化進(jìn)去減少對外部大模型的依賴。如果你也在琢磨這個(gè)方向建議從一個(gè)小地塊、一個(gè)明確的監(jiān)測需求開始先把工具鏈跑通再去追求規(guī)模和智能感。