【Shein】【大模型开发】【暑期实习一面】面经（八股+大模型项目+手撕）

背景

海外一年制硕士，投递时间线是 3 月中旬投递简历，3 月底收到笔试通知，4 月初约面。

题目摘要

• 编程语言基础（Java）：HashMap 底层结构、扩容机制、ConcurrentHashMap 分段锁与 CAS 实现；synchronized 与 ReentrantLock 区别及适用场景
• MySQL/Redis 八股：InnoDB 索引结构为什么选 B+ 树而非红黑树；最左前缀原则底层原理；Redis 缓存穿透、击穿、雪崩区别及各自解决方案
• 大模型/Agent 项目深挖：RAG 检索召回率低如何优化；Function Calling 的触发机制与工具选择策略；多轮对话中上下文窗口溢出如何处理
• 手撕算法：LeetCode 原题变体——实现一个支持过期时间的 LRU Cache（get(key) 与 put(key, value, ttl) 两个方法），要求 get 和 put 平均时间复杂度 O(1)

项目深挖

面试官全程围绕简历上的一个 Agent 项目展开，该项目是一个基于大模型 API 的智能客服系统，集成了 RAG 和 Function Calling 能力。追问密度很高，基本没有给喘息时间。

追问 1：你说检索召回率不高，具体怎么定位的？优化后提升了多少？

参考回答方向：先量化问题，从 62% 提升到 84%，定位手段是抽样 bad case 并人工标注错误类型——发现 70% 的错误是召回相关文档不完整导致生成幻觉。优化路径分三层：第一层是对 query 做改写，增加同义词扩展和意图分类前置；第二层是调整 chunk 切分策略，从固定 512 token 改成按语义段落切分，重叠窗口设为 64 token；第三层是引入 hybrid search，BM25 与向量检索结果做 RRF 融合。面试官追问了 RRF 的 k 值怎么定，以及向量检索的 embedding 模型选型依据，需要能答出实验对比过程。

追问 2：Function Calling 触发不准，经常该调工具不调，不该调乱调，你怎么处理的？

参考回答方向：核心思路是不只依赖模型自身判断，而是加了一层规则前置过滤。具体做法是维护一个工具意图分类器（用 few-shot 微调的小模型或直接规则匹配），先判断用户 query 是否需要调用工具，再决定是否走 Function Calling 流程。另外在 function 描述中增加了触发条件和反例描述，比如查询天气的 function 明确写上“仅当用户询问天气时调用，闲聊场景不要触发”。还提到了对 function 返回结果做校验，如果返回为空或异常，降级为普通对话回复，避免把错误结果暴露给用户。面试官追问了降级策略的触发阈值怎么设，需要回答实际业务中如何通过日志统计工具调用成功率并动态调整。

追问 3：上下文管理怎么做？长对话场景 token 成本怎么控制？

参考回答方向：采用分层上下文管理——系统提示词固定常驻，最近 6 轮对话完整保留，更早的历史做摘要压缩后注入。摘要策略是每 4 轮触发一次异步摘要任务，用一个小模型把历史对话提炼成结构化要点。成本控制方面，对每次请求的 token 消耗做了监控，统计发现 70% 的请求集中在 2k token 以内，于是设了 4k 的硬上限，超限时强制裁剪最早的非关键轮次。面试官追问了摘要信息丢失导致回答质量下降怎么处理，参考思路是引入关键实体和用户意图的持久化存储，摘要时保留这两类信息。

手撕算法

题目是实现一个带过期时间的 LRU Cache，比标准 LRU 多了一个 TTL 参数。

核心思路：在标准 LRU（HashMap + 双向链表）基础上，每个节点额外存 expireTime 字段。get 时先检查是否过期，过期则删除节点并返回 -1；put 时同样先检查过期，插入时记录当前时间 + ttl。为了支持 O(1) 过期检查，可以在 HashMap 的 value 中同时存过期时间，或者在节点中维护。注意点是过期检查的时机——懒删除即可，不需要后台线程扫描，只在访问时判断。另外需要注意 put 更新已有 key 时也要重置过期时间。

面试官会追问：如果同一个 key 被多次 put，旧节点的过期时间怎么处理？答案是在链表删除旧节点时同步清理。

准备建议

1. 项目准备以“量化指标 + 失败案例”为主线。面试官对项目深挖的耐心远超预期，每个优化点都会追问你怎么量化收益、怎么定位问题、有没有对比实验。建议把项目中的每个优化动作都补上前后指标对比，哪怕是自己拍的数字也要逻辑自洽。同时准备 1-2 个“踩坑后修复”的故事，比如 RAG 检索调参失败后如何通过 bad case 分析找到根因，这类叙事比顺风顺水的项目更有说服力。

2. 八股复习聚焦“原理 + 为什么”而非“是什么”。MySQL 索引部分重点准备 B+ 树与 LSM-Tree 对比、联合索引字段顺序对性能的影响；Redis 部分重点准备缓存一致性（先更新 DB 还是先删 Cache）和分布式锁的可靠性问题。面试官问八股时习惯连续追问两层，比如问完缓存穿透会接着问布隆过滤器误判率怎么算、怎么动态扩容。建议用“自己给自己出题”的方式，每个知识点往后推演两到三层。

3. 手撕算法不要只刷原题，要练习变体。这次考的带 TTL 的 LRU 就是经典题的扩展，面试官明显在考察候选人对基础数据结构的理解深度而非背诵能力。建议把高频题（LRU、LFU、TopK、合并区间）都过一遍变体思路，特别是和“时间”“过期”“并发”相关的扩展。写代码时注意边界条件处理，比如 TTL 为 0 或负数时的行为，这类细节最容易丢分。

结果反馈

一面通过，约 3 天后二面，整体面试风格偏工程实践，对项目细节的追问深度明显高于常规八股考察，建议准备时把最多精力放在项目复盘上。

想系统备战大厂大模型/Agent 开发？NiceOffer 提供 SDE+LLM 双轨 1v1 陪跑，合同保底 40w 年薪，文末扫码咨询。