【寒武纪】【大模型开发】【暑期实习三面】面经（八股+大模型项目+手撕）

背景

海外一年制硕士，计算机方向，投递寒武纪大模型开发暑期实习，三面为技术终面，整体节奏紧凑，考察深度明显高于前两轮。

题目摘要

1. Go 语言基础：goroutine 与 channel 的底层实现，GMP 调度模型中 P 的本地队列何时会处于饥饿状态，如何避免。
2. MySQL/Redis 八股：MySQL 的 MVCC 机制在 RR 隔离级别下如何解决幻读；Redis 的持久化策略 AOF 重写触发条件，以及 RDB 与 AOF 混合持久化的优缺点。
3. 大模型项目深挖：基于 RAG 的客服问答系统，追问了检索召回率优化、上下文窗口管理、Function Calling 的异常处理与推理成本优化方案。
4. 手撕算法题：题目为「寻找旋转排序数组中的最小值 II」（LeetCode 154），要求写出二分查找思路并处理重复元素。

项目深挖

面试官对项目细节的追问非常密集，以下为印象最深的三个问题及参考回答方向。

追问一：RAG 检索召回率低，你会如何系统性优化？

参考回答方向：先定位瓶颈在召回还是重排。召回层面，尝试混合检索（BM25 + 向量检索），并调整向量检索的 top-k 与 score 阈值；重排层面，引入 cross-encoder 模型进行精排，同时考虑对用户 query 做改写（如利用 LLM 生成多个子查询）。若数据分布有明显领域特征，可微调 embedding 模型。最后，建立评估集，用 Recall@k 和 MRR 量化每次改动效果。

追问二：Function Calling 过程中，如果模型返回的 JSON 参数格式错误或调用超时，你的兜底方案是什么？

参考回答方向：分三层兜底。第一层，对模型输出做 schema 校验，失败则让模型重新生成，但限制重试次数（如 2 次）；第二层，若重试仍失败，降级为规则匹配，将用户意图映射到预设函数；第三层，若超时，直接返回友好提示并记录日志，用于后续微调数据。同时，在 prompt 中强调输出格式，并给出 few-shot 示例，从源头降低出错概率。

追问三：推理成本优化具体做了哪些工作，量化收益如何？

参考回答方向：从三个维度回答。第一，上下文管理：对历史对话做摘要压缩，控制 token 长度，减少重复计费；第二，模型选择：简单意图用轻量模型，复杂推理用大模型，做路由分流；第三，缓存：对高频 query 的结果做 Redis 缓存，命中率约 20%。量化收益方面，整体推理成本下降约 35%，响应延迟降低 40%。

手撕算法题

题目：给定一个可能包含重复元素的旋转排序数组（如 [2,2,2,0,2,2]），求数组中的最小元素。

关键思路：经典二分查找变种。维护 left、right 指针，取 mid。与常规旋转数组题不同，当 nums[mid] == nums[right] 时无法判断最小值在左半还是右半，此时将 right-- 缩小范围（因为重复元素不影响最小值判断）。当 nums[mid] > nums[right] 时，最小值在右半；否则在左半。时间复杂度最坏 O(n)，平均 O(log n)。实现时注意边界条件，如数组长度为 1 或所有元素相同的情况。

准备建议

1. Go 语言不能只背八股，要能画 GMP 流程图。面试官会追问「P 的本地队列满了怎么办」「M 阻塞后 G 如何调度」，建议自己动手模拟一遍 goroutine 从创建到销毁的完整生命周期，理解 work stealing 和 hand off 机制。
2. 大模型项目准备一份「指标改进记录表」。列出每个优化动作前后的数据变化，如检索召回率从 70% 提到 85%、推理成本下降百分比。面试官对量化结果非常敏感，有数据支撑的回答可信度远高于定性描述。
3. 手撕算法题刷 LeetCode 旋转数组系列全部变种。包括 33、81、153、154 题，重点理解重复元素对二分查找的影响。建议总结一份「旋转数组二分模板」，涵盖所有边界情况，面试时直接套用。

结果反馈

三面通过，约一周后收到 HR 电话沟通 offer 意向。

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