阅读量:0
参考：https://blog.csdn.net/UbuntuTouch/article/details/139502650
检索器（standard、kNN 和 RRF）
检索器（retrievers）是搜索 API 中的一种新抽象概念，用于描述如何检索一组顶级文档。检索器被设计为可以嵌套在树形结构中，因此任何检索器都可以拥有子检索器。检索器是一种标准、更通用且更简单的 API，它取代了其他各种搜索元素，如 kNN 和查询。在 8.14 版本中，我们引入了对三种类型的检索器的支持：
Standard — 提供标准查询功能
kNN — 启用基于 HNSW 的密集向量搜索
RRF — 使用倒数排名融合算法将不同的密集和稀疏向量排名结果集合并成一个单一的混合和排序的结果集
检索器方法的两个主要好处是：
所有检索器的结构都是相同的，因此它们更容易学习、编写和维护。
设计成可以在树结构中组合使用，提供了更多的灵活性来设计之前无法定义的查询 —— 例如，不将 kNN 或 RRF 作为顶级元素。
引入检索器是我们简化搜索使用、特别是向量搜索使用的又一步。这一主题包括了像自动向量标准化以实现更高效的余弦相似度和引入 RRF 以便无需调整即可实现高质量混合集的增强功能。我们将继续在这方面进行大量投资，并计划在未来通过我们新的 ES|QL 语言引入相关性排名。
有关将 RRF 与检索器一起使用的其他示例，请参阅此博客。
使用 SIMD (Neon) 针对 int8 向量优化向量距离函数
Elasticsearch 现在使用本机代码使用 SIMD (Neon) 进行向量比较，以提高 ARM AArch64 架构处理器上的性能。此增强的详细信息将在向量相似性计算 - 可笑的速度中讨论。最重要的是，int8 向量的段合并速度比这些处理器上的速度快几倍（通常快 3-6 倍）。此改进为其他任务释放了资源，并加快了段大小优化过程。
这是一系列向量相似性性能改进的又一步。将来，我们打算在其他上下文中使用这种优化，例如改善查询延迟。
密集向量场默认采用 Int8 量化
许多模型生成带有 float32 元素的向量。然而，在检查现实生活场景时，很快就会发现 int8 元素提供了更好的承诺，具有更小的索引（更低的成本）、改进的摄取性能和改进的查询延迟。所有这些都是在几乎不影响排名质量的情况下实现的。有时在质量指标（例如 NDCG 或召回率）排名中可以发现的微小影响可以通过增加正在考虑的候选者数量来轻松减轻。但即使没有这一点，最终用户通常也不会注意到这种变化，从业务角度来看也是如此。
考虑到这一点，我们在 8.12 中向 int8 引入了标量量化。在检查了此功能的生产使用后，我们决定将其设为新索引的默认行为。提供这样的合理默认值可以让用户更轻松地迈出向量搜索的第一步。
参考：回顾相关性：平衡关键字和语义搜索_关键词搜索和语义搜索-CSDN博客
词汇搜索工具箱
像 BM25 这样的文本搜索算法已经存在了几十年，事实上 BM25 经常与文本搜索同义使用。 这篇博文详细介绍了 BM25 的工作原理。
分析器、分词器、过滤器、字段权重和增强都是我们的词法搜索工具箱中的工具，它们使我们能够以非常特定的方式转换文本，以支持一般和非常专业的搜索用例。
但我们还有很多其他工具可供使用：
重新排名是该工具箱中的另一个强大工具，无论是学习排名、语义重新排名等。
同义词在关键字搜索中大量使用，以区分俚语、特定领域的行话等。 通用模型可能无法很好地处理非常小众的同义词。
这些工具用于影响相关性，但更重要的是适应业务规则。 业务规则是自定义规则，它们的用例差异很大，但通常包括使结果集多样化或基于上下文查询结果或其他个性化因素显示赞助内容。
Elasticsearch：实用 BM25 - 第 2 部分：BM25 算法及其变量_bm25算法得到结果样式-CSDN博客
语义搜索并不完美
语义搜索在代表你寻找的内容意图方面非常有效，即使返回的结果不包含你指定的确切关键字，也能返回匹配的结果。然而，如果你正在开发一个搜索应用并将语义搜索纳入现有技术栈，那么语义搜索并非没有一些缺陷。
这些缺陷主要分为三类：
成本
语义搜索本身尚未具备的功能
语义搜索单独无法很好处理的查询
成本可能是金钱（训练或许可模型、计算），也可能是时间。时间可以是延迟（摄入或搜索推断延迟），也可以是开发时间的成本。我们不希望在那些可以用现有工具轻松解决的问题上浪费宝贵的工程时间，而是将这些时间用于解决需要工程关注的难题。
还有许多人们在其搜索解决方案中希望拥有的功能；例如，高亮显示、拼写纠正和错字容忍。这些都是语义搜索当前原生支持度较低的功能，但许多 UI/UX 人员将这些视为用户功能的基本要求。
至于语义搜索可能不擅长处理的查询，通常是一些特定领域的查询。例如：
像型号编号这样的精确匹配
领域专业术语
我们还必须考虑包括业务规则（例如基于流行度、转化率或活动的提升）在内的要求，这些语义搜索本身可能无法本地处理。
查询理解是另一个问题。这可能是简单的数字转换和度量单位处理，也可能是非常复杂的处理，比如处理否定语句。你可能曾经有过令人沮丧的搜索经历，例如搜索 “I want a restaurant that doesn't serve meat - 我想找一家不提供肉类食品的餐厅”。LLM 在这里返回素食餐厅可能还可以，但大多数语义搜索会返回提供肉类食品的餐厅！
混合搜索的优势所在
混合搜索结合了两全其美的优点：它将 BM25 文本搜索的精确性和功能性与向量搜索的语义理解相结合。这导致了更好的召回率和更高的整体相关性。
让我们来看一些例子：
房地产：Modern farmhouse with lots of land and an inground pool in the 12866 zip code - 位于 12866 邮政编码区的现代农舍，拥有大片土地和一个地下游泳池。是否有游泳池及其邮政编码可以作为过滤条件，而风格描述可以使用语义搜索。
电子商务：Comfortable Skechers with memory foam insoles in purple - 带有记忆海绵鞋垫的紫色舒适斯凯奇鞋。颜色和品牌可以作为过滤条件，其余部分可以通过语义搜索来处理。
求职：Remote software engineer jobs using Elasticsearch and cloud native technologies - 使用 Elasticsearch 和云原生技术的远程软件工程师职位。职位名称和远程工作偏好可以作为过滤条件，而工作技能可以通过语义搜索来处理。
在 Elasticsearch 中，混合搜索是什么样子的？
当前，“hybrid search - 混合搜索” 这个术语有点流行，不同的场景下人们可能会有不同的理解。在一些系统中，如果你有一个单独的向量数据库，这可能涉及到对不同数据存储的多次调用，并将它们与一个服务结合起来。但是，Elasticsearch 的一个超能力是所有这些都可以结合在一个单一的索引和一个搜索调用中。
在 Elasticsearch 中，混合搜索可能像一个布尔查询那样简单。这里有一个 Elasticsearch 中布尔查询结构的示例，它结合了文本搜索、KNN 搜索、文本扩展查询和其他支持的查询类型。当然，这可以与重新评分以及其他使 Elasticsearch 如此强大的功能结合使用。布尔查询是将这些文本和向量搜索结合成一个单一查询的非常简单的方法。
在 8.12 版本中
另一种选择是使用 retrievers，从 Elasticsearch 8.14.0 开始，检索器是描述这些复杂检索管道的更简单的方法。 下面是一个示例，它将标准查询与 kNN 查询结合起来作为 retriever，所有这些都汇总起来以使用倒数排名融合 (RRF) 对结果进行排名。
合并结果集
现在你有了一个混合搜索查询，如何将所有这些合并成一个单一的结果集呢？这是一个难题，特别是当分数几乎肯定会因结果检索方式的不同而大相径庭时。
经典的方法，使用布尔查询示例，是采用线性组合，在较大的查询中对每个单独子句应用提升。这是一种经过验证的、老式的技术，我们都熟悉并喜爱，但它可能会很棘手。它需要调整才能得到正确的结果，而且你可能永远也无法做到完美。
如果你使用 retrievers，你也可以使用 RRF。这更容易 - 你可以依赖一个算法，而不需要做任何调整。但也存在一些折衷 - 你对结果集的精细控制更少。RRF 不考虑 BM25 的提升，因此如果你在业务规则上进行提升，可能无法立即获得想要的结果。
最终，你应该选择的方法取决于你的数据和你的用例。
调整词汇搜索相关性
一旦你创建了查询，为了提高相关性进行调整是一个难题，但你有几种可用的工具：
业务指标。从很多方面来说，这些是最重要的指标：用户是否点击了结果，在电子商务用例中，更好的是他们是否完成了购买？你的转化率是否在增加？用户是否花了相当多的时间阅读你网站上的内容？这些都是用户体验的衡量标准，但它们是通过分析收集的，它们是是否你的搜索提供了实际有用的结果的直接证明。对于像 RAG 这样的用例，结果是定制的、主观的，并且可能会发生变化，这可能是真正衡量你的搜索变化影响的唯一方法。
用户调查。为什么不问问用户他们认为结果好还是不好呢？你必须考虑一些因素，比如用户是否会提供真实的回答，但这是了解用户对你的搜索引擎的看法的好方法。
定量衡量相关性的方法，如 MAP 和 NDCG。这些指标需要判断列表，然后也可以用于学习排序。
然而，人们可能会陷入的最大陷阱是为一个或几个 “pet - 宠物” 查询进行调整：你或者你的老板输入的少数查询。你可以改变算法的所有内容，以获得该查询的最佳结果，但这可能会在下游产生连锁效应，因为现在你无意中已经搞乱了大部分其他查询。
语义搜索不会取代 BM25 搜索，而是对现有搜索技术的增强。 混合搜索解决了语义搜索固有的许多问题，并且在召回率和功能方面都是两全其美。 语义搜索确实在长尾查询和躯干查询中大放异彩。 查询规则和同义词等工具可以帮助提供最佳的搜索体验，同时释放开发人员宝贵的时间来专注于解决重要问题。
参考：Elasticsearch：介绍 kNN query，这是进行 kNN 搜索的专家方法_knnquery-CSDN博客
Elasticsearch：实用 BM25 - 第 2 部分：BM25 算法及其变量_bm25算法得到结果样式-CSDN博客
