纽约 311 赛题聚焦的是市政工单关闭天数预测，表面上属于结构化数据回归，实际更接近公共服务运营分析中的时效建模问题。工单类别、区域差异、创建时间与历史处理效率都会共同影响结案周期，这使得赛题天然具备业务解释空间，也非常适合作为数据分析与机器学习落地练习。
相比只关注排行榜分数，这类任务更值得研究的是目标定义是否清晰、时间标签是否可靠、异常长尾样本如何处理，以及验证方式能否贴近真实服务场景。围绕纽约 311 数据建立预测流程，本质上是在训练一套面向工单系统、SLA 管理和资源调度的建模思路。
文章目录
赛题概述
本案例地址 Predict New York 311 Response Times。
这是一道典型的城市公共服务时效预测问题，核心任务是根据 311 市政服务请求相关信息，预测一条工单从提交到关闭需要多少天。题目本质属于结构化数据回归建模，但价值不止于刷分，它对应的是政府热线、工单平台和城市治理系统中的资源调度与服务承诺管理。练习过程中会覆盖目标定义、时长型标签处理、特征工程、异常样本识别、回归评估与结果解释，适合作为从数据分析走向真实业务预测建模的入门案例。
| 模块名称 | 内容简介 | 所需技能 | 数据类型 | 应用场景 |
|---|---|---|---|---|
| 赛题背景 | 赛题围绕纽约 311 公共服务请求展开，本质是对市政协同处理链路中的结案周期进行预测。相比单纯学术数据集，这类问题带有明显业务约束，既受工单类别、区域差异、历史处理效率影响，也反映公共服务流程中的资源紧张、优先级分配与治理效率。 | 业务问题抽象、回归任务建模、时效目标理解、异常值识别、面向公共服务的特征设计、结果解释 | 结构化工单数据、时间字段、地理区域信息、服务类别信息、历史处理结果 | 公共服务数字化、城市治理分析、市政热线工单系统、服务时效预估与运营监控 |
| 竞赛目标 | 需要构建一个能够输出结案天数预测值的模型，用于估计不同 311 请求的处理时长。交付物虽然表现为提交预测结果，但实际对应的是一套可用于工单分流、超时预警和服务能力评估的预测方案，而不只是单次离线建模结果。 | 监督学习建模、特征工程、时间差标签构造、回归模型选择、验证集设计、预测结果校准 | 历史请求记录、关闭时长标签、类别变量、时间变量、可能的空间位置与上下文属性 | 工单处理时长预测、服务承诺管理、资源调度辅助、运营排班优化 |
| 评价指标 | 竞赛采用均方根误差作为核心评价方式，重点考察预测时长与真实时长之间的偏差控制能力。该指标对较大误差更敏感，意味着模型不能只在常规样本上表现稳定，还要尽量降低极慢工单或异常处理周期带来的失真。 | 回归指标理解、误差分析、长尾样本处理、模型稳健性优化、交叉验证与调参 | 数值型预测结果、真实关闭天数、误差分布、残差分析样本 | 回归模型评估、服务时长预测质检、风险工单识别、预测稳定性分析 |
| 业务意义 | 这类任务在真实项目中可直接服务于公共部门和大型客服平台，将历史工单数据转化为可操作的时效预测能力。预测结果能够支撑 SLA 管理、投诉高峰期预警、跨区域资源配置和流程瓶颈诊断，也适合作为学习如何把结构化机器学习模型嵌入业务系统的实践样板。 | 从数据到策略的转化能力、模型落地思维、运营分析、可解释性表达、工程整合与监控意识 | 业务报表、预测分数、工单流转记录、服务水平数据、自建验证样本 | 公共服务数字化、政务运营优化、企业客服工单管理、流程效率提升项目 |
数据详解
这场竞赛的数据结构相对简洁，真正值得关注的信息集中在任务定义、评估方式、时间约束、提交限制和数据获取入口几个部分。赛题核心是基于历史 311 工单信息，预测纽约市关闭请求所需的天数，因此它本质上是一个典型的监督式回归问题。标签信息里只出现了 RMSE，说明竞赛评价关注预测值与真实关闭时长之间的数值误差，且平方项会放大大偏差样本的影响，这会直接影响特征工程、异常值处理和模型选择。结构化字段中还混入了不少平台管理属性，例如论坛 ID、组织 ID、是否启用某类提交机制、排行榜开关等，这些内容对建模帮助有限，阅读时不必平均分配精力。更值得重视的是比赛标题与简介对目标变量的定义、数据集下载地址与体量对本地实验方式的影响，以及每日提交次数、组队上限、开放时间等对项目推进节奏的约束。需要注意的是，当前元数据里并没有给出训练集字段清单、目标列名或文件级说明，这意味着真正进入建模前，仍需打开数据文件核实样本粒度、标签生成方式、时间字段格式以及是否存在明显的数据泄漏风险。
| 字段名称 | 类型/范围 | 描述信息 |
|---|---|---|
| competition_title | 字符串 | 赛题标题为 Predict New York 311 Response Times，直接定义了业务目标：预测纽约 311 请求的响应或关闭耗时。对于任务理解，这个字段决定了问题不是分类，而是连续数值预测。 |
| competition_subtitle | 字符串/空值 | 当前为空，说明没有额外的官方补充口号或任务限定。阅读时不能指望副标题提供目标范围、样本边界或特殊限制，需要更多依赖简介和数据文件本身。 |
| overview | 字符串 | 比赛简介明确写出需要预测"纽约关闭 311 请求所需的天数"。这条信息比标题更具体，直接提示目标变量应是一个以"天"为单位的连续值，也意味着时间处理和工单生命周期理解会成为建模关键。 |
| tags | JSON 数组 | 当前标签只包含 RMSE。标签数量很少，说明平台没有提供更多主题性引导，任务解读主要依赖赛题文本和数据本身。RMSE 标签同时提醒这是数值回归场景，且模型需要尽量控制大误差样本。 |
| evaluation_algorithm_name | 字符串 | 评价指标为 Root Mean Squared Error，即均方根误差。这个字段决定了模型优化方向：预测偏差越小越好，尤其要注意极端错误会被放大，因此简单均值预测通常难以取得好成绩。 |
| evaluation_algorithm_abbreviation | 字符串 | 指标缩写为 RMSE。在阅读代码、提交结果和实验记录时，通常以该缩写出现，是竞赛实验管理中的核心指标标识。 |
| enabled_date | 时间 | 比赛开放时间。对长期开放或练习型竞赛，这个字段的实际业务意义不如数据和指标重要，但可用于判断竞赛所处时期，以及是否可能存在较老的数据格式或旧版基线方案。 |
| deadline_date | 时间 | 报名截止时间显示为极晚日期，基本可视为长期开放。这意味着竞赛更像练习题或持续可参与项目，适合用于完整走一遍数据分析、特征工程和回归建模流程。 |
| team_merger_deadline_date | 时间 | 队伍合并截止时间同样设置得很靠后，表明组队管理不是核心限制。对个人学习者而言，这类字段只需确认比赛允许协作即可，无需投入过多注意力。 |
| max_daily_submissions | 整数 | 每日最多提交 20 次。这个限制会影响实验节奏，要求离线验证尽量可靠，避免把 Kaggle 提交当成主要调参手段。真实项目中也对应"线上试错成本有限"的常见场景。 |
| max_team_size | 整数 | 最大组队人数为 20。对学习型参与者而言，这个字段更多反映协作空间，而不是建模难点本身。对于多人协作项目，可据此安排特征、建模、验证和文档分工。 |
| reward_type | 字符串/空值 | 奖励类型为空，说明比赛不以奖金驱动。该信息有助于判断竞赛定位更偏练习、教学或社区共享，而非高强度奖金竞争。 |
| reward_quantity | 数值/空值 | 奖金数额为空，进一步说明不需要从奖金机制角度解读赛题热度或竞争强度，关注重点应放在任务本身的业务建模价值。 |
| num_prizes | 整数/空值 | 奖项数量为空，和无奖金信息一致。对技术分析影响不大，可视为平台展示信息，而非数据理解重点。 |
| dataset_url | 字符串（URL） | 数据集下载入口。这个字段是真正进入分析阶段的起点，所有训练集、测试集和样本提交文件通常都从这里获取。对于复现实验流程，它比多数平台元数据更重要。 |
| dataset_description | 字符串/空值 | 数据集说明为空，意味着平台元数据没有提前给出字段级解释、文件结构或数据来源背景。实际工作中需要自行检查文件名、列名、缺失值和时间字段格式，补齐数据字典。 |
| total_compressed_bytes | 整数 | 压缩后数据大小约 2.64 MB，说明数据规模不大，适合在本地快速完成探索、特征试验和多模型对比，不需要复杂的分布式计算环境。 |
| total_uncompressed_bytes | 整数 | 解压后大小与压缩后基本一致，也说明原始文件体量很轻。对于学习者，这意味着可以把精力放在业务理解和特征构造，而不是数据存储与算力问题。 |
| case_url | 字符串（URL） | 竞赛主页入口。用于查看官方说明、提交页面和可能的补充内容。在元数据不完整、字段解释缺失的情况下，这个入口往往是确认规则和文件结构的必要来源。 |
| 数据文件说明 | 结构未知，通常为多个表格文件 | 当前结构化元数据未给出训练集、测试集、样本提交文件名，也没有列级清单。这意味着最关键的数据文件信息仍需到下载页核实，尤其要确认是否存在 train/test/sample_submission 这类标准竞赛文件。 |
| 目标标签字段 | 未直接提供 | 元数据只说明目标是预测关闭请求所需天数，但没有给出目标列名。建模前必须在训练数据中确认标签字段的实际列名、单位、是否经过预处理，以及标签是否由多个时间字段计算得到。 |
| 平台管理与内部控制信息 | 多个布尔值、ID、空字段 | 论坛 ID、组织 ID、是否支持 Notebook、是否启用某种模型提交机制、排行榜控制字段等内容对任务理解和模型设计帮助有限。这类信息可以统一视为平台运行元数据，阅读时应降低优先级。 |
解题思路
这类赛题表面上是一个典型的监督学习预测任务，核心目标是根据历史 311 工单信息估计结案耗时，实质上却适合多条建模路线并行推进。原因在于，311 场景通常同时包含结构化字段、时间信息、地理信息以及可能存在的文本描述，目标值又是连续变量，评价指标采用 RMSE，这使得问题既可以用统计建模和树模型处理非线性关系，也可以在存在文本字段时引入文本表示学习方法补充语义信息。从实战角度看，不同方法的价值并不只体现在排行榜分数上，还体现在对业务解释性、部署成本、训练资源和特征工程投入的平衡。若文本较短、标签并非多标签分类而是数值回归，线性文本模型往往是稳健基线；若文本描述承载了大量案件上下文，深度学习和预训练模型会更有发挥空间；若结构化特征远比文本更强，融合方案通常比单一路线更接近真实生产环境中的最佳实践。
| 方法标题 | 案例适配度 | 方法说明 | 操作流程 | 优点 | 缺点 |
|---|---|---|---|---|---|
| 规则统计特征 + 线性回归/岭回归基线 | 72% | 以工单创建时间、投诉类别、行政区、是否节假日、历史类别平均结案时长等规则与统计特征为核心，构建可解释的回归基线方案。适合快速理解数据分布与业务规律。 | 清洗异常值与缺失值，构造时间周期特征与类别聚合统计特征，做数值标准化或类别编码，训练线性回归或岭回归，按验证集 RMSE 调整特征组合。 | 可解释性强，适合建立业务认知；训练速度快，适合做首个可用版本；对于小体量数据和稳定字段通常有不错表现。 | 对复杂非线性关系拟合能力有限；若文本描述或空间信息贡献较大，单靠统计特征容易欠拟合；对高基数类别的表达能力偏弱。 |
| 类别编码 + GBDT/随机森林/XGBoost 结构化建模 | 88% | 将任务视为典型表格回归问题，重点利用类别字段、时间字段和区域字段，通过树模型捕捉非线性关系与特征交互。对于 311 结案时长预测，这类方法通常是结构化数据中的主力方案。 | 完成缺失处理与目标异常分析，构造时间与区域特征，采用频次编码、目标编码或标签编码处理类别变量，训练 LightGBM、XGBoost 或随机森林，使用交叉验证控制过拟合。 | 对表格数据适应性强，能自动学习复杂交互；对缺失值和非线性关系较稳健；通常比纯线性基线有明显提升。 | 目标编码若处理不当容易泄漏；对文本原始语义利用有限；模型解释性弱于线性方案，特征贡献需要借助 SHAP 等工具分析。 |
| TF-IDF 文本特征 + 线性回归/线性支持向量回归 | 64% | 若数据中包含投诉标题、描述或备注字段，可将文本转为 TF-IDF 稀疏向量，再用线性回归或线性支持向量回归预测结案时长。这是文本回归任务中常见且稳定的传统路线。 | 提取并清洗文本字段，分词或采用 n-gram 向量化，生成 TF-IDF 特征，与基础数值特征拼接，训练线性回归、岭回归或线性 SVR，依据验证集选择词表与正则化强度。 | 对短文本和中小数据集较友好；实现难度低，适合学习文本建模入门；在文本信息较直接反映案件复杂度时能提供有效增益。 | 只能表达词频层面的浅层语义；对同义表达和上下文关系刻画不足；若文本字段噪声大或极短，提升空间有限。 |
| 词向量表示 + 传统回归模型 | 58% | 使用 Word2Vec、FastText 或平均词向量将文本压缩为稠密表示，再结合结构化特征输入到回归模型中，适合作为从传统文本特征过渡到深度学习前的中间路线。 | 训练或加载预训练词向量，对每条文本做平均池化或加权池化，拼接类别编码与时间特征，训练岭回归、SVR 或 GBDT，并用交叉验证比较不同文本表示方式。 | 比 TF-IDF 更紧凑，特征维度低；对词汇稀疏问题更友好；便于与结构化特征联合建模。 | 对句序和长距离语义无建模能力；平均池化会损失关键信息；在任务数据量不大且文本不长时，未必优于 TF-IDF 基线。 |
| CNN/RNN 文本回归模型 + 结构化特征拼接 | 55% | 当文本描述较完整、包含案件复杂程度、地点细节或处理难度线索时，可用 CNN 提取局部模式，或用 LSTM/GRU 建模时序语义，再与结构化特征融合进行回归预测。 | 对文本做分词与序列化，构建词嵌入层，使用 TextCNN 或 BiLSTM 提取文本表示，与数值和类别嵌入特征拼接，训练回归网络，并以 RMSE 监控验证效果。 | 能学习比传统词袋更丰富的上下文模式；适合进阶练习深度学习文本建模；在文本信息量较大时可能优于传统方法。 | 对数据规模和训练调参更敏感；训练成本高于传统机器学习；若文本字段较短或噪声大，模型复杂度可能无法转化为分数提升。 |
| Transformer 预训练模型做文本回归 | 50% | 若工单文本包含较强语义线索，可将 BERT、RoBERTa 一类预训练语言模型用于回归任务，直接预测结案天数，或输出文本向量后与结构化特征融合。 | 构造文本输入与目标值，选择预训练模型并添加回归头，微调训练；若存在结构化字段，可在 Transformer 输出层后拼接表格特征，使用分层验证评估 RMSE。 | 对复杂语义理解能力最强；适合处理含上下文、缩写、投诉细节的文本；是检验高阶文本建模能力的代表方案。 | 对算力和训练技巧要求高；在小数据集上容易过拟合；若赛题主要信号来自结构化字段，投入产出比可能不高。 |
| 结构化模型与文本模型融合 | 92% | 将树模型学习到的结构化模式与文本模型提取的语义信息结合，通过加权平均、Stacking 或二层回归器输出最终预测。这类方案更贴近真实业务中的多源信息集成。 | 分别训练表格回归模型与文本回归模型，保留交叉验证预测结果，按验证集表现设定权重或训练二层融合器，输出最终预测并检查误差分布。 | 通常能获得比单模型更稳定的效果；能同时利用业务属性和文本语义；非常符合工单类场景在生产系统中的建模方式。 | 实现复杂度明显提高；需要严格控制交叉验证避免信息泄漏；当单模型差异不明显时，融合收益可能有限。 |
| 对数变换目标 + 模型融合 + 误差校准 | 90% | 311 结案时长往往右偏分布明显，少量超长工单会放大 RMSE。通过对目标值做对数变换、对异常预测做截断或校准，再结合多模型融合，可显著改善整体误差表现。 | 分析目标分布并做对数变换，分别训练线性模型、树模型与文本模型，反变换后进行加权融合，对极端预测值做业务合理范围校准，依据 RMSE 持续迭代。 | 直接围绕 RMSE 优化，适合处理长尾回归目标；对真实工单时长预测很有业务意义；能将基线、进阶模型和工程经验整合到同一框架。 | 依赖较完整的验证设计；误差校准若过度手工化，泛化风险会上升；方案适合有一定经验后再使用，不适合作为入门起点。 |
操作案例
基础流程样例
尽管竞赛元数据中的标题与简介更像是一个回归任务，但当前写作要求明确指定为"多标签文本分类任务"，因此操作案例采用教学中常见的多标签文本建模范式来组织。这样的写法适合技术博客中的方法演示：把问题抽象为"根据工单文本内容，同时预测多个业务标签"，对应真实业务中的场景包括 311 市政热线诉求自动分派、投诉主题识别、责任部门预判与优先级辅助判断。基础版本选择 TF-IDF + OneVsRestClassifier + LogisticRegression 作为主线，原因在于这套方案依赖少、可解释性较强、适合快速建立可运行基线，也方便后续平滑升级到更复杂的文本表示与模型结构。
读取数据并确认任务结构
教学示例的起点不是直接建模，而是确认数据文件、文本字段、标签字段以及样本分布是否符合多标签任务的基本假设。对于类似 311 工单的数据，原始表通常会包含标题、描述、类别、部门、渠道、区域等字段，其中可用于建模的核心输入往往是文本字段，而输出则可能是一组可以同时成立的标签。下面的代码假设训练集 train.csv 至少包含一个文本列与若干个二值标签列；如果真实字段名不同，只需替换变量即可复用整套流程。
python
import os
import re
import numpy as np
import pandas as pd
from sklearn.model_selection import train_test_split
from sklearn.pipeline import Pipeline
from sklearn.multiclass import OneVsRestClassifier
from sklearn.linear_model import LogisticRegression
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.metrics import roc_auc_score
# Kaggle 数据目录示例
DATA_DIR = "./data"
train_path = os.path.join(DATA_DIR, "train.csv")
test_path = os.path.join(DATA_DIR, "test.csv")
train_df = pd.read_csv(train_path)
test_df = pd.read_csv(test_path)
print("训练集形状:", train_df.shape)
print("测试集形状:", test_df.shape)
print("\n训练集字段:")
print(train_df.columns.tolist())
print("\n训练集前5行:")
print(train_df.head())
# ====== 根据实际数据修改以下字段名 ======
# 假设存在两个文本字段：title 和 description
# 假设以下列为多标签二值列
TEXT_COLUMNS = ["title", "description"]
TARGET_COLUMNS = ["label_noise", "label_heat", "label_water", "label_street"]
# 检查字段是否存在
missing_text_cols = [c for c in TEXT_COLUMNS if c not in train_df.columns]
missing_target_cols = [c for c in TARGET_COLUMNS if c not in train_df.columns]
if missing_text_cols:
raise ValueError(f"缺少文本字段: {missing_text_cols}")
if missing_target_cols:
raise ValueError(f"缺少标签字段: {missing_target_cols}")
print("\n标签列示例统计:")
print(train_df[TARGET_COLUMNS].sum().sort_values(ascending=False))
# 查看每条样本命中的标签数量，确认是否真的是多标签结构
label_count_per_sample = train_df[TARGET_COLUMNS].sum(axis=1)
print("\n每条样本标签数量分布:")
print(label_count_per_sample.value_counts().sort_index())查看标签结构并构造建模输入
多标签文本任务中，标签结构的理解比单标签分类更重要。原因在于同一条工单可能同时涉及噪音、道路、积水、照明等多个问题，标签之间存在共现关系，直接决定模型评价方式与预测输出格式。输入端也不应只保留单一字段，业务标题与详细描述往往共同决定语义边界，因此基础样例采用文本拼接方式形成统一输入，既简单又实用。
python
def safe_text_concat(df, text_cols):
"""将多个文本列拼接为一个统一输入字段"""
text_series = []
for col in text_cols:
s = df[col].fillna("").astype(str)
text_series.append(s)
combined = text_series[0]
for s in text_series[1:]:
combined = combined + " " + s
return combined
train_df["text"] = safe_text_concat(train_df, TEXT_COLUMNS)
test_df["text"] = safe_text_concat(test_df, TEXT_COLUMNS)
X = train_df["text"]
Y = train_df[TARGET_COLUMNS].astype(int)
print("建模输入示例:")
print(X.head(3).tolist())
print("\n标签矩阵形状:", Y.shape)
print("标签名:", TARGET_COLUMNS)
# 查看标签共现情况
co_occurrence = Y.T.dot(Y)
print("\n标签共现矩阵:")
print(pd.DataFrame(co_occurrence, index=TARGET_COLUMNS, columns=TARGET_COLUMNS))文本预处理
文本预处理的目标不是追求复杂，而是把原始工单中的噪声先压下来。311 类文本通常包含大小写混杂、标点、编号、地址缩写、重复空格，甚至夹杂工单系统产生的模板语句。基础版本只做轻量清洗，保留足够的信息供 TF-IDF 提取词项特征，同时避免过度规则化造成语义损失。对于教学文章来说，这种处理方式更利于展示"先跑通，再迭代"的实践思路。
python
def clean_text(text):
text = str(text).lower()
text = re.sub(r"\n|\r|\t", " ", text)
text = re.sub(r"[^a-z0-9\s]", " ", text) # 仅保留字母、数字和空格
text = re.sub(r"\s+", " ", text).strip()
return text
X_clean = X.apply(clean_text)
test_df["text_clean"] = test_df["text"].apply(clean_text)
print("清洗后文本示例:")
for i in range(3):
print(f"[{i}] {X_clean.iloc[i][:200]}")训练集与验证集划分
在多标签任务中，验证集不能省略，因为仅凭训练集拟合结果无法判断不同标签上的泛化能力。真实业务里，模型经常出现"头部标签效果很好、长尾标签几乎失效"的情况，因此需要保留一部分数据进行离线评估。基础案例使用随机划分作为教学方案，适合快速建立基线；如果数据规模较大或标签极不均衡，后续可升级为迭代分层抽样等更稳妥的切分方式。
python
X_train, X_valid, y_train, y_valid = train_test_split(
X_clean,
Y,
test_size=0.2,
random_state=42
)
print("训练集大小:", X_train.shape[0])
print("验证集大小:", X_valid.shape[0])
print("\n训练集标签均值:")
print(y_train.mean().sort_values(ascending=False))
print("\n验证集标签均值:")
print(y_valid.mean().sort_values(ascending=False))基础建模
入门版模型强调稳定、透明、便于解释。TfidfVectorizer 负责把文本转换为稀疏词项特征，适合处理工单短文本与中短描述；OneVsRestClassifier 把多标签任务拆成多个独立二分类器；LogisticRegression 输出概率稳定，适合后续按标签计算 AUC，也利于根据业务阈值做策略调整。这套组合在许多文本基线任务中都能得到足够可靠的首版结果。
python
from sklearn.exceptions import UndefinedMetricWarning
import warnings
warnings.filterwarnings("ignore", category=UndefinedMetricWarning)
model = Pipeline([
("tfidf", TfidfVectorizer(
max_features=30000,
ngram_range=(1, 2),
min_df=3,
max_df=0.95,
sublinear_tf=True
)),
("clf", OneVsRestClassifier(
LogisticRegression(
solver="liblinear",
max_iter=1000,
class_weight="balanced"
)
))
])
model.fit(X_train, y_train)
print("基础模型训练完成。")预测与评估
多标签分类的评估不能只看单一准确率，因为每一列标签都对应一个独立判断任务，且标签分布往往高度不均衡。基础样例采用按列计算 ROC AUC，再取宏平均分数，适合观察模型在不同标签上的区分能力。如果某些验证折中某个标签全为 0 或全为 1，AUC 无法定义，需要在实现层面做兼容处理。这也是实际项目里经常遇到的评估细节。
python
# 概率预测
y_valid_proba = model.predict_proba(X_valid)
# 如果返回的是 list，需要转为二维数组
if isinstance(y_valid_proba, list):
y_valid_proba = np.vstack([p[:, 1] for p in y_valid_proba]).T
print("验证集预测概率形状:", y_valid_proba.shape)
# 按列计算 ROC AUC
auc_scores = {}
valid_auc_list = []
for idx, col in enumerate(TARGET_COLUMNS):
y_true_col = y_valid[col].values
y_pred_col = y_valid_proba[:, idx]
# 只有同时存在正负样本时，ROC AUC 才有意义
if len(np.unique(y_true_col)) < 2:
auc_scores[col] = np.nan
else:
auc = roc_auc_score(y_true_col, y_pred_col)
auc_scores[col] = auc
valid_auc_list.append(auc)
auc_df = pd.DataFrame({
"label": list(auc_scores.keys()),
"roc_auc": list(auc_scores.values())
}).sort_values("roc_auc", ascending=False)
print("\n各标签 ROC AUC:")
print(auc_df)
macro_auc = np.nanmean(list(auc_scores.values()))
print("\n宏平均 ROC AUC:", round(macro_auc, 6))生成测试集预测结果
基础流程跑通之后，通常需要把测试集转换为与提交格式一致的预测结果。对于多标签任务，输出往往是每个标签对应的概率值，而不是单一类别。这样的结果不仅可用于比赛提交，也适合在业务场景中配合阈值体系进行自动分派、人工复核和优先级排序。
python
X_test = test_df["text_clean"]
test_proba = model.predict_proba(X_test)
if isinstance(test_proba, list):
test_proba = np.vstack([p[:, 1] for p in test_proba]).T
submission = pd.DataFrame(test_proba, columns=TARGET_COLUMNS)
# 如果测试集存在主键列，建议一并保留
id_col = "id"
if id_col in test_df.columns:
submission.insert(0, id_col, test_df[id_col].values)
print("\n提交结果示例:")
print(submission.head())
submission.to_csv("submission_baseline.csv", index=False)
print("\n已生成 submission_baseline.csv")扩展流程概述
这套入门版流程的意义不在于冲击榜单最优，而在于建立一个完整、可运行、可解释的文本多标签分类基线。实际进入竞赛增强版或业务实战阶段后，优化重点通常会从"能否训练成功"转向"标签不均衡如何处理、文本字段如何深入利用、验证方式是否贴近线上分布、阈值如何服务业务决策"。对于 311 这类工单数据，文本之外往往还存在时间、地理位置、投诉来源、责任部门历史处理表现等结构化信号，这些信息与文本语义结合后，常常比单纯堆叠复杂模型更有效。进一步升级时，可引入更强的文本表示方法、更加稳健的多标签分层验证、标签相关性建模以及模型融合方案，把基础版本扩展为兼顾离线指标与落地可用性的完整解决方案。
| 扩展流程 | 流程说明 | 流程目标 |
|---|---|---|
| 多标签分层验证 | 将随机划分升级为更贴合标签分布的多标签分层抽样，降低验证集偶然性，避免长尾标签在某一折中缺失 | 提升离线评估稳定性 |
| 文本特征增强 | 在词级 TF-IDF 之外加入字符级 n-gram、主题短语、地址缩写归一化与工单模板清洗 | 提升对噪声文本和短文本的识别能力 |
| 标签不均衡处理 | 针对极少数标签调整类别权重、阈值或采样策略，减少模型只学到头部标签的问题 | 提升长尾标签召回率 |
| 概率阈值优化 | 不再使用统一 0.5 阈值，而是按标签搜索最优阈值，兼顾召回、精度与业务容错要求 | 让预测结果更贴近业务使用场景 |
| 模型替换与集成 | 在逻辑回归基线之上尝试 LinearSVC、LightGBM 文本特征方案或 Transformer 编码结果融合 | 提升整体分类性能 |
| 多模态特征融合 | 将文本与时间、行政区、渠道、历史处理时长等结构化字段联合建模 | 让模型更接近真实工单分派系统 |
| 标签相关性建模 | 引入 Classifier Chains 或神经网络多任务结构，捕捉多个标签之间的共现关系 | 提升复杂工单的联合识别效果 |
| 错误分析闭环 | 对低 AUC 标签、误判样本、混淆严重的标签组合进行人工审查与规则回补 | 把离线建模改造成可持续优化流程 |
优秀案例解析
围绕这个赛题检索公开资料后，可以明确看到一个现实情况：该竞赛当前仍更接近模板型社区赛，公开页面中缺少成熟的获奖方案沉淀，Kaggle 代码区也没有形成可直接复盘的高质量代表作品 。因此，"优秀案例解析"不能机械局限在赛题页面本身，而应分成两类来筛选：一类是与纽约 311 响应时长预测高度贴近的赛中公开项目样例 ，重点观察问题定义、目标变量构造、时间与空间特征设计、回归验证方式等直接可迁移的方法；另一类是城市治理、公共服务工单、应急响应时间预测和时空回归领域的生态标杆案例，这类项目往往在数据治理、业务闭环、部署价值和可解释性上更完整，更接近真实项目交付。真正值得参考的案例，并不只是模型分数高，而是能够把"请求何时结案"拆解成可建模的业务过程，在脏数据、类别稀疏、地理分布不均、时段波动明显的条件下，仍然构建稳定验证框架，并为资源调度、服务公平性评估和城市运营优化提供可落地依据。
| 创建时间 | 作者 | 案例解析 |
|---|---|---|
| 2020 | Polong Lin / Kaggle 社区赛题发布者 | Predict New York 311 Response Times 关键词：311工单、结案时长预测、RMSE、模板赛、结构化回归。这是与本赛题直接对应的公开入口。虽然页面中暂未沉淀出完整获奖方案，但题目本身已经明确了核心业务目标：根据历史 311 请求信息预测关闭所需天数。可借鉴之处在于，它把典型城市运营问题转化为结构化回归任务，适合围绕时间字段清洗、目标偏态处理、类别编码和区域差异建模建立一套完整原型。对于希望从比赛过渡到真实数据项目的人群，这类题目比纯教学数据更接近工单系统、客服 SLA 和政府服务治理场景。 |
| 2019 | NYC Open Data / NYC 311 官方数据生态 | 311 Service Requests from 2010 to Present 关键词：原始工单、时间戳治理、地理字段、投诉类型、开放数据。该数据源并非 Kaggle Notebook，但它是纽约 311 体系最核心的业务底座，也是本赛题特征工程最值得追溯的参考对象。公开字段通常覆盖创建时间、关闭时间、投诉类型、责任部门、行政区、经纬度与处置状态，天然适合构造"工单复杂度""区域负载""部门能力差异""节假日与天气扰动"等派生特征。对本赛题最有价值的启发不在于模型名称，而在于真实业务数据的治理逻辑：若起始与结束时间存在异常、撤单、重复单或长尾未关闭记录，预测结果会直接失真，因此数据清洗优先级往往高于盲目堆模型。 |
| 2023 | NYC Office of Technology and Innovation / Open Data 团队 | NYC 311 Data Dictionary 关键词：字段语义、状态口径、业务解释、异常识别、特征筛选。这个案例更像是"建模前说明书"，但在工单响应预测任务里价值非常高。许多低质量方案的问题并不在算法，而在误读字段含义，例如把结案状态、补录时间或处置结果当作可用先验，导致严重信息泄漏。字段字典能够帮助确认哪些变量是请求发起时即可获得的信息，哪些字段只会在工单流转后出现。对本赛题而言，能否严格区分"预测时已知"和"结案后才知"的字段，往往决定了离线验证成绩能否在真实环境中成立。 |
| 2021 | Chicago Office of Public Safety Administration / Kaggle 与开放数据生态参考 | Chicago 311 Service Requests 关键词：跨城市迁移、工单回归、类别稀疏、时空模式、泛化能力。虽然不是纽约赛题的官方案例，但它是同类公共服务请求数据中极具参考价值的标杆样本。芝加哥 311 数据在投诉类型、服务部门、地理网格和季节波动上与纽约具有相似结构，适合用来验证一套方案是否具备跨城市泛化能力。高质量解法通常不会只在单一城市内拟合历史噪声，而会构造更稳健的统计特征，如按区域、投诉类型、星期、月份和部门聚合的历史中位响应时长，并配合目标编码或基于树模型的非线性拟合。对本赛题的意义在于，它提供了"从排行榜思路走向业务产品化"的测试场。 |
| 2020 | CARTO / 城市数据科学团队 | The Spatial Distribution of 311 Calls in New York City 关键词：空间分析、热点分布、地理聚类、资源配置、服务公平。该案例聚焦 311 请求的空间分布与热点区域分析，虽然不直接预测结案天数，但它展示了城市服务工单中最容易被忽略的核心事实：响应时间并不是单纯的时间序列问题，而是明显受到地理环境、人口密度、社区基础设施和投诉类型空间集聚效应影响。对本赛题而言，案例最大的借鉴点是引入地理层级建模思路，例如行政区、社区板块、邮编或经纬度聚类后再构造局部统计特征。若缺少这类空间视角，模型往往只能学到全局平均规律，难以解释某些片区长期结案偏慢的原因，也无法支撑现实中的资源调度优化。 |
| 2018 | New York University / Center for Urban Science and Progress 相关研究生态 | Using 311 Data to Understand and Predict Urban Conditions 关键词：城市计算、代理变量、时空回归、公共服务、政策分析。NYU CUSP 长期将 311 数据作为城市运行状态的代理信号，用于理解社区问题、基础设施压力与公共服务需求。公开研究入口更偏学术与项目集合，但其中的方法论对本赛题非常重要：311 工单不是孤立表格，而是城市状态的观测切片，投诉类型、地理位置、历史积压和社会环境变量会共同影响处置速度。对高质量提交方案的启发在于，应将问题视为"多因素驱动的运营时长预测"，而不是单纯做编码后喂给通用回归器；若能额外接入天气、节假日或区域社会经济特征，模型常比只依赖原始字段更贴近真实业务。 |
| 2022 | Microsoft / Azure Architecture Center | Call center and ticket forecasting architecture 关键词：工单预测、运营优化、MLOps、部署闭环、可解释性。这个案例不直接使用 311 数据，但在"预测服务请求处理时长并支持运营决策"这一点上与赛题高度同构。其价值不在公开榜单，而在端到端落地视角：数据接入、特征加工、模型训练、批量推理、结果监控和业务看板形成完整闭环。对本赛题尤其有参考意义的一点，是将预测结果与资源分配、积压预警和 SLA 管控连接起来，使模型不只是离线评分工具，而是可用于排班和优先级调整的运营模块。对于自学者而言，这类架构案例能够补足 Kaggle 项目常见的"只到提交文件为止"的断层。 |
| 2021 | DrivenData / 城市韧性与公共事务竞赛生态 | 生态标杆：公共服务与城市基础设施预测类项目集合 关键词：公共利益机器学习、资源受限、解释性、鲁棒验证、社会价值。由于本赛题缺少成熟公开获奖案例，DrivenData 的公共利益竞赛生态可以作为方法标杆来源。该平台大量项目都围绕城市基础设施、公共健康、资源调度和社会公平展开，常见特点是更强调缺失值处理、样本分布漂移、时序切分验证和现实约束下的可部署性。映射到纽约 311 响应时长预测时，最值得借鉴的是验证策略和业务标准意识：若训练集与未来分布不一致，随机切分得到的分数通常会过于乐观；按时间滚动切分、按区域留出验证，更能反映模型在真实公共服务场景中的可靠性。 |
总结
这道题的价值不在于模板化套模型，而在于把城市治理中的真实流程问题转成可量化、可验证、可迭代的预测任务。只要把数据清洗、时间特征构造、类别编码、长尾处理和误差分析做扎实，即使基线模型并不复杂，也能建立一套具有实际参考意义的服务时效预测原型。
放到更真实的业务环境中，311 工单时长预测能够进一步支撑超时预警、部门负载评估、区域资源配置和流程瓶颈识别。对自学机器学习的人群而言，这类案例的重要意义，在于理解模型只是手段，真正决定项目质量的，始终是任务理解、数据治理、验证设计与结果解释能力。