面试官：你会Java？——从UGC社区到AI问答平台的全链路拷问（含Kafka、Redis、RAG、向量数据库等）

场景：互联网内容社区 + AIGC / AI 问答平台（偏“内容社区与UGC + 大数据与AI服务”）

角色：

  • 面试官：认真、犀利，不爱废话。
  • 候选人小Y：略水，但嘴甜，会简单题，复杂题开始含糊其辞。

一、第一轮：从单体内容社区到基础架构

场景：一家做短内容社区 + 图文 / 小视频的互联网公司，要做一个「用户发帖 + 点赞 + 评论 + 简单推荐」的系统。

第一轮 · 第 1 问：基础技术栈 & 项目整体架构

面试官： 我们现在做的是一个内容社区，核心功能是：用户发帖、点赞、评论、关注作者、基于用户兴趣做简单推荐。你用 Java 会怎么选技术栈，大致架构说一下？

小Y：

嗯……这个嘛，肯定是 Java 啊，我比较熟 Java 8（虽然 17 也能看懂一点）。我一般就 Spring Boot 搭个项目，数据库就 MySQL，前端随便给我个 Vue 我都能对接。

我会用 Maven 管理依赖，然后写几个 Controller、Service、Mapper 就行。发帖、点赞、评论这些都写成接口……然后用 MyBatis 查数据库就行了。推荐的话，也可以……以后再加个服务之类的？

面试官（点点头）：

技术栈上还算落地，Spring Boot + MySQL + MyBatis 是个常见选择。但是你说“以后再加个服务”，如果从一开始就考虑扩展，你会怎么划分模块？比如用户、内容、关系（关注）、推荐等，你会怎么切？

小Y（有点慌）：

呃……那就分几个模块嘛：user-service、content-service、relation-service、recommend-service……每个都是个 Spring Boot 应用，以后再用 Spring Cloud 注册一下……大概是这样。

第一轮 · 第 2 问：数据库设计 & ORM

面试官：

那我们先不谈微服务，就当你现在是单体服务。发帖和点赞评论这些表你会怎么设计？用什么 ORM？

小Y：

数据库肯定是 MySQL 嘛。然后表的话……

  • user 表存用户
  • post 表存帖子
  • comment 表存评论
  • like 表存点赞

ORM 我比较会 MyBatis，配 Mapper XML 或者用注解都可以。JPA 也能看懂，但是我平时更喜欢 MyBatis 手写 SQL，比较灵活。

面试官：

那 like 表的主键你会怎么设计？防止一个用户对同一帖子重复点赞？

小Y：

这个嘛……可以用 id 自增主键，然后再加个唯一索引 user_id + post_id，这样就不能重复点赞了。如果重复插入会报错，到时候我们代码里捕获一下异常就行。

面试官（肯定）：

这个设计还可以，唯一索引防重复点赞是常见做法。

第一轮 · 第 3 问：缓存与热点数据

面试官：

内容社区里，热点帖子会被频繁浏览和点赞。如果所有读写都走 MySQL，很容易顶不住。你会怎么用缓存来优化，比如用 Redis？

小Y：

Redis 我还算熟。帖子详情和点赞数可以放 Redis 里，比如：

  • post:{postId} 存帖子详情
  • post:like_count:{postId} 存点赞数

读帖先查 Redis，查不到再查 MySQL 然后回写。点赞的时候就先 INCR Redis 里的计数，再异步写回数据库……嗯，大概这样。避免 MySQL 压力太大。

面试官：

那 Redis 挂了怎么办？数据会不会丢？

小Y（开始含糊）：

这个……嗯……可以开个持久化，RDB 和 AOF 都开上？然后多部署几个 Redis 实例，搞个集群？真的挂了的话，最多就是少一点点赞数，下次再……再算？

面试官（略皱眉）：

有一点概念，但对于“最终一致性”和“缓存架构”的描述还不太清晰，后面我们会再细问。

第一轮 · 第 4 问：日志与监控

面试官：

线上系统除了业务代码，还要有日志和监控。你在项目里会怎么做日志？再比如 QPS 上来之后要看哪些监控指标？

小Y：

