首页 / 文章 / Java作为人工智能生产语言：Spring Boot、RAG与pgvector

java spring-boot spring-ai rag pgvector langchain4j

Java作为人工智能生产语言：Spring Boot、RAG与pgvector

一份实用指南，介绍如何使用Spring AI或LangChain4j在JVM上构建RAG服务，包括选择向量存储方案以及处理租户管理、成本控制、性能评估和故障恢复等问题。

2624 词

Python负责训练模型，而Java则逐渐成为将这些模型部署到实际应用中的语言。大约三年来，人工智能领域仿佛就是一场预算更充足的Python会议：演示都在笔记本中进行，教程以pip install开头，架构图上则有一个名为“Python LLM服务”的小方块连接在真正的后端之上。而那个真正的后端通常是Spring Boot，它早已负责处理身份验证、计费、审计日志以及数据库相关事务。

现在那个小方块已不再是必需的。Spring AI已经从1.0版本升级到2.0版本。LangChain4j则是一个成熟的JVM库，提供了二十多种模型接口以及三十多种向量存储方案。PostgreSQL可通过pgvector功能来存储嵌入向量。你已有的Spring Boot服务可以在JVM内部直接调用大型语言模型、获取相关上下文信息、调用各类工具、处理令牌流，并输出Micrometer指标数据。

这是否意味着 Java 成为了新的 AI 之王？并非那种常见的语言之争。没人会用 Java 取代 PyTorch。Java 赢得的是那些关乎金钱利益的领域：那些必须准确、可观测，同时又尽可能简洁的业务应用。如果你在相关领域工作，胜出者永远是已经运行在你生产环境中的技术，而如今这类技术越来越多地采用 Java。

本文的其余部分将阐述这一转变的脉络。内容包括其产生的原因、Spring Boot 中的 RAG 服务是什么样子、如何选择向量存储，以及哪些生产环境细节能区分演示版本与可用于处理客户数据的可靠系统。

Python 的优势始终在于研究领域

Python之所以在研究领域占据主导地位，是有其合理原因的，这些原因至今依然适用：NumPy、PyTorch、Hugging Face、Jupyter，以及一大批精通张量的工程师。模型的微调、新嵌入架构的测试或在GPU上训练，这些工作依然属于Python的范畴。

而实际应用则是另一回事。大多数企业并不会自行训练基础模型，他们只是调用现有模型，随后才开始真正的任务：获取文档、注入策略规则、隔离不同用户、记录查询请求、控制成本支出，还要确保不会出现错误的退款金额。这些工作涉及API设计、数据访问、安全保障以及运维管理，而Spring Boot自2014年起便已能处理这些问题。

将模型置于FastAPI背后的流行做法存在一定的额外成本：

单个产品中需要使用两种语言
需要独立的部署流程
需要独立的监控系统

每个迭代周期都会略有变化的接口契约

安全审查突然开始涉及那些存储自身机密信息的Python服务

人们之所以接受这种情况，是因为Java当时缺乏成熟的LLM相关工具。但到2025年这一状况已不复存在。Spring AI 1.0于2025年5月正式发布，2.0版本则与Spring Boot 4一同于2026年6月推出。同一时期LangChain4j也达到了1.0版本。如今JVM技术栈已不再落后。对于已经在使用Spring的团队而言，这是个合理的默认选择。

在Spring应用中“添加AI”意味着什么

无需重新编写代码，仅需利用三项功能即可实现。

聊天层。Spring AI中的ChatClient或LangChain4j中的AiService可将提示词和消息历史转换为模型回复。流式处理为标准功能，结构化输出可存储在Java记录中，从而无需通过正则表达式从文本中提取JSON信息。
访问自有数据。您可以计算嵌入向量并将它们存储在向量数据库中，这样答案就来源于您的策略、发票、操作手册和产品文档，而非模型仅有的零散记忆。这就是检索增强生成（RAG）技术。
工具调用。在您的授权规则允许下，模型可以调用Java方法，例如查询订单、打开工单或读取余额。此时，现有的类型系统及服务就能发挥作用。模型并非事实的来源，它是在已有数据基础上进行推理的。

