26年7月第四周

day 1

1. 学习apollo配置有关内容，粗略了解

2. 优化模型的四个方向：样本选择偏差，训练预估集不匹配，特征体系不完善，模型学习能力及扩展性弱

3. 沟通后续方向，了解数据链路。
   • 把巴西moto升级到v8，似乎就是每个城市的配置都要改一改。然后在这基础上有什么优化也可以加上去。
   • 优化ar-trigger模型，现在的模型baseline是 dipn，在这个基础上优化。
   • 线上生产数据表里可以拉取离线模型的训练数据，数据梦工厂里拉取
4. 记得学一下lego平台。
   • 看上去像是一个零代码平台，搭管线用的，领导力推这个。

day2

1. 配置本地ide远程连接jupyter，vscode中可以使用远程jupyter kernel运行本地代码，pycharm中可以编辑远程文件但是不能用远程kernel。 现在可以在本地vscode连远程服务器，并且进行读写，很奇怪的用法，在本地新建ipynb文件，选择远程kernel，然后在本地vscode中运行代码，代码会在远程服务器上运行，运行结果会返回到本地vscode中显示。读写文件和路径都是远程服务器的，每次pwd显示远程服务器的用户目录。因此在开发时切记！！！所有代码写绝对路径！！！

2. 申请lego，数梦等权限。

day3

1. 尝试从数梦获取训练dipn模型所需的数据

数梦上ar模型训练特征用表 intl_discount_car.dp_sample_explore_v1 获取格子级别样本和label 和 intl_discount_car.dp_sample_v2 获取格子级别样本join特征（这个全一点）
表逻辑：线上探索(exploration)流量的 label（订单结果） 与 feature（特征） 按预估单 estimate_id 拼接成一张宽表 ，落到 intl_discount_car.dp_sample_v2，按天(dt)分区. 只取探索流量以确保训练模型所需的反事实。
这张表没按国家分，国家混在一起，注意一下

   log_label  (dp_sample_explore_v1)   ──┐
                                         ├─ JOIN ON dt + estimate_id ──► dp_sample_v2
  feat       (dp_online_sds_feature_v2)──┘

  - log_label：探索日志表，过滤条件 hit_explore='true' AND is_layer_explore='true'，即只保留命中探索、且在探索分层内的流量。
  - feat：线上 SDS 特征表（离线落地版）。
  - JOIN 键：dt + estimate_id（一次预估报价对应一条特征）。
  - 分区取 ${BIZ_DATE_2AGO_LINE}，即 T-2（两天前），两侧都用同一天。

  字段分成两大块

  ① Label / 主键 / 上下文（来自 log_label）
  - 标识：country_code / passenger_id / estimate_id / order_id / orderid
  - 订单结果标签：is_send / is_accept / is_finish（发单 / 接单 / 完单）
  - 动调相关量：dynamic_times（动调倍数）、driver_dynamic_times、demand_supply_rate（供需比
  ）、pre_total_fee_amt、driver_pre_total_fee
  - 预估量：eta / eda / road_dist、bubble_time/date（冒泡本地时间）
  - 探索信息：bcrate / explore_var_layer / esr

  ② Feature（来自 feat，即模型输入特征）
  - 乘客画像特征 pax_*：冒泡/呼叫/取消/完单/GMV/优惠券/时长等，按 3/7/14/21/28 天滚动窗口。
  - 网格供需特征 grid_*_origin_* /
  grid_*_dest_*：起点、终点网格的冒泡/呼叫/成交/加价/补贴/GMV 等，同样多窗口。
  - 实时供需特征：*_in_10_minutes、realtime_esr/dsr/ar/ecr、biz_bubble_minute_*、biz_order_
  create_minute_*、driver_strive_order_minute_*、派单侧 coordstream_* / engine_dispatch_* /
  realtime_no_broadcast_order_*、passenger_wait_pick_time_*、dynamic_times_minute_*（近
  1/5/10 分钟聚合，含 c1/c2/all 分车型口径）
  

1. 用新数据复现dipn
   • 使用从20251210到20260315的数据进行训练，目前eval上的 auc为0.73，明天拉取四月两周的数据作为test，看看能否达到文档中写的0.71
   • 目前的dipn可优化的地方：特征输入过滤，特征处理，模型结构，optuna自动化
   • 今天完成了从sql取数据到离线训练模型的完整流程。