日志的话，我一般用 Spring Boot 默认的 Logback，再引入 SLF4J 打日志，info、error 区分一下。稍微高级点，可以用 Log4j2。日志格式里会加 traceId 方便排查问题。

监控的话，可以集成 Micrometer + Prometheus + Grafana，监控 QPS、请求耗时、错误率、JVM 内存这些指标。然后有告警阈值，超了就通知运维。

面试官（点头）：

这一块还比较扎实。

二、第二轮：引入 Kafka、微服务与搜索

场景升级：用户规模上来了，内容量巨大，我们引入 Kafka 做异步解耦，引入 ElasticSearch 做搜索，把系统拆成微服务，用 Spring Cloud 管理。

第二轮 · 第 1 问：Kafka 消息模型 & 业务解耦

面试官：

现在点赞、评论、发帖量都上来了，我们想把“行为日志”统一收集起来做推荐和数据分析。你会怎么设计 Kafka 的 topic 和消息结构？

小Y：

Kafka 我知道。我们可以搞一个 user-action 的 topic，里面发用户行为，比如：

{
  "userId": 123,
  "actionType": "LIKE", // 或 COMMENT, POST
  "targetId": 456,
  "timestamp": 1719999999
}

然后推荐服务、风控服务都从这个 topic 消费。这样就实现了系统解耦，生产者就是我们的内容服务，消费者是推荐、统计、风控，互相不影响。

面试官：

那 topic 分区你怎么考虑？为什么要分区？

小Y（有点虚）：

分区可以提高并行度……一个 topic 多个 partition，多台 consumer 可以一起消费，吞吐量就高了。分区策略嘛，可以按 userId 的 hash 分区，让同一用户的消息落到同一个分区，这样处理起来更有序……具体多少分区，就看并发量和机器数……呃……大概是这样。

面试官：

有基本概念，但在容量规划、扩分区带来的 rebalancing 问题上，你还需要多了解。

第二轮 · 第 2 问：ElasticSearch 搜索 & 数据同步

面试官：

社区内容越来越多，靠 MySQL 做模糊搜索不现实了。我们准备用 ElasticSearch 做“帖子搜索 + 简单推荐”。你会怎么把 MySQL 里的帖子数据同步到 ES？

小Y：

可以有两种方式：

  1. 写入 MySQL 时，同时写 ES（双写）。
  2. 通过 binlog 或 Kafka 进行异步同步。

我觉得第二种更好一点。比如发帖时写 MySQL，然后通过 Canal 等工具监听 binlog，把新增/修改的帖子推到 Kafka，再由一个“索引同步服务”消费，写入 ES。这样就不影响主流程的性能。

面试官：

那 ES 的索引结构你会怎么设计？支持标题、正文、标签搜索，还要支持根据点赞数和时间综合排序。

小Y：

索引字段就可以有：

  • id（postId）
  • title
  • content
  • tags（数组）
  • likeCount
  • createTime

查询的时候可以用 multi_match 查询 title 和 content，然后在 sort 里对 likeCount 和 createTime 做一个权重排序，比如最近的和点赞高的优先。

面试官：

这个方向没问题，细节可以再丰富。

第二轮 · 第 3 问：Spring Cloud 微服务 & 网关

面试官：

现在你刚才说的 user-service、content-service、recommend-service 等都拆成了独立服务，用 Spring Cloud 管理。那你会用哪些组件？整体调用链是什么样？

小Y：

嗯……Spring Cloud 里我知道可以用：

  • 注册中心：Eureka 或者用 Nacos
  • 负载均衡：Spring Cloud LoadBalancer
  • 网关：Spring Cloud Gateway
  • 配置中心：Spring Cloud Config 或 Nacos Config
  • 服务间调用：OpenFeign
  • 容错：Resilience4j 做熔断、限流

调用链的话：

  1. 前端先打到 Gateway
  2. Gateway 做鉴权、路由，把请求转发到对应的服务，比如 content-service
  3. content-service 如果需要用户信息，就通过 OpenFeign 调用 user-service
  4. 如果要查推荐，就调 recommend-service
  5. 中间用注册中心发现服务地址，用配置中心统一管理配置

面试官（赞许）：

