小红书精读：Generative Retrieval under Real-Time Supply Constraints in Local Commerce

🛒生成式检索别把beam浪费在无效商家

各位算法同学们，先甩个反常识结论：在本地生活场景里，生成式检索给出的商家 ID 在 catalog 里完全合法，也照样可能是一家此刻送不到你手上的店。这篇把“供给幻觉”单独拎出来分析，还给了工程侧的解法。

📄 Generative Retrieval under Real-Time Supply Constraints in Local Commerce

🔧 把可服务的 SID 编译成请求级 CSR 前缀索引，CPU 解析排序编译与模型 prefill 并行，索引上传后所有 beam 共用一份 🧩 非法扩展直接剪枝，合法候选仍用原模型 log prob 比较，约束状态跟着选中 beam 的父节点走，避免 beam 复制后状态错位 ⚙️ 概念上拆开三件事：catalog 有效性、请求级可服务性、新鲜度；后置过滤省不掉已经花掉的 beam 名额和推理算力

📊 同 beam 对比的日更约束场景，299 个候选里被过滤掉的商家从 170 个降到 29 个 📈 C++ 排序约 3ms，CSR 构建约 1ms，编译这步确实不便宜 ✅ 跨机器、3 万条供给条目对比，服务侧延迟只增加 0.6ms，但客户端实测还暴露出额外请求开销

总结：这是一篇偏工程落地的报告，作者自己也写明尚未证明“同等检索质量下省了算力”。要盯的指标是 GPU 时间除以有效输出数，再加零结果率，基线该选后置过滤而不是全局 catalog 树。坑在上游：供给集合漏了或老化了，mask 再准也救不回来，而且三 token 短序列本来就没几步可摊薄传输和编译成本。

原文：AlphaXiv