【Spring Boot+Spring Cloud+Kafka+Redis+RAG】大厂面试实战：严肃面试官 vs 搞笑水货程序员小Y

场景：某头部电商+内容社区双线发展的互联网大厂，招聘 Java 开发。面试分三轮，每轮围绕一个完整业务场景展开：

  • 第一轮：电商下单链路（微服务 + 缓存 + 消息队列）
  • 第二轮：支付与风控（安全、日志、监控、链路追踪）
  • 第三轮：AIGC 智能客服 & RAG（向量数据库 + Embedding + Agent）

出场人物：

  • 面试官：语气严肃但不刻薄，会适当引导。
  • 小Y：自称“3 年经验”，实则复制粘贴工程师，简单问题能答，复杂问题就开始跑火车。

第一轮：电商下单链路（微服务 + 缓存 + 消息队列）

场景：双十一大促电商场景，用户从 App 下单到订单入库、库存扣减、消息通知全链路。

第一轮·问题 1：Spring Boot & Spring Cloud 微服务拆分

面试官：

我们先从一个简单的电商下单场景开始。假设你负责的是 订单中心，整体是基于 Spring Boot + Spring Cloud 的微服务架构。你会怎么拆分服务？以及在 Spring Cloud 里一般会用到哪些组件？

小Y：

嗯……这个简单嘛。我们一般就是：用户服务、订单服务、商品服务、库存服务、支付服务……都用 Spring Boot 起微服务，然后用 Spring Cloud。组件嘛，呃……有 Eureka、Ribbon、Feign、还有那个，呃，Gateway？反正就是注册中心、配置中心，还有个啥……反正都能自动发现、自动负载均衡那种。

面试官（点头）：

大方向可以，但如果让你具体设计一下 订单服务 的 REST 接口，会怎么设计？比如用 Spring MVC 或 Spring WebFlux 的注解写一个下单接口？

小Y：

这还不简单，@RestController 然后 @PostMapping("/order")，参数写个 DTO，就 orderService.createOrder(dto)。WebFlux 的话就返回 Mono，比如 Mono<OrderVO>。

第一轮·问题 2：Redis 缓存与热点商品

面试官：

双十一大促会有很多 热点商品，你打算在订单或商品详情这块加缓存。我们给你 Redis，问两个点：

  1. 你会缓存哪些数据？怎么设计 key？
  2. 用 Spring Cache 或者直接使用 jedis/lettuce？会选择什么序列化方式？

小Y：

缓存啊，就缓存那个商品详情和库存数字嘛。key 就 product:{id}，然后用 Redis 存 JSON。Spring Boot 不是有 @Cacheable 嗯……加一下就好了。

连接的话就随便来个 starter，用默认的就可以了，比如 Jackson 啊，Gson 啊，都差不多……

面试官（微微皱眉）：

那缓存和数据库同步不一致的时候，你会怎么处理？比如缓存击穿、缓存雪崩这种，你听说过吗？

小Y：

啊，这个……嗯，缓存嘛，实在不行就删掉重建就好了。雪崩的话……呃，可能就是加个随机过期时间吧，具体我觉得线上看监控调一调就行了。

第一轮·问题 3：Kafka 异步下单与库存扣减

面试官：

高并发下单时，为了削峰填谷，我们会把部分逻辑做成 异步处理。比如：下单请求先写入队列，再异步扣减库存、发送通知。假设我们用 Kafka，你会怎么设计 topic 和消费者？

小Y：

Kafka 这个我会啊，我们就搞一个 order-created topic，然后一个消费者服务订阅，消费之后扣库存。再搞一个 stock-deducted topic 通知别的服务。消费者就用 Spring Kafka 写个 @KafkaListener 啊，然后 groupId 啊，topic 啊，对上就行。

面试官：

那订单服务如何保证 幂等性？比如消息重复消费，你怎么处理？

小Y（开始飘）：

