智识神工实习经历 - 面试话术指南

一、实习整体介绍（30秒版本）

“我在智识神工实习期间，负责心理医生知识库项目的后端开发。这是一个 AI 驱动的心理健康服务平台，核心功能是让用户可以和 AI 进行心理咨询对话。

我主要做了几件事：

AI 大模型集成：用 Spring AI 封装了通义、Ollama 等多个大模型的统一调用接口

RAG 混合检索：基于 ElasticSearch 实现了语义+关键词的混合检索，召回率提升 40%

对话历史优化：用时间游标分页解决了深分页性能问题，百万级数据查询从 2.1 秒降到 0.7 秒

接口限流：用 Redisson + AOP 实现了令牌桶限流，保护 AI 接口

这段实习让我对 RAG 系统、大模型应用开发、性能优化 有了深入的实践经验。”

二、八股文融合速查表

八股知识点	项目中的应用场景	引出话术
ElasticSearch 原理	RAG 混合检索	“ES 的倒排索引原理是…”
向量检索	语义匹配	“向量相似度计算用的是余弦相似度…”
MySQL 深分页	对话历史查询	“深分页问题的本质是…”
游标分页	时间游标优化	“游标分页避免了 OFFSET 的问题…”
复合索引	查询优化	“我建了联合索引…”
令牌桶算法	接口限流	“令牌桶和漏桶的区别是…”
AOP 原理	限流注解	“我用 AOP 实现了声明式限流…”
Redis 分布式	Redisson 限流	“Redisson 的 RRateLimiter 底层是…”
策略模式	多模型切换	“我用策略模式封装了多个大模型…”
Rerank 机制	检索结果排序	“Rerank 是二次排序，用交叉编码器…”

三、核心亮点一：AI 大模型集成

问题背景

“我们的系统需要对接多个大模型：通义千问用于生产环境，Ollama 本地模型用于开发测试。

问题是：每个模型的 API 格式不一样，如果在业务代码里写一堆 if-else，代码会很乱，而且每次加新模型都要改业务代码。”

技术方案

“我用 Spring AI + 策略模式 解决：

定义统一的 AiModelService 接口

每个模型实现一个策略类

用 Spring 的 Map<String, Interface> 注入自动收集所有实现

业务代码只调用统一接口，根据配置切换模型”

🎯 融合八股：策略模式

面试官追问：为什么用策略模式？

回答：“策略模式的核心是把算法封装成独立的类，让它们可以互相替换。好处是：

开闭原则：加新模型只需新增策略类，不改原有代码

消除 if-else：不用写条件判断

易于测试：每个策略可以独立单元测试”

四、核心亮点二：RAG 混合检索

问题背景

“心理咨询场景有个特点：用户问题很口语化，比如’我最近心情不好’，但知识库里是专业术语’抑郁情绪’。

纯关键词检索：词不一样，匹配不上 纯向量检索：能匹配语义，但可能召回不相关内容

所以需要混合检索，结合两者优点。”

技术方案

“我设计了三阶段检索架构：

第一阶段：混合召回

关键词检索：ES 的 BM25 算法

向量检索：ES 的 kNN 搜索

两路结果合并去重

第二阶段：Rerank 精排

用交叉编码器对召回结果重新打分

第三阶段：Top-K 截断

取 Top 5 拼接到 Prompt”

效果数据

“- 召回率提升 40%

NDCG 提升 35%

响应时间 < 0.2 秒”

🎯 融合八股：ES 倒排索引

面试官追问：ES 检索原理是什么？

回答：“ES 底层用 Lucene，核心是倒排索引。

传统数据库是正排：文档 ID → 内容倒排索引反过来：词 → 包含这个词的文档列表

比如：'抑郁' → [doc1, doc3, doc7]

搜索时取列表的交集或并集，就能快速找到相关文档。

BM25 在此基础上计算相关性分数，考虑词频、逆文档频率、文档长度。”

🎯 融合八股：向量检索

面试官追问：向量检索怎么实现？

回答：“核心是把文本转成向量，计算相似度。

Embedding：用预训练模型把文本转成 1024 维向量 相似度：余弦相似度 cos(A,B) = A·B / (|A|*|B|) ES kNN：底层用 HNSW 算法，时间复杂度 O(log n)”

🎯 融合八股：Rerank 机制

面试官追问：Rerank 和初次检索的区别？