day4

1. 评估dipn，构造模型评估管线，具体包括从指定pth读取模型权重，从数梦拉取测试集并且处理，计算模型auc，qini，mae等指标，做出ar和真实接单率的dp的分桶图等
2. 优化目前等dipn，有如下方向todo：（cc说的）

• 网络结构有点臃肿 主干形状有个多余的”缩了又扩”: 108→256→128→64→32→64→32→22。shared_net 已经收到 32 又扩回 64 输出,net_s 再 64→32→22,这个二次瓶颈会白丢信息也浪费参数。让宽度单调收窄、或直接 trunk 出表示 → 一个干净的响应头输出 22 增量,会更合理。

• BN 用法偏重、且有线上一致性隐患。 _create_subnet 第一层就对输入做 BatchNorm1d,但 dense 特征在预处理里已经 z-score 过了,是重复;而且每个 block 是 BN→Linear→ReLU→Dropout,Dropout 在 BN 前会造成方差漂移(Dropout/BN 不和谐的经典问题)。BN 推理走 running-stats,和前面数据处理强调的”线上记得截断”是同一类训练/线上一致性坑。可考虑:去掉输入 BN(已归一化)、或整体换 LayerNorm(与 batch 无关、导出更安全)、并把 Dropout 挪到 BN 之后。

• 平滑只靠 loss,且 TV 正则连 w0 一起罚了。 compute_loss 对全部 22 维算 Σ

  w_j−w_{j+1}

  ,但 w0 是基准 logit、w_{1..21} 是正增量,量纲/语义不同,罚

  w0−w1

  把两者混在一起——平滑应只作用在增量位。更进一步,曲线平滑目前完全由 loss 驱动,比较脆;如果想更稳,可以把平滑做进结构(如样条/单调基,或让相邻 bin 共享参数)。

• EMA 两个问题。 一是收尾 load_state_dict(best_model) 后又 apply_shadow() 覆盖成 EMA 权重(上轮提过,最终存的其实不是 best);二是 decay=0.95 对逐 step EMA 太快,只等效平均最近 ~20 步,几乎没起到平滑作用,通常用 0.999+。

1. 模型对比，训练集20251210到20260315， 测试集20260401-202604300. 很奇怪为什么优化完还不如之前
   • 训练时，dipn-v3 auc=0.73, 测试集上0.655
   • 训练时，v2模型 auc=0.74，测试集上0.697 不管是测试还是训练似乎原始模型更好？
2. dp-ar分桶图的业务理解，在某一dp处（如dt=1.3） 预测高于真实（高估）→ 加价不足、成交受损 模型以为 1.3 倍就能达到目标接单率，于是选了偏低的动调；但真实接单率没那么高 → 实际达不到目标，订单应答/成交不足、乘客等待久、司机供给跟不上。 换个说法：要真正达到模型承诺的那个接单率，实际需要 >1.3 的动调，模型系统性低估了”达标所需的加价”。

预测低于真实（低估）→ 过度加价、成本浪费 模型以为 1.3 倍还不够，为凑够接单率会把动调抬得更高；但其实不用加那么多价司机就愿意接 → 过度加价/过度补贴，乘客多付钱或平台多花成本，还可能因加价过高导致乘客流失。 换个说法：达到目标接单率实际只需 <1.3 的动调，模型选了偏高的倍数。

day5

优化了昨天遗留的dipn问题，优化损失计算中的reg计算方式，对reg权重做搜索

和老员工交流，得知做BR-moto的困难点：
该员工之前做BR的快车和MX的四轮车的迭代，很快拿到收益的原因是：对于BR-快车业务，现有线上策略会导致动调倍数堆积在高处，他的新模型可以把倍数分布左移动；对于MX四轮业务，是因为之前的四轮用的策略在demandsupplyfilter中没有ar_trigger，加上了ar_trigger模型后，在供需失衡（运营说，早晚高峰，雨天）的场景下立竿见影。而BR-moto存在的问题是，moto自己不加约束的ddt倍数分布就很合理了，导致没有什么好优化的，其次巴西的运营更关注覆盖率，严格限制覆盖率的增长，mx的运营不管这些，所以策略比较狂野。总之目前br-moto的优化可能只能在模型性能做提升，如果想要拿收益，最好做做其他西语区的moto，也就是和另一个老员工赛马。。。