内容社区UGC平台中的 Java 微服务与AI实践面试：从Spring全家桶到RAG搜索的连环拷问

标题：内容社区UGC平台中的 Java 微服务与AI实践面试：从Spring全家桶到RAG搜索的连环拷问

一、面试背景与场景设定

场景：互联网大厂内容社区与 UGC 平台（类似「图文+短视频」社区），需要招聘一名 Java 后端工程师，负责 Feed 流、评论、点赞、搜索推荐和部分 AI 增强能力（比如智能检索和问答）。

人物：

面试官：严肃、专业，逻辑清晰，对系统架构、性能和 AI 能力有较高要求。
小Y：简历写得天花乱坠，实战一般。简单问题还能答，复杂一点就开始打太极，靠嘴硬和运气撑场面。

面试共 3 轮提问，每轮 3-5 个问题，按照业务场景循序渐进，从基础到微服务到 AI 与 RAG，最后由面试官「回家等通知」。

二、第一轮：基础服务与用户内容流（3问）

场景：用户打开 APP，首页展示关注 Feed + 推荐 Feed，支持图文+短视频，用户可以点赞、评论、收藏。

问题1：整体技术栈与框架选择

面试官：

我们这个 UGC 社区，后端主要是 Java 技栈。假设你来设计首页 Feed 流服务，请你简单说下你会怎么选技术栈？

比如：

Java 版本、Web 框架、ORM、数据库连接池
API 设计与文档
构建与部署方式

小Y：

啊，这个问题比较简单。我一般就是：

直接上 Java 17，毕竟越新越好......（大不了开启预览特性嘛）。
Web 框架就 Spring Boot 搞定，一把梭，RestController 一写接口就能跑。
ORM 肯定是 MyBatis，灵活嘛，SQL 我全手写，性能杠杠的。
数据库连接池就 HikariCP，号称地球上最快的。
接口就 RESTful ，至于文档就随缘吧，写写 Swagger，不写也能调试。
构建工具我喜欢 Maven ，部署直接打 Jar 用 Docker 跑一下就行，Kubernetes 什么的后面再说。

面试官：

还行，整体方向没错，不过：

Java 版本要结合公司现网环境，比如很多生产还在 Java 11，新功能要评估兼容性。
ORM 不一定只用 MyBatis，结合 Spring Data JPA 或 Spring Data JDBC，一些简单 CRUD 可以提效。
文档不能「随缘」，要结合 Swagger / OpenAPI，方便前后端和测试协作。

问题2：Feed 查询与缓存设计

面试官：

首页 Feed 要求：

用户点击首页，首屏返回时间在 200ms 内；
首页包含关注流 + 推荐流；
数据量大，数据库压力大。

你会怎么做缓存设计？涉及的技术可以有：Redis、Spring Cache、Caffeine 等。

小Y：

这个我熟：

把所有 Feed 查询都缓存到 Redis 里，比如 user_feed:{userId}；
然后在应用里再用个 Caffeine 做本地缓存，两级缓存，性能肯定爆炸；
过期时间嘛，就先随便设个 5 分钟，反正刷新一下就好了；
缓存一致性就交给 MQ ......呃，后面再说吧。

面试官：

方向是大致对的，但要更清晰：

Redis 作为分布式缓存，适合存 用户 Feed 列表、热门推荐等；
Caffeine 可以用于热点数据的短期缓存，配合 Micrometer 做命中率监控；
缓存过期策略要区分：
- 用户关注流：偏实时，可使用 短 TTL + 主动失效；
- 推荐流：可通过批量预计算，较长 TTL；
缓存一致性要说明是 「读写策略」（Cache Aside、Write Through等），而不是一句「交给 MQ」。

问题3：点赞与计数的一致性

面试官：

用户对某条内容点赞，我们要实时显示点赞数。假设你用 Redis + MySQL 来存数据，如何保证点赞数基本准确且性能好？

小Y：

这个我以前做过：

点赞就直接 INCR Redis 里的计数，比如 like_count:{contentId}；
然后定时任务再把 Redis 同步回 MySQL；
至于丢不丢我觉得问题不大，用户一般看个差不多就行；
Redis 挂了就先重启一下......

面试官：

想法接近实际方案，但要说明：