回答：“初次检索用双塔模型：Query 和 Document 分别编码，快但精度一般。

Rerank 用交叉编码器：Query 和 Document 拼接输入，精度高但慢。

策略是：双塔快速召回 Top 100，交叉编码器精排出 Top 5。”

五、核心亮点三：对话历史查询优化

问题背景

“用户的对话历史会越来越多，产品要求支持分页查看历史记录。

问题：传统的 LIMIT offset, size 在深分页时性能很差。比如查第 10000 页，MySQL 要先扫描前 10000*20 条记录，再丢弃，非常慢。

测试数据：百万级数据，查第 5000 页，耗时 2.1 秒，完全不能接受。”

技术方案

“我用时间游标分页替代传统分页：

传统分页：SELECT * FROM chat_history WHERE user_id = ? ORDER BY timestamp DESC LIMIT 100000, 20

游标分页：SELECT * FROM chat_history WHERE user_id = ? AND timestamp < ? ORDER BY timestamp DESC LIMIT 20

区别是：游标分页不用 OFFSET，直接从上一页最后一条记录的时间戳开始查，走索引，性能稳定。”

索引设计

“我建了复合索引：(user_id, timestamp, session_id)

为什么这个顺序？

user_id 放最前面，因为每次查询都带这个条件

timestamp 放第二，用于游标定位和排序

session_id 放最后，用于覆盖索引，避免回表”

效果数据

“- 查询性能提升 3 倍

百万级数据响应时间从 2.1 秒降到 0.7 秒

无论查第几页，性能都稳定”

🎯 融合八股：MySQL 深分页问题

面试官追问：深分页为什么慢？

回答：“深分页的本质问题是 OFFSET 需要扫描并丢弃大量数据。

LIMIT 100000, 20 的执行过程：

从索引中找到符合条件的记录

扫描前 100020 条

丢弃前 100000 条

返回最后 20 条

OFFSET 越大，扫描的数据越多，性能越差。这是 MySQL 的机制决定的，无法优化。”

🎯 融合八股：游标分页原理

面试官追问：游标分页为什么快？

回答：“游标分页用 WHERE 条件替代 OFFSET。比如上一页最后一条的时间戳是 2024-01-01 12:00:00，下一页查询 WHERE timestamp < '2024-01-01 12:00:00' LIMIT 20。这样 MySQL 直接从索引定位到这个时间点，往前取 20 条，不需要扫描前面的数据。时间复杂度：传统分页 O(offset + limit)，游标分页 O(limit)。”

🎯 融合八股：复合索引最左前缀

面试官追问：为什么索引顺序是 (user_id, timestamp, session_id)？

回答：“遵循最左前缀原则。

这个索引可以支持：

WHERE user_id = ? ✅

WHERE user_id = ? AND timestamp < ? ✅

WHERE user_id = ? AND timestamp < ? ORDER BY timestamp ✅

但不支持：

WHERE timestamp < ? ❌（没有 user_id）

WHERE session_id = ? ❌（跳过了前两列）

我的查询条件是 user_id = ? AND timestamp < ?，正好匹配索引前两列，可以走索引。”

六、核心亮点四：接口限流

问题背景

“AI 接口调用大模型，成本很高（按 Token 计费），而且响应慢。如果不限流：

恶意用户可能刷接口，造成巨额费用

大量请求可能打垮服务”

技术方案

“我用 Redisson RRateLimiter + Spring AOP 实现了声明式限流，底层用 Redisson 的 RRateLimiter，基于 Redis 实现分布式限流。”

1
2
3
4


@RateLimit(key = "ai:chat", limit = 10, window = 60)  // 每分钟10次
public String chat(String prompt) {
    return aiService.chat(prompt);
}

🎯 融合八股：令牌桶 vs 漏桶

面试官追问：令牌桶和漏桶有什么区别？

回答：“两者都是限流算法，但特性不同：

漏桶：

请求进入桶中，以固定速率流出

特点是平滑流量，无论请求多快，处理速度恒定

缺点是无法应对突发流量

令牌桶：

以固定速率往桶里放令牌，请求需要拿到令牌才能执行

特点是允许突发，桶里有令牌就能立即执行

可以设置桶的容量，控制突发上限

我选令牌桶是因为 AI 接口允许一定的突发，比如用户连续问几个问题。”

🎯 融合八股：Redisson 分布式限流

