Spring AI 面试题库

生成时间: 2026-05-21 21:17 来源: Spring AI 面试刷题助手 (Cron 自动生成)

---

本轮 Spring AI 面试题库（带答案）

【面试题】1. Spring AI 1.0 正式版中，ChatClient 相比旧版 ChatModel 有什么核心优势？为什么要统一到 ChatClient 入口？

【标准答案】 ChatClient 是 Spring AI 1.0 推出的统一调用入口，核心优势有三点：

第一，Fluent API 更直观。以前用 ChatModel 要自己拼 Prompt 对象，现在链式调用一行搞定：

chatClient.prompt().user("你好").call().content();

第二，Advisor 机制内置。ChatClient 原生支持 Advisor 拦截器，可以统一处理日志、重试、记忆等功能，不用每个调用点都写一遍。

第三，结构化输出集成。直接 .entity(MyClass.class) 就能把 LLM 响应映射成 POJO，不用手动解析 JSON。

至于为什么要统一？因为之前 ChatModel、StreamingChatModel、ImageModel 各有各的调用方式，项目一大就乱。统一到 ChatClient 后，调用模式一致，代码更易维护，团队上手成本低。简单说：一个入口，所有能力，风格统一。

---

【面试题】2. RAG 场景中，TokenTextSplitter 的切分策略怎么选？chunk_size 和 chunk_overlap 设置多少合适？

【标准答案】 这是个很实用的问题，没有万能答案，但有最佳实践：

chunk_size 选择：

• 通用文档（FAQ、知识库）：500-800 tokens，信息密度高，检索精准
• 长文档（论文、合同）：1000-1500 tokens，保持段落完整性
• 代码文件：按函数/类切分，200-500 tokens，避免跨函数截断

chunk_overlap 选择：

• 一般设 chunk_size 的 10%-20%
• 比如 chunk_size=800，overlap 设 80-160
• 目的是保证切分处上下文连续，避免关键信息被切断

我的建议：先用默认值（8191/500）跑一轮看效果，检索召回率低就调小 chunk_size，响应质量差就调大。线上环境建议按文档类型建多个 Splitter，配置不同的切分参数。记住：没有一招鲜，业务测试说了算。

---

【面试题】3. Spring AI 的 Function Calling 工具调用，底层调度流程是怎样的？@Bean 注册的函数怎么被 LLM 识别？

【标准答案】 整个流程分五步：

第一步：函数注册。@Bean 标注的方法，Spring AI 自动扫描，提取方法名、参数、返回值类型。

第二步：Schema 生成。基于函数签名，自动生成 JSON Schema，告诉 LLM 这个工具能干啥、参数是啥格式。

第三步：模型决策。用户提问时，LLM 判断是否需要调用工具，返回 tool_call 类型的响应，包含函数名和参数。

第四步：Spring AI 执行。收到 tool_call 后，从 Spring 容器取出对应 Bean，用参数执行方法。

第五步：结果回填。执行结果作为 tool 类型消息追加到对话，LLM 基于结果生成最终回答。

关键点：开发者不用写任何 HTTP 调用代码，声明式注册，框架自动编排。这就是 Spring 风格：你写业务，框架管调度。

---

【面试题】4. VectorStore 接口统一后，PGVector、Redis、Pinecone 这些向量库该怎么选？各有什么适用场景？

【标准答案】 选型看三个维度：数据规模、查询延迟、运维成本。

PGVector：

• 适合：已有 PostgreSQL 基础设施，中小规模（百万级以下）
• 优势：零额外运维成本，ACID 事务支持，和业务数据同库
• 劣势：向量索引性能一般，超大规模会吃力

Redis：

• 适合：已有 Redis 集群，需要超低延迟（毫秒级）
• 优势：内存级速度，支持实时更新，适合高频写入场景
• 劣势：内存成本高，数据量受限于内存容量

Pinecone/Chroma/Milvus：

