从精准检索到 AI 问答：Elasticsearch 与 Easysearch 的一次迁移验证

这次选型不是从产品对比表开始的。一个原本只做精准检索的文献项目增加了 AI 问答，顺势把语义检索、混合排序和模型推理带进了系统；另一个从一开始就使用 Easysearch 的轻量项目，则让我们意识到，或许不必长期绑定原来依赖的搜索底座。

摘要

我们的第一个项目长期使用 Elasticsearch。最初目标很朴素：让研究者准确找到一句原文，并能沿书名、篇名、日期、页码和原图回到出处。后来增加 AI 问答，检索不再只是“原文里有没有这个词”，还要处理不同说法之间的语义关联，并把关键词结果与向量结果稳定融合。

基础向量字段、vector search 和 standard/kNN retriever 本来就在 Elastic Basic 中。真正触发许可问题的，是更进一步的产品化需求：原生 RRF、Query Rules 和 Learning to Rank 只在 Enterprise；第三方模型管理、ELSER 和 e5 从 Platinum 起；Elastic Rerank、Elastic Inference Service 和统一 Inference API 只在 Enterprise。我们开启过 30 天全功能试用，体验确实很好，也因此认真评估过采购；但按节点或资源规模累积的长期费用，超出了多数高校课题能够持续承担的范围。

恰好第二个轻量项目从一开始就使用 Easysearch。它在中文检索、聚合、SQL/JDBC 和日常运维上已经给我们留下不错印象，反馈渠道也比预期更直接。问题只剩一个：它能否承担第一个项目已经在 Elasticsearch 上实现的检索功能，而不只是完成一个轻量级部署？

于是，我们把相同数据和查询写入两端做功能验证。结果是，Easysearch 2.3.1 经过 mapping、查询 DSL 和客户端适配，可以覆盖当前实际使用的关键词检索、dense 语义检索、范围过滤、应用层 RRF、聚合、分页和索引维护。现有项目在完成性能、容量、稳定性和回滚演练后，即可开始分阶段迁移；需求相近的新项目，则可以直接从 Easysearch 起步。

文献的关键词检索与语义向量经过同集测试和结果复核后迁移到新的搜索后端

这次迁移先验证检索结果，再更换搜索底座：关键词、语义向量、过滤范围和融合排序都要逐项过关。

一、一次迁移评估的起点

项目一：先把原文搜准

第一个项目处理的是扫描 PDF、图片型图书和带有低质量文本层的文档。材料经过 OCR、版面分析、目录识别、篇目划分、跨页段落合并和日期校订后，被组织成可检索、可引用、可回看原始页面的研究单元。

系统最早并没有 AI 问答。研究者输入的是一段确定表述、一个人名或一篇文章标题，期望得到原句所在的书、篇目、日期和页码。Elasticsearch 的中文分词、match_phrase、高亮、bool/filter、聚合和 alias 很适合这项工作。检索结果还要保留命中页和原图入口，方便核对 OCR、页码与上下文。

在这个阶段，目标是“搜准”和“可核验”。Elastic Basic 已经足够支撑主要功能，我们也因此长期把 Elasticsearch 作为可靠的数据底座。

AI 问答把检索要求向前推了一步

变化来自 AI 问答。用户不再只输入原文中的固定短语，还会问：“某一时期如何讨论群众路线？”“不同文集中对同一问题的表述有什么变化？”这类问题不能把整库直接交给大模型，也不能只靠关键词召回，必须先找到合适的文献片段，再让模型根据出处组织回答。

于是，系统增加了用户口中的“模糊搜索”。严格说，它不是 Elasticsearch 的 fuzzy query，而是 dense semantic search：即使提问和原文没有共享相同词项，也可以根据向量相似度找到相关论述。与此同时，关键词检索仍然不能丢，因为人名、年代、文件编号、专有名词和原句核验往往由 BM25 更可靠。两路结果需要进一步做混合排序。

这里很容易产生一个误解：增加 AI 搜索就一定要购买高级许可。其实不是。根据 Elastic 当前 self-managed 订阅矩阵和官方矩阵 PDF，vector field、vector search、相似度函数以及 standard/kNN retriever 都在 Basic。

许可边界出现在我们想把这套体验做得更完整时：让数据库在一次查询中完成多路召回与融合，使用的是原生 RRF retriever，它与 linear、rule、text-similarity retriever、Query Rules 和 Learning to Rank 一样，只在 Enterprise 提供。如果进一步希望在集群内管理模型，第三方模型管理、ELSER 和 e5 需要 Platinum 或 Enterprise；Elastic Rerank、Elastic Inference Service，以及统一调用托管、第三方和自托管 embedding、reranking、LLM provider 的 Inference API，则只在 Enterprise 提供。

