大厂 Java 面试实录：从音视频内容社区到 AI RAG 的全链路技术设计

场景：互联网大厂音视频 + 内容社区业务线 Java 面试。主角：严肃的面试官 & 搞笑又有点水的候选人——小 Y。

---

一、第一轮：基础业务与整体架构设计

业务背景：做一个类似「短视频 + 图文内容社区」的 App，支持推荐流、关注流、评论、点赞、收藏、搜索等，后续还要接入 AIGC 自动生成内容。

Q1：整体系统架构如何设计？用到哪些 Java 技术栈？

面试官： 我们先从整体出发。如果让你设计一个短视频 + 图文的内容社区系统，你会怎么做整体架构？重点说说你会用什么 Java 技术栈，以及为什么这么选。

小 Y： 这个…整体上肯定是微服务嘛，用 Spring Boot 和 Spring Cloud 搭一套就行了。前面放个网关，用 OpenFeign 调服务，注册中心用 Eureka 或者 Nacos，负载均衡嘛…反正 Spring Cloud 全家桶都可以。数据库就 MySQL，缓存用 Redis，MQ 用 Kafka。日志就 Logback 吧，监控可以上 Prometheus 和 Grafana。大概就这样。

面试官： 微服务 + Spring Cloud 的方向还可以，但你说得太「云」了，业务拆分和关键组件选型都没展开，下次回答的时候要把「系统划分 + 组件职能」说清楚。这个问题先往下，我们后面再细抠。

---

Q2：你会怎么划分微服务？和业务功能怎么对应？

面试官： 那具体到业务，你会怎么拆服务？比如用户、内容、推荐、搜索、互动这些，你打算怎么拆，为什么这么拆？

小 Y： 这个…就按业务名拆嘛。用户服务、内容服务、评论服务、点赞服务、搜索服务、推荐服务、支付服务、通知服务……然后再搞个网关服务，呃，还有…嗯，差不多就这些。

面试官： 按业务名拆是一种直觉，但你要体现出职责边界和数据边界，以及访问路径。你刚才只是列了个清单。等会儿我们会在答案里详细给出一个拆分示例，你回去要多练习「从入口 → 业务流程 → 服务调用」这条线。

---

Q3：短视频上传和播放链路你会怎么设计？涉及到哪些组件？

面试官： 我们聚焦到「音视频」场景：用户上传一个短视频，到其他用户可以流畅播放，中间会经过哪些步骤、涉及哪些服务？你可以简单说一下链路。

小 Y： 呃…用户上传视频到后端，后端存一下，然后…再给个播放地址。中间可能会转码吧，用个任务队列，转码完了就可以播放了。组件的话，就 Spring Boot 写个上传接口，Kafka 发个消息，然后有个转码服务消费消息，处理完后写数据库…具体嘛，我实习的时候看过类似的。

面试官： 有点印象，但是漏了不少关键点，比如存储选型、CDN、元数据管理等。没关系，后面答案会展开，让你有一个比较完整的音视频链路概念。

---

Q4：在高并发下，如何保证内容详情页的性能？

面试官： 热门视频/图文内容详情页如果被高频访问，你会怎么优化性能？会用到哪些缓存方案？

小 Y： 这个我知道，用 Redis 缓存！可以用 Spring Cache 或者直接用 RedisTemplate，把内容缓存到 Redis 里，然后加上过期时间…呃，还可以用本地缓存，比如 Caffeine 做个二级缓存，减少 Redis 压力。热点数据就多缓存一下。

面试官： 这个回答就比较具体了，提到 Redis + Caffeine 的多级缓存就不错，也知道 Spring Cache。后面我们会在答案里帮你补充缓存穿透、击穿、雪崩的一些手段。

---

Q5：接口如何对外暴露？REST API 怎么管理？

面试官： 那这些服务对外的接口你打算怎么管理？比如版本、文档、测试联调？

小 Y： 一般就是写 REST 接口，用 Spring MVC 或 Spring WebFlux 做 Controller，然后用 Swagger…嗯，现在叫 OpenAPI 规范，自动生成接口文档。对外可以统一从网关暴露，像 Spring Cloud Gateway 或者 Nginx 也行。版本的话，在 URL 里加 /v1 /v2，或者用 Header 搞一下。

面试官： 这个还可以，基本点都算答到了。

---

二、第二轮：可靠性、监控与消息队列

业务继续：系统用户量上来了，活动期间有大流量，要求高可用、可观测、可回溯。

