1. Java 开发者切入 AI 的真实路径与选型逻辑Java 开发者聊 AI最常听到的一句话就是“你们 Java 做 AI 是不是不太行”。这话放在三年前可能还有点道理但放到现在说这话的人大概率没认真看过 Spring AI 和 LangChain4j 这两个库的迭代速度。我身边不少写了七八年 Spring Boot 的老哥从去年开始陆续往 AI 方向转踩了不少坑也总结出了一些真正能落地的路线。这篇内容就是把这些经验整理出来给还在观望或者刚起步的 Java 开发者一个清晰的参照。先说清楚这篇东西适合谁看。如果你是一个有 Java 基础、熟悉 Spring Boot、想往 AI 应用开发方向走的开发者那这篇内容就是给你写的。如果你已经能熟练用 Python 写 LangChain 应用只是想看看 Java 生态有什么替代品那也有参考价值。但如果你连 Spring Boot 的依赖注入都没搞明白建议先把 Java 基础打牢再来看 AI 集成这块不然会非常痛苦。核心问题其实就一个Java 开发者做 AI到底走哪条路我的答案是不要试图去训练模型也不要去跟 Python 生态拼算法研究而是聚焦在AI 应用层开发这个定位上。具体来说就是用 Java 把大模型能力集成到现有的业务系统里做 RAG 知识库、做智能客服、做文档处理、做 Agent 工作流。这个定位决定了你的工具链选型、学习路径和最终能交付的东西。为什么这么定位因为 Java 的主战场从来都是企业级应用而企业级应用恰恰是 AI 落地最需要的地方。你想想一个已经跑了五年的订单系统不可能因为要加个 AI 问答就把整个技术栈换成 Python。这时候 Java 开发者的优势就出来了——你懂业务系统你懂 Spring 生态你懂怎么把新能力无缝嵌进现有架构。这才是 Java 开发者做 AI 的真正切入点。1.1 为什么不是 Python 而是 Java 生态很多人一上来就问学 AI 是不是必须学 Python。我的回答是看你做什么。如果你要做模型微调、要做算法研究、要发论文那 Python 确实是首选。但如果你要做的是把 AI 能力集成到企业系统里Java 生态现在的成熟度已经足够用了。Spring AI 从 2023 年底开始发力到现在的版本已经支持了主流的模型接入、向量数据库、RAG 流程编排、工具调用等核心能力。LangChain4j 更是在 RAG 和 Agent 方向做了大量工作API 设计对 Java 开发者非常友好。这两个库的存在让 Java 开发者不需要切换语言就能完成大部分 AI 应用开发工作。更重要的是Java 的类型系统和工程化能力在构建复杂 AI 应用时反而是优势。Python 写原型快但维护一个大型 AI 应用时类型混乱、依赖冲突、部署复杂这些问题会让人非常头疼。Java 的强类型、成熟的构建工具链、完善的测试框架在长期维护上优势明显。1.2 三条可选路线与适用场景根据我这段时间的观察和实践Java 开发者切入 AI 大概有三条路线路线一Spring AI 路线。适合已经在用 Spring Boot 的团队想快速把 AI 能力集成到现有项目里。Spring AI 的抽象层设计跟 Spring 生态一脉相承学习成本低上手快。缺点是某些高级功能可能不如 LangChain4j 灵活。路线二LangChain4j 路线。适合想深入做 RAG、Agent 的开发者。LangChain4j 的 API 设计更贴近 AI 应用的实际需求在链式调用、记忆管理、工具集成方面做得更细致。缺点是生态相对 Spring AI 小一些社区资源没那么丰富。路线三混合路线。用 Spring Boot 做业务框架用 LangChain4j 做 AI 核心逻辑两者通过接口层解耦。这是我在实际项目中用得最多的方式兼顾了工程化和灵活性。选哪条路线取决于你的具体场景。如果只是做个简单的问答接口Spring AI 足够了。如果要做一个完整的 RAG 知识库系统LangChain4j 可能更合适。如果是在现有大型项目里加 AI 功能混合路线最稳妥。2. 核心工具链拆解与选型对比工具链选型是 Java 开发者入门 AI 时最容易纠结的地方。我见过太多人在选型上花了两周时间结果代码一行没写。这一章把核心工具链拆开讲清楚每个工具解决什么问题、什么场景下选它、有什么坑都说明白。2.1 Spring AI 与 LangChain4j 的定位差异这两个库经常被拿来比较但其实它们的定位有本质区别。Spring AI 的核心思路是“把 AI 能力抽象成 Spring 生态里的标准组件”。它提供了 ChatClient、EmbeddingClient、VectorStore 这些抽象接口让你可以像使用 JdbcTemplate 一样使用 AI 能力。它的优势在于与 Spring Boot 的无缝集成配置方式、依赖注入、自动装配这些机制都跟 Spring 生态一致。LangChain4j 的核心思路是“为 Java 开发者提供一套完整的 AI 应用开发框架”。它不仅有模型接入层还有 Chain、Memory、Retriever、Tool 这些更高层的抽象。它的 API 设计更贴近 AI 应用的实际开发需求比如你想做一个带记忆的对话系统LangChain4j 有现成的 ChatMemory 接口可以用。我的建议是如果你只是想在现有 Spring Boot 项目里加一个 AI 问答接口用 Spring AI。如果你要从零构建一个 AI 应用或者需要复杂的 RAG、Agent 逻辑用 LangChain4j。如果两者都需要那就混合用Spring AI 做基础接入LangChain4j 做上层编排。2.2 RAG 技术栈的完整组成RAG 是 Java 开发者做 AI 最常落地的场景也是面试里被问得最多的。一个完整的 RAG 系统包含以下几个核心组件组件作用常用选型注意事项文档加载器读取各种格式的文档LangChain4j DocumentLoader、Apache Tika注意编码格式和分页处理文本分割器把长文档切成小块LangChain4j DocumentSplitter分割策略直接影响检索效果嵌入模型把文本转成向量OpenAI Embedding、Ollama 本地模型维度要和向量库匹配向量数据库存储和检索向量PGVector、Milvus、Redis注意索引类型和距离度量检索器根据问题找相关文档LangChain4j EmbeddingStoreRetriever需要调 topK 和阈值生成模型根据上下文生成回答GPT-4、Claude、本地模型注意上下文长度限制这套技术栈里最容易出问题的是文本分割和检索策略。很多人以为 RAG 就是“把文档塞进去然后问问题”实际上分割粒度、重叠长度、检索数量这些参数对最终效果影响巨大。我后面会专门讲这块的调优经验。2.3 本地模型与云端模型的取舍Java 开发者做 AI绕不开的一个问题是用云端 API 还是本地部署模型。云端 API 的优势是效果好、免维护、按量付费。缺点是数据要出本地有隐私顾虑而且长期使用成本不低。本地部署的优势是数据不出本地、无调用限制、长期成本低。缺点是需要 GPU 资源模型效果通常不如云端大模型。我的实际经验是开发阶段用云端 API 快速验证生产环境根据数据敏感度决定。如果数据不敏感云端 API 更省心。如果数据敏感或者调用量大本地部署更划算。Ollama 是目前本地部署最方便的方案一条命令就能跑起来Java 通过 HTTP 接口调用也很简单。注意本地部署模型时一定要确认机器的内存和显存是否足够。7B 参数的模型至少需要 8GB 显存13B 需要 16GB70B 需要 40GB 以上。如果显存不够推理速度会慢到无法接受。3. 从零搭建一个 RAG 知识库的完整实操这一章是重头戏。我会用一个完整的例子演示怎么用 Java 搭建一个 RAG 知识库系统。这个例子基于 LangChain4j 和 Ollama全部本地运行不需要任何云端 API Key零基础也能跟着做。3.1 环境准备与依赖配置首先确认你的开发环境JDK 17 或以上Spring AI 和 LangChain4j 都要求 JDK 17Maven 3.8 或 Gradle 7Ollama 已安装并运行用于本地模型推理一个向量数据库这里用 PGVectorPostgreSQL 的向量扩展Ollama 的安装很简单去官网下载对应系统的安装包安装完成后运行ollama pull qwen2:7b拉取模型。PGVector 可以用 Docker 快速启动docker run -d --name pgvector \ -e POSTGRES_PASSWORDpostgres \ -e POSTGRES_DBragdb \ -p 5432:5432 \ pgvector/pgvector:pg16然后在 Maven 的pom.xml里加入 LangChain4j 的依赖dependency groupIddev.langchain4j/groupId artifactIdlangchain4j/artifactId version0.35.0/version /dependency dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-ollama/artifactId version0.35.0/version /dependency dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-pgvector/artifactId version0.35.0/version /dependency版本号建议去 Maven Central 查最新的LangChain4j 迭代很快新版本通常会修复不少问题。3.2 文档加载与文本分割的关键参数文档加载这块LangChain4j 提供了FileSystemDocumentLoader和ApacheTikaDocumentLoader。前者适合纯文本和 Markdown后者支持 PDF、Word、Excel 等格式。我一般用 Tika因为企业文档格式太杂了。DocumentLoader loader new ApacheTikaDocumentLoader(); ListDocument documents loader.loadDocument(/path/to/your/docs);文本分割是 RAG 效果的关键。LangChain4j 提供了DocumentSplitters.recursive()方法支持按段落、句子、字符递归分割。核心参数有三个chunkSize每个文本块的最大字符数默认 300。这个值太小会导致上下文不完整太大会导致检索精度下降。我的经验是中文文档用 500-800 比较合适。chunkOverlap相邻块之间的重叠字符数默认 0。设置 50-100 可以避免关键信息被切断。separators分割符优先级默认是\n\n、\n、。、 。中文场景建议加上。、、。DocumentSplitter splitter DocumentSplitters.recursive(600, 80); ListTextSegment segments splitter.splitAll(documents);实操心得分割参数没有万能值一定要根据你的文档类型调。技术文档段落长chunkSize 可以大一些FAQ 类文档段落短chunkSize 要小一些。调完之后一定要实际测几个问题看检索出来的内容是否完整。3.3 向量化与检索的完整代码实现接下来是向量化和存储。这里用 Ollama 的嵌入模型PGVector 做向量存储。EmbeddingModel embeddingModel OllamaEmbeddingModel.builder() .baseUrl(http://localhost:11434) .modelName(nomic-embed-text) .build(); EmbeddingStoreTextSegment embeddingStore PgVectorEmbeddingStore.builder() .host(localhost) .port(5432) .database(ragdb) .user(postgres) .password(postgres) .table(embeddings) .dimension(768) .build(); EmbeddingStoreIngestor ingestor EmbeddingStoreIngestor.builder() .documentSplitter(DocumentSplitters.recursive(600, 80)) .embeddingModel(embeddingModel) .embeddingStore(embeddingStore) .build(); ingestor.ingest(documents);注意dimension参数必须和嵌入模型的输出维度一致。nomic-embed-text的输出是 768 维所以这里填 768。如果换了模型这个值要跟着改否则会报错。检索部分LangChain4j 提供了EmbeddingStoreRetrieverRetrieverTextSegment retriever EmbeddingStoreRetriever.from( embeddingStore, embeddingModel, 5, 0.7 );这里的5是返回的最大结果数0.7是最小相似度阈值。这两个参数直接影响检索质量。topK 太小可能漏掉相关内容太大会引入噪声。阈值太低会返回不相关的内容太高可能什么都检索不到。3.4 对话链的组装与流式输出最后把检索器和对话模型组装成完整的 RAG 链ChatLanguageModel chatModel OllamaChatModel.builder() .baseUrl(http://localhost:11434) .modelName(qwen2:7b) .build(); RetrievalAugmentor augmentor DefaultRetrievalAugmentor.builder() .contentRetriever(retriever) .build(); Assistant assistant AiServices.builder(Assistant.class) .chatLanguageModel(chatModel) .retrievalAugmentor(augmentor) .build(); String answer assistant.chat(你的问题);Assistant是一个接口你可以用SystemMessage注解定义系统提示词interface Assistant { SystemMessage(你是一个知识库助手根据提供的上下文回答问题。如果上下文中没有相关信息请如实告知。) String chat(String userMessage); }流式输出用TokenStreamTokenStream stream assistant.chatStream(你的问题); stream.onNext(token - System.out.print(token)) .onComplete(response - System.out.println(\n完成)) .start();这套代码跑通之后你就有了一个完整的本地 RAG 知识库。接下来就是调优和扩展。4. 实际开发中的高频问题与排查手册这一章整理的是我在实际项目中踩过的坑和常见问题的排查思路。这些问题在官方文档里通常不会写但实际开发中几乎一定会遇到。4.1 检索效果差的排查思路检索效果差是 RAG 系统最常见的问题。表现是明明知识库里有答案但模型就是答不出来或者答非所问。排查顺序是这样的第一步检查分割是否合理。把分割后的文本块打印出来看如果发现关键信息被切断了就调整 chunkSize 和 chunkOverlap。如果发现块太大导致检索不精准就调小 chunkSize。第二步检查嵌入模型是否合适。中文场景建议用专门的中文嵌入模型比如bge-large-zh或者nomic-embed-text。用英文模型处理中文效果会打折扣。第三步检查检索参数。把 topK 调大试试看是否能检索到相关内容。如果 topK 调大后能检索到说明是 topK 太小的问题。如果调大后还是检索不到说明是嵌入或分割的问题。第四步检查相似度阈值。如果阈值设得太高可能过滤掉了本来相关的内容。可以先把阈值设成 0看检索结果再逐步调高。问题表现可能原因排查方法解决方案检索不到相关内容分割粒度太大打印文本块检查调小 chunkSize检索到无关内容阈值太低查看相似度分数调高阈值答案不完整上下文被切断检查重叠长度增大 chunkOverlap中文效果差嵌入模型不匹配换中文模型测试用中文嵌入模型响应太慢向量库索引未建检查索引配置建 HNSW 索引4.2 模型调用超时与重试策略本地模型推理速度受硬件影响很大。7B 模型在消费级显卡上大概每秒 20-40 个 token如果上下文很长响应时间可能超过 30 秒。这时候需要配置合理的超时和重试。LangChain4j 的 Ollama 客户端默认超时是 60 秒可以通过 builder 调整OllamaChatModel model OllamaChatModel.builder() .baseUrl(http://localhost:11434) .modelName(qwen2:7b) .timeout(Duration.ofSeconds(120)) .maxRetries(3) .build();注意重试次数不要设太多否则一次请求失败会阻塞很久。建议配合熔断机制使用连续失败达到阈值就快速返回错误。4.3 内存溢出与性能调优Java 做 AI 应用内存管理是个容易被忽视的问题。向量数据、文档内容、对话历史都会占用内存。如果 JVM 堆设得太小很容易 OOM。我的经验配置是开发环境-Xms2g -Xmx4g生产环境-Xms4g -Xmx8g根据并发量调整向量检索场景额外预留 2-4GB 给向量计算另外对话历史一定要做限制。LangChain4j 的MessageWindowChatMemory可以限制保留的消息数量ChatMemory memory MessageWindowChatMemory.withMaxMessages(20);如果不限制对话越长内存占用越大最终必然 OOM。4.4 常见问题速查表问题排查方向快速解决启动报错找不到模型Ollama 是否运行ollama list确认模型存在向量维度不匹配嵌入模型和向量库配置检查 dimension 参数检索结果为空阈值和 topK先设阈值为 0 测试响应乱码编码格式统一用 UTF-8连接超时网络或模型加载中增加超时时间内存持续增长对话历史未限制配置 ChatMemory 上限检索速度慢向量索引未建建 HNSW 或 IVFFlat 索引5. 进阶方向与持续学习建议基础 RAG 跑通之后下一步往哪走根据我这段时间的观察有几个方向值得深入。5.1 Agentic RAG 与工作流编排普通 RAG 是“检索一次生成一次”Agentic RAG 是“让模型自己决定什么时候检索、检索什么、检索几次”。这个方向目前很热LangChain4j 也提供了工具调用的支持。核心思路是把检索器封装成一个 Tool让模型自己决定是否调用。这样模型可以先判断问题是否需要查知识库需要的话再调用检索工具甚至可以多轮检索。interface Assistant { SystemMessage(你可以使用知识库检索工具来回答问题。) String chat(String message); } Assistant assistant AiServices.builder(Assistant.class) .chatLanguageModel(chatModel) .tools(new KnowledgeBaseTool(retriever)) .build();这个方向的门槛在于工具描述的设计和调用流程的控制。工具描述写得好模型调用就准确写得模糊模型就会乱调。5.2 多模态与文档理解企业文档不只有文本还有表格、图片、扫描件。多模态 RAG 是下一个要解决的问题。目前的思路是用 OCR 把图片转文本用表格解析库把表格转结构化数据然后再走 RAG 流程。Java 生态里Apache Tika 可以处理大部分格式但表格和图片的处理还需要额外工具。这块目前没有特别成熟的 Java 方案通常需要结合 Python 服务来做。5.3 学习资源与社区Java AI 生态还在快速迭代保持学习的最好方式是跟社区保持同步。Spring AI 和 LangChain4j 的 GitHub 仓库值得关注Release Notes 里通常会有新功能和 Breaking Changes 的说明。另外实际动手做项目比看文档有效得多。我的建议是先跑通一个最小可用的 RAG 系统然后逐步加功能——加记忆、加工具调用、加多轮对话、加流式输出。每加一个功能你对整个体系的理解就会深一层。最后分享一个我自己的习惯每次遇到问题先把排查过程记下来包括现象、排查步骤、最终原因和解决方案。积累一段时间后这就是你自己的知识库比任何文档都有用。
