Hard Search vs Soft Search 怎么选?

我觉得这道题其实问的是，在推荐系统里处理超长用户行为序列时，怎么在检索效率和模型优化之间做取舍。SIM模型给出了两种思路，一个叫Hard Search，一个叫Soft Search。我先说结论：它们不是二选一的关系，实际落地往往是两阶段配合。

先说Hard Search。它的核心就是用[[近似最近邻]]，比如[[Faiss]]或者[[HNSW]]，从几亿的候选里快速捞出一小部分，比如几千个。效率确实高，毫秒级。但这里有个问题：ANN是近似检索，不是精确的，它可能会漏掉真正相关的item，这就是召回损失。而且训练的时候，这个操作是不可导的，你没法直接做梯度回传，得用一些技巧，比如强化学习或者Gumbel-Softmax，要么就搞成两阶段pipeline，先检索再训练，流程很复杂。

再讲Soft Search。它其实是用注意力机制，对所有候选算一个加权和，本质上是连续的、可导的，所以训练可以端到端。理论上它没有检索误差，因为每个候选都有权重。但问题来了，候选集规模受显存限制，你不可能把几亿个item都塞进注意力矩阵，所以实际得截断到几千个，那和Hard Search的候选规模差不多。而且还有一个坑：长尾item的注意力权重会非常小，梯度几乎为零，模型根本学不到它们，等于白费。另外Soft Search对温度参数很敏感，温度高了注意力均匀化，低了又变成hard selection，调起来挺麻烦。

所以你看，单独用哪个都有问题。真正的工程做法是两阶段：先用Hard Search做粗排，从十亿级快速降到千级，这一步保证效率；然后在截断后的子集上跑Soft Search做精排，这一步保证端到端优化。阿里就是这么干的。

这里有个关键风险点：Hard Search的索引更新有延迟。比如用户刚点了一个新商品，索引还没更新，那下次检索就捞不到，导致推荐滞后。所以上线我会特别关注索引的实时性，比如用增量更新或者分层索引。另外Soft Search的温度调节也很关键，我一般会先设一个中等温度，然后根据验证集上的召回率来调。

还有一个场景值得注意：如果候选池本身很小，比如只有几万个item，那Hard Search的优势就不明显了，直接全量Soft Search可能更简单。但大部分互联网场景都是亿级候选，所以两阶段还是主流。

所以我会把SIM的检索策略看成一种效率与质量的妥协。具体选哪种，取决于你的候选规模、对实时性的要求、以及训练pipeline的复杂度。我更倾向两阶段，因为能在不牺牲太多召回的情况下，保证训练的可控性。