大厂 Java 面试实战：从电商微服务到 AI 智能客服（含 Spring 全家桶、Redis、Kafka、RAG/Agent 解析）

场景：某互联网大厂电商 + 智能客服部门，招聘 Java 开发工程师。一位严肃的面试官，和一位略显搞笑、略水但又有点基础的小Y同学之间的对话。

一、面试背景设定

部门主要负责：

电商核心链路：商品、购物车、订单、库存、支付
智能客服与问答中心：基于 RAG + Agent，支持商品问答、物流查询、售后咨询
技术栈覆盖：
- 语言平台：Java 8/11/17，JVM
- 框架：Spring Boot、Spring MVC、Spring Cloud、MyBatis、Spring Data、Redis、Kafka、Elasticsearch
- 基础设施：Docker、Kubernetes、Jenkins CI/CD
- AI 能力：Spring AI、RAG、向量数据库、Agent 工作流、企业文档问答

下面进入正式 3 轮面试对话，每轮 3--5 个问题。

二、第一轮：电商下单链路 & 基础 Java / Spring

场景：用户在电商 App 上浏览商品，下单购买。重点考察 Java 基础、Spring Boot、数据库访问与事务。

Q1：下单接口的整体设计

面试官：

我们有一个典型的电商下单流程：用户提交订单，涉及校验库存、扣减库存、生成订单、扣款（假设调用支付网关），请你用 Spring Boot + Spring MVC 简单设计一下下单接口的结构，包括：

Controller 层大概长什么样？
Service 层做哪些事情？
DAO/Mapper 层你会用 MyBatis 还是 JPA？为什么？

小Y：

Controller 就写个 @RestController，然后一个 @PostMapping("/order/create")，接收一个 DTO。Service 就再调一下 DAO，插个订单就好了。Mapper 我一般用 MyBatis，反正公司都是这么写的，写 XML 比较自由......

面试官：

嗯......勉强算是答到了最表层。待会我们在解析部分详细展开。

Q2：下单时的事务控制

面试官：

下单过程里面有：

扣减库存
生成订单记录

假设这两个动作都在 MySQL 里，用 Spring 你怎么做事务控制？用什么注解？放在什么位置？它默认传播行为和隔离级别是什么？

小Y：

这个我知道，用 @Transactional 就行了，一般加在 Service 上。具体传播行为，我记得是啥 REQUIRED 吧，隔离级别我就用数据库默认的，反正一般没啥问题......

面试官：

嗯，基础点说对了，细节方面我们稍后展开。

Q3：高并发下的库存超卖问题

面试官：

在大促场景，很多用户同时对同一商品下单，很容易出现库存超卖。你会用哪些方案来避免超卖？可以从 数据库层面 和 缓存/分布式锁 两方面回答。

小Y：

这个......可以用 Redis 啊，反正大家都用 Redis。先把库存放 Redis，减一减一就行了。如果不够就不让下单。数据库的话可以加个锁？比如乐观锁，带个 version 字段。具体怎么写我不太记得了......

面试官：

思路方向还行，回答得比较散，后面我们系统梳理一下。

Q4：订单查询接口的性能优化

面试官：

假设订单表数据量非常大，一个用户可能有几千笔订单。我们提供一个"我的订单列表"的接口，支持分页和状态筛选（已支付、已发货、已完成等）。

数据库层面你会怎么建索引？
Java 代码中分页你会怎么做？使用 Spring Data 还是自己写 MyBatis 分页？
为了减少数据库压力，可以用哪些缓存手段？

小Y：

索引就给 user_id 建一个，状态也顺便建一下，联合索引吧。分页就 limit offset 呗。缓存就 Redis，查出来塞进去就好了。具体 key 怎么设计嘛，可以用 user:orders:userId 这种......

面试官：

有一些点说到了，但还不够系统，特别是索引和缓存一致性，后面细讲。

Q5：日志与链路追踪

面试官：