面试官追问：为什么用 Redisson 而不是本地限流？

回答：“因为我们是分布式部署，多个实例。

本地限流（如 Guava RateLimiter）只能限制单个实例，3 个实例就是 3 倍的限流额度。

Redisson RRateLimiter 基于 Redis，所有实例共享同一个限流器，能实现全局限流。

底层原理是用 Redis 的 Lua 脚本实现令牌桶，保证原子性。”

🎯 融合八股：AOP 实现原理

面试官追问：限流注解是怎么生效的？

回答：“通过 Spring AOP 实现。

定义 @RateLimit 注解

写一个切面类，用 @Around 拦截带注解的方法

在切面里调用 Redisson 限流器

限流通过则执行原方法，否则抛异常

Spring AOP 底层用动态代理：

如果目标类实现了接口，用 JDK 动态代理

否则用 CGLIB 生成子类”

七、核心亮点五：可观测性建设

问题背景

“AI 应用有个特点：大模型是黑盒，出了问题很难排查。比如用户反馈回答不好，我们需要知道：

检索到了哪些文档？

Prompt 是什么？

大模型返回了什么？

Token 消耗了多少？”

技术方案

“我搭建了完整的可观测性体系：

监控告警：ARMS（阿里云应用监控）

接口响应时间、错误率

JVM 内存、GC 情况

自定义指标：Prometheus + Grafana

大模型 Token 用量

检索召回率

限流触发次数

日志追踪：

每次请求记录完整的 RAG 链路

检索结果、Prompt、响应都落日志”

🎯 融合八股：Prometheus 指标类型

面试官追问：Prometheus 有哪些指标类型？

回答：“四种：

Counter：只增不减的计数器，如请求总数

Gauge：可增可减的仪表盘，如当前连接数

Histogram：直方图，统计分布，如响应时间分布

Summary：摘要，计算分位数，如 P99 响应时间

我用 Counter 统计 Token 用量，用 Histogram 统计响应时间分布。”

八、口语化面试话术（完整版）

公式：业务背景 → 技术选型原因 → 核心难点实现 → 遇到的坑与解决 → 未来优化方向

【话术一】RAG 混合检索系统

1️⃣ 业务背景（30秒）

“我们做的是一个心理咨询 AI，用户可以和 AI 聊天，AI 会根据专业知识库给出回答。

核心问题是检索：用户说’我最近心情不好睡不着’，但知识库里写的是’失眠症状’、‘抑郁情绪’这种专业术语。

如果用传统的关键词搜索，根本搜不到，因为词不一样。但如果纯用向量语义搜索，又可能召回一些不太相关的内容。

所以我需要设计一个混合检索方案，把关键词匹配和语义匹配结合起来。”

2️⃣ 技术选型原因（1分钟）

“我调研了几种方案：

方案一：纯 ES 关键词检索

用 BM25 算法匹配关键词
问题是：用户口语化表达和专业术语对不上

方案二：纯向量检索

用 Embedding 模型把文本转成向量，计算余弦相似度
问题是：可能召回语义相近但实际不相关的内容

方案三：混合检索 + Rerank（我最终选的）

关键词和向量两路召回，合并结果
用 Rerank 模型二次排序，提高精度

选这个方案是因为它结合了两者的优点：关键词保证精确匹配，向量保证语义理解，Rerank 保证排序质量。”

3️⃣ 核心难点实现（2分钟）

“整个检索分三个阶段：

第一阶段：混合召回

我在 ES 里同时存了原文和向量。查询时并行执行两个搜索：”

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 关键词检索 - BM25
List<Doc> keywordResults = es.search(matchQuery("content", query));

// 向量检索 - kNN
float[] vector = embeddingModel.embed(query);
List<Doc> vectorResults = es.knnSearch("embedding", vector, k);

// 合并去重
Set<Doc> merged = new LinkedHashSet<>();
merged.addAll(keywordResults);
merged.addAll(vectorResults);

“第二阶段：Rerank 精排

召回的结果可能有几十条，但给大模型的 context 不能太长。我用交叉编码器重新打分：”

1
2


// Rerank - 交叉编码器
List<Doc> reranked = rerankModel.rerank(query, merged);

“交叉编码器和双塔模型的区别是：双塔模型分别编码 query 和 doc，交叉编码器把两者拼在一起编码，能捕捉更细粒度的交互，精度更高。

第三阶段：构建 Prompt

