2025年Elastic公司研究：向量搜索渗透率持续提升，IT预算预计保持稳定

向量数据库对比：Elastic vs Pinecone 等专用向量数据库

就搜索场景而言，其无外乎四个功能场景：1）全文搜索（关键词搜索，根据 prompt input 去搜索文档）； 2）向量搜索（语义搜索，将文档内容向量化后，再与 prompt 进行相关性搜索）；3）混合搜索（基于上面两种 的结合，可以基于关键词搜索，也可以基于语义搜索）；4）过滤排序（排除低质量或无关结果或通过业务规则 筛选）。GenAI 驱动下向量搜索兴起，混合搜索则是结合向量搜索/全文搜索，典型用例就是引入模糊查询，提 升查询范围，过滤查询则引入 Know-how 筛除部分不合常理的内容，提升输出结果有效性。因此，我们认为混 合搜索和过滤排序的应用正在逐步渗透开来。

就 Elastic 的竞争格局而言，我们主要讨论双方在向量功能上的优劣以及潜在的技术架构差异。目前竞争力 对比的结果是 Lucene 引擎在向量功能上存在限制，相比于 Pinecone 等专用向量数据库性能存在损失。我们主 要关注这一结论背后的原因，未来技术架构的迭代是否可以缩小双方的差距，以及未来市场格局的变化趋势。 大体而言，Lucene 引擎与专用向量数据库如 Pinecone 架构差异如下：1）索引构建与并发能力，Lucene 的 索引构建是单线程且非并发的，导致在向量数据写入时无法同时支持查询操作，限制了实时性。而 Pinecone 作 为专用向量数据库，支持高并发的写入与查询，其架构设计允许在索引构建期间处理请求。 2）存储与扩展性限制。Lucene 使用直接字节缓冲区，存在 2GB 的内存寻址限制，处理大规模向量数据时 需额外代码管理分片；而 Pinecone 采用自研的列式存储格式，专为高维向量优化，支持分布式扩展，可处理百 亿级数据。 3）数据更新与段合并机制。Lucene 的不可变段（segment）设计虽保证了搜索稳定性，但频繁合并段会降 低写入性能，这对于需要动态更新的向量数据（如实时推荐）效率不足。Pinecone 则通过更灵活的存储结构减 少此类开销，适应高吞吐场景。 4）专用性与功能适配。Lucene 的核心目标是全文检索，其稀疏向量优化主要服务于传统搜索场景，而 Pinecone 从底层专为密集向量计算设计，支持近似最近邻（ANN）算法，并深度整合了混合搜索（如结合元数 据过滤）。

关于索引构建，Lucene 引擎原生设计下不支持多线程并发写入和查询，引入隔离线程操作/NRT 近实时机 制后支持并发写入和查询，但受限于底层架构为单体架构，扩展性仍然弱于云原生架构。具体而言，多线程隔 离操作实际上是手动将资源切分为 N 份，每个线程的 DWPT 独立构建内存中的倒排索引和文档链，无需全局 锁，仅在提交与刷新阶段需要短暂全局锁，将内存中的段（segment）写入磁盘，这里 Lucene 引擎多并发写入本 质上是用内存资源换 I/O 带宽。而 NRT 近实时查询则是通过快照实现，新文档先写入内存缓冲区，通过刷新生 成新段（segment），查询时获取包含未提交段的快照，实现近实时性，其中延迟来自段合并及提交需要串行操 作，可能引发 I/O 峰值和查询延迟，这里 Lucene 引擎多并发查询也是用内存资源换 I/O 带宽。由于系统并发的 瓶颈就是合并+提交的串行操作，如果系统同时高并发写入与查询，可能会导致锁竞争从而影响延迟。 为提升扩展性，引入 Elastic Cloud/Serverless 改变底层架构，可部分提升 Lucene 引擎的扩展性。例如，通 过存算分离架构1，可以避免读写资源冲突导致的高延迟。另外，Serverless 支持支持动态调整分片和节点资源， 减少手动分片管理成本2。例如，分片数限制（如单节点 5 分片）可通过自动扩展和负载均衡缓解。基于自动分 片，可以将大量小查询合并为批量操作，提升并发能力3。