Q6：微服务之间调用失败怎么处理？如何做熔断限流？

面试官： 微服务之间总会有失败，你会怎么保证整体的稳定？比如推荐服务依赖用户画像服务，如果用户画像挂了怎么办？

小 Y： 这个用…以前 Netflix OSS 里的 Hystrix，现在不太用了，可以用 Resilience4j 做熔断和限流。比如服务调用失败到一定阈值，就打开断路器，走降级逻辑。限流的话，可以在网关做，也可以用令牌桶之类的算法。整体就这些吧。

面试官： 方向对，能说出 Resilience4j 已经不错。不过你没提到具体降级策略，比如推荐可以退化成通用热门榜。等会儿在答案里我们帮你补全一个比较完整的思路。

---

Q7：你会怎么设计消息队列在系统中的作用？Kafka 怎么用？

面试官： 刚才你说短视频转码用 Kafka。整个内容社区系统中，你还会在哪些场景用消息队列？Kafka、RabbitMQ、Redis Pub/Sub 你会怎么选？

小 Y： 消息队列的话…呃，像点赞、收藏这些可以异步写统计，用 Kafka 发消息给统计服务。通知推送也可以用 MQ。Kafka 适合高吞吐日志、行为埋点那种；RabbitMQ 适合业务消息比较复杂的确认和路由；Redis Pub/Sub 就简单通知用用。我之前项目里主要用 Kafka，其他就…了解。

面试官： 对 Kafka 的定位算是说到了，但和业务场景的结合还是略泛。后面我们会给出一个「内容社区里的 MQ 使用清单」，让你更有画面感。

---

Q8：监控与日志怎么做？如何定位线上问题？

面试官： 大厂很看重可观测性。如果你的系统线上出现接口超时、报错，你会用哪些工具去排查？你会怎么埋点和打日志？

小 Y： 监控的话，可以用 Micrometer 把指标暴露给 Prometheus，然后在 Grafana 上画看板。日志就用 Logback 结合 SLF4J，输出到 ELK（Elasticsearch + Logstash + Kibana）里，方便检索。链路追踪可以用 Zipkin 或 Jaeger，通过 traceId 关联请求链路。排查问题就看错误日志、慢查询、接口耗时分布之类。

面试官： 这个回答比较完整，工具链也成体系了，说明你对观测这块有一定了解。

---

Q9：数据库层如何保证高可用与数据一致性？

面试官： 我们说说数据库：内容数据、用户数据、互动数据非常多，你会用什么方案保证高可用和数据一致性？顺便说说你对 ORM 和连接池的选型。

小 Y： 数据库高可用可以用主从、读写分离，再加上分库分表之类… 一致性嘛，重要操作尽量用事务…比如 Spring 事务 + JPA 或 MyBatis，隔离级别就…默认就行吧。连接池可以用 HikariCP，比 C3P0 快。ORM 就 Hibernate、JPA、MyBatis，看项目情况选。

面试官： 你显然对这块没太深入思考。事务的隔离级别、分布式事务、热点库表这些都没提到。不过至少你知道 HikariCP、JPA、MyBatis，说明用过。详细的设计我们在文末答案里展开，你回去好好看。

---

Q10：如何做接口灰度发布与回滚？

面试官： 系统迭代很快，你怎么做灰度发布？比如新版本推荐算法上线，只让 5% 的用户先用，出问题能快速回滚？

小 Y： 灰度的话，可以通过 Kubernetes 滚动发布，用 Jenkins 或 GitLab CI 做 CI/CD，然后在网关按用户 ID 或标签做流量分配…呃，或者用 Nginx 做。回滚就…把 Deployment 回滚到上一个版本，或者重新部署旧版本镜像。配置可以用 Spring Cloud Config 或 Nacos 管理。

面试官： 思路还算 OK，但缺少细化，比如灰度标识、埋点指标、回滚策略。待会儿答案里会有一个「灰度发布小模板」，可以直接记下来。

---

三、第三轮：接入 AIGC & RAG 能力

业务升级：内容社区要引入 AI 能力。包括：

• 帮创作者生成标题、文案、标签（AIGC）
• 为用户提供智能问答和搜索（RAG + 语义检索）
• 对内容进行风控审查（AI+规则引擎）

Q11：如何为内容社区接入 AIGC 生成功能？

面试官： 产品经理说，创作者上传视频后，希望自动生成标题、文案、标签，辅助创作。你会怎么从后端架构上设计这一块？可以涉及到 Spring AI、RAG、向量库等。

