2024.8.14

• 定转正target
• 测评升舱项目的必要性
• 整理自定义特征上线文档
• 询问职级

20240826

• 分析差供需（周三给）

20240827

• 出by城市的丢单和hold比例

20240828

• 根据实验数据调整端流量分发的阈值
• 针对广州丢单极少的情况，提取端内呼叫和ar数据分析，发现有一周内也有4W多单，不太可能为0条，等路师傅休假结束问
• 整理下周升舱排期要用的数据、表和模型

20240830

• 看一下29号全天的端外丢单情况（修改策略后全天生效的结果）
• 修改8月回顾9月规划+时间点
• 看0829的端外丢单数据
• 看预分单接受度模型特征和单调性
• 丢单是不是都是在treatment时间片内丢的？
• 跑一下DS的评估报告，加上指标：1.未播订单数，2.连边订单数，3.司机拒单率，4.乘客应答前取消率

20240902

• 问路师傅为什么hold数据没有了——>是自己sql 的问题
• 预分单接受度模型加单调性验证
• 跑通验证大师DEMO代码

20240903

• 查丢掉的单对应的时空下未播订单数以及未播订单数里的连线数
• 看升舱PRD
• 预分单接受度线上模型跑一遍——>AUC0.866，降低了0.03

20240909

• 检查预分单接受度模型wait_relay那个特征是什么，以及是否有特征是在接受后才有的：wait_relay_selected_num：发单车型数
• 找到business_id和cp_id之间的关系

20240911

• 预分单接受度模型：左表里有滴滴渠道的流量，因此需要去掉（inner join或者把左表交order表 is_hxz = 1）
• ar模型：bubble_base_all_di的trace_id和trd_order_base_di的trace_id交不起来——>用order表的bubble_trace_id和bubble表的trace_id去交

20240912

• estimate_id和product_id的关系——>一个product_id对应多个estimate_id
• pk type = 16什么意思？——>预分单
• 预分单历史数据中接受的case多于拒绝的case，加action='passenger_decision'约束
• 预分单模型特征表中存在多个相同的order_id✖️product_id过模型得出不同打分的情况——>同一个order_id✖️product_id在不同轮下过模型
• 重训练后的xgb auc 0.68，召回率很差，尝试从以下几个方面调整：1. 去掉冗余特征 2. 调参 3. 针对正负样本分布不均调整权重

20240913

• ar模型日志表用estimate_id和trace_id交出来后部分为null，看看是不是盒子的原因：？目前看来不在盒子里的也有空，还得接着问
• 检查接受度模型的特征空值是什么情况，AUC提升到0.7以上
• 当level_type 在105或200的时候，代表该运力在盒子里，此时用trace_id和product_id去拿ar
• 如果在盒子里某个product被勾选了，那么若其在盒子外未被勾选，也不参与升舱
• 如果product_id是80，即自营，那么即使在盒子里被勾选，盒子外若未被勾选，也可以升舱
• 盒子内的运力不升舱
• 离线计算时可以手动替换预分单接受度模型里的缺失特征，线上怎么办？还是得check
• ar里面有20%是空的

20240914

• 离线表dt=在线表dt - 1
• dufe看在线特征采样是否有问题：确实有问题

20240918

• 预分单接受度模型训练完成，AUC0.698，暂用这一版：upgrade_cabin_v4
• 升舱所需数据梳理完毕，正在拉数求解

20240919

• 排除升舱条件存在问题，待修正——>导致base和升舱trace数量不在一个量级上
• 看一下final_data中是否有ar为空的情况——>确实存在
• 预分单接受度模型新增的三个特征和工程对（jialuo），给他一条passenger_id + order_id能手动拿到特征，但是线上日志表拿不到特征的case查验 order_id: 52811592317986 passenger_id:17595166735065 ❓有些order_id + passenger_id在特征表里查出来的和手动查的不一样，怀疑是工程配置问题

20240920

• 0901的GMV：50266634.22

20240921