Redis 用作 计数缓冲层 ，依靠 INCR 提升写性能；
定时任务或 异步任务（Kafka/RabbitMQ） 批量刷回 MySQL，减少数据库写压力；
要考虑 幂等性 与 故障恢复 ，例如：
- 用 消息队列 Kafka ，Topic 为 content_like_event；
- 消费端使用 Spring Boot + Spring Kafka + Spring Data；
用户看到的是「最终一致」，但重要业务要能回溯。

三、第二轮：微服务、消息队列与监控（4问）

场景：UGC 平台业务变复杂：Feed、评论、点赞、通知、搜索、推荐等拆分为多个微服务，使用 Spring Cloud + Kubernetes 部署，消息队列用 Kafka 和 RabbitMQ。

问题4：微服务拆分与网关设计

面试官：

假设你负责整体后端架构，我们会把服务拆成：

feed-service
user-service
comment-service
like-service
search-service
notification-service

你会怎么做：

网关与服务发现
服务间调用
限流与熔断

可以提到：Spring Cloud、Netflix OSS、OpenFeign、Resilience4j、Kubernetes 等。

小Y：

这个我就比较熟悉了：

直接上 Spring Cloud Gateway 做网关；
注册中心用 Eureka，经典组合嘛；
服务间调用用 OpenFeign，写接口就能调用；
熔断我以前用过 Hystrix，不过现在好像不流行了；
部署就放到 Kubernetes ，加个 Deployment 就完事儿。

面试官：

方向基本可以，但要注意：

Netflix OSS（Eureka/Zuul/Hystrix）部分已经进入维护或停更，要结合 Spring Cloud Alibaba 或 Consul 等方案；
当前主流熔断限流是 Resilience4j，可以在 Feign Client 上配置重试、超时、熔断策略；
Kubernetes 可以配合 Kubernetes Java Client ，以及 GitLab CI/GitHub Actions/Jenkins 做持续部署；
网关层也要接入 Spring Security/OAuth2 做统一认证鉴权。

问题5：消息队列在 UGC 平台中的应用

面试官：

我们的 UGC 平台大量使用消息队列，比如：

用户发布内容后，异步通知关注者；
点赞、评论触发消息中心；
数据统计、埋点日志进入大数据平台。

我们用 Kafka 为主，部分业务用 RabbitMQ。你能说说：

Kafka、RabbitMQ 的典型使用场景区别？
在 Java 中你怎么集成？（Spring Kafka、Spring AMQP、JMS 等）

小Y：

Kafka 就适合大吞吐、日志那种，RabbitMQ 就适合轻量级的，比如发个短信啥的。

Java 集成的话：

Kafka 就用 Spring Kafka ，配置一下 bootstrap servers，然后写个 @KafkaListener；
RabbitMQ 我就用 Spring AMQP ，加个 @RabbitListener 就可以；
JMS 我觉得有点老了，现在很少用（反正我没怎么用过......）。

面试官：

回答还算到位，不过可以补充：

Kafka 适合 日志、行为数据、流式处理 ，配合 Flink/Spark;
RabbitMQ 适合 可靠消息、延时重试等场景；
对于 Java：
- Kafka 用 Spring Kafka，或者原生 Kafka Client；
- RabbitMQ 用 Spring AMQP 或直接使用 Rabbit Java Client；
如果涉及 ActiveMQ / Pulsar / JMS，也要知道大致生态。

问题6：日志与链路追踪

面试官：

微服务环境下，请求会在多个服务之间调用。我们需要知道：

用户打开首页，到底调用了哪些服务？
哪个服务变慢？

你会怎么做：

日志体系（Logback/Log4j2/SLF4J）；
链路追踪（Jaeger/Zipkin）；
度量监控（Prometheus+Grafana, Micrometer）。

小Y：

日志的话，我一般默认用 Logback，因为 Spring Boot 默认就带；

链路追踪的话，就加个 Zipkin 的依赖，配置一下 URL；

监控的话，就把 Actuator 打开，用 Prometheus 抓一下，然后画个 Grafana 看看；

至于链路 ID 啥的，Spring Cloud 好像会自动帮我传，我就没管太多。

面试官：

核心方向正确，但要说明：

