深度解读：Probe-then-Plan — 面向工业电商搜索的环境感知规划

1. 问题与动机（~300字）

现代电商搜索日益需要处理复杂的用户意图，但现有 LLM 搜索范式面临一个根本性矛盾——「盲目性-延迟困境」。一方面，传统 query 改写方法对检索能力与实时库存一无所知，生成的改写计划往往召回为零（Blind Rewriter 仅 REL@30=20.7）；另一方面，ReAct 风格的深度搜索 agent 通过多轮工具调用和反思能获得更好结果（REL@30=24.1），却产生数秒延迟，与工业亚秒级 SLA（p99 < 1s）根本不兼容。

作者的核心洞察来自对线上日志的诊断分析：对于绝大多数复杂电商 query，一次初始检索的诊断反思就足以制定有效的搜索计划，无需 multi-turn 迭代。这一发现直接激发了 Probe-then-Plan 机制——在规划之前先「探测」检索环境，而非规划之后再迭代修正。JD.com（京东）已将 EASP 部署于生产，每日服务数百万 query，2周在线 A/B 测试验证了 UCVR +0.89%、GMV +0.57% 的商业增益。

2. 方法详解（~600字）

EASP 框架整体分三层：Retrieval Probe（探针）、Planner（规划器）、Router（路由器）。

核心机制：Probe-then-Plan

Retrieval Probe 是一个轻量级检索模块，在规划前先执行一次初始检索，暴露以下「环境快照」信息：当前 query 能召回的文档集合、相关性分布、以及库存边界。Planner 接收 (原始 query, 环境快照 O_init) 作为输入，在单步推理中诊断执行间隙并生成落地计划 P。设计上刻意避免多轮交互，将 Probe 延迟控制在 ms 级（比完整检索管线快约 75%）。

三阶段训练

Stage 1：教师智能体离线数据合成。以 DeepSeek-R1 为教师，对 query-观察对进行「感知诊断」，将检索状态分为三类：(a) Effective State（高相关，足够覆盖，无需修改）；(b) Recall Failure（召回失败，分两子类：Query Noise——词汇噪声/营销词干扰；Inventory Void——有效意图但库存为零）；(c) Precision Failure（精度不足，分两维：Bias Perception——检索器实体漂移或粒度不匹配；Gap Perception——用户词汇与商品属性的对齐缺口）。基于诊断结果，教师生成三类执行路径：Preservation（保留原 query）、Sanitization（去除噪声）、Concretization（将模糊意图转化为精确可检索表达）。教师以温度 τ>0 随机采样生成多个候选计划，对每个计划验证其检索结果，只保留执行成功的计划，最终构建包含 100k 条 (query, O_init, P) 三元组的 SFT 数据集 D_sft。

Stage 2：规划器训练与业务对齐。以 Qwen3-4B 为学生规划器，先在 D_sft 上做 2 epoch SFT，使其内化教师的诊断推理模式。随后用 GRPO（Group Relative Policy Optimization）做业务对齐：对每个输入采样 G=8 个计划，每个计划执行后检索 Top-K 商品，奖励函数为：

R(P_i) = (1/K) × Σ [I(φ_rel(q,d_j) ≥ τ) · φ_cvr(q,d_j)]

即硬相关门控 × CVR 预估值的均值。硬相关门控 I(·) 确保只有通过相关性阈值的商品才贡献转化收益——防止模型为追求高 CVR 而召回不相关高价值商品，是防止奖励篡改的关键设计。RL 在 5k 高频、高方差 query 子集上运行，使用 8 台 NVIDIA H800 GPU。

Stage 3：自适应在线服务。以 Qwen3-0.6B 为复杂度感知路由器，将 query 分流：约 80% 的明确产品 query（如「iPhone 17 256G」）走 Fast Path，直接检索，延迟 p75 < 20ms；复杂 query 走完整 EASP 管线，延迟 p99 < 700ms。

3. 核心技术贡献（~400字）

贡献一：规划与环境解耦的 Probe-then-Plan 范式。区别于 Blind Rewriter（完全忽略检索状态）和 ReAct Agent（检索-反思交替迭代），EASP 将「单次环境感知」与「单步规划」解耦为两个轻量操作，在保留感知能力的同时消除迭代延迟。离线消融验证：移除 Probe 后 REL@30 从 23.3 降至 20.7（-2.6pp），证明环境感知是核心增益来源。

贡献二：GRPO 业务对齐——相关性门控 + CVR 的奖励设计。SFT-only 方法在 REL@30 上接近 EASP（23.0 vs 23.3），但 HR@30 显著低于 EASP（29.5% vs 31.0%），说明 SFT 擅长模仿教师行为但无法直接优化购买命中率。GRPO 以「购买命中」为终态奖励，将语义相关与转化信号对齐，弥补 SFT 与业务指标的鸿沟。

