我要建房子去什么网站找人做,装饰工程东莞网站建设,工业设计公司,网站建设调研报告的前言作者#xff1a;来自 Elastic Mike Pellegrini, Nick Chow 及 Libby Lin 比较 Elasticsearch 语义文本和 OpenSearch 语义字段在简洁性、可配置性和效率方面的表现。 自己动手体验向量搜索#xff0c;使用这个自定进度的 Search AI 实操学习。你现在可以开始免费的云试用来自 Elastic Mike Pellegrini, Nick Chow 及 Libby Lin 比较 Elasticsearch 语义文本和 OpenSearch 语义字段在简洁性、可配置性和效率方面的表现。 自己动手体验向量搜索使用这个自定进度的 Search AI 实操学习。你现在可以开始免费的云试用或者在本地机器上尝试 Elastic。 在 Elasticsearch 8.152024 年 8 月中我们引入了 semantic_text 功能将语义搜索的设置简化为一步指定字段类型。从那时起我们持续增强这一 正式发布版功能目标是进一步简化用户体验。
最近OpenSearch 3.12025 年 6 月发布了一个类似功能名为 semantic 字段类型。在这篇博客中我们将从简洁性、可配置性和效率方面比较这两个功能并展示它试图模仿 Elasticsearch 的创新但实际上为用户提供的功能更弱同时引入了更多复杂性。 Elasticsearch semantic_text —— 优雅简洁
Elasticsearch 的 semantic_text 功能通过默认语义模型自动生成向量嵌入只需简单切换已定义的推理端点即可自定义为其他模型从而简化了语义搜索工作流。这加快了语义搜索的交付速度同时无需手动配置、设置 ingest pipeline、引入外部工具也不需要在写入和查询时手动同步所用的模型。
这种能力可以通过集成大量其他模型提供商轻松扩展并支持强大的混合搜索场景。
semantic_text 字段在 _source 中提供了简化的表示形式相比之前的版本减少了冗余、提升了磁盘效率。Elasticsearch 的功能与这一能力无缝集成。例如它支持高亮功能可以将字段中最相关的片段提取并发送给 LLM。语义搜索从多步骤的 pipeline 设置演变为单一的专用字段类型后更加简单且可直接投入生产。这些细节累积起来在构建 Agent 和将 Elasticsearch 用作 grounding 来源及向量存储时能带来更高质量的答案。
semantic_text 字段与查询语言包括查询 DSL 和 ES|QL紧密集成。查询选项也扩展为支持 match、knn 和 sparse_vector 查询。semantic_text 保持了简单的设置方式同时通过这种集成查询支持可以使用高级选项。随着我们持续投资于 ES|QL这个底层系统的能力将继续体现在每个命令中。
对于完全托管的 Elasticsearch 用户和使用最新版本的用户现在可以使用新的分块和索引选项并可配置用于语义文本。
这些变化体现了我们持续关注为语义搜索提供优秀默认设置的同时也让用户能够广泛使用平台的底层 AI 能力。
那么OpenSearch 3.1 中的新 semantic 字段类型表现如何呢让我们一探究竟…… 评测 OpenSearch 3.1 的 semantic 字段功能
OpenSearch 在 3.1 版本中引入的 semantic 字段类型旨在通过在写入和查询时自动启用向量嵌入生成来简化神经搜索。然而经过检查我们发现其实现方式由于与 OpenSearch 其他功能的集成方式反而引入了一些阻碍。 功能上的主要差异
Elasticsearch 在默认值和可配置性上的深思熟虑使用户能够快速上手。由于 Elastic 的实现方式无缝衔接用户可以在不牺牲简洁性的情况下顺利过渡到更高级的功能。
例如在使用默认量化开始后用户可能希望根据所需的准确性与延迟权衡来调整量化级别。而 OpenSearch 的实现僵化阻碍了轻松获得更优体验的途径。 Elasticsearch集成更紧密/运行更流畅
Elasticsearch semantic_textOpenSearch semantic field开箱即用 embedding 默认附带 ELSER开箱即可生成向量嵌入。支持即时语义搜索无需设置模型。 没有默认的开箱即用模型。需要额外步骤来选择、注册并部署向量嵌入模型。 支持的查询类型 Semantic、Match、KNN、Sparse_vector。在保持语义查询简洁性的同时具备 DSL 的灵活性。 NeuralVector。在开发过程中灵活性有限。 与查询语言的集成 与 ES|QL 集成提供统一的数据探索体验提升生产力。 目前不支持与 PPL 集成。开发者被迫在查询语言之间切换例如切换到 DSL。 语义高亮参见高亮方法差异部分 无需设置模型。查询中不需要指定模型 ID。用户可即时获得高亮无技术负担。 没有默认高亮模型。每次查询都需要指定模型 ID。开发者必须分别管理和跟踪高亮模型与嵌入模型。
Elasticsearch semantic_text 与 ES|QL 集成示例
FROM product-catalog-index
| WHERE match(product_description.prod_embedding,
carpenter thing for shaving wood ?) Elasticsearch更快更高效
Elasticsearch semantic_textOpenSearch semantic field 量化 默认使用 BBQ内存节省高达 95%。支持可配置量化用户可调整。 量化继承自嵌入模型不支持配置。用户被锁定在低效内存使用和较差性能中。 响应中包含的嵌入数据 输出简洁客户端关注核心内容。 响应中附加嵌入数据开发者需过滤非必要信息或总是“排除”。
附加资源
Elasticsearch 的 semantic_text 默认使用 BBQ。OpenSearch 的 semantic 字段需过滤非必要信息或总是 “排除”。 Elasticsearch可配置
Elasticsearch semantic_textOpenSearch semantic field 稀疏模型的 Token 修剪 默认启用。稀疏向量延迟提升 3-4 倍。查询时可配置用户可根据查询需求调整。 修剪比例固定为 0.1且不可配置。导致处理不同数据集时缺乏灵活性。 分块 默认启用且可配置。可配置分块提升相关性。 默认禁用启用时仅支持固定长度分块。固定长度分块会丧失上下文含义因此相关性较低。
附加资源
使用 Elasticsearch 的 Token 修剪提升文本扩展性能。OpenSearch 的 semantic 字段的限制。OpenSearch 的 semantic 字段中的固定长度分块。
上表提供了简明的概览但语义高亮的细节对于像 RAG 这样的应用尤为重要。让我们更详细地比较 Elasticsearch 和 OpenSearch 如何处理这一功能。 RAG 语义高亮最佳实践 最佳实践
语义高亮应尽量复用已索引的嵌入避免查询时进行昂贵的二次推理。此设计大幅降低查询延迟和计算成本。此外为了提升大型语言模型LLM的相关性高亮机制应返回足够的上下文信息通常是整块文本而非孤立句子。能够配置这些文本块的大小对优化 RAG 用例也很有帮助。 Elasticsearch 方法
Elasticsearch 的高亮实现符合上述最佳实践提升了 效率与成本复用每个文档已索引的嵌入无需二次推理处理效率优于 OpenSearch。 上下文灵活性其语义高亮返回整块文本通常比单句更长为 LLM 提供更多上下文提升相关性。如果块大小不适合特定用例用户可以通过 semantic_text 字段的分块设置调整。 OpenSearch 方法
相比之下OpenSearch 的语义高亮实现存在以下限制 成本与延迟增加查询时需对文档和查询同时使用特定的语义高亮模型导致额外的查询延迟和计算开销。 上下文受限且相关性较低高亮模型仅对单句操作且无法配置更大上下文窗口只返回单句因上下文不完整可能影响相关性。
除了功能和效率上的差异简洁性和集成度的根本区别从最初的设置阶段就显而易见。接下来我们将看到 Elasticsearch 的方案从一开始就更简便。 简单对比示例使用 RRF 的混合搜索
这里展示一个示例未配置分块、修剪或高亮说明设置基础语义semantic字段并执行基于 RRF 的简单混合搜索所需的额外步骤。使用了 Elasticsearch 9.1 和 OpenSearch 3.1。
我们在 Elasticsearch 中创建了一个带多字段的简单索引 product_description product_description.prod_embedding
在 OpenSearch 开箱即用OOTB环境中顶层有两个字段因为如果字段是 “semantic” 类型文本不会流向子字段。
然后我们在 Elasticsearch 和 OpenSearch 上分别运行基于 RRF 的混合搜索。
可以看到 Elasticsearch 中 semantic_text 与检索器之间的无缝集成。 Elasticsearch semantic_text
PUT /product-catalog-index{mappings: {properties: {product_description: {type: text,fields: {prod_embedding: {type: semantic_text}}}}}
}
# Insert a document
POST /product-catalog-index/_doc{product_description: A hand plane is an essential tool in a woodworkers toolset. Its used to smooth and flatten wood surfaces as well as trim components.
}# Do Hybrid Search using Retrievers (RRF)
POST /product-catalog-index/_search{retriever: {rrf: {retrievers: [{standard: {query: {match: {product_description: Thing that Carpenters use to shave lumber.}}}},{standard: {query: {semantic: {field : product_description.prod_embedding,query: Thing that Carpenters use to shave lumber.}}}}]}}
} OpenSearch semantic field:
# Register and Deploy an embedding model
POST /_plugins/_ml/models/_register?deploytrue{name: amazon/neural-sparse/opensearch-neural-sparse-encoding-doc-v3-distill,version: 1.0.0,model_format: TORCH_SCRIPT
}# WAIT for the TASK to be COMPLETED and then create your index
GET /_plugins/_ml/tasks/csMZdJgBeUoTAZq7_jT0# Create Index
PUT /product-catalog-index{mappings: {properties: {product_description: {type: text,copy_to: prod_embedding},prod_embedding: {type: semantic,model_id: c8MadJgBeUoTAZq7ADQt}}}
}# NOTE: The “copy_to” did not work on a “semantic” field.
POST /product-catalog-index/_doc{product_description: A hand plane is an essential tool in a woodworkers toolset. Its used to smooth and flatten wood surfaces as well as trim components.,prod_embedding: A hand plane is an essential tool in a woodworkers toolset. Its used to smooth and flatten wood surfaces as well as trim components.
}# Create a RRF Pipeline processor
PUT /_search/pipeline/rrf-pipeline-product-catalog{description: Processor for hybrid RRF search,phase_results_processors: [{score-ranker-processor: {combination: {technique: rrf}}}]
}
#
POST /product-catalog-index/_search?search_pipelinerrf-pipeline-product-catalog{_source: {excludes: [prod_embedding_semantic_info]},query: {hybrid: {queries: [{match: {product_description: Thing that Carpenters use to shave lumber.}},{neural: {prod_embedding: {query_text: Thing that Carpenters use to shave lumber.}}}]}}
}
在这个简单案例中Elasticsearch 需要的步骤更少突出其易用性。
随着搜索场景复杂度的增加Elasticsearch 可扩展的架构确保它能够轻松应对需求。 总结
Elasticsearch 的 semantic_text 与 OpenSearch 的 semantic 字段虽然目标相似但功能存在显著差异。架构选择和持续改进的承诺带来了功能和资源需求上的巨大不同。
Elasticsearch 的 semantic_text 字段以简洁、高效和与套件其他部分的无缝集成为特色提供可配置分块、默认量化BBQ和紧凑存储。OpenSearch 的 semantic 字段目前更僵化缺少 Elasticsearch 中一些简化的集成和存储优化。
Elasticsearch 对 semantic_text 的实现为更高级的语义搜索能力提供了清晰路径同时不牺牲简洁性。 立即试用 semantic_text
你可以通过免费试用在完全托管的 Elasticsearch Serverless 项目中体验 semantic_text。它也可在 8.15 及以上版本使用但在 8.19 和 9.1 中体验最佳。
只需一条命令几分钟内即可在本地环境开始使用
curl -fsSL https://elastic.co/start-local | sh原文Beyond similar names: How Elasticsearch semantic text exceeds OpenSearch semantic field in simplicity, efficiency, and integration - Elasticsearch Labs