换句话说，收费的不是“向量搜索”四个字，而是原生融合、可控排序、模型生命周期和统一推理这些把 AI 搜索做成完整产品的能力。它们确实能减少应用层胶水代码，也正好对应我们继续提升 AI 问答体验时希望补齐的环节。

试用体验很好，长期授权却算不过账

Elastic 的 Start trial API 可以开启 30 天试用，并开放全部订阅功能。我们实际试用后，感受并不是“这些高级功能可有可无”，恰恰相反：原生 RRF、模型与推理管理、统一的过滤和排序链路，确实让开发和管理体验顺畅很多。

但试用只能回答“好不好用”，不能回答“能不能长期用”。按照 self-managed license 管理文档，许可证过期后会回到 Basic；要保留 Platinum 或 Enterprise 能力，就需要续期或采购。

也正因为体验不错，我们认真考虑过付费。按当时接触到的方案，费用会随节点数量或资源规模增加。我们的系统为了数据冗余、检索负载和多个项目隔离，本来就需要多节点运行；把单节点或资源单元的授权成本累积到完整集群后，已经超出多数高校课题和公益数据库能够长期承担的范围。

这些年，我们也常把实际使用中碰到的问题和改进建议反馈给官方。一次交流中，一位市场人员半开玩笑地说：

“问题在于，你们只是用户，而不是我们的客户呀。”

这句话我们并不觉得冒犯。免费用户的需求可以被听见，但付费客户自然更能影响产品路线、支持优先级和资源投入。我们还评估过阿里云等云合作伙伴提供的托管 Elasticsearch；托管服务能减少安装、升级和运维负担，但在我们的数据规模、节点数量和长期运行周期下，持续费用仍然较高。课题经费也许可以覆盖建设期，真正困难的是项目结项之后如何继续提供公共服务。

我们理解并尊重这种市场策略。Elastic 是上市公司，需要持续投入底层研发、云基础设施、安全、支持和生态建设，也有责任建立可持续的商业模式。问题不在于“收费是否合理”，而在于这套成本结构是否适合教育、科研和公益项目。

项目二：Easysearch 原本只是一个轻量选择

第二个项目的起点完全不同。它处理的是百万级历史报刊文章与版面数据，首要任务是固定短语检索、同文共现、词间距离、时间线、版面分布和时期聚合；最初既没有 AI 问答，也没有复杂的多路语义召回。

这个项目从一开始就使用 Easysearch。原因很实际：部署轻量，中文分析和 Query DSL 够用，ES API 的使用习惯比较熟悉，SQL/JDBC 也方便统计人员和报表工具读取结果。对于这样一个边界清楚的新项目，没有必要先部署 Elasticsearch 再做一次迁移。

实际接触一段时间后，Easysearch 给我们的好感不只来自“国产化”。遇到 mapping、中文分析、插件行为或许可边界问题时，官方人员回应很快，态度诚恳，很多问题可以直接得到一线开发者的解释。即使某项能力暂时不存在，对方也通常会说明当前实现和限制。对需求不完全标准化的科研项目来说，这种反馈效率很有价值。

随着 Easysearch 增加向量检索、Ollama embedding、语义搜索、Search Pipeline 和混合排序，原来的轻量选择开始具备承接复杂检索的可能。INFINI Labs 又推出面向开源项目和教育机构的免费许可证：符合条件的非商业教育科研项目经申请批准后，可以获得与企业版本同等的产品功能。

从“感觉不错”到“能否平替”

但在轻量项目里运行顺利，不等于它可以直接承接第一个项目。两边的向量字段不同，kNN 查询 DSL 不同，官方 Elasticsearch Python client 还会进行产品识别；范围过滤后的 top-K、应用层 RRF、分页、聚合和索引维护能否保持一致，都需要逐项确认。

这才有了后面的功能验证。我们没有拿产品文档互相对照后就宣布兼容，而是从两个真实系统抽取同一批数据、同一组查询和明确真值，写入独立临时索引。两套生产索引始终只读，测试完成后删除临时数据。文章后半部分的 3578 条文档、25 条词法查询、22 条 dense 查询和 540/540 范围返回，都是为了回答这个具体问题。

二、两个产品及其背后的公司

Elasticsearch 与 Elastic

Elasticsearch 是产品，Elastic 是开发和经营这套产品的公司。按照 Elasticsearch 当前官方定义，它是基于 Apache Lucene 构建的分布式搜索与分析引擎，同时也承担可扩展数据存储和向量数据库的角色。围绕 Elasticsearch，Elastic 又形成了数据采集、可视化、可观测性和安全分析等完整产品体系。