小 Y： 嗯…那就搞一个 AI 服务吧，单独一个微服务。然后…用 Spring AI 调 OpenAI 或者其他模型接口，拿到结果。传进去视频的字幕或者文案，模型输出标题和标签。向量库的话也可以用，比如 Redis 或者 Milvus，存一些东西…大概这样。

面试官： 你知道要抽象出 AI 服务，这个方向对。但你提到 RAG 和向量库的时候明显有点虚。RAG 怎么和「创作辅助」挂上关系，你没讲明白。后面答案会给一个典型的接入流程。

---

Q12：什么是 RAG？在内容社区里怎么用？

面试官： 那你说说 RAG 是什么？在我们这个内容社区场景里，有哪些具体可落地的玩法？

小 Y： RAG…是检索增强生成，Retrieval-Augmented Generation。先检索文档再让大模型回答。内容社区的话…可以让用户问问题，然后从内容库里检索相关视频和文章，再让模型生成回答，就类似智能搜索吧。呃，具体的话…可以用向量数据库做语义检索，用 Embedding 模型，比如 OpenAI 的，或者本地 Ollama，那种…

面试官： 这次说得还不错，基本定义和大致玩法都有了。后面我们会补充一个 RAG 流程图（文字描述版），你可以记下来用在别的面试上。

---

Q13：如何实现语义搜索和向量化？技术链路如何？

面试官： 如果要做「视频 / 图文内容的语义搜索」，不只是关键词匹配，你会怎么设计向量化和检索的链路？

小 Y： 这个…就是把内容文本用 Embedding 模型向量化，存到 Milvus 或者 Chroma、Redis 里。搜索的时候，把用户的查询也向量化，然后去算相似度，取 TopK 结果，再返回给用户。后端流程就差不多。怎么落地嘛…可以写个服务，呃，用 Spring Boot 写。

面试官： 核心步骤你说到了，就是有点「只会背公式」。文末我们会给一个更贴近工程实践的设计，包括数据更新、增量向量化等。

---

Q14：Agentic RAG 和普通 RAG 有什么区别？在复杂工作流怎么用？

面试官： 我们这条业务线最近在做「智能客服系统」，需要支持复杂工作流，比如：先根据用户问题检索文档，再调用内部工具查询订单，最后帮用户发起退款申请。你理解的 Agent 或 Agentic RAG 是怎么回事？怎么和工具调用结合？

小 Y： Agent…就是让模型更智能一点，它可以自己决定下一步干嘛。Agentic RAG…就是在 RAG 的基础上，再加上工具调用吧。比如模型可以先检索知识库，再决定要不要调用查询订单的接口，然后再生成回答。工具调用有 MCP、还有…Google 的什么东西…我有点忘了，反正就是标准化模型和工具的交互。

面试官： 虽然有点含糊，但至少知道「RAG + 工具调用 + 决策」这几个关键词，也知道 MCP 这种模型上下文协议。具体工程化落地你还不太清楚，文末会有一节专门讲。

---

Q15：如何减少 AI 幻觉（Hallucination），保证回答可靠？

面试官： 在企业文档问答、客服、医疗类问答里，AI 幻觉是个大问题。你觉得后端在设计时，可以从哪些方面降低幻觉风险？

小 Y： 呃…这个…可以用 RAG 嘛，让模型有文档可参考就不乱编了。然后…可以在提示词里强调不要乱编…还有可以在回答里加引用来源。要是很重要的场景，可以让人审核一下，或者给出多个备选。具体怎么设计…

面试官： 你知道几个关键手段，比如 RAG、提示词约束、引用来源、人工审核，但没形成体系。最后的答案部分会给你一套「降低幻觉的清单」，你照着背也能应付大多数面试。

---

四、面试结束话术

面试官： 今天先面到这里。整体看，你的基础还可以，但在系统设计和 AI 落地这块还比较泛，很多点只停留在「听说过」。我们会综合评估一下，你先回去等通知吧。

小 Y（心里 OS）： 完了完了，又是「回去等通知」…

---

五、详细解析：从零拆解业务场景与技术点

下面是对上面问题的系统化答案与延展说明，按模块整理，方便小白学习和有经验的人查漏补缺。

---

1. 整体架构设计与微服务拆分（对应 Q1、Q2、Q3、Q5）

1.1 业务场景