这个嘛，一般线上不会怎么重复吧？就，Kafka 其实很稳定的。实在不行就……加个分布式锁，或者在数据库加个唯一索引，顶多失败就 retry 呗。

面试官（语气稍冷）：

好，下一个问题。

第一轮·问题 4：数据库与 ORM 选择

面试官：

我们订单服务用的是 MySQL，你更偏向用 MyBatis 还是 JPA + Hibernate？给一个简单的订单表结构，写一个插入订单的示例代码或者伪代码。

小Y：

我比较喜欢 MyBatis，直接写 SQL 稳一点。比如：

<insert id="insertOrder" parameterType="Order">
  INSERT INTO t_order(user_id, product_id, amount, status)
  VALUES (#{userId}, #{productId}, #{amount}, #{status})
</insert>

然后在 Mapper 接口里面调一下就好了。

面试官（点头）：

这个还可以。那如果我们用 Spring Data JPA 呢？

小Y：

哦，那就 @Entity 一下，@Id，然后搞个 OrderRepository extends JpaRepository<Order, Long> 就能 save(order) 了。

第一轮·问题 5：接口测试与自动化

面试官：

订单服务的接口上线前，你会怎么用 JUnit 5 + Mockito 做单元测试？以及，用什么工具做接口自动化测试？

小Y：

单元测试啊，就 @SpringBootTest 写，@MockBean 注入。然后 when(orderRepository.save(..)).thenReturn(..)。接口测试就 Postman、Swagger UI 点点……再高级一点就用 JMeter 压测。

面试官（露出一丝笑意）：

好，第一轮先到这里。

第二轮：支付与风控（安全、监控、日志、链路追踪）

场景：电商平台接入支付（支付宝/微信），需要风控、日志、监控，防止刷单与作弊。

第二轮·问题 1：Spring Security + JWT 登录鉴权

面试官：

支付前必须登录。请你设计一个基于 Spring Security + JWT 的登录方案：

  1. 用户名密码验证流程？
  2. JWT 中一般放什么信息？
  3. Token 刷新策略怎么做？

小Y：

这个我知道，Spring Security 有过滤器，登录的时候 UsernamePasswordAuthenticationFilter，校验用户，成功了就生成一个 JWT。

JWT 里面就放 userId 啊，username 啊，角色之类的。刷新策略就……快过期了就重新登录？或者搞个 refreshToken，大厂都这么干的。

面试官：

那和 OAuth2 的区别你能讲一下吗？比如我们如果希望未来接入三方登录（微信、GitHub），你会怎么选？

小Y：

嗯……OAuth2 更高级一点吧，可以对接第三方。JWT 更轻量？具体差别我觉得……到时候看官方文档就行了（笑）。

第二轮·问题 2：风控规则与 Redis + Kafka

面试官：

假设我们需要一个简单的风控规则：

  • 同一用户 5 分钟内超过 N 笔支付，就触发风控报警；
  • 同一 IP 短时间大量下单，也要告警。

如果你来设计，会如何利用 Redis 和 Kafka？

小Y：

Redis 可以计数嘛，比如 key 是 risk:user:{id}，过期时间 5 分钟，每次支付就 INCR 一下。超过阈值就写个标记，或者发消息到 Kafka 的 risk-alert topic，让风控系统消费。

IP 也差不多，多加一个维度 risk:ip:{ip}。Kafka 就做异步处理，比如给安全团队的系统发，或者写到 ELK。大概这样。

面试官（表情缓和）：

这个答得还不错。

第二轮·问题 3：日志与 ELK / 监控与 Prometheus

面试官：

出过事故的同学都知道，日志非常关键。我们使用 Logback + SLF4J，集中收集到 ELK。

问你几个点：

  1. 日志等级怎么划分？INFO / WARN / ERROR 一般分别记什么？
  2. 如何在日志中打印 traceId，配合 Zipkin/Jaeger 做链路追踪？
  3. Prometheus + Grafana 大概怎么统计订单 QPS？

小Y：

日志就……DEBUG 打详细，INFO 打正常流程，ERROR 打异常嘛。traceId 就在拦截器里生成一个 UUID，放到 MDC 里面，然后日志格式里 %X{traceId} 输出。

Prometheus 的话，就加个 Micrometer 指标，比如 Counter 啊，记录接口调用，然后 Prometheus 抓取，Grafana 画图。具体 yaml 我不太记得了，到时候搜一下配置就好。

面试官（轻叹）：

你回答思路 OK，但细节还是模糊了一些。

第二轮·问题 4：接口幂等与防重放攻击

面试官：

支付回调接口需要做 幂等，防止重复通知，以及防止 重放攻击。你能说一下整体思路吗？

小Y：

幂等嘛，就在数据库里加个状态，比如 PAID 了就不再处理。

重放攻击的话……嗯，应该是签名验证？加个时间戳，超过多少秒就不接受？还有 nonce 之类的随机数。具体……支付平台 SDK 不是都帮我们搞好了吗？

面试官：

好，再来最后一个问题。

第二轮·问题 5：CI/CD 与灰度发布

面试官：

我们的支付服务是跑在 Docker + Kubernetes 上，CI/CD 使用 Jenkins。如何做一个简单的 蓝绿发布 / 灰度发布？

小Y：

Jenkins 构建 Docker 镜像，推到镜像仓库，然后 K8s 部署新版本。灰度的话就……在 Deployment 里先改 replica 数量，让新版本只占一部分流量，比如 10%。流量分配就用 Service，或者用 Ingress 控制一下。

蓝绿发布嘛，就一套旧，一套新，切换负载均衡就行了。K8s 也可以用 kubectl rollout 之类的。

面试官（点点头）：

行，进入第三轮。

第三轮：AIGC 智能客服 & RAG（向量数据库 + Agent）

场景：电商平台有内容社区、商品问答、UGC 评价。公司决定引入 AIGC + RAG 建设智能客服系统，为用户提供个性化问答与推荐。

第三轮·问题 1：什么是 RAG？如何结合 Spring AI？

面试官：

你简历上写了“熟悉 RAG 和 Agent 智能客服”。现在请你：

  1. 用自己的话解释什么是 RAG（检索增强生成）？
  2. 在 Java 生态下，比如用 Spring AI 或者 Google A2A，如何大致搭一套 RAG 流程？

小Y（开始紧张）：

RAG 啊，就是……先检索，再生成。就是说大模型先从向量数据库里把文档查出来，然后再生成答案，这样就不会幻觉……呃，至少少一点。

Spring AI 就是……有点像 Spring Boot Starter，那种把模型调用封装起来的，写个 @Service 调一调就行，比如注入一个 client，传 prompt，它自动帮你调用 Embedding 和 LLM。具体……我没怎么实际用过，但原理就是这样。

面试官：

那向量数据库你会选什么？比如 Milvus、Chroma、Redis？你怎么做 文档分片与向量化？

小Y：

向量库就……Milvus 吧，挺火的。或者直接用 Redis 的 vector 类型。文档分片就按段拆，比如每 500 字一块，然后用 OpenAI 的 embedding 模型生成向量，存进去。

检索的时候就做语义搜索，找相似度最高的几段，拼到 prompt 里让模型回答。

面试官（眉头一皱）：

你这回答听起来有点像背书。

第三轮·问题 2：Agent 智能客服与工具调用

面试官：

我们希望做一个 智能客服 Agent：

  • 能查询订单状态（调用订单服务 API）；
  • 能基于用户聊天上下文记住用户之前的问题；
  • 还能在必要时调用工具，比如发起退款申请。

你能说说大致架构吗？包括：

  • 会话内存怎么设计？
  • 工具调用标准化怎么做？

小Y：

会话内存嘛，就把用户最近几条消息放数据库或者 Redis，再给大模型。或者用那种 conversation buffer……

工具调用就用那种 function calling 吧，统一定义 JSON schema，然后模型输出要调用哪个工具，我们后端解析一下，调用 Java 的 Service，再把结果喂回模型。Agent 就像一个 orchestrator，负责把这些串起来。反正大概……就这么个流程。

面试官：

那你如何处理 复杂工作流？比如：

  1. 模型先查询订单详情；
  2. 再判断是否符合退款规则；
  3. 再创建退款单；
  4. 最后通知用户。

你会用什么方式编排？

小Y（明显卡壳）：

这个……可以……呃，用个状态机？或者一个大的 if-else……或者……用工作流引擎？比如 Camunda 啊，Flowable 啊。Agent 负责一步步调用就行。

具体细节……我觉得需要看业务再设计吧。

面试官（表情冷淡）：

好，我们看最后一个问题。

第三轮·问题 3：如何降低 AI 幻觉？以及安全与风控

面试官：

智能客服如果乱说话是很危险的，尤其是涉及 订单、支付、发货 信息。我们希望尽量降低 AI 幻觉（Hallucination），同时要保证：

  • 不泄露敏感信息；
  • 不放大诈骗风险。

你能说说 RAG + Agent 场景下，你会采取哪些措施？

小Y：

嗯……可以限制模型只基于检索到的文档回答，比如在 prompt 里写“只能根据提供的上下文回复”。然后把用户隐私信息脱敏，像手机号只显示后四位。

幻觉的话……就多检索一点文档？或者让模型回答的时候加个置信度判断？实在不行就提示用户‘请以页面实际信息为准’。

诈骗的话……呃，感觉防不胜防，反正用户支付这种一定要跳转到我们官网或者 App 正式页面，模型只能做解释，不要帮忙直接处理支付之类的。

面试官（看了看简历）：

好，那我们面试差不多到这里。

面试结束

面试官：

今天就先聊到这里。你有一些基础，简单问题还可以，但在 微服务细节、AI 工程落地、运维与监控 上，很多地方还是比较模糊。

我们后续会结合团队需求和其他候选人的情况综合评估。你先回去等通知吧。

小Y：

好的好的，那我就先……回去背两本《Spring 源码解析》再说。

面试知识点与业务场景详解（小白向）

下面按轮次，把上面出现的关键问题拆开讲，适合小白系统学习。

一、第一轮：电商下单链路

1.1 Spring Boot + Spring Cloud 微服务拆分

业务场景：

电商平台常见的服务拆分方式：

  • 用户服务（User Service）：注册登录、用户资料。
  • 商品服务（Product Service）：商品信息、价格、库存展示。
  • 订单服务（Order Service）：下单、订单状态流转。
  • 支付服务（Payment Service）：支付下单、回调。
  • 库存服务（Inventory Service）：库存扣减、回滚。
  • 消息/通知服务：短信、站内信、Push。

技术点：

  • 使用 Spring Boot 快速启动应用。
  • 使用 Spring Cloud 做：
    • 服务注册与发现（Eureka / Consul / Nacos）。
    • 客户端负载均衡（Ribbon / Spring Cloud LoadBalancer）。
    • 服务调用（OpenFeign / RestTemplate / WebClient）。
    • API 网关（Spring Cloud Gateway / Zuul）。
    • 配置中心（Spring Cloud Config）。

示例（Spring MVC 下单接口伪代码）：

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

    private final OrderService orderService;

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

    @PostMapping
    public OrderVO createOrder(@RequestBody CreateOrderRequest request) {
        return orderService.createOrder(request);
    }
}

