工作知识库

Appearance

Spring AI 面试题库 ​

生成时间：2026-05-23 16:17

【面试题】1. Spring AI中ChatModel和ChatClient有什么区别？实际开发中该怎么选？ ​

【标准答案】

这两个都是调用大模型的核心接口，定位不同。

ChatModel是底层抽象，直接对应一个具体的模型实例，比如OpenAI的gpt-4、Anthropic的claude-3。它是"一个模型一个Bean"的概念。你调用它的call方法，就是直接跟这个模型对话，简单直接。

ChatClient是Spring AI 1.0推荐的统一入口，是Fluent API风格。它内部封装了ChatModel，但加了更多能力：Advisor链、ChatMemory、工具调用等。代码写起来更优雅，像builder模式一样链式调用。

实际选型：简单场景用ChatModel足够，一行代码搞定；复杂场景（需要对话记忆、工具调用、RAG）用ChatClient，架构更清晰。我的习惯是新项目统一用ChatClient，省得后期重构。

【面试题】2. Spring AI的Advisor机制是什么？有什么实际用途？ ​

【标准答案】

Advisor是Spring AI的拦截器模式，作用类似Spring MVC的HandlerInterceptor。

核心思路：每次对话前后插入自定义逻辑。比如：

  • MessageChatMemoryAdvisor：对话前从内存加载历史消息，对话后保存新消息
  • QuestionAnswerAdvisor：对话前检索向量库，把相关文档塞进Prompt
  • 自定义Advisor：加日志、限流、敏感词过滤

链式执行，顺序可控。我在项目里做过一个Advisor，对话前先调风控接口，拦截敏感问题，避免模型乱回。

使用方式：ChatClient.prompt().advisors(advisor1, advisor2).call()，配置简单，职责解耦。

【面试题】3. 如何用Spring AI实现一个完整的RAG流程？关键步骤有哪些？ ​

【标准答案】

RAG = 检索增强生成，核心是让模型"先查资料再回答"。

完整流程四步：

  1. 文档切分：TokenTextSplitter把长文档切成小块，参数设置chunkSize和overlap，避免语义断裂
  2. 向量化存储：EmbeddingModel把文本转成向量，存进VectorStore（PGVector、Milvus等）
  3. 相似度检索：用户提问时，用vectorStore.similaritySearch(queryEmbedding, k)找出最相关的k条文档
  4. 增强生成：把检索结果拼进Prompt，让模型基于资料回答

Spring AI的实现很简单：

java
ChatClient.builder(chatModel)
    .defaultAdvisors(new QuestionAnswerAdvisor(vectorStore))
    .build()
    .prompt()
    .user(question)
    .call();

QuestionAnswerAdvisor自动完成步骤3和4，一行代码搞定RAG。

关键点：chunk大小影响检索精度，overlap防止语义截断；向量库选型看数据量，小项目PGVector够用，大规模上Milvus。

【面试题】4. Spring AI支持哪些VectorStore？选型时怎么考虑？ ​

【标准答案】

主流的有这些：

  • PGVector：基于PostgreSQL，部署简单，适合中小规模，已有PG的项目直接复用
  • Redis：内存级速度，支持向量+结构化混合查询，适合实时性要求高的场景
  • Milvus：分布式架构，支持十亿级向量，高性能，适合生产级大规模应用
  • Chroma：轻量级，适合开发测试，生产环境不推荐
  • Pinecone：全托管服务，免运维，但海外服务，合规项目慎用

选型考虑三个维度：

  1. 数据量：<百万级PGVector或Redis，>百万级考虑Milvus
  2. 运维成本：有运维团队可自建，没有选Pinecone或云服务
  3. 查询复杂度：纯向量检索都行，需要混合过滤（向量+metadata）优先Redis或Milvus

我的经验：POC阶段用Chroma快速验证，生产上用PGVector（数据量可控）或Milvus（大规模），合规项目不碰海外云服务。

【面试题】5. Spring AI的Function Calling怎么实现？整个流程是怎样的？ ​

【标准答案】

Function Calling让模型能够"调用工具"，比如查天气、调数据库、调API。

实现步骤：

  1. 定义函数：写一个普通方法，加@Bean注解注册到Spring容器
java
@Bean
public Function<Request, Response> weatherTool() {
    return request -> weatherService.query(request.city());
}

  1. 自动注册：Spring AI扫描@Bean函数，自动生成JSON Schema，包含参数类型、描述、必填项

  2. 调用流程：

    • 用户提问"北京天气"
    • 模型返回tool_call（函数名+参数）
    • Spring AI自动执行函数
    • 函数结果返回给模型
    • 模型生成最终回答

整个过程是自动的，开发者只需定义函数，Spring AI搞定调度。关键点：函数签名要清晰，参数类加@Description注解，模型才能准确传参。

【面试题】6. BeanOutputConverter怎么用？有什么常见坑？ ​

【标准答案】

BeanOutputConverter用于把模型输出转成Java对象，底层是JSON Schema约束。

使用方式：

java
BeanOutputConverter<User> converter = new BeanOutputConverter<>(User.class);
String schema = converter.getFormat(); // 生成JSON Schema
String response = chatModel.call(prompt);
User user = converter.convert(response); // 解析成对象

更简单的是用entity()：