Elastic 官方公司资料显示，公司成立于 2012 年，创始团队来自 Elasticsearch 和 Apache Lucene 项目。目前 Elastic 在纽约证券交易所上市，代码为 ESTC，并将自己定位为“Search AI Company”；其业务早已不只限于全文检索，还覆盖可观测性与安全等领域，见 Elastic 官方公司介绍。

区分产品和公司，是为了避免把技术评价与商业政策混在一起。我们日常部署和调用的是 Elasticsearch，订阅分层、产品路线和商业支持则由 Elastic 制定。本文讨论许可成本时，针对的是 Elastic 的 self-managed 订阅政策，并不否定 Elasticsearch 这项技术本身。

Easysearch 与 INFINI Labs

Easysearch 同样是产品，背后的公司是 INFINI Labs（极限科技）。公司时间线显示，INFINI Labs 成立于 2021 年，Easysearch 于 2023 年正式发布。与发展十余年的 Elasticsearch 相比，它仍是一个年轻产品。

按照 Easysearch 产品概述，Easysearch 是基于 Apache Lucene 的分布式 AI 搜索型数据库，覆盖全文、结构化数据、向量、地理位置和聚合检索，并以兼容 ES API 和相关生态工具作为迁移路径之一。它也强调中文处理、轻量部署和国产软硬件适配。

“兼容 ES”在这里不等于“就是另一个 Elasticsearch”。两者共享不少概念和 API 习惯，但向量字段、查询 DSL、客户端识别、插件体系和许可机制都有差异。也正因为这种相似与差异并存，迁移不能只靠产品页判断，必须落到实际 mapping、查询和结果上。

三、本文涉及的几种检索能力

后文会反复出现 BM25、dense vector、ANN、RRF 和 inference。这里先说明它们分别解决什么问题，避免把“AI 搜索”当成一个不可拆分的黑箱。

BM25 与倒排索引

传统全文检索会把文本切成词项，并建立从词项到文档的倒排索引。BM25 会综合词频、文档长度和词项稀有程度计算相关性。

它非常适合：

搜索固定表述、专有名词、人名和机构名。
使用 match_phrase 要求词项顺序连续。
使用 bool 查询组合“必须出现”“至少出现”“不得出现”。
配合 IK、拼音、简繁转换和同义词优化中文检索。
高亮实际命中的原文。

BM25 的弱点也很明确：如果用户说“面向基层的工作方法”，原文写的是“群众路线”，两段文字可能语义相关，却没有共享足够的词项。

稠密向量（dense vector）

Embedding 模型会把文本转换成一组浮点数。例如我们使用的 BGE-M3 dense 输出是 1024 维：

[0.031, -0.087, 0.114, 0.006, ...]

查询文本和文档文本经过同一个模型后，可以用 cosine similarity 比较方向是否接近。这样，即使两者词面不同，只要模型认为语义接近，也可能互相命中。

向量检索适合概念发现、问答检索、跨表述匹配和多语言场景。但它不应完全替代全文检索：人名、年代、文件编号、特定术语和原句核验通常仍由词法检索更可靠。

精确向量搜索与 ANN

如果把查询向量与过滤范围内每个文档向量逐一计算相似度，再排序取前 K 条，就是 exact search。它的语义很直接：只要候选域定义正确，返回的就是这一候选域内真正的 top-K。

当数据规模很大时，逐一比较可能代价较高，这时就会用到 ANN，即 approximate nearest neighbor。HNSW、LSH 等方法先快速找到一批可能相近的候选，再返回近似 top-K。

ANN 的重点不只是“快不快”，还包括：

召回率：真正相关的向量是否进入候选集。
过滤语义：先限定某本书再找 top-K，还是先在全库找候选再过滤。
underfill：请求 50 条时，过滤后是否只剩 18 条。
可重复性：参数和数据变化是否造成明显漂移。

我们的迁移探索曾经在这里走错一次，后文会详细说明。

混合检索与 RRF

混合检索不是简单把 BM25 分数和 cosine 分数相加。两种分数的量纲、分布和上限不同，直接相加经常不稳定。

比较常见的做法是 RRF，即 Reciprocal Rank Fusion。它不直接比较原始分数，而是根据每一路的名次加分：

RRF(document) = Σ 1 / (rank_constant + rank_i(document))

某文档如果在关键词结果和向量结果中都排名靠前，就会获得更高的融合分。RRF 简单、稳定，并且不要求 BM25 与 cosine 处于同一分值区间。

Elastic 提供原生 RRF retriever，但当前 self-managed 订阅矩阵把 RRF、linear/rule/text-similarity retriever、Query Rules 和 LTR 列在 Enterprise。其算法与使用方法见 Elastic RRF retriever 文档。