取 Top 5 的文档，拼接到 Prompt 里：”

1
2
3
4
5
6
7
8
9


你是一个专业的心理咨询师。根据以下参考资料回答用户问题：

【参考资料】
1. {doc1}
2. {doc2}
...

【用户问题】
{query}

4️⃣ 遇到的坑与解决（1分钟）

“坑一：向量维度不匹配

一开始用的 Embedding 模型输出 768 维，后来换了个模型输出 1024 维，ES 里的旧数据就查不了了。

解决：重新建索引，写了个迁移脚本，把旧数据重新 Embedding 一遍。以后换模型前先评估维度兼容性。

坑二：Rerank 太慢

交叉编码器精度高但是慢，100 条文档 Rerank 要 500ms。

解决：控制召回数量，两路各召回 50 条，去重后大概 70-80 条，Rerank 时间控制在 200ms 以内。

坑三：ES 向量检索版本问题

ES 7.x 的向量检索是插件形式，不太稳定。

解决：升级到 ES 8.x，原生支持 kNN 搜索，性能和稳定性都好很多。”

5️⃣ 未来优化方向（30秒）

“1. Query 改写：用大模型把用户口语化的问题改写成专业术语，提高关键词召回率 2. 多路召回融合：除了关键词和向量，还可以加知识图谱召回 3. 在线学习：根据用户反馈调整 Rerank 模型的权重”

【话术二】对话历史分页优化

1️⃣ 业务背景（30秒）

“用户和 AI 的对话历史需要持久化，产品要求支持分页查看历史记录。

问题是：用户聊得越多，数据越多。有的用户聊了几千条，用传统的 LIMIT offset, size 分页，翻到后面特别慢。

我测了一下，百万级数据查第 5000 页，要 2.1 秒，用户体验完全不能接受。”

2️⃣ 技术选型原因（30秒）

“深分页慢的根本原因是 OFFSET 需要扫描并丢弃大量数据。

LIMIT 100000, 20 实际上要扫描 100020 条，丢弃前 100000 条，只返回最后 20 条。

解决方案有两种：

子查询优化：先查出 ID，再根据 ID 查数据。能优化一些，但还是要扫描
游标分页：用 WHERE 条件替代 OFFSET，彻底避免扫描

我选了游标分页，因为它无论查第几页，性能都是恒定的。”

3️⃣ 核心难点实现（1分钟）

“游标分页的核心思想是：记住上一页最后一条记录的位置，下一页从这个位置开始查。

传统分页：”

1
2
3
4


SELECT * FROM chat_history 
WHERE user_id = 123 
ORDER BY timestamp DESC 
LIMIT 100000, 20

“游标分页：”

1
2
3
4


SELECT * FROM chat_history 
WHERE user_id = 123 AND timestamp < '2024-01-01 12:00:00'
ORDER BY timestamp DESC 
LIMIT 20

“关键是要建好索引：(user_id, timestamp, session_id)

这个索引可以：

通过 user_id 快速定位到这个用户的数据
通过 timestamp 快速定位到游标位置
session_id 作为覆盖索引，避免回表”

4️⃣ 遇到的坑与解决（30秒）

“坑：同一时间戳有多条记录

如果两条记录的 timestamp 完全相同，游标分页可能会漏数据或重复。

解决：游标改成 (timestamp, id) 组合。先按 timestamp 排序，timestamp 相同时按 id 排序。查询条件改成：”

1

WHERE (timestamp < ?) OR (timestamp = ? AND id < ?)

5️⃣ 未来优化方向（30秒）

“1. 缓存热点数据：最近的对话记录访问频率高，可以缓存到 Redis 2. 冷热分离：超过 30 天的历史数据迁移到归档表，减少主表数据量 3. ES 检索：如果要支持全文搜索历史记录，可以同步到 ES”

【话术三】接口限流设计

1️⃣ 业务背景（30秒）

“AI 接口调用大模型，按 Token 计费，成本很高。而且大模型响应慢，如果不限流：

恶意用户刷接口，一天能刷出几千块的账单
大量请求堆积，正常用户也用不了”

2️⃣ 技术选型原因（30秒）

“限流算法有几种：

固定窗口：简单但有临界问题 滑动窗口：平滑但内存占用大漏桶：平滑流量但不能应对突发 令牌桶：允许突发，适合我的场景

我选令牌桶，因为用户可能连续问几个问题，需要允许一定的突发。