虽然 Elastic 引入诸多改进，但 Lucene 与专用向量数据库架构在优化方向上仍然存在较大差异。自 2022 年 2 月 10 日，Elasticsearch 8.0 原生支持 ANN 算法，并引入对浮点向量的 HNSW kNN 搜索的实验性支持。2024 年 8 月 2 日4，Elasticsearch 8.15 版本更新，原生支持 Int8/Int4 的 HNSW 搜索。 检索方式上，Elastic 使用倒排索引，就像图书馆的书目检索系统，每本书的内容被拆解成关键词标签（比 如“人工智能”、“Python”），通过标签卡片快速找到相关书籍，但这种检索方式忽略了语义层面的相似性， 即实际上搜索引擎对于书籍内容并没有认识，也无法找出与 XX 书籍相似的其他书籍。Pinecone 等专用向量数 据库采用列式存储，按特征分类，例如所有饮料放冷藏区、所有零食放货架前排，因此天然适合处理向量等负 载。而这两种检索场景需求有显著差异： Elasticsearch 的传统优势在于处理结构化/半结构化稠密数据 （如日志、指标），但对密集向量的支持需要 额外优化。倒排索引适合稀疏数据（如文本关键词），但处理密集向量（如图像特征）时需叠加 HNSW 等专用 索引。稀疏向量本质上是一个包含大量零值的矩阵，仅包含少量非零值（关键词），基于关键词和文档的映射 关系进行搜索，例如查询“Python”和“人工智能”两个关键词，“人工智能”→ [A, B, C]，“Python”→ [B, D]，最终合并结果 → [B]，这一过程省去对 A、B、C 三本书籍全部内容的扫描，因此倒排索引的效率提升主 要反映在关键词和文档的映射关系，此外就是一些预处理（倒排表）、压缩存储、结构优化等工程处理。 向量搜索则不同，需要把全文内容压缩为高维密集向量（很少为零值），这就导致很难提取关键词，即使 提取关键词重合率也非常高，此时做排序计算复杂度相比于稀疏向量呈指数级提升，因此本质上语义搜索和关 键词搜索的需求存在显著差异，二者在技术实现上优化方向也不一致。

混合语义搜索与关键词搜索后效果整体好于向量搜索/关键词搜索，因此未来搜索市场的融合趋势明显。

Google 扩大 AI Overview 渗透后可以看到 CTR 相当显著的变化，侧面反映 AI Overview 的流量渗透率达到 相当规模（预估 10-20%），未来可能进一步提升。与 Google 类似，Elastic 所面临的企业搜索场景也呈现类似 的趋势，混合搜索占比提升必然带来向量搜索需求的同步提升。

我们核心关注成本与延迟。Elastic AI Search Lake 采用云原生架构，将存储与计算分离，允许独立扩展存储 容量和计算资源。Serverless 通过无状态设计解决传统 Elasticsearch 中分片管理和段合并带来的复杂性。因此基 于 AI Search Lake + Serverless 的 Elastic 方案长期扩展性较好，且按资源付费模式成本低于 Pinecone 按量付费 （资源使用率的优化）。Pinecone 并非原生支持结构化数据查询。Pinecone 的核心设计是专为向量数据 （多维 空间表示的数据）优化的数据库，主要用于存储和检索密集或稀疏向量。虽然 Pinecone 支持元数据过滤功能（如 对向量附加标签并进行条件筛选），但其主要能力集中在向量相似性搜索 ，而非传统意义上的结构化数据查询 （如 SQL 查询）。因此 Pinecone 需要额外集成工具。因此成本端 Elastic 相对稳健一些，且在延迟层面在中小 规模场景（百万量级向量）基本实现与 Pinecone 同等级别的延迟，但在大规模场景（亿级向量）层面仍有数倍的延迟差距，后续关注架构优化缩小二者差距。