• Pinecone：全托管，零运维，适合快速上线，但成本较高
• Chroma：轻量级，适合 PoC 和小项目，单机部署
• Milvus：开源分布式，支持十亿级向量，适合大规模生产环境

我的建议：小项目用 PGVector 或 Chroma，中大规模用 Milvus，不想运维就 Pinecone。Spring AI 的好处是 VectorStore 接口统一，换个实现就改个配置，迁移成本低。

---

【面试题】5. Chat Memory 对话记忆在多轮对话中如何实现？InMemoryChatMemory 有什么坑？

【标准答案】 Spring AI 的 Chat Memory 分三层：

第一层：接口抽象。ChatMemory 接口定义了 add、get、clear 方法，核心是按 conversationId 管理消息历史。

第二层：Advisor 集成。MessageChatMemoryAdvisor 自动把历史消息注入到 Prompt，开发者不用手动拼接。配置方式：

ChatClient.builder(chatModel)
    .defaultAdvisors(new MessageChatMemoryAdvisor(chatMemory))
    .build();

第三层：持久化扩展。默认的 InMemoryChatMemory 只存内存，重启丢失。生产环境要自己实现持久化，存 Redis、MySQL 都行。

InMemoryChatMemory 的坑：

1. 内存泄漏：不主动清理，对话历史会无限增长，OOM 风险
2. 无持久化：服务重启，用户对话上下文全丢
3. 集群不共享：多实例部署时，用户请求打在不同实例上，记忆不连续

生产建议：实现一个 RedisChatMemory 或 JDBCChatMemory，设置过期时间，定期清理冷数据。

---

【面试题】6. Spring AI 多模型切换怎么配置？如果项目要同时支持 OpenAI 和国内模型（智谱、通义），架构怎么设计？

【标准答案】 Spring AI 用 spring.ai.* 配置前缀区分模型：

单模型配置：

spring:
  ai:
    openai:
      api-key: ${OPENAI_API_KEY}
      chat:
        options:
          model: gpt-4o

多模型并存：用 @Bean 手动注册多个 ChatModel：

@Bean
ChatModel openaiChatModel() { ... }

@Bean  
ChatModel zhipuChatModel() { ... }

架构设计建议：

1. 路由层：封装一个 ChatModelRouter，根据请求参数或用户配置选择模型
2. 降级策略：主模型超时自动切备用模型，保证可用性
3. 成本控制：简单问题用便宜模型（如 gpt-3.5），复杂问题用强模型

实际项目中，建议把模型选择逻辑抽成独立的 Service，配合配置中心动态切换。Spring AI 的抽象层已经做好了，上层业务只管依赖 ChatModel 接口，不用关心具体实现。

---

【面试题】7. BeanOutputConverter 在结构化输出时，有哪些常见的坑？怎么保证 LLM 输出符合 POJO 定义？

【标准答案】 BeanOutputConverter 很强，但有坑：

坑一：LLM 输出格式不稳定 LLM 可能返回多余的文字，或者 JSON 格式不完整。解决：Prompt 里明确要求"只返回 JSON，不要其他内容"，并用 responseFormat 强制 JSON 模式。

坑二：字段类型不匹配 LLM 返回 "age": "25"，但 POJO 是 int age。解决：用 String 类型兜底，或者加校验逻辑。

坑三：嵌套对象处理 复杂嵌套结构容易解析失败。解决：尽量扁平化 POJO，或者用 Map 接收后再转换。

坑四：必填字段缺失 LLM 没返回某个字段，解析直接报错。解决：POJO 字段用 Optional 或设置默认值。

最佳实践：

1. 用 @JsonProperty 和 @JsonPropertyDescription 给 LLM 提供字段描述
2. 结构化 Prompt：先给示例 JSON，再让 LLM 按格式输出
3. 加一层校验：解析后用 Validator 校验，不符合就重试

