面试官翻了翻项目经历问了一个看似随意、其实很能分辨人的问题你这个 AI 知识库项目后端用的什么框架Spring AI。候选人答得很干脆。为什么用它而不是 LangChain4j候选人有点懵因为……我们本来就是 Spring 项目面试官点点头又问那模型呢调的是哪家的 API某云的。考虑过私有化部署吗如果客户要求数据不能出内网你怎么办候选人这次卡住了。这两个问题一个考框架选型一个考部署选型其实是两道完全不同的题。很多人把它们混成一团答的时候东一句西一句。能分开讲清楚的人面试官心里会给一个这人做过真项目的印象。这篇就把这两道题分开掰碎。第一步把两个问题分开先纠正一个常见误区框架选型和部署选型是两个独立的决策别混着答。-框架选型你代码里用哪套 Java 库来对接大模型Spring AI 还是 LangChain4j或者干脆自己封装 HTTP这影响的是怎么写代码、怎么维护。-部署选型模型跑在哪是调厂商的云端 API还是自己拿 GPU 私有化部署Ollama / vLLM这影响的是数据往哪走、成本多少、运维谁扛。框架是上层的地基部署是底层的水电。地基选好了水电可以换反过来也一样。两件事拆开谈思路立刻清晰。一、框架选型Spring AI vs LangChain4j这两套是目前 Java 圈对接大模型最主要的选择。它们都能干同样的事——调用对话模型、做向量检索、流式输出、工具调用。差别不在能不能在用起来顺不顺、跟你的工程环境合不合。生态与抽象层。Spring AI 的定位很明确它就是 Spring 生态的一部分。你项目里如果有 Spring Boot引入一个 starter写几行配置文件就能用依赖注入、自动配置、Actuator 都是现成的。它把模型抽象成ChatModel、EmbeddingModel、VectorStore接口统一换模型基本只改配置。LangChain4j 是独立库不依赖 Spring 也能跑。它的抽象更链条化概念上贴近 Python 的 LangChain最有特色的是AiServices——你定义一个接口用注解描述行为框架帮你生成实现interface Assistant { SystemMessage(你是严谨的客服助手只依据资料回答资料没有就说不知道。) String chat(UserMessage String question); } // 让框架生成实现类 Assistant assistant AiServices.builder(Assistant.class) .chatLanguageModel(chatModel) // 底层用哪个对话模型 .chatMemory(MessageWindowChatMemory.withMaxMessages(10)) // 保留最近10条 .build(); String answer assistant.chat(你们的退货政策是什么);AiServices.builder会根据接口和注解动态实现AssistantSystemMessage是系统提示词UserMessage标记用户输入。MessageWindowChatMemory只保留最近若干条消息避免历史越攒越长。写起来直观像在声明我要一个什么样的助手而不是一步步拼 Prompt。Spring AI 这边对应的写法是ChatClient链式调用ChatClient chatClient ChatClient.builder(chatModel) .defaultSystem(你是严谨的客服助手。) .build(); String answer chatClient.prompt() .user(你们的退货政策是什么) .call() .content();ChatClient.builder拿到模型defaultSystem设默认系统提示prompt().user(...).call().content()一路链下去拿到文本。如果你团队本来就在 Spring 舒适区里这套用起来几乎零学习成本。流式与工具调用。两套都支持形式不同。Spring AI 的流式直接返回响应式流天然接 WebFluxFluxString stream chatClient.prompt() .user(写一首关于秋天的诗) .stream() .content(); // 逐段吐出增量文本LangChain4j 用回调式StreamingChatLanguageModel streamModel ...; streamModel.generate(messages, new StreamingResponseHandlerAiMessage() { Override public void onNext(String token) { // 每收到一小段增量推给前端 } Override public void onComplete(ResponseAiMessage response) { // 生成结束 } Override public void onError(Throwable error) { // 出错处理 } });工具调用Function Calling也有对应写法。LangChain4j 用Tool注解声明式class OrderTools { Tool(根据订单号查询订单状态) String queryOrder(P(订单号) String orderId) { // 真正查库的逻辑 return orderService.getStatus(orderId); } } Assistant assistant AiServices.builder(Assistant.class) .chatLanguageModel(chatModel) .tools(new OrderTools()) // 把工具挂上去模型需要时会自动调用 .build();方法上打一个Tool框架自动把方法签名转成模型能理解的工具描述。模型判断需要查订单时会发起调用框架再回填结果。Spring AI 同样支持用Tool注解配合chatClient.prompt().tools(...)。可观测性。这点对企业项目很关键。Spring AI 天然能接 Micrometer 和 Actuator模型调用的耗时、Token 用量这些指标能进你已有的监控大盘跟其他微服务指标放一起看。LangChain4j 自带一套监听器接口灵活但接什么监控系统要你自己搭。如果你们已经有成熟的 Spring 监控体系Spring AI 是顺水推舟如果想完全自定义LangChain4j 更自由。版本成熟度。两套项目早期版本都改过 API升级要养成看 changelog 的习惯。Spring AI 从 1.0 正式版之后接口趋于稳定LangChain4j 迭代快、功能加得勤。押注之前先确认你用的版本、锁好依赖别用 snapshot。二、部署选型云端 API vs 私有化框架定完接下来才是最花钱、最容易踩合规红线的一步模型跑在哪。先问一句最重要的话你的数据能不能出你的机房这一个问题往往就把方案砍掉一半。路线一调云端 API。省心模型能力通常也最强弹性扩缩不用你操心不用买 GPU。代价是数据要发到厂商那边合规得先过评估按 Token 计费量一大账单很难看请求还受网络和厂商配额牵制。路线二Ollama本地跑。ollama pull一个模型ollama serve起服务本机就能用数据一步不出门。它对外提供 OpenAI 兼容的接口Java 端几乎不用改代码就能切过来。缺点是单机吞吐有限高并发下会排队。它适合开发调试、内网小工具、个人知识库这类场景别指望它扛生产级大流量。Spring AI 接本地 Ollama配置几行搞定spring.ai.ollama.base-urlhttp://localhost:11434 spring.ai.ollama.chat.options.modelllama3.1指定地址和模型名就行。因为走的是 Ollama 的 OpenAI 兼容端点代码里那套ChatClient调用写法一点不用动。路线三vLLM自建 GPU 集群。要规模化私有部署vLLM 是常见选择。它用连续批处理continuous batching和 PagedAttention 这类技术把 GPU 利用率拉高还能开多卡并行并且对外提供 OpenAI 兼容接口。启动起来大致是这样vllm serve meta-llama/Llama-3.1-8B-Instruct \ --host 0.0.0.0 --port 8000服务起来后http://你的机器:8000/v1就是一个标准 OpenAI 兼容地址。Java 端把它当成普通 OpenAI 端点配就行spring.ai.openai.base-urlhttp://你的机器:8000 spring.ai.openai.api-keydummy # 本地服务通常不校验填个占位 spring.ai.openai.chat.options.modelmeta-llama/Llama-3.1-8B-Instruct用spring.ai.openai.*这套配置把base-url指向自己的 vLLM代码层面跟在调云厂商没有区别。这就是OpenAI 兼容协议最大的好处留了一条随时切换的后路。云厂商宕了、配额不够了把 base-url 一改请求就转到自建服务上。代价也实在要真金白银买 GPU要有人维护推理服务扩容缩容得自己做调度而且自建模型的效果上限取决于你选的开源模型跟头部闭源模型比可能差一截。三、一张决策表把两个维度合起来看你的情况建议团队重度使用 Spring Boot框架优先 Spring AI需要丰富的 Agent / 检索编排能力可以评估 LangChain4j数据不能出内网私有化小规模 Ollama规模化 vLLM快速验证、对外产品、非敏感数据云端 API省事优先强合规 稳定并发vLLM 自建配负载均衡既想效果好又想控风险云 API 主力 本地模型兜底没有哪条路永远正确。一个很实用的做法是所有方案都走 OpenAI 兼容协议把用哪个模型变成配置项而不是硬编码。这样从云 API 切到 vLLM只是改一行base-url的事多花的成本极低却能换来巨大的灵活性。 面试官视角的标准回答如果面试官问Java 做 AIGC框架和模型怎么选我会把它拆成两个独立的决策。框架选型上如果团队主力是 Spring Boot选 Spring AI 更顺Starter 引入即用ChatClient 链式调用模型抽象成统一接口监控能接 Micrometer 和 Actuator工程一致性最好。如果项目需要更丰富的 Agent、检索编排或者概念上更贴近 LangChain 那套可以评估 LangChain4j它的 AiServices 接口式写法和 Tool 注解很直观。两套底层能力重叠度很高别为框架而框架跟着团队的技术栈走。部署选型上先问数据能不能出域。必须本地、规模小用 Ollama一条命令跑起来数据不出门必须本地、要并发用 vLLM 自建 GPU 集群连续批处理提升吞吐对外也是 OpenAI 兼容接口。如果数据不敏感、追求效果和上线速度就用云端 API省运维。代价是数据出域和按量计费。我的落地建议是所有方案统一走 OpenAI 兼容协议把模型选择做成配置项。主力走云 API 保效果敏感链路或兜底走本地模型切换只改 base-url。这样既控制了合规和成本风险也不把自己绑死在某一家上。面试官可能追问的进阶问题用 LangChain4j 或 Spring AI会不会被框架绑死会有一点但可控。关键是把调用模型这层收敛到自己定义的门面接口后面框架只做实现。真要换改实现类就行业务代码不动。别让业务逻辑直接散落在框架的 API 调用里。私有化部署的模型效果不够怎么办两个方向选更强的开源模型配合量化或者在自己的数据上做微调。但微调是另一道题先评估是不是数据质量和检索的问题别一上来就上微调。云 API 和本地模型能不能同时用能这是很常见的做法。用统一的接口做路由普通请求走云 API涉密请求走本地云 API 挂掉时自动降级到本地。前提是两边都遵循同一套协议业务层感觉不到区别。Ollama 能不能上生产小规模、低并发、内网工具可以配好资源限制和超时。真要高并发、要稳定 SLA还是得上 vLLM 这类专门做推理服务的方案。下一篇是这个系列的压轴大题——从 0 设计一套企业级 AI 知识库问答系统。文档怎么进来、怎么切分、存哪、怎么检索、怎么生成、怎么评估、怎么运维面试官会一层层往下问我会给你一套能顶住连环追问的完整框架。