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

背景

海外一年制硕士，本科国内中流 211 计算机，无大厂实习经历，投的是 B站 大模型开发暑期实习（主站技术中心方向），3 月中旬投递，一周后约面，全程 60 分钟，腾讯会议，面试官一人，开场自我介绍 3 分钟。

题目摘要

1. Go 语言基础：slice 的底层结构、扩容规则，以及 map 并发读写为什么会 panic，如何规避。
2. MySQL 八股：聚簇索引与非聚簇索引的区别，什么情况下会走覆盖索引，EXPLAIN 里 type 字段从差到好怎么排序。
3. Redis 八股：缓存穿透、击穿、雪崩的区别与各自应对方案；追问了布隆过滤器误判后怎么兜底。
4. Agent 项目深挖：RAG 检索链路中 chunk 切分策略、embedding 模型选型、召回后如何重排；Function Calling 的工具描述怎么写才能降低误调用率。
5. 推理成本优化：上下文窗口越来越长时怎么做 token 压缩，KV Cache 的基本原理，量化部署有没有实际踩过坑。
6. 手撕算法：给定一个字符串数组，找出所有由相同字母异位词组成的词组（LeetCode 49 变体，要求返回分组结果并按组内字典序输出）。关键思路：对每个字符串排序后作为哈希 key，或统计 26 个字母频次拼成 key，遍历一次分组，最后对每组内部排序。

项目深挖

简历上写了一个基于 RAG 的文档问答 Agent，面试官几乎全程围绕这个项目追问，没有问八股式的"你用了什么框架"，而是直接切到决策细节。

追问一：chunk 切分你用的是固定长度还是语义切分？为什么？

参考回答方向：先说清楚两种方案的取舍——固定长度实现简单、chunk 大小可控，但容易把一句话或一个表格切断；语义切分按段落/标题层级走，召回质量高但 chunk 长度方差大，可能撑爆上下文。然后落到自己的场景：文档以技术文档为主，有明确标题层级，所以用「标题层级 + 最大长度兜底」的混合策略，同时保留 10%–15% 的 overlap 防止边界信息丢失。面试官接着问 overlap 会不会导致重复召回，回答思路是召回去重按文档 ID + chunk 起始位置做，重排阶段再按相关性截断。

追问二：召回之后你怎么保证 LLM 真的用了检索到的内容，而不是自己编？

参考回答方向：分三层讲。Prompt 层明确要求「仅基于给定上下文回答，上下文没有就说不知道」，并给出引用格式；后处理层做答案与引用片段的归因校验，简单场景可以用字符串匹配或小模型判断，复杂场景用 LLM 做一次 self-check；评估层离线用带标注的 QA 对跑命中率和忠实度，线上采样人工抽检。不要只说"我加了 prompt 约束"，要体现你知道这只解决一部分问题。

追问三：Function Calling 的工具多了之后误调用率上升，你怎么处理？

参考回答方向：先定位原因——工具描述语义重叠、参数 schema 不够严格、模型对工具边界理解模糊。对应措施：工具描述里写清楚「什么时候用」和「什么时候不用」，参数用 enum 和 required 收窄；工具数量超过一定阈值时先做一层工具检索，只把相关工具喂给模型；对高风险工具加二次确认或 dry-run。可以补一句：如果模型本身支持并行调用，注意在 prompt 里约束互斥工具的调用顺序。

准备建议

1. 项目按「决策点」重新梳理，不要按时间线讲。面试官不关心你先写了哪个模块，关心你为什么这么选。把 RAG 链路上的切分、embedding、召回、重排、生成每一步的备选方案和取舍理由写成一句话卡片，面试时直接调用。

1. 八股不要背结论，背「为什么」和「边界」。比如 Redis 缓存穿透，布隆过滤器是常见答案，但面试官会追问误判怎么办、布隆过滤器本身怎么更新。每个八股点准备一层追问的答案，比覆盖十个知识点更有用。

1. 手撕算法控制在 15 分钟内写完并自测。B站 这场给的是中等难度哈希题，思路不难，但要求返回结果有序，容易在排序细节上卡住。平时练习时强制自己写完就跑两个边界 case（空数组、单元素），养成习惯，面试时能省掉面试官提示。

结果

一面通过，5 天后约了二面，方向是更偏工程落地的 Agent 系统设计。

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