• 类似抖音 / 小红书的短视频 + 图文内容社区
• 场景包括：
  • 视频上传、转码、审核、发布、播放
  • 内容流（推荐流 / 关注流）、评论、点赞、收藏
  • 搜索与话题、标签体系
  • 后续接入 AIGC（标题/文案生成）与智能搜索（RAG）

1.2 技术栈总览

• 核心：Java 17 + Spring Boot 3.x
• Web：Spring MVC（主接口），少量高并发场景可用 Spring WebFlux
• 微服务：Spring Cloud Alibaba / Spring Cloud + OpenFeign + Gateway
• 注册 / 配置：Eureka / Consul / Nacos + Spring Cloud Config
• 构建：Maven（主）、Gradle（部分服务也可）
• 数据：
  • 业务数据：MySQL / PostgreSQL + MyBatis / Spring Data JPA
  • 内容索引：Elasticsearch
  • 时序数据 & 监控：Prometheus
• 缓存：Redis + Caffeine（本地二级缓存）
• MQ：Kafka（行为、日志、转码任务）、RabbitMQ（关键业务消息）
• CI/CD & 部署：GitLab CI 或 GitHub Actions + Jenkins + Docker + Kubernetes

1.3 微服务拆分示例

以「职责 + 数据边界」拆分，例如：

1. API Gateway 服务

   • 基于 Spring Cloud Gateway 或 Nginx
   • 功能：统一入口、鉴权、灰度、限流、路由

2. 用户服务

   • 用户注册、登录、资料、关系（关注/粉丝）
   • 数据库：user_db

3. 内容服务（Content Service）

   • 视频/图文的元数据：标题、描述、封面、标签、作者等
   • 内容发布、下架、编辑
   • 数据库：content_db

4. 媒体服务（Media Service）

   • 视频上传、转码、截图、存储
   • 对接对象存储（S3、OSS、COS）与 CDN
   • 使用 MQ（Kafka）接收转码任务

5. 互动服务（Interaction Service）

   • 点赞、收藏、评论、转发等
   • 用 Redis 记录计数 & 排行，落盘到 DB 做最终一致

6. 推荐服务（Recommend Service）

   • 推荐流生成，调用用户画像、内容特征
   • 使用 Kafka 消费行为日志

7. 搜索服务（Search Service）

   • 构建 Elasticsearch 索引
   • 提供关键字搜索与基础语义搜索接口

8. 通知服务（Notification Service）

   • 站内信、Push、短信、邮箱等
   • 消费 MQ 里的事件消息（如有人评论你的视频）

9. AI 服务（AI Service）

   • AIGC：标题、文案、标签生成
   • RAG：语义搜索、企业文档问答
   • 封装 Spring AI / HTTP 调用外部大模型

10. 风控与审计服务（Risk Service）

    • 内容审核（涉黄、涉暴、敏感词）
    • 账号行为风控（刷量、黑产）

业务流程一般形式：

• App → API Gateway → 各业务服务 → DB/缓存/MQ → 监控/日志

1.4 短视频上传与播放链路（Q3）

1. 上传

   • 客户端：分片上传至上传网关（可直接上传到对象存储，后端只收回调）
   • 网关：鉴权、限流、简单校验

2. 媒体服务处理

   • 将上传完成事件写入 DB（视频元数据），设置状态为 UPLOADING / PROCESSING
   • 往 Kafka 发送转码任务消息 topic=video-transcode

3. 转码服务

   • 消费 video-transcode 主题
   • 使用 FFmpeg 等工具转码多码率（1080p/720p/480p）
   • 转码完成后上传至对象存储，生成不同清晰度的播放地址
   • 更新内容服务中的视频状态为 READY

4. CDN 分发

   • 播放链接指向 CDN 域名，对象存储作为源站
   • 客户端根据网络情况自适应选择码率（HLS/DASH）

5. 播放

   • 前端请求内容服务获取视频详情（包含播放 URL 列表）
   • 播放器根据网络 & 缓冲策略进行播放

技术点：

• Spring MVC / WebFlux 接口
• Kafka 可靠消息投递
• 对象存储 + CDN
• 状态机（UPLOADING → PROCESSING → READY → BLOCKED）

1.5 接口管理与 OpenAPI（Q5）

