大厂内容社区面试实录：从 Spring Boot 微服务到 AI RAG 问答（附详细解析）

大厂内容社区面试实录：从 Spring Boot 微服务到 AI RAG 问答（附详细解析）

---

一、故事背景：内容社区的 Java 面试

场景设定：

• 公司类型：互联网大厂，做 内容社区 + UGC + AIGC 推荐，类似「知乎 + 小红书 + AI 问答」的综合平台。
• 技术栈：以 Java + Spring Boot + Spring Cloud 为主，配合 Kafka、Redis、Elasticsearch、Docker/Kubernetes、Prometheus/Grafana、RAG 智能问答 等。
• 主角：
  • 面试官：P8 架构师，风格严肃、逻辑性强。
  • 候选人小Y：简历写满技术栈，看起来像"全会"，但其实有点"水货"，基础还行，复杂问题容易飘。

面试分 3 大轮，围绕一个"内容社区 + AI 问答"的业务场景，层层深入：

1. 第一轮：单体到 Spring Boot 微服务 & 基础能力
2. 第二轮：微服务拆分、消息队列、缓存 & 搜索
3. 第三轮：监控、链路追踪、CI/CD、以及 AI RAG 智能问答

对话结束后，文末给出 每个问题的详细标准答案 + 场景解析，适合小白系统学习。

---

二、第一轮：从用户发帖到基础服务设计

场景：一个类似「内容社区」的产品，用户可以发图文 / 视频内容、点赞、评论，后续还要接 AI 生成内容（AIGC）。

第一轮·问题 1：项目整体架构

面试官： 假设我们要做一个内容社区：用户注册登录、发帖、评论、点赞，还有基础推荐。你用 Java 技术栈，会怎么选型？整体架构大概怎么设计？

小Y： 嗯......我肯定用 Spring Boot ，再加上 Spring MVC 写接口。数据库嘛，就用 MySQL + MyBatis。

Redis 也要上，用来做缓存。日志的话，用 Logback + SLF4J 就够了。部署的话，可以用 Docker 打包一下，然后丢到 Kubernetes 上跑，这样就很微服务了。

面试官（点头）： 有一些关键点你提到了，但是整体架构还是比较零散，后面我会结合你的回答往下深挖。

---

第一轮·问题 2：接口设计与 Spring Boot 细节

面试官： 那我们以「发布帖子（图文）」为例，说一下：

1. 接口的 URL 和请求方式会怎么设计？
2. 用 Spring Boot + Spring MVC，大致会写出什么样的 Controller 代码结构？

小Y： 发布帖子嘛，一般是 POST 请求，比如 /api/post/create 之类的。

Spring Boot 的 Controller，我就这么写：

@RestController
@RequestMapping("/api/post")
public class PostController {

    @PostMapping("/create")
    public PostDTO create(@RequestBody CreatePostRequest request) {
        // 调用 service 保存
        return postService.create(request);
    }
}

差不多就这样，很简单。

面试官： 最基础的确实够用了，后面我会问你关于 验证、异常处理、链路追踪 等更完整的实践。

---

第一轮·问题 3：事务与数据库设计

面试官： 发布帖子时，我们需要往数据库写入帖子主表、帖子内容表，甚至还有标签表。你会如何设计数据库表？事务怎么保证？用什么技术栈？

小Y： 我就建一个 post 表，然后把标题、内容直接都放里面，简单好用。

事务的话，用 Spring + MyBatis ，在 Service 上加一个 @Transactional 注解，不出问题的。

面试官（略皱眉）： 你这个设计能用，但不太适合后续复杂功能，我们后面在答案解析里会展开。

---

第一轮·问题 4：简单登录与安全

面试官： 那用户登录这块，如果我们先不上复杂的 OAuth2，只做最简单的账号密码登录，你会用什么方案？

小Y： 就写个 /login 接口，然后查数据库，匹配账号和密码。然后用 JWT 生成一个 token 返回给前端。下次请求带上 token 就行。

