1. Java 开发者切入 AI 的真实动机与路径选择1.1 为什么 Java 开发者需要关注 AI 而不是转语言这两年我身边不少 Java 老哥都在焦虑一件事AI 火了Python 成了“AI 第一语言”自己写了七八年的 Spring Boot、MyBatis、Dubbo难道要推倒重来我的判断很明确——不需要转语言但需要转思维。Java 在企业级后端、高并发、分布式事务、微服务治理上的积累恰恰是 AI 应用落地阶段最缺的能力。模型训练确实以 Python 为主但模型服务化、推理接口封装、RAG 检索链路、Agent 编排、向量库对接、权限与计费这些工程化环节Java 的生态成熟度并不差。我实测下来一个熟练的 Java 后端用两周业余时间就能跑通“调用大模型 API 本地向量检索 简单 Agent 工具调用”的完整闭环。难点不在语言而在于你要理解 AI 应用的数据流和不确定性处理——传统后端是确定性逻辑AI 应用是概率性输出这个思维切换才是真正的门槛。1.2 三条典型路线API 调用派、框架集成派、自建推理派我把 Java 开发者入门 AI 的路线粗分成三条你可以对号入座路线适合人群核心技术栈上手周期落地场景API 调用派业务后端、想快速出活HTTP Client、Spring AI、LangChain4j3~7 天智能客服、文档问答、内容生成框架集成派架构师、中间件方向Spring AI、LangChain4j、向量库 SDK2~4 周RAG 知识库、Agent 工作流自建推理派算法工程、追求可控DJL、ONNX Runtime、TensorFlow Java1~3 个月私有化部署、边缘推理我个人的建议是先走 API 调用派再过渡到框架集成派。原因很简单自建推理对 Java 开发者性价比太低除非你有明确的私有化合规需求否则没必要一上来就啃模型权重和 CUDA。先把“怎么把大模型能力接进现有 Java 系统”这件事跑通比什么都重要。1.3 路线图总览从环境到上线的五个阶段我把完整路线拆成五个阶段每个阶段都有明确的交付物避免你学着学着就迷失环境准备阶段JDK 17、Maven/Gradle、IDE、API Key 管理、HTTP 调试工具基础调用阶段同步/流式调用、Prompt 模板、Token 计费、异常重试工程集成阶段Spring AI 或 LangChain4j 接入、向量库对接、RAG 链路Agent 编排阶段工具调用、多轮记忆、任务分解、结果校验上线运维阶段限流降级、缓存、可观测性、成本控制、安全过滤这五个阶段不是线性的实际做项目时经常来回跳。但作为学习路径按这个顺序走不会乱。2. 工具链选型Java 生态里哪些东西真能用2.1 核心框架对比Spring AI vs LangChain4j这是 Java 开发者问得最多的问题。我两个都用过说下真实感受Spring AI的优势在于和 Spring 生态无缝集成如果你现有项目就是 Spring Boot引入spring-ai-openai-spring-boot-starter之后配置几个application.yml就能跑。它的抽象层设计比较克制ChatClient、EmbeddingClient、VectorStore 这几个接口覆盖了 80% 的场景。缺点是版本迭代快API 偶尔有破坏性变更生产环境要锁版本。LangChain4j更偏向“AI 原生”链式调用、Agent、Tool 抽象做得更细适合复杂编排场景。它的AiServices可以把接口直接映射成 AI 调用写起来很舒服。缺点是学习曲线略陡概念比 Spring AI 多。我的选型建议业务系统集成选 Spring AI独立 AI 应用选 LangChain4j。如果团队 Java 水平参差Spring AI 的认知负担更低。2.2 向量库与嵌入模型RAG 的地基怎么打RAG检索增强生成是 Java 开发者最容易落地的 AI 场景核心就两件事把文档变成向量存起来查询时找最相似的。向量库选型我踩过坑列个表向量库部署方式Java 客户端适用规模备注Redis Stack内存Jedis/Lettuce百万级已有 Redis 直接用最省事Milvus独立服务官方 SDK亿级功能全运维成本高PGVectorPostgreSQL 插件JDBC千万级已有 PG 首选Elasticsearch独立服务官方 Client亿级全文向量混合检索强Chroma轻量嵌入HTTP十万级原型阶段方便嵌入模型方面Java 开发者不用自己训直接调 API 或本地跑 ONNX 模型。我实测text-embedding-3-small这类 API 模型性价比最高本地模型推荐bge-small-zh的 ONNX 版本用 DJL 加载CPU 也能跑。2.3 开发辅助工具让 AI 帮你写 Java这里说个反直觉的点AI 编程助手对 Java 开发者的提效比对 Python 更明显。因为 Java 样板代码多getter/setter、DTO 转换、异常处理这些 AI 生成准确率很高。我常用的组合IDE 插件通义灵码、GitHub Copilot写 CRUD 和单元测试极快Prompt 管理把常用 Prompt 存成模板比如“生成带参数校验的 Controller”API 调试Apifox 或 Postman调大模型接口时看流式返回很方便本地模型Ollama 跑个 7B 模型断网也能用适合敏感代码场景注意AI 生成的 Java 代码一定要过 SonarQube 或 SpotBugs我遇到过生成的代码有资源未关闭、空指针隐患的情况别直接上生产。2.4 环境与依赖管理别在配置上浪费时间Java 开发者入门 AI 最容易卡在环境上。我的建议是JDK 版本17 或 21Spring AI 要求 17构建工具Maven 足够Gradle 也行别纠结API Key 管理用环境变量或配置中心千万别硬编码网络调外部 API 要配超时和重试OkHttp或WebClient都行日志请求和响应要脱敏后记录方便排查# application.yml 示例 spring: ai: openai: api-key: ${AI_API_KEY} chat: options: model: gpt-4o-mini temperature: 0.7 embedding: options: model: text-embedding-3-small3. 从零到一一个 Java AI 问答服务的完整实操3.1 项目初始化与依赖引入我拿一个真实做过的“内部文档问答服务”举例完整走一遍。项目用 Spring Boot 3.2 Spring AI 1.0 PGVector。pom.xml核心依赖dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-openai-spring-boot-starter/artifactId version1.0.0/version /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-pgvector-store-spring-boot-starter/artifactId version1.0.0/version /dependency dependency groupIdorg.postgresql/groupId artifactIdpostgresql/artifactId /dependency这里解释下为什么选 PGVector我们已经有 PostgreSQL加个扩展就能用不用额外维护一套向量数据库。对于文档量在百万级以内的场景PGVector 的召回率和性能完全够用。3.2 文档入库把 PDF 和 Word 变成向量文档解析是 RAG 的第一步。Java 生态里Apache Tika是万能解析器PDF、Word、Excel、PPT 都能读。public ListDocument parseDocument(InputStream inputStream, String filename) { TikaDocumentReader reader new TikaDocumentReader( new InputStreamResource(inputStream), filename); ListDocument documents reader.get(); // 分块每块 500 token重叠 50 TokenTextSplitter splitter new TokenTextSplitter(500, 50, 5, 10000, true); return splitter.apply(documents); }分块参数是经验值500 token 一块重叠 50。块太大检索不准块太小上下文断裂。重叠是为了避免关键信息被切在边界上。入库时调用vectorStore.add(documents)Spring AI 会自动调嵌入模型并写入 PGVector。实操心得入库前一定要做文档清洗去掉页眉页脚、乱码、重复段落。我一开始没做检索出来的内容全是“第 X 页 共 Y 页”白白浪费 Token。3.3 检索与生成RAG 链路的核心代码查询链路分两步先检索相似文档再拼 Prompt 调大模型。public String ask(String question) { // 1. 检索 Top 5 相似文档 SearchRequest request SearchRequest.query(question) .withTopK(5) .withSimilarityThreshold(0.7); ListDocument docs vectorStore.similaritySearch(request); // 2. 拼接上下文 String context docs.stream() .map(Document::getContent) .collect(Collectors.joining(\n\n)); // 3. 构造 Prompt String prompt 你是一个内部文档助手请根据以下资料回答问题。 如果资料中没有答案请明确说“文档中未找到相关信息”。 资料 %s 问题%s .formatted(context, question); // 4. 调用大模型 return chatClient.prompt(prompt).call().content(); }similarityThreshold(0.7)这个阈值很关键。太低会召回无关内容太高会漏掉正确内容。我实测中文场景 0.65~0.75 比较合适具体要拿测试集调。3.4 流式输出与前端对接用户体验上流式输出比一次性返回好太多。Spring AI 支持stream()GetMapping(value /ask/stream, produces MediaType.TEXT_EVENT_STREAM_VALUE) public FluxString askStream(RequestParam String question) { return chatClient.prompt(buildPrompt(question)) .stream() .content(); }前端用EventSource接收逐字显示。这里有个坑流式返回时异常处理要单独做因为响应已经开始写了不能再改 HTTP 状态码。我的做法是捕获异常后返回一个特殊的结束标记前端识别后提示用户重试。3.5 成本控制与缓存策略大模型 API 是按 Token 计费的不做控制月底账单会吓人。我用了三层策略语义缓存相同或相似问题直接返回缓存结果用向量相似度判断阈值 0.95Prompt 压缩检索到的文档去重、截断控制上下文长度模型分级简单问题用便宜模型复杂问题才用贵模型// 语义缓存示例 public OptionalString getFromCache(String question) { ListDocument cached cacheStore.similaritySearch( SearchRequest.query(question).withTopK(1).withSimilarityThreshold(0.95)); return cached.isEmpty() ? Optional.empty() : Optional.of(cached.get(0).getMetadata().get(answer).toString()); }实测下来语义缓存能挡掉 30%~40% 的重复请求成本直接降三分之一。4. 进阶方向Agent、工具调用与工程化4.1 工具调用让 AI 能查数据库、调接口Agent 的核心是工具调用Function Calling。比如用户问“上个月销售额多少”AI 需要调用你的查询接口。Spring AI 里定义工具很简单public class SalesTool { Tool(description 查询指定月份的销售额) public BigDecimal querySales(ToolParam(description 月份格式 yyyy-MM) String month) { return salesService.getMonthlySales(month); } } ChatClient client ChatClient.builder(chatModel) .defaultTools(new SalesTool()) .build();AI 会自动判断是否需要调工具、调哪个、传什么参数。这里的关键是工具描述要写清楚描述模糊 AI 就乱调。我踩过的坑工具参数没加校验AI 传了个不存在的月份直接抛异常。后来在工具方法里加了参数校验和友好错误返回。4.2 多轮记忆对话上下文怎么管多轮对话不能把所有历史都塞进 PromptToken 扛不住。我的做法是滑动窗口保留最近 N 轮对话摘要压缩超过 N 轮后把早期对话摘要成一段话关键信息提取用户提到的订单号、姓名等单独存结构化字段public class ConversationMemory { private final DequeMessage recent new ArrayDeque(); private String summary ; public void add(Message message) { recent.addLast(message); if (recent.size() 10) { Message old recent.pollFirst(); summary summarize(summary, old); // 调模型摘要 } } }4.3 可观测性AI 应用的日志和监控怎么做传统后端的监控指标在 AI 应用里不够用。我额外加了这些指标说明告警阈值首 Token 延迟流式返回第一个字的时间 3s总 Token 消耗按天/按用户统计日环比 50%检索命中率相似度 阈值的比例 60%工具调用成功率Agent 调工具成功比例 95%用户负反馈率点踩/重问比例 15%这些指标用 Micrometer Prometheus 采集Grafana 展示。我特别推荐盯首 Token 延迟它直接决定用户体验比总响应时间更重要。4.4 安全与合规内容过滤和权限控制AI 应用的安全问题比传统后端更微妙。我做了这几层输入过滤敏感词、Prompt 注入检测输出过滤大模型返回内容再过一遍敏感词权限隔离不同用户检索的文档范围不同向量检索时带权限过滤条件审计日志谁在什么时候问了什么返回了什么全记录权限隔离这块要特别注意向量检索的过滤条件必须在数据库层面做不能检索完再过滤否则会泄露文档存在性。PGVector 支持 metadata 过滤建索引时把部门 ID 写进去。5. 常见问题与排查技巧实录5.1 依赖冲突与版本兼容问题Java 生态的依赖冲突是老毛病AI 框架引入后更明显。我遇到最多的是Jackson 版本冲突Spring AI 和项目里的 Jackson 版本不一致导致序列化异常Netty 冲突WebClient 和项目里的 Netty 版本打架SLF4J 绑定冲突多个日志实现共存排查方法mvn dependency:tree看依赖树用exclusions排除冲突版本。我习惯在父 POM 里统一管理 AI 相关依赖版本避免子模块各引各的。5.2 大模型接口超时与重试策略外部 API 不稳定是常态。我的重试策略RetryTemplate retryTemplate RetryTemplate.builder() .maxAttempts(3) .exponentialBackoff(1000, 2, 10000) .retryOn(IOException.class, TimeoutException.class) .build();注意流式接口不要盲目重试因为部分内容可能已经返回给用户了。我的做法是流式接口只在建立连接阶段重试一旦开始返回内容就不再重试而是返回错误标记让前端处理。5.3 向量检索不准的排查思路检索不准是 RAG 最常见的问题。我的排查顺序看分块文档分块是否合理有没有把完整语义切碎看嵌入模型中文场景用中文优化的模型别用纯英文模型看相似度阈值调低阈值看能否召回判断是阈值问题还是嵌入问题看查询改写用户问题口语化严重时先让大模型改写成检索友好的查询看混合检索纯向量检索对关键词不敏感加 BM25 混合检索效果更好我实测查询改写 混合检索能把召回率提升 20% 以上值得投入。5.4 常见问题速查表问题现象可能原因排查方法解决方案启动报 Bean 冲突多个 AI Starter看启动日志排除多余 Starter调用返回 401API Key 无效检查环境变量重新配置 Key流式返回乱码编码问题看响应头设置 UTF-8检索结果为空阈值过高调低阈值测试调整阈值或重建索引Token 超限上下文太长统计 Token 数截断或摘要响应特别慢模型选择不当看模型延迟换小模型或加缓存5.5 我踩过的三个真实坑第一个坑以为 Java 做 AI 要学 Python。我一开始花了两周学 Python 和 PyTorch后来发现根本用不上Java 调 API 和框架完全够。这两周纯属浪费建议直接上手 Java 生态。第二个坑忽略 Prompt 工程。我一开始觉得 Prompt 随便写写就行结果检索出来的答案质量很差。后来认真调 Prompt加了角色设定、输出格式约束、Few-shot 示例效果立竿见影。Prompt 工程是 AI 应用的核心技能不是玄学。第三个坑没做成本监控。上线第一周没看账单月底发现超预算三倍。后来加了 Token 统计和告警才发现是某个接口被刷了。AI 应用的成本控制要从第一天就做别等账单来了才后悔。6. 学习资源与持续进阶建议6.1 官方文档与社区资源Spring AI 和 LangChain4j 的官方文档是必读的但更新快建议看对应版本的文档。GitHub 上的 examples 仓库比文档更实用直接跑一遍就懂了。国内社区方面掘金和 CSDN 上有不少实战文章但质量参差建议优先看带完整代码的。6.2 从 Demo 到生产的差距Demo 跑通只要一天上生产要补的东西很多限流、降级、缓存、监控、告警、灰度、回滚。我的经验是把 AI 调用当成一个不稳定的外部依赖来对待所有传统后端的容错手段都要用上。别指望大模型 100% 可靠它就是个概率性服务。6.3 我个人在实际操作中的体会做了几个 AI 项目后我最大的体会是Java 开发者的优势在工程化不在算法。你不需要懂 Transformer 的注意力机制但你需要懂怎么把模型能力稳定、安全、低成本地交付给业务。这个能力恰恰是纯算法背景的人欠缺的。所以别焦虑把 AI 当成一个新的中间件来学。你会用 Redis就会用向量库你会调 Dubbo就会调大模型 API你会做熔断降级就会做 AI 服务的容错。底层思维是通的只是换了个技术栈而已。最后分享一个小技巧建一个自己的 Prompt 库把工作中验证有效的 Prompt 存下来按场景分类。这东西越攒越值钱比任何教程都实用。我现在攒了 60 多个 Prompt 模板新项目直接复用效率翻倍。
Java开发者AI入门实战：从API调用到RAG与Agent工程化落地
1. Java 开发者切入 AI 的真实动机与路径选择1.1 为什么 Java 开发者需要关注 AI 而不是转语言这两年我身边不少 Java 老哥都在焦虑一件事AI 火了Python 成了“AI 第一语言”自己写了七八年的 Spring Boot、MyBatis、Dubbo难道要推倒重来我的判断很明确——不需要转语言但需要转思维。Java 在企业级后端、高并发、分布式事务、微服务治理上的积累恰恰是 AI 应用落地阶段最缺的能力。模型训练确实以 Python 为主但模型服务化、推理接口封装、RAG 检索链路、Agent 编排、向量库对接、权限与计费这些工程化环节Java 的生态成熟度并不差。我实测下来一个熟练的 Java 后端用两周业余时间就能跑通“调用大模型 API 本地向量检索 简单 Agent 工具调用”的完整闭环。难点不在语言而在于你要理解 AI 应用的数据流和不确定性处理——传统后端是确定性逻辑AI 应用是概率性输出这个思维切换才是真正的门槛。1.2 三条典型路线API 调用派、框架集成派、自建推理派我把 Java 开发者入门 AI 的路线粗分成三条你可以对号入座路线适合人群核心技术栈上手周期落地场景API 调用派业务后端、想快速出活HTTP Client、Spring AI、LangChain4j3~7 天智能客服、文档问答、内容生成框架集成派架构师、中间件方向Spring AI、LangChain4j、向量库 SDK2~4 周RAG 知识库、Agent 工作流自建推理派算法工程、追求可控DJL、ONNX Runtime、TensorFlow Java1~3 个月私有化部署、边缘推理我个人的建议是先走 API 调用派再过渡到框架集成派。原因很简单自建推理对 Java 开发者性价比太低除非你有明确的私有化合规需求否则没必要一上来就啃模型权重和 CUDA。先把“怎么把大模型能力接进现有 Java 系统”这件事跑通比什么都重要。1.3 路线图总览从环境到上线的五个阶段我把完整路线拆成五个阶段每个阶段都有明确的交付物避免你学着学着就迷失环境准备阶段JDK 17、Maven/Gradle、IDE、API Key 管理、HTTP 调试工具基础调用阶段同步/流式调用、Prompt 模板、Token 计费、异常重试工程集成阶段Spring AI 或 LangChain4j 接入、向量库对接、RAG 链路Agent 编排阶段工具调用、多轮记忆、任务分解、结果校验上线运维阶段限流降级、缓存、可观测性、成本控制、安全过滤这五个阶段不是线性的实际做项目时经常来回跳。但作为学习路径按这个顺序走不会乱。2. 工具链选型Java 生态里哪些东西真能用2.1 核心框架对比Spring AI vs LangChain4j这是 Java 开发者问得最多的问题。我两个都用过说下真实感受Spring AI的优势在于和 Spring 生态无缝集成如果你现有项目就是 Spring Boot引入spring-ai-openai-spring-boot-starter之后配置几个application.yml就能跑。它的抽象层设计比较克制ChatClient、EmbeddingClient、VectorStore 这几个接口覆盖了 80% 的场景。缺点是版本迭代快API 偶尔有破坏性变更生产环境要锁版本。LangChain4j更偏向“AI 原生”链式调用、Agent、Tool 抽象做得更细适合复杂编排场景。它的AiServices可以把接口直接映射成 AI 调用写起来很舒服。缺点是学习曲线略陡概念比 Spring AI 多。我的选型建议业务系统集成选 Spring AI独立 AI 应用选 LangChain4j。如果团队 Java 水平参差Spring AI 的认知负担更低。2.2 向量库与嵌入模型RAG 的地基怎么打RAG检索增强生成是 Java 开发者最容易落地的 AI 场景核心就两件事把文档变成向量存起来查询时找最相似的。向量库选型我踩过坑列个表向量库部署方式Java 客户端适用规模备注Redis Stack内存Jedis/Lettuce百万级已有 Redis 直接用最省事Milvus独立服务官方 SDK亿级功能全运维成本高PGVectorPostgreSQL 插件JDBC千万级已有 PG 首选Elasticsearch独立服务官方 Client亿级全文向量混合检索强Chroma轻量嵌入HTTP十万级原型阶段方便嵌入模型方面Java 开发者不用自己训直接调 API 或本地跑 ONNX 模型。我实测text-embedding-3-small这类 API 模型性价比最高本地模型推荐bge-small-zh的 ONNX 版本用 DJL 加载CPU 也能跑。2.3 开发辅助工具让 AI 帮你写 Java这里说个反直觉的点AI 编程助手对 Java 开发者的提效比对 Python 更明显。因为 Java 样板代码多getter/setter、DTO 转换、异常处理这些 AI 生成准确率很高。我常用的组合IDE 插件通义灵码、GitHub Copilot写 CRUD 和单元测试极快Prompt 管理把常用 Prompt 存成模板比如“生成带参数校验的 Controller”API 调试Apifox 或 Postman调大模型接口时看流式返回很方便本地模型Ollama 跑个 7B 模型断网也能用适合敏感代码场景注意AI 生成的 Java 代码一定要过 SonarQube 或 SpotBugs我遇到过生成的代码有资源未关闭、空指针隐患的情况别直接上生产。2.4 环境与依赖管理别在配置上浪费时间Java 开发者入门 AI 最容易卡在环境上。我的建议是JDK 版本17 或 21Spring AI 要求 17构建工具Maven 足够Gradle 也行别纠结API Key 管理用环境变量或配置中心千万别硬编码网络调外部 API 要配超时和重试OkHttp或WebClient都行日志请求和响应要脱敏后记录方便排查# application.yml 示例 spring: ai: openai: api-key: ${AI_API_KEY} chat: options: model: gpt-4o-mini temperature: 0.7 embedding: options: model: text-embedding-3-small3. 从零到一一个 Java AI 问答服务的完整实操3.1 项目初始化与依赖引入我拿一个真实做过的“内部文档问答服务”举例完整走一遍。项目用 Spring Boot 3.2 Spring AI 1.0 PGVector。pom.xml核心依赖dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-openai-spring-boot-starter/artifactId version1.0.0/version /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-pgvector-store-spring-boot-starter/artifactId version1.0.0/version /dependency dependency groupIdorg.postgresql/groupId artifactIdpostgresql/artifactId /dependency这里解释下为什么选 PGVector我们已经有 PostgreSQL加个扩展就能用不用额外维护一套向量数据库。对于文档量在百万级以内的场景PGVector 的召回率和性能完全够用。3.2 文档入库把 PDF 和 Word 变成向量文档解析是 RAG 的第一步。Java 生态里Apache Tika是万能解析器PDF、Word、Excel、PPT 都能读。public ListDocument parseDocument(InputStream inputStream, String filename) { TikaDocumentReader reader new TikaDocumentReader( new InputStreamResource(inputStream), filename); ListDocument documents reader.get(); // 分块每块 500 token重叠 50 TokenTextSplitter splitter new TokenTextSplitter(500, 50, 5, 10000, true); return splitter.apply(documents); }分块参数是经验值500 token 一块重叠 50。块太大检索不准块太小上下文断裂。重叠是为了避免关键信息被切在边界上。入库时调用vectorStore.add(documents)Spring AI 会自动调嵌入模型并写入 PGVector。实操心得入库前一定要做文档清洗去掉页眉页脚、乱码、重复段落。我一开始没做检索出来的内容全是“第 X 页 共 Y 页”白白浪费 Token。3.3 检索与生成RAG 链路的核心代码查询链路分两步先检索相似文档再拼 Prompt 调大模型。public String ask(String question) { // 1. 检索 Top 5 相似文档 SearchRequest request SearchRequest.query(question) .withTopK(5) .withSimilarityThreshold(0.7); ListDocument docs vectorStore.similaritySearch(request); // 2. 拼接上下文 String context docs.stream() .map(Document::getContent) .collect(Collectors.joining(\n\n)); // 3. 构造 Prompt String prompt 你是一个内部文档助手请根据以下资料回答问题。 如果资料中没有答案请明确说“文档中未找到相关信息”。 资料 %s 问题%s .formatted(context, question); // 4. 调用大模型 return chatClient.prompt(prompt).call().content(); }similarityThreshold(0.7)这个阈值很关键。太低会召回无关内容太高会漏掉正确内容。我实测中文场景 0.65~0.75 比较合适具体要拿测试集调。3.4 流式输出与前端对接用户体验上流式输出比一次性返回好太多。Spring AI 支持stream()GetMapping(value /ask/stream, produces MediaType.TEXT_EVENT_STREAM_VALUE) public FluxString askStream(RequestParam String question) { return chatClient.prompt(buildPrompt(question)) .stream() .content(); }前端用EventSource接收逐字显示。这里有个坑流式返回时异常处理要单独做因为响应已经开始写了不能再改 HTTP 状态码。我的做法是捕获异常后返回一个特殊的结束标记前端识别后提示用户重试。3.5 成本控制与缓存策略大模型 API 是按 Token 计费的不做控制月底账单会吓人。我用了三层策略语义缓存相同或相似问题直接返回缓存结果用向量相似度判断阈值 0.95Prompt 压缩检索到的文档去重、截断控制上下文长度模型分级简单问题用便宜模型复杂问题才用贵模型// 语义缓存示例 public OptionalString getFromCache(String question) { ListDocument cached cacheStore.similaritySearch( SearchRequest.query(question).withTopK(1).withSimilarityThreshold(0.95)); return cached.isEmpty() ? Optional.empty() : Optional.of(cached.get(0).getMetadata().get(answer).toString()); }实测下来语义缓存能挡掉 30%~40% 的重复请求成本直接降三分之一。4. 进阶方向Agent、工具调用与工程化4.1 工具调用让 AI 能查数据库、调接口Agent 的核心是工具调用Function Calling。比如用户问“上个月销售额多少”AI 需要调用你的查询接口。Spring AI 里定义工具很简单public class SalesTool { Tool(description 查询指定月份的销售额) public BigDecimal querySales(ToolParam(description 月份格式 yyyy-MM) String month) { return salesService.getMonthlySales(month); } } ChatClient client ChatClient.builder(chatModel) .defaultTools(new SalesTool()) .build();AI 会自动判断是否需要调工具、调哪个、传什么参数。这里的关键是工具描述要写清楚描述模糊 AI 就乱调。我踩过的坑工具参数没加校验AI 传了个不存在的月份直接抛异常。后来在工具方法里加了参数校验和友好错误返回。4.2 多轮记忆对话上下文怎么管多轮对话不能把所有历史都塞进 PromptToken 扛不住。我的做法是滑动窗口保留最近 N 轮对话摘要压缩超过 N 轮后把早期对话摘要成一段话关键信息提取用户提到的订单号、姓名等单独存结构化字段public class ConversationMemory { private final DequeMessage recent new ArrayDeque(); private String summary ; public void add(Message message) { recent.addLast(message); if (recent.size() 10) { Message old recent.pollFirst(); summary summarize(summary, old); // 调模型摘要 } } }4.3 可观测性AI 应用的日志和监控怎么做传统后端的监控指标在 AI 应用里不够用。我额外加了这些指标说明告警阈值首 Token 延迟流式返回第一个字的时间 3s总 Token 消耗按天/按用户统计日环比 50%检索命中率相似度 阈值的比例 60%工具调用成功率Agent 调工具成功比例 95%用户负反馈率点踩/重问比例 15%这些指标用 Micrometer Prometheus 采集Grafana 展示。我特别推荐盯首 Token 延迟它直接决定用户体验比总响应时间更重要。4.4 安全与合规内容过滤和权限控制AI 应用的安全问题比传统后端更微妙。我做了这几层输入过滤敏感词、Prompt 注入检测输出过滤大模型返回内容再过一遍敏感词权限隔离不同用户检索的文档范围不同向量检索时带权限过滤条件审计日志谁在什么时候问了什么返回了什么全记录权限隔离这块要特别注意向量检索的过滤条件必须在数据库层面做不能检索完再过滤否则会泄露文档存在性。PGVector 支持 metadata 过滤建索引时把部门 ID 写进去。5. 常见问题与排查技巧实录5.1 依赖冲突与版本兼容问题Java 生态的依赖冲突是老毛病AI 框架引入后更明显。我遇到最多的是Jackson 版本冲突Spring AI 和项目里的 Jackson 版本不一致导致序列化异常Netty 冲突WebClient 和项目里的 Netty 版本打架SLF4J 绑定冲突多个日志实现共存排查方法mvn dependency:tree看依赖树用exclusions排除冲突版本。我习惯在父 POM 里统一管理 AI 相关依赖版本避免子模块各引各的。5.2 大模型接口超时与重试策略外部 API 不稳定是常态。我的重试策略RetryTemplate retryTemplate RetryTemplate.builder() .maxAttempts(3) .exponentialBackoff(1000, 2, 10000) .retryOn(IOException.class, TimeoutException.class) .build();注意流式接口不要盲目重试因为部分内容可能已经返回给用户了。我的做法是流式接口只在建立连接阶段重试一旦开始返回内容就不再重试而是返回错误标记让前端处理。5.3 向量检索不准的排查思路检索不准是 RAG 最常见的问题。我的排查顺序看分块文档分块是否合理有没有把完整语义切碎看嵌入模型中文场景用中文优化的模型别用纯英文模型看相似度阈值调低阈值看能否召回判断是阈值问题还是嵌入问题看查询改写用户问题口语化严重时先让大模型改写成检索友好的查询看混合检索纯向量检索对关键词不敏感加 BM25 混合检索效果更好我实测查询改写 混合检索能把召回率提升 20% 以上值得投入。5.4 常见问题速查表问题现象可能原因排查方法解决方案启动报 Bean 冲突多个 AI Starter看启动日志排除多余 Starter调用返回 401API Key 无效检查环境变量重新配置 Key流式返回乱码编码问题看响应头设置 UTF-8检索结果为空阈值过高调低阈值测试调整阈值或重建索引Token 超限上下文太长统计 Token 数截断或摘要响应特别慢模型选择不当看模型延迟换小模型或加缓存5.5 我踩过的三个真实坑第一个坑以为 Java 做 AI 要学 Python。我一开始花了两周学 Python 和 PyTorch后来发现根本用不上Java 调 API 和框架完全够。这两周纯属浪费建议直接上手 Java 生态。第二个坑忽略 Prompt 工程。我一开始觉得 Prompt 随便写写就行结果检索出来的答案质量很差。后来认真调 Prompt加了角色设定、输出格式约束、Few-shot 示例效果立竿见影。Prompt 工程是 AI 应用的核心技能不是玄学。第三个坑没做成本监控。上线第一周没看账单月底发现超预算三倍。后来加了 Token 统计和告警才发现是某个接口被刷了。AI 应用的成本控制要从第一天就做别等账单来了才后悔。6. 学习资源与持续进阶建议6.1 官方文档与社区资源Spring AI 和 LangChain4j 的官方文档是必读的但更新快建议看对应版本的文档。GitHub 上的 examples 仓库比文档更实用直接跑一遍就懂了。国内社区方面掘金和 CSDN 上有不少实战文章但质量参差建议优先看带完整代码的。6.2 从 Demo 到生产的差距Demo 跑通只要一天上生产要补的东西很多限流、降级、缓存、监控、告警、灰度、回滚。我的经验是把 AI 调用当成一个不稳定的外部依赖来对待所有传统后端的容错手段都要用上。别指望大模型 100% 可靠它就是个概率性服务。6.3 我个人在实际操作中的体会做了几个 AI 项目后我最大的体会是Java 开发者的优势在工程化不在算法。你不需要懂 Transformer 的注意力机制但你需要懂怎么把模型能力稳定、安全、低成本地交付给业务。这个能力恰恰是纯算法背景的人欠缺的。所以别焦虑把 AI 当成一个新的中间件来学。你会用 Redis就会用向量库你会调 Dubbo就会调大模型 API你会做熔断降级就会做 AI 服务的容错。底层思维是通的只是换了个技术栈而已。最后分享一个小技巧建一个自己的 Prompt 库把工作中验证有效的 Prompt 存下来按场景分类。这东西越攒越值钱比任何教程都实用。我现在攒了 60 多个 Prompt 模板新项目直接复用效率翻倍。