提示：面试常问“如何划分微服务边界？”，可以从 业务职责单一、数据边界清晰 的角度回答。

1.2 Redis 缓存与热点商品

业务场景：

双十一秒杀，热门商品详情和库存被大量访问，如果每次都查数据库，会：

  • 数据库连接打满；
  • 响应时间变长；
  • 甚至导致数据库崩溃。

技术点：

  • 使用 Redis 做缓存，典型数据：
    • 商品详情（基本不会频繁变化）。
    • 商品库存（变化频繁，需要更谨慎）。
  • Key 设计示例：
    • product:detail:{productId}
    • product:stock:{productId}
  • 借助 Spring Cache 简化缓存操作：
@Service
public class ProductService {

    @Cacheable(value = "productDetail", key = "#productId")
    public ProductDetail getProductDetail(Long productId) {
        // 从数据库查询
    }
}

常见问题：

  • 缓存击穿：某个热点 key 过期，大量请求同时打到 DB。
    • 解决：互斥锁（例如基于 Redis 分布式锁）、后台预热，短期返回旧数据等。
  • 缓存雪崩：大量 key 在同一时间过期。
    • 解决：设置随机过期时间，打散失效时间。
  • 缓存穿透：查询大量不存在的数据。
    • 解决：对不存在的数据写入一个短期的“空值缓存”，或者使用 Bloom Filter。

