跳转到主要内容

语义搜索作为产品:当检索理解意图时,什么发生了改变

阅读需 1 分钟Tian PanTian Pan

大多数构建语义搜索的团队都从 RAG 概念验证出发:对文档分块、生成嵌入向量、存储到向量库、用余弦相似度查询。在演示中效果不错。然后他们把它发布给用户,结果有一半的查询以与检索质量毫无关系的方式失败了。

原因在于 RAG 和面向用户的语义搜索解决的是不同的问题。RAG 在问"给定一个问题,检索上下文供 LLM 回答"。语义搜索在问"给定用户的查询,呈现真正符合其需求的结果"。第二个问题有一层 RAG 基准系统性忽视的复杂性——而这种复杂性几乎完全存在于检索开始之前。

所有人都忽视的检索前问题

在 RAG 管道中,查询通常是结构良好的。有人提出一个问题,系统检索上下文,LLM 给出回答。查询很少模糊,因为通常是人或另一个 LLM 在刻意组织它。

真实用户不会刻意组织查询。他们在想了解 sort()sorted() 区别时,会输入"python sort list reverse"。他们的意思是"OAuth refresh token 过期处理",却搜索"login not working"。他们缩写、拼写错误、使用文档中根本没有的内部术语,同一个会话里重新表述三次却始终找不到想要的内容。

结果就是:面向用户的语义搜索中,有相当大比例的失败发生在任何向量被触及之前。如果你像监控 RAG 管道一样监控系统——跟踪检索召回率、检查返回文档是否相关——你就会错过那些查询本身从未公平测试过索引时所发生的失败。

检索前失败有几种具体形式:

  • 查询与语料库的词汇不匹配:用户的措辞与语料库描述同一概念的方式几乎没有语义重叠。嵌入模型可以处理同义改写,但对于训练数据中未出现的领域特定缩写、首字母缩略词或行话则举步维艰。
  • 表述不足的查询:短小模糊的查询会产生质量平庸的嵌入。"How to do authentication"生成的向量与数十个文档等距,检索返回的是噪声样本而非排名结果。
  • 多意图查询:"Is product X worth buying and where can I get it cheapest"包含两个独立意图。单个嵌入向量无法忠实表示两者。传统嵌入模型每个查询只产生一个表示,该表示在两种意图之间插值,而非服务于任何一个。

解决检索前失败的方案不是更好的嵌入模型,而是查询预处理——一个发生在向量查找之前的步骤。

查询改写是最大的杠杆点

所有构建出高留存率搜索产品的团队都会进行某种形式的查询规范化。最简单的版本:拼写校正和同义词扩展。更复杂的版本:神经查询改写,将模糊的用户输入转化为与语料库结构相匹配的查询。

生产搜索系统的核心洞察是:用户查询和文档语言是由目标不同的人写就的。文档是为了传递信息而写;查询是为了检索而写。搜索"why does my connection keep dropping"的用户,找的是可能描述"间歇性连接问题"或"TCP 超时配置"的文档。这两种表述几乎没有共同词汇。

查询改写通过将用户的查询重写为更匹配索引的形式来弥合这一差距——不是改变用户想要什么,而是把他们的表达方式翻译成检索系统能够实际服务的形式。

行为信号使这个循环能够自我改进。当用户在一个会话中改写查询——先输入"python list sort",看到令人失望的结果后,再尝试"python sorted function descending"——他们就给了你一对高质量的训练样本。第一个查询是输入,第二个是更好的版本。在规模化之后,这些会话级改写链条成为查询改写模型的训练数据,无需任何标注开销便能持续改进。

这就是为什么像监控 RAG 一样监控产品的搜索团队会错过一半失败。RAG 评估问"检索到的文档与查询相关吗?"它不问"用户是否改写了三次才放弃?"后者才是能告诉你搜索产品是否真正有效的问题。

多意图查询需要不同的架构

单嵌入检索在查询只有一个意图时有效。许多用户查询并非如此。

处理多意图查询的标准方法是在查询层面检测意图,并路由到专门的检索器。关于产品库存的查询可能去商品目录索引;关于产品故障排除的查询可能去支持文档索引;同时包含两者的查询则由能够合并两者结果的系统处理。这并不复杂——就是一个分类器加一个路由层——但其表现远优于试图从单个通用嵌入搜索服务所有意图。

更先进的架构使用神经多意图表示(NMIR)模型,为每个检测到的意图生成不同的查询嵌入。你得到的不是一个代表查询的向量,而是一组向量,每个向量针对不同的方面。检索在所有向量上进行,重排序步骤决定哪些结果最能满足意图的组合。

架构层面的含义是:面向用户的语义搜索需要一个位于检索系统上游的查询理解层。该层负责意图检测、查询扩展、消歧和改写。在 RAG 中,这一层要么不存在,要么由构建检索查询的 LLM 隐式处理。在搜索产品中,它需要是显式的、有监控的——因为它是大多数机会和大多数失败所在之处。

行为信号取代人工相关性判断

会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 10 分钟

RAG 流水线中被你忽略的查询重写层

大多数检索失败源于查询形态的问题,而非嵌入模型本身。本文将深入探讨 HyDE、查询分解、多查询并行分发以及排名融合等技术,并教你如何在盲目更换编码器之前,诊断出你的 RAG 流水线真正需要的优化方案。

insider
rag
阅读需 9 分钟

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

基于嵌入的检索针对的是那些明确知道自己想要什么的用户。对于其他用户,它往往默默地失效了 —— 本文将介绍如何识别浏览意图并优化你的排名策略。

search
retrieval
阅读需 9 分钟

P99 是产品决策,而非基建决策

你的尾部延迟目标并不是基建团队单纯优化出的一个数字 —— 这个数字本身就是一个产品选择。本文探讨了 UX 交互设计与延迟预算如何相互权衡,以及为什么 P99 应该出现在设计评审中。

insider
latency
阅读需 9 分钟

检索流水线的数据驻留:那些跨境而去的 Embedding,以及并未跨境的 LLM 调用

你的推理端点固定在法兰克福,但你的 Embedding API、向量控制平面、重排序(Rerank)服务、Prompt 缓存和追踪存储却并非如此。本文将深入探讨 RAG 请求中的六个数据驻留层面,以及每个环节在不知不觉间跨境传输时所存在的组织架构差距。

insider
data-residency
阅读需 8 分钟

你的检索管道从未衡量的中间上下文盲区

当 Retrieval@10 指标依然处于绿色安全状态时,回答质量却在下滑。这种差距源于一种 U 型注意力偏差,它存在于检索团队和提示词团队之间的交界处,而双方的监控面板都无法察觉模型从未读取过的那段内容。

insider
rag