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

背景

海外一年制硕士，投递字节跳动大模型开发暑期实习，岗位偏应用层（Agent/RAG 方向），一面约 70 分钟，面试官是团队里做 LLM 应用落地的工程师，全程共享屏幕，手撕代码要求可运行。

题目摘要

1. Go 语言基础：slice 的底层结构与扩容策略；map 是否并发安全，为什么；defer 的执行顺序与闭包变量捕获陷阱。
2. MySQL：聚簇索引与二级索引的区别，回表是什么；EXPLAIN 里 type 字段从差到好的排序；一条慢 SQL 的排查路径。
3. Redis：缓存穿透、击穿、雪崩的区分与各自解法；为什么用 SETNX 做分布式锁要配合过期时间和唯一 value。
4. RAG 项目深挖：文档切分策略怎么定的、召回效果怎么评估、有没有做过 rerank、幻觉怎么压。
5. Function Calling / 上下文管理：工具数量变多后怎么选工具、多轮对话上下文超长怎么截断、怎么控制推理成本。
6. 手撕算法：给一个字符串数组，找出所有由相同字母异位词组成的词组（即 LeetCode 49 变体），要求用哈希表 + 排序后的字符串作 key，时间复杂度 O(n·k log k)，并追问如果字符集只有小写字母能否优化到 O(n·k)。

项目深挖

追问一：你的 RAG 系统里 chunk 是怎么切的，为什么这么切？

参考回答方向：不要只说"按 512 token 切"。要讲清楚切分粒度和检索粒度的矛盾——切太小语义不完整、召回噪音大，切太大 embedding 稀释、命中率下降。可以说明自己用的是"按标题层级 + 递归字符切分"的混合策略，chunk 之间保留 overlap，并且针对表格、代码块做了特殊处理（不拆断）。如果做过对比实验，直接给数字：比如 chunk 从 512 降到 256 后，召回率变化多少、答案准确率变化多少。面试官真正想听的是你有没有用数据驱动的方式定参数，而不是拍脑袋。

追问二：召回不准的时候你怎么定位是 embedding 的问题还是切分的问题还是 query 的问题？

参考回答方向：分层排查。先看 bad case 里正确答案是否在 top-k 召回结果中——不在，说明是召回阶段问题（embedding 或切分）；在但没被用上，说明是排序或 prompt 的问题。召回阶段再拆：把原始 query 直接拿去检索，如果命中说明是 query 改写/扩展环节引入的偏差；仍不中就看 chunk 里是否包含答案，包含说明 embedding 语义匹配弱，可以考虑换模型或加 BM25 做混合检索。这套"分段归因"的思路比单点答案更能体现工程能力。

追问三：Function Calling 工具多了以后，模型选错工具或参数怎么处理？

参考回答方向：几个层面。一是工具描述本身要写清楚，包括什么时候用、什么时候不用、参数示例；二是工具数量超过一定阈值后不要全量塞进 prompt，先做一层工具检索（用 embedding 匹配 query 和工具描述）选出 top-n 再给模型；三是加参数校验和重试，模型给的参数不合法时把错误信息回灌让它重试，而不是直接失败；四是关键路径上做兜底，比如用规则或小模型做意图分类，避免完全依赖大模型选工具。可以补一句成本考量：工具全量塞进去会显著增加 input token，直接影响推理成本和延迟。

准备建议

1. 八股要能讲到"为什么"而不是"是什么"。比如被问 map 并发安全，不要只答"不安全，要加锁"，要能说到 Go runtime 里有 hashWriting 标志位做并发写检测、检测到会直接 fatal error 而不是 panic，以及为什么官方选择 fatal 而不是返回 error。面试官追问一层就能区分背题和理解。

1. 项目准备一份"数据版"和一份"踩坑版"。数据版：每个技术决策背后的对比实验和指标变化，哪怕是自己离线测的小样本也要有数。踩坑版：至少准备 2 个真实翻车案例（比如某次上线后召回率暴跌、某类 query 一直答错），讲清楚怎么发现、怎么定位、怎么修。面试官对"一路顺利"的项目天然不信任。

1. 手撕题按"能跑 + 能优化 + 能讲复杂度"三层准备。字节一面手撕通常不难，但要求代码规范、边界处理完整。刷题时养成习惯：写完先自己口述测试用例（空输入、单元素、重复元素），再主动说时间空间复杂度，最后提一句"如果数据规模变大可以怎么优化"。这三点做到，手撕环节基本不会扣分。

结果

一面通过，3 天后约了二面。

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