发现难题：为什么语义搜索会让浏览型用户失望

向量搜索正在吞噬世界。基于嵌入（Embedding）的检索现在为各大电商平台的商品搜索提供动力，驱动着 RAG 系统的检索层，并处于大多数 AI 驱动的搜索重写（search rewrites）的核心。但有一类用户，这些系统一直在默默且持续地令其失望：即“浏览型用户”（browsing user）。这并不是因为嵌入模型不好，而是因为它们被设计用来解决一个完全不同的问题。

语义搜索背后的基本假设是：用户带着一个与其需求相近的查询（query）而来。只要在嵌入空间中优化与该查询的邻近度（proximity），你就赢了。但很大一部分真实用户带来的更像是“好奇心”而非具体的查询——对于他们来说，向量空间中的最近邻（nearest neighbors）恰恰是错误的答案。

查找 vs 探索：两种根本不同的搜索模式

每个搜索系统都在同时服务于两类群体，而大多数系统却将他们混为一谈。

查找型用户（Lookup users）知道自己想要什么。他们有精确的信息需求，正在寻找特定的事实、产品或文档。他们的会话表现为：一次查询，点击第一或第二个结果，结束。成功意味着精确度（precision）——即正确答案就在最上方。

探索型用户（Exploratory users）不知道自己想要什么，或者他们了解领域但不确定具体的答案。他们可能会搜索“户外爱好者的送礼创意”、“关于推荐系统的机器学习论文”或“男士保暖夹克”。他们的会话表现为：多次重新表述（reformulations）、分散点击各种结果、较长的停留时间以及频繁的回退。成功意味着覆盖面（coverage）和惊喜感（serendipity）——即看到足够广阔的空间以做出明智的决定。

关于查询重构模式的研究表明，探索型用户会以特征明显的方式重构查询：专门化（从宽泛到细化）、泛化（陷入困境时扩大范围）以及横向移动（探索相邻概念）。“查找该嵌入的最近邻”无法很好地服务于这些行为。

这种失败在标准指标中是隐形的。如果你衡量所有查询类型的平均 precision@5，查找型查询会支撑起你的综合评分。探索型查询在悄无声息中表现不佳，却不会拖累标题数据。

为什么嵌入不是探索的正确工具

基于嵌入的检索将查询和文档编码为高维向量，然后找到向量与查询向量最接近的文档。隐含的假设是“最近”意味着“最相关”。对于查找型查询，这个假设足够有效。对于探索，它会产生预料之中的失败模式：一堆相似的文档，全部聚集在查询附近，缺乏多样性。

理论上的解释不仅仅是直觉——它还是一种数学约束。嵌入维度直接限制了模型能够表示的不同 top-k 文档组合的数量。对于任何固定的嵌入维度，都存在一些相关文档的组合，无论你如何表述查询都无法触及。这不是通过扩展维度就能弥补的差距，而是压缩过程的一个基本属性。

实际后果是可衡量的。最近对检索任务的基准测试发现，在答案集少于 50 个文档的相对简单的匹配任务中，最先进的嵌入模型实现的 recall@100 不到 20%。余弦相似度检索的前 5 个结果中，有近一半与查询意图无关——仅仅是它们在嵌入空间中离得比较近。

对于探索型用户，问题更加复杂。他们对该领域的了解不足以形成精确的查询。短促、模糊的查询——如“蔬菜园”、“日本旅行”、“投资基础”——为嵌入模型提供的信号不足以区分意图。模型返回的结果往往聚集在这些词项的主流含义周围，错失了真正存在探索价值的长尾分布。

在查询时检测浏览意图

意图信号虽然有噪声，但是可以检测的。构建搜索系统的工程师可以针对这些信号进行监测：

查询特征：

• 不含特定标记（品牌名、产品 ID、专有名词）的短促、高熵词汇与探索意图相关
• 比较性术语（“vs”、“替代品”、“类型”）是强烈的探索信号
• 缺乏限定符、否定词或约束条件表明用户尚未致力于特定的子空间

会话行为：

• 点击熵（点击在不同 URL 域名上的分散程度）是一个强有力的消歧信号。查找型会话的点击较为集中；探索型会话则较为分散
• 在短时间内多次快速重构查询表明用户正在导航，而非获取
• 在结果页面停留时间较长，随后进行回退，表明是在评估选项而非提取事实

随时间变化的点击模式：

• 针对给定查询领域持续重构并点击多样化结果的用户，表明该领域对该用户而言本质上是探索性的
• 在会话开始时的个性化意图建模可以动态地为这些信号加权

这些信号可以将用户实时引导至不同的检索配置——为查找模式提供更严谨的精确度，为探索模式提供权重偏向多样性的结果。路由逻辑不需要完美，即使是粗糙的意图分类也能提高整体满意度。

服务于探索的排序策略

一旦你接受了探索需要不同的检索逻辑，几种实用的方法就派上用场了。

最大边际相关性 (MMR)

