企业官网建设流程全解析

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 搭过一套 RAG，FastAPI 起服务、自己管 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 的时候会细说。

流式这块我建议候选人一定要亲自写过一遍。它牵扯到响应式编程，Flux<String>的用法如果没接触过，面试的时候很容易露怯。而且实际生产环境中流式调用会带来额外的网关超时配置问题，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 List<String> splitIntoChunks(String text, int chunkSize, int overlap) { List<String> chunks = new ArrayList<>(); List<Integer> 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 给了一个很简洁的 API：

vectorStore.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(); List<Document> docs = vectorStore.similaritySearch(request);

这里有个参数之间互相制约的经验：TopK 和 similarityThreshold 要配合着调。TopK 设大了，可能召回一堆低相关度的内容，反而干扰模型；阈值设高了，可能一条都召不回，导致模型直接说不知道。我当时线上调参调到 TopK=5、阈值 0.5，对 FAQ 类问题的整体命中率不错。但这个值没有普适性，合成数据或者领域向量分布不同，参数差异会很大。

检索完成之后是 Prompt 组装。我放弃了对齐所有代码模板，而是直接用 Spring AI 的 Prompt Template 机制。在 resources 目录下建一个rag-prompt.st模板文件，内容大概是：你是一个知识库助手，请仅根据下面提供的参考资料来回答用户问题，如果参考资料中没有相关信息，请诚实回答不知道，不要编造。然后运行时通过PromptTemplate注入上下文和问题变量，生成完整的 Prompt。

这里有一个非常推荐的细节操作：把召回文档的元数据（来源文件名、章节）拼到 Prompt 里。大模型会把这个信息当作引用的依据，回答的时候会带上“根据某文档的说明”，用户体验会好很多。更重要的是，这能显著降低幻觉概率，因为模型知道自己的回答是有据可依的。我试过不加来源和加了来源的对照组，加了来源之后回答准确率体感提升了至少三成。

4. 常见问题与排查技巧实录

实战环节最容易翻车的不是模型调用，而是数据链路和工程配置里那些千奇百怪的问题。我把当时实操中遇到的典型问题整理成了一张速查表，后面按问题展开讲细节。

问题一：启动时提示找不到向量库相关 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，因为它能让 RAG 链路最先跑通、最少踩坑。等数据量真正到了千万级以上，或者检索性能成为瓶颈时，再去评估 Milvus 这类专用系统。工程上最忌讳一上来就上重型组件，一个还处于验证阶段的产品配上亿级向量库，运维成本直接吃掉研发效率。

5.2 索引类型、查询参数与召回率调优的实战总结

向量库调优比较关键的是索引类型的选择。pgvector 支持两种索引，IVFFlat 和 HNSW。我的建议是：数据量在百万级以内用 IVFFlat 足够，构建速度快、内存占用低；千万级以上用 HNSW，它是基于图的近似最近邻算法，查询延迟会更稳定，但构建时内存开销会明显增大。

HNSW 有个参数叫m，控制每个节点的最大连接数。m越大，召回率越高，但内存和构建时间也越高。ef_search控制查询时的探索范围，值越大召回越精确，但查询越慢。我当时调参的经验是：m=16是平衡点，ef_search=40在百万级数据集上能拉到 95% 以上的召回率。调参不能只看延迟，一定要结合召回率做评估。

另一个经常被忽视的点是，向量查询的并发模型。OpenAI 级别的 Embedding 接口有 QPS 限制，直接在主线程里逐条调用很容易触发限流。我当时用一个线程池做了批量并发提交，配合 Semaphore 做信号量控制，把 Embedding 吞吐量拉了近十倍，同时对模型接口保持礼貌。面试中能谈到 Embedding 吞吐优化，说明你已经对这个环节的瓶颈做过真实测量，这比背十个概念都管用。

5.3 混合检索与重排序的进阶实现

如果你的 RAG 系统处理的是包含代码、专有名词、长尾 ID 的技术文档，纯向量检索会遇到一个非常尴尬的问题：向量检索对语义相似的内容很敏感，但对精确的专有名词匹配很容易翻车。比如用户搜索“订单号 ABC123”，向量召回的结果可能全是“订单系统”的泛化描述，根本没有召回那条包含具体单号的记录。这时候直接拼一个关键词检索进去，形成混合检索（Hybrid Search），效果会有质的提升。

我用 Elasticsearch 做了并行通道的关键词检索，和 pgvector 的向量召回结果合并，然后用 RRF（Reciprocal 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 要设计成检索和生成两步。把这些问题想透了，面试官问什么你都不慌，做项目也不会跑偏。