序列化：

  • 常用：
    • JSON（Jackson / Gson）：易调试，可读性好。
    • JDK 序列化：不推荐，效率低。
  • Spring Data Redis 默认可以使用 Jackson2JsonRedisSerializer。

1.3 Kafka 异步下单与库存扣减

业务场景：

在高并发场景，为了保护数据库和下游服务：

  • 下单请求先写入消息队列（Kafka）；
  • 后台消费者异步处理订单创建和库存扣减。

技术点：

  • Topic 设计：
    • order-created：用户请求创建订单。
    • stock-deducted：库存扣减完成通知。
  • 消费者使用 Spring Kafka：
@KafkaListener(topics = "order-created", groupId = "order-service")
public void handleOrderCreated(OrderCreatedEvent event) {
    // 1. 校验订单
    // 2. 扣减库存
    // 3. 更新订单状态
}

幂等性处理：

  • 使用 业务唯一键（如订单号）+ 数据库约束，防止重复插入。
  • 消费前检查订单状态：
    • 若已处理，则直接返回。
  • 可以加“消费日志表”，记录消息 id 是否处理过。

1.4 MyBatis vs JPA（Hibernate）

比较：

  • MyBatis：
    • 优点：SQL 可控，适合复杂查询、调优；
    • 缺点：手写 SQL 多，开发工作量大。
  • JPA + Hibernate：
    • 优点：面向对象，CRUD 简单，能快速开发；
    • 缺点：复杂查询易出性能问题，需要理解 ORM 原理。

