Java 开发者转 AI 这件事这两年我身边问的人特别多。大家的困惑出奇地一致写 Spring Boot 写得好好的突然发现招聘 JD 里开始要求熟悉大模型应用开发打开技术社区满屏都是 Python 的 LangChain 教程于是产生了一种我是不是要被淘汰了的焦虑。但实际情况是AI 应用开发的下半场恰恰是 Java 的主场——企业级系统里跑的都是 Java而 AI 要真正落地产生业务价值必须嵌入到这些系统里去。这就是 Spring AI 和 LangChain4j 这两个框架存在的意义。我自己是从 Java 后端转过来做 AI 应用开发的踩过的坑不算少。这篇文章不讲虚的就把Java 开发者怎么入门 AI这条路线拆开揉碎讲清楚需要补哪些 AI 基础概念、Spring AI 和 LangChain4j 到底怎么选、RAG 知识库从零怎么搭、本地模型怎么跑、以及那些文档里不会写的实操细节。不管你是刚工作一两年的 Java 开发还是做了七八年的架构师只要想把手里的 Java 技能和 AI 结合起来这篇内容都能给你一条能直接照着走的路径。1. 先搞清楚 Java 开发者做 AI 到底做什么1.1 不是让你去训练大模型很多人一听Java 做 AI第一反应是Java 能训练模型吗答案是不能也没必要。训练大模型是算法团队的事用的是 PyTorch、CUDA 那一套跟 Java 没关系。Java 开发者在 AI 领域的定位是AI 应用工程师核心工作是把已经训练好的大模型能力通过 API 或者本地部署的方式集成到业务系统里解决具体的业务问题。打个比方大模型就像一台发动机算法团队负责造发动机Java 开发者负责把发动机装到汽车上还要配上方向盘、刹车、仪表盘让它能真正上路跑。这个装车的过程涉及的能力包括调用模型接口、管理对话上下文、接入企业知识库、设计 Agent 工作流、做效果评估和监控。这些活儿恰恰是 Java 工程师最擅长的工程化工作。所以心态上先放平你不需要从头学微积分和反向传播需要补的是大模型的能力边界、Prompt 工程、向量检索、RAG 架构这些应用层知识。这些概念理解起来并不难难的是工程落地时的细节。1.2 企业级 AI 应用的四个典型场景从我这几年接触的项目来看Java 开发者做 AI落地场景基本集中在四类第一类是智能问答与知识库。这是最普遍的需求企业内部有大量文档、手册、工单记录员工想查个东西得翻半天。用 RAG检索增强生成把这些文档做成知识库员工用自然语言提问就能拿到答案。这类项目技术栈清晰是入门的最佳练手场景。第二类是业务流程智能化。比如客服系统自动分类工单、合同文档自动提取关键条款、报表数据自动生成分析结论。这类场景往往需要把 AI 能力嵌入到已有的 Spring Boot 服务里通过 API 调用模型对结果做结构化处理。第三类是 Agent 智能体。让模型不只是回答问题还能调用工具、执行多步任务。比如一个帮我查一下上个月的销售数据并生成报告的 Agent它需要理解意图、调用数据库查询工具、调用报表生成工具、最后组织语言输出。这类场景对工程能力要求高也是目前最热的方向。第四类是 NL2SQL 这类结构化转换。用户用自然语言描述查询需求系统自动生成 SQL 去查数据库。Spring AI Alibaba 就提供了这类能力。这个场景对 Java 开发者特别友好因为你对数据库和 SQL 本来就熟。1.3 需要补的 AI 基础概念清单不用学太多但下面这几个概念必须搞明白否则看框架文档会一头雾水Token模型处理文本的基本单位一个中文字大约 1-2 个 token。这直接关系到成本和上下文长度限制必须心里有数。Embedding向量化把文本转成一串数字向量语义相近的文本向量距离也近。这是 RAG 的基石检索就是靠它。向量数据库专门存 Embedding 向量的数据库支持相似度检索。常见的有 Milvus、Qdrant、PgVector、Redis 等。Prompt 与上下文窗口你发给模型的指令叫 Prompt模型能记住的内容长度叫上下文窗口。超出窗口的内容会被截断这是很多 bug 的根源。RAG检索增强生成先从知识库检索相关内容再连同问题一起发给模型让模型基于检索到的内容回答。这是解决模型胡说八道和不知道企业私有知识的核心方案。Function Calling / Tool Calling让模型能够调用你定义好的函数这是 Agent 的基础能力。这些概念花两三天时间看资料就能理解个大概剩下的在动手做项目的过程中自然会加深。别指望先把理论学透了再动手那样效率极低。2. Spring AI 与 LangChain4j 的选型逻辑2.1 两个框架的定位差异Java 生态里做 AI 应用绕不开这两个框架。很多人纠结选哪个其实它们的定位有微妙差别。Spring AI是 Spring 官方团队推出的设计哲学和 Spring 一脉相承约定优于配置、依赖注入、starter 开箱即用。如果你本来就是 Spring Boot 开发者上手 Spring AI 几乎没有学习成本加个依赖、配个 API Key、注入一个 ChatClient 就能用。它的优势在于和 Spring 生态的无缝集成——事务、缓存、监控、安全这些你熟悉的东西都能直接用上。LangChain4j是社区驱动的项目灵感来自 Python 的 LangChain功能覆盖面更广尤其在 Agent、RAG 的高级用法、多模型编排方面更灵活。它的 API 设计更贴近链式调用的思路适合做复杂的 AI 工作流。我个人的判断是做企业级业务集成优先 Spring AI做复杂的 AI 原生应用和 AgentLangChain4j 更顺手。但这不是非此即彼的选择两个框架可以共存甚至可以在一个项目里各取所长。2.2 选型对比表维度Spring AILangChain4j维护方Spring 官方社区驱动上手难度低Spring 开发者零成本中等需理解链式概念生态集成与 Spring Boot 无缝需手动集成RAG 支持完善有 Easy RAG非常完善灵活度高Agent 支持逐步完善中成熟工具调用灵活多模型支持OpenAI、Ollama、通义等覆盖更广文档质量官方文档规范文档较全但更新快适合场景业务系统 AI 集成AI 原生应用、复杂工作流2.3 我的实际选型经验说个真实案例。之前做一个企业内部知识库问答系统一开始用 LangChain4j因为它的 RAG 组件确实丰富。但后来发现这个系统需要和现有的权限体系、审计日志、缓存机制深度集成用 LangChain4j 就得自己写一堆胶水代码。后来换成 Spring AI直接复用现有的 Spring Security 和 Redis 缓存代码量少了一大半。反过来另一个做多步骤 Agent 的项目需要模型自主决定调用哪个工具、按什么顺序调用LangChain4j 的 Agent 抽象明显更成熟Spring AI 在这块当时还不够灵活。所以选型的核心不是哪个更好而是你的场景更需要什么。如果拿不准我的建议是先用 Spring AI 把 RAG 跑通建立信心遇到 Spring AI 搞不定的复杂编排再引入 LangChain4j。两个框架的底层都是调用模型 API概念是相通的切换成本不高。提示不要一开始就纠结选型选一个先动手做起来。框架只是工具真正决定项目成败的是你对业务场景的理解和工程细节的把控。3. 从零搭建第一个 RAG 知识库3.1 RAG 到底解决了什么问题先说清楚 RAG 为什么重要。大模型有两个硬伤一是知识有截止日期训练完之后的新知识它不知道二是它不知道你的私有数据比如公司内部文档。你直接问它我们公司的报销标准是多少它要么说不知道要么一本正经地胡说八道。RAG 的思路很朴素既然模型不知道那我就在提问的时候把相关资料一起塞给它。具体流程是用户提问 → 把问题向量化 → 去向量数据库里找最相似的文档片段 → 把这些片段和问题拼成一个 Prompt → 发给模型 → 模型基于这些片段回答。这个流程听起来简单但每个环节都有坑。检索不准、片段切得不好、Prompt 组织不当都会导致最终答案质量差。下面我按实操顺序拆解。3.2 文档处理与切分的关键细节RAG 的第一步是把文档变成可以检索的片段。这里最容易踩的坑是切分策略。很多人上来就用固定长度切分比如每 500 字切一段。这在处理结构化的技术文档时问题很大——一个完整的操作步骤可能被从中间切断检索出来的片段前言不搭后语。我的经验是优先按语义结构切分其次才考虑固定长度。比如 Markdown 文档按标题层级切PDF 按段落切代码文档按函数切。LangChain4j 提供了DocumentSplitter的多种实现Spring AI 也有TokenTextSplitter都支持配置重叠长度overlap让相邻片段有部分内容重叠避免信息断裂。具体参数上我一般这样设片段长度300-800 token根据文档类型调整。技术文档可以短一些叙述性文档可以长一些。重叠长度片段长度的 10%-20%保证上下文连贯。保留元数据文档来源、章节标题、页码这些信息一定要带上检索时可以用来过滤回答时可以用来标注出处。还有一个细节文档预处理比切分更重要。PDF 里的表格、页眉页脚、乱码如果不清理干净会严重污染检索结果。我一般会先用工具把 PDF 转成 Markdown人工检查一遍再入库。这一步偷懒后面检索效果差排查起来非常痛苦。3.3 向量化与存储的实操配置向量化就是把文本片段转成向量。这里的选择是用哪个 Embedding 模型。如果追求效果用 OpenAI 的 text-embedding-3 或者国内的通义、智谱的 Embedding 服务效果好但要走网络、有成本。如果追求本地化和低成本用 Ollama 跑本地的 Embedding 模型比如nomic-embed-text或bge-m3效果也够用。向量数据库的选择上入门阶段我强烈建议用PgVector因为如果你已经用了 PostgreSQL加个扩展就能用不用额外部署。规模大了再考虑 Milvus 或 Qdrant。Spring AI 的配置大概长这样spring: ai: ollama: base-url: http://localhost:11434 embedding: options: model: nomic-embed-text vectorstore: pgvector: index-type: HNSW distance-type: COSINE_DISTANCE dimensions: 768这里有个坑要注意Embedding 模型的维度必须和向量库配置的维度一致。nomic-embed-text是 768 维text-embedding-3-small是 1536 维配错了会直接报错。换模型的时候一定要同步改维度配置并且重新灌数据。3.4 检索策略与效果调优检索是 RAG 效果的分水岭。基础的向量相似度检索Top-K在很多场景下不够用我一般会叠加几种策略混合检索向量检索擅长语义匹配但对精确的关键词、专有名词不敏感。把向量检索和关键词检索BM25结合起来效果提升明显。LangChain4j 有现成的混合检索组件。重排序Rerank先检索出 Top-20 个候选片段再用一个重排序模型精排出 Top-3。这一步能显著提升相关性代价是多一次模型调用。常用的重排序模型有 bge-reranker 系列。元数据过滤如果知识库有分类、时间、权限等维度检索时先按元数据过滤再在子集里做向量检索能大幅提升准确率。关于检索效果评估有个指标叫Hit Rate命中率就是正确答案是否出现在检索结果里。我一般会准备一批测试问题人工标注正确答案所在的文档然后跑一遍看命中率。命中率低于 80% 就要回头优化切分和检索策略了。注意RAG 效果不好90% 的问题出在检索环节而不是模型环节。很多人一上来就换更大的模型其实应该先检查检索出来的片段是不是真的相关。4. 本地模型环境搭建与工具链4.1 为什么建议先跑本地模型入门阶段我强烈建议先用本地模型原因有三一是不花钱随便折腾二是不依赖网络调试方便三是数据不出本地做企业项目时这点很重要。本地跑模型最省事的工具是Ollama。装好之后一行命令就能拉模型ollama pull qwen2.5:7b ollama pull nomic-embed-textqwen2.5:7b做对话nomic-embed-text做向量化这两个组合足够跑通一个完整的 RAG 系统。7B 的模型对显存要求不高8G 显存的显卡就能跑没有独显用 CPU 也能跑就是慢一点。4.2 Java 侧的工具链清单把本地模型跑起来之后Java 侧需要准备的东西JDK 17 或 21Spring AI 和 LangChain4j 都要求 JDK 17建议直接用 21。Spring Boot 3.xSpring AI 依赖 Spring Boot 3。构建工具Maven 或 Gradle 都行我用 Maven 多一些。向量数据库入门用 PgVectorDocker 一条命令就能起。PostgreSQL pgvector 扩展如果本地没有用 Docker 起一个最方便。docker run -d --name pgvector \ -e POSTGRES_PASSWORDpostgres \ -p 5432:5432 \ pgvector/pgvector:pg164.3 一个最小可运行的 RAG 示例把依赖配好之后一个最小的 RAG 流程大概是这样Service public class RagService { private final ChatClient chatClient; private final VectorStore vectorStore; public RagService(ChatClient.Builder builder, VectorStore vectorStore) { this.chatClient builder.build(); this.vectorStore vectorStore; } public String ask(String question) { // 检索相关文档 ListDocument docs vectorStore.similaritySearch( SearchRequest.builder() .query(question) .topK(5) .build() ); // 拼接上下文 String context docs.stream() .map(Document::getText) .collect(Collectors.joining(\n\n)); // 构造 Prompt 并调用模型 return chatClient.prompt() .system(你是一个知识库助手请基于以下资料回答问题如果资料中没有相关信息请如实说明。) .user(u - u.text(资料\n{context}\n\n问题{question}) .param(context, context) .param(question, question)) .call() .content(); } }这段代码虽然简单但已经包含了 RAG 的核心逻辑。跑通它你就理解了 RAG 的骨架。剩下的优化都是在这个骨架上做加法。4.4 灌数据与增量更新知识库不是灌一次就完事的文档会更新新文档会加入。这里要设计好增量更新机制。我的做法是给每个文档算一个内容哈希入库时记录哈希值。更新时对比哈希变了才重新切分和向量化没变就跳过。这样能避免全量重灌节省时间和成本。另外删除文档时要同步删除对应的向量数据否则会出现文档已经删了但还能检索到的诡异问题。Spring AI 的 VectorStore 提供了delete方法按文档 ID 或元数据过滤删除。5. 那些文档里不会写的踩坑经验5.1 上下文窗口超限的隐蔽问题这是新手最容易踩的坑。你把检索到的 5 个片段拼起来加上系统提示和历史对话很容易就超过模型的上下文窗口。超了之后有的模型直接报错有的模型默默截断前面的内容导致回答质量莫名其妙地下降。我的处理方式是在拼接 Prompt 之前先估算 token 数。可以用简单的字符数除以 1.5 来粗略估算中文 token 数或者用框架提供的 tokenizer 精确计算。如果超了就减少检索片段数量或者对片段做摘要压缩。还有一个技巧把最重要的内容放在 Prompt 的开头和结尾。有研究表明模型对上下文中间部分的内容注意力会下降这就是所谓的迷失在中间现象。所以检索结果要按相关性排序最相关的放前面。5.2 模型不听话的应对有时候你明明在 Prompt 里写了只基于资料回答模型还是忍不住自己发挥。这种情况有几个应对办法一是强化指令把约束条件写得更明确比如如果资料中没有答案必须回答根据现有资料无法回答禁止编造。二是降低温度参数。温度temperature控制输出的随机性做知识库问答时设成 0 或 0.1让模型更保守。三是结构化输出。让模型按 JSON 格式返回包含answer和source字段这样既方便程序处理也能通过要求填写 source 来约束模型基于资料回答。5.3 流式输出的实现细节做聊天类应用流式输出打字机效果几乎是标配。Spring AI 和 LangChain4j 都支持流式返回但有几个细节要注意。Spring AI 的流式返回用FluxString配合 Spring WebFlux 的 SSE 推送给前端。要注意的是流式返回时如果中途出错错误处理要单独做否则前端会一直转圈。还有一个坑流式输出和 Function Calling 一起用的时候有些模型不支持流式返回工具调用结果需要特殊处理。这个在文档里往往一笔带过实际调试起来很费时间。5.4 成本控制的实战技巧如果用云端模型 API成本是要认真考虑的。几个实用的省钱技巧缓存高频问题把常见问题和答案缓存起来命中缓存直接返回不调模型。用 Redis 做这个很合适。小模型打头阵简单问题用小模型便宜复杂问题才路由到大模型。可以先用小模型判断问题复杂度。精简 Prompt系统提示能短则短检索片段能少则少在保证效果的前提下压缩 token。批量处理如果有大量文档要向量化用批量接口比一条条调便宜也快。5.5 效果评估不能省最后说一个容易被忽略但极其重要的环节效果评估。很多人做完 RAG 系统自己试几个问题觉得还行就上线了结果用户一用全是问题。我的做法是建一个测试集包含 50-100 个真实问题每个问题标注期望答案和来源文档。每次调整检索策略或换模型都跑一遍测试集看命中率和答案准确率的变化。这个测试集是持续迭代的基础没有它优化就是盲人摸象。评估指标上除了前面说的 Hit Rate还可以看答案忠实度答案是否基于检索到的资料和答案相关性答案是否切题。这些可以用模型来辅助评估也可以用人工抽检。6. 进阶方向与学习路径建议6.1 从 RAG 到 Agent 的演进RAG 跑通之后下一步自然是 Agent。Agent 的核心是让模型能够自主决策什么时候该检索知识库什么时候该调用外部工具什么时候该追问用户。LangChain4j 的 Agent 抽象比较成熟通过定义Tool接口模型就能自主调用。比如定义一个查询订单的工具、一个发送邮件的工具模型会根据用户意图决定调用哪个。Agent 的难点不在技术而在可靠性。模型可能会调用错误的工具、传错误的参数、陷入循环。所以生产环境的 Agent 一定要有兜底机制限制最大调用轮数、对工具调用做参数校验、关键操作要人工确认。6.2 GraphRAG 与本体 RAG 的适用场景普通 RAG 处理的是扁平的文档片段对于需要跨文档推理的问题比如这几个项目之间有什么关联效果有限。GraphRAG 的思路是把文档中的实体和关系抽出来构建知识图谱检索时沿着图谱找关联信息。GraphRAG 效果确实好但构建成本高需要额外的实体抽取和关系建模步骤。我的建议是普通问答场景用普通 RAG 就够了只有确实需要跨文档推理的场景才上 GraphRAG。不要为了技术而技术。6.3 给不同阶段开发者的建议如果你是刚入门的 Java 开发先把 Spring Boot 和数据库基础打牢然后按这篇文章的路径用 Spring AI Ollama PgVector 跑通一个 RAG 小项目。不要贪多一个项目吃透比十个项目浅尝辄止强。如果你是有几年经验的开发者可以深入研究检索优化、Agent 编排、效果评估这些进阶话题同时关注 Spring AI Alibaba 这类国内生态的进展它们在 NL2SQL、企业集成方面有独特优势。如果你是架构师重点应该放在技术选型的权衡、系统的可扩展性和可维护性、以及 AI 能力如何与现有系统架构融合上。技术细节可以交给团队但架构决策的后果你要负责。6.4 持续学习的资源方向AI 这个领域变化太快框架版本几个月就更新一次。我的学习习惯是关注 Spring AI 和 LangChain4j 的官方文档和 GitHub Release看它们的更新日志加入几个技术社区看别人踩的坑最重要的是保持动手每学一个新概念就写个 demo 验证。不要被AI 焦虑裹挟着去学一堆用不上的东西。Java 开发者的核心竞争力永远是工程能力——把复杂问题拆解清楚、把系统设计得健壮、把代码写得可维护。AI 只是给你多了一个解决问题的工具把这个工具用好比追着所有新概念跑要实在得多。我在实际项目里最大的体会是AI 应用开发 80% 的工作量在工程细节上模型调用本身反而是最简单的一环。文档切分、检索调优、错误处理、效果评估、成本控制这些才是真正拉开差距的地方。而这些恰恰是 Java 开发者多年积累的强项。所以别慌你的底子比你想的要厚。