Spring AI 这个方向这两年确实火得不行尤其是 RAG 和向量库一组合基本成了 Java 后端接大模型能力的标准玩法。我最近帮团队面了一批候选人也顺手整理了一套模拟面试题今天直接把这 10 道题连同我自己的踩坑经验一起分享出来。不管你是准备面试的求职者还是要搭建 RAG 服务的开发者这套题基本能把 Spring AI 的核心链路和向量库的实战细节都覆盖到。先说清楚这套题的筛选逻辑。我见过太多候选人简历上写着“熟悉 RAG”结果一问三不知连 Embedding 和向量检索的基本原理都说不清。所以我设计这 10 道题的时候刻意避开了那种“Spring AI 有哪些注解”的八股全部围绕真实的业务落地场景来出。从框架选型、RAG 流程设计、向量库调优到生产环境的坑一层层往里挖每一道题背后都对应着一个实际项目中必然要面对的技术决策。1. 内容整体设计与思路拆解Spring AI 这套东西本质上就是 Spring 官方为了解决 Java 生态里调用大模型时“各自为政”的问题而推出的抽象层。在它出现之前我们要接 GPT、接通义、接各种国产模型每个 SDK 的调用方式都不一样参数千奇百怪换一个模型供应商就得改一堆代码。Spring AI 做的事情很朴素把ChatClient、EmbeddingModel、VectorStore这些概念统一成标准接口就像 Spring Data 统一了数据库操作一样。你面向接口编程底层实现随时可以换。RAG 这个模式就更值得聊了。很多人把 RAG 理解成“把文档丢给大模型”这是最大的误解。RAG 的全称是 Retrieval-Augmented Generation核心在于“先检索再生成”。它的出现背景很直接大模型的训练数据有截止日期它不知道你公司的内部资料也不知道你产品的最新变更。你总不能每次提问都把整个知识库塞进上下文吧Token 限制放一边成本先炸了。所以 RAG 的思路是先把知识库拆成小块做向量化用户提问时先从向量库里召回最相关的片段再把这些片段作为上下文拼进 Prompt 送给大模型。模型不需要知道全部知识它只需要基于你给的材料进行回答。这套机制的工程价值在你真正做过一次之后才会体会得到。我最早用纯 Python 搭过一套 RAGFastAPI 起服务、自己管 Embedding、自己写向量检索功能是能跑但工程化太痛苦了。后来切到 Spring AI最大的感受是它的VectorStore抽象把向量数据库的差异屏蔽得很干净。你写业务代码的时候根本不用关心底层是 Redis 还是 PostgreSQL 的 pgvector反正都是add和similaritySearch两个核心操作切换实现类只需要改配置。面试题的设计思路也是围绕这套链路展开的。我不会问你“RAG 是什么”这种送分题而是直接问“如果用户问了一个知识库里没有答案的问题你怎么办”。这种问题没有标准答案考的是你对整个系统边界的理解。下面进入正题我把这 10 道题分成四个梯队基础概念、RAG 专项、向量库深入、生产实战大家按需取用。2. 核心细节解析与实操要点我们先从第一梯队开始聊。这部分题目看着简单但往往最能区分“用过”和“真正理解”的人。2.1 第一梯队Spring AI 基础与选型第一题Spring AI 相比直接在代码里调用 HTTP 接口对接大模型优势到底在哪很多人第一反应是“方便”“封装好了”但面试官想听的是更深层的东西。我实际用下来的体会是Spring AI 的价值有三层。第一层是接口统一你定义了一个ChatClientBean业务代码里注入使用底层是 OpenAI 还是通义千问对业务代码完全透明。第二层是异常体系它把模型限流、超时、网络错误这些常见问题统一抽象成了 Spring 的异常体系配合Retryable这类 Spring Retry 注解容错逻辑写起来非常干净。第三层是生态整合它和 Spring Boot 的配置体系、Actuator 监控、Spring Cloud 的链路追踪都是天然打通的这对 Java 后端团队来说是实打实的降本增效。我在项目里踩过一个坑就是刚开始没搞清楚ChatClient和ChatModel的区别直接在 Service 层注入了ChatModel导致后面想加流式响应、想加 Advisors 拦截器的时候代码改得很难看。正确做法是面向ChatClient编程它才是 Spring AI 从 1.0 版本开始主推的门面接口。ChatClient提供了流式调用、Prompt 定制、Advisors 扩展等一系列高阶能力而ChatModel只是最底层的模型调用抽象。候选人如果能主动提到这层区别我会明显加分。第二题Spring AI 的 ChatClient 支持哪些调用方式你在什么场景下会选流式这道题考的是对阻塞和非阻塞两种模式的理解。ChatClient的call()是同步阻塞适合内部系统调用、需要拿到完整结果再继续处理的场景比如生成周报文本、批量生成产品描述。stream()是流式返回适合面向用户的对话场景比如聊天机器人、智能客服需要打字机效果来提升用户体验。还有一个容易被忽略的chatClient.prompt().user(...).call().getContent()这种链式写法它其实是构建 Prompt 的标准姿势后面讲 Prompt Template 的时候会细说。流式这块我建议候选人一定要亲自写过一遍。它牵扯到响应式编程FluxString的用法如果没接触过面试的时候很容易露怯。而且实际生产环境中流式调用会带来额外的网关超时配置问题Nginx 默认 60 秒超时如果模型推理时间超过这个阈值前端就会断开连接。这些实战细节比语法本身重要得多面试时能主动提出来说明你真在线上跑过。第三题如果让你为团队选型Spring AI 和 LangChain4j 你会怎么选这个问题越来越常被问到因为 LangChain4j 在 Java 圈子里的声量也不小。我的真实观点是如果你的团队已经从 Spring Boot 构建服务那 Spring AI 的集成体验更平滑配置风格、Bean 管理、依赖注入都是熟悉的味道如果你的核心诉求是丰富的 RAG 链条组件和 Agent 编排能力LangChain4j 目前在某些模块上更成熟。但从 Spring 官方的投入力度和版本迭代速度来看Spring AI 的后劲明显更足。面试官其实还想听到你对“锁定风险”的判断。选任何框架都是有成本的关键看团队的技术栈和长期规划。如果只是做简单的问答机器人Spring AI 完全够用如果要做复杂的多智能体协作那可能要重新评估。候选人能说出这种取舍逻辑比单纯背对比表强得多。2.2 第二梯队RAG 核心链路进入 RAG 专项这是整个模拟面试的深水区。没有真正落地过 RAG 项目的人答这几道题的时候会露馅。第四题完整描述一下你用 Spring AI 实现 RAG 的全流程从文档导入到用户问答。这道题我给满分的答案长这样首先原始文档经过解析和清洗把 PDF、Word、Markdown 等格式统一提取成纯文本。接着做分块根据文档结构或固定 token 数把文本切成多个 chunk。第三步是 Embedding调用 Spring AI 的EmbeddingModel把每个 chunk 转成向量。第四步是把向量和原文一起存入VectorStore这一步会为向量建索引。用户提问时先把问题也转成向量然后在向量库里做相似度检索召回 TopK 个最相关的 chunk。最后把召回的 chunk 拼进 Prompt 模板连同用户问题一起交给ChatClient生成最终答案。这个流程本身不难背关键在于每个环节的细节。比如分块大小我实测下来 chunk size 在 500 到 800 个 token 之间、overlap 设 100 左右对大多数业务文档效果不错。chunk 太小语义容易被切断检索召回的内容可能不完整chunk 太大向量化的粒度太粗精确匹配度下降而且塞进 Prompt 的 Token 成本也上去了。这个平衡点要根据文档类型做实验法律合同和客服 FAQ 的最优参数完全不同。第五题RAG 的效果不好你会从哪些环节排查和优化这道题是我最喜欢问的因为 RAG 的优化链路太长答得好的人一定有实战经验。我的排查顺序是倒着来的先看结果如果回答出现了幻觉内容大概率是召回的相关文档质量不行不是模型的问题。那就去看向量检索的 TopK 结果到底是没召回相关内容还是召回了错误内容。没召回可能是分块切碎了语义或者 Embedding 模型与文档领域不匹配召回了错误内容可能是查询本身太模糊需要做查询改写或者向量检索的评分阈值设得太低。召回没问题但生成不好那就要优化 Prompt。我常用的技巧是给大模型明确的指令约束比如“仅基于提供的上下文回答不要补充未知信息”同时把召回内容的来源文档标识带进 Prompt让模型能给出引用来源。再往下还可以做重排序用 Cross-Encoder 模型对召回结果做一次精排把最相关的 Top2 提出来送进 LLM效果提升非常明显。这条链路全是经验活面试时能把一环扣一环地说清楚基本就能证明你真正调过一套 RAG 系统。3. 实操过程与核心环节实现下面这部分是我当初搭建一套完整 Spring AI RAG Demo 时的真实实操记录每个环节怎么选型、怎么配参数、怎么踩坑都写得比较细。这部分的颗粒度比面试题更落地可以直接拿去当一个最小可行方案的脚手架参考。3.1 搭建最小可用的 Spring AI RAG 服务先交代一下我当时的技术选型Spring Boot 3.4、Spring AI 1.0、开放平台的 Embedding 接口、pgvector 作为向量库。选 pgvector 的理由很简单团队里 PostgreSQL 已经是现成的不需要额外引入一套独立的向量数据库运维成本最低。如果是个人学习想快速上手也可以用 Redis 的向量检索能力但生产级推荐还是 pgvector 或者专门的向量库。依赖配置上面核心是在pom.xml里引入spring-ai-starter-model-openai这类 model starter再加上spring-ai-starter-vector-store-pgvector。Spring AI 的 starter 封装做得很不错引入之后只需要在application.yml里配置 API Key、Base URL、Embedding 模型名称一个可用的ChatClient和VectorStoreBean 就自动装配好了。这一步在本地跑通的时候你会觉得 Spring 的自动配置大法是真的省事。spring: ai: openai: api-key: ${AI_API_KEY} base-url: https://api.your-provider.com/v1 chat: options: model: your-chat-model-name temperature: 0.2 embedding: options: model: your-embedding-model-name一个比较关键的取舍是 temperature 参数。做 RAG 问答时我习惯把 temperature 调低到 0.2 左右因为我们需要模型忠实于检索到的上下文而不是自由发挥。如果做创意写作或者头脑风暴类场景temperature 可以调到 0.7 以上但知识问答场景下温度越低幻觉越少。向量存储这里有个容易忽略的点表结构不是你自己建的。Spring AI 首次启动时会自动在 PostgreSQL 里创建向量表。但注意一个细节如果后续要手动管理索引建议关掉自动建表用 Flyway 或者 Liquibase 来做版本管理。不然生产环境的表结构变更会非常痛苦这种数据库变更管理的问题在 Spring 生态里属于基本功面试问到的时候能提出来会很加分。3.2 文档处理与向量化的工程实现当时我处理的是一个混合格式的知识库有 Markdown 的技术文档有 PDF 的产品手册还有零散的 Word 立项材料。第一步是统一文本抽取。Markdown 直接用正则把正文取出来PDF 用的开源的解析库Word 用的 poi。这些工具单独都好用但组合在一起的时候要格外小心编码问题我印象很深的是有一次解析一个带图片的 Word 文档正文里的换行符被处理成了乱码入库的 chunk 质量极差。文本抽取完成之后是分块逻辑。我实现了一个简单的重叠分块器按 Token 数切块每块 600 Token相邻块重叠 120 Token。这样能保证一个语义完整的段落不会被从中间生硬切开。用 Token 而不是字符数的原因是大模型的上下文窗口是按 Token 计算的而 Embedding 模型也有 Token 上限用 Token 做单位更贴近模型的实际规格。代码逻辑大概长这样public ListString splitIntoChunks(String text, int chunkSize, int overlap) { ListString chunks new ArrayList(); ListInteger tokens tokenizer.encode(text); for (int i 0; i tokens.size(); i chunkSize - overlap) { int end Math.min(i chunkSize, tokens.size()); chunks.add(tokenizer.decode(tokens.subList(i, end))); if (end tokens.size()) break; } return chunks; }把 chunk 存入向量库之前我踩过一个很典型的坑忘了做文本清洗。原文里如果带着 Markdown 语法符号、HTML 标签或者无意义的空白字符Embedding 的质量会大打折扣。文本清洗没有统一的标准但至少要把控制字符、超长空白、重复的换行去掉。清洗完再分块、再向量化整个过程形成数据管线。面试的时候如果能主动聊到清洗环节说明你真的处理过脏数据。向量化完成后的入库操作Spring AI 给了一个很简洁的 APIvectorStore.add(ListUtils.zip(chunks, embeddings));这一行背后的逻辑是把 chunk 原文和对应的向量绑在一起连同元数据 Metadata 一起写入向量库。Metadata 的用途很广比如我可以给每个 chunk 打上文档来源、章节标题、更新日期后续检索的时候可以做条件过滤比如“只检索 2024 年之后更新的 FAQ”这种过滤能力在生产环境非常常用。3.3 查询链路与 Prompt 组装用户在页面输入一个问题之后查询链路会启动。第一步是把问题转换成查询向量用同一个EmbeddingModel来做这样才能保证用户问题向量和库里的文档向量处于同一语义空间。第二步是在向量库里执行相似度检索我用的 pgvector 执行的是余弦距离检索。Spring AI 的VectorStore.similaritySearch方法支持传一个SearchRequest对象可以设置返回条数 TopK 和相似度阈值。SearchRequest request SearchRequest.builder() .query(question) .topK(5) .similarityThreshold(0.5) .build(); ListDocument docs vectorStore.similaritySearch(request);这里有个参数之间互相制约的经验TopK 和 similarityThreshold 要配合着调。TopK 设大了可能召回一堆低相关度的内容反而干扰模型阈值设高了可能一条都召不回导致模型直接说不知道。我当时线上调参调到 TopK5、阈值 0.5对 FAQ 类问题的整体命中率不错。但这个值没有普适性合成数据或者领域向量分布不同参数差异会很大。检索完成之后是 Prompt 组装。我放弃了对齐所有代码模板而是直接用 Spring AI 的 Prompt Template 机制。在 resources 目录下建一个rag-prompt.st模板文件内容大概是你是一个知识库助手请仅根据下面提供的参考资料来回答用户问题如果参考资料中没有相关信息请诚实回答不知道不要编造。然后运行时通过PromptTemplate注入上下文和问题变量生成完整的 Prompt。这里有一个非常推荐的细节操作把召回文档的元数据来源文件名、章节拼到 Prompt 里。大模型会把这个信息当作引用的依据回答的时候会带上“根据某文档的说明”用户体验会好很多。更重要的是这能显著降低幻觉概率因为模型知道自己的回答是有据可依的。我试过不加来源和加了来源的对照组加了来源之后回答准确率体感提升了至少三成。4. 常见问题与排查技巧实录实战环节最容易翻车的不是模型调用而是数据链路和工程配置里那些千奇百怪的问题。我把当时实操中遇到的典型问题整理成了一张速查表后面按问题展开讲细节。现象可能原因排查手段启动报错找不到 VectorStore Beanstarter 依赖缺失或配置项未填检查 pom 依赖和 yml 配置检索结果为空向量未入库、阈值过高、Embedding 维度不匹配先验证库中数据量再调低阈值回答内容有明显幻觉召回质量差、Prompt 约束不足、temperature 过高优化分块和召回加强 Prompt 约束流式接口超时网关超时配置过短、模型推理慢调长超时时间或改用异步任务向量维度冲突切换了 Embedding 模型旧数据与新模型不兼容重新生成全部向量或统一模型版本Token 成本飙升chunk 过大、TopK 过多减少 chunk size 和 TopK加缓存问题一启动时提示找不到向量库相关 Bean。这个问题我遇到过一次原因特别基础spring-ai-starter-vector-store-pgvector依赖没引或者引了但url没有配。Spring AI 的自动配置对配置项要求很严格你缺一个关键配置它就直接不装配 Bean。遇到这种问题先别慌第一反应应该是去看启动日志里的 AutoConfiguration 相关报错信息它会直接告诉你缺了什么。这种问题学会看日志比死记配置项有效率得多。问题二向量检索一条都召不回。这个当时折腾了我两个小时。数据确实入库了向量也存进去了但查出来永远是空。后来我逐步排查发现Embedding 模型在入库时和查询时没有保持一致。因为项目里有两份配置代码里某处指定了 embedding 模型 A默认配置却指向了模型 B导致向量空间不一致语义距离计算完全没有意义。换回同一模型后重建向量索引检索立刻恢复正常。这个坑太典型了我后来每次切换模型都会先全局搜索一遍确认没有遗漏的旧配置。问题三回答牛头不对马嘴。这个问题基本都出在召回质量上。我当时测试业务问题时发现回答总是引用了无关文档打开召回记录一看Top5 里只有一条是相关的。原因是这个文档库很大不同主题的内容向量在空间里挤在一起余弦相似度区分度不够。我的解决办法是在分块时把文档类别信息写进 Metadata查询时利用filterExpression先按业务线过滤再在子集里做相似度检索。这个方案实施之后召回精准度提升了一大截。问题四生产环境首次请求极其缓慢。这是所有模型调用类应用都会遇到的问题。第一次请求要初始化模型客户端、建立连接池、加载各种资源所以响应时间会比后续请求慢出一个量级。我当时用了两种手段优化一是 Spring Boot 的启动预热应用启动完成后主动发起一次空调用触发模型客户端初始化二是给客户端配置连接池和超时避免每次请求都重建资源。这两种手段配到一起生产环境的首次延迟从 8 秒降到了 2 秒左右体验提升很明显。问题五相同的问题反复消耗 Token。如果用户问的问题在知识库里没有新增数据它的答案基本是一样的。每次重新调用模型既费钱又费时间我当时的优化思路是在查询链路前面加一层缓存。把用户问题的 Embedding 向量本身作为缓存的 key把模型答案存进 Redis命中之后直接返回。这个方案简单直接还能顺便记录哪些问题是高频问题反哺知识库建设。Session 级缓存和全局级缓存分开设计效果更好但这个属于进阶玩法了面试时能提出来会非常加分。5. 向量库选型与深度调优的复盘这部分单独拉出来讲因为向量库在整个 RAG 链路里承担的角色经常被低估。很多人觉得向量库就是存储和检索没什么技术含量但真正上了生产环境你就会发现选型和调优直接决定 RAG 的天花板。5.1 常见向量库的横向对比我当时做选型调研的时候维护过一张对比表今天也分享出来。这几种方案没有绝对好坏取决于你的团队技术栈和业务量级。方案优点缺点适用场景pgvector复用现有 PostgreSQL运维成本低支持 SQL 联合查询大数据量下性能弱于专用向量库中小规模、已有 PG 的团队Redis读写速度快生态成熟支持多种检索能力向量检索能力相对单一内存成本高高并发、低延迟的会话场景Milvus分布式架构支持亿级向量功能丰富部署运维重技术栈复杂大规模知识库、高吞吐生产环境Elasticsearch天然支持全文检索和向量检索混合内存和磁盘占用高调优复杂需要混合搜索能力的搜索系统内存向量库速度极快适合原型验证数据量受内存限制无法持久化开发调试、POC 阶段我给团队的建议是起步阶段无脑选 pgvector因为它能让 RAG 链路最先跑通、最少踩坑。等数据量真正到了千万级以上或者检索性能成为瓶颈时再去评估 Milvus 这类专用系统。工程上最忌讳一上来就上重型组件一个还处于验证阶段的产品配上亿级向量库运维成本直接吃掉研发效率。5.2 索引类型、查询参数与召回率调优的实战总结向量库调优比较关键的是索引类型的选择。pgvector 支持两种索引IVFFlat 和 HNSW。我的建议是数据量在百万级以内用 IVFFlat 足够构建速度快、内存占用低千万级以上用 HNSW它是基于图的近似最近邻算法查询延迟会更稳定但构建时内存开销会明显增大。HNSW 有个参数叫m控制每个节点的最大连接数。m越大召回率越高但内存和构建时间也越高。ef_search控制查询时的探索范围值越大召回越精确但查询越慢。我当时调参的经验是m16是平衡点ef_search40在百万级数据集上能拉到 95% 以上的召回率。调参不能只看延迟一定要结合召回率做评估。另一个经常被忽视的点是向量查询的并发模型。OpenAI 级别的 Embedding 接口有 QPS 限制直接在主线程里逐条调用很容易触发限流。我当时用一个线程池做了批量并发提交配合 Semaphore 做信号量控制把 Embedding 吞吐量拉了近十倍同时对模型接口保持礼貌。面试中能谈到 Embedding 吞吐优化说明你已经对这个环节的瓶颈做过真实测量这比背十个概念都管用。5.3 混合检索与重排序的进阶实现如果你的 RAG 系统处理的是包含代码、专有名词、长尾 ID 的技术文档纯向量检索会遇到一个非常尴尬的问题向量检索对语义相似的内容很敏感但对精确的专有名词匹配很容易翻车。比如用户搜索“订单号 ABC123”向量召回的结果可能全是“订单系统”的泛化描述根本没有召回那条包含具体单号的记录。这时候直接拼一个关键词检索进去形成混合检索Hybrid Search效果会有质的提升。我用 Elasticsearch 做了并行通道的关键词检索和 pgvector 的向量召回结果合并然后用 RRFReciprocal Rank Fusion算法做分数融合最后用一个 Cross-Encoder 重排序模型对融合结果做精排选出最相关的 Top5 送入 LLM。这个链路看着复杂但工程实现起来并不算困难每个组件都是现成的。而一旦接上系统的问答质量提升是肉眼可见的。面试时如果能把这段讲得头头是道基本就是高级岗位候选人的水平了。6. 面试延伸题从功能到生产级考量最后一道延伸题是我实战中特别看重、面试时也会反复追问的一类你的 RAG 服务怎么保证生产可用怎么监控怎么评估效果这类问题的核心考点其实不是你会不会用 Spring AI而是你有没有“系统化”的思维。一个完整的 RAG 服务光有问答链路远远不够。你需要一个可观测性方案把每次调用的 Prompt、召回文档列表、Token 消耗、响应耗时都记录下来。我当时用 Spring Boot Actuator 暴露了健康检查接口用 Micrometer 接了指标监控把模型调用的成功率和耗时都落到了监控面板上。效果评估方面我当时建了一套小型的评测集大约一百个问题每个问题标注了标准答案每次修改链路后跑一遍评测集用准确率和召回率两个指标做回归。这套评测体系帮我拦下了很多“改完 A 坏了 B”的回归问题。面试延伸的时候我还喜欢问候选人对“RAG 的局限”的理解。RAG 不是银弹它对检索质量的依赖非常高知识库本身的质量、查询的意图理解、分块策略都会影响最终效果。如果知识库里全是一堆过时的、互相矛盾的内容RAG 只会把这些错误忠实地送进上下文从而产生一个充满自信的错误回答。真正成熟的工程链路必须配套知识库的更新机制、内容的版本管理、回答质量的反馈闭环这三件套。这方面答得好不好能直接看出来这个候选人是做过深度思考的而不是仅仅跑过一个 Demo。聊到这里这套模拟面试题基本就讲完了。我个人在实际操作中最深的体会是不管面试还是做项目底层原理的扎实程度永远比花哨的工具链重要。Spring AI 和向量库都是容易上手的工具但真正决定项目成败的是你对数据链路的理解、对异常情况的预判以及面对生产环境问题时能不能冷静地分层排查。最后再分享一个小技巧准备面试的时候不要背题而是把每个问题背后的技术决策重新推演一遍比如为什么分块要重叠、为什么检索要用余弦相似度、为什么 RAG 要设计成检索和生成两步。把这些问题想透了面试官问什么你都不慌做项目也不会跑偏。