广州网站建设南宁网站域名实名认证怎么做

当前位置： 首页 > news >正文

广州网站建设南宁,网站域名实名认证怎么做,国外域名需要实名吗,apk开发参考#xff1a;https://blog.csdn.net/UbuntuTouch/article/details/139502650 检索器#xff08;standard、kNN 和 RRF#xff09; 检索器#xff08;retrievers#xff09;是搜索 API 中的一种新抽象概念#xff0c;用于描述如何检索一组顶级文档。检索器被设计为可以…参考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 doesnt 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博客