Java 转大模型开发：从工具接入到项目提效

关注

原创最新推荐文章于 2026-06-27 12:39:54 发布 339 阅读 AI 写同款· GEO 优化 ›

SpringAI——如何使用java来接入大模型 Spring AI是Spring生态中的新成员，专门为AI服务接入而设计，提供统一的API接口和自动配置能力，极大地简化了开发人员与不同大模型API集成的过程。add存储指定会话ID的聊天消息列表到内存或持久存储中。get根据会话ID和数量lastN，获取最近的N条聊天消息。clear清空指定会话ID对应的消息列表。阅读详情

**分类**：职业转型
**账号**：Java技术那些事

摘要

去年年底接手公司内部一个智能知识库项目，需求很简单：把几十份产品文档喂进去，让销售能用自然语言问问题，并且答案必须带来源页码。我那时候刚对 Python 生态系统有点熟悉，但公司 Java 栈太深，没法换语言。硬着头皮用 Java 干完了，结果发现这条路不仅走得通，而且很多后端同学的优势恰恰被低估了。这篇文章就从那次项目复盘说起，重点讲讲我踩过的坑、扔掉的东西，以及真正值得投入时间去练的部分。

Java 开发者的优势

文章插图 1

刚转的时候我特焦虑，一刷 GitHub 全是 Python 的 LLM 项目，Community 里 Java 影子都找不到。但真干起来才发现，后端那套底子没白费。

**第一个优势是工程化思维**。大模型开发最头疼的不是调 API，而是怎么处理调用失败、限流重试、超时熔断。这些在 Spring Cloud 里早就烂熟于心。我第一次用 `RetryTemplate` 包装 OpenAI 调用时，同事还在用 Python 的 `tenacity` 写循环，但 Java 的线程模型和异常处理让整个链路更可控。

**第二个优势是数据基础设施**。知识库项目涉及文档解析、向量化、存储。我们团队之前用 Elasticsearch 做搜索，换成向量数据库 Milvus 后，索引管理、聚合查询、分片策略几乎可以直接复用。Java 客户端生态成熟，生产环境里的连接池、心跳检测都是现成的。

**第三个优势是类型安全**。大模型输出的 JSON 经常格式崩塌，Python 那边要写一堆 try-catch 或 pydantic 校验。Java 直接用 Jackson 的 `@JsonSetter` 加默认值，配合 `Optional` 处理 null，比 Python 的字典显式检查更干净。后面会给出具体代码。

别被“Python 才是 AI 主流”这种话吓退。Java 转过去，你的优势在于**把模型打包成稳定服务**，而不是调参炼丹。

需要补齐的 AI 技能

文章插图 2

老实说，一开始我高估了自学难度。真正需要补齐的只有三块：

1. **Prompt Engineering 基础**。不用学什么复杂策略，先搞懂 system prompt 和 user prompt 的区别，学会用结构化指令（比如要求输出 JSON 并用中文修饰）。踩坑点：很多 Java 同学会直接拿字符串拼接去拼 prompt，结果带换行符和转义字符导致模型幻觉。最好用 `String.format` 或模板引擎（如 Freemarker）预先定义好占位符。

2. **Embedding 与向量检索原理**。不需要会推公式，但要理解余弦相似度、文本切分（Chunking）策略。我那项目最开始用固定 500 字符切分，结果答案总是断在句子中间。后来改用 LangChain4j 的 `DocumentSplitter` 按段落切分，召回率从 40% 提到 70%。

3. **模型 API 的限流与计费控制**。后端同学习惯“资源无限”的思维，但大模型 API 是计费的，而且并发限制卡得死。我得在 `@RateLimiter` 注解和 `Semaphore` 之间做取舍——最终用了 Guava 的 `RateLimiter` 配合线程池，避免因为频繁重试把账单打爆。

**判断标准**：只要你用 Java 写过 REST 接口，这三块每周花 10 小时，一个月就能上手。不用专门去学 Python。

优快云资料领取方式

Spring AI 与 LangChain4j

当时项目选型，我在 Spring AI（官方的）和 LangChain4j（社区更活跃）之间犹豫了三天。最后两个都试了一下，说说真实体验。

**Spring AI** 的好处是跟 Spring Boot 无缝集成，配置走 `application.yml`，自动装配 VectorStore 和 ChatModel。缺点是文档太薄，很多高级用法（比如 Tool calling、Agent）要靠读源码。我用它搭了一个简单 RAG 原型，但遇到中文切分不对的问题，查 issue 发现是 `DocumentSplitter` 对中文不友好，只能自己写 `ChineseDocumentSplitter`（后面附代码）。