• 预分单接受度模型日志表里，所有的发单都会过线上模型吗？如果不是的话，全部特征怎么拿到？当前检查的结果是，日志表里数据不全，有的passenger_id没有数据，有的passenger_id✖️order_id✖️dt下没有对应的product_id——>建议只拿日志表中有特征的数据进行训练
• 问jialuo能不能直接拿到特征，不从线上日志表拿
• 特征为空的大部分非工程传入特征，问张聪特征配置映射or是否线上拿特征时缺少工程传入的参数（确定了一点：dufe配置的特征，周期任务中用到的表就是我们现在的其他底表）——>缺失的特征的周期任务早就停用了，需要重新配
• EVE中过模型拿预测值还需要label列，如果拿有现实乘客是否拒绝的数据去inner join的话，可用的训练数据量就更少了，如何解决？——>label列随便传
• 之前既然停了周期任务，为什么还能拿到日志表里的特征？——>工程线上传入
• 确认当前存在问题的预分单接受度模型停的话有什么影响
• 线上模型用的训练数据，时间窗口已经是特征的调度任务停止日期之后了，所以我预计线上模型既扩充了样本，特征也存在问题——>线上模型的训练集已经拿不到，无法拆开特征和扩充样本分开看
• 周期任务 kflower_marketplace.data_h2d_fe_fex_ecr_weather的上游依赖已经不存在
• 很多配置的特征的周期任务的上游依赖都存在问题，要么没有了，要么停了，干脆我们自己重写好了
• 将新特征放到特征算子里，重新训练预分单模型
• 升舱数据对应的预分单接受度预测里，接受的占比（prediction=1）非常高，正常吗？——>prediction的阈值设定为0.5，而且看的是isotonic_feature的预测值，如果其大于0.5，则判定为1，实际上应该看isotonic_prediction更为准确
• 预分单接受度模型日志表的trace_id和订单/冒泡的trace_id不是一个东西，不能直接用
• 分单矩阵表ods_log_kflower_stgmatrix_hh里的driver_id在pbd和thlm端可以参考以下join方式，花小猪端内可以直接和dwd_kf_trd_unity_order_di的driver_id交

inner join (
        select
            param ["area"] as city_id,
            param ['uuid'] as uid,
            param ["grid_id"] as grid_id,
            shiftleft(
                shiftright(cast(param ["base_order_id"] as bigint), 46) & 262143,
                32
            ) +(
                cast(param ["base_order_id"] as bigint) & 4294967295
            ) as order_id_duanwai,
            param ["driverid"] as driver_id
        from
            kflower_marketplace.ods_log_kflower_stgmatrix_hh
        where
            concat_ws('-', year, month, day) between "2024-08-26"
            and "2024-09-08"
            and param ['order_origin'] in (1, 2)
            and param ["area"] in (
                2,
                9,
                11,
                12,
                13,
                14,
                16,
                19,
                35,
                50,
                60,
                62,
                65,
                72,
                74,
                83,
                107,
                125,
                134,
                137,
                161,
                167,
                241,
                254,
                280
            )
    ) b on a.driver_id = b.driver_id
    and a.uid = b.uid
    left join 
    (
        select  distinct hxz_driver_id
                ,other_driver_id as driver_id_hh
                ,didi_driver_id
        from    kflower_strategy.pk_hxz_driver_id
        where   concat_ws('-', year, month, day) = '2024-09-08'
    ) d on a.driver_id = d.driver_id_hh
    left join (
        select
            start_city_id as city_id,
            date_format(answer_time, "yyyy-MM-dd") as cur_date,
            order_id,
            driver_id
        from
            kflower_dw.dwd_kf_trd_unity_order_di
        where
            (
                is_pbd = 1
                or is_thlm = 1
            )
            and (product_type = '花小猪自营'
            or (product_type = '三方品牌'
            and platform_name in ('鸿鹄', '宏鹄')))
            and is_td_call = 1
            and is_td_answer = 1
            and start_city_id in (
                2,
                9,
                11,
                12,
                13,
                14,
                16,
                19,
                35,
                50,
                60,
                62,
                65,
                72,
                74,
                83,
                107,
                125,
                134,
                137,
                161,
                167,
                241,
                254,
                280
            )
            and dt between "2024-08-26"
            and "2024-09-08"
    ) c on b.order_id_duanwai = c.order_id
    and d.didi_driver_id = c.driver_id

• 0901真实数据下的升舱lambda求解完毕，拉14天完整数据求解ing
• 产出司机履约分工程文档和0917-0923数据的$\alpha$求解结果