具体而言，①中小规模场景 Elasticsearch 的 ESRE（Elasticsearch Relevance Engine）在处理交易审批等场景 时，延迟可控制在 400 毫秒左右，显著优于传统搜索技术的 600 毫秒，能够满足实时性要求（如支付处理）。 对于非结构化数据（文本、图像），Elasticsearch 通过优化内存分配（25%堆内存专用于向量操作）和硬件配置 （Elastic Cloud 的专用硬件），能够提供可接受水平的召回率和响应速度，尤其在企业已有 Elastic 生态的情况 下，其集成优势明显。 ②大规模与复杂场景，在处理超大规模数据（如数亿向量）或高维嵌入模型（如 OpenAI 的 1,024 维以上） 时，Elasticsearch 的局限性显现：性能下降：尤其在处理长文本（如 950 页 PDF）时需大量预处理，且语义搜索 严格性易导致漏筛。向量长度限制：Elasticsearch 的默认索引最多支持 2,000 维向量，需适配更高维嵌入需重写 索引或算法，增加复杂度。在涉及数亿级向量的生产环境中，如 Verizon 的案例，原生向量数据库（Milvus）或 托管服务（Azure AI Search）因扩展性和专用设计更受青睐，而 Elasticsearch 可能因性能不足被弃用。 Pinecone 的优势在于①大规模场景的扩展性：Pinecone 在数亿级向量处理中展现更优扩 展 性 ，而 Elasticsearch 在达到一定规模后性能显著下降。②托管与无服务器架构：Pinecone 的云原生设计简化了基础设施 管理，适合需要按需付费的场景（如 Gong.io 处理 20-25 亿向量时按实际调用付费），而 Elasticsearch 需依赖企 业自建或托管集群。③端到端优化：Pinecone 提供自动化 RAG管理、文档分块等应用层功能，对比 Elasticsearch 需依赖额外工具链（如 LangChain）更高效。 总结来看，对于中小规模/低维数据场景，Elasticsearch 在延迟和成本上表现均衡，是企业优先选择。而超大 规模/复杂场景，Pinecone 等专用向量数据库在扩展性和性能上更优，但需权衡成本和生态依赖性。已有 Elas tic 生态或注重合规的客户倾向 Elasticsearch；需要处理海量数据或追求最优性能的客户则偏向 Pinecone 或原生解 决方案（如 Milvus）。

近期边际跟踪：向量搜索采用率持续提升，订单趋势积极

3 月以来 Qdrant、Faiss、Pinecone、Pgvector 等 python 包下载量明显提升，反映了 MCP 协议热度提升后大 量工程努力投入研发 Agent，带动向量数据库需求回升，但从提升幅度来看，传统的 Pgvector 提升幅度最大，而 非专用向量数据库。我们认为这反映了应用在接入 Agent 时更倾向于从现有数据库中扩展而非完全采用新数据 库，这对于现有的数据库厂商有利（如 Elastic/MongoDB）。

2025 年 IT 预算增速预期好于 24 年，尽管近期关税&CPI 数据导致部分扰动，我们认为只要实际数据没有 出现明显恶化，企业 IT 预算受到的影响可能较为有限。

后续 FY26 的驱动力：①Serverless 驱动客户用量增长。Elastic Cloud Serverless 于 2025 年 3 月 10 日在 Google Cloud 技术预览13，2 月 6 日在 Azure 技术预览14，2024 年 12 月 2 日在 AWS Generally Available15。 Serverless 产品可以帮助提升资源利用率（帮助 Elastic 提升毛利率），同时提升客户易用性（降低运维负担）， 缩短客户从部署到大规模采用的周期。公司长远目标是 Serverless 成为 Elastic Cloud 主要部署模式，但目前处于 早期阶段，我们预计在 FY26H1 可能看到 Serverless 产品对收入增速更大的拉动。 ②LogsDB 提升存储效率，吸引用户迁移并带来总体支出增长。通过采用 ZSTD、增量压缩等高级算法，减 少日志数据的磁盘占用，结合动态调整索引结构，降低冗余数据存储，提升查询速度。LogsDB 允许在不增加预 算的情况下存储更多日志数据，同时保持数据的实时可访问性。对于长期储存的数据而言，TCO 可优化 50%16。 引入 LogsDB 后目前看到客户转向企业级，并将工作负载从竞争对手的产品中转移，并将更多工作负载整合到 Elastic 平台上，进而带动其他产品的资源消耗提升。我们预计在 FY26 将进一步看到订单和客户单价的强劲提 升。 ③开源许可证调整，中长期驱动客户数量增长。2024 年 8 月 Elasticsearch 宣布从 Apache 2.0 许可证模式转 向 AGPL，主要由于部分客户对于许可证更改表示疑虑，开源可以增强客户信任，在获取客户订单时有所帮助。 但我们预计这对于 FY26 客户增长帮助有限，可能在中期维度是客户增长的驱动力。

（本文仅供参考，不代表我们的任何投资建议。如需使用相关信息，请参阅报告原文。）