下单过程中，一次请求会经过网关、订单服务、库存服务、支付服务。为了排查问题，我们需要完整的调用链路。请问：

在 Java 侧，你会用什么日志框架？
链路追踪你了解哪些方案？比如 Zipkin、Jaeger、Spring Cloud Sleuth？
你会记录哪些关键字段来方便排查？

小Y：

日志嘛，就 slf4j + logback，这个比较常见。链路追踪我知道 Zipkin，但没搞过，感觉就是打个 traceId 然后一路传下去。记录字段就记录一下订单号、用户 ID，还有异常堆栈就行......

面试官：

好，基础 OK，但工程实践细节我们后面给一个标准示例。

三、第二轮：微服务、消息队列与搜索（大促与智能客服场景）

场景：电商大促，上线了智能客服中心。订单、库存、物流、客服中心都拆成微服务，依赖 Kafka、Redis、Elasticsearch、Spring Cloud 等。

Q6：微服务拆分与 Spring Cloud 选型

面试官：

我们现在的电商系统已经拆成微服务：商品服务、订单服务、库存服务、用户服务、客服服务等。你会用哪些 Spring Cloud 组件来支撑：

服务注册与发现
配置中心
熔断与限流
服务间调用

顺便说说你对 Netflix OSS（Eureka、Zuul）和 Spring Cloud Alibaba（Nacos、Sentinel、Gateway）的理解和选择。

小Y：

服务发现可以用 Eureka，配置中心可以用 Config Server 或者 Nacos，现在感觉 Nacos 更多。熔断限流以前是用 Hystrix，现在好像是 Resilience4j 和 Sentinel。服务间调用就 OpenFeign。选型嘛，我觉得大家都在用 Spring Cloud Alibaba 就跟着用吧，社区热闹......

面试官：

大方向知道，但缺乏具体场景和优劣比较，解析部分我们展开讲。

Q7：订单事件与 Kafka 解耦

面试官：

用户下单成功后，需要：

发送站内信和短信
给智能客服中心推送订单信息，方便客服和机器人查询
给风控服务发送事件

如果使用 Kafka 来解耦这些业务，你会怎么设计 Topic、消息格式，以及在 Java 代码中用什么方式（Spring Kafka）来发送和消费消息？如何考虑消息的幂等性？

小Y：

Kafka 的话，就建一个 order-created 的 topic，消息就放个 JSON，里面有订单号啥的。发消息用 Spring Kafka 的 KafkaTemplate，消费就写个 @KafkaListener。幂等性的话，可以在数据库里搞个表，记录消息 ID，消费前查一下，如果有就不处理......大概这样？

面试官：

这个回答还不错，基本思路比较完整，幂等性意识也有，加分。

Q8：智能客服的搜索与 Elasticsearch

面试官：

智能客服需要支持用户输入"我想查一下上次买的蓝牙耳机订单"，系统要根据用户历史订单做搜索。我们使用 Elasticsearch 来做：

商品与订单的 ES 索引大致如何设计？
Java 里用什么客户端？Spring Data Elasticsearch 还是 RestHighLevelClient？
如何保证 MySQL 中订单数据与 ES 中索引的最终一致性？

小Y：

索引就把订单的一些字段丢进去，比如订单号、商品名，然后加个分词。Java 客户端我知道有 RestHighLevelClient，还有 Spring Data Elasticsearch，不过我没怎么用。至于一致性嘛，可以靠定时同步？比如用个定时任务扫一下......

面试官：

只靠定时任务有点粗暴，解析部分我们会讲基于 Kafka 的实时同步方案。

Q9：Redis 在智能客服会话中的应用

面试官：

智能客服机器人需要维护用户会话上下文，比如最近几轮的问答、用户 ID、当前订单焦点等。你会如何使用 Redis 来实现会话存储？

key 的设计
过期策略
使用 Redis 的数据结构（String、Hash、List、ZSet 等）

小Y：