在已配置好 Spring Security、Spring Data、Actuator 和 PostgreSQL 的情况下，这又是一种新的客户端类型，就如同 Redis 或 Kafka 出现时的情形一样。

为 Java 开发者讲解的 RAG

抛开神秘感，RAG 实际上是一种以语言模型为终点的搜索流程。具体步骤如下：

将文档分割成多个片段。
把每个片段转换为一个嵌入向量，即用于编码其含义的浮点数向量。
将这些向量与元数据一起保存，包括租户信息、文档 ID、来源 URI 以及生成日期。
当有查询出现时，先对该查询进行嵌入处理，再查找最相似的片段。
将这些片段插入提示词中。
指示模型仅依据这些片段来回答问题，并在无法找到答案时明确说明。

向量数据库并不能替代传统的关系型数据库，它实际上是一种语义索引，有点类似于功能更强大的 Elasticsearch。

对于使用 Spring Boot 的项目，通常从 PostgreSQL 加上 pgvector 开始。Postgres 已经部署完成、具备备份功能且支持连接池，因此引入一个扩展模块的成本远低于立即使用 Pinecone、Weaviate 或 Qdrant。在需要极高扩展性或混合搜索功能时，专用引擎确实更具优势，但大多数内部 RAG 应用其实并不需要达到那种程度。

可运行的框架结构

下面的配置是将 Spring AI 2.0 与 Boot 4 结合使用；若使用 Boot 3.4 或 3.5，则应选用 1.1.x 版本。请先引入依赖清单，以确保所有启动项都使用相同版本：

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.ai</groupId>
      <artifactId>spring-ai-bom</artifactId>
      <version>1.1.8</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

接下来，只需声明您所需的依赖项：

<dependency>
  <groupId>org.springframework.ai</groupId>
  <artifactId>spring-ai-starter-model-openai</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.ai</groupId>
  <artifactId>spring-ai-starter-vector-store-pgvector</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-jdbc</artifactId>
</dependency>

JDBC是特意列出的。pgvector启动器是通过JdbcTemplate来工作的，忘记添加该依赖是导致启动失败的常见原因。

相关配置位于application.yml中。这正是Spring AI的设计理念：模型应像数据源一样进行配置。

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/app
    username: app
    password: ${DB_PASSWORD}
  ai:
    openai:
      api-key: ${OPENAI_API_KEY}
      chat:
        options:
          model: gpt-4o-mini
          temperature: 0.2
      embedding:
        options:
          model: text-embedding-3-small
    vectorstore:
      pgvector:
        initialize-schema: true
        index-type: HNSW
        distance-type: COSINE_DISTANCE
        dimensions: 1536

此文件中的两个细节比表面看起来更为重要。嵌入维度必须与嵌入模型生成的数值一致，而text-embedding-3-small生成的数值为1536。如果更换模型却忘记这个数值，相似度搜索功能虽不会报错，但性能会下降。第二个要点是RAG任务应使用较低的温度参数，因为你需要的是与检索到的文本高度相似的输出，而非对报表内容的创造性改写。

应将数据导入视为独立的服务，而非简单的控制器指令。VectorStore.add(...)方法可接收Document格式的数据块，每个数据块都应包含日后用于过滤的元数据，如tenantId、source、docType和effectiveDate。如果没有这些过滤条件，语义搜索可能会在某个客户的答案中显示出另一个客户的合同内容。

查询流程同样简洁。Spring AI中的QuestionAnswerAdvisor实际上就是该循环的一种固定实现方式：获取数据、添加上下文、调用模型。如果需要过滤、重排序或引用功能，可自行使用similaritySearch，并将filterExpression视为WHERE子句，因为这正是它的作用。

选择向量存储时无需盲目跟风