日志层：统一用 SLF4J 接口 + Logback/Log4j2 实现，注意日志级别和规范化（JSON 日志方便 ELK 分析）；
链路追踪：
- 使用 Spring Cloud Sleuth + Zipkin/Jaeger；
- 请求头透传 TraceId、SpanId；
指标监控：
- 使用 Micrometer 统一输出到 Prometheus；
- 配合 Grafana 做仪表盘；
日志集中：配合 ELK Stack（Elasticsearch + Logstash + Kibana）。

问题7：接口测试与自动化

面试官：

我们要求重要接口要有自动化测试，包含：

单元测试
集成测试
接口契约测试

你平时怎么做？用过哪些测试框架？比如 JUnit 5, Mockito, AssertJ, Spring Boot Test, Selenium, Cucumber 等。

小Y：

测试嘛......我觉得最好的测试就是直接打断点 F8（咳）。

当然，我也会写点测试：

单元测试用 JUnit 5；
Mock 依赖的时候用 Mockito；
集成测试就用 Spring Boot Test ，@SpringBootTest 一加，整个应用都起来；
Web 自动化的话，以前搞过 Selenium，不过挺麻烦的；
BDD 什么的，用过一次 Cucumber，感觉写故事比写代码还累，就没坚持了。

面试官：

测试是质量的底线，不是「可有可无」。可以补充：

使用 JUnit 5 + AssertJ 提高断言可读性；
使用 JUnit Pioneer 提升测试扩展能力（比如额外注解、参数化）；
对于接口，配合 REST Assured 或 Spring MVC Test 做接口层测试；
持续集成中接入 GitLab CI/Jenkins/GitHub Actions 自动执行测试。

四、第三轮：搜索、推荐与 AI RAG（5问）

场景：平台接入搜索与简单推荐，还希望接入 AI 能力，实现智能问答、内容摘要和企业文档问答，构建 Agentic RAG 能力。

问题8：搜索服务与 Elasticsearch 集成

面试官：

我们有一个 search-service，负责：

全文搜索帖子与评论；
按话题、标签、作者过滤；
按发布时间、热度排序。

底层用 Elasticsearch，你怎么设计 Java 端？

同步数据：写库、ES 如何同步？
查询接口：如何设计？

小Y：

这个我在项目上写过点：

写入的时候，我就直接在业务代码里同时写 MySQL 和 Elasticsearch，保证同步嘛；
查询的时候就用 Spring Data Elasticsearch，或者 REST 客户端，写点 DSL；
ES 索引我就按表结构一人一索引，字段就 text 和 keyword 随便设设；
同步失败的话，再手动跑个脚本对一下就行。

面试官：

核心技术栈没问题，但需要更系统：

写库 + ES 双写存在一致性问题，更建议：
- 业务写 MySQL；
- 通过 Binlog（Canal/Flink）或 Kafka 异步同步到 ES；
通过 Spring Data Elasticsearch / 官方 Java Client 封装搜索逻辑；
索引设计要考虑：
- 分词（中文用 IK/自定义分词）；
- 字段类型（text+keyword 组合，用于搜索+聚合）；
查询接口设计为 REST API，返回分页结果、聚合结果等。

问题9：推荐与缓存/队列结合

面试官：

我们有一个简单的推荐服务：

基于用户历史行为（点击、点赞、收藏）；
基于内容热度（全站热门）。

你如何用：

Redis 做热门榜缓存；
Kafka 采集行为日志；
简单地生成推荐列表？

小Y：

这个我觉得就：

用户行为事件发到 Kafka ，比如 user_action_topic；
然后用个 Flink 或者自己写个消费者统计个排行榜；
排行榜存 Redis 的 Sorted Set ，比如 zset:hot:content；
推荐的时候就从 Sorted Set 里取前 100 个，给用户随便发点......

面试官：

思路 OK，但要注意：

Kafka 的消费可以：
- 实时流计算（Flink/Spark Streaming）；
- 或者使用 Spring Boot + Kafka + Redis 做简化版；
Redis Sorted Set 存热门内容 ID + 分数（权重由点击、点赞等行为加权）；
推荐列表可以与「个性化推荐」结合：
- 个性化靠用户行为；
- 热门榜作为兜底；
最终通过 API + 缓存 对外输出推荐结果。

问题10：AI 搜索与 RAG 架构

面试官：

我们希望在 UGC 平台中增加一个「智能问答」：

用户可以用自然语言提问，比如「帮我找最近关于微服务实践的帖子」。
系统要能理解语义并返回相关内容，还能生成答案摘要。