我一般就用 String，存个 JSON，key 叫 session:userId，过期时间设个 30 分钟啥的。复杂点也可以用 Hash 吧，不过我平时都是直接塞 JSON，简单粗暴。

面试官：

有可行性，但还有更精细的设计方式，我们后面会示例说明。

Q10：Docker、Kubernetes 与弹性扩缩容

面试官：

大促期间，智能客服和订单服务的流量会暴涨。我们使用 Docker + Kubernetes：

Spring Boot 应用如何打成镜像？Dockerfile 大概长什么样？
在 Kubernetes 中如何配置水平自动扩缩容（HPA）？基于哪些指标？
你会如何在 CI/CD 中用 Jenkins 或 GitLab CI 完成自动构建和部署？

小Y：

打镜像就用 Dockerfile，FROM openjdk 然后 COPY jar 进去，java -jar 跑起来。HPA 我知道是根据 CPU 或 QPS 自动调 replicas，但具体 YAML 我没写过。CI/CD 就 Jenkins 拉代码，maven 打包，然后 docker build & push，最后 kubectl apply 一下......

面试官：

基本有概念，但对 Kubernetes 细节了解不多，解析部分我会给示例流程。

四、第三轮：安全、AI RAG/Agent 与风控

场景：电商 + 智能客服系统要处理支付、用户隐私、敏感问答，还要引入大模型做智能客服，需要考虑安全、风控和 AI 架构。

Q11：登录、鉴权与 Spring Security + JWT

面试官：

我们的电商与客服系统需要统一登录鉴权：

简述一下基于 Spring Security + JWT 的登录流程。
JWT 里会放哪些信息？如何避免在 Token 中泄露敏感信息？
客户端如何携带 JWT？服务端如何进行校验与刷新？

小Y：

这个我大概知道，登录的时候用用户名密码校验，通过了就生成一个 JWT，里面有 userId 啊、用户名啊，然后返回给前端。前端每次请求就带在 Header 里。校验就解析一下 token 看是否有效，过期就让用户重新登录......其它细节我不是很熟。

面试官：

总体流程说到了，安全细节会在解析部分详细说明。

Q12：AI 智能客服的 RAG 架构

面试官：

我们要基于大模型搭建一个智能客服，用于：

回答商品相关问题
查询用户订单物流
回答售后政策

你听说过 RAG（检索增强生成） 吗？简单说说：

RAG 的核心流程有哪些步骤？
在 Java 体系中可以用哪些组件/框架（比如 Spring AI）来实现？
向量数据库你了解哪些？比如 Milvus、Chroma、Redis Vector？

小Y：

RAG 我好像在网上看到过，就是先检索再让大模型生成。我知道要先把文档切片，生成向量，存起来。然后问问题时按相似度检索，再拼到 prompt 里。Spring AI 我听说过，但是没用过，向量库就知道个 Milvus，具体怎么用不太清楚......

面试官：

这个回答反而比你前面的一些问题更完整，说明你最近在看 AI 相关的内容，挺好，等会儿我们给一个标准 RAG 流程图解。

Q13：Agent、工具调用与订单查询

面试官：

智能客服不仅要"会说话"，还要"能办事"，比如：

用户问：帮我查一下昨天买的那台 iPhone 的物流到哪儿了？

此时大模型需要：

先理解用户意图
调用后端订单服务接口，查询订单与物流信息
再用自然语言回答用户

这类模式叫 Agent + 工具调用。你能描述一下这套流程在 Java 服务中如何落地吗？比如：

如何定义工具调用标准化接口？
如何在对话中保持上下文（会话内存）？

小Y：

Agent 这个我了解得不多，感觉就是让大模型决定什么时候调哪个接口？然后我们后端暴露一些 HTTP API，它就去调。上下文的话不是也可以用 Redis 存吗......具体实现我还没搞过。

面试官：

可以，知道核心思想，但实现细节比较模糊。解析部分我们会给一个通俗示意。

Q14：AI 幻觉（Hallucination）与企业知识库问答

面试官：

大模型有"幻觉"问题，可能会：

