# Task 1(2021 年 MFP 计划)——可审计建模与排程(论文式说明) ## 摘要 本文给出一套在“仅有站点经纬度、2019 年访问次数、单次到访人数均值/标准差”的数据条件下,仍然**闭环、可复现、可审计**的 2021 年 MFP 访问频次与全年日历排程方案。方案遵循三层结构: (1) 用空间核平滑把“周边社区总需求”落地为站点邻域需求代理; (2) 在给定全年总访问次数约束下分配每个站点年度访问次数; (3) 将年度次数转换为 2021 年逐日(每天 2 个站点)可发布的排程日历。 本文严格采用题面确认的运营情景:**每天 2 个站点、全年 365 天运营、总访问次数 `N_total=730`、必须覆盖全部 70 个站点、且不建单次容量上限**。 ## 1. 问题与数据 ### 1.1 输入数据(`data.xlsx`) 对每个站点 `i=1..70`,数据给出: - 位置:`(lat_i, lon_i)` - 2019 年访问次数:`v_i^{2019}` - 单次到访人数统计量:均值 `μ_i`、标准差 `σ_i`(单位为 “clients per visit”,按题面口径理解) ### 1.2 决策变量与约束 我们需要为 2021 年决策每个站点年度访问次数 `k_i`,并生成逐日排程。 - 覆盖约束(题面/用户确认):`k_i >= 1` - 总资源约束(情景 B):`Σ_i k_i = N_total = 730`(= 365 天 × 2 站点/天) ## 2. “周边社区总需求”的可审计代理 题面要求“频次由周边社区总需求指导”,但数据没有社区人口/贫困率等外部字段,因此我们将其定义为**可审计的空间平滑代理**。 ### 2.1 距离 使用 haversine 距离 `dist(i,j)`(英里)。 ### 2.2 高斯核平滑(核心) 给定尺度参数 `ρ`(英里),定义站点 i 的邻域需求代理: `D_i(ρ) = Σ_j μ_j · exp( - dist(i,j)^2 / (2ρ^2) )` 含义:越近的站点对“周边需求”贡献越大,且贡献按距离平滑衰减;`ρ` 越大表示“更大范围的周边”。 ### 2.3 敏感性分析 本文默认同时计算 `ρ ∈ {10, 20, 30}` miles 三个情景,用于审计“周边”尺度选择对结果的影响。 ## 3. 年度频次分配:有效性与公平性 ### 3.1 有效性(Effectiveness) 用户确认“不建单次容量上限”,因此总体服务量(期望)可用下式作为有效性代理: `Eff = Σ_i k_i · μ_i` 该指标等价于:假设单次服务量随到访人数线性增长,且不考虑单次运力/食品上限截断。 ### 3.2 公平性(Fairness):服务水平而非次数 题面“served much better”更自然地对应“服务水平/满足率”而非“访问次数相等”。 我们定义站点 i 的服务水平(对邻域需求的相对供给)为: `S_i(ρ) = (k_i · μ_i) / D_i(ρ)` 然后用两类审计指标衡量不均等: - `min_i S_i(ρ)`:最弱站点的服务水平(max-min 视角) - `Gini({S_i(ρ)})`:服务水平分布的不均等程度(标准 Gini 公式) ### 3.3 分配规则(主推荐:按周边需求比例分配) 在覆盖约束 `k_i>=1` 下,我们采用**按周边需求代理 `D_i(ρ)` 比例分配剩余次数**: 1) 先给每站点 1 次:`k_i := 1` 2) 将剩余 `R = N_total - 70` 次按权重 `w_i = D_i(ρ)` 做整数分配(largest remainder / Hamilton 方法): - 连续目标:`k_i ≈ 1 + R · w_i/Σw` - 再通过取整与余数分配保证 `Σk_i=N_total` 该规则的解释性很强:**周边需求越大,年度访问越多**,且覆盖约束保证所有站点至少一次。 ### 3.4 基线与对比 为可审计地量化改进,输出中包含“2019 访问次数按比例缩放到 730 次”的基线(`baseline_2019_scaled`),并在同一套指标下对比: - 总有效性 `Σ k_i μ_i` - 公平性 `Gini(S)`、`min S` ## 4. 排程层(何时去):将 `k_i` 变成 2021 日历 目标:把每站点年度次数转成可发布的具体日期,同时保证每天正好 2 个不同站点。 ### 4.1 均匀间隔的目标日期 对站点 i 的第 `j` 次访问(`j=0..k_i-1`),设理想目标日(1..365)为: `t_{i,j} = round( (j+0.5) · 365 / k_i )` 直观含义:尽量均匀地把 `k_i` 次撒在全年。 ### 4.2 装箱与修复 先按 `t_{i,j}` 把访问事件放入对应日期桶;若某天超过容量(2 个站点)或出现同一站点重复,则将溢出事件移动到最接近的仍有空位且不重复的日期,直至: - 每天正好 2 个站点 - 每天两站点不同 - 总计 730 个事件全部入日历 输出同时给出每站点相邻访问间隔的统计(最大/均值/标准差),用于审计“服务连续性”。 ## 5. 可复现流水线(脚本 + xlsx 传输) 按步骤运行(从项目根目录): 1) `python task1/01_clean.py` → `task1/01_clean.xlsx`(标准化字段、补 `site_id`) 2) `python task1/02_neighbor_demand.py` → `task1/02_neighbor.xlsx`(`D_i(ρ)` 与距离矩阵) 3) `python task1/03_allocate_k.py` → `task1/03_allocate.xlsx`(多种分配方法 + 指标对比) 4) `python task1/04_schedule_2021.py` → `task1/04_schedule.xlsx`(2021 日历排程;默认 `ρ=20mi` + `proportional_D`) ### 5.1 关键输出表 - `task1/03_allocate.xlsx`: - `allocations`:每站点的 `k_i` 以及对应 `S_i(ρ)`(按不同 `ρ`/方法) - `metrics`:每种方法/情景的有效性与公平性汇总 - `task1/04_schedule.xlsx`: - `meta`:排程采用的 `ρ` 与方法列名 - `calendar`:每天两个站点(可直接发布的日历) - `site_dates`:每站点的具体日期列表 - `gap_metrics`:每站点访问间隔统计(连续性审计) ## 6. 假设与局限(必须在正文显式声明) - 由于用户确认“不建单次容量上限”,本文未建模单次运力/食品约束,也无法估计缺供概率;有效性以 `Σ k_i μ_i` 作为线性代理。 - `μ_i, σ_i` 被视为“真实到访需求”的代理统计量;若历史存在供给截断,则高需求站点可能被系统性低估(需在后续任务中引入容量或外部数据修正)。 - “周边需求”完全由站点间空间平滑构造;`ρ` 的选择需要与 FBST 对“可接受出行半径”的运营经验校准,因此本文提供 `ρ∈{10,20,30}` 的敏感性结果便于审计与讨论。