面试面经 · 深信服
【深信服】【大模型开发】【暑期实习一面】面经（八股+大模型项目+手撕）
深信服 大模型开发 暑期实习一面
背景与整体感受
海外一年制硕士，投递方向为大模型应用开发。整体面试节奏偏快，面试官是业务侧技术负责人，没有过多寒暄，直接进入正题。全程约 50 分钟，技术考察占 80% 以上，项目深挖非常细致，尤其关注工程实现细节而非模型原理本身。
题目摘要
- Go 语言基础：goroutine 与 channel 的底层实现，GMP 模型简述，以及 slice 与 array 的区别、扩容机制。
- MySQL 与 Redis 八股：InnoDB 索引结构为什么选 B+ 树；事务隔离级别与 MVCC；Redis 持久化机制对比（RDB vs AOF），以及缓存穿透/击穿/雪崩的应对方案。
- RAG 项目深挖：针对简历中的 RAG 项目，追问 chunk 切分策略、embedding 选型依据、检索召回效果优化手段。
- Agent/Function Calling 项目深挖：多工具调用的决策逻辑，上下文窗口管理策略，以及推理成本优化手段。
- 手撕算法题：合并 K 个升序链表（LeetCode 23 原题变体），要求分析时间/空间复杂度。
- 场景设计题：如何设计一个面向企业内部的 LLM 知识库问答系统，要求给出整体架构与关键模块设计。
项目深挖
面试官对项目经历的追问非常密集，几乎每个技术选型都要问"为什么"。以下是几个典型追问与参考回答方向：
追问一：RAG 系统中，你的 chunk 切分策略是什么？如何确定 chunk size？
参考回答方向：先说明没有通用最优解，而是结合文档类型与评测结果迭代。我采用的是按语义段落切分为主，辅以滑动窗口重叠的混合策略——先按 Markdown 标题或段落边界做粗切分，再对过长 chunk 做递归切分，保证单 chunk 在 300-500 token 之间。chunk size 的确定依据是：在自建的领域问答评测集上对比 200/300/500/800 token 四组参数，观察 recall@k 与答案完整度两个指标，最终选定 400 token、overlap 50 token。同时补充了一个细节：对于表格类内容，单独走 CSV-to-Text 的结构化转换流程，避免纯文本切分破坏行列对应关系。
追问二：Function Calling 场景下，如果模型选错了工具或参数格式错误，你怎么处理？
参考回答方向：这个问题考察容错设计。我做了三层防护：第一层是 prompt 约束，在 system prompt 中给出严格的 JSON Schema 示例，并要求模型先输出思考过程再输出调用（虽然会增加延迟，但显著降低格式错误率）；第二层是运行时校验，解析模型输出后走 JSON Schema validator，失败则自动附加错误信息让模型重试一次，限制最大重试次数为 2；第三层是兜底策略，如果重试后仍然失败，则返回候选工具列表让用户确认，而不是直接报错。另外，我提到在工具描述中加入"何时使用该工具"的触发条件，比单纯描述"该工具能做什么"效果更好，准确率大约提升 6-8 个百分点。
追问三：你提到优化推理成本，具体做了什么？
参考回答方向：从两个维度回答——减少 token 消耗和降低调用频次。减少 token 方面：一是系统 prompt 压缩，把原有 800 token 的 prompt 精简到 400 token，用更紧凑的措辞和结构化格式替代冗长描述；二是历史消息裁剪，采用滑动窗口 + 关键信息摘要的混合策略，超过 10 轮对话后自动触发摘要；三是输出限制，在 temperature 和 max_tokens 上做控制。降低调用频次方面：引入 semantic cache，对用户 query 做 embedding 相似度计算，命中缓存直接返回历史答案，缓存阈值为 0.92。最终整体成本下降约 35%，回答延迟从 2.8s 降到 1.9s。
手撕算法题
题目：合并 K 个升序链表。给定 K 个链表，每个链表升序排列，将所有链表合并成一个升序链表并返回。
关键思路：优先队列（最小堆）是最优解——维护一个大小为 K 的小根堆，每次弹出堆顶节点加入结果链表，然后将该节点的 next 入堆，直到堆为空。时间复杂度 O(N log K)，其中 N 为总节点数，空间复杂度 O(K)。面试官还追问了边界条件：空链表数组、K=1 的情况，以及如果要求空间复杂度 O(1) 可以用分治合并（两两合并），时间复杂度同样是 O(N log K) 但常数略大。我选择了优先队列方案，手写代码约 5 分钟完成，面试官没有要求运行测试。
准备建议
- 项目细节必须能闭环回答：不要只准备"我做了什么"，更重要的是"为什么这么做"和"有没有对比过其他方案"。面试官对 RAG/Agent 项目的追问明显在考察候选人的工程判断力，建议把项目中的每个技术选型都整理成「方案 A vs 方案 B vs 方案 C」的对比表，并准备好量化收益数据（如准确率提升百分比、成本下降比例）。
- 八股要背但不要死背：MySQL 和 Redis 的考点非常常规，但面试官会通过追问判断你是否真正理解。例如索引问题会追问"为什么不用红黑树"，Redis 持久化会追问"AOF 重写机制如何避免阻塞"。建议每个高频考点准备一个"为什么"层面的解释，而不是只背结论。
- 算法题保持手感：深信服手撕难度不算高，LeetCode 热题 Hot 100 中链表、二叉树、滑动窗口三类题型做到无脑默写即可。重点练合并 K 个链表、LRU 缓存、二叉树层序遍历这类高频题，同时准备好时间/空间复杂度分析的口述表达。
结果反馈
一面通过，约 3 天后收到二面通知，二面为技术+HR 交叉面。
想系统备战大厂大模型/Agent 开发？NiceOffer 提供 SDE+LLM 双轨 1v1 陪跑，合同保底 40w 年薪，文末扫码咨询。