实现上用 Redisson RRateLimiter，因为我们是分布式部署，需要全局限流。”

3️⃣ 核心难点实现（1分钟）

“我用 AOP 实现了声明式限流：”

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


// 自定义注解
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface RateLimit {
    String key();
    int limit();      // 令牌数
    int window();     // 时间窗口（秒）
}

// 切面
@Around("@annotation(rateLimit)")
public Object around(ProceedingJoinPoint point, RateLimit rateLimit) {
    String key = buildKey(rateLimit);  // 拼接用户ID
    RRateLimiter limiter = redisson.getRateLimiter(key);

    // 初始化限流器（只执行一次）
    limiter.trySetRate(RateType.OVERALL, rateLimit.limit(), rateLimit.window(), RateIntervalUnit.SECONDS);

    // 尝试获取令牌
    if (!limiter.tryAcquire()) {
        throw new RateLimitException("操作过于频繁");
    }

    return point.proceed();
}

“使用时只需要加注解：”

1
2


@RateLimit(key = "ai:chat", limit = 10, window = 60)
public String chat(String prompt) { ... }

4️⃣ 遇到的坑与解决（30秒）

“坑：限流器初始化重复执行

trySetRate 每次请求都调用，虽然 Redisson 内部做了幂等，但还是有性能开销。

解决：用一个 Set 记录已初始化的 key，只有第一次才调用 trySetRate。”

5️⃣ 未来优化方向（30秒）

“1. 动态限流：根据系统负载动态调整限流阈值 2. 分级限流：VIP 用户限流阈值更高 3. 熔断降级：大模型响应慢时自动降级，返回缓存的通用回答”

九、常见追问及回答

Q1: 为什么选择 ElasticSearch 而不是专门的向量数据库？

“我对比了几个方案：

方案优点缺点

ES 8.x 同时支持关键词和向量，运维成熟向量检索性能不如专业向量库

Milvus 向量检索性能好不支持关键词检索，需要两套系统

Pinecone 托管服务，省心成本高，数据出境问题

我选 ES 是因为：

我需要混合检索，ES 一套系统搞定

公司已有 ES 集群，运维成本低

我的数据量不大（几十万条），ES 性能够用”

方案	优点	缺点
ES 8.x	同时支持关键词和向量，运维成熟	向量检索性能不如专业向量库
Milvus	向量检索性能好	不支持关键词检索，需要两套系统
Pinecone	托管服务，省心	成本高，数据出境问题

Q2: Rerank 模型用的是什么？

“我用的是 bge-reranker-base，是智源开源的中文 Rerank 模型。

选它的原因：

中文效果好，专门针对中文优化

模型不大，推理速度可以接受

开源免费，可以本地部署”

Q3: 游标分页的缺点是什么？

“游标分页有两个限制：

不能跳页：只能上一页、下一页，不能直接跳到第 100 页

需要稳定的排序字段：如果数据会更新，排序可能变化

对于我的场景，对话历史是按时间顺序的，用户也不需要跳页，所以这两个限制可以接受。”

Q4: 限流被触发后怎么处理？

“我做了几层处理：

友好提示：返回’操作过于频繁，请稍后重试’，不是冷冰冰的错误码

重试建议：告诉用户多久后可以重试

监控告警：限流触发次数超过阈值时告警，可能是有人在刷接口

日志记录：记录被限流的用户 ID 和 IP，方便排查”

Q5: 实习期间最大的收获是什么？

“最大的收获是学会了从 0 到 1 做一个完整的功能。

以前在学校做项目，主要是实现功能。实习之后发现，功能只是一部分，还要考虑：

性能：能不能扛住线上流量

成本：AI 接口调用费用怎么控制

可观测性：出了问题怎么排查

兼容性：新功能上线会不会影响老功能

这些是在实际工作中才能学到的。”

十、面试前 Checklist

必须能脱口而出的

实习 30 秒介绍
RAG 混合检索的三阶段架构
深分页为什么慢，游标分页为什么快
令牌桶和漏桶的区别
为什么用 Redisson 而不是本地限流
召回率提升 40%、NDCG 提升 35% 这些数据

最好能说清楚的

ES 倒排索引原理
BM25 算法
向量检索和余弦相似度
Rerank 交叉编码器 vs 双塔模型
MySQL 复合索引最左前缀原则
AOP 动态代理原理

加分项

