美团 AI / 算法怎么准备
美团算法常带时空：匹配骑手、估计送达、城市之间差很大。全国一套模型往往不够。
五题覆盖匹配、ETA、区域、编码和值班。用你的调度或预估项目答。
美团怎么面算法
- 会问为什么高峰和平峰不能同一套。
- ETA 误差如何评估。
- 准备区域泛化。
面试阶段与知识点
第一批不把每个阶段拆成独立 URL，避免程序化重复页。阶段对应下面的题，练完再用模拟面试串起来。
- 匹配：供需。
- ETA：误差。
- 区域：泛化。
- 高峰：取舍。
值得开口练的题
每题给考察点、思路、结构化参考答案和追问。参考答案用来组织语言，面试时必须换成你自己的项目事实。
订单和骑手如何匹配，才不会让近的单永远抢走远的单？
考察点
- 公平
- 超时
- 全局
回答思路
贪心最近会饿死远单，代价函数要含超时风险，优先批量匹配而非逐单局部最优。
结构化参考答案
- 指标上同时看用户超时率、骑手空驶里程与远单完成率，按距离段与时段分层评估公平性。
- 方法上代价含配送距离、预计超时风险与骑手负载，用批量匹配或整数规划近似替代逐单贪心。
- 工程上匹配求解需在秒级内完成，高峰可降级为启发式并保留回滚开关，恶劣天气单独调权。
- 有效性以超时与空驶双指标 A/B 及远单投诉回归，证明全局策略优于纯最近分配。
面试官可能追问
- 计算时延太大怎么办？
- 如何避免骑手被算法折磨？
- 恶劣天气如何调？
ETA 估早了导致大量超时投诉，你如何改评估？
考察点
- 非对称损失
- 分位
- 城市
回答思路
不能只看 MAE，估早与估晚的用户代价不对称，需用非对称损失或分位数回归。
结构化参考答案
- 指标上采用非对称损失或 P90 分位 ETA，分城市、分高峰单独报误差，并与超时投诉做回归对齐。
- 方法上展示给用户用区间而非点估计，路况与备餐延迟作为实时特征，离线训练按城市分层。
- 工程上 ETA 服务要低延迟更新，模型版本可回滚，避免为压投诉把 ETA 系统性拉长伤害体验。
- 有效性以估早率下降、投诉量与真实送达时长分布同向改善，证明新评估口径捕捉了用户感知。
面试官可能追问
- 如何避免为了少投诉把 ETA 拉得过长？
- 实时路况如何进模型？
- 离线误差为何和投诉不一致？
模型在一线城市好、下沉城市差，怎么办？
考察点
- 样本
- 特征
- 分模型
回答思路
先看样本量与特征漂移，再决定共享结构加分区域参数，或下沉城市单独建模。
结构化参考答案
- 指标上禁止只看全国均值，分城市看 ETA 误差、超时率与匹配公平，小样本城市单独建看板。
- 方法上采用共享 backbone 加区域偏置或分模型，下沉城市加规则保底与定向探索补样本。
- 工程上特征覆盖低的区域降级为规则 ETA，配置变更可灰度回滚，避免运营过拟合单城。
- 有效性以区域分层 A/B 与下沉城市投诉下降，证明泛化策略弥合了城市差异而非掩盖问题。
面试官可能追问
- 小城市数据少如何正则？
- 如何判断该拆模型？
- 运营配置如何避免过拟合某城？
如何在日志里正确计算超时率（注意时区与取消）？
考察点
- 分母
- 取消
- 时区
回答思路
先写死超时定义与分母口径，时区统一，取消单是否计入分母要明确。
结构化参考答案
- 样本上明确超时是实际送达减承诺时间，分母是完成单还是含取消必须写死并版本化。
- 方法上时间戳统一 UTC 或业务时区，改址、系统延迟等边界单独打标，改定义需回测历史。
- 工程上 SQL 或流作业与履约系统对齐在途状态，避免重复计数或漏计取消单造成指标偏差。
- 有效性以边界 case 单测、离线重算与线上看板对账，证明超时率口径与投诉统计一致可追溯。
面试官可能追问
- 改址后超时如何算？
- 系统延迟造成的超时？
- 如何回测定义变更？
高峰要牺牲一点匹配公平保送达，你怎么和运营对齐？
考察点
- 临时策略
- 指标
- 恢复
回答思路
高峰策略要有明确触发条件、临时权重与自动恢复时间，不能变成永久牺牲公平。
结构化参考答案
- 指标上定义高峰触发阈值，临时提高超时权重，同时监控骑手过劳与远单完成率双指标。
- 方法上采用可配置临时策略而非改主模型，高峰结束自动恢复默认权重并留变更记录。
- 工程上开关权限与审批流程清晰，防止人为永久开启高峰模式，支持一键回滚。
- 有效性以高峰时段超时下降而平峰公平性未受损的对照复盘，证明临时取舍可验证且可逆。
面试官可能追问
- 谁开开关？
- 如何防永久高峰？
- 骑手投诉如何进模型？
和岗位、模拟面试一起用
资料管理里保存目标岗位 JD，模拟面试会按简历出题。点题目下的按钮会把本题带进模拟开场，仍需先绑定简历与岗位。