杜撰商品信息
编造售后政策
给出错误的退款流程

你觉得在企业级电商 + 医疗/金融等敏感领域，如何降低幻觉风险？可以从：

检索与知识来源控制
回答内容后处理
审计与日志

三个角度讲讲。

小Y：

这个......我觉得就要让模型只根据我们的文档回答？然后最好加点规则，比如不能随便说"一定可以退款"。日志啥的就把每次对话存下来。具体怎么做我也不是很清楚......

面试官：

方向是对的，我们在解析部分补充一套完整的风险控制策略。

Q15：风控与安全：支付场景

面试官：

在支付与金融服务场景，比如用户频繁下单退款，或者多设备异常登录，需要做风控。简单说说：

你会采集哪些行为数据做风控？
后端 Java 服务、MQ（Kafka）、大数据（Flink/Spark）如何配合？
你如何在代码层面保证日志与事件上报不影响主链路性能？

小Y：

采集数据就采 IP、设备、下单频率啥的。Kafka 可以用来把这些日志发给大数据平台，Flink 做实时计算。至于不影响性能，就异步发一下，或者丢个队列里。更细的我就不太清楚啦......

面试官：

好，基础思路有，工程实现还需要补课。

五、面试结束

面试官：

今天时间差不多了，你在基础 Java 与常用 Spring 技术栈方面有一定基础，对微服务、消息队列和 AI 方向也有一定了解，但在工程落地细节上还有不少提升空间。

我们会在一周内给你反馈结果，你先回去等通知吧。

小Y：

好的好的，那我就先回去把今天你问的都查一遍......

六、标准答案与知识点解析（给读者看的学习部分）

下面是对上述 15 个问题的系统解析，给刚入行或准备面试的同学一个完整的学习路径。

Q1：下单接口设计（Spring Boot + MVC + Service + DAO）

1. Controller 层示意

java 复制代码

@RestController
@RequestMapping("/api/orders")
public class OrderController {

    private final OrderService orderService;

    public OrderController(OrderService orderService) {
        this.orderService = orderService;
    }

    @PostMapping("/create")
    public OrderCreateResponse createOrder(@RequestBody @Valid OrderCreateRequest request,
                                           @AuthenticationPrincipal LoginUser loginUser) {
        return orderService.createOrder(request, loginUser.getUserId());
    }
}

接收 DTO，做参数校验（@Valid）
从登录用户信息中拿 userId
不写业务逻辑，只做"输入输出"转发

2. Service 层职责

java 复制代码

@Service
public class OrderService {

    @Transactional
    public OrderCreateResponse createOrder(OrderCreateRequest request, Long userId) {
        // 1. 校验商品 & 价格
        // 2. 扣减库存
        // 3. 生成订单记录
        // 4. 发送 MQ 消息（订单创建事件）
        // 5. 返回订单号等信息
    }
}

业务编排与事务控制集中在 Service
可以调用多个 Repository/Mapper

3. DAO/Mapper 选型：MyBatis vs JPA

MyBatis 适合：
- SQL 控制要求高、性能敏感场景
- 数据库结构复杂，需要手写复杂 SQL
JPA（Hibernate） 适合：
- 快速 CRUD，开发效率优先
- 业务复杂度更在领域对象上而不是 SQL 细节

在大厂电商场景，订单、库存等核心表 通常更偏向 MyBatis（可控性和性能），一些配置、字典表可以用 JPA/Spring Data JPA。

Q2：事务控制（@Transactional）

在 Spring 中常用 @Transactional 加在 Service 方法 上
默认行为：
- 传播行为：Propagation.REQUIRED（如果当前有事务就加入，没有就新建）
- 隔离级别：Isolation.DEFAULT（使用数据库默认，一般 MySQL 是 REPEATABLE_READ）
- 只对 运行时异常（RuntimeException） 触发回滚

注意要点：

建议把事务边界定义在"一个完整业务单元"上，例如"下单"
不要在 Controller 里写事务
同类内部调用事务方法会失效（因为没有经过代理），需要注意设计

