作为一名 Java 开发者，你是不是也有过这样的焦虑：kan着满屏的 Python 教程和层出不穷的向量数据库名词——Milvus、Pinecone、Qdrant，感觉Ru果不赶紧把这些新技术栈堆进自己的项目里明天就要被淘汰了？特别是当你准备动手搞一个 RAG应用时这种焦虑感geng是达到了顶峰。

但我想说先别急着引入新组件。Ru果你的技术栈里Yi经躺着 Elasticsearch，那么恭喜你，对于绝大多数场景下的 Spring AI RAG 应用，ES 足矣。真的，不需要再为了那点向量检索Neng力去维护一套全新的数据库系统，这不仅是资源的浪费，geng是未来运维噩梦的开始。

深夜的调试现场：当 RAG 遇上性Neng瓶颈

让我们把时间拨回到某个深夜。你正在为公司的新一代智Neng答疑助手ZuoZui后的性Neng压测。这是一个基于 Spring AI 搭建的 RAG 系统，旨在帮助学生自动解答课程相关的问题。一切kan起来douhen美好，直到你模拟并发请求的那一刻。

日志显示，用户的一个简单查询——“丹麦第二大城市的历史沿革”，竟然需要等待整整 5 秒才Neng返回结果。geng让你崩溃的是通过链路追踪发现，这 5 秒里有 90% 的时间dou消耗在了向量相似度计算上。那一刻，你的内心可Neng是崩溃的：难道我必须去学 Milvus 的运维手册了吗？

其实问题可Neng不在于你缺一个专用的向量数据库，而在于你是否挖掘了现有 Elasticsearch 的潜力。ES 从 7.x 版本开始，就Yi经悄悄埋下了一颗彩蛋——dense_vector 字段类型。而到了 8.x 版本，这颗彩蛋geng是长成了参天大树，直接引入了原生的 kNN 搜索Neng力，底层用的正是工业界Zui主流的 HNSW 算法。

揭开 HNSW 的面纱：像查地图一样找向量

提到 HNSW，hen多同学会被这个全称“分层可导航小世界”劝退。其实它的原理非常直观，就像我们平时查地图导航一样。

想象一下你想去一个叫“深圳”的地方旅游。你会怎么Zuo？

你会拿出一张中国地图，这就像 HNSW 的Zui顶层结构。你一眼就定位到了“广东省”这个大区域，这步hen快，因为节点hen少。接着，你切换到广东省地图，你找到了“深圳市”。Zui后你打开深圳的详细地图，精确地找到了具体的景点位置。

HNSW 就是这个思路。它构建了一个多层图结构：

顶层用于快速定位大致区域，路少但跳得远。

中层逐步缩小范围。

底层包含所有数据点，进行精确的Zui近邻搜索。

搜索时算法从顶层入口出发，像坐跳楼机一样逐层向下Zui终在底层找到Zui近的邻居。这种机制的时间复杂度大约是 O。这意味着什么？意味着在百万级甚至千万级的数据量中，你的单次查询延迟Ke以控制在几十毫秒级别。这比传统的暴力遍历快了不知道多少倍。

Spring AI 的“官方背书”：ES 作为统一存储

既然 ES 这么强，那在 Spring AI 里怎么用呢？其实Spring AI 官方早就把 Elasticsearch 纳入了“亲儿子”行列，原生支持将其作为 VectorStore。

这解决了什么痛点？解决了“双系统”的痛点。

在传统的架构里为了Zuo混合检索，你往往需要维护两套系统：一套 ES 负责关键词搜索，一套 Milvus 负责向量搜索。这简直是运维的灾难——数据写入时要双写，geng新时要双删，查询时要两边跑，Zui后还得在内存里合并结果。任何一环出问题，数据不一致，排查起来Neng让你掉层皮。

而使用 ES，你只需要一个索引，一段 Mapping。kan下面这段配置：

PUT /knowledge_base
{
  "mappings": {
    "properties": {
      "textContent": { "type": "text" },
      "vector": {
        "type": "dense_vector",
        "dims": 1024,
        "index": true,
        "similarity": "cosine"
      }
    }
  }
}

这里面的门道可不少：

dims这是向量的维度，取决于你选用的 Embedding 模型。比如你用的是 OpenAI 的 text-embedding-3-small，那这里可Neng就是 1536。

index: true这是开启 HNSW 的开关。在 ES 8.x 里默认就是开启的，不用你操心。

similarity这是相似度算法。对于文本语义检索，cosine 是首选。因为它只关注向量的方向，不关心长度，这就好比“我喜欢吃苹果”和“我爱吃苹果”，语义方向一致，不管句子长短，douNeng被判定为相似。

纯向量检索的陷阱：语义相近不代表答案正确

这时候，可Neng有杠精要跳出来了：“ES 虽然方便，但毕竟是半路出家，Neng比得上专业的向量数据库吗？”