记住：LLM 不是数据库，输出有不确定性，防御性编程要到位。

---

【面试题】8. Spring AI 生产环境部署，API Key 怎么安全管理？超时、限流、熔断怎么配？

【标准答案】 生产环境要考虑三点：

API Key 管理：

• 禁止硬编码，用环境变量或配置中心（如 Vault、Consul）
• Spring Boot 用 ${OPENAI_API_KEY} 注入
• 敏感配置用 Jasypt 加密，或放在配置中心统一管理

超时配置：

spring:
  ai:
    openai:
      chat:
        options:
          timeout: 60s

LLM 响应慢，超时设长一点，建议 30-60 秒。

限流熔断： Spring AI 本身不内置，但可以集成 Spring Cloud Circuit Breaker 或 Resilience4j：

@Bean
ChatModel resilientChatModel(ChatModel delegate) {
    return new ResilientChatModel(delegate, 
        CircuitBreaker.ofDefaults("llm"));
}

限流用 Redis + Lua 脚本，或者网关层（如 Spring Cloud Gateway）统一限流。我的建议：LLM 调用成本高，做好限流，防止被刷爆；做好熔断，防止下游模型服务挂掉拖垮整体。

---

【面试题】9. Spring AI 的 Advisor 机制是什么？和 Spring AOP 有什么区别？实际项目中怎么用？

【标准答案】 Advisor 是 Spring AI 的拦截器机制，在请求前后做统一处理。

和 Spring AOP 的区别：

• AOP 是 Spring 核心能力，通用拦截任何 Bean 方法
• Advisor 是 Spring AI 特有的，专为 LLM 调用链设计，能访问 Prompt、响应、上下文

Advisor 的核心能力：

• 拦截请求：修改 Prompt、添加系统指令、注入记忆
• 拦截响应：后处理、日志、指标采集
• 链式编排：多个 Advisor 按顺序执行

实际应用场景：

1. 日志记录：记录请求响应，方便排查问题
2. 记忆注入：MessageChatMemoryAdvisor 自动加历史对话
3. RAG 增强：QuestionAnswerAdvisor 自动检索相关文档
4. 安全校验：敏感词过滤、权限校验

用法：

chatClient.prompt()
    .advisors(new LoggingAdvisor(), new MemoryAdvisor())
    .user("你好")
    .call();

Spring 风格的扩展能力：声明式注册，框架自动编排，业务代码无侵入。

---

【面试题】10. Spring AI 支持 MCP（Model Context Protocol）是什么意思？对构建 AI Agent 有什么帮助？

【标准答案】 MCP 是 Anthropic 推出的模型上下文协议，Spring AI 1.0 开始原生支持。

MCP 解决什么问题： LLM 应用要对接各种外部工具（数据库、API、文件系统），每个都单独写集成代码，成本高。MCP 统一了"工具接入"的标准协议，LLM 通过 MCP Server 访问资源，一套协议通吃。

Spring AI 的 MCP 支持：

• 可以让 Spring AI 作为 MCP Client，连接任意 MCP Server
• 也可以把 Spring AI 的 Function 包装成 MCP Server，给其他 LLM 应用调用

对 Agent 构建的帮助：

1. 工具复用：社区已经有现成的 MCP Server（如 GitHub、Google Drive、Slack），直接接入
2. 标准化：不用每个工具都写适配代码，遵循协议即可
3. 生态互通：Claude、OpenAI、本地模型都能用同一套 MCP 工具

实际项目中，Spring AI + MCP 可以快速搭建 Agent：用 Spring AI 做 LLM 编排，用 MCP 接入外部工具，专注业务逻辑，不用重复造轮子。这是 Spring AI 走向 Agent 生态的关键一步。

---

本轮题目覆盖：架构设计、RAG切分策略、Function Calling流程、向量库选型、对话记忆、多模型切换、结构化输出、生产部署、Advisor机制、MCP协议