共有四种可选方案：

搭配pgvector的Postgres。这是最合理的默认选择，操作方式也最为成熟。借助HNSW索引、召回率监控以及紧凑的数据块结构，它能够处理数千万个向量数据。不过在需要高级混合搜索功能或专门的近似最近邻查询基础设施支持时，它的表现就会不足。

Redis。响应速度快，通常已集成在 Spring 生态系统中，适合用于会话存储及小型知识库。需要权衡的是其内存占用成本。

专为搜索设计的引擎（Qdrant、Weaviate、Milvus、Pinecone）。当搜索本身就是核心功能时，这些引擎非常适用：处理大规模语料库、词汇与向量混合查询、多索引场景，或是需要专为近似最近邻算法设计的软件。Spring AI 直接支持这些流行的引擎。

您已有的搜索引擎。Elasticsearch 和 OpenSearch 支持 kNN 查询，如果文档已经存储在这些系统中，使用现有的密集向量场即可，无需再添加第四个数据系统。

决策方法很简单，这正是它的优势。当 Postgres 已经在生产环境中运行时，就从 pgvector 开始使用。只有当召回率、延迟或混合搜索无法满足实际的服务水平指标时才需要更换方案，而非因为某些说法称严肃的 AI 应用必须使用某种产品。此外，应在每个向量旁边保留原始记录的引用，这样在策略发生变化时就可以重新嵌入向量。

最后一点正是教程中常常忽略的。嵌入模型会不断更新，分块处理方式也会变得更智能，法律文件也会被修订。如果有一个基于文档版本且具有幂等性的数据导入任务，就能避免你花费大量时间去查明为什么机器人会引用去年的费用标准。

Spring AI 与 LangChain4j

两者都已准备好投入生产环境。选择哪一种取决于你们团队当前所处的阶段。

Spring AI沿用了Spring中熟悉的可移植抽象理念，并将其应用于模型开发。若将其视为LLM领域的Spring Data，便会觉得十分自然——自动配置、ChatClient、顾问组件、Actuator以及Micrometer等功能都能无缝集成。在Boot 4上可使用2.0版本；而在Boot 3上则需继续使用1.1.x版本，因为2.0无法直接兼容。

LangChain4j最初是为Java开发的，同时也提供了Spring启动器。它支持更多的服务提供者，其带类型的AiServices类似于指向模型的Feign客户端，非常适合同时使用Quarkus或纯Java的团队。那些希望对代理循环进行精细控制的人通常会选择它。

没有任何因素能阻止你同时使用这两种技术。一种可行的方案是：用 Spring AI 处理聊天功能，而在面向客户的服务中使用 RAG，再通过 LangChain4j 来填补特定提供商或代理模式下的需求。应将它们的组件分开管理，绝不能让两种不同的嵌入模型将不兼容的向量写入同一个表格中。

如果整个系统都是 Spring-Boot 构建且已准备好升级到 Boot 4，那么选择 Spring AI 更为合适。而对于混合 JVM 环境，或是已多年停留在 Boot 3 版本的系统，LangChain4j 对该框架版本更新的依赖程度会相对较低。

在生产环境中，JVM 具有优势

任何人都能演示出功能响应，但产品必须能够通过严格审查。以下是需要重点考虑的方面：

约束与拒绝处理。将模型限制在已检索的上下文范围内，并仅返回引用信息。当相似度得分低于阈值时，回复应为“该内容不在知识库中”，而非猜测性答案。在金融、运营和医疗领域，含糊的错误回应比直接拒绝造成的损失更大。
租户隔离与数据脱敏。按租户对向量进行过滤，并从提示语中清除敏感信息。不得将卡号、账号及健康数据记录在原始提示日志中；若因调试需要记录这些信息，应先进行分词处理，并按照源系统的数据保留规则来存储。
成本与延迟预算控制。每个令牌都会产生费用，因此需记录输入令牌数、输出令牌数、检索时间以及模型运行时间。为每次调用设定最大令牌数限制，对重复出现的文档缓存其嵌入向量，分类或路由任务可交由小型模型处理，仅在必要时才使用大型模型。

