asp 免费网站模板,网站关键词排名优化应该怎么做,网站开发 c,seo策略工具Elasticsearch Relevance Engine—为AI变革提供高级搜索能力[ES向量搜索、常用配置参数、聚合功能等详解]
今天要介绍的 Elasticsearch Relevance Engine™ (ESRE™)#xff0c;提供了多项用于创建高度相关的 AI 搜索应用程序的新功能。ESRE 站在 Elastic 这个搜索领域的巨人…Elasticsearch Relevance Engine—为AI变革提供高级搜索能力[ES向量搜索、常用配置参数、聚合功能等详解]
今天要介绍的 Elasticsearch Relevance Engine™ (ESRE™)提供了多项用于创建高度相关的 AI 搜索应用程序的新功能。ESRE 站在 Elastic 这个搜索领域的巨人肩膀之上并基于两年多的 Machine Learning 研发成就构建而成。Elasticsearch Relevance Engine 将 AI 的最佳实践与 Elastic 的文本搜索进行了结合。ESRE 为开发人员提供了一整套成熟的检索算法并能够与大型语言模型 (LLM) 集成。不仅如此ESRE 还可通过已经得到 Elastic 社区信任的简单、统一的 API 访问因此世界各地的开发人员都可以立即开始使用它来提升搜索相关性。 Elasticsearch Relevance Engine 的可配置功能可用于通过以下方式帮助提高相关性 应用包括 BM25f这是混合搜索的关键组成部分在内的高级相关性排序功能 使用 Elastic 的矢量数据库创建、存储和搜索密集嵌入 使用各种自然语言处理 (NLP) 任务和模型处理文本 让开发人员在 Elastic 中管理和使用自己的转换器模型以适应业务特定的上下文 通过 API 与第三方转换器模型如 OpenAI 的 GPT-3 和 4集成以根据客户在 Elasticsearch 部署中整合的数据存储检索直观的内容摘要 使用 Elastic 开箱即用型的 Learned Sparse Encoder 模型无需训练或维护模型就能实现 ML 支持的搜索从而在各种域提供高度相关的语义搜索 使用倒数排序融合 (RRF) 轻松组合稀疏和密集检索倒数排序融合是一种混合排名方法让开发人员能够自行优化 AI 搜索引擎以符合他们独特的自然语言和关键字查询类型的组合 与 LangChain 等第三方工具集成以帮助构建复杂的数据管道和生成式 AI 应用程序 克服生成式 AI 模型的局限性 Elasticsearch Relevance Engine™ 非常适合助力开发人员快速发展并应对包括生成式 AI 在内的自然语言搜索方面的这些挑战。 企业数据/上下文感知模型可能没有足够的与特定域相关的内部知识。这要源于训练模型的数据集。为了定制 LLM 生成的数据和内容企业需要一种方法来向模型馈送专有数据以便模型能够学会提供更相关、特定于业务的信息。 卓越的相关性Elasticsearch Relevance Engine 让整合来自私有来源的数据变得非常简单只需生成和存储矢量嵌入便可使用语义搜索来检索上下文。矢量嵌入是单词、短语或文档的数字化表示可以帮助 LLM 理解单词的含义及其关系。这些嵌入可以增强转换器模型的输出速度和规模。此外ESRE 还可让开发人员将自己的转换器模型引入到 Elastic 中或与第三方模型集成。 我们也意识到后期交互模型的出现使我们能够提供这种开箱即用型的功能而无需对第三方数据集进行大量训练或微调。由于并非每个开发团队都有资源或专业知识来训练和维护 Machine Learning 模型也不了解如何在规模、性能和速度之间进行权衡因此 Elasticsearch Relevance Engine 还提供了一个为跨不同域进行语义搜索而构建的检索模型 Elastic Learned Sparse Encoder。该模型将稀疏嵌入与传统的基于关键字的 BM25 搜索配对为混合搜索提供了一个易于使用的倒数排序融合 (RRF) 评分器。ESRE 从一开始就为开发人员提供了 Machine Learning 驱动的相关性和混合搜索技术。 隐私和安全数据隐私是企业如何通过网络和在组件之间使用和安全地传递专有数据的核心即使在构建创新的搜索体验时也是如此。 Elastic 提供对基于角色和基于属性的访问控制的原生支持以确保只有那些有权限访问数据的角色才能看到数据即使对于聊天和问题回答应用程序也可以进行如此设置。Elasticsearch 可以支持您的组织保持某些文档可供特权个人访问的需求从而帮助组织维护所有搜索应用程序的通用隐私和访问控制。当隐私是最重要的关注点时将所有数据保留在组织的网络内不仅至关重要而且是强制性的。从允许组织在气隙环境中实施部署到支持访问安全网络ESRE 提供了您所需的各种工具助力您的组织保护数据安全。 规模和成本由于数据量以及所需的计算能力和内存使用大型语言模型可能会让许多企业望而却步。然而想要构建自己的生成式 AI 应用如聊天机器人的企业需要将 LLM 与他们的私有数据结合起来。 Elasticsearch Relevance Engine 为企业提供了一种可通过精确的上下文窗口高效提供相关性的引擎既有助于减少数据占用空间又不会增加工作量和费用。 过时模型在收集训练数据的时候就已被冻结在过去的某一时间点上。因此生成式 AI 模型所创建内容和数据只有在基于它们进行训练时才是最新的。整合公司数据是让 LLM 能够提供及时结果的内在需求。幻觉当回答问题或进行交互式对话时LLM 模型可能会编造一些听起来可信和令人信服的事实但实际上是一些不符合事实的预测。这也是为什么需要将 LLM 与具有上下文、定制的知识相结合的另一个原因这对于让模型在商业环境中发挥作用至关重要。 借助 Elasticsearch Relevance Engine开发人员可通过生成式 AI 模型中的上下文窗口关联到自己的数据存储。添加的搜索结果可以提供来自私有来源或专业领域的最新信息因此在有询问时可以返回更多的事实信息而不是仅仅依赖于模型所谓的“参数化”知识。 通过矢量数据库提高效率
Elasticsearch Relevance Engine 在设计上包含了一个具有弹性的生产级矢量数据库。它为开发人员提供了构建丰富的语义搜索应用程序的基础。使用 Elastic 的平台开发团队可以使用密集的矢量检索来创建更直观的问题回答而不受关键字或同义词的限制。他们可以使用图像等非结构化数据构建多模态搜索甚至可以对用户概要文件进行建模并创建匹配项以在产品和发现、求职或配对应用程序中个性化搜索结果。此外这些 NLP 转换器模型还支持情绪分析、命名实体识别和文本分类等 Machine Learning 任务。通过 Elastic 的矢量数据库开发人员可以创建、存储和查询嵌入这些嵌入具有高度可扩展性和优异性能适用于真正的生产应用程序。
Elasticsearch 特别适用于进行高相关性的搜索检索。通过 ESREElasticsearch 为与企业专有数据关联的生成式 AI 提供了上下文窗口让开发人员能够构建更吸引人、更准确的搜索体验。搜索结果是根据用户的原始查询返回的开发人员可以将数据传递给他们选择的语言模型以提供带有附加了上下文的答案。Elastic 利用来自您企业内容存储中的相关上下文数据为问题回答和个性化功能提供动力这些数据是私有的也是专为您的业务量身定制的。
https://www.elastic.co/cn/blog/may-2023-launch-announcement
1. ES 向量检索
KNNk-nearest neighbor search vs ANN search
KNN 检索给定一个 query vector寻找 K 个与之最相近的向量。数据量太时KNN 检索性能太差实际应用中一般采用 ANN 检索。
1.1 向量检索的步骤
将待检索的数据转换成向量表示比如将 “有商品曝光的 query” 通过 transformer 转换成 query embing 向量其表现形式则是128 维的 float 数组。将 float 数组 indexing 到 ES 的 dense_vector 类型的字段中。基于 ES 提供的 2 种向量检索方式进行搜索。这 2 种方式分别是近似 KNN 搜索的 ANN 搜索以及精确的暴力 KNN 搜索基于 script_score 查询实现
1.2 向量检索中的距离
如何衡量 2 个向量相似引入了向量之间的距离。常用的计算距离函数有 3 种
l2 norm欧式距离dot-product向量的点积cosine余弦相似度
1.3 两种向量检索方式 暴力 KNN 检索采用 ES 的 script_score 查询实现在 script 中指定计算距离的函数。 近似的 KNN 检索ANN与暴力检索相比我们可以采用某种算法牺牲一些精度来加速查找与 query vector 相似的向量。这种加速查找的算法最常用的如下 基于倒排 聚类的方式 IVF基于图的方式HNSW基于 LSH局部敏感 hash基于树结构 KD-tree
其中ES 的 ANN 检索采用HNSW 算法实现。向量检索工具包 faiss 则将上述各种算法都实现了。
以常见的欧式距离来算假设向量的维度为k,库总共有 n个item。则搜索一次的时间复杂度为 O(k*n)且整体的查询耗时与item库的大小线性相关显然这种线上查询要遍历成百万上千万的暴力计算并不满足需求。
考虑到向量检索的大部分场景都是返回与该元素相似的topk个元素即可比如推荐中的召回只需召回近似100个item也不关注item间的相对顺序也无需100%准确毕竟上游还会有粗排和精排。因此工程上会使用近似最近邻搜索(Approximate Nearest Neighbor Search)来解决这个精度和效率上的问题。
近似近邻搜索ANNS 由于暴力搜索是全局空间搜索因此为了提高查询效率大部分的ANN(Approximate Nearest Neighbor)近似算法的核心都是:将所有的数据集按照一定规则划分到一些子空间或者子集里然后查询的时候用比较低的代价确认在哪几个子集中搜索计算这样就避免了全局遍历。
ANN的方法分为三大类基于树的方法、哈希方法、矢量量化方法。brute-force搜索的方式是在全空间进行搜索为了加快查找的速度几乎所有的ANN方法都是通过对全空间分割将其分割成很多小的子空间在搜索的时候通过某种方式快速锁定在某一几子空间然后在该几个子空间里做遍历。
更多内容见推荐系统[九]项目技术细节讲解z3向量检索技术与ANN搜索算法[KD树、Annoy、LSH局部哈希、PQ乘积量化、IVFPQ倒排乘积量化、HNSW层级图搜索等]超级详细技术原理讲解
1.4 ES ANN 检索
将待查询的字段放在 “knn” option 里面发起查询示例如下 POST byte-image-index/_search { “knn”: { “field”: “byte-image-vector”, “query_vector”: [-5, 9], “k”: 10, “num_candidates”: 100 }, “fields”: [“title”] } 涉及的参数有
num_candidates在 ES 的每个分片上执行向量检索找到与 query-vector 最相近的num_candidates 个向量返回k对每个分片上的 num_candidates 个向量进行合并合并成全局的 top k 个向量返回给 client。query_vector用户输入的向量从byte-image-vector 中找到与 query-vecotr 最相近的 k 个向量返回。field字段名称byte-image-vector 字段存储了float 数组对该字段进行向量检索。
向量检索字段 与 其它字段 「混合」查询
方式一 因为 filter 语句是放在 knn option 里面在执行 knn 查询的同时执行 filter 查询确保能返回 5 个 (k5) doc。这并不是后置过滤。所谓后置过滤就是基于 knn 查询的结果之上再对 文件类型为 png 的 doc 做过滤后置过滤可能会导致最终返回的 doc 不足 5 个。 POST image-index/_search { “knn”: { “field”: “image-vector”, “query_vector”: [54, 10, -2], “k”: 5, “num_candidates”: 50, “filter”: { “term”: { “file-type”: “png” } } }, “fields”: [“title”], “_source”: false } 方式二 knn 检索有一个打分match query 检索有一个打分。根据公式计算出打分最高的 top 10 个size10 doc 返回。 score 0.9 * match_score 0.1 * knn_score 查询语句如下 POST image-index/_search { “query”: { “match”: { “title”: { “query”: “mountain lake”, “boost”: 0.9 } } }, “knn”: { “field”: “image-vector”, “query_vector”: [54, 10, -2], “k”: 5, “num_candidates”: 50, “boost”: 0.1 }, “size”: 10 } 参考资料 k-nearest neighbor (kNN) search K邻近搜索Dense vector field type 稠密向量ES官网语义搜索semantic-search
2.elasticsearch 字段常用配置参数解释
主要解释下面 3 个常用的参数
index 参数store 与 _source 参数doc_value 参数
2.1 index 参数
默认为 true。当设置为 true 时代表需要对该字段进行检索也即倒排查询根据 query 条件 查询 doc_id
2.2 store 与 _source 参数
这 2 个参数是 “互补” 的。一般而言_source 设置成 false然后具体需要获取哪个字段时将该字段的 store 选项设置成 true。因为开启 _source 表示直接存储的原始的 doc 文件内容占用的磁盘空间较大。而 store 则表示只存储此字段采用的是“行存的方式”by the way doc_value 是列存方式相比于_source 存储原始的 doc 文件“行存方式” 会对该字段建“索引”索引文件 fdx、数据文件 fdm从而能够高效访问。
2.3 doc_value
默认开启。开启 doc_value 意味着在写入 doc 时会对该字段创建列存索引用于排序聚合。类似于 HBase某字段开启 doc_value 后会把所有文档中该字段的值放在 “一起存储”由于同一个字段它的类型是确定的那么该字段所有的值都放在一起存储能够很好地使用压缩算法进行压缩存储。 举例有个 ES 索引有 100 个 doc其中有个字段是 “销量字段 sale_cnt”它是 int 型的对销量字段开启了 doc_value则这 100 个 doc 的 sale_cnt 字段的值 都会 “放在一起存储”由于这些值都是 int 型的那就可以用各种数据结构做存储优化比如压缩算法 当需要对 销量字段 做排序时显然是只有获取 销量字段 sale_cnt 所有的值才能排序那么开启 doc_value 就能大大加速排序了。这也是为什么官方文档中说doc_value 用于排序聚合的原因。
index 参数代表建立倒排索引结构是倒排存储。而store 和 doc_value 则代表建立正排索引正排索引有 2 种存储方式行存和列存其中 store 采用行存方式实现doc_value 采用列存方式实现。
参考链接
index 参数https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-index.html _source 参数https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-source-field.html store 参数https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-store.html doc_value 参数https://www.elastic.co/guide/en/elasticsearch/reference/current/doc-values.html
3. ES function_score 查询
官方文档https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-function-score-query.html
为什么 function_score 查询可以修改得分todo: 以示例进行演示
function_score 查询由两部分组成一个查询语句以及用于计算得分的若干 functions
它有两种查询形式一种只能有一个 function如下
GET /_search
{query: {function_score: {query: { match_all: {} },boost: 5,random_score: {}, boost_mode: multiply}}
}
另一种可以有多个 function即functions 数组下面指定了两个 function并且每个 function 都带有 filter 过滤条件。只有被 filter 过滤条件命中的文档才会应用 function 来计算得分。支持的 function 类型有script_score、weight、random_score、field_value_factor、decay_functions。不同的 function 类型计算得分的方式不一样对于 decay_function又包含几种 score 函数比如 guass、exp、linear 函数。
{query: {function_score: {query: { match_all: {} },boost: 5, functions: [{filter: { match: { test: bar } },random_score: {}, weight: 23},{filter: { match: { test: cat } },weight: 42}],max_boost: 42,score_mode: max,boost_mode: multiply,min_score: 42}}
}
score_mode 参数决定 filter 条件过滤之后打分的文档它们之间如何结合成一个总分数。以上面示例filter match “bar” 对命中的文档计算出一个分数它用的 score 函数是 random_score。filter match “cat” 对命中的文档计算出一个分数它用的 score 函数是 weight。然后对这两个 filter 命中的文档分数做一个结合 (combined)结合的方式由 score_mode 参数来决定。不同 filter 条件计算的得分衡量维度不一样比如有些是百分制有些是小数制因此需要结合成最终分数时需要统一维度这就是每个 filter 条件对应的 weight 参数所起的作用。
4.ES terms 聚合功能理解
本文介绍 ESES7.8.0 里面两种不同的聚合统计cardinality aggregations 和 terms aggregations。为了方便理解以 MySQL 表的示例数据来讲解 ES 的这两个聚合功能。MySQL 表结构如下
CREATE TABLE es_agg_test (id int(11) NOT NULL AUTO_INCREMENT COMMENT 主键id,name varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT 名称,label varchar(128) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT 标签,PRIMARY KEY (id)
) ENGINEInnoDB AUTO_INCREMENT9 DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci COMMENTes agg 测试示例
示例数据如下第一列是主键 id第二列是 name第三列是 label
1,apple,iphone12
2,apple,iphone11
3,apple,iphone11
4,huawei,mate30
5,huawei,mate30
6,huawei,mate30
7,huawei,p30
8,huawei,mate20
4.1 cardinality 聚合
1、计算 es_agg_test 表中一共有多少个不同的 label
SQL 写法
//SQL输出 5
select count(distinct (label)) from es_agg_test;
ES 代码
// ES 代码
SearchSourceBuilder sourceBuilder new SearchSourceBuilder();
sourceBuilder.fetchSource(true);
distinct AggregationBuilders.cardinality(labels).field(label).precisionThreshold(10000);
sourceBuilder.aggregation(distinct);
SearchRequest searchRequest buildSearchRequest(INDEX, sourceBuilder);
SearchResponse response esClient.search(searchRequest, RequestOptions.DEFAULT);protected SearchRequest buildSearchRequest(String index, SearchSourceBuilder sourceBuilder) {SearchRequest request new SearchRequest(index);request.searchType(SearchType.DEFAULT);request.source(sourceBuilder);return request;}
cardinality 聚合有个 precision_threshold 参数ES7.8.0 默认是 3000最大可配置成 40000也即如果 es_agg_test 表里面不同 label 的记录超过 4wES 统计出来的结果可能不准确。
4.2terms 聚合
全部 label 聚合统计
有时候知道一共有多少个不同的 label 还不够还想知道每个 label 对应的行数记录数是多少
在示例数据中一共有 5 个不同的 label我们统计出了所有的这 5 个 label 对应的行数记录数。
而有时候往往需要的是 top N 统计比如统计行数最多的前 2 个 label在示例数据中分别是 “mate30” 和 “iphone11”
SQL 写法
select label,count((label)) from es_agg_test group by label;
输出的结果如下
mate30,3
iphone11,2
iphone12,1
p30,1
mate20,1
相应地ES 要实现统计每一个 label 对应的行数记录数可以通过 terms 聚合来实现。terms 聚合需要传一个 size 参数具体到上面的示例也即一个有多少个不同的 label这可以通过 cardinality 聚合来得到。但是需要注意 cardinality 聚合参数 precision_threshold 的限制。
top N label 聚合统计
如果只需要统计行数最多的前 2 个 label那 size 参数如何设置呢可能大家的第一反应就是 size 参数设置成 2。由于 ES 底层是分布式存储数据分散在不同的分片中因此存在一个分布式统计的误差问题。如下 ES 索引有 2 个分片每个分片上的记录数量如下。如果分片 top2 聚合就会导致 2 种错误
1、label 不正确。真正的 top2 label 是 “iphone11” 和 “mate20”但是分片 top2 聚合产生的结果是 “iphone11” 和 “mate30”
2、数量不正确。label 为 “iphone” 的行数应该是 510但是聚合出来的结果是 500
正是因为分布式聚合统计存在如上问题所以 ES 在 terms 聚合时size 越大聚合的结果越精确但是性能开销也越大。 The higher the requested size is, the more accurate the results will be, but also, the more expensive it will be to compute the final results (both due to bigger priority queues that are managed on a shard level and due to bigger data transfers between the nodes and the client). 实际需求是求解 top2但是若在每个分片上计算 topN 时是按 top3 来统计的话上面的示例计算出来的结果就和 “上帝视角” 保持一致了。这也是为什么 terms 聚合里面有个 shard_size 参数的原因shard_size 的计算公式是shard_size (size * 1.5 10)
如果要计算 topN在 ES 每个分片上计算的是 top (N*1.510)然后再汇总排序得出 topN。如果在求解 topN 过程中导致 shard_size 参数超过了 1 万ES7.8 就会报错 Trying to create too many buckets. Must be less than or equal to: [10000] but was [10001]. This limit can be set by changing the [search.max_buckets] cluster level setting shard_size 参数由 ES 的索引动态配置参数 search.max_buckets 参数限制ES7.8.0 默认是 10000参考search.max_buckets 配置。
参考链接 https://stackoverflow.com/questions/57393548/control-number-of-buckets-created-in-an-aggregationhttps://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-terms-aggregation.html
更多优质内容请关注公号汀丶人工智能会提供一些相关的资源和优质文章免费获取阅读。