面试官： JWT 方向是对的，那密码加密、token 校验、权限控制后面再追问。

---

第一轮·问题 5：单元测试

面试官： 你上面说的这些 Controller、Service，你平时会怎么写单元测试？用哪些测试框架？

小Y： 我都用 JUnit 5 ，有时候也用 Mockito。

比如 Controller，我就写个测试类，用 @SpringBootTest 跑起来，然后模拟发请求，看看返回是不是 ok。就差不多了。

面试官（轻轻笑）： 至少你知道要写测试，这一点值得肯定。那我们进入第二轮，聊聊微服务拆分、缓存和消息队列。

---

三、第二轮：微服务、缓存、消息队列与搜索

场景继续：内容社区用户量上升，要拆微服务、加缓存、引入消息队列和搜索引擎。

第二轮·问题 1：微服务拆分与 Spring Cloud

面试官： 用户量上来之后，你会怎么把这个内容社区从单体拆成微服务？参考 Spring Cloud 的体系，至少划分出哪些核心服务？注册发现和调用用什么？

小Y： 那肯定要拆成很多服务：

• 用户服务
• 帖子服务
• 评论服务
• 点赞服务
• 推荐服务

注册发现就用 Eureka ，然后服务间调用用 OpenFeign 就搞定了。

面试官： 拆的方向还不错，但缺少对 网关、配置中心、熔断限流 的考虑，后面答案里我会补充一个完整方案。

---

第二轮·问题 2：缓存与 Redis

面试官： 热门帖子详情访问很频繁，数据库压力很大。你用 Redis 做缓存，会怎么设计 key、多久过期？如何避免缓存击穿、雪崩和穿透？

小Y（略显犹豫）： 嗯......Redis 我一般就用 post:{id} 这种 key，过期时间随便 5 分钟吧。

缓存击穿嘛......可以加个互斥锁，避免很多请求同时打到数据库。雪崩就......呃......可以随机一下过期时间？穿透就......可以用布隆过滤器吧？

面试官（点头）： 概念基本知道，但你说得比较散，后面我会在解析里系统梳理一下。

---

第二轮·问题 3：Kafka 在内容系统中的应用

面试官： 用户发帖、点赞、评论这些行为，我们希望用于 异步计数、消息通知、推荐特征收集 。你会怎么用 Kafka 来做？设计几个 topic？消费策略如何？

小Y： Kafka 的话，我就弄一个 user-action 的 topic，把所有行为都发进去。然后消费端根据 action type 不同，做不同事情就好了。

消费策略嘛，反正就是多开几个 consumer，做成 consumer group，自动分区，多一点就快一点。

面试官： 思路有一点，但对 Topic 设计、幂等、顺序性、死信队列 这些没考虑清楚。稍后在答案里我会给出更落地的设计。

---

第二轮·问题 4：Elasticsearch 搜索

面试官： 我们的帖子需要支持搜索，比如按标题、内容、标签做检索。你会如何用 Elasticsearch 或 Spring Data Elasticsearch 来实现？索引怎么设计？和数据库如何保持一致？

小Y： 我会建一个 post_index 的索引，把帖子标题、内容都存进去。然后用 Spring Data Elasticsearch 定义一个 Repository，像查数据库那样用就行了。

数据一致性嘛......可以在新建帖子的时候，同时写库和 ES，就还可以吧。

面试官（摇头）： 同时写库和 ES 会有不少坑，尤其是失败重试、幂等等，答案解析里我会给出一个比较通用的方案。

---

第二轮·问题 5：接口文档与 Swagger/OpenAPI

面试官： 你们这么多微服务，API 怎么管理？你会用 Swagger/OpenAPI 吗？

小Y： 会的，会的，我在项目里一般用 Springdoc OpenAPI 或 Swagger，加注解就能生成接口文档，比如：

@Operation(summary = "创建帖子")
@PostMapping("/create")
public PostDTO create(@RequestBody CreatePostRequest request) { ... }

然后就能在 /swagger-ui.html 看到文档了。