Easysearch 文档也提供基于 AI 插件和 Search Pipeline 的 hybrid_ranker_processor，使用 RRF 融合多路查询，见 Hybrid Ranker Processor 文档和 Search Pipeline 文档。

此外，RRF 完全可以放在应用层实现。这次正式等效测试使用的就是应用层 RRF，没有调用任何一端的原生 RRF 功能。

模型推理的部署位置

搜索数据库保存向量，不等于搜索数据库必须生成向量。常见架构有两种：

数据库内管理模型或推理端点，在写入和查询时自动调用。
应用层调用本地 Ollama、vLLM 或第三方 API，再把生成的向量写入数据库。

第一种更一体化，能减少应用代码，但容易受数据库许可、模型支持列表和生命周期管理方式约束。第二种组件更多，却更容易跨数据库迁移。

我们采用第二种：文献处理应用在应用侧调用本地 Ollama bge-m3:latest，生成 1024 维向量，然后写入搜索后端。Easysearch 与 Elasticsearch 看到的是同一组浮点数，因此模型不需要跟着数据库一起更换。

Easysearch 自身也支持 Ollama、OpenAI 等 embedding 服务、文本向量化处理器和语义查询增强器，见 Easysearch Embedding 服务集成；但这次测试没有依赖该原生 AI 插件路线。

BGE-M3 还可以输出 sparse lexical weights，也就是 token-to-float 形式的加权稀疏向量；模型同时支持 dense、sparse 和 multi-vector，见 BAAI/bge-m3 与 BGE-M3 论文。Elasticsearch 的 sparse_vector 可以保存这类数据，而 Easysearch 当前的 knn_sparse_bool_vector 不能直接承载浮点权重，见 Elastic sparse vector 字段文档。

这项差异只涉及未来可能增加的 BM25+dense+sparse 三路融合。当前线上功能从未启用 content_sparse，实际使用的是 lexical、semantic 和 lexical+dense hybrid，所以它既不在本次功能契约内，也不影响当前迁移结论。等到真的启用三路融合时，再单独设计应用层融合或其他存储方案即可。

四、两套许可体系的功能边界

许可政策会变化，网上很多旧文章和截图已经不可靠。本文统一以 2026-07-11 可访问的 Elastic self-managed 当前订阅矩阵和 2026 年 2 月导出的官方矩阵 PDF 为准。

先纠正一个容易传播的说法：Elasticsearch 的基础向量搜索不是付费专属能力。 当前 Basic 已经包含 vector field、基础 kNN、相似度函数和标准 retriever。TLS、RBAC、Query DSL、聚合、快照恢复、ILM 等大量基础能力也在 Basic。

教育科研项目需要关注的差别主要集中在下面这些能力。

能力	作用	Elastic self-managed	Easysearch 普通版本	Easysearch 教育许可
TLS、基础 RBAC	加密通信、用户和角色授权	Basic	社区版	免费
kNN 向量搜索	dense 语义召回	Basic	社区版	免费
LDAP / AD	接入学校统一身份目录	Platinum / Enterprise	当前报价页列为社区版	免费
ABAC	根据用户/资源属性动态授权	Platinum / Enterprise	当前报价页列为社区版	免费
文档级 / 字段级权限	不同用户只能看获准文档或字段	Platinum / Enterprise	当前报价页列为社区版	免费
IP 黑白名单	限制来源网络	付费层级	当前报价页列为社区版	免费
JDBC / ODBC	BI、报表或传统数据工具连接	Platinum / Enterprise	SQL/JDBC 当前列为社区版	免费；Easysearch 未在该表承诺 ODBC 等价
审计日志	记录谁在何时访问或修改了什么	Platinum / Enterprise	Easysearch 企业版	经审批的学术企业许可免费
同版本跨集群复制	灾备、异地只读副本	Platinum / Enterprise	Easysearch 专业版起	经审批的学术企业许可免费
不同版本跨集群复制	迁移、升级和跨版本容灾	Elastic CCR 不以此方式区分	Easysearch 企业版	经审批的学术企业许可免费
可搜索快照	不完整恢复索引也能直接搜索快照	Enterprise	Easysearch 企业版	经审批的学术企业许可免费
原生 RRF	数据库内融合 BM25、dense、sparse 等排序	Enterprise	Easysearch AI 插件提供 RRF pipeline；具体 feature flag 需核验	学术企业许可原则上覆盖，仍应核对签发内容
Query Rules / LTR	业务规则干预排序、训练排序模型	Enterprise	Easysearch Rules/Search Pipeline 路线并非一一同构，Rules 插件要求 license	可申请企业功能，但必须逐项验证语义
ML 节点第三方模型管理	在集群内管理和部署模型	Platinum / Enterprise	Easysearch AI 插件支持外部模型管理	学术企业许可可降低许可门槛；模型能力不等同
ELSER / e5 集群内模型	Elastic 自带 sparse/dense 模型	Platinum / Enterprise	没有同名模型；可接 BGE、Qwen、Ollama 等	是替代路线，不是同一实现
Elastic Rerank / EIS / Inference API	托管或统一调用 embedding、rerank、LLM	Enterprise	Easysearch AI 插件与外部模型服务可承担部分工作	学术许可可覆盖产品能力；外部模型费用另计