MyBatis 插入示例：

<insert id="insertOrder" parameterType="Order">
  INSERT INTO t_order(user_id, product_id, amount, status)
  VALUES (#{userId}, #{productId}, #{amount}, #{status})
</insert>

JPA 实体示例：

@Entity
@Table(name = "t_order")
public class Order {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private Long userId;
    private Long productId;
    private BigDecimal amount;
    private String status;
}

public interface OrderRepository extends JpaRepository<Order, Long> {}

1.5 JUnit 5 + Mockito 测试

业务场景：

订单创建逻辑复杂：

  • 校验库存；
  • 调用优惠券服务；
  • 插入订单表。

技术点：

  • 用 JUnit 5 写测试类。
  • 用 Mockito mock 掉外部依赖（如库存服务）。
@ExtendWith(MockitoExtension.class)
class OrderServiceTest {

    @Mock
    private InventoryClient inventoryClient;

    @Mock
    private OrderRepository orderRepository;

    @InjectMocks
    private OrderService orderService;

    @Test
    void testCreateOrder() {
        when(inventoryClient.checkStock(1L)).thenReturn(true);

        CreateOrderRequest req = new CreateOrderRequest();
        // 设置参数

        OrderVO vo = orderService.createOrder(req);

        assertNotNull(vo);
        verify(orderRepository).save(any(Order.class));
    }
}

二、第二轮：支付与风控

2.1 Spring Security + JWT 登录鉴权

业务场景：

  • 用户必须登录才能发起支付。
  • 后端 API 需要验证用户身份和权限。

技术点：

  1. 登录流程：
    • 用户提交用户名/密码。
    • 后端验证（读取数据库或用户中心）。
    • 验证成功后生成 JWT，返回给前端。
  2. JWT 内容：
    • sub：用户 ID。
    • username：用户名。
    • roles：角色列表。
    • exp：过期时间。
  3. Token 刷新：
    • Access Token 有较短有效期（如 30 分钟）。
    • Refresh Token 有较长有效期（如 7 天）。
    • 提供刷新接口用 Refresh Token 换新的 Access Token。

注：OAuth2 更适合做统一认证/授权中心，以及第三方登录。本项目内部可以先从 JWT 做起，后续再升级为 OAuth2 + OpenID Connect。

2.2 风控规则：Redis + Kafka

业务场景：

  • 防止黑产，某个用户/某个 IP 在短时间内大量下单、支付。

技术点：

  1. Redis 计数：
    • key：risk:user:{userId}，value 为 N 分钟内的支付次数。
    • 使用 INCR + EXPIRE 实现滑动窗口近似效果。
  2. Kafka 异步告警：
    • 当计数超过阈值，将告警信息发送到 Kafka topic risk-alert。
    • 风控系统订阅该 topic，进一步人工审核或自动拦截。

2.3 日志与 ELK / 监控与 Prometheus

日志：

  • 日志等级：

    • DEBUG：调试用详细日志（线上一般关闭）。
    • INFO：关键业务流程，如“订单创建成功”。
    • WARN：可疑但未严重影响业务的情况，如重试、降级。
    • ERROR：异常、错误，需告警。

  • traceId：

    • 在网关或入口处生成 traceId。
    • 放入 MDC（Mapped Diagnostic Context）。
    • 日志 pattern 中加入 %X{traceId}。

  • ELK：

    • Filebeat/Logstash 收集日志。
    • Elasticsearch 存储，Kibana 展示、搜索。

监控（Prometheus + Grafana + Micrometer）：

  • 使用 Micrometer 在代码中定义指标：
    • QPS：订单接口调用次数。
    • RT：响应时间。
  • Prometheus 定时抓取 /actuator/prometheus。
  • Grafana 配置数据源为 Prometheus，制作看板。

2.4 支付回调幂等与防重放攻击

幂等：

  • 支付平台可能多次回调（网络重试、补发）。
  • 在回调处理中：
    • 根据订单号查询订单状态。
    • 若已是 PAID 或 SUCCESS 状态，则直接返回成功，不重复处理。

防重放攻击：

  • 回调请求中通常包含：
    • 签名字段（signature）。
    • 时间戳（timestamp）。
    • 随机数（nonce）。
  • 服务端校验：
    • 检查签名正确性（结合密钥/公私钥）。
    • 检查 timestamp 是否在合理时间窗口内，比如 5 分钟。
    • nonce 可存入 Redis 防重复使用。

2.5 CI/CD 与灰度发布（Docker + Kubernetes + Jenkins）

业务场景：

新版本支付服务上线，希望：

  • 先在小流量下验证；
  • 没问题后再全量替换。

技术点：

  • Jenkins pipeline：
    1. mvn test 跑单元测试。
    2. 构建 Docker 镜像并推送到仓库（Harbor / Docker Hub）。
    3. 触发 Kubernetes 部署更新（kubectl apply 或 ArgoCD / GitOps）。
  • 灰度发布：
    • Kubernetes Deployment 同时存在 v1、v2 两个版本。
    • 通过 replicas 控制新旧版本实例比例。
    • 配合 Ingress 或 Service 做流量路由。

三、第三轮：AIGC 智能客服 & RAG

3.1 什么是 RAG？

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

流程：

  1. 用户提问。
  2. 对问题做向量化（Embedding）。
  3. 在向量数据库中检索与问题相似的文档片段。
  4. 将检索结果和问题一起作为上下文输入 LLM。
  5. LLM 生成回答，这样回答更贴近业务知识，减少幻觉。

应用场景：

  • 电商 FAQ 问答（退货政策、运费说明）。
  • 企业内部文档问答（SaaS 产品手册）。
  • 医疗、金融等对准确性要求高的领域。

3.2 Java 生态下的 RAG 架构示例（Spring AI）

核心组件：

  • 文档加载：把商品说明书、客服知识库、UGC 内容导入系统。
  • 向量化（Embedding）：调用 OpenAI / 本地模型生成向量。
  • 向量数据库：Milvus / Chroma / Redis。
  • 检索服务：提供语义检索 API。
  • 生成服务：调用 LLM（通过 Spring AI / Google A2A）。

简单流程：

  1. 离线/增量构建索引：
    • 使用 Spring Batch 或定时任务读取文档。
    • 分片（Chunk）为 300–500 字一段。
    • 调用 Embedding 模型生成向量，写入向量库。
  2. 在线问答：
    • 接收用户问题。
    • 生成问题向量。
    • 检索 top-k 文档片段。
    • 将这些片段拼接到 prompt 中调用 LLM。

3.3 Agent 智能客服与工具调用

业务场景：

智能客服不只是回答知识问答，还需要：

  • 查询订单状态；
  • 创建售后工单；
  • 触发退款；
  • 做复杂工作流：查询 → 判断 → 操作 → 通知。

技术点：

  • Agent：可以理解为一个“带决策能力的中枢”，负责：
    • 分析用户意图；
    • 决定是否调用工具（后端 API）；
    • 调整多步工作流。
  • 工具调用标准化：
    • 定义统一的工具描述（name、参数 JSON schema、返回结构）。
    • 模型输出工具调用指令（如 function calling 格式）。
    • 后端解析指令，调用相应 Java Service。

会话内存：

  • 保存用户最近 N 条对话。
  • 可以存：
    • Redis（短期）；
    • 数据库（长期）；
    • 或者使用专门的对话存储结构。
  • 生成回答时，把历史对话作为上下文传给模型。

3.4 降低 AI 幻觉与安全风控

降低幻觉：

  • 使用 RAG：
    • 强制模型“只基于检索结果回答”。
  • 加强提示词（Prompt）：
    • 指定“如果不知道，就说不知道，不要编造”。
  • 对输出做规则校验：
    • 对涉及金额、订单号的回答，和后台真实数据比对。

安全与隐私：

  • 脱敏显示：
    • 手机号/身份证号只显示部分。
  • 权限控制：
    • 通过 JWT / OAuth2 确保用户只能查询自己的订单。
  • 防诈骗：
    • 模型只提供解释，不直接给“转账账号”“汇款链接”。
    • 所有支付动作必须在官方页面完成。

四、小结与学习建议

  1. 从业务场景入手：电商下单、支付、风控、智能客服，每个场景对应一整套技术栈。
  2. 掌握核心 Java 后端栈：Spring Boot / Spring Cloud / MyBatis / Redis / Kafka / Docker / K8s。
  3. 理解 AI 工程化：RAG、向量库、Agent，并不仅仅是会调一个 API，而是要能设计一整套系统。
  4. 多做系统性项目：比如做一个简化版电商 + FAQ 智能客服项目，把文中技术点串起来。

只背 API 和关键词，很容易像小Y一样在复杂问题上“脑子一片浆糊”。真正的大厂面试，更看重你是否能从业务到架构再到实现，讲得清楚、做得出来。

# RAG
Logo
快递鸟一站式物流API解决方案

电商企业物流数字化转型必备！快递鸟 API 接口，72 小时快速完成物流系统集成。全流程实战1V1指导，营造开放的API技术生态圈。

更多推荐

cover

启动优化案例——从 2.8 秒到 0.85 秒的电商元服务实战复盘

avatar 快递鸟社区
cover

电商多店运维：云机24小时挂机频繁掉线、账号无故风控深度原因分析及解决方案

avatar 快递鸟社区
cover

Java 大厂面试实录：Spring Boot + Kafka + Redis + Spring Security + RAG 的电商 AIGC 进阶追问

avatar 快递鸟社区