面试官： 至少你用过，没问题。下面第三轮，我们聊聊监控、CI/CD，以及你简历里写的 AI RAG 问答。

---

四、第三轮：监控、链路追踪与 AI RAG 智能问答

第三轮·问题 1：监控与日志体系

面试官： 这么多服务，你怎么做监控与日志？请结合：

• 日志（Logback/SLF4J + ELK）
• 指标（Micrometer + Prometheus + Grafana）
• 链路追踪（Jaeger/Zipkin）

给我一个整体方案。

小Y： 日志就用 Logback + SLF4J 打日志，然后收集到 ELK 里，Kibana 查日志。

指标的话，用 Actuator ，它不是有 /actuator/prometheus 接口嘛，Prometheus 抓一下，然后 Grafana 展示。

链路追踪......我们可以用 Sleuth + Zipkin 吧，现在也可以上 OpenTelemetry 之类的，我了解得也不是特别细。

面试官： 有一些关键名词，说明你有接触，但缺乏整体设计意识。解析部分我会给出一个较完整的监控体系方案。

---

第三轮·问题 2：CI/CD 与灰度发布

面试官： 你们代码从提交到上线，怎么做 CI/CD？结合 Git、Jenkins 或 GitLab CI、Docker、Kubernetes 说一下。最好顺带讲讲灰度发布怎么做。

小Y： 我们一般是：

1. 开发提交代码到 Git；
2. 然后由 Jenkins 拉代码，执行 Maven 构建，打包成 jar；
3. 再用 Docker 打镜像，推到镜像仓库；
4. 然后部署到 Kubernetes 上。

灰度的话，可以把 Deployment 副本数调一下，一部分新版本，一部分旧版本......差不多是这样。

面试官： 流程还算顺，但对灰度/回滚策略讲得过于笼统，后面答案里我会补充。

---

第三轮·问题 3：AI RAG 问答在内容社区中的应用

重点来了：业务要引入 AI 问答功能，让用户基于社区内容进行智能问答与搜索。

面试官： 你简历上写了"熟悉 RAG、Agent、向量数据库 等 AI 技术"。现在公司要做一个「基于社区内容的 AI 问答」功能，大致要求：

1. 用户提问，系统从社区内容里检索相关帖子作为上下文；
2. 使用大模型生成回答，尽量减少幻觉；
3. 支持后续扩展成企业文档问答、智能客服。

你会怎么用 Java 生态里的技术来落地？比如 Spring AI、向量数据库（Milvus/Chroma/Redis）、Embedding、RAG 流程 等。

小Y（开始飘）： 嗯......RAG 就是 Retrieval-Augmented Generation 嘛，就是先检索再生成。

我们可以用 Spring AI 调一下 OpenAI 或者别的大模型，然后 Embedding 用 OpenAI 的模型，把帖子向量化丢到，比如说 Redis 里面吧，用作向量数据库......

然后用户问问题的时候，我们就把问句 Embedding 一下，在 Redis 里搜索最近的几个帖子，然后把帖子内容拼接到 Prompt 里，让大模型输出答案，这样就减少幻觉了......

至于 Agent 什么的，就是让模型调用工具之类的，比如再调用一下搜索接口，或者数据库 API......

面试官（稍微沉默）： 你说的方向大差不差，但细节非常模糊，比如：向量检索怎么做？如何做会话内存？怎么控制幻觉？怎么在业务里逐步接入？这些都没有说清楚。

我们最后一个问题，稍微轻一点。

---

第三轮·问题 4：接口稳定性与熔断限流

面试官： AI 接口一般比较贵，也可能很慢甚至失败。你会如何在 Java 微服务里对接这些 AI 接口，同时保证整体系统稳定？可以结合 Resilience4j、Spring Cloud Gateway 之类的说说。

小Y： 可以用 Resilience4j 做熔断、限流、重试......比如请求 AI 如果超时的话，就快速失败，走降级逻辑。