MMR 通过迭代选择结果来重新排列候选结果集，这些结果既要与查询相关，又要与已选结果具有最大的差异性。每个选择步骤对候选结果的评分如下：λ × relevance − (1 − λ) × max_similarity_to_selected。参数 λ 控制相关性与多样性之间的权衡。

对于探索意图，λ 在 0.3–0.5 范围内效果较好。对于查找意图，将 λ 推向 0.8–0.9。该算法作为现有系统上的检索后重排序（post-retrieval reranking）步骤，实现起来非常简单 —— 它作用于候选池，而非检索机制本身。

混合搜索中的倒数排名融合 (RRF)

混合搜索 —— 并行运行关键词（BM25/稀疏）和语义（稠密向量）检索，然后进行合并 —— 解决了问题的另一个层面。BM25 捕捉词汇精度：精确的产品名称、特定领域的专业术语、SKU 以及嵌入模型在分布外（out-of-distribution）难以处理的术语。稠密检索则捕捉语义意图和改写。

RRF 合并两个排名列表而不依赖于原始得分：每个文档的融合得分是其在出现的列表中 1 / (rank + k) 的总和，其中 k 是一个平滑常数（通常为 60）。在两个列表中都出现的文档会获得巨大的加分 —— 与纯语义检索相比，这往往会使既具有词汇相关性又具有语义恰当性的结果脱颖而出，从而向多样性倾斜。

基准测试一致表明，在混合意图查询集上，混合搜索的表现优于任何一种纯检索方法 15–25%。对于探索密集型的产品搜索，提升幅度更大。

作为探索界面的分面导航

分面界面（Faceted interfaces）将探索问题从排序算法转移到了用户身上。分面并不是试图预测用户想要哪些结果子集，而是让结果空间的维度变得可见且可操作。不知道自己想要什么的用户可以通过约束条件 —— 价格、类别、属性、评分 —— 进行导航，逐步探索空间。

工程上的权衡是真实存在的：分面界面增加了 UI 复杂度，并要求你的语料库中具有一致的结构化元数据。对于产品目录和文档库，这项投资通常是值得的。对于非结构化语料库（通用网络搜索、原始文档检索），可靠地生成分面会更加困难。

评估中的惊喜度指标

标准的相关性指标（NDCG、precision@k）无法衡量探索质量，因为它们不惩罚冗余。一个包含五个几乎完全相同文档的列表，得分与涵盖查询五个不同维度的多样化列表相同。

α-nDCG (alpha-NDCG) 直接解决了这个问题：它是 NDCG 的扩展，跟踪查询的哪些子话题已被每个后续结果覆盖，惩罚那些重复已覆盖内容的文档。针对 α-nDCG 而非标准 NDCG 优化的系统会产生明显更多样化的结果集。

推荐系统研究中的惊喜度（Serendipity）通常被形式化为 unexpectedness × relevance：一个结果必须既相关又不显而易见，才能算作惊喜。在你的评估套件中构建明确的惊喜度信号，会迫使你衡量并优化探索用户真正需要的指标。

最终的架构形态

大规模生产系统 —— 电子商务平台、大型文档检索、企业搜索 —— 通常会收敛于一种通用模式：

1. 广泛检索：在一个巨大的候选池中并行运行 BM25 和稠密检索
2. 使用 RRF 合并：使用排名融合混合这两个列表，以提升在两者中都出现的文档
3. 检测意图信号：从可观察的信号中对查询级和会话级的意图进行分类
4. 带有多样性权重的重排序：应用 MMR 或将意图类别作为输入的学习型重排序器 —— 对于查找意图，相关性要求更紧密；对于探索意图，MMR 的 λ 趋向 0.4
5. 在语料库支持的地方展示分面：对于结构化语料库，将分面作为并行的导航界面呈现

意图分类步骤是大多数团队投入不足的地方。即使是简单的启发式方法 —— 查询长度、比较词的存在、会话重构次数 —— 也能显著提高路由决策的质量。更复杂的方法会在源自历史会话的点击熵（click entropy）标签上训练分类器。

纯语义搜索无法弥合的鸿沟

深层次的问题在于，探索型用户不仅没有得到语义搜索的良好服务，反而被它误导了。嵌入模型返回具有高置信度得分的结果，这些结果看起来相关，但其相关性的类型完全相同。一个搜索 “python web frameworks” 的用户，如果得到五个关于 Flask 的结果、三个关于 Django 的结果和两个关于 FastAPI 的结果，并没有真正看到这个空间。他们看到的只是空间的中心，权重取决于这些话题在训练数据中出现的频率。

好的探索并不是寻找最近邻。它是要给用户提供一个相关图景的真实样本 —— 包括那些他们甚至没有想到要直接查询的角落。这要求系统对空间进行建模，而不仅仅是对查询建模。

向量搜索是用于查找的强大工具。对于探索来说，它是一个必要但不充分的组件。那些能很好服务于浏览用户的系统，是那些已经工具化了意图、在排序目标中构建了多样性、并将 “帮助用户理解存在什么” 视为与 “找到用户要求的东西” 同等地位的一等产品需求的系统。

大多数搜索系统只优化了后者。