能把常见组件讲出来，并且描述了一个完整调用链，这点还不错。

第二轮 · 第 4 问：分布式调用链跟踪

面试官：

微服务多了之后，排查问题很容易迷路。你会怎么做分布式链路追踪？比如一个请求经过网关、内容服务、用户服务、推荐服务，你要在日志里串起来怎么看？

小Y：

我知道可以用 Zipkin 或 Jaeger。通过 Spring Cloud Sleuth 可以自动生成 traceId 和 spanId，把它们注入日志和 HTTP header 里。这样每个服务的日志都有同一个 traceId，就能在 Zipkin/Jaeger 里看到完整链路。

面试官：

这部分也还可以。

三、第三轮：AI 问答、RAG 与智能客服

场景再次升级：公司想做一个 AI 问答 + 智能客服系统，用户可以问“如何提升内容曝光”“平台违规内容怎么处理”等，系统会结合平台内部文档和用户数据给出回答。

引入：RAG、向量数据库、Spring AI、工具调用、Agent 等。

第三轮 · 第 1 问：RAG 架构总体设计

面试官：

我们要做一个面向创作者和运营同学的“智能问答助手”，支持：

  • 问产品规则、运营策略
  • 查数据指标（比如某个帖子的曝光、转化）

你会怎么用 RAG（检索增强生成）来设计整体架构？

小Y（有点紧张）：

RAG……就是先检索再生成对吧？

大概可以这样：

  1. 先把内部文档（规则、策略、FAQ）用一个文档加载工具读进来，然后切成小 chunk
  2. 用 Embedding 模型（比如 OpenAI 的）把每个 chunk 向量化，存到 Milvus 或者 Redis 的向量库里
  3. 用户提问题时，也先做向量化，在向量数据库里做语义检索，找到相关文档
  4. 把这些文档塞到大模型的 prompt 里，让模型基于这些文档生成答案，这样可以减少幻觉

面试官：

那业务数据查询（比如某个创作者最近 7 天阅读量）也要支持，怎么跟 RAG 结合？

小Y（含糊）：

可以……可以让模型调用一些工具吧？比如一个“查询数据服务”的 API，当用户问“帮我查一下 A 这个账号的最近 7 天曝光和点赞”，我们就让模型识别到这是个数据查询意图，然后让它调用后端的接口，拿到结果再生成回答。这个好像就是工具调用和 Agent？

面试官：

方向是对的，但还不算具体，后面我追问一下安全和风控。

第三轮 · 第 2 问：Spring AI、工具调用与权限控制

面试官：

假设我们用 Spring AI 来封装大模型调用，并且用 Agent 的方式让模型可以调用“数据查询工具”。你会怎么设计这部分？另外，如何保证用户只能查到自己有权限看的数据？

小Y：

Spring AI 我大概看过一点，可以把 LLM 封装成一个 Bean，然后通过注解或者配置定义工具。

工具调用的话，我会定义一个“查询用户数据”的工具，里面调用我们自己的微服务 API，比如 data-service。模型识别到需要查数据，就“调用”这个工具，执行代码，然后把结果返回给模型，让模型组织语言回答。

权限的话……可以在调用工具前做一层鉴权。比如工具的入参里有 userId 和要查的对象 id，我们在 data-service 里做权限校验，只返回当前登录用户有权限的数据。Agent 那边只要把用户的身份传过去就行。

面试官：

大方向还可以，不过你对 Spring AI 的具体用法还比较抽象，建议回去写个 demo 熟悉一下。

第三轮 · 第 3 问：向量数据库、语义检索与去幻觉

面试官：

再问细一点。你刚才提到向量数据库，比如 Milvus / Chroma / Redis。你会怎么选择？语义检索时有哪些关键参数？我们如何减少幻觉？

小Y（明显开始虚）：

选择的话……如果公司已经有 Redis 集群，可以先用 Redis 的向量索引，简单上线。如果是专门做 AI 文档问答，数据量大，就用 Milvus 这种专业向量数据库，检索性能会更好。Chroma 可以在小规模和本地开发时用。

语义检索参数……有 topK、相似度阈值之类的。topK 太小可能漏掉重要信息，太大又会给模型太多无关内容。