读这张表时，需要把三类情况分开：

双方都免费：BM25、基础向量、基础安全和常用 Query DSL。
Elastic 付费、Easysearch 社区版直接包含：LDAP/AD、ABAC、文档/字段级权限、SQL/JDBC 等。
双方在普通商业场景都可能要求高级版本，但合格教育机构可免费获得 Easysearch 企业功能：审计、CCR、可搜索快照、部分 AI 和规则能力。

RRF：原生实现与应用层实现

RRF 原生实现的价值，是让多路检索在数据库内部完成：应用只发一个请求，数据库负责召回、融合、分页和过滤。应用复杂度会下降，特别适合标准化搜索服务。

但 RRF 公式本身并不复杂。我们可以分别请求 lexical 和 dense，再在应用层按名次融合。这条路线不依赖 Elastic Enterprise，也不依赖 Easysearch AI 插件。代价是应用要处理多请求、统一过滤、分页、超时和可解释信息。

所以“Elastic 原生 RRF 是 Enterprise”不等于“Basic Elasticsearch 不能做混合搜索”，准确说法是：Basic 下不能直接使用该原生高级 retriever，但可以自行实现融合。

Easysearch 的教育许可让原生 AI pipeline 更值得尝试，但我们仍建议保留应用层 RRF 作为可移植基线和回退路线。

模型管理与推理接口

将模型管理、推理端点、自动分块、embedding、rerank 和 LLM provider 全部纳入搜索集群，能减少 AI 搜索开发中的胶水代码。Elastic 把 ML 节点第三方模型管理、ELSER/e5、Elastic Rerank、EIS 和 Inference API 分布在 Platinum/Enterprise。我们最早感受到 license 限制的，正是这一领域。

Easysearch 提供 AI 插件、模型提供商管理、Ollama/OpenAI embedding、ingest 文本向量化和 semantic query enricher。教育许可使这些企业功能对符合条件的科研项目更容易获得。

但从架构独立性看，我们更倾向于把 embedding 模型保持在应用侧：

模型可由 Ollama、vLLM 或独立服务管理。
Elasticsearch 与 Easysearch 共用同一向量。
模型升级不强制重构搜索客户端。
数据库迁移时不需要同时迁移推理基础设施。
外部 API 429、模型审查、上下文长度和并发策略可以由统一 provider 层处理。

数据库原生推理是一项便利能力，不应自动成为数据格式和模型生命周期的唯一入口。

高校同样需要细粒度安全

高校项目经常同时存在公开语料、合作方授权语料、内部校订稿和受限原图。仅有“管理员/普通用户”两级角色通常不够。

文档级安全可以表达：某用户只允许搜索某批书。字段级安全可以表达：普通用户能看正文和引用信息，却不能看到内部审校备注。LDAP/AD 可以接入学校已有身份目录。ABAC 可以根据院系、课题组、数据许可和项目角色动态决定访问范围。审计日志则用于回答“谁在什么时候访问了哪些受限数据”。

Elastic 当前把 LDAP/AD、SSO、ABAC、字段/文档级安全和审计日志放在付费层级。Easysearch 当前报价页把 LDAP/AD、ABAC、文档/字段级权限和 IP 黑白名单列入社区版；审计日志属于企业版，但教育机构可申请企业功能免费许可证。

这可能是教育科研场景里比 AI 搜索更直接的许可优势。

SQL API 不等于 JDBC/ODBC

研究团队不一定都通过搜索 API 工作。统计人员可能使用 BI 工具，教师可能使用熟悉 SQL 的客户端，项目验收还可能要求报表系统读取搜索结果。

Elastic 的 SQL API/CLI 与 JDBC/ODBC 不是同一个许可层级。当前矩阵中 JDBC、ODBC 和 Tableau Connector 位于 Platinum/Enterprise。Easysearch 当前报价页明确把“SQL 语法支持，包括 JDBC 客户端”列入社区版。