贡献三：结构化诊断分类体系。将检索失败分解为 Recall Failure（Query Noise / Inventory Void）和 Precision Failure（Bias Perception / Gap Perception），为每类失败提供对应处理策略（Sanitization / Concretization），使模型能够区分「无库存」（应放弃改写）和「词汇偏差」（应换词）两种本质不同的问题，比简单的 query 改写具有更精细的控制。

贡献四：轻量级 0.6B 路由器降低整体延迟。80% Fast Path 绕过规划，使平均延迟大幅低于单纯部署 EASP 管线，是工业落地的重要工程贡献。

4. 实验结果分析（~600字）

离线评测（10k 复杂 query）核心指标：REL@30（Top-30 中相关商品数）和 HR@30（购买商品是否出现在 Top-30）。

关键发现：

• EASP 的 REL@30 略低于 ReAct（-0.8pp），但 HR@30 反超 ReAct（+0.8pp）。这一交叉说明 GRPO 的奖励设计有效地将「商品相关」与「用户购买」对齐，而 ReAct 的反思迭代虽能召回更多相关商品，但召回的商品不一定是用户会购买的那一个。
• SFT-only 的 REL@30 与 EASP 相近（差 0.3pp），但 HR@30 低 1.5pp，验证了 GRPO 在业务指标对齐上的独立贡献。
• Blind Rewriter 与 EASP 之间 REL@30 差距达 2.6pp，是所有消融中最大的单因素影响，确认 Probe 是系统核心。

在线 A/B 测试（JD.com，2周，10% 流量）：

全流量结果因 ~80% 简单 query 走 Fast Path 而被摊薄；在复杂 query 子集上，UCVR +4.10% 和 GMV +2.59% 的提升是相当显著的工业增益，验证了 EASP 在真实商业场景中的价值。延迟方面：Fast Path p75 < 20ms，复杂路径 p99 < 700ms，完全满足亚秒级工业约束。

一个值得注意的 surprising result：ReAct Agent 在离线 REL@30 上高于 EASP，但在线环境中 EASP 的业务指标更好。这提示「相关性」指标与「转化」指标存在分离，多轮反思不总是带来更好的业务结果，单步规划在有限信息下已接近「足够好」的决策点。

5. 局限与未来方向（~300字）

作者明确指出的局限：EASP 当前聚焦 query 级别规划，未整合用户个性化信号。相同的「蓝色运动鞋」query 对不同用户应有不同的检索策略（跑步爱好者 vs. 篮球爱好者），但当前系统对此无感知。作者明确列出用户行为信号整合作为下一步工作，扩展至会话级优化。

作者未明确指出但显而易见的局限：(1) Probe 的检索快照质量直接影响规划质量——若初始检索召回集本身存在系统性偏差（如索引覆盖不均），Planner 将基于有偏快照做出有偏计划，无法自我纠偏；(2) GRPO 奖励中的 CVR 预估模型（φ_cvr）质量是隐含的上界约束，若 CVR 模型对某类商品存在偏差，奖励信号也会传递这种偏差；(3) 教师模型 DeepSeek-R1 的分类诊断是在离线阶段完成的，若新品类/新意图不在训练分布内，学生规划器的泛化能力需要持续监控。

6. 工业实践意义（~400字）

对社区搜索和 UGC 平台的直接可迁移经验：

(1) Probe-then-Plan 的社区搜索适配：社区搜索中的「库存」即帖子/回答索引。Probe 可设计为：给定 query，先做一次轻量 BM25 或向量检索，检查召回集的相关性分布和覆盖情况；若召回为空或平均相关性低于阈值，触发 query 改写；否则直接进入精排。这个判断逻辑比无条件改写更节省算力，且能避免「改写导致召回变差」的常见问题。

(2) GRPO 奖励设计的参考：将 GRPO 奖励替换为社区搜索的「点击率 + 相关性」组合，即：R = I(相关性 ≥ τ) × CTR_预估，可让 query 改写模型直接优化用户点击而非中间指标。硬相关门控的设计尤为重要——它防止模型学习「改写为热词」（高 CTR 但语义偏移）的捷径策略。

(3) 结构化诊断框架的借鉴：Recall Failure vs. Precision Failure 的分类对搜索系统调试极具参考价值。Query Noise 对应 UGC 搜索中用户输入口语化/表情符号/错别字等问题；Inventory Void 对应特定长尾内容的索引缺失；Bias Perception 对应 embedding 召回偏向高热内容的问题；Gap Perception 对应用户词汇（「好看的穿搭」）与内容标签（「OOTD」）的对齐缺口。针对这四类问题应有不同的处置策略，而非统一做 query 改写。

(4) 路由器设计：80% Fast Path 的设计对资源受限团队尤为重要——不需要对所有 query 启用 LLM 推理，只有真正「难」的 query 才值得额外计算预算。这一原则可直接应用于 UGC 搜索，通过 query 难度预测模型分流，将 LLM 算力集中在长尾复杂意图上。

(5) 延迟 SLA 的工程意义：本文提供了实际部署参考值：Fast Path p75 < 20ms，完整 EASP p99 < 700ms。对于需要在搜索链路中引入 LLM 规划的团队，这两个数字是可参照的工业基准。