题目重点：DoorDash MLE 面经题：用户输入 query 推荐餐厅，讨论地理营业硬约束、词法/语义召回、排序，以及 LLM 的实际用处与成本。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 可见题目未公开 query 类型、流量、地理条件或 LLM 具体任务。训练契约假设 query 是自然语言/关键词，用户位置用于可送达过滤，返回餐厅列表而不是生成一段未经验证的答案。
- 题目只问如何结合 LLM，并未要求所有在线请求都调用生成模型。是否使用 LLM 必须由延迟、成本、质量增益和安全评估决定。
解题路线
- 先拆 query intent：菜系、菜品、饮食限制、价格、时间等。保留原始词法 query，并可用轻量模型做拼写/实体归一化；对模糊长句可让 LLM 抽结构化约束，但必须校验 schema 和置信度。
- 并行召回词法索引、餐厅/菜品 embedding 向量索引、历史偏好与地理热榜。去重后用实时营业、送达范围和不可违背的用户限制做硬过滤；LLM 不应自行判定商家当前是否营业。
- 排序结合 query 相关性、预计送达、价格、转化/完成率和个人偏好，明确多目标取舍；缺用户历史时靠 query 与位置兜底。结果附可追溯菜品/餐厅字段，生成式说明只能引用这些字段。
- 在灰度中比较无 LLM、仅离线扩写、在线 query 解析/重写等方案。监控 P95/P99、调用成本、无结果率、错解饮食限制与订单完成率；在线 LLM 超时则回退原 query 检索。
手动走一遍
用户搜“附近适合素食的晚餐”，解析得到 vegetarian 与 dinner 两个约束；词法索引找含相关菜单标签的店，向量索引找语义相近店。最终仍按配送范围、营业状态与经验证的素食标签过滤。若 LLM 把“素食”错误解释成“低卡”，schema/规则校验阻止直接替换硬约束，回退原 query。场景和规则是训练示例。
规模与取舍
设 R 路召回、每路 K 个候选，合并去重约 O(RK)，排序模型成本约随候选数与特征维度增长。在线 LLM 会增加模型推断尾延迟与每请求成本，需预算和缓存；地理/营业过滤可先缩小候选再做贵的排序。
易错点与追问
容易失分的边界
- 把 LLM 文本输出直接当权威餐厅列表，可能生成不存在或已关门的餐厅；实体必须来自可追溯索引。
- 只看搜索点击率会鼓励诱人但无法送达或取消率高的结果；要看下单与履约指标。
- 将 q4 首页推荐的无 query 场景直接套用到本题，会忽略显式用户意图和 query 相关性。
- 饮食限制若涉及过敏原，不能靠生成模型推测标签；必须使用可靠商家/菜品数据并对不确定性明确提示。
继续深挖
- 若 LLM 在线解析超过延迟预算，先使用离线扩写词典/小模型，或只对长尾模糊 query 异步触发；常见 query 缓存结构化解析结果。
- 若新餐厅冷启动，词法菜单与地理召回仍可曝光；排序中设置受控探索与商家公平指标。