这不能保证所有 SQL 方言和驱动行为完全一致，但它降低了为普通数据分析接入单独购买高级许可的门槛。

长期运行需要 CCR、审计与可搜索快照

课题建设期最关注功能，上线几年后真正困难的往往是维护：

主机损坏后能否快速恢复。
校内外两地是否能保留副本。
升级期间能否逐步迁移。
冷数据能否放在对象存储，同时保持查询能力。
出现数据争议时能否追溯访问和操作。

Elastic 的 CCR 和审计位于 Platinum/Enterprise，可搜索快照位于 Enterprise。Easysearch 普通报价中，同版本 CCR 从专业版开始，可搜索快照和审计属于企业版；不过教育机构学术许可证可提供企业版同等产品功能。

五、教育许可证的价值与边界

根据 INFINI Labs 社区计划当前页面和教育机构申请页面，学术许可证覆盖公立或私立学校、职业学校、函授学校、专科学院、大学、科研或技术机构。许可仅限非商业用途，软件副本只能由获许可机构的学生、教职员工使用。

现行政策的核心是：开源项目与教育机构免费许可证所覆盖的 INFINI Labs 产品，功能等同于相应企业版本，但仅供非商业使用。

许可证有效期一年；如果项目继续符合计划要求，可以续申。2024 年的免费许可证计划升级公告也明确说明教育机构许可免费、一年有效并可继续申请。

对高校项目来说，变化很具体：

不必把架构永久限制在社区版功能边界内。
可以在真实科研需求下评估企业级安全、容灾、AI 和数据管理能力。
可以先以功能正确性为标准选型，而不是先删除所有可能收费的功能。
项目经费可以更多投入数据治理、OCR、模型算力、人工校订和长期保存。

申请和使用时还要注意：

免费许可需要申请和审核，不是下载后自动获得。
许可限于非商业用途；商业化、对外收费或交付性质变化时必须重新确认。
免费的是产品功能许可，不自动等于商业技术支持、专属顾问或 7×24 服务免费。
GPU、服务器、存储、带宽、外部模型 API 和运维人力仍然有成本。
政策和 feature flags 可能变化，部署和续期时应以实际签发 license 与当期条款为准。

Easysearch 是商业软件，教育免费 license 也不等于开源许可证。这两件事不应混淆。

六、同一批数据上的功能复核

测试环境与边界

我们测试的是两个真实运行环境：

Elasticsearch 8.18.2，现有主项目使用 dense_vector、1024 维、cosine、int8_hnsw。
Easysearch 2.3.1，轻量项目已经在使用其全文检索、IK/CJK 分析、聚合和安全能力。

Elasticsearch 侧承载的是研究型文献库；Easysearch 侧承载的是另一个报刊话语分析项目。两套生产索引在测试中均只读，所有写入都进入带独立前缀的临时索引，测试结束后删除并复核不存在残留。

这次没有测试性能，也没有记录延迟、吞吐、资源占用、索引体积或 P50/P95。我们只回答一个问题：当前已经使用的功能，经过明确适配后能否正确工作。

LSH 路线暴露的问题

最初我们把 Elasticsearch 的 dense_vector + int8_hnsw 转换成 Easysearch 的 knn_dense_float_vector + LSH。API 能运行，但真实过滤查询出现系统性 underfill：在单书或套系范围内请求 K 条时，Easysearch 的 LSH 候选会先在更大范围生成，再经过过滤后不足 K 条。提高 candidates 能缓解，却不能保证过滤后仍凑满 K 条。

如果测试到这里就停，结论会是“Easysearch 不支持等效的范围向量检索”。这个结论后来被证明下得太早。

进一步研究 Easysearch 文档后，我们确认它还支持 model=exact。测试目标也随之调整：不再比较 Elasticsearch 的 HNSW 与 Easysearch 的 LSH 谁更像谁，而是把过滤范围内的精确 cosine 排序作为真值。两条 ANN 路线不同，并不能证明 Easysearch 没有其他正确实现。

复核结果

正式测试在两端写入相同的 3578 条真实文档，包括确定性背景样本、词法查询候选、dense 查询候选和明确黄金样本。

结果如下：

测试项	结果
精准词法	25/25 条查询的 top-10、top-50 双端一致
Easysearch exact dense	22/22 条相对精确 cosine 真值的 recall@10、recall@50 均为 1.0
单书/套系过滤 dense	11 条非空范围查询全部返回完整 K；累计应返/实返 540/540
零候选控制	正确返回 0
应用层 RRF	22/22 条 top-10、top-50 与 lexical+exact 参考结果一致
本地 embedding	Ollama `bge-m3:latest` 1024 维向量在两端均往返成功并命中自身 top-1
查询契约	phrase、高亮、bool、filter、term、range、exists、wildcard、prefix 全部通过
分页与聚合	sort、from、search_after、collapse、terms、cardinality、date histogram、top hits 等通过
维护契约	bulk、scroll、update/delete by query、reindex、alias 原子切换全部通过
安全结果	两套生产 alias 和文档数前后不变，临时索引均已清理