减少幻觉的话……可以让模型“只根据检索到的文档回答”，如果没匹配到就直接说“不确定”。还可以在 prompt 里强调不要编造数据。再加一个“引用文档”的机制，让模型输出时带上引用出处……嗯……类似这样。

面试官：

思路上没问题，不过在评估 embedding 质量、召回率/精准率权衡上，你还缺一些实践经验。

第三轮 · 第 4 问：限流、熔断与成本控制

面试官：

大模型调用很贵，而且有并发限制。你会怎么在网关和服务内部做限流与熔断？用到什么组件？

小Y：

可以在 Spring Cloud Gateway 上用 Resilience4j 做限流和熔断。比如一个用户每分钟最多调用 10 次 AI 接口，超过就直接在网关返回“调用频率过高”。

内部的话，也可以在调用 LLM 的 client 上配置熔断和重试策略，当下游模型服务超时或错误率高时，开启熔断，直接降级返回“当前服务繁忙请稍后再试”。

另外可以在业务层做配额控制，比如每天免费额度，超出要收费或者限制功能。

面试官：

差不多可以。

第三轮 · 第 5 问：安全与风控

面试官：

最后一个问题。我们是内容社区+AI 问答，一定要非常注意安全与风控，比如：

  • 不让用户通过 AI 套取敏感数据
  • 不让 AI 输出违规内容

你会从哪些层面来设计安全方案？

小Y（已进入“嘴强王者”模式）：

安全嘛……肯定要多层防护：

  1. 鉴权：用 Spring Security + JWT，所有 API 都要带 token，网关做统一校验
  2. 权限：后台服务按角色和资源做 RBAC，像 Keycloak 也可以用
  3. 风控：对请求参数做规则校验，比如敏感词过滤、内容审核
  4. 对 AI 输出可以再加一层审查，通过一个“二次审核模型”或者内容安全接口过滤一下再返回前端
  5. 还有操作日志，重要操作要记录下来，异常行为交给风控系统分析

具体嘛……可以根据公司策略再细化。

面试官：

思路不算差，但还是偏概念化。整体来说，你对 Java 基础、Spring Boot、常见中间件和微服务有一定掌握，对 AI 方向刚刚入门。今天就先到这里，回去等通知吧。

四、面试题详细解析（小白也能看懂的技术拆解）

下面把上面所有问题，按技术点和业务场景拆开讲一遍，方便你系统学习。

1. 内容社区基础架构：从单体到微服务

业务场景：

  • 用户发帖（文字/图片/短视频）
  • 点赞、评论、关注作者
  • 基于兴趣做简单推荐

常见技术栈选择：

  • 语言 & 运行时：Java 8 / 11 / 17（新项目推荐 17 LTS）
  • Web 框架：Spring Boot + Spring MVC
  • 构建工具：Maven 或 Gradle
  • 数据库：MySQL（事务型业务、关系模型）
  • ORM：MyBatis / JPA / Spring Data JPA
  • 缓存：Redis
  • 消息队列：Kafka（行为日志、异步处理）
  • 搜索：ElasticSearch（帖子搜索）
  • 微服务框架：Spring Cloud 全家桶
  • 日志与监控：SLF4J + Logback / Log4j2、Micrometer + Prometheus + Grafana、Zipkin / Jaeger
1.1 单体架构

初期可以是一个 monolith：

  • 模块按业务分包：user、content、comment、like 等
  • 数据库一个实例，多张业务表
  • 部署一个~多个副本，用 Nginx + SLB 做负载均衡

优点：简单、开发快、部署方便。

缺点：

  • 模块耦合重，代码越来越难维护
  • 部署颗粒度粗，小改动也要整体发版
  • 吞吐和稳定性差，易成为“大泥球”
1.2 微服务拆分思路

当用户量和功能变多后，就会考虑微服务拆分。常见切分方式：

  • 按业务域：

    • user-service：用户、登录、权限
    • content-service：帖子、草稿、发布
    • social-service：关注、粉丝、关系链
    • comment-service：评论、回复
    • like-service：点赞
    • recommend-service：推荐逻辑

  • 按非功能模块：

    • search-service（接 ES）
    • notify-service（短信、站内信、推送）