20240929

• 验证预分单接受度模型单调性
• 找如帅和yiwei聊一下PK动态窗口强化学习
• 10号之后找leader对

20240930

• 发现大问题，当前升舱求解框架下得到的$\lambda$不能满足补贴约束
• 0929晚餐未报销——>已提交未到账（0914的也未到账）
• 0930晚餐未报销（重新开发票）

20241010

• 升舱：当前大盘GMV用的是全部应答订单的gmv，但是最终求解的时候用的是过预分单接受度的订单数据，应当用这部分子集的gmv算更准确——>线上判断升舱需要订单经过预分单接受度模型的过滤条件，因此按原本的大盘gmv计算即可
• 当前GMV增量过大，很奇怪，待排查->用概率计算，不要看历史订单对应的gmv

20241011

• 1010和1011两天的餐补没报销

20241014

• 让明光测预分单接受度模型（空跑）
• 预分单接受度模型线上空跑后在离线一致性检验：离线特征和在线特征是否一致，相同的特征拿到的结果是否一致
• 看上周六和本周一全量实验的触发面，如果没问题，开5min时间片实验
• 升舱项目情况：策略：已离线求解完毕 工程：1016上线+模型空跑 业务：API商家只有哈啰和享道参与 预算：API愿意补贴就参与升舱，自己承担全部成本，不愿意补贴就不参与升舱，自营和宏鹄的成本全部由我们平台承担
• 当前线上有其他丢单策略，在重庆 长沙 杭州三个城市长期生效，会影响特惠联盟丢单（增多）
• 统计了1012的晚高峰丢单hold率，还差1014的早高峰

20241015

• 5min时间片实验当前在评估大师上无法配置，转而配置30min时间片
• 实验选城按照城市在1008-1014之间触发阈值比例+自营宏鹄在端内外的比例叉乘排序取出

20241016

• 国庆期间0930-1007滴滴端丢单多于PBD端？ 猜测原因：

1. 滴滴订单密度高于PBD端，更多触发端内差供需场景
2. 触发条件还有距离条件，可能滴滴侧将更多小单放到我们这边

20241017

• 三天后看差供需v3版本实验指标

20241018

• 看是否受前置实验影响导致时间片实验没有触发
• 晚峰关注最新实验的监控

20241021

• 升舱进度：策略离线开发完毕 工程全部模块上线完毕 10.29发版，发版后一周开实验
• 了解折叠现状，整理一份文档
• 多和jiatong聊，投入折叠
• https://ether.intra.hongyibo.com.cn/deploy/466： 这个模型预测的是应答率

20241022

• check了by grid和by is_degrade拿到丢单结果不同的问题：用case when打标签再sum没有对orderid去重
• 升舱中间结果初步出来，todo: 1. 加一个by商家的发单数和升舱占发单的比例数据 2. 根据order_id回溯city_id，增加by city粒度的结果分析 3. 加一个提升完单的期望值

20241024

• 看下升舱上线后怎么看触发面、花费、roi等指标，找名光了解一下，整理后和工程or数舱对一下，在上线前确认一下是否能看
• 想一下三个漏斗：是否找司机、是否找到司机、乘客是否接受
• 晚餐未报销

20241028

• 差供需实验结束后去掉受影响前置城市+gongjian城市后给到xinyu
• 看30min时间片第一周和第二周对应时间都有差供需的trace分布
• 给API商家测算数据
• 填写DS需求文档
• 问路师傅hold看板的事
• check完整的预分单接受度model在离线
• 确认曹操出行参加升舱？

20241031

• eve上跑了预分单接受度模型原始的训练数据，待检查其中有没有出现一条case多个价格的情况——>出现了，占约3.5%
• 尝试用kflower_dw.dwd_kf_trd_pre_dispatch_decision_di这张表的estimate_fee字段在预分单接受度模型训练数据的sql中加一个卡的约束，但是这张表中很多的estimate_fee为空，交完后500多万训练数据只剩下23万，打算拉大时间范围按这个训一版新模型，再按名光说的取同一条case两个价格里的较低价case作为真实数据训一版模型

20241104

• 预分单日志表最早分区为8月2号