我们计划采用 RAG（检索增强生成） 架构，请你从：

文档加载与向量化；
向量数据库选型；
检索与生成流程；
如何在 Java 中落地（Spring AI、RAG、Agent 等）；

简单描述一下你的方案。

小Y：

这个我研究挺久的（其实没怎么上生产）：

我会把所有帖子内容用 Embedding 模型转成向量；
向量数据库就上个 Redis，反正它现在也支持向量；
检索的时候就根据用户问题做向量检索，然后把找到的内容丢给大模型，让它生成答案；
Java 里就用个 SDK 调一下 OpenAI，然后写点逻辑就可以了；
具体的什么 RAG、Agent 之类的，我觉得都是包装，本质就那样......

面试官：

你把 RAG 说成「就那样」，有点轻视了。不过方向勉强及格。更完整一点应该是：

文档加载：
- 使用 文档加载器 （比如从 MySQL、ES、对象存储中批量拉取内容）；
- 将内容切分成 chunk，附带 metadata（作者、话题、时间）；
向量化：
- 使用 Embedding 模型（OpenAI、Ollama、本地模型）；
- 通过 Java SDK 或 HTTP Client (Retrofit/RestTemplate/WebClient) 调用；
向量数据库：
- 可选：Milvus、Chroma、Redis（向量索引） 等；
检索与生成：
- 接收用户问题 -> 向量化 -> 语义检索 -> 选出最相关的文档 -> 提示填充（Prompt） -> 调用大模型生成回答；
- 使用 RAG Pipeline 组合上述步骤；
Java 落地：
- 使用 Spring AI 统一调用模型，支持 Chat、Embedding、Tool 调用；
- 实现 Agentic RAG：让 Agent 根据意图决定是否调用搜索、向量检索或业务工具；
- 注意 会话内存（聊天上下文），避免模型「失忆」。

问题11：AI 幻觉与企业文档问答

面试官：

RAG 还有一个关键问题：AI 幻觉（Hallucination）。尤其是我们做「企业文档问答」------比如平台运营规范、内容审核标准等。

你怎么在系统设计层面减轻幻觉？

小Y：

这个嘛......我觉得主要靠模型自己进化吧？

要不就：

多给模型点上下文；
提醒它不要乱编；
实在不行，让它说「我不知道」。

面试官：

现实没这么简单，不能只说「多给点上下文」。可以从：

检索质量：提高向量检索的准确性（分片、重排、Hybrid Search：全文+向量）；
提示设计：
- 明确要求「只基于提供的文档回答」；
- 找不到答案时返回「未找到相关信息」；
工具执行框架：
- 使用 Agent 调用「知识库查询」、「业务接口」等工具；
- 对重要问题增加 二次验证（比如调用业务接口校验结果）；
日志与审计：
- 记录模型输入/输出，通过 ELK 或专用监控 分析幻觉案例；
在 Java 中：
- 用 工具调用标准化 的框架，把业务接口封装成 Tool；
- 使用 Spring AI + MCP（模型上下文协议），让模型通过统一接口访问工具与上下文。

问题12：复杂工作流与智能客服系统

面试官：

最后一个问题，我们希望基于 RAG 和 Agent 搭建一个「智能客服系统」，支持：

内容审核咨询；
UGC 发布规范问答；
针对创作者的成长建议；

并且要支持：

多轮对话（会话内存）；
工具调用（比如查订单、查收益）；
审核工单流转（复杂工作流）。

你会如何在 Java 后端设计这个系统？尽量提到：

Spring AI / Agent / 会话内存
工具执行框架
工作流引擎（如基于 Spring + 状态机）

小Y：

这个......我觉得就：

前端一个聊天框；
后端一个大模型接口；
需要查订单的时候，模型就说「帮我查订单」，然后我在后端写点 if-else 调下订单服务；
工单流转就一个表加个状态字段，改一改就行了；

复杂工作流的话，我感觉太复杂反而不好维护，还是越简单越好......

面试官：

你的回答太「理想主义」了。更工程化的做法是：