在网关那一层，比如用 Spring Cloud Gateway 或者 Zuul，也可以做限流，避免太多请求打到 AI 接口。实在不行就返回一个「稍后再试」啥的。

面试官： 好的，今天就先到这里。

---

第三轮结束

面试官（结束语）： 整体来看，你在基础部分还可以，复杂场景下的设计能力和实践经验比较欠缺。我们会在一两周内给你反馈，你先回去等通知吧。

小Y（苦笑）： 好，好的，谢谢老师......

---

五、面试题标准答案与详细解析

下面是上面所有问题的参考答案 + 场景解析，按照轮次整理，适合新人系统学习。

---

第一轮详解：从单体到基础服务

1. 整体架构与技术选型

业务场景：

• 用户注册登录
• 发图文/短视频帖子
• 点赞、评论
• 简单推荐流（按时间 + 热度）

推荐技术选型：

• 核心语言与平台 ：
  • Java 11 / 17（长期支持，性能与语法特性更好）
  • Spring Boot 2.x/3.x 作为应用骨架
• Web 层 ：
  • Spring MVC（同步接口）
  • 若后续有长连接/推送，可配合 WebSocket 或 Spring WebFlux
• 持久层 ：
  • 关系型数据库：MySQL
  • ORM：JPA/Hibernate 或 MyBatis
  • 连接池：HikariCP
  • 数据迁移：Flyway 或 Liquibase
• 缓存 ：
  • Redis（热点数据缓存、计数、会话等）
• 消息队列 ：
  • Kafka（行为日志、异步计数、推荐特征）
• 搜索与推荐 ：
  • Elasticsearch（搜索）
  • 初期推荐可以简单按热度 + 时间，不必一开始就上复杂算法
• 日志 & 监控 ：
  • 日志：SLF4J + Logback，集中到 ELK
  • 指标：Micrometer + Prometheus + Grafana
  • 链路追踪：OpenTelemetry + Jaeger/Zipkin
• 部署与运维 ：
  • Docker 容器化
  • Kubernetes 编排
  • CI/CD：Jenkins/GitLab CI/GitHub Actions

架构形态建议：

• 初期可以是 分层单体（Modular Monolith） ：
  • interface 层（Controller）
  • application 层（Service）
  • domain 层（领域模型）
  • infrastructure 层（持久化、消息、缓存）
• 随着业务发展，再逐步拆分微服务。

---

2. 发布帖子接口设计

接口设计建议：

• URL：POST /api/v1/posts
• 请求体：

{
  "title": "今天在地铁上遇到一件事......",
  "content": "具体内容......",
  "coverImageUrl": "https://...",
  "tags": ["职场", "通勤"],
  "type": "ARTICLE"  // 或 VIDEO
}

• 响应体：包含帖子 id、创建时间等。

Controller 示例要点：

@RestController
@RequestMapping("/api/v1/posts")
public class PostController {

    private final PostService postService;

    public PostController(PostService postService) {
        this.postService = postService;
    }

    @PostMapping
    public ResponseEntity<PostDTO> create(@Valid @RequestBody CreatePostRequest request,
                                          @AuthenticationPrincipal LoginUser user) {
        PostDTO result = postService.createPost(request, user.getId());
        return ResponseEntity.status(HttpStatus.CREATED).body(result);
    }
}

关键点：

• 使用 @Valid 做参数校验（结合 javax.validation 注解）。
• 从安全上下文中获取当前登录用户（Spring Security）。
• 返回 201 Created，符合 REST 语义。

---

3. 数据库设计与事务

数据表建议：

• post：帖子主表
  • id、user_id、title、type（图文/视频）、status、create_time、update_time
• post_content：帖子内容表
  • post_id、content（可为长文本）
• post_tag：标签表
  • id、name
• post_tag_rel：帖子-标签关联
  • post_id、tag_id

事务处理：

• 在 Service 层使用 @Transactional：

@Service
public class PostServiceImpl implements PostService {

