作者：Gilad Gal, Tyler Perkins, Srikanth Manvi, Aris Papadopoulos, Trevor Blackford
在 8.13 版本中，Elastic 引入了向量搜索的重大增强，并将 Cohere 嵌入集成到其统一 inference API 中。这些更新简化了将大型语言模型（LLM）集成到用户工作流中的过程，并提高了查询效率，使得通过搜索更快、更容易地解决复杂数据问题，具体包括：
- 开发了一种新方法，用于在运行 HNSW 向量搜索的不同段之间的线程传递中间结果，这提高了查询延迟，并有时将平均查询时间减少到之前的一半甚至三分之一
- 使向量搜索更简单、更高效，允许你利用默认设置改善查询性能，无需深入了解底层机制
- 将统一 inference API 扩展以包括 Cohere 嵌入，同时支持 OpenAI 和 HuggingFace，便于更轻松地访问更广泛的语言处理工具
- 引入了为密集向量字段编索引的新选项，以使用 brute force 向量搜索 —— 在适当条件下，brute force 向量搜索显著减小了索引大小并改善了查询延迟，特别是现在我们引入了与 brute force 向量搜索一起使用的标量量化
- 简化了对高级搜索功能的访问，并扩大了支持的语言模型范围，赋予你实现更细腻、准确和高效的搜索及数据分析结果的能力
8.13 现已在 Elastic Cloud 上可用 —— 唯一包含此最新版本所有新功能的托管 Elasticsearch 服务。你也可以下载 Elastic Stack 及我们的云编排产品 —— Elastic Cloud Enterprise和Elastic Cloud for Kubernetes —— 以获得自我管理的体验。
向量搜索改进
在 8.10 版本中，通过在不同段之间的线程通信改进了查询并行化 ，我们实现了可以在每个查询中为每个段使用一个线程来执行向量搜索查询；也就是说，我们实现了在分片内并行运行查询。这促使我们思考通过在执行相同查询的线程之间共享信息来改进查询延迟的方法。线程间的信息共享允许 Elasticsearch 针对在没有好的候选结果段时更早中止搜索。我们将这一独特方法贡献给了 Lucene，并且你可以在这里查看代码和改进后的查询延迟。更多关于这一新方法的详细信息，请参见加速多图向量搜索博客。
最根本的是，查询运行所需的时间大大减少。在数据集之间改进的程度有很大的变化，但是拥有多个段和高维度的大型数据集可能会经历 2x 至 3x 的改进（在某些情况下可能更多）。当我们用 Cohere 数据集（1百万个 768 浮点维度的向量）进行实验时，我们也在 Lucene 中看到了 1.7x 至 2.5x 的改进。这一影响也可以在我们的夜间基准测试中看到（尽管这是一个小数据集，但在更大的数据集中影响更为显著）。例如，经过 2024 年 3 月 4 日合并的变更之后，knn-search-100-1000-concurrent-with-indexing-latency rally 跟踪测试几乎快了两倍。
简化 kNN 向量搜索
向量搜索的受欢迎程度越来越高。它通过查询向量与文档向量的相似度来排序结果，并返回一小部分与查询向量最相似的向量文档。这意味着更多的用户在没有专门的机器学习或相关性排名团队的情况下使用这项技术。为了方便那些刚接触这一领域的人使用向量搜索，我们使得向量搜索的使用变得更加简单。你仍然可以使用所有高级功能，但你也可以依赖我们的默认设置来更简单地开始，而无需了解所有细微差别。依赖默认设置的结果出乎意料地好。
从工程角度来看，向量搜索延迟（运行查询所需的时间）主要由所需的向量比较操作数量决定。HNSW kNN 向量搜索的美妙之处在于，被评估的向量数量大致与语料库中的向量数量呈对数关系，但由于 Elasticsearch 是分布式的且搜索是并行的，在这个上下文中的语料库是分片内的段。然而，即使是 HNSW，考虑作为返回的 top-k 候选的向量数量也是平衡召回率和延迟的重要方式。到目前为止，用户需要提供两个数字：分片将返回的文档数量（命名为 num_candidates）和查询将返回的文档数量（命名为‘k’）。我们决定允许依赖于两者的默认值。
对我们来说，依赖于默认值意味着我们需要进行大量测试以找到正确的默认值，和往常一样，我们公开进行了这些测试。经过大量讨论和测试，我们最终决定 num_candidates 将是 10,000 和 1.5 倍的 k 这两个值的最小值。默认情况下 k 等于 size，而默认情况下 size 是 10，所以默认情况下每个分片的 num_candidates 将是 15。
int8_flat 和 flat 向量字段索引类型
在过滤后集合的大小相对较小时，通常更好依赖于 brute force 向量搜索而不是基于 HNSW 的向量搜索。潜在的好处包括更好的性能（摄取和查询延迟）、完全准确的召回率（无近似最近邻搜索）、更低的内存消耗以及对于缓存未命中更宽容的查询延迟梯度。实际的界限必须根据情况进行测试，但是如果在过滤后的向量数量低于 10,000，那么 brute force 搜索应该是首选。这些情况出现得惊人地频繁，因为它与通过过滤器的文档数量有关。现在 Elasticsearch 提供了标量量化，可以将索引大小减小到原始大小的约三分之一（有关更多详细信息，请参阅使用字节大小向量节省空间、标量量化 101 和介绍 Lucene 中的标量量化），因此使用 brute force 向量搜索的阈值甚至更高。
在 8.13 版本中，我们将为索引向量字段添加两个新选项：flat 和 int8_flat 向量索引。虽然 flat 是对执行 brute force 向量搜索的索引的一种语法糖，但 int8_flat 将自动将向量量化为 int8，从而减小索引大小并提高查询延迟。
同一文档的多个结果与嵌套向量
在 8.11 版本中，我们增加了对嵌套向量的支持，用于对每个文档字段中具有多个向量的文档进行排名。这个功能在支持以下情况方面非常受欢迎：
-
将长文本拆分为多个分块 — 大多数模型限制了 token 的数量（例如，BERT 每个向量限制为 512 个 token），因此，一个文档中如果有一个以上的段落通常意味着创建多个向量来表示该文本。
-
每个文档的多个图片 — CNN 模型通常将每个图像转换为单个向量，在电子商务等场景中，每个文档通常都会附带多个图像。
大多数实际情况下使用基于 token 频率的搜索和关键字过滤以及向量搜索的组合。另一种选择（大多数引擎会采用的方法）是对文档进行去规范化和拆分，将每个向量拆分为单独的文档，这样会增加数据摄取的复杂性，也会导致索引变得显著更大且不太经济。就像任何受欢迎的功能一样，我们开始收到许多关于它的问题，比如它是否支持 ELSER（是的），以及是否有选项可以从同一文档返回多个结果 — 目前还没有，但现在我们在 8.13 版本中正在添加此选项。这意味着，例如，你现在可以选择让来自同一文档的不同图片或段落在结果集中分别显示。
统一 inference API 现在集成了 Cohere 嵌入
在 8.13 版本中，Elastic 进一步扩展了其统一 inference API 的功能，包括对 Cohere 嵌入的支持，以增强其多样性和易用性。这一增强构建在 8.12 版本的基础之上，该版本引入了与 OpenAI 和 HuggingFace 嵌入的兼容性，标志着与不断发展的 LLMs 景观无缝集成的持续努力。
这一增强与 E5 多语言嵌入的加入一起，展示了 Elastic 简化和丰富了将 LLMs 集成到你的工作流中的承诺。API 在 8.11 版本首次引入了简单的语法，使得无缝访问更广泛的语言处理工具变得轻松自如，极大地增强了数据分析和处理能力。这一扩展不仅促进了创新，还确保 Elastic 的产品更具包容性，并能够根据你的需求提供巨大价值，为希望在 Elastic 部署中有效利用高级语言模型的人们提供了极大的帮助。
使用新的推理 API 对新支持的模型和服务进行推理就像在 8.11 版本中引入的简单语法中调用一样简单：
PUT /_inference/<task_type>/<model_id>
要开始使用 Cohere 嵌入与你的 Elastic 部署，使用新的 inference API，请参阅此教程。此功能在 8.13 版本中处于技术预览阶段。
新的和改进的健康指标
我们继续扩展 health API 的覆盖范围 — 这是一个我们发现对于监控 Elasticsearch 服务非常有帮助的功能。
使用 DSL 健康指标检测处于数据流生命周期中卡住的数据流
随着我们接近数据流生命周期（data stream lifecycle - DSL）设置的正式发布（在 8.13 版本仍处于技术预览阶段），我们希望在健康报告中覆盖它，该报告已经覆盖了 ILM。Elasticsearch 8.13 版本包括一个新的 DSL 健康指标，它将检测数据流后端索引无法取得进展（停滞）的情况，因为它们在生命周期执行过程中重复出现错误。与所有健康指标一样，我们将包括影响、严重性、受影响的资源和诊断，以简化故障排除过程。
使用增强的 repository_integrity 指标检测配置错误或无效的存储库
有时节点无法按照当前集群元数据指定的方式创建工作的快照存储库实例。这可能是由于缺少插件（导致 UnknownTypeRepository 实例）或其他不良配置（导致 InvalidRepository 实例）。这会在实际尝试使用存储库时引发日志消息和故障，但在其他情况下可能不会被注意到。repository_integrity 健康指标已经覆盖了损坏的存储库；现在，健康指标将直接向用户显示这些错误配置，因为我们将其扩展为报告未知和无效的存储库。
ES|QL 的增强功能
ES|QL 在 Java 客户端中的支持
Elasticsearch 查询语言（ES|QL）为过滤、转换和分析存储在 Elasticsearch 中的数据提供了强大的方式，并且未来还会支持其他运行时环境。它旨在通过最终用户、SRE 团队、应用程序开发人员和管理员轻松学习和使用。
随着 8.13 版本的发布，开发人员现在可以在使用 Elasticsearch Java 客户端时直接从其集成开发环境（IDE）中运行 ES|QL 查询。开发人员可以将 ES|QL 返回的数据投影为域对象或使用数据库游标（如 Resultset）进行迭代。此功能在 8.13 版本中处于 beta 阶段。
数据可视化器中的 ES|QL 支持
数据可视化器现在支持 ES|QL，这是 Elastic 的一种新的管道查询语言，可简化数据调查。在数据可视化器中运行你的 ES|QL 查询，轻松探索你的数据集。选择探索并将你的查询应用于整个数据集或其子集以提高速度。在 8.13 版本中，此功能处于技术预览阶段，并支持关键字、文本、数值、布尔、日期和 IP 字段。
异常检测和 AIOps：可用性增强
你现在可以轻松地将单一指标异常检测图表添加到仪表板中。在仪表板编辑模式下的 “Add panel” 选项中，选择 Machine Learning，然后从菜单中选择 Single metric viewer 选项。
此外，我们还增强了 AIOps 中的模式分析功能，以便你可以展开一行并查看 tokens、正则表达式以及一些示例，以更好地了解模式。此外，语法高亮（字体颜色）反映了检测到的模式。当你选择在 Discover 的主视图中过滤模式时，模式分析功能和 Discover 之间的突出显示现在是一致的。
此外，你现在可以从 Anomaly Explorer 和 Single Metric Viewer 中运行 Log Rate Analysis。单击 Actions 设置图标，然后从菜单中选择 “Run log rate analysis”。你将被引导至机器学习中的日志速率分析界面。
从 8.13 版本开始，你还可以从 Single Metric Viewer 中的异常标记实现相同的功能。单击它们，操作菜单将出现。
Elastic 集成过滤器：改变 Logstash 用户的游戏规则
在不断演变的数据处理和分析领域，灵活和强大的工具需求至关重要。Elastic 集成提供了广泛数据源的模式和可视化，使用户能够充分释放其数据的潜力。
新的 Logstash 插件 —— Elastic Integration Filter —— 结合了 Logstash 的强大功能和数据智能，允许你在将数据发送到 Elasticsearch 之前，将集成特定的转换的执行从 Elasticsearch 转移到 Logstash。通过将 Elastic 集成过滤器添加到 Logstash 管道中，你现在可以弥合 Logstash 的分布式处理能力与 Elastic 集成目录之间的差距。这使你能够解决各种用例，包括空隙环境、数据隐私处理和多个目的地。
Elastic 代理支持 Kafka 现已正式发布
在 11 月份，Elastic Agent 的原生输出到 Kafka 在技术预览中可用。我们很高兴地宣布，Elastic Agent 的 Kafka 版本现已正式发布。
许多组织选择在其数据处理管道中使用 Kafka，因为它具有持久性/排队和流媒体功能，包括全面托管的云服务，以及通过专用连接器简化的操作需求。Kafka 的可扩展架构允许有效处理数据，确保系统稳定性并优化 Elasticsearch 索引。关键功能包括数据聚合和转换，将数据源和消费者解耦以增强稳定性，以及与其他系统（如 Logstash）的全面集成能力。此集成有助于进行高效的数据分析和处理，轻松适应不断增长的数据量和复杂的工作负载。
虽然这个功能在 Beats 中已经暴露了一段时间，但 Elastic Agent 通过将数据收集和解析整合成一个单一代理，简化了部署和管理。它通过 Kibana 的 Fleet 提供了集中管理，可以轻松更新和推送 policies 到主机，并通过集成端点保护增强了安全性，无需额外的工具或努力，从而扩展了 Elastic 的价值。
尝试一下吧！
阅读有关这些功能以及更多内容的发布说明。
现有的 Elastic Cloud 客户可以直接从 Elastic Cloud 控制台访问许多这些功能。还没有在云上利用 Elastic？开始免费试用吧。
此帖子中描述的任何功能或功能的发布和时间仍由 Elastic 自行决定。当前不可用的任何功能或功能可能无法按时或完全交付。
在本博客文章中，我们可能已经使用或引用了第三方生成式 AI 工具，这些工具由各自的所有者拥有和运营。Elastic 对第三方工具没有任何控制权，对其内容、操作或使用不承担任何责任或义务，也不对你使用此类工具可能产生的任何损失或损害负责。在使用个人、敏感或机密信息时，请谨慎使用 AI 工具。你提交的任何数据可能会用于 AI 训练或其他用途。不能保证你提供的信息将被安全地保密。在使用任何生成式 AI 工具之前，请熟悉其隐私实践和使用条款。
Elastic、Elasticsearch、ESRE、Elasticsearch Relevance Engine 及相关标记是 Elasticsearch N.V. 在美国和其他国家的商标、标志或注册商标。所有其他公司和产品名称均为其各自所有者的商标、标志或注册商标。
原文：Elasticsearch and Kibana 8.13: Simplified kNN and improved query parallelization | Elastic Blog
