面试面经 · 携程
【携程】【大模型开发】【暑期实习一面】面经（八股+大模型项目+手撕）
携程 大模型开发 暑期实习一面
背景：海外一年制硕士，主攻 NLP 与 LLM 应用，有一段 RAG 相关项目经历，投递的是携程大模型应用方向。
题目摘要
- Go 语言基础：goroutine 与 channel 的底层原理，GMP 模型简述，如何避免 goroutine 泄漏。
- MySQL/Redis 八股：MySQL 索引失效场景、事务隔离级别与 MVCC；Redis 持久化机制（RDB/AOF）与缓存穿透解决方案。
- RAG 项目深挖：针对简历中的 RAG 项目，追问 chunk 切分策略、检索召回率优化、上下文窗口管理、推理成本优化。
- 手撕算法：合并 K 个有序链表（LeetCode 23），要求用最小堆实现并分析时间复杂度。
- 开放性设计题：如何设计一个面向用户的旅游攻略生成 Agent，需要哪些模块，如何评估生成质量。
项目深挖
面试官全程围绕简历上的 RAG 项目展开，没有一句闲聊。以下是三个印象最深的追问及参考回答方向：
追问 1：你的 chunk 切分策略是怎么设计的？为什么不用固定长度？
参考方向：固定长度切分容易切断语义完整的句子或段落，导致检索时召回片段缺乏上下文。我采用的是基于文档结构的分层切分——先按 Markdown 标题和段落进行语义块划分，再对超过阈值的块做递归切分，同时保留 10%-15% 的重叠区域。这样既保证了 chunk 的语义完整性，又控制了单次送入 LLM 的 token 数量。面试官追问了重叠区域会不会造成检索冗余，我补充说在检索后会对重叠部分做去重，并利用重排模型对召回结果做二次筛选。
追问 2：检索召回率不达标时，你怎么定位问题？
参考方向：我会先分模块排查——先看 Embedding 模型本身对领域术语的表征能力，再看检索方式（向量检索 vs 混合检索），最后看 rerank 环节。我的项目里最初只用了向量检索，对包含酒店名、景点名的查询经常召回不准确，后来加了 BM25 与向量检索的混合召回，用 RRF（Reciprocal Rank Fusion）做分数融合，召回率提升了 12% 左右。面试官追问了 RRF 的权重如何设定，我回答说是通过小规模验证集网格搜索确定的，同时说明 RRF 对分数分布不敏感、不需要归一化，工程实现更简单。
追问 3：上下文窗口有限，你的 RAG 系统如何处理长文档或多轮对话？
参考方向：我采用了分层摘要 + 动态上下文裁剪的策略——对超长文档先做递归摘要，保留核心信息；多轮对话中，只保留与当前 query 最相关的历史轮次，用向量检索从对话历史中召回相关片段，而不是把所有历史都塞进 prompt。面试官追问了摘要信息的损失问题，我承认摘要会丢失细节，所以系统设计了"摘要优先、原文兜底"的机制，当摘要置信度不足时回退到原始 chunk 检索。
手撕算法：合并 K 个有序链表
题意：给定 K 个升序链表，将它们合并为一个新的升序链表并返回。
关键思路：维护一个大小为 K 的最小堆，初始将所有链表的头节点入堆。每次弹出堆顶节点（当前最小节点），将其下一个节点入堆，重复直到堆空。时间复杂度 O(N log K)，N 为总节点数，空间复杂度 O(K)。面试官要求手写完整代码，注意处理链表为空的边界情况。写完后他追问了"如果链表数量非常大（比如百万级）怎么办"，我回答可以用败者树或分批合并，面试官点头没继续深挖。
准备建议
- 项目深挖要提前预演：针对简历上的大模型项目，至少准备 10 个"为什么"——为什么选这个方案、有没有对比过其他方案、数据量多少、效果指标怎么定义的。面试官会顺着你的回答往下追问，不要给自己挖坑。建议把项目的架构图画清楚，每个模块的输入输出、技术选型理由都要能流利讲出。
- 八股要结合场景理解：MySQL 索引失效、Redis 缓存穿透这些题目，不要死记硬背，要能结合业务场景说明。比如面试官问缓存穿透时，我回答了布隆过滤器 + 缓存空值的方案，并补充了空值过期时间要设置短一些，避免雪崩。这种"方案 + 细节"的回答方式明显比单纯背概念更受认可。
- 算法题要练到"肌肉记忆"：面试前把 LeetCode 热门题（尤其是链表、二叉树、动态规划）刷到能闭眼写出来的程度。手撕题往往不是最难的，但紧张状态下容易出边界条件错误，建议平时就养成先写边界判断、再写主逻辑的习惯。另外，写完后主动说时间复杂度和空间复杂度，展示工程思维。
结果反馈
一面通过，约了三天后二面（技术面 + 部分场景设计），整体面试节奏紧凑，面试官技术功底扎实，问题全部围绕实际业务场景展开，几乎没有闲聊。
想系统备战大厂大模型/Agent 开发？NiceOffer 提供 SDE+LLM 双轨 1v1 陪跑，合同保底 40w 年薪，文末扫码咨询。