Q3：库存超卖解决方案

1. 数据库层面

悲观锁：
sql 复制代码
```
SELECT stock FROM t_sku WHERE id = ? FOR UPDATE;
```
再更新库存，适合并发不是极高的场景。

乐观锁（推荐）：

表结构增加 version 字段或直接用库存字段：

sql 复制代码

UPDATE t_sku
SET stock = stock - 1
WHERE id = ? AND stock > 0;

或使用 version 字段：

sql 复制代码

UPDATE t_sku
SET stock = stock - 1, version = version + 1
WHERE id = ? AND version = ? AND stock > 0;

2. Redis + 分布式锁 / 预减库存

把库存放到 Redis，使用 Lua 脚本保证减库存操作的原子性
大促场景常用"预减库存 "：
- Redis 扣减成功才允许进入下单逻辑
- 后台异步回写数据库或基于消息队列最终一致
使用 Redisson、Redis + Lua 实现分布式锁，控制同一商品的并发修改

3. 综合实践

接口前端：限流 + 降级
Redis 预减库存，防止击穿数据库
数据库使用乐观锁保证最终正确性

Q4：订单查询性能优化

1. 索引设计

常见查询条件：user_id + status + create_time

sql 复制代码

CREATE INDEX idx_user_status_ctime
ON t_order (user_id, status, create_time DESC);

联合索引可以覆盖用户订单分页查询
避免单独给 status 建索引而不包含 user_id，容易导致索引选择不精准

2. 分页实现

MyBatis + limit/offset：

sql 复制代码

SELECT * FROM t_order
WHERE user_id = ? AND status = ?
ORDER BY create_time DESC
LIMIT ?, ?;

大数据量优化：做"基于游标的分页"（即基于上一页最大 create_time），避免深分页：
sql 复制代码
```
SELECT * FROM t_order
WHERE user_id = ? AND status = ?
  AND create_time < ?
ORDER BY create_time DESC
LIMIT 20;
```

3. 缓存策略

针对"最近订单列表"，放到 Redis，key 如：order:list:uid:{userId}
只缓存最近 N 条（如 20 条），避免大列表
更新策略：
- 新订单创建时写入缓存
- 状态变更时更新缓存
- 超时自动过期（例如 5--10 分钟）

Q5：日志与链路追踪

1. 日志框架

常用：SLF4J + Logback 或 SLF4J + Log4j2
不直接使用具体实现类，而是使用 LoggerFactory.getLogger() 获取 SLF4J Logger

2. 链路追踪方案

Spring Cloud 环境可以用：
- Spring Cloud Sleuth + Zipkin/Jaeger
Sleuth 会自动：
- 给每个请求生成 traceId 和 spanId
- 通过 HTTP 头、消息队列传递上下文

3. 关键字段记录

traceId、spanId
userId、订单号、请求 URL、参数摘要
异常栈信息

配合 ELK（Elasticsearch + Logstash + Kibana）可以进行全链路日志搜索与分析。

Q6：微服务拆分与 Spring Cloud

1. 服务注册与发现

选择：Eureka、Consul、Nacos
目前社区趋势：Nacos 更流行（同时做配置中心）

2. 配置中心

Spring Cloud Config
Nacos Config

3. 熔断与限流

早期：Netflix Hystrix（已停更）
现在：Resilience4j、Spring Cloud Circuit Breaker，或者 Sentinel（阿里开源，支持限流降级 RT/QPS 等）

4. 服务间调用

OpenFeign：声明式 HTTP 客户端
也可选 gRPC/Thrift 做高性能 RPC

Netflix OSS vs Spring Cloud Alibaba（简化对比）：

Netflix OSS（Eureka、Zuul、Ribbon、Hystrix）逐渐淡出主流
Spring Cloud Alibaba（Nacos、Sentinel、Gateway、RocketMQ 等）在国内生态广泛