配合 Spring Cloud，微服务之间通过 REST（OpenFeign）、gRPC 或 Dubbo 调用。

2. 数据库设计与 ORM

2.1 核心数据表设计示例
CREATE TABLE user (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  nickname VARCHAR(64) NOT NULL,
  avatar VARCHAR(255),
  created_at DATETIME NOT NULL
);

CREATE TABLE post (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT NOT NULL,
  title VARCHAR(200) NOT NULL,
  content TEXT NOT NULL,
  tags VARCHAR(255),
  like_count INT DEFAULT 0,
  comment_count INT DEFAULT 0,
  created_at DATETIME NOT NULL,
  INDEX idx_user_id (user_id),
  INDEX idx_created_at (created_at)
);

CREATE TABLE `like` (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT NOT NULL,
  post_id BIGINT NOT NULL,
  created_at DATETIME NOT NULL,
  UNIQUE KEY uk_user_post (user_id, post_id),
  INDEX idx_post_id (post_id)
);

CREATE TABLE comment (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  post_id BIGINT NOT NULL,
  user_id BIGINT NOT NULL,
  content VARCHAR(500) NOT NULL,
  created_at DATETIME NOT NULL,
  INDEX idx_post_id (post_id)
);
  • uk_user_post (user_id, post_id) 防止重复点赞
  • idx_created_at 支持按时间倒序拉取 feed
2.2 ORM：MyBatis vs JPA
  • MyBatis：
    • 需要写 SQL（XML 或注解）
    • 灵活、可控，适合复杂查询与调优
  • JPA/Spring Data JPA：
    • 面向对象操作，自动生成 SQL
    • 开发快，但复杂查询可读性差

在大厂内容业务里，MyBatis + 手写 SQL 非常常见。

3. Redis 缓存与热点数据

痛点：

  • 热门帖子被疯狂浏览、点赞
  • 如果全打到 MySQL，容易出现连接数打满、慢查询等问题

解决思路：读写分离 + 缓存 + 限流

3.1 Redis 缓存帖子与计数

常见 key 设计：

  • post:{postId}：帖子详情（JSON）
  • post:like_count:{postId}：点赞数
  • post:comment_count:{postId}：评论数

读流程：

  1. 先查 Redis
  2. 未命中则查 MySQL
  3. 把结果写回 Redis，并设定过期时间

写流程（点赞）：

  1. 对 like 表插入记录（带唯一键防重复）
  2. Redis INCR post:like_count:{postId}
  3. 定时或异步把计数刷回 MySQL（如每隔 N 分钟聚合一次）
3.2 缓存与一致性问题

常见方案：

  • 写 + 删（写库 + 删除缓存）：
    • 写 MySQL 成功后，删除缓存，让下次读取强制走 DB
  • 双写（写库 + 写缓存）：
    • 简单但容易不一致

缓存挂了怎么办？

  • Redis 本身做持久化（RDB + AOF）、主从复制、哨兵或集群
  • 应用要处理 Redis 不可用的情况：
    • 降级：直接走 DB，但可能要配合限流

4. 日志与监控

4.1 日志
  • 使用 SLF4J 作为日志门面，底层用 Logback 或 Log4j2
  • 约定日志格式：时间 | 级别 | traceId | spanId | 线程 | 类 | 内容
  • 按业务打 INFO、按异常打 ERROR，注意日志脱敏
  • 通过 Filebeat/Logstash 收集日志到 Elasticsearch，配合 Kibana/Graylog 查询
4.2 监控
  • 基础指标：
    • QPS、响应时间、错误率
    • JVM 内存、GC 次数、线程数
  • 技术栈：
    • Micrometer + Prometheus 采集
    • Grafana 展示
    • 告警（邮件、钉钉/企业微信机器人）

5. Kafka、用户行为与异步解耦

业务需求：

  • 收集用户发帖、点赞、评论行为，用于：
    • 推荐算法（协同过滤、召回策略）
    • 风控（刷赞、刷粉、恶意灌水）
    • 数据看板（UV、PV、转化）
5.1 Topic 设计