完整运行日志、测试程序和脱敏聚合证据均在内部工程仓库中留存。公开文章只使用汇总数字，不公开开发项目名、生产索引、服务地址、原始正文、向量或查询级分歧样本。

等效迁移仍需要适配

Elasticsearch 与 Easysearch 不是字段名不同的同一个产品。当前等效路线至少需要三类 adapter。

第一类是 mapping：

Elasticsearch:
dense_vector + dims=1024 + cosine + int8_hnsw

Easysearch:
knn_dense_float_vector + dims=1024

第二类是查询 DSL：

Elasticsearch:
knn / retriever DSL

Easysearch:
knn_nearest_neighbors + model=exact + similarity=cosine

第三类是客户端：官方 Elasticsearch Python client 会进行产品识别，并拒绝把 Easysearch 当作 Elasticsearch 连接。需要显式 HTTP adapter、Easysearch 客户端，或者在统一 backend interface 下分别实现连接器。

因此，我们的结论是 functional_equivalent_with_adapter=true，不是 drop_in_equivalent=true。

七、迁移边界

经适配可以覆盖

中文全文检索、IK 分词、短语搜索和高亮。
bool 组合、过滤、范围、存在性、通配和前缀查询。
关键词精准检索与高级筛选。
1024 维 dense vector 和 cosine 语义搜索。
单书、套系、篇目、时期等过滤范围内的 exact top-K。
应用层 RRF hybrid。
常用排序、分页、collapse 和聚合。
bulk、scroll、update/delete by query、reindex 和 alias 切换。
应用侧 Ollama/BGE-M3 embedding 服务。
当前前端依赖的 lexical、semantic、hybrid 三种模式。

不能原样照搬

至少以下部分不能原样照搬：

Elasticsearch dense_vector mapping 和 HNSW 参数。
Elasticsearch kNN/retriever DSL。
官方 Elasticsearch Python client 的直接连接。
Elasticsearch ANN 与 Easysearch exact 的逐位相同分数或排序。
Elastic 原生 RRF、Inference API、ELSER 等产品工作流本身。

迁移前仍需完成

全量数据规模下 exact 的运行成本。
两种后端的延迟、吞吐、内存、磁盘或能耗差异。
长时间运行、故障恢复和混合负载表现。
Easysearch 原生 AI pipeline 与应用层 RRF 的完整行为差异。
人工专家对不同 ANN 排序的相关性偏好。

到这里，剩下的待办已经不是功能可行性问题。对当前项目，下一道门槛是用真实规模完成性能、容量和稳定性测试，并演练切换与回滚；只要达到预设阈值，就可以开始按索引或站点分阶段迁移。

八、迁移实验留下的架构原则

比“把 ES 换成 Easysearch”更有价值的，是趁这次迁移把搜索系统拆成可以验证、替换和回退的层次。

数据模型不绑定搜索产品

书、篇目、段落、日期、页码、来源和质量字段应该由主线数据模型定义，而不是由某个搜索引擎 mapping 反向决定。这样才能在两个后端间转换，也能在未来引入关系数据库或对象存储。

Embedding 服务独立部署

应用侧 embedding 让模型版本、并发、重试、审查策略和本地 GPU 调度保持统一。数据库只消费向量，不垄断模型生命周期。

用 capability contract 描述后端

不同后端不能假装 API 完全相同。每个 adapter 应明确声明：

是否支持 phrase/highlight。
是否支持 pre-filter 或 filter-domain exact top-K。
向量字段类型和相似度。
是否有原生 RRF，还是应用层融合。
是否支持 DLS/FLS、审计、CCR 和可搜索快照。
客户端和错误语义是什么。

功能、性能与上线安全分开验收

功能等效、性能可行和上线安全是三个不同门槛。一个小样本 API 能运行，不代表全量可上线；同样，一条 ANN 路线表现不好，也不能证明整个产品没有功能等价路线。

架构层面理清之后，还剩一个常被低估的问题：省下的许可预算应该投向哪里。

九、许可预算与数据质量投入

对公共知识基础设施来说，长期成本往往落在数据治理上，而不只是软件安装：

扫描件获取与保存。
OCR 和版面分析。
目录、正文、序跋、注释和参考文献识别。
跨页段落合并。
篇目与原始发表日期校订。
页码映射与原图核验。
研究者反馈后的持续修正。