Q7：Kafka 解耦订单事件

1. Topic 设计

order-created：订单创建事件
order-paid：订单支付成功

2. 消息格式（JSON 示例）

json 复制代码

{
  "eventType": "ORDER_CREATED",
  "orderId": 123456,
  "userId": 10086,
  "status": "CREATED",
  "createdAt": "2026-04-08T12:00:00Z"
}

3. Java 发送与消费

java 复制代码

// 发送
@Autowired
private KafkaTemplate<String, String> kafkaTemplate;

public void publishOrderCreated(Order order) {
    String payload = objectMapper.writeValueAsString(order);
    kafkaTemplate.send("order-created", order.getId().toString(), payload);
}

// 消费
@KafkaListener(topics = "order-created", groupId = "notification-service")
public void onOrderCreated(String message) {
    // 反序列化并处理
}

4. 幂等性处理

为每条消息生成唯一 eventId（可用 orderId + eventType）
消费端维护"已处理事件表"或 Redis 集合
消费前检查是否已处理，避免重复发短信、重复扣减积分

Q8：Elasticsearch 与订单搜索

1. 索引示例（简化）

json 复制代码

PUT order_index
{
  "mappings": {
    "properties": {
      "orderId": {"type": "keyword"},
      "userId":  {"type": "keyword"},
      "productName": {"type": "text", "analyzer": "ik_max_word"},
      "createdAt": {"type": "date"}
    }
  }
}

2. Java 客户端

Spring Data Elasticsearch：风格类似 Spring Data JPA
官方 Java API Client（新）：替代旧的 RestHighLevelClient

3. 数据一致性

常用方案：

订单写入 MySQL 成功后，发送 Kafka 事件
一个独立的"索引同步服务"消费 Kafka：
- 对 ORDER_CREATED 写入 document
- 对 ORDER_UPDATED 部分更新
- 对 ORDER_CANCELED 做软删除或删除 document

这样保证 MySQL 是源数据，ES 是"搜索副本"，通过消息实现最终一致。

Q9：Redis 存储客服会话

1. key 设计

chat:session:{sessionId} 存会话元数据
chat:history:{sessionId} 存最近若干轮对话

2. 数据结构

元数据可用 Hash：
- userId
- currentOrderId
- lastActiveTime
对话历史可用 List：
- LPUSH chat:history:{sessionId} messageJson
- 控制长度：LTRIM chat:history:{sessionId} 0 19

3. 过期策略

设置 session key 过期时间（如 30 分钟无操作自动清理）：
shell 复制代码
```
EXPIRE chat:session:{sessionId} 1800
EXPIRE chat:history:{sessionId} 1800
```

Q10：Docker、Kubernetes 与弹性扩缩容

1. Dockerfile 示例

dockerfile 复制代码

FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY target/app.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java","-XX:+UseContainerSupport","-jar","app.jar"]

2. Kubernetes HPA（简化 YAML）

yaml 复制代码

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60

依据 CPU 利用率自动扩缩容，也可以接入自定义指标（如 QPS、Kafka 消费堆积等）。

3. CI/CD 流程（Jenkins 示例）

步骤：
1. 拉取代码（Git）
2. mvn clean package -DskipTests
3. docker build & docker push
4. kubectl apply -f k8s/deployment.yaml

Q11：Spring Security + JWT 鉴权

1. 登录流程

用户提交 username + password
Spring Security 通过 UserDetailsService 加载用户并校验密码
认证通过后生成 JWT：
- 包含 userId、username、角色等
- 设置过期时间 exp
返回给前端，前端保存在 LocalStorage / Cookie

2. JWT 内容与安全

不要放敏感信息（如明文手机号、银行卡）
使用签名（HS256/RS256），防止篡改
可以增加：tokenId（jti）、签发时间（iat）、过期时间（exp）

3. 请求携带与校验

前端在 Authorization: Bearer <token> 中携带
服务端通过过滤器解析 token：
- 验证签名和过期时间
- 解析出用户信息放入 SecurityContext