示例：

  • user-action：统一用户行为
    • actionType：POST / LIKE / COMMENT 等
    • userId / targetId / timestamp

也可以细分：

  • user-like
  • user-comment
  • user-post

分区（partition）考虑：

  • 提升吞吐：更多分区 → 更多并发消费
  • 顺序要求：对同一用户、同一帖子，需要顺序的可以按 userId/postId 做 key，保证落在同一分区
5.2 消费端
  • 推荐服务：根据用户行为更新“兴趣画像”
  • 风控服务：检测异常行为
  • BI/统计：写入 OLAP 或数据仓库（Hive/Spark/Flink）

6. ElasticSearch 搜索与排序

场景：

  • 搜索帖子标题/内容/标签
  • 按时间 + 热度（点赞/评论）综合排序
6.1 索引结构
{
  "mappings": {
    "properties": {
      "id": {"type": "long"},
      "title": {"type": "text", "analyzer": "ik_max_word"},
      "content": {"type": "text", "analyzer": "ik_max_word"},
      "tags": {"type": "keyword"},
      "likeCount": {"type": "integer"},
      "commentCount": {"type": "integer"},
      "createTime": {"type": "date"}
    }
  }
}
6.2 数据同步方案
  • 双写：写 MySQL 时同步写 ES，简单但耦合
  • binlog + Canal + Kafka：
    • MySQL → binlog → Canal → Kafka → ES 同步服务
    • 优点：异步、解耦、不影响主流程
6.3 查询与排序
  • 搜索：multi_match 查询 title 和 content
  • 排序：
    • 首先按一个综合得分排序：
      • score = w1 * 文本相关度 + w2 * likeCount + w3 * commentCount + w4 * 时间衰减

7. 微服务与 Spring Cloud

7.1 常用组件
  • 服务注册与发现：Eureka / Consul / Nacos
  • 配置中心：Spring Cloud Config / Nacos Config
  • 网关：Spring Cloud Gateway / Zuul（老）
  • 客户端负载均衡：Spring Cloud LoadBalancer
  • 服务调用：OpenFeign / gRPC / Dubbo
  • 容错：Resilience4j（限流、熔断、降级）
  • 链路追踪：Spring Cloud Sleuth + Zipkin/Jaeger
7.2 调用链示例
  1. 用户调用 api.xxxx.com → Nginx → Gateway
  2. Gateway：
    • 鉴权（JWT、Session）
    • 路由到 content-service
  3. content-service：
    • 查询帖子信息（DB + Redis）
    • Feign 调用 user-service 获取作者信息
    • Feign 调用 recommend-service 获得相关推荐
  4. 所有请求携带 traceId，日志打点统一

8. 分布式链路追踪

目的：

  • 查某个请求在哪个服务耗时高、哪一环出错

实现：

  • 引入 Spring Cloud Sleuth：自动生成 traceId、spanId
  • 所有服务日志中打印 traceId
  • 集成 Zipkin 或 Jaeger：
    • 采集 span 信息
    • 可视化展示调用链、耗时

9. AI 问答、RAG 与向量数据库

业务场景：

  • 面向创作者、运营、客服的 智能问答系统：
    • 问平台规则、内容规范
    • 问运营活动玩法
    • 查询自己内容的数据指标
9.1 什么是 RAG？

RAG（Retrieval-Augmented Generation）：检索增强生成。

流程：

  1. 把企业内部文档（产品文档、FAQ、规约）切片（chunk），比如每 200~500 字一段
  2. 使用 Embedding 模型（OpenAI、Ollama 等）将每个 chunk 向量化
  3. 把向量 + 原文存入向量数据库（Milvus、Chroma、Redis-Search）
  4. 用户提问：
    • 对问题做向量化
    • 在向量数据库中执行“语义相似检索”，找到 topK 个相关文档片段
    • 将这些文档作为上下文，填入 Prompt
    • 调用大模型生成最终回答

好处：

  • 模型回答有“依据”，降低幻觉
  • 可以快速接入企业私有知识