AI 层：
- 使用 Spring AI 把大模型包装成统一接口；
- 定义 Agent ，支持工具调用（Tool 例如：queryOrder, queryIncome, createTicket）；
- 会话内存：存储在 Redis / 数据库，关联用户与会话 ID；
工具执行框架：
- 把业务接口封装为标准 Tool，模型通过 Tool 调用实现「客户端-服务器架构」；
- 通过 MCP（模型上下文协议） 或自定义协议统一工具描述；
工作流层：
- 使用 工作流引擎 或 状态机（Spring Statemachine） 管理审核工单状态（创建、审核、驳回、关闭）；
- Agent 在需要时触发工作流变更；
监控与安全：
- 对敏感操作增加 安全与风控（比如额度限制、风控规则、操作审计）；
- 通过 Prometheus + Grafana + ELK 观测系统行为。

五、面试尾声：回家等通知

面试官：

今天先到这里。你整体上基础还行，很多点知道名词，但工程化和细节掌握不够，比如缓存一致性、RAG 的实际落地、工作流的设计等等。

回去可以重点补下：

Spring Cloud + Resilience4j
Redis 高级用法（向量索引、Sorted Set）
RAG + Agentic RAG + 企业级检索

我们这边会综合评估后，回头邮件通知你结果。

小Y：

好的好的，那我先回去......补个简历。

六、答案与知识点详细解析（给小白看的部分）

下面是对上面问题的「正经解析」，适合学习和系统复习。

1. 基础技术栈与 Feed 服务设计

1.1 Java 版本与平台

常见生产环境：Java 8/11/17 ，版本选择要考虑：
- 现网兼容性
- 公司依赖库支持情况
JVM 调优：
- 垃圾收集器（G1、ZGC 等）；
- 堆大小、线程数控制；
- 可配合 Micrometer + Prometheus 监控 GC 延迟。

1.2 Web 框架

主流选择：
- Spring Boot + Spring MVC：同步阻塞模型，开发效率高；
- Spring WebFlux：基于 Reactor 的响应式模型，适合高并发 IO 场景；
- 其他可选：Jakarta EE、Micronaut、Quarkus 等；
模板引擎：Thymeleaf, FreeMarker, JSP 等适用于 SSR 场景。

1.3 ORM/数据库

ORM 技术栈：
- Hibernate / JPA：适合复杂对象关系映射；
- MyBatis：SQL 可控，常用于核心交易或复杂查询；
- Spring Data JDBC：轻量级；
连接池：
- HikariCP：高性能；
- 其他：C3P0；
版本管理：
- Flyway / Liquibase 维护数据库 Schema 版本。

2. 缓存与计数一致性

2.1 缓存分层

本地缓存：
- Caffeine/Ehcache，提高单机命中率；
分布式缓存：
- Redis：存用户 Feed 列表、热门推荐、会话等；
- 支持 Pub/Sub、Sorted Set、向量索引；
Spring 集成：
- Spring Cache 注解（@Cacheable, @CacheEvict）+ 自定义 CacheManager。

2.2 缓存模式

Cache Aside（旁路缓存）：应用读写逻辑自己控制；
「写数据库、删缓存」的策略：
- 避免「写后读旧数据」；
对 Feed 可以采用：
- 冷数据走数据库；
- 热数据预计算后刷到缓存。

2.3 点赞计数

Redis 计数：
- INCR/DECR 实现高吞吐计数；
异步落库：
- 使用 Kafka Topic，消费端定期批量写 MySQL；
幂等设计：
- 使用消息 ID、幂等表防止重复写入；
最终一致：
- 即使短时间有误差，最终会与数据库同步。

3. 微服务架构与消息队列

3.1 微服务拆分

按领域拆分服务：用户、内容、Feed、评论、点赞、搜索、推荐、通知等；
服务发现与网关：
- Spring Cloud Gateway 做 API 入口；
- 注册中心：Eureka、Consul、Nacos 等；
服务间调用：
- OpenFeign + 负载均衡；
- gRPC/RESTful 结合。

3.2 限流与熔断

使用 Resilience4j ：
- 熔断器（CircuitBreaker）
- 限流器（RateLimiter）
- 重试（Retry）
在 Feign Client 方法上配置策略；
监控熔断情况，避免依赖服务故障放大。

3.3 消息队列

Kafka：
- 用于行为日志、Feed 异步更新；
- 配合 Spark/Flink 做大数据分析；
RabbitMQ：
- 用户通知、邮件、短信等；
ActiveMQ/Pulsar：特定场景备选；
Java 框架：Spring Kafka、Spring AMQP、JMS。

4. 日志、监控与测试

