作者：來自 Elastic?Mike Pellegrini,?Nick Chow? 及?Libby Lin
比較 Elasticsearch 語義文本和 OpenSearch 語義字段在簡潔性、可配置性和效率方面的表現。
自己動手體驗向量搜索，使用這個自定進度的 Search AI 實操學習。你現在可以開始免費的云試用，或者在本地機器上嘗試 Elastic。
在 Elasticsearch 8.15（2024 年 8 月）中，我們引入了 semantic_text 功能，將語義搜索的設置簡化為一步：指定字段類型。從那時起，我們持續增強這一 正式發布版功能，目標是進一步簡化用戶體驗。
最近，OpenSearch 3.1（2025 年 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_text | OpenSearch semantic field | |
|---|---|---|
| 開箱即用 embedding | 默認附帶 ELSER，開箱即可生成向量嵌入。支持即時語義搜索，無需設置模型。 | 沒有默認的開箱即用模型。需要額外步驟來選擇、注冊并部署向量嵌入模型。 |
| 支持的查詢類型 | Semantic、Match、KNN、Sparse_vector。在保持語義查詢簡潔性的同時具備 DSL 的靈活性。 | Neural（Vector）。在開發過程中靈活性有限。 |
| 與查詢語言的集成 | 與 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_text | OpenSearch semantic field | |
|---|---|---|
| 量化 | 默認使用 BBQ，內存節省高達 95%。支持可配置量化，用戶可調整。 | 量化繼承自嵌入模型，不支持配置。用戶被鎖定在低效內存使用和較差性能中。 |
| 響應中包含的嵌入數據 | 輸出簡潔，客戶端關注核心內容。 | 響應中附加嵌入數據，開發者需過濾非必要信息或總是“排除”。 |
附加資源：
- Elasticsearch 的 semantic_text 默認使用 BBQ。
- OpenSearch 的 semantic 字段需過濾非必要信息或總是 “排除”。
Elasticsearch：可配置
| Elasticsearch semantic_text | OpenSearch 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 woodworker's toolset. It's 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?deploy=true{"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 woodworker's toolset. It's used to smooth and flatten wood surfaces as well as trim components.","prod_embedding": "A hand plane is an essential tool in a woodworker's toolset. It's 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_pipeline=rrf-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