说实话，在超大规模数据下专业向量库确实有优势。但在千万级以下ES 的性Neng完全够用。而且，纯向量检索其实有一个巨大的坑，那是无论什么数据库dou躲不过去的——语义模糊。

举个真实的例子。假设你的知识库里存着一份 UI 设计规范文档，里面写着：“竖屏模式采用上下分栏布局，横屏模式采用左右分栏布局。经典模式布局比例：题干50% + 答案30% + 草稿20%。”

这时候，用户问了一个非常具体的问题：“横屏模式的布局比例是多少？”

Ru果你只用 KNN 向量检索，系统可Neng会一脸无辜地给你返回关于“横屏布局”的描述，告诉你它是左右分栏。但在语义上，“横屏布局”和“横屏布局比例”是非常接近的，向量模型hen难区分出用户真正想要的是那串具体的数字。结果就是大模型拿到了一堆关于“布局”的废话，却唯独漏掉了Zui关键的数字。

这就是为什么我们需要 混合检索。

混合检索：BM25 与向量的双重奏

ES 的真正杀手锏，在于它Neng在一个查询里同时搞定 BM25 和向量检索，这就是传说中的“混合检索”。

BM25 是信息检索界的常青树，它擅长处理精确匹配。比如用户问“横屏比例”，BM25 Neng精准命中文档里包含“比例”这个词的段落。而向量检索擅长处理语义关联，比如用户问“如何退款”，向量Neng找到“退货流程”。

在 Spring AI 中，你Ke以利用 ES 的 rescore 机制来实现“KNN 粗召回 + BM25 精排”。或者geng简单点，直接利用 bool 查询结合 knn 子句。

业界的大厂，比如阿里云的企业知识库、字节跳动的智Neng客服，早就这么干了。他们发现，与其花大力气维护两套系统，不如把 ES 用到极致。这种架构不仅降低了运维成本，geng重要的是它解决了纯向量检索“懂语义但不懂事实”的尴尬。

Spring AI 实战：配置与避坑指南

说了这么多理论，咱们来kankan在 Spring Boot 项目里怎么落地。

你得引入依赖。这里有个小坑，Ru果你项目里用了 Redis，记得把 Spring AI 默认的 Redis 向量库自动配置给关了不然它会和你的 Redis 配置打架。

    org.springframework.ai
    spring-ai-rag


    org.springframework.ai
    spring-ai-advisors-vector-store

然后是配置类：

@Configuration
@EnableAutoConfiguration
@EnableConfigurationProperties
@AllArgsConstructor
public class VectorStoreConfig {
    // 这里配置你的 Elasticsearch Client
    // 或者直接使用 Spring AI 提供的 ElasticsearchVectorStore
}

在代码层面Spring AI 把这一切封装得非常丝滑。你只需要定义一个 Document 对象，把文本和向量塞进去，然后调用 vectorStore.add，数据就进 ES 了。查询的时候，直接传问题文本，框架会自动帮你Zuo向量化、检索、重排序，Zui后把结果拼装进 Prompt 喂给 LLM。

选型建议：什么时候该上 Milvus？

当然我不是在无脑吹 ES。作为负责任的架构师，我们得客观。什么时候 ES 足矣，什么时候你需要 Milvus？

这里有一个简单的判断标准：

数据规模Ru果你的数据量在千万级以下ES 的 HNSW 算法完全Neng hold 住延迟和召回率dou表现优异。一旦突破亿级，或者你的向量维度特别高，这时候专用向量库的内存优化和索引压缩优势才会显现出来。

功Neng需求Ru果你只需要Zuo简单的语义检索，或者基础的混合检索，ES 是首选。但Ru果你需要极其复杂的向量过滤、超大规模的实时geng新，或者对 GPU 加速有强依赖，那还是考虑 Milvus 吧。

团队成本这是Zui现实的一点。Ru果你的团队对 Java 和 ES hen熟，但对 Python 和 Milvus 一无所知，强行上 Milvus 只会增加学习成本和排障难度。

回归技术本质

说到底，RAG 的核心价值在于“检索增强”，而不是“数据库堆砌”。我们构建系统的目的是为了解决业务问题，比如那个深夜里让你头疼的 5 秒延迟，而不是为了在简历上多写几个时髦的技术名词。

Elasticsearch 8.x 的进化，让我们kan到了“老树发新芽”的惊喜。它用事实证明，一个成熟的、经过实战检验的搜索引擎，完全有Neng力承载起 AI 时代的向量检索重任。

所以下次当产品经理跑过来跟你说“我们要Zuo个智Neng助手”的时候，别慌。先kankan你的服务器上那个熟悉的 ES 集群，给它升个级，开个 dense_vector，也许你会发现：Spring RAG，ES 足矣。

---