遇到的坑和解决方案
未来优化方向
技术选型的对比和权衡
可观测性建设的思路

十一、实习经历软性问题（必问）

这部分问题考察的不是技术，而是你的工作态度、团队协作、抗压能力。即使实际经历不多，也要准备好合理的回答。

Q1: 实习期间加班多吗？怎么看待加班？

参考回答：

“实习期间加班不算特别多，但也有过几次。

印象比较深的一次是 RAG 检索功能要上线前，发现召回率不达标，我主动留下来和 mentor 一起排查问题。最后发现是 Embedding 模型的版本问题，换了模型后效果好了很多。那次大概加班到晚上 10 点多。

我对加班的看法是：

如果是因为项目紧急、技术攻关，我觉得是可以接受的，毕竟这也是学习和成长的机会
但如果是因为效率低或者流程问题导致的常态化加班，我觉得应该反思和优化
我会尽量在工作时间内高效完成任务，减少不必要的加班”

Q2: 你的代码是怎么上线的？经历过完整的上线流程吗？

参考回答：

“经历过，我们的上线流程大概是这样的：

1. 开发阶段

在本地开发，用 Ollama 本地模型测试
写完后提交到 Git，发起 Merge Request

2. Code Review

mentor 会 review 我的代码，提出修改意见
我印象比较深的是，mentor 指出我的一个 SQL 没有走索引，让我加了复合索引

3. 测试环境

代码合并到 develop 分支后，自动部署到测试环境
测试同学会做功能测试，我也会自测

4. 预发布环境

测试通过后，部署到预发布环境
预发布环境连的是生产数据库的从库，可以验证真实数据

5. 生产发布

一般是晚上低峰期发布
我参与过一次发布，主要是在旁边看 mentor 操作，学习发布流程
发布后会观察监控，确认没有异常

我学到的是：上线不只是把代码部署上去，还要考虑灰度发布、回滚方案、监控告警这些。”

Q3: 和同事/mentor 是怎么协作的？

参考回答：

“我们团队大概 5-6 个人，我主要和 mentor 还有另一个后端同事协作比较多。

日常协作方式：

每天早上有个 15 分钟的站会，同步昨天做了什么、今天计划做什么、有没有阻塞
有问题会先在飞书群里问，复杂的问题会拉个小会讨论
代码通过 GitLab 的 Merge Request 协作，互相 review

印象比较深的一次协作：做 RAG 混合检索的时候，需要和算法同学配合。他负责调 Rerank 模型，我负责工程实现。我们一起定义了接口格式，他把模型封装成 HTTP 服务，我这边调用。中间遇到过返回格式不一致的问题，我们一起 debug 解决的。

我学到的是：

提前对齐接口和预期，能减少很多返工
遇到问题及时沟通，不要自己闷头搞
文档很重要，接口文档、设计文档都要写清楚”

Q4: 遇到过和同事意见不一致的情况吗？怎么处理的？

参考回答：

“有过一次。

背景是：我在做对话历史分页的时候，想用游标分页，但 mentor 一开始建议用传统的 LIMIT OFFSET，因为实现简单。

我的处理方式：

我没有直接反驳，而是先写了个测试，用百万级数据测了两种方案的性能
测试结果显示，深分页时传统方案要 2 秒多，游标分页只要 0.7 秒
我把测试结果和分析发给 mentor，说明游标分页虽然实现复杂一点，但性能好很多
mentor 看了数据后同意了我的方案，还夸我做事有理有据

我学到的是：

意见不一致很正常，关键是用数据和事实说话
不要情绪化，要尊重对方的经验
最终目标是把事情做好，不是证明谁对谁错”

Q5: 实习期间遇到过什么困难？怎么解决的？

参考回答：

“遇到过几个困难：

技术上的困难：刚开始做 RAG 的时候，对向量检索完全不懂，不知道 Embedding 是什么，kNN 是什么。

我的解决方式：

先看了几篇入门文章，了解基本概念
然后看 ES 官方文档，学习怎么用 ES 做向量检索
不懂的地方问 mentor，他给我推荐了几篇论文
最后自己写 demo 验证，边做边学

工作节奏上的困难：刚开始不太适应，不知道怎么估时间，经常低估任务复杂度，导致 delay。

我的解决方式：