9.2 向量数据库选择
  • Milvus：
    • 专业向量数据库，支持大规模向量、高性能检索
    • 适合生产环境和海量文档
  • Chroma：
    • 轻量化，适合本地开发、PoC、数据量不大场景
  • Redis（向量索引）：
    • 如果公司已有 Redis 集群，可复用
    • 性能不错，运维成本低
9.3 语义检索关键参数
  • topK：检索返回文档数量
    • 太少：可能遗漏关键信息
    • 太多：上下文变长，成本高，可能引入噪音
  • 相似度阈值：低于某个 score 就不算匹配
  • Embedding 维度与质量：影响召回效果
9.4 减少幻觉的方法
  • 在 Prompt 里明确规定：只能基于提供的文档回答，不要编造
  • 若检索不到相关文档，要求模型回答“不确定”或提示人工客服
  • 给回答加“引用来源”，比如“根据《创作者规范第 3 条》”
  • 对模型输出做二次审核（敏感内容过滤）

10. Spring AI、工具调用与 Agent

问题：

  • 光能回答规则说明还不够，用户还会问“帮我查下这个帖子最近 7 天曝光”。

方案：

  • 给 Agent 配置“工具”（Tool / Function）：
    • getPostStats(postId, days)
    • 内部调用我们的 data-service（REST / gRPC）

Spring AI 相关点：

  • 统一封装 LLM 调用（OpenAI、Azure、Ollama 等）
  • 定义工具接口，让模型在对话中能“决定”是否调用工具
  • 工具返回数据后，模型根据实际数据组织回答

权限控制：

  • 所有工具调用时必须带上当前登录用户的 userId / token
  • 后端 data-service 负责校验：
    • 当前用户是否有权限查看该帖子数据
    • 是否超过调用次数、是否异常行为

11. 限流、熔断与成本控制

大模型调用痛点：

  • 并发限制：模型服务 QPS 有上限
  • 成本高：每次调用按 token 计费

解决：

  • 在网关做限流：

    • 按用户、按 API 维度限流（如 10 次/分钟）
    • 使用 Resilience4j、Bucket4j 等组件

  • 在服务内做熔断：

    • 调用 LLM 超时或错误率高时短期熔断
    • 直接返回“系统繁忙”或兜底回答

  • 成本控制：

    • 用户配额：每天免费 N 次
    • 优先缓存常见问题的答案（FAQ 结果缓存）

12. 安全与风控

多层安全设计：

  1. 身份认证

    • Spring Security + JWT
    • 或使用 Keycloak 做统一身份认证

  2. 权限控制（Authorization）

    • RBAC：角色-权限模型
    • 控制谁能看哪些数据、谁能调用哪些接口

  3. 内容审核 & 风控

    • 文本、图片、视频内容接入内容安全服务
    • 对 AI 回复再做一次内容审核
    • 对异常行为（频繁调用、恶意提问）进行策略限制

  4. 审计日志

    • 记录关键操作（登录、敏感数据访问）
    • 方便事后追踪

五、如何复盘这场“面试剧本”？

如果你是 Java 面试准备阶段，可以照着这篇文章做：

  1. 把“内容社区 + AI 问答”当成一个完整项目
  2. 按顺序思考：
    • 基础 Web + DB 架构
    • 缓存、消息队列、搜索
    • 微服务拆分 + Spring Cloud
    • 日志、监控、链路追踪
    • AI：RAG、向量库、工具调用、Agent、安全
  3. 不会的点，逐个补：
    • Kafka Topic 分区与消费组
    • Redis 缓存策略与一致性
    • ES 索引设计与查询 DSL
    • Spring Cloud 各组件角色
    • RAG 流程与向量数据库

等你能把这套故事从“业务需求 → 技术选型 → 架构设计 → 运维与安全”顺下来，再去面试大厂 Java 岗位，你就不会像小Y那样在复杂问题上“含糊其辞”了。

# RAG
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

qData 数据中台开源版 v1.2.0 正式发布：重构数据建模体系，重塑开发体验！

avatar AtomGit开源社区
cover

2026企业级AI智能体深度解析：如何通过可信架构降低大模型幻觉，实现深度数据挖掘？

avatar AtomGit开源社区
cover

6个常用国自然课题项目查询网站，码住以备不时之需

avatar AtomGit开源社区