简介基于机器学习的治安案件预警系统完整项目包面向毕业设计、课程设计及期末大作业等典型场景旨在帮助学习者快速搭建案件数据建模与预警展示流程。资源融合机器学习与深度学习技术涵盖前后端完整代码适合具备Java Web基础、希望完成同类课题的学生参考。包内共225个文件包含36个JS、32个CSS、22个HTML等前端页面以及15个Java类、30个class文件和3个SQL数据库脚本整体大小仅4.71MB。从内容预览可看出项目涵盖数据库操作、Servlet控制层和人员管理实体等典型模块目录结构清晰便于对照学习。目前已有37人学习下载通过SQL初始化数据库并结合前端页面可快速理解项目结构与算法应用流程是一份性价比高的实战参考资料。1. 基于机器学习的治安案件预警系统.zip打开之前先想明白的三件事拿到“基于机器学习的治安案件预警系统.zip”这个包第一眼就能判断出里面装的是一整个工程数据清洗脚本、特征构造模块、模型训练代码、预估模型文件加上一份说明文档。这个方向的价值并不在于让模型精确预言“某年某月某日某地会发生某案”而在于把过去只能靠经验拍板的“哪里风险高”变成可量化、可回溯、可验证的“风险面”让巡逻和布控资源向高概率区域倾斜。值得照着做下去的人有两种一种是手里握有历史案件数据、只差一套建模路径的在校研究者另一种是具备一定数据分析能力的基层安全岗位从业者想自行搭建能跑通、能解释、能迭代的预警原型而不是采购一个说不清依据的封闭黑匣子。下文我不会去复述压缩包里的目录清单只按我实际落地这类系统的顺序把样本构造、特征选择、模型训练、踩坑处理和效果验证讲透。2. 治安案件预警的建模逻辑预警不是猜单案而是给“风险面”打分2.1 先定分析粒度样本不是“一条案件”而是“一个时空格子”治安案件预警最容易在起步阶段翻车因为很多人直接把“每一条案件记录”当作一条训练样本然后试图让模型预测“下一个案件发生在哪”。这么做有个绕不过去的坎负样本从哪来案件确实没发生的位置和时间点在原始数据里根本不存在你无法为“没发生的事件”凭空造出对照记录。因此这类系统必须先把连续空间切成网格把连续时间切成天或半天再把“某个网格 × 某个日期”当作一个候选样本。建模目标随之变为在未来的预警窗口内这个时空格子里发生风险的可能性有多高。粒度怎么选直接影响模型能学到什么网格边长 500 米左右在城市尺度上既能覆盖街区单元又不至于把数据拆得过分稀疏时间步取 1 天便于和值班、排班、日报制度对齐预警窗口取未来 7 天一周的跨度既保证预测有提前量又不会让标签因为窗口过长而变得噪声太大。标签的形状也值得刻意设计。二分类“未来 7 天是否发案”是最简单的起步版本如果案件样本量足够可以进一步把未来案件数量映射成 0、1、2、3 四个风险等级让模型从“会不会发生”升级为“风险有多大”。等级化之后输出就不再是一个冷冰冰的概率而是可以直接对应到网格巡查频次的分档。2.2 把原始案件表变成监督学习样本一段可以抄走的构造脚本样本构造是整个项目的地基地基歪了后面所有模型提升都是白费。下面这份代码目标是把“案件流水表”改写成“网格 × 日期”的监督学习表并顺手生成三类基础特征网格坐标、时间因子、历史案发密度。import pandas as pd import numpy as np def build_risk_samples( cases: pd.DataFrame, grid_size: float 0.005, # 经纬度网格边长约500米 history_days: int 30, # 用于构造历史特征的窗口 future_days: int 7 # 预警窗口未来7天 ): # 1. 网格化把经纬度取整形成 gx, gy 网格编号 cases cases.copy() cases[gx] np.floor(cases[lng] / grid_size).astype(int) cases[gy] np.floor(cases[lat] / grid_size).astype(int) cases[date] pd.to_datetime(cases[occur_time]).dt.normalize() # 2. 每个网格每天的案发计数 daily ( cases.groupby([gx, gy, date], as_indexFalse) .size() .rename(columns{size: n_case}) ) # 3. 生成全量候选样本所有网格 × 所有日期 cells daily[[gx, gy]].drop_duplicates() dates pd.date_range( daily[date].min(), daily[date].max() - pd.Timedelta(daysfuture_days), freqD ) samples cells.assign(dummy1).merge( pd.DataFrame({date: dates}).assign(dummy1), ondummy ).drop(columnsdummy) # 4. 构造标签未来 future_days 天内该网格是否再次发案 future daily[[gx, gy, date, n_case]].rename( columns{date: case_date, n_case: future_cnt} ) merged samples.merge(future, on[gx, gy]) merged merged[ (merged[date] merged[case_date]) (merged[case_date] merged[date] pd.Timedelta(daysfuture_days)) ] label ( merged.groupby([gx, gy, date])[future_cnt] .sum() .reset_index() ) samples samples.merge(label, on[gx, gy, date], howleft) samples[future_cnt] samples[future_cnt].fillna(0) samples[label] (samples[future_cnt] 0).astype(int) # 5. 构造历史特征过去 history_days 天内该网格的案发情况 hist daily[[gx, gy, date, n_case]].rename( columns{date: case_date, n_case: hist_cnt} ) feat samples.merge(hist, on[gx, gy]) feat feat[ (feat[case_date] feat[date]) (feat[case_date] feat[date] - pd.Timedelta(dayshistory_days)) ] agg ( feat.groupby([gx, gy, date]) .agg( recent_n_case(hist_cnt, sum), recent_n_days(hist_cnt, count) ) .reset_index() ) samples samples.merge(agg, on[gx, gy, date], howleft) samples[recent_n_case] samples[recent_n_case].fillna(0) samples[recent_n_days] samples[recent_n_days].fillna(0) # 6. 时间因子月份与星期 dt pd.to_datetime(samples[date]) samples[month] dt.dt.month samples[dow] dt.dt.dayofweek return samples代码里的关键设计有两处。其一是标签的求法我没有直接把“当天发案”当标签而是把从当天到未来 7 天内的案件全部归并到当前样本这样模型学到的是“过去某状态对未来一周风险的影响”而不是“昨天发案所以明天也发案”的原地重复。其二是历史特征窗口独立于标签窗口history_days 负责描述过去状态future_days 负责定义预测目标两者一旦混用就会把未来信息偷偷漏进特征训练指标好看、上线立刻失真。参数上grid_size 使用经纬度时建议取 0.005 到 0.01对应纬度方向约 500 到 1000 米如果你的案件数据覆盖范围很大可先用整张表跑一遍网格计数把网格数控制在几千个以内避免全笛卡尔积把样本量撑爆。样本量级粗估500 个网格跑一年约产生 18 万条训练样本足够训练一个树模型但还不足以支撑特别深的神经网络。2.3 负样本处理不要把“多报”当成“错报”治安案件预警天然是类别不平衡问题高风险格子在所有样本里通常只占 5% 到 15%。模型如果只用准确率做指标完全可以把所有格子都预测为“无风险”拿一个 90% 的准确率交差。线上这么干的最直接后果是预警系统永远不报报了也是误报最后被一线直接弃用。更合理的做法是把评估指标重心放在精确率、召回率、PR 曲线、以及“预警点位命中率”这类业务指标上。比如每天选出全城风险分最高的前 20 个网格统计这些网格在未来 7 天里实际发生案件的比例这个命中率才是系统价值的分母。标签比例低不是模型缺陷它只是提醒你训练时要用类别权重评估时不要只看准确率阈值选择要放到后面单独调。3. 特征工程与基线模型先让系统跑通再谈精度提升3.1 特征面板把一个“格子”变成模型能消化的向量样本构造完成后表格里只有近 30 天案发量、活跃天数和时间因子这几列这远不足以支撑有效预警。治安风险的空间分布有明显“聚集效应”一个网格周边区域的历史案发情况往往比网格自身更能解释未来风险。所以特征面板至少要按下面几个块去补特征块构造方式注意点自身历史案发量近 7 天、近 30 天案件数特征和标签窗口必须错开防止时间泄漏周边网格案发量取欧几里得距离 1 到 2 个网格内的案件总数半径太大会抹平风险差异太大会引入噪声案发结构案件类型计数如盗窃类、纠纷类、斗殴类类型字段缺失时可以先用全体计数替代时间切片月份、星期、是否节假日、是否夜间和值班表对齐后解释性好环境背景周边 POI 密度、道路密度、人口热力指数数据获取成本高可以放到第二阶段我自己动手时会先用“自身历史案发量 周边网格案发量 时间切片”三个块跑一版因为这三块几乎任何案件台账都能提供不需要外部数据接入。POI 和人口热力指数属于提高上限的增量如果所在单位能拿到标准化数据再往模型里加拿不到也不要卡在这一步。周边网格案发量的实现可以通过把 gx、gy 平移生成多个偏移副本再合并计数也可以直接用上面 samples 表里对每个网格求邻域。注意邻域计数同样要走“只统计日期早于当前样本日期”的过滤条件否则等于把未来案件当特征喂给了模型。3.2 基线模型选择为什么先用 LightGBM 而不是直接上深度模型治安案件预警的特征几乎全是表格型离散特征网格编号、星期、月份、历史计数、周边计数。这类数据的第一选择业界通常是用梯度提升树模型LightGBM 是其中最常用、也最容易把效果跑出来的一种原因有三对离散格点数据天然友好不需要像神经网络那样先做大规模 embedding支持类别权重和样本加权处理不平衡标签只需要一个参数训练速度快几百个特征、几十万样本的情况下普通台式机几分钟就能迭代一版。神经网络并非不能做我自己也见过有人用图神经网络把网格建模成空间图把相邻关系作为边上的消息传递实验效果确实比普通树模型高几个百分点。但代价是调参难度显著上升而且图模型对网格划分方式极其敏感——换个网格边长模型表现可能突然掉一截。对绝大多数预警场景LightGBM 做主力、神经网络做对照是更稳妥的组合。3.3 训练与评估用时间切分而不是随机切分治安案件数据有强时间习性直接用 sklearn 的 train_test_split 随机划分会埋一颗大雷同一时间段里特征和标签在训练集、测试集里都有分布模型能看到“同一个时期”的完整模式线上推理时面对未来数据却会模型漂移。正确做法是按时间切分例如用 2023 年全年训练用 2024 年第一季度做测试。from sklearn.model_selection import train_test_split import lightgbm as lgb # 先转成可排序的时间特征再严格按时间切分 data[ts] pd.to_datetime(data[date]).astype(int64) // 10**9 cutoff 2024-01-01 train data[pd.to_datetime(data[date]) cutoff] test data[pd.to_datetime(data[date]) cutoff] feature_cols [ gx, gy, recent_n_case, recent_n_days, month, dow, nearby_n_case ] y_train train[label] y_test test[label] clf lgb.LGBMClassifier( n_estimators600, learning_rate0.05, num_leaves31, class_weightbalanced, random_state42, verbose-1 ) clf.fit( train[feature_cols], y_train, eval_set[(test[feature_cols], y_test)], eval_metricauc, callbacks[lgb.early_stopping(50)] )这里 class_weightbalanced 会自动按样本比例放大少数类的损失避免模型全预测为 0。early_stopping 用测试集 AUC 控制迭代次数防止过拟合到训练期的短期模式上。num_leaves31 在多数网格数据上属于稳定起点大于 63 时模型容易把个别网格特有的历史节奏背下来泛化反而变差。评估阶段还要看一组业务口径选出测试集里每天风险分最高的前 K 个网格计算这些网格在未来 7 天内实际发案的比例。这比 AUC 更贴近“预警系统值多少钱”这个问题。AUC 高说明排序能力强但排在前面的网格是不是真发生了案件才是巡逻资源有没有被浪费的关键。4. 治安案件预警系统落地时最常见的 5 个坑现象、原因、处置4.1 随机划分指标极高上线效果却大幅缩水现象用 sklearn 默认随机划分训练测试集AUC 能做到 0.9 以上模型上线后命中率远低于测试表现甚至不如“直接报昨日案发网格”。原因案件数据在时间上自相关极强同一个时段出现在训练和测试里的概率高模型等于“开卷考试”。治安案件的季节性、节假日效应、集中整治行动带来的波动都会被随机划分打散模型根本没有见过真正连续的“未来”。处置一律改成按时间切分或者用后面会讲的滚动回测。凡是涉及预测类任务随机划分都不应该出现在代码里。4.2 正样本太少模型输出全是 0但“准确率还挺好看”现象高风险网格占比只有 8%模型把所有样本预测为 0准确率 92%看起来交差有余。原因训练目标与业务目标不一致。业务要的是“从 10000 个格子里挑出 200 个值得巡查的”模型默认在优化整体准确率于是选择保守。处置在模型层面加 class_weight在评估层面换 PR 曲线、F1、Top-K 命中率。具体到 LightGBM可以用 scale_pos_weight 参数代替 class_weight手动设成正负样本比的平方根附近再根据 PR 曲线调阈值。4.3 历史案发计数特征放大了“热点回音”模型永远报老地方现象某网格近 30 天发案多模型持续给它打高分即使这个网格近期已经被整治、案发清零模型仍沿袭历史惯性。原因近 30 天案发量本身是强特征但它既描述“长期热点”也描述“短期突发”。树模型分不清这两种语义容易把“最近发生过”直接等价成“未来还会发生”。处置把历史案发量拆成两个窗口比如近 7 天与近 60 天让模型自己去组合同时为案发量变体适当降权。更好的做法是给历史窗口加时间衰减权重越靠近当前日期权重越大但这需要自定义特征不是简单加一列参数能完成的。4.4 CSV 时间字段缺失或格式混杂样本数量少了一大截现象案件表中的 occur_time 有的是“2024-03-15 09:23”有的是“2024/3/15 9:23”还有几行直接是空值。pd.to_datetime 跑完后这几千行全部变成 NaT在 merge 时被静默丢弃。原因案件台账往往是多个系统拼接导出时间格式不一致几乎是必然事件。问题在于大多数人不会去看清洗后的行数变化样本少了 20% 还浑然不觉。处置写清洗脚本时强制校验三件事NaN 比例、时间范围是否落在预期区间、网格编号是否有越界值。清洗完成后打印一行“原始行数 / 清洗后行数 / 丢弃原因”只要丢弃率超过 5%就要回查源数据。4.5 坐标体系不一致网格在地图上整体偏移现象把模型的 gx、gy 还原成经纬度并叠加到底图上时预警网格整体偏移了几百米和真实案发位置对不上。模型本身可能没多大问题但图一画出来一线人员立刻质疑结果可信度。原因案件数据使用的坐标系和底图不一致比如原始经纬度是 GCJ-02 等偏移坐标而底图使用标准经纬度或者数据在导出时做了投影变换又没记录投影参数。处置处理坐标前先确认数据说明或元数据。最稳妥的办法是全程使用同一套坐标系训练、预测、出图统一如果只能拿到偏移坐标就先把底图也统一到同一套坐标上不要混用。网格编号用经纬度取整时还要注意经度方向的物理距离随纬度变化大范围区域建议先投影到平面坐标再做网格化。5. 把预警从“离线 demo”变“可信工具”滚动验证、阈值校准、模型刷新5.1 滚动回测我眼中最接近真实场景的“后悔药”单次时间切分只能验证一个固定时点治安案件存在周内波动、节假日变化、专项整治等阶段效应固定切分的结果会被某一段特殊时期带偏。更稳的做法是滚动回测从历史数据靠前位置开始每前进一个月就用截止到当月的全部数据训练一次预测下一个月然后平移窗口重复这个过程。这样得到的指标是跨多个时间段的平均表现模型是否稳定一目了然。def rolling_backtest(data, feature_cols, start, end, step_days30, horizon_days7): results [] cursor start while cursor end - pd.Timedelta(dayshorizon_days): train data[pd.to_datetime(data[date]) cursor] test data[ (pd.to_datetime(data[date]) cursor) (pd.to_datetime(data[date]) cursor pd.Timedelta(dayshorizon_days)) ] if train[label].sum() 20: cursor pd.Timedelta(daysstep_days) continue clf lgb.LGBMClassifier( n_estimators200, learning_rate0.05, num_leaves31, class_weightbalanced, verbose-1 ) clf.fit(train[feature_cols], train[label]) test test.copy() test[score] clf.predict_proba(test[feature_cols])[:, 1] results.append(test) cursor pd.Timedelta(daysstep_days) return pd.concat(results, ignore_indexTrue)滚动窗口的起点不要从数据集最早期开始最早 3 到 6 个月的数据应留作初始训练避免冷启动期特征不稳定。step_days 与 horizon_days 的关系值得解释一下horizon_days 是每次评估覆盖的未来天数step_days 是两次训练之间的间隔。step_days 大于 horizon_days 时验证集不重叠指标更保守step_days 小于 horizon_days 时相邻两次回测会重叠评估指标更平滑但结果之间存在相关性。滚动回测还有一个隐性的考验要定期重新训练。评估代码里循环每次都会重新 fit 模型这既模拟了线上更新频率也是检验“模型在新增数据后会不会退化”的最低成本手段。5.2 阈值校准0.5 不是默认答案风险分级才是模型输出的是“风险概率”一线人员真正需要的是“该不该去”和“多久去一次”。直接把概率按 0.5 切分大概率得到一个很少触发的预警系统因为高风险格子的概率普遍集中在 0.1 到 0.4 区间。正确做法是用验证集反推阈值线上可接受的风险数量分布再做分级。风险等级阈值分位建议响应动作低风险低于 70% 分位常态巡查不作额外部署中风险70% 到 90% 分位每日巡查一次重点观察高风险高于 90% 分位每日两次巡查纳入当日工作清单分位数的选择要以“每天预计产生多少条预警”为约束而不是机械地选 90%。如果全城网格有 5000 个90% 分位意味着每天 500 条预警远超处置能力可以先设为 98% 分位跑半个月看命中率再逐步下调到业务可承受的报警量。5.3 模型刷新策略增量训练还是周期重训治安案件数据的分布不是静止的。商业区迁移、新小区入住、地铁线路开通都会改变案发空间分布如果模型按月训练一次中间这些变化只能由历史特征自身去体现。常见的做法有两种每周全量重训数据量大时成本高但最稳健每日增量训练用前三周数据 当日数据继续训练成本低但容易在数据分布突变时反应不足。我更推荐折中模型主体每周重训一次历史特征窗口保持 30 天或 60 天不变这样模型既能看到较长的周维度规律又能吸收最近一周的变化。重训前一定要做一次特征分布对比比如近 7 天案发量均值相对训练集是否有明显偏移如果偏移超过 30%先排查采集链路和业务口径变化再决定是否直接把新数据喂给模型。数据分布突变时重训只会得到一个适应了新分布但可能忘记长期规律的新模型。6. 把风险分数翻译成排班单我常用的执行顺序预警系统最终要落到“今天谁去哪个格子、几点去、重点看什么”而不是停留在模型报告的 PPT 上。我自己在项目里形成了一套固定的执行顺序按这个顺序走模型、数据、一线同事三方都不容易产生误解。先拿到当日模型预测全量结果按分数排序取 90% 分位以上的网格作为候选再叠加一条硬规则过去 24 小时发生过案件且分数排在前 20% 的网格必须进入当日清单这是对突发事件的响应底线。然后做半小时人工复核逐个查看候选网格近 3 天的案发记录排除数据错误和极端历史值写入值班系统前还要确认排班表里没有已经覆盖同一区域的任务。模型给出的分数不要直接推送给一线而是转译成行动语言比如“该网格近一周夜间案发占比 60%建议 22 点到 2 点之间巡查”。同一个概率值在不同时段可以对应完全不同的部署建议这部分是我的经验迭代里最重要的一环。我自己的底线是永远保留人工复核入口系统输出任何高风险结论都必须能追溯到具体特征取值。这个“可追溯”的习惯帮我处理过好几起由数据口径变化引发的误报事故也让我在向同事解释模型行为时不再依赖“模型玄学”这个说法。希望这套从网格样本到分级排班的路径能帮你少走我踩过的那几个坑。本文还有配套的精品资源点击获取 基于机器学习的治安案件预警系统：从网格化建模到风险分级落地
简介基于机器学习的治安案件预警系统完整项目包面向毕业设计、课程设计及期末大作业等典型场景旨在帮助学习者快速搭建案件数据建模与预警展示流程。资源融合机器学习与深度学习技术涵盖前后端完整代码适合具备Java Web基础、希望完成同类课题的学生参考。包内共225个文件包含36个JS、32个CSS、22个HTML等前端页面以及15个Java类、30个class文件和3个SQL数据库脚本整体大小仅4.71MB。从内容预览可看出项目涵盖数据库操作、Servlet控制层和人员管理实体等典型模块目录结构清晰便于对照学习。目前已有37人学习下载通过SQL初始化数据库并结合前端页面可快速理解项目结构与算法应用流程是一份性价比高的实战参考资料。1. 基于机器学习的治安案件预警系统.zip打开之前先想明白的三件事拿到“基于机器学习的治安案件预警系统.zip”这个包第一眼就能判断出里面装的是一整个工程数据清洗脚本、特征构造模块、模型训练代码、预估模型文件加上一份说明文档。这个方向的价值并不在于让模型精确预言“某年某月某日某地会发生某案”而在于把过去只能靠经验拍板的“哪里风险高”变成可量化、可回溯、可验证的“风险面”让巡逻和布控资源向高概率区域倾斜。值得照着做下去的人有两种一种是手里握有历史案件数据、只差一套建模路径的在校研究者另一种是具备一定数据分析能力的基层安全岗位从业者想自行搭建能跑通、能解释、能迭代的预警原型而不是采购一个说不清依据的封闭黑匣子。下文我不会去复述压缩包里的目录清单只按我实际落地这类系统的顺序把样本构造、特征选择、模型训练、踩坑处理和效果验证讲透。2. 治安案件预警的建模逻辑预警不是猜单案而是给“风险面”打分2.1 先定分析粒度样本不是“一条案件”而是“一个时空格子”治安案件预警最容易在起步阶段翻车因为很多人直接把“每一条案件记录”当作一条训练样本然后试图让模型预测“下一个案件发生在哪”。这么做有个绕不过去的坎负样本从哪来案件确实没发生的位置和时间点在原始数据里根本不存在你无法为“没发生的事件”凭空造出对照记录。因此这类系统必须先把连续空间切成网格把连续时间切成天或半天再把“某个网格 × 某个日期”当作一个候选样本。建模目标随之变为在未来的预警窗口内这个时空格子里发生风险的可能性有多高。粒度怎么选直接影响模型能学到什么网格边长 500 米左右在城市尺度上既能覆盖街区单元又不至于把数据拆得过分稀疏时间步取 1 天便于和值班、排班、日报制度对齐预警窗口取未来 7 天一周的跨度既保证预测有提前量又不会让标签因为窗口过长而变得噪声太大。标签的形状也值得刻意设计。二分类“未来 7 天是否发案”是最简单的起步版本如果案件样本量足够可以进一步把未来案件数量映射成 0、1、2、3 四个风险等级让模型从“会不会发生”升级为“风险有多大”。等级化之后输出就不再是一个冷冰冰的概率而是可以直接对应到网格巡查频次的分档。2.2 把原始案件表变成监督学习样本一段可以抄走的构造脚本样本构造是整个项目的地基地基歪了后面所有模型提升都是白费。下面这份代码目标是把“案件流水表”改写成“网格 × 日期”的监督学习表并顺手生成三类基础特征网格坐标、时间因子、历史案发密度。import pandas as pd import numpy as np def build_risk_samples( cases: pd.DataFrame, grid_size: float 0.005, # 经纬度网格边长约500米 history_days: int 30, # 用于构造历史特征的窗口 future_days: int 7 # 预警窗口未来7天 ): # 1. 网格化把经纬度取整形成 gx, gy 网格编号 cases cases.copy() cases[gx] np.floor(cases[lng] / grid_size).astype(int) cases[gy] np.floor(cases[lat] / grid_size).astype(int) cases[date] pd.to_datetime(cases[occur_time]).dt.normalize() # 2. 每个网格每天的案发计数 daily ( cases.groupby([gx, gy, date], as_indexFalse) .size() .rename(columns{size: n_case}) ) # 3. 生成全量候选样本所有网格 × 所有日期 cells daily[[gx, gy]].drop_duplicates() dates pd.date_range( daily[date].min(), daily[date].max() - pd.Timedelta(daysfuture_days), freqD ) samples cells.assign(dummy1).merge( pd.DataFrame({date: dates}).assign(dummy1), ondummy ).drop(columnsdummy) # 4. 构造标签未来 future_days 天内该网格是否再次发案 future daily[[gx, gy, date, n_case]].rename( columns{date: case_date, n_case: future_cnt} ) merged samples.merge(future, on[gx, gy]) merged merged[ (merged[date] merged[case_date]) (merged[case_date] merged[date] pd.Timedelta(daysfuture_days)) ] label ( merged.groupby([gx, gy, date])[future_cnt] .sum() .reset_index() ) samples samples.merge(label, on[gx, gy, date], howleft) samples[future_cnt] samples[future_cnt].fillna(0) samples[label] (samples[future_cnt] 0).astype(int) # 5. 构造历史特征过去 history_days 天内该网格的案发情况 hist daily[[gx, gy, date, n_case]].rename( columns{date: case_date, n_case: hist_cnt} ) feat samples.merge(hist, on[gx, gy]) feat feat[ (feat[case_date] feat[date]) (feat[case_date] feat[date] - pd.Timedelta(dayshistory_days)) ] agg ( feat.groupby([gx, gy, date]) .agg( recent_n_case(hist_cnt, sum), recent_n_days(hist_cnt, count) ) .reset_index() ) samples samples.merge(agg, on[gx, gy, date], howleft) samples[recent_n_case] samples[recent_n_case].fillna(0) samples[recent_n_days] samples[recent_n_days].fillna(0) # 6. 时间因子月份与星期 dt pd.to_datetime(samples[date]) samples[month] dt.dt.month samples[dow] dt.dt.dayofweek return samples代码里的关键设计有两处。其一是标签的求法我没有直接把“当天发案”当标签而是把从当天到未来 7 天内的案件全部归并到当前样本这样模型学到的是“过去某状态对未来一周风险的影响”而不是“昨天发案所以明天也发案”的原地重复。其二是历史特征窗口独立于标签窗口history_days 负责描述过去状态future_days 负责定义预测目标两者一旦混用就会把未来信息偷偷漏进特征训练指标好看、上线立刻失真。参数上grid_size 使用经纬度时建议取 0.005 到 0.01对应纬度方向约 500 到 1000 米如果你的案件数据覆盖范围很大可先用整张表跑一遍网格计数把网格数控制在几千个以内避免全笛卡尔积把样本量撑爆。样本量级粗估500 个网格跑一年约产生 18 万条训练样本足够训练一个树模型但还不足以支撑特别深的神经网络。2.3 负样本处理不要把“多报”当成“错报”治安案件预警天然是类别不平衡问题高风险格子在所有样本里通常只占 5% 到 15%。模型如果只用准确率做指标完全可以把所有格子都预测为“无风险”拿一个 90% 的准确率交差。线上这么干的最直接后果是预警系统永远不报报了也是误报最后被一线直接弃用。更合理的做法是把评估指标重心放在精确率、召回率、PR 曲线、以及“预警点位命中率”这类业务指标上。比如每天选出全城风险分最高的前 20 个网格统计这些网格在未来 7 天里实际发生案件的比例这个命中率才是系统价值的分母。标签比例低不是模型缺陷它只是提醒你训练时要用类别权重评估时不要只看准确率阈值选择要放到后面单独调。3. 特征工程与基线模型先让系统跑通再谈精度提升3.1 特征面板把一个“格子”变成模型能消化的向量样本构造完成后表格里只有近 30 天案发量、活跃天数和时间因子这几列这远不足以支撑有效预警。治安风险的空间分布有明显“聚集效应”一个网格周边区域的历史案发情况往往比网格自身更能解释未来风险。所以特征面板至少要按下面几个块去补特征块构造方式注意点自身历史案发量近 7 天、近 30 天案件数特征和标签窗口必须错开防止时间泄漏周边网格案发量取欧几里得距离 1 到 2 个网格内的案件总数半径太大会抹平风险差异太大会引入噪声案发结构案件类型计数如盗窃类、纠纷类、斗殴类类型字段缺失时可以先用全体计数替代时间切片月份、星期、是否节假日、是否夜间和值班表对齐后解释性好环境背景周边 POI 密度、道路密度、人口热力指数数据获取成本高可以放到第二阶段我自己动手时会先用“自身历史案发量 周边网格案发量 时间切片”三个块跑一版因为这三块几乎任何案件台账都能提供不需要外部数据接入。POI 和人口热力指数属于提高上限的增量如果所在单位能拿到标准化数据再往模型里加拿不到也不要卡在这一步。周边网格案发量的实现可以通过把 gx、gy 平移生成多个偏移副本再合并计数也可以直接用上面 samples 表里对每个网格求邻域。注意邻域计数同样要走“只统计日期早于当前样本日期”的过滤条件否则等于把未来案件当特征喂给了模型。3.2 基线模型选择为什么先用 LightGBM 而不是直接上深度模型治安案件预警的特征几乎全是表格型离散特征网格编号、星期、月份、历史计数、周边计数。这类数据的第一选择业界通常是用梯度提升树模型LightGBM 是其中最常用、也最容易把效果跑出来的一种原因有三对离散格点数据天然友好不需要像神经网络那样先做大规模 embedding支持类别权重和样本加权处理不平衡标签只需要一个参数训练速度快几百个特征、几十万样本的情况下普通台式机几分钟就能迭代一版。神经网络并非不能做我自己也见过有人用图神经网络把网格建模成空间图把相邻关系作为边上的消息传递实验效果确实比普通树模型高几个百分点。但代价是调参难度显著上升而且图模型对网格划分方式极其敏感——换个网格边长模型表现可能突然掉一截。对绝大多数预警场景LightGBM 做主力、神经网络做对照是更稳妥的组合。3.3 训练与评估用时间切分而不是随机切分治安案件数据有强时间习性直接用 sklearn 的 train_test_split 随机划分会埋一颗大雷同一时间段里特征和标签在训练集、测试集里都有分布模型能看到“同一个时期”的完整模式线上推理时面对未来数据却会模型漂移。正确做法是按时间切分例如用 2023 年全年训练用 2024 年第一季度做测试。from sklearn.model_selection import train_test_split import lightgbm as lgb # 先转成可排序的时间特征再严格按时间切分 data[ts] pd.to_datetime(data[date]).astype(int64) // 10**9 cutoff 2024-01-01 train data[pd.to_datetime(data[date]) cutoff] test data[pd.to_datetime(data[date]) cutoff] feature_cols [ gx, gy, recent_n_case, recent_n_days, month, dow, nearby_n_case ] y_train train[label] y_test test[label] clf lgb.LGBMClassifier( n_estimators600, learning_rate0.05, num_leaves31, class_weightbalanced, random_state42, verbose-1 ) clf.fit( train[feature_cols], y_train, eval_set[(test[feature_cols], y_test)], eval_metricauc, callbacks[lgb.early_stopping(50)] )这里 class_weightbalanced 会自动按样本比例放大少数类的损失避免模型全预测为 0。early_stopping 用测试集 AUC 控制迭代次数防止过拟合到训练期的短期模式上。num_leaves31 在多数网格数据上属于稳定起点大于 63 时模型容易把个别网格特有的历史节奏背下来泛化反而变差。评估阶段还要看一组业务口径选出测试集里每天风险分最高的前 K 个网格计算这些网格在未来 7 天内实际发案的比例。这比 AUC 更贴近“预警系统值多少钱”这个问题。AUC 高说明排序能力强但排在前面的网格是不是真发生了案件才是巡逻资源有没有被浪费的关键。4. 治安案件预警系统落地时最常见的 5 个坑现象、原因、处置4.1 随机划分指标极高上线效果却大幅缩水现象用 sklearn 默认随机划分训练测试集AUC 能做到 0.9 以上模型上线后命中率远低于测试表现甚至不如“直接报昨日案发网格”。原因案件数据在时间上自相关极强同一个时段出现在训练和测试里的概率高模型等于“开卷考试”。治安案件的季节性、节假日效应、集中整治行动带来的波动都会被随机划分打散模型根本没有见过真正连续的“未来”。处置一律改成按时间切分或者用后面会讲的滚动回测。凡是涉及预测类任务随机划分都不应该出现在代码里。4.2 正样本太少模型输出全是 0但“准确率还挺好看”现象高风险网格占比只有 8%模型把所有样本预测为 0准确率 92%看起来交差有余。原因训练目标与业务目标不一致。业务要的是“从 10000 个格子里挑出 200 个值得巡查的”模型默认在优化整体准确率于是选择保守。处置在模型层面加 class_weight在评估层面换 PR 曲线、F1、Top-K 命中率。具体到 LightGBM可以用 scale_pos_weight 参数代替 class_weight手动设成正负样本比的平方根附近再根据 PR 曲线调阈值。4.3 历史案发计数特征放大了“热点回音”模型永远报老地方现象某网格近 30 天发案多模型持续给它打高分即使这个网格近期已经被整治、案发清零模型仍沿袭历史惯性。原因近 30 天案发量本身是强特征但它既描述“长期热点”也描述“短期突发”。树模型分不清这两种语义容易把“最近发生过”直接等价成“未来还会发生”。处置把历史案发量拆成两个窗口比如近 7 天与近 60 天让模型自己去组合同时为案发量变体适当降权。更好的做法是给历史窗口加时间衰减权重越靠近当前日期权重越大但这需要自定义特征不是简单加一列参数能完成的。4.4 CSV 时间字段缺失或格式混杂样本数量少了一大截现象案件表中的 occur_time 有的是“2024-03-15 09:23”有的是“2024/3/15 9:23”还有几行直接是空值。pd.to_datetime 跑完后这几千行全部变成 NaT在 merge 时被静默丢弃。原因案件台账往往是多个系统拼接导出时间格式不一致几乎是必然事件。问题在于大多数人不会去看清洗后的行数变化样本少了 20% 还浑然不觉。处置写清洗脚本时强制校验三件事NaN 比例、时间范围是否落在预期区间、网格编号是否有越界值。清洗完成后打印一行“原始行数 / 清洗后行数 / 丢弃原因”只要丢弃率超过 5%就要回查源数据。4.5 坐标体系不一致网格在地图上整体偏移现象把模型的 gx、gy 还原成经纬度并叠加到底图上时预警网格整体偏移了几百米和真实案发位置对不上。模型本身可能没多大问题但图一画出来一线人员立刻质疑结果可信度。原因案件数据使用的坐标系和底图不一致比如原始经纬度是 GCJ-02 等偏移坐标而底图使用标准经纬度或者数据在导出时做了投影变换又没记录投影参数。处置处理坐标前先确认数据说明或元数据。最稳妥的办法是全程使用同一套坐标系训练、预测、出图统一如果只能拿到偏移坐标就先把底图也统一到同一套坐标上不要混用。网格编号用经纬度取整时还要注意经度方向的物理距离随纬度变化大范围区域建议先投影到平面坐标再做网格化。5. 把预警从“离线 demo”变“可信工具”滚动验证、阈值校准、模型刷新5.1 滚动回测我眼中最接近真实场景的“后悔药”单次时间切分只能验证一个固定时点治安案件存在周内波动、节假日变化、专项整治等阶段效应固定切分的结果会被某一段特殊时期带偏。更稳的做法是滚动回测从历史数据靠前位置开始每前进一个月就用截止到当月的全部数据训练一次预测下一个月然后平移窗口重复这个过程。这样得到的指标是跨多个时间段的平均表现模型是否稳定一目了然。def rolling_backtest(data, feature_cols, start, end, step_days30, horizon_days7): results [] cursor start while cursor end - pd.Timedelta(dayshorizon_days): train data[pd.to_datetime(data[date]) cursor] test data[ (pd.to_datetime(data[date]) cursor) (pd.to_datetime(data[date]) cursor pd.Timedelta(dayshorizon_days)) ] if train[label].sum() 20: cursor pd.Timedelta(daysstep_days) continue clf lgb.LGBMClassifier( n_estimators200, learning_rate0.05, num_leaves31, class_weightbalanced, verbose-1 ) clf.fit(train[feature_cols], train[label]) test test.copy() test[score] clf.predict_proba(test[feature_cols])[:, 1] results.append(test) cursor pd.Timedelta(daysstep_days) return pd.concat(results, ignore_indexTrue)滚动窗口的起点不要从数据集最早期开始最早 3 到 6 个月的数据应留作初始训练避免冷启动期特征不稳定。step_days 与 horizon_days 的关系值得解释一下horizon_days 是每次评估覆盖的未来天数step_days 是两次训练之间的间隔。step_days 大于 horizon_days 时验证集不重叠指标更保守step_days 小于 horizon_days 时相邻两次回测会重叠评估指标更平滑但结果之间存在相关性。滚动回测还有一个隐性的考验要定期重新训练。评估代码里循环每次都会重新 fit 模型这既模拟了线上更新频率也是检验“模型在新增数据后会不会退化”的最低成本手段。5.2 阈值校准0.5 不是默认答案风险分级才是模型输出的是“风险概率”一线人员真正需要的是“该不该去”和“多久去一次”。直接把概率按 0.5 切分大概率得到一个很少触发的预警系统因为高风险格子的概率普遍集中在 0.1 到 0.4 区间。正确做法是用验证集反推阈值线上可接受的风险数量分布再做分级。风险等级阈值分位建议响应动作低风险低于 70% 分位常态巡查不作额外部署中风险70% 到 90% 分位每日巡查一次重点观察高风险高于 90% 分位每日两次巡查纳入当日工作清单分位数的选择要以“每天预计产生多少条预警”为约束而不是机械地选 90%。如果全城网格有 5000 个90% 分位意味着每天 500 条预警远超处置能力可以先设为 98% 分位跑半个月看命中率再逐步下调到业务可承受的报警量。5.3 模型刷新策略增量训练还是周期重训治安案件数据的分布不是静止的。商业区迁移、新小区入住、地铁线路开通都会改变案发空间分布如果模型按月训练一次中间这些变化只能由历史特征自身去体现。常见的做法有两种每周全量重训数据量大时成本高但最稳健每日增量训练用前三周数据 当日数据继续训练成本低但容易在数据分布突变时反应不足。我更推荐折中模型主体每周重训一次历史特征窗口保持 30 天或 60 天不变这样模型既能看到较长的周维度规律又能吸收最近一周的变化。重训前一定要做一次特征分布对比比如近 7 天案发量均值相对训练集是否有明显偏移如果偏移超过 30%先排查采集链路和业务口径变化再决定是否直接把新数据喂给模型。数据分布突变时重训只会得到一个适应了新分布但可能忘记长期规律的新模型。6. 把风险分数翻译成排班单我常用的执行顺序预警系统最终要落到“今天谁去哪个格子、几点去、重点看什么”而不是停留在模型报告的 PPT 上。我自己在项目里形成了一套固定的执行顺序按这个顺序走模型、数据、一线同事三方都不容易产生误解。先拿到当日模型预测全量结果按分数排序取 90% 分位以上的网格作为候选再叠加一条硬规则过去 24 小时发生过案件且分数排在前 20% 的网格必须进入当日清单这是对突发事件的响应底线。然后做半小时人工复核逐个查看候选网格近 3 天的案发记录排除数据错误和极端历史值写入值班系统前还要确认排班表里没有已经覆盖同一区域的任务。模型给出的分数不要直接推送给一线而是转译成行动语言比如“该网格近一周夜间案发占比 60%建议 22 点到 2 点之间巡查”。同一个概率值在不同时段可以对应完全不同的部署建议这部分是我的经验迭代里最重要的一环。我自己的底线是永远保留人工复核入口系统输出任何高风险结论都必须能追溯到具体特征取值。这个“可追溯”的习惯帮我处理过好几起由数据口径变化引发的误报事故也让我在向同事解释模型行为时不再依赖“模型玄学”这个说法。希望这套从网格样本到分级排班的路径能帮你少走我踩过的那几个坑。本文还有配套的精品资源点击获取