后来学会了把大任务拆成小任务，每个小任务单独估时间
估时间的时候会乘以 1.5 的系数，留一些 buffer
如果发现要 delay，提前和 mentor 沟通，而不是等到 deadline 才说

我学到的是：遇到困难很正常，关键是主动学习、主动沟通，不要等着别人来帮你。”

Q6: mentor 对你的评价怎么样？

参考回答：

“mentor 对我的评价总体是正面的。

他肯定的地方：

学习能力强，新技术上手快
做事有责任心，交给我的任务都能按时完成
代码质量不错，review 的时候问题比较少

他给我的建议：

要更主动地沟通，有问题早点说，不要自己闷头搞
技术深度还要加强，不能只停留在会用的层面，要理解原理
可以多参与技术分享，锻炼表达能力

我的改进：后来我确实更主动了，每周会主动找 mentor 聊一次，同步进度和问题。技术上也开始看源码、看论文，不只是看教程。”

Q7: 为什么从上一家公司离职/实习结束？

参考回答：

“主要是因为实习期到了，要回学校准备毕业的事情。

这段实习我收获很大：

技术上，学会了 RAG、大模型应用开发、性能优化
工作方式上，学会了怎么和团队协作、怎么做 code review、怎么上线
认知上，知道了企业级开发和学校项目的区别

如果有机会，我还是很愿意继续在这个方向深耕的，所以现在在找相关的工作机会。”

Q8: 实习期间有没有主动做过什么事情？

参考回答：

“有的，我主动做了几件事：

1. 写了技术文档 RAG 检索模块做完后，我主动写了一份技术文档，包括架构设计、接口说明、部署方式。后来新来的实习生就是看我的文档上手的。

2. 优化了一个慢查询 有一次我在看监控的时候，发现有个接口响应时间很长，排查后发现是 SQL 没走索引。我主动提了优化方案，加了索引后响应时间从 2 秒降到了 200ms。

3. 分享了一次技术 实习快结束的时候，我在组内做了一次技术分享，讲的是游标分页的原理和实践。虽然有点紧张，但反馈还不错。

我觉得：主动做事不仅能学到更多，也能让 mentor 和团队看到你的价值。”

Q9: 你觉得自己在实习中有什么不足？

参考回答：

“有几个不足：

1. 技术深度不够 很多技术只停留在会用的层面，比如 ES 我会用，但底层的 Lucene 原理不太清楚。后来我开始有意识地看源码和论文。

2. 沟通不够主动 刚开始遇到问题会自己闷头搞很久，后来才学会及时问 mentor。现在我会设一个时间限制，比如一个问题卡了 2 小时还没解决，就去问人。

3. 全局视角不够 我主要关注自己负责的模块，对整个系统的架构了解不多。后来我会主动看其他模块的代码，了解上下游是怎么配合的。

我在持续改进，比如现在会定期复盘，看看哪些地方可以做得更好。”

Q10: 你对这份工作有什么期望？

参考回答：

“我的期望主要有三点：

1. 技术成长 希望能接触到有挑战的项目，比如高并发、大数据、AI 应用这些方向。我不怕难，怕的是没有成长。

2. 团队氛围 希望团队氛围是开放的，大家可以互相学习、互相帮助。我在实习的时候很喜欢和 mentor 讨论技术问题，这种感觉很好。

3. 业务价值 希望做的事情是有价值的，能真正帮助到用户。我在实习的时候做的心理咨询 AI，虽然是 toB 的产品，但想到能帮助到有心理困扰的人，还是很有成就感的。

总的来说，我希望找一个能让我快速成长、做有价值的事情的平台。”

十二、软性问题回答技巧

回答公式：STAR 法则

S（Situation）：背景是什么
T（Task）：你的任务是什么
A（Action）：你采取了什么行动
R（Result）：结果怎么样

几个原则

诚实但有技巧：不用编造经历，但可以把普通经历讲得有亮点
具体比抽象好：说"我优化了一个 SQL，响应时间从 2 秒降到 200ms"比"我做了性能优化"好
展示成长：即使是不足，也要说你怎么改进的
正面积极：不要抱怨前公司、前同事，即使有不好的经历也要正面表达

避免的雷区

❌ “我没怎么加班” → 显得不够投入
❌ “我就是按 mentor 说的做” → 显得没有主动性
❌ “前公司/mentor 不好” → 显得情商低
❌ “我没遇到什么困难” → 显得经历太浅
❌ “我什么都会” → 显得不够谦虚