• 使用 Spring Boot + Spring MVC 编写 REST API
• 使用 springdoc-openapi 或 Swagger 自动生成接口文档
• 为每个服务提供 /v1/**、/v2/** 等版本前缀
• 在 API Gateway 层做统一路由、限流、鉴权

---

2. 高并发与可靠性设计（对应 Q4、Q6、Q7、Q9、Q10）

2.1 内容详情页性能优化（Q4）

目标：热门内容详情页的 QPS 非常高，需要低延迟、高稳定。

常见手段：

1. 多级缓存

   • 本地缓存：Caffeine
   • 分布式缓存：Redis

2. 缓存模式

   • Cache Aside（旁路缓存）：
     • 读：先查缓存 → 缓存 miss → 查 DB → 写缓存
     • 写：更新 DB → 删除缓存

3. 热点内容预热

   • 活动前预热热门内容到 Redis
   • 定时任务 + Kafka 行为日志分析

4. 避免缓存问题

   • 穿透：对不存在的数据加空值缓存 + 布隆过滤器
   • 击穿：热点 Key 使用互斥锁 / 分布式锁
   • 雪崩：过期时间增加随机值，错开集中失效

2.2 微服务容错：熔断、限流、降级（Q6）

• 使用 Resilience4j 实现：
  • 熔断（Circuit Breaker）
  • 限流（Rate Limiter）
  • Bulkhead（舱壁隔离）

示例场景：

• 推荐服务调用用户画像服务超时过多 → 打开熔断 → 推荐服务执行降级逻辑：
  • 返回通用热门内容
  • 或者 fallback 到简单逻辑（根据全站点击率）

限流策略：

• 网关层：按用户、IP、接口级别限流
• 服务层：针对短时间内高频写操作（比如点赞、评论）做限流

2.3 消息队列在内容社区中的典型用法（Q7）

1. 行为日志与埋点（Kafka）

   • 用户浏览、点赞、分享等行为发送到 Kafka
   • 推荐服务、统计服务消费

2. 异步任务（Kafka / RabbitMQ）

   • 视频转码、封面截图、审核请求

3. 事件通知（RabbitMQ）

   • 有人评论 / 点赞你的内容 → 通知服务消费 → 发送站内信/Push

4. 缓存更新

   • 重要数据更新后，通过 MQ 发布事件，各节点订阅并更新本地缓存

选型建议：

• Kafka：行为日志、埋点、转码任务、流式计算
• RabbitMQ：对可靠性和路由规则要求较高的业务事件
• Redis Pub/Sub：轻量通知，不要求持久化

2.4 数据库高可用与一致性（Q9）

1. 高可用

   • 主从复制 + 自动故障转移
   • 读写分离（内容详情读取量大）
   • 分库分表：
     • 按用户 ID / 内容 ID 分片

2. ORM 与连接池

   • MyBatis：写 SQL 灵活，适合复杂查询
   • JPA/Hibernate：适合模型相对稳定的领域
   • 连接池：首选 HikariCP（轻量高性能）

3. 一致性策略

   • 强一致：单库事务 + 合理设置事务隔离级别（一般 READ COMMITTED）
   • 最终一致：通过 MQ + 重试机制
   • 分布式事务：
     • 能避免就避免，多使用 TCC / 本地消息表方案

2.5 灰度发布与回滚（Q10）

1. CI/CD 流程

   • Git → GitLab CI / GitHub Actions → Jenkins → Docker 镜像 → Kubernetes 部署

2. 灰度机制

   • 在网关层对用户打标签（AB 分组、地区、设备类型）
   • 基于 Header / Cookie / 用户 ID 做路由规则

3. 回滚策略

   • Kubernetes：保留若干旧版本 Deployment，支持一键 rollback
   • 配置变更：使用配置中心（Spring Cloud Config/Nacos），可快速回滚配置

4. 灰度监控指标

   • 接口错误率、响应时间、用户行为（留存、转化）
   • 若超过阈值，自动或手动回滚

---

3. 监控、日志与可观测性（对应 Q8）

3.1 指标监控（Metrics）

• 使用 Micrometer 统一采集指标：
  • QPS、响应时间、异常数
  • JVM 指标：GC 次数、堆内存、线程数
• Prometheus 抓取 /actuator/prometheus 指标
• Grafana 进行可视化展示和告警

3.2 日志系统（Logging）

• 日志框架：Logback + SLF4J
• 日志输出到：
  • 本地文件 + Logstash → Elasticsearch → Kibana
• 规范：
  • 统一日志格式（JSON）
  • 每个请求携带 traceId / spanId 方便串联

3.3 分布式链路追踪

• 使用 Zipkin 或 Jaeger
• 在网关注入 traceId，向下游透传
• 通过 UI 查看全链路调用耗时，快速定位慢点

---

4. AI 接入、RAG 与 Agent（对应 Q11–Q15）

4.1 AIGC 内容生成（Q11）

场景：创作者上传视频后，希望系统自动生成：

• 标题
• 摘要/文案
• Tag/话题

基本流程：

1. 数据准备

   • 对视频进行 ASR（语音转文本），得到字幕稿
   • 对图文内容直接使用正文

2. 调用 AI 服务

   • AI 服务封装 Spring AI 或 HTTP 调用大模型（OpenAI / 内部模型）
   • Prompt 示例：
     • 「请根据以下字幕内容，生成 3 个适合短视频平台的中文标题，并为每个标题推荐 5 个标签。」

3. 结果落地

   • AI 返回候选标题 + 标签
   • 写入内容服务的草稿字段，用户可编辑后发布

4. 技术点

   • Spring Boot + Spring AI
   • 调用外部 LLM 接口，注意重试、限流、监控

4.2 RAG 基本概念与内容社区落地（Q12）

RAG（Retrieval-Augmented Generation）：

• 先「检索相关内容」，再「让大模型基于检索结果生成回答」，减小幻觉，提高专业度。

在内容社区的几个用法：

1. 智能搜索 / 问答

   • 用户问：「如何用 Spring Boot 实现视频上传？」
   • 系统在内容库中检索相关视频与文章
   • 将这些内容摘要 + 链接提供给模型，让模型给出答案 + 推荐内容链接

2. 企业知识库问答

   • 针对内部文档（产品说明、运营规程），为运营人员、客服提供问答接口

4.3 语义搜索与向量化链路设计（Q13）

1. 向量化过程

   • 对内容文本（标题 + 摘要 + 部分正文）调用 Embedding 模型
   • 得到高维向量（例如 1536 维）

2. 向量存储

   • 使用向量数据库：Milvus、Chroma 或 Redis Vector
   • 记录内容 ID、向量、元信息（tag、作者、时间）

3. 检索流程

   • 用户输入查询（自然语言）
   • 将查询向量化
   • 在向量库中基于余弦相似度 / 内积检索 TopK
   • 返回结果列表，同时可联动 ES 做关键词过滤

4. 增量更新

   • 新内容发布 / 编辑 → 通过 MQ 通知向量服务
   • 向量服务生成向量并写入向量库

4.4 Agent 与 Agentic RAG 实战思路（Q14）

Agentic RAG = RAG + 工具调用 + 决策能力。

在「智能客服系统」中的典型流程：

1. 用户提问：

   • 「我昨天买的会员没到账，帮我查一下。」

2. Agent 思考：

   • 先检索文档，看有没有通用处理流程（RAG）
   • 再调用「订单查询工具」获取用户最近订单
   • 发现订单状态异常 → 再调用「补单工具」或「工单创建工具」

3. 最终回答：

   • 告诉用户处理结果（补发成功 / 已创建工单）
   • 引用相关规则文档片段

技术点关键词：

• 工具调用框架：
  • MCP（模型上下文协议，统一模型与工具的接口）
  • 自研工具调用标准（JSON Schema 描述工具）
• Agent 框架：
  • 基于 Spring Boot 封装一层，定义工具集合、对话状态、记忆

4.5 降低 AI 幻觉的实践清单（Q15）

从后端工程角度：

1. 使用 RAG

   • 为每个回答提供相关文档片段
   • 限制模型只能基于提供的文档回答

2. Prompt 设计

   • 明确要求：
     • 「如果文档中没有答案，请直接回答『文档中没有明确说明』，不要推测。」

3. 答案可追溯

   • 在回答中附带引用文档标题、段落 ID、链接

4. 多模型校验（高风险场景）

   • 重要业务可使用两个模型交叉验证

5. 人工审核

   • 医疗、金融、风控类场景，对部分回答进行人工复审

6. 日志与反馈

   • 记录用户对回答的评分或反馈
   • 将错误案例回流到训练 / Prompt 优化

---

六、小结

通过这场「大厂音视频 + 内容社区 Java 面试」的故事，我们串联了：

• 微服务拆分与 Spring Boot / Spring Cloud 选型
• 缓存、消息队列、数据库高可用、监控与日志体系
• 音视频上传、转码、播放的端到端链路
• AIGC、RAG、Agentic RAG 在内容社区与智能客服中的落地方式

你可以把这篇当作一个「面试复盘 + 学习目录」，对照自己的项目经验，一个模块一个模块地补齐。下次如果再遇到类似场景，就不会像小 Y 那样「听过但说不全」了。