    @Transactional
    public PostDTO createPost(CreatePostRequest request, Long userId) {
        // 1. 写 post
        // 2. 写 post_content
        // 3. 处理标签 & 关联
        // 若中间失败，整体回滚
    }
}

• 使用 JPA/Hibernate 或 MyBatis + HikariCP 作为持久化层。

---

4. 简单登录与安全

基本流程：

1. 用户注册时：
   • 密码使用 BCrypt 等算法加密存储，不要明文。
2. 登录接口：
   • 根据用户名查用户；
   • 使用密码加密算法验证；
   • 签发 JWT（内含用户 id、角色等信息），返回给前端。
3. 每次请求：
   • 前端在 header Authorization: Bearer <token> 传 JWT；
   • 后端通过 Spring Security 过滤器解析 JWT，建立认证上下文。

关键技术点：

• Spring Security：认证、授权框架
• JWT（JSON Web Token） ：无状态令牌，注意：
  • 令牌要有过期时间
  • 签名 key 要妥善保存
  • 对敏感操作可配合 redis 黑名单做 token 作废

---

5. 单元测试与测试框架

常见组合：

• 单元测试：JUnit 5 + AssertJ
• Mock：Mockito
• Spring 相关：@SpringBootTest、@WebMvcTest

示例：Service 层测试

@ExtendWith(MockitoExtension.class)
class PostServiceTest {

    @Mock
    private PostRepository postRepository;

    @InjectMocks
    private PostServiceImpl postService;

    @Test
    void createPost_shouldSavePost() {
        CreatePostRequest request = new CreatePostRequest("title", "content");
        when(postRepository.save(any(Post.class)))
            .thenAnswer(invocation -> {
                Post p = invocation.getArgument(0);
                p.setId(1L);
                return p;
            });

        PostDTO dto = postService.createPost(request, 100L);

        assertThat(dto.getId()).isEqualTo(1L);
    }
}

---

第二轮详解：微服务拆分、缓存与 MQ、搜索

1. 微服务拆分与 Spring Cloud

典型服务划分：

• 用户服务（user-service）：账号、资料、关系
• 内容服务（post-service）：帖子 CRUD
• 互动服务（interaction-service）：点赞、收藏、评论
• 搜索服务（search-service）：基于 ES 的搜索
• 推荐服务（recommendation-service）：Feed 流、个性化推荐
• 网关服务（api-gateway）：统一入口、鉴权、限流

基础组件（Spring Cloud & Netflix OSS）：

• 服务注册发现：Eureka / Consul
• 配置中心：Spring Cloud Config / Nacos
• 网关：Spring Cloud Gateway / Zuul
• 客户端调用：OpenFeign + Ribbon（或使用 Spring Cloud LoadBalancer）
• 容错：Resilience4j（替代 Hystrix）

调用示例：

@FeignClient(name = "user-service")
public interface UserClient {

    @GetMapping("/internal/users/{id}")
    UserDTO findById(@PathVariable("id") Long id);
}

---

2. Redis 缓存设计与三大问题

Key 设计：

• 帖子详情：post:detail:{postId}
• 帖子点赞数：post:likeCount:{postId}
• 热门列表：post:hot:list（ZSet）

过期策略：

• 热门帖子：短 TTL（如 5~10 分钟），且随机加减几分钟，避免集中失效。
• 不常变化的数据可以长 TTL 或不设置 TTL，配合后台刷新。

缓存三大问题处理：

1. 缓存穿透 ：大量访问不存在的数据
   • 解决：
     • 对不存在的 key 也写入短期空值
     • 使用 Bloom Filter 预过滤非法 id
2. 缓存击穿 ：某个热点 key 失效瞬间，大量请求打到数据库
   • 解决：
     • 互斥锁：只有一个线程去加载 DB，其余等待或返回旧值
     • 逻辑过期 + 后台异步刷新
3. 缓存雪崩 ：大量 key 同时失效
   • 解决：
     • 随机过期时间
     • 多级缓存（本地 Caffeine + Redis）
     • 热 key 提前续期或永不过期 + 后台刷新

