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

携程 大模型开发 暑期实习三面面经

背景：海外一年制硕士，主攻 NLP 与 LLM 应用，一段中小厂大模型实习，简历项目以 RAG + Function Calling 为主。

题目摘要

面试整体以项目深挖 + 场景设计为主，八股占比不高，但问得偏底层。核心考点如下：

1. Go 语言基础：Goroutine 与 Channel 的调度模型、内存逃逸分析、defer 的坑（参数求值时机）。
2. MySQL/Redis 八股：InnoDB 索引结构（B+ 树高度计算）、覆盖索引与回表、Redis 持久化（RDB/AOF 混合）、缓存穿透/击穿/雪崩的区分与应对。
3. RAG 项目深挖：切分策略、召回率优化、重排（Rerank）的必要性、上下文窗口管理。
4. Function Calling 实现细节：工具定义 Schema 设计、多轮对话中工具调用的状态管理、幻觉控制。
5. 推理成本优化：Prompt 压缩、KV Cache 复用、小模型兜底策略。
6. 手撕算法：「合并区间」变体——合并重叠的会议时间区间，并返回每个区间内可用空闲时间段。要求先排序，再贪心合并，最后补全空闲段。关键点是边界条件（跨天/零长度区间）。

项目深挖

追问 1：你提到 RAG 里用了混合检索（BM25 + 向量），为什么不用纯向量？

参考方向：
不能只答"BM25 精确匹配好、向量语义泛化强"。要落到数据场景——携程这类平台，用户 Query 里大量出现酒店名、地名、品牌词，这些是专有名词，向量化后容易丢失精确性。BM25 保证字面命中，向量负责语义扩展。另外，要提召回融合策略：我用的 RRF（Reciprocal Rank Fusion），而不是简单拼接，因为不同检索器分数分布不可比。面试官可能会追问"RRF 的 k 值怎么定的"，答：按线上 A/B 测试，k=60 时效果最稳，过小会导致长尾结果抖动。

追问 2：Function Calling 时，如果模型幻觉了工具参数（比如日期格式错误），你怎么兜底？

参考方向：
别只答"加 system prompt 约束"。实际工程做法是三层校验：
第一层，Schema 里用 JSON Schema 的 format 和 pattern 硬性约束（比如日期必须是 YYYY-MM-DD）；
第二层，代码里写解析后校验器，失败则触发自纠正循环——把错误信息拼进下一轮 prompt，让模型重新生成（限 2 次，防死循环）；
第三层，如果仍失败，回退到规则匹配（正则提取关键实体），再不行就返回"无法处理"给用户，而不是硬编一个错误结果。
面试官真正想听的是你有没有工程容错意识，而不是模型调参。

追问 3：多轮对话里，上下文越来越长，你怎么控制成本？

参考方向：
核心是分层策略：

• 短期记忆：保留最近 N 轮完整对话（按 token 预算，比如 2000 token）；
• 长期记忆：每轮对话结束，用一个小模型抽取"用户偏好 + 未完成事项"，存 Redis，需要时注入；
• 动态压缩：对历史轮次做摘要（用 LLM 压缩，但注意摘要本身也有成本，所以只在超过阈值时触发）；
• KV Cache 复用：前缀相同的请求复用 cache，但要注意多轮场景下前缀会变长，需要结合 prompt 分块设计。

另外，我提了一个点：把系统 prompt 和工具定义放在最前面，且保持静态，这样前缀缓存命中率能到 80% 以上，这是实际优化中收益最明显的。

手撕算法：合并会议区间 + 求空闲段

题目：给定一组会议时间区间 [start, end)（左闭右开），合并所有重叠区间，并返回合并后每个区间的空闲时间段（即两个合并区间之间的空隙）。

关键思路：

1. 按 start 升序排序；
2. 初始化 merged = []，遍历区间，若当前区间与 merged 最后一个区间重叠（cur.start < last.end），则合并（last.end = max(last.end, cur.end)），否则直接加入；
3. 合并完成后，遍历 merged，相邻两个区间的空隙 [last.end, cur.start) 即为空闲段。

边界条件：

• 输入为空或只有一个区间，返回空空闲段；
• 区间端点可能跨天（用时间戳，避免时区问题）；
• 注意左闭右开，所以 cur.start == last.end 不算重叠，是连续会议，无空隙。

我用了 Go 写，注意 sort.Slice 的稳定性和 int64 时间戳比较。面试官追问了时间复杂度——排序 O(n log n)，合并 O(n)，整体 O(n log n)，空间 O(n)（存结果）。

准备建议

1. 项目要准备"最差情况"答案：面试官不会按你准备的亮点问，而是专挑你没做的、做糟的、妥协的点。比如"你 RAG 里为什么不用 GraphRAG？""Function Calling 如果模型返回 JSON 格式错误怎么办？"——每个项目至少准备 3 个"当时没做好/后来怎么补"的故事，比背亮点有用得多。

1. 手撕题别只刷 LeetCode 原题：携程这类业务导向的面试，算法题常带"业务包装"（会议、航班、订单）。练题时把题目改成业务场景，比如"合并订单时间区间""找出可预约的时段"，练变体识别能力。另外，Go 的 sort.Slice 和 container/heap 要手写熟，别依赖 IDE 提示。

1. 八股只背高频且能讲深：本次面试 MySQL 只问了索引结构，Redis 只问了缓存场景。不要贪多，把 B+ 树（为什么 3-4 层、一页能存多少行）、Redis 持久化（RDB 和 AOF 的取舍、混合持久化怎么工作）这类"能展开推导"的吃透，比背 50 个冷门命令有用。

结果反馈

三面通过，隔了两天收到 HR 电话，约了一周后的 HR 面，目前流程进行中。

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