**LangChain4j** 功能更全，支持更多模型（包括国内的通义千问、DeepSeek），内置的 `ContentRetriever` 和 `Chain` 更贴近 Python 版的思路。但它跟 Spring 生态融合生硬，需要手动管理 Bean 生命周期。我最后选了 LangChain4j，原因是项目需要对接企业微信机器人——它内置了 `ToolSpecification` 的 Spring 集成，省了写消息通道的功夫。

**踩坑细节**：LangChain4j 的版本更新太快，0.30 到 0.33 的 API 不兼容。我花了一天升级后发现 `AiServices` 的创建方式变了，最后锁定版本号并写了个 `@ConditionalOnProperty` 做灰度切换。

下面是一个用 LangChain4j 调用本地 Ollama 的简单示例（可以跑通）：

import dev.langchain4j.model.ollama.OllamaChatModel;
import dev.langchain4j.service.AiServices;
import dev.langchain4j.memory.chat.MessageWindowChatMemory;

interface Assistant {
    String chat(String userMessage);
}

public class SimpleDemo {
    public static void main(String[] args) {
        OllamaChatModel model = OllamaChatModel.builder()
                .baseUrl("http://localhost:11434")
                .modelName("qwen2.5:7b")
                .temperature(0.7)
                .build();

        Assistant assistant = AiServices.builder(Assistant.class)
                .chatLanguageModel(model)
                .chatMemory(MessageWindowChatMemory.withMaxMessages(10))
                .build();

        String answer = assistant.chat("Java转大模型开发需要哪些技能？");
        System.out.println(answer);
    }
}

注意这里 `qwen2.5:7b` 要提前在 Ollama 里 pull，并且注意模型名大小写。Java 调用 Ollama 比直接调 OpenAI 更省事，本地开发不用申请 API Key。

项目练习

光看文档没用，必须做项目。我推荐三个循序渐进的方向，每个都踩过坑。

**练习一：文档问答机器人（RAG）**

选一个 Spring Boot 项目，集成 LangChain4j + Milvus（或本地的 Chroma）。
踩坑点：文档切分太细导致上下文丢失，太粗又超 Token 限制。我最后的方案是先用段落切分，然后按语义重叠（1024 字符，128 字符重叠），用 `OverlappingDocumentSplitter`。
展示建议：在简历里写“基于 LangChain4j 实现企业级 RAG 系统，支持多格式文档解析，召回准确率 92%”。面试官会追问“你怎么评估准确率”，不要编，直接说用人工标注了 200 条问答对。

**练习二：Function Calling 工具调用**

模拟一个天气查询或订单查询，让模型决定调用哪个 Java 方法。
踩坑点：模型可能自己虚构工具名。必须做白名单校验，只允许注册过的函数。
代码关键点：用 `@Tool` 注解定义方法，并配置 `ToolSpecification` 的 description 要写详细，否则模型不会触发。

**练习三：简单的多轮 Agent**

用 AiServices 加 `ChatMemory` 实现带记忆的客服 Agent。
踩坑点：内存条数设置太大导致 Token 消耗剧增。我限制最多 6 轮对话，超出后自动压缩历史。
面试价值：这个项目能体现你对 Agent 模式的理解，而不是只会调 API。

面试准备

面试官大多是做 AI 的，但对 Java 后端可能不太感冒。你要准备三个故事。

**第一个故事：RAG 实现中的取舍**。不要只说“用了 LangChain4j”，要讲“为什么不用向量数据库的默认切分策略而改用自己写的切分器”——这在面试官眼里比调框架值钱。

**第二个故事：大模型输出的不稳定性处理**。我遇到最离谱的是模型返回的 JSON 里包含英文注释（`// ` 开头），Jackson 直接崩。解决方案是先用正则过滤注释，再用 `ObjectMapper` 反序列化。这种工程细节比背 Prompt 技巧加分。

**第三个故事：性能与成本控制**。真实项目里一个请求可能调两次大模型（一次 Embedding，一次生成），如果都用高精度模型，单次成本很高。我设计了一个“先检索后判断”的流程：先用廉价模型做 Embedding，只有检索结果不足时才调高价模型。面试官听了会追问“你怎么定义‘不足’”，准备个阈值设计思路。

额外提醒：简历上不要写“精通大模型”，这词太虚。改成“Spring AI / LangChain4j 实战经验，独立完成基于 RAG 的智能问答系统”。另外准备一两个 GitHub 仓库，代码不用漂亮，但要能跑。