可选：引入"刷新 token"机制，接近过期时给新 token。

Q12：RAG（检索增强生成）架构解析

核心流程：

文档加载与切片：
- 企业文档、FAQ、商品说明书、政策条款等
- 用工具（如 Spring AI、LangChain4j）将文档切成小 chunk
向量化（Embedding）：
- 使用嵌入模型（OpenAI Embedding、Ollama、本地模型）把文本 chunk 转成向量
向量数据库存储：
- Milvus、Chroma、Redis Vector（Redis 7 向量索引）
查询时流程：
- 用户提问
- 将问题向量化，去向量库做相似度检索
- 取回若干相关文档片段
- 将这些片段拼接到 prompt 中，喂给大模型
- 大模型基于真实文档生成答案

在 Java 中的实现：

使用 Spring AI ：
- 提供统一接口调用模型与向量库
- 支持文档加载、RAG 工作流
结合 Redis/Milvus 等存储向量

Q13：Agent、工具调用与会话内存

1. Agent 模式

大模型不仅生成文本，还能"决策"：
- 是否需要调用工具（查询订单、调用支付接口等）
- 调用哪个工具，用什么参数

2. 工具调用标准化

在后端定义一组标准接口，例如：

java 复制代码

public interface OrderQueryTool {
    OrderInfo getLatestOrderByProductName(Long userId, String productName);
}

通过类似 MCP（模型上下文协议）或自定义 schema，把这些工具描述暴露给大模型：

工具名称
参数结构
返回结构

大模型根据自然语言生成对工具的调用参数，后端执行后再把结果返回给模型继续生成自然语言回答。

3. 对话会话内存

使用 Redis 保存：
- 最近 N 轮问答
- 当前关注的订单号等"对话状态"
每次请求：
- 先加载会话历史
- 与最新问题一起构造 prompt
- 调用大模型
- 更新会话历史

Q14：AI 幻觉控制与企业知识问答

1. 检索与知识来源控制

严格基于企业知识库（RAG 检索结果）来回答
Prompt 中明确指示：
- "只能基于给定文档回答问题"
- "对于文档中没有的信息回答：我不知道或建议联系人工客服"

2. 回答内容后处理

对涉及 支付、退款、药品、医疗建议 的回答进行规则校验：
- 不得使用"保证""百分之百"等词
- 不得给出具体诊断方案
关键问题可以要求多次检索与多模型交叉验证

3. 审计与日志

对每次对话记录：
- 用户问题
- 检索到的文档片段
- 模型回答
- 工具调用记录
方便事后审计与质量监控

Q15：风控与大数据实时分析

1. 数据采集

登录行为：IP、设备指纹、地理位置
下单行为：下单频率、金额、商品类型
支付行为：支付失败次数、支付通道

2. 技术链路

Java 服务将事件发到 Kafka（行为日志、业务事件）
实时计算：Flink 消费 Kafka，实时计算风险分、识别异常模式
离线分析：Spark/Hadoop 做长期数据挖掘

3. 主链路性能保护

事件上报使用异步调用：
- 本地队列 + 批量发送
- 或直接异步写 Kafka
即使风控系统短暂不可用，也不能影响下单核心流程（容错、降级）

七、总结

通过这场"严肃面试官 vs 搞笑小Y"的面试剧情，我们串联了：

电商业务核心链路（下单、库存、订单查询）
微服务与消息队列（Spring Cloud、Kafka、Redis、Elasticsearch、K8s）
安全与风控（Spring Security、JWT、日志与行为采集）
AI 场景（RAG、Agent、向量数据库、会话内存、幻觉控制）

建议你结合本文的问题和解析，自查一下：

哪些点你可以像"标准答案"一样系统地讲出来？
哪些点你现在还停留在"小Y式模糊印象"？

把这份"面试对话 + 解析"当成一个复习清单，逐项补完，面对大厂 Java + AI 智能客服/电商的岗位时，你会更有底气。