java
User user = chatClient.prompt()
    .user("提取用户信息：张三，25岁")
    .call()
    .entity(User.class);

常见坑：

  1. Schema太复杂模型不遵守：嵌套层级深的对象容易解析失败，建议扁平化设计
  2. 字段命名不一致：JSON的snake_case和Java的camelCase不匹配，加@JsonProperty注解
  3. 必填字段缺失：模型可能漏字段，实体类字段尽量给默认值或用Optional
  4. 数组解析失败：List字段容易出问题，Schema里要明确定义items类型

经验：简单对象用BeanOutputConverter，复杂嵌套对象建议先让模型返回JSON字符串，再用Jackson手动解析，更可控。

【面试题】7. Spring AI的ChatMemory怎么实现对话记忆？生产环境怎么持久化？ ​

【标准答案】

ChatMemory是对话历史的存储接口，实现类有：

  • InMemoryChatMemory：内存存储，重启丢失，适合开发测试
  • 自定义持久化：实现ChatMemory接口，对接数据库或Redis

使用方式：

java
ChatMemory memory = new InMemoryChatMemory();
MessageChatMemoryAdvisor advisor = new MessageChatMemoryAdvisor(memory);

chatClient.prompt()
    .advisors(advisor)
    .user("你好")
    .call();

MessageChatMemoryAdvisor自动管理历史消息，每次对话前加载，对话后保存。

生产持久化方案：

  1. Redis存储：每个会话一个key，设置TTL自动过期，适合高并发
  2. 数据库存储：设计conversation_id、message_id、role、content表结构，支持查询审计
  3. 混合方案：热点会话放Redis，历史归档到数据库

关键点：对话历史不能无限增长，设置maxHistorySize限制条数，避免token超限。我的做法是保留最近20轮，更早的定期压缩或删除。

【面试题】8. Spring AI如何实现多模型路由？配置上要注意什么？ ​

【标准答案】

多模型路由是实际项目的刚需，比如：GPT-4处理复杂推理，Claude处理长文本，本地Ollama处理敏感数据。

实现方式：

  1. 配置多个ChatModel Bean：
java
@Bean
ChatModel openai() { return new OpenAiChatModel(openaiConfig); }
@Bean
ChatModel ollama() { return new OllamaChatModel(ollamaConfig); }
  1. 路由策略：
    • 按业务路由：不同Controller注入不同ChatModel
    • 按负载路由：自定义Router根据压力选择模型
    • 按能力路由：复杂问题走GPT-4，简单问题走便宜模型

配置注意：

  1. spring.ai.*前缀：Spring AI 1.0统一用这个前缀，不同模型用不同namespace：

    • spring.ai.openai.api-key
    • spring.ai.ollama.base-url
    • spring.ai.anthropic.api-key

  2. 动态切换：不要写死模型名，用配置中心或数据库管理，方便热切换

  3. Fallback机制：主模型挂了自动切备用模型，用Resilience4j实现熔断降级

【面试题】9. Spring AI 1.0相比之前有哪些重要更新？迁移时要注意什么？ ​

【标准答案】

Spring AI 1.0是正式版，架构和API都有大调整。

核心更新：

  1. ChatClient统一入口：之前ChatModel直接用，现在推荐ChatClient，Fluent API更优雅
  2. Advisor架构：之前是零散的拦截逻辑，现在统一成Advisor链，扩展性更强
  3. VectorStore接口统一：不同向量库实现统一接口，切换成本低
  4. spring.ai.*配置前缀：配置规范化，之前是spring.ai.openai.key，现在统一spring.ai.openai.api-key
  5. Observability内置：集成Micrometer，开箱即用的监控指标

迁移注意：

  1. API变化：ChatModel.call(prompt)还能用，但推荐迁移到ChatClient
  2. 配置调整：检查application.yml，把老配置改成新前缀
  3. 依赖升级：spring-ai-core版本号从0.x改到1.0.0
  4. 测试覆盖：API改动较多，迁移后务必跑全量测试

我的建议：新项目直接上1.0，老项目逐步迁移，先升级依赖+改配置，API迁移分批进行。

【面试题】10. Spring AI生产环境怎么做监控和故障排查？ ​

【标准答案】

生产环境监控分三层：

1. 基础指标（Micrometer）：

  • 请求量、成功率、响应时间（P50/P95/P99）
  • 模型调用耗时、Token消耗统计
  • VectorStore检索延迟

Spring AI 1.0内置支持，只需：

yaml
management:
  endpoints:
    web:
      exposure:
        include: prometheus,health

2. 日志追踪：

  • 每次对话记录request_id，关联用户、模型、耗时、Token数
  • Advisor链路日志，定位是哪个环节出问题
  • 错误日志要包含原始Prompt，方便复现

3. 告警机制：

  • 模型调用失败率>5%告警
  • 响应时间>P95阈值持续5分钟告警
  • Token消耗异常增长告警（可能是被刷）

常见故障排查：

  • 模型超时：检查网络、调整超时配置、加降级策略
  • Token超限：压缩Prompt、限制历史消息条数、换长上下文模型
  • 向量检索慢：检查向量库索引、增加副本数、优化查询参数
  • 内存泄漏：ChatMemory未清理、长会话堆积，定期清理过期会话

经验：上线前先压测摸清瓶颈，生产上留足buffer，模型服务不稳定时要能快速切备用。