技术实现：

• 使用 Spring Cache (@Cacheable)、Redisson 分布式锁、Caffeine 作为本地缓存。

---

3. Kafka 在内容系统中的使用

常见 Topic 设计：

• user-action-log：记录用户行为（view/like/comment/share）
• post-event：帖子创建/更新/删除
• notification-event：消息通知事件

典型消费场景：

• 行为日志用于：推荐特征、运营分析
• post-event 用于：
  • 搜索服务更新 ES
  • 计数服务更新统计

设计要点：

• 幂等：消费者处理消息时，要能根据业务主键去重（比如使用本地表记录已处理 offset 或使用业务 id）。
• 顺序性 ：对同一帖子相关的事件，可以将 partition key 设为 postId，保证同一帖子事件顺序消费。
• 死信队列 ：对于多次失败的消息，发送到 *-dlq 主题，人工或异步处理。

---

4. Elasticsearch 搜索与数据一致性

索引设计：

PUT post_index
{
  "mappings": {
    "properties": {
      "id": {"type": "keyword"},
      "title": {"type": "text", "analyzer": "ik_max_word"},
      "content": {"type": "text", "analyzer": "ik_max_word"},
      "tags": {"type": "keyword"},
      "createTime": {"type": "date"},
      "status": {"type": "keyword"}
    }
  }
}

与数据库同步的推荐方案：

• 写路径：

  1. 业务操作写 MySQL（强一致）
  2. 写成功后发送 post-event 到 Kafka
  3. search-service 订阅 post-event，异步更新 ES

• 好处：

  • 解耦业务写入与搜索系统
  • 通过重放 Kafka，支持重建索引

注意点：

• 要容忍 最终一致性（数据在极短时间内可能不在搜索结果中）。

---

5. Swagger/OpenAPI 管理 API

实践建议：

• 统一使用 Springdoc OpenAPI 生成 OpenAPI 3 规范。
• 每个微服务暴露自己的 API 文档，网关或文档服务统一聚合。

配置示例（Spring Boot 3）：

@OpenAPIDefinition(
    info = @Info(title = "Post Service API", version = "v1")
)
@SpringBootApplication
public class PostServiceApplication { }

---

第三轮详解：监控、CI/CD 与 AI RAG

1. 监控与日志体系

目标：

• 出问题能快速定位：哪台机器？哪个服务？哪条链路？
• 有数据支持容量规划与性能优化。

日志体系（ELK）：

• 应用：Logback + SLF4J 输出 JSON 格式日志
• 日志收集：Filebeat/Fluentd 收集 -> Logstash -> Elasticsearch
• 可视化：Kibana

指标监控：

• 应用：Micrometer + Spring Boot Actuator 暴露 /actuator/prometheus
• 指标：QPS、接口耗时、错误率、JVM 内存、GC 次数、线程数、连接数等
• Prometheus 抓取 -> Grafana 看板展示，设置告警

链路追踪：

• 使用 OpenTelemetry SDK，在每个服务中埋点
• 通过 B3 / W3C Trace Context 在 HTTP / MQ 调用中传递 traceId
• Jaeger 或 Zipkin 展示调用链

这样，用户一次请求从网关 -> 多个微服务 -> 数据库 / 缓存 / MQ 的完整路径都可视化。

---

2. CI/CD 与灰度发布

典型流水线：

1. 开发提交代码到 Git（GitLab/GitHub）
2. CI：
   • 触发 Jenkins/GitLab CI Pipeline
   • 步骤：
     1. 编译 & 单元测试（Maven/Gradle）
     2. 代码扫描（SonarQube）
     3. 打包 Jar
     4. 构建 Docker 镜像并推送到镜像仓库
3. CD：
   • 通过 Jenkins Pipeline 或 GitOps（Argo CD）更新 Kubernetes 部署
   • 使用 Rolling Update / Blue-Green / Canary 等策略

灰度发布（以 Kubernetes + Istio 为例）：