4.1 日志体系

SLF4J 接口 + Logback/Log4j2 实现；
结构化日志（JSON），方便 ELK 分析；
统一 TraceId，贯穿整个调用链。

4.2 链路追踪与监控

Spring Cloud Sleuth + Zipkin/Jaeger：
- 自动注入 TraceId/SpanId；
Micrometer + Prometheus + Grafana：
- 指标采集与可视化；
ELK Stack：集中日志查询。

4.3 测试体系

单元测试：
- JUnit 5 + AssertJ，Mock 依赖用 Mockito/PowerMock；
集成测试：
- Spring Boot Test + 嵌入式数据库；
UI/端到端测试：
- Selenium、Cucumber；
新工具：
- JUnit Pioneer 扩展；
CI/CD：
- Jenkins/GitLab CI/GitHub Actions 自动执行测试与部署。

5. 搜索与推荐

5.1 Elasticsearch 集成

索引设计：
- 根据业务划分索引（帖子、评论等）；
- 字段：text + keyword；
数据同步：
- MySQL 作为主存；
- 使用 CDC（Canal/Flink）+ Kafka 同步到 ES；
Java 客户端：
- Spring Data Elasticsearch 或官方 Java REST 客户端；
分词与评分：
- 中文分词器、字段权重调整。

5.2 推荐系统基础

行为日志：
- 通过 Kafka 收集；
热门榜：
- Redis Sorted Set 存内容 ID + 热度分；
简单推荐：
- 热门榜兜底 + 用户兴趣相似内容；
高级推荐：
- 基于 Spark/Flink 的特征提取与模型训练。

6. RAG、Agent 与 AI 系统

6.1 RAG 架构核心步骤

文档加载（Data Loading）：
- 从数据库（MySQL）、搜索引擎（ES）、对象存储（OSS）加载内容；
文档切分（Chunking）：
- 按字数/段落切片，保留 metadata；
向量化（Embedding）：
- 调用 Embedding 模型（OpenAI、Ollama、本地模型）；
向量存储：
- Milvus、Chroma、Redis Vector、Elasticsearch 向量；
检索（Semantic Retrieval）：
- 根据用户问题向量搜索相似文档；
生成（Generation）：
- 将检索到的文档通过 Prompt 提供给大模型生成答案。

6.2 Java 中的 RAG 实践

Spring AI：
- 统一封装 Chat、Embedding、Tool 调用；
- 简化模型切换（OpenAI、Azure、Ollama）；
工具调用（Tools）：
- 将业务能力（查询订单、查收益等）封装为工具；
- Agent 根据意图选择调用哪些工具；
向量库接入：
- 使用 Java 客户端连接 Milvus/Redis/Chroma；
- 封装统一的 Repository 接口。

6.3 Agentic RAG 与复杂工作流

Agentic RAG：
- Agent 不只是检索 + 生成，而是可以：
  - 调用工具（Tool Execution Framework）；
  - 访问业务接口；
  - 驱动工作流（工单创建、审核流转）；
MCP（模型上下文协议）：
- 提供统一协议，让模型访问工具和上下文；
会话内存：
- 将每次对话存储在 Redis/数据库中；
- 按需截断（防止上下文过长）。

6.4 AI 幻觉与防控

检索增强：
- Hybrid Search（全文 + 向量）；
严格的 Prompt 约束：
- 「只基于提供文档回答，不要编造」；
回答策略：
- 找不到答案要明确说「未找到相关信息」；
审计与监控：
- 记录问题与回答，分析幻觉场景；
风控：
- 敏感操作需二次确认或人工审核。

七、小结

这场面试从：

Java 基础 + Spring Boot 服务
缓存、消息队列、微服务与监控
到 Elasticsearch 搜索、推荐，再到 RAG、Agent 与智能客服

串起了一条典型的 内容社区 + AI 增强 的技术路线。

小Y 虽然有很多地方回答得不够专业，但对正在入门的同学来说，已经涵盖了很多关键点。你可以按本文章的「解析部分」逐个补齐知识：

把 Java 基础 + Spring 生态打牢；
学会用 Redis、Kafka、Elasticsearch 构建可扩展系统；
逐步上手 RAG、向量数据库与 Agent，构建企业级 AI 应用。

当下一次面试官问到这些问题时，至少别再像小Y一样，只会说「差不多」了。