如果教育许可证获批，省下来的许可预算就可以更多转向这些直接决定学术质量的工作。团队也能在真实环境中学习企业级安全、容灾、审计和 AI 搜索，而不是只能在演示版或短期 trial 中接触。

对于参与项目的学生，这种完整环境也比单独写一个向量数据库 demo 更有训练价值。他们需要理解：

数据质量如何影响检索。
词法与语义检索为什么互补。
过滤语义为什么比“接口返回 200”更重要。
权限、审计、备份和回滚为什么属于系统设计。
license、技术等价和运行成本为什么必须分别讨论。

十、迁移前的六项检查

如果你的项目也是高校、科研院所或非商业开源项目，可以按下面的顺序排查：

核对资格和用途。 确认主体是否属于教育、科研或技术机构，项目是否为非商业用途，实际使用者是否为本机构学生和教职员工，不要先假设自己当然符合。
申请并核对实际许可证。 通过教育机构免费许可证申请页面提交申请。收到 license 后，不只看“Enterprise”字样，还应核对有效期、节点范围和实际 feature flags，特别是 AI、rules、audit、CCR 等插件能力。
从系统反推依赖。 根据应用代码、mapping、查询日志和前端功能列出实际使用的能力。尚未启用的 future feature 应单列，不能混入当前迁移阻塞。
建立同集、同查询、同真值测试。 两端写入同一批文档，使用同一 embedding，固定 lexical 和 semantic 查询。向量比较应尽可能使用 exact cosine 作为真值，不要把任一 ANN 后端的 top-K 自动当作正确答案。
区分原生能力与替代实现。 名称相近或目标相同，不代表执行过程和运维语义相同。Elastic 原生 RRF 与应用层 RRF 的算法目标相同，运维和分页语义却不同；ELSER 与 BGE-M3 sparse 都属于 learned sparse，模型和数据格式并不相同；Elasticsearch HNSW 与 Easysearch exact 都能提供 top-K，也不是同一种执行方式。Query Rules 与 ingest Rules Engine 虽然都有“规则”二字，作用阶段也可能完全不同。
保留回滚。 新建候选索引，双读验证，按 alias 或后端配置逐步切换。原索引和原服务在验证阶段只读保留。任何迁移都应能回答“失败后如何在分钟级恢复”。

对于同类新项目，情况反而更简单。新系统没有历史 mapping、查询 DSL、客户端和存量索引的兼容负担，只要需求落在已验证的功能范围内，就可以从第一天直接使用 Easysearch，不必先部署 Elasticsearch 再等待一次迁移。适配层和 capability contract 仍然值得保留，但它们此时是架构设计，不是迁移成本。

十一、结语

Elasticsearch 仍然是一套成熟而强大的搜索与 AI 搜索平台，我们长期使用它的理由没有消失；它的 Basic 版本也已经包含基础全文、向量和安全能力，不能笼统地说成“ES 的向量搜索都要收费”。但对教育科研项目而言，产品成熟并不自动等于许可和长期成本最合适。

差别出现在更高一层。原生融合、规则排序、模型管理、高级安全、审计、容灾和快照等能力，在 Elastic 的订阅体系中有明确的付费边界。Easysearch 社区版直接提供了其中一部分能力；对符合条件的非商业教育科研项目，学术许可证还能提供与企业版本同等的产品功能。长期部署时，这笔账就需要重新算。

就我们已经使用的功能而言，Easysearch 经过 adapter 后已经覆盖 lexical、dense semantic、范围过滤和应用层 RRF hybrid，查询、分页、聚合和索引维护契约也全部通过。BGE-M3 weighted sparse 从未用于当前线上系统；未来如果增加三路融合，再作为一项独立能力设计即可。

对我们现有的真实项目，剩余工作是完成真实规模下的性能、容量、稳定性测试和回滚演练。这几道门槛过了，就可以开始分阶段迁移到 Easysearch。

对于需求相近的新建教育科研或公益知识项目，结论可以更直接：如果需求落在已验证的功能范围内，可以从一开始就使用 Easysearch。教育许可证还会进一步降低高级安全、审计、容灾和 AI 功能的使用门槛。

数据模型和 embedding 服务仍应保持独立，搜索后端也应保留 capability contract。就当前证据而言，存量项目可以进入迁移准备；新项目如果需求相近，可以直接部署。

参考资料

许可声明：本文根据 2026-07-11 可访问的官方页面整理，不构成法律、采购或商业授权意见。正式部署、续期或用途变化时，应以当期政策、实际签发许可证和双方书面约定为准。