超时与隔离。模型调用属于具有长延迟的远程 I/O 操作。通过限制线程池大小、使用断路器以及提供降级处理路径（如关键词搜索或人工队列），可以防止模型故障占用所有 Tomcat 或 Netty 线程，进而影响整体系统运行。

评估。提示词无法像税务计算那样进行单元测试，但若准备一组包含 30 道已知答案的固定问题集，就能在数值精度出现偏差时及时发现构建错误。对于 RAG 系统，也可通过检查正确的文本片段是否被纳入提示词中来评估得分。许多所谓的模型质量问题实际上都是检索错误导致的。

人工审核。在企业软件中，最有价值的 AI 功能往往仍是草稿功能而非聊天机器人：比如针对某个案例的提示性备注、预填的异常原因，或是长达 40 页的报告摘要。在错误不再频繁出现之前，应保留人工审核环节。

这些都是常见的 Spring 功能：封装远程调用、标记指标、拒绝未经身份验证的请求。大语言模型是一种新的依赖项，且服务级别协议更为严格，因此需要像管理其他依赖项一样来管理它。

“Java 为王”这一说法成立的场景

当核心系统已运行在 JVM 上、当 AI 功能需要与现有 API 共享身份、租户信息和审计数据、当需要调用内部的 Java 服务作为工具、当合规要求不允许使用 Python 并行环境，以及当凌晨 2 点值班的人员已经熟悉 Spring Boot 时，Java 是更好的选择。

而在模型训练或微调、需要在研究库发布后立刻使用它，或者当模型本身就是产品而非更大应用中的某个功能时，Python 仍然更具优势。

那是两件独立的工作，但两年来整个行业却表现得好像它们是一体的。结果就是出现了大量带有 Python sidecar 的架构设计，人们希望其接口规范不会发生变化。对于2026年来说，比较有前景的模式是混合型的：Python或托管的模型实验室负责训练和评估，Java负责服务提供，向量搜索则与运营数据并存，模型由供应商提供，而业务逻辑仍掌握在用户手中。

一个合理的首个项目

不要一上来就开发覆盖全公司的无限制聊天机器人。应选择范围明确、价值较高的内容领域以及能够量化评估的问题。一些可行的方案包括：

为值班工程师准备的操作手册问答系统，链接至相关页面
能够准确引用条款的政策辅助工具
针对用户刚上传的发票或对账单进行的问答系统

票证摘要应记录在案件记录中，而非单独的聊天界面里

将其置于你已有的经过身份验证的API之后，记录每一次数据获取操作，在用户界面中显示引用信息，添加配置开关，并在扩大数据量之前先了解每次请求的成本。第一个项目会教授数据分块、元数据处理、评估方法以及提示词变更控制等技能，这些技能可以迁移使用，但框架品牌则无法移植。

你已信任的运行时环境

“Java是新的AI王者”这一说法适合作为标题，却不足以作为论点。Java并未赢得机器学习领域的优势，它只是将应用型AI引入了原本就承载着全球各类交易系统的平台之中。

Spring Boot工程师在这里工作无需任何人的许可，也不必先拥有数据科学学位。所需的条件只是模型提供方、嵌入模型、向量索引，以及与处理支付和消息传递时相同的运营规范。Python依然是实验室里最受青睐的工具；而在需要将结果落地、工具调用需经授权、每笔账单都需有明确解释的从实验室到实际应用的过渡阶段，Java正逐渐成为主导力量。对大多数团队而言，这才是唯一值得追求的“皇冠”。

如果你的Spring Boot服务已经能够管控身份、资金和审计轨迹，那就没必要再等待额外的辅助工具。本周就选定一个特定的数据集，将ChatClient置于pgvector之前，并要求模型必须提供出处说明。

全部文章发送简报