• 把新旧版本同时部署为两个 Deployment（v1、v2）。
• 使用 Istio/Service Mesh 或 Gateway 控制流量比例（如 5% -> 20% -> 100%）。
• 如果监控指标异常，自动或人工回滚到 v1。

---

3. AI RAG 智能问答方案

业务目标：

• 用户在内容社区提问，系统能够：
  1. 检索社区已有内容作为知识库；
  2. 调用大模型生成答案；
  3. 尽量减少纯幻想（AI 幻觉）；
  4. 可扩展到企业文档问答、智能客服。

整体架构：

1. 文档加载与拆分
   • 将帖子、文章、FAQ、文档等内容抽取出来
   • 使用分段算法（按段落、按长度）切成较短文本
2. 向量化（Embedding）
   • 调用 Embedding 模型（OpenAI、Ollama 等）生成向量表示
   • 使用 Java 客户端调用，比如通过 Spring AI 封装的客户端
3. 向量数据库
   • 存储在 Milvus/Chroma/Redis Vector 等
   • 记录：向量 + 原文 + 元信息（作者、时间、标签等）
4. 语义检索
   • 用户提问 -> Embedding -> 在向量库中做相似度搜索
   • 取 TopK 条最相关内容作为上下文
5. RAG 生成
   • 构造 Prompt：
     • 系统提示：你是某内容社区助手，只能基于提供的上下文回答
     • 上下文：检索到的帖子内容们
     • 用户问题
   • 调用大模型生成最终回答
6. 会话内存 & Agent 扩展
   • 对多轮对话，保存历史提问和摘要
   • Agent 可以在需要时调用工具：比如搜索接口、用户画像服务、知识库更新服务等

在 Java 中的落地（示意）：

• 使用 Spring AI 封装：
  • 配置大模型、Embedding 模型
  • 定义 RAG Chain（检索 + 生成）
• 使用 Redis + Redisearch 或 向量数据库 存储向量
• 通过 REST API 暴露 POST /api/v1/ai/ask 接口

减少幻觉的手段：

1. 检索质量 ：
   • 合理的分段粒度
   • 向量检索 + 关键词检索混合
2. 提示工程（Prompting） ：
   • 明确要求模型：如果上下文没有答案，要说「我不知道」
3. 引用原文 ：
   • 在回答中给出来源链接或片段，方便用户验证

---

4. 接口稳定性与 Resilience4j

对接外部 AI 接口常见问题：

• 延迟高、容易超时
• 调用成本高（需控制 QPS）
• 偶尔失败（网络、限流）

设计方案：

1. 在调用 AI 的 Service 层使用 Resilience4j ：
   • 超时控制：TimeLimiter
   • 重试策略：Retry
   • 断路器：CircuitBreaker
   • 限流：RateLimiter
2. 在网关层（Spring Cloud Gateway）：
   • 限流：基于 IP / 用户 id 限制 AI 问答 QPS
   • 认证：确保只有登录用户才能访问
3. 降级策略：
   • 当 AI 接口不可用时：
     • 返回基于搜索的结果
     • 提示用户稍后再试

---

六、小结：从业务到技术的思考路径

通过这场「内容社区 + AI 问答」的大厂 Java 面试，我们串联了：

1. 从 单体 Spring Boot 应用 到 Spring Cloud 微服务 的演进；
2. 数据库 + Redis 缓存 + Kafka + Elasticsearch 的协同；
3. 日志、监控、链路追踪、CI/CD、灰度发布 的工程化能力；
4. 如何将 RAG、向量数据库、Spring AI 等 AI 能力融入到 Java 业务系统中。

也可以看到，小Y 虽然会一些概念，但在：

• 系统性设计
• 边界条件处理
• 工程化落地 上仍有明显短板。

如果你是刚入门的 Java 开发，可以从本文的 答案解析 开始，一边看业务场景一边对照技术点，逐步形成自己的系统知识框架，这样下次面对类似的大厂面试，不至于像小Y那样只能「含糊其辞」。