多益网络校招面试（技术面 + HR 面）

《面试题目》

1. 请介绍一下你的项目，项目整体是如何运行的？
2. 上下文熔断机制是怎么做的？
3. BM25 和向量索引的重排序具体怎么实现？
4. RAG 的全流程应该是怎么样的？
5. 实习期间主要做了什么，有什么心得？
6. 实习有没有遇到加班？你怎么看待加班？
7. 你怎么看待加班？
8. 你在观点题作答时没有写够 300 字，原因是什么？

《参考解析》

1. BM25 与向量索引怎么重排：BM25 是词频类稀疏检索，靠词频饱和与文档长度归一化算分，对关键词命中精确、可解释、延迟低，但同义改写的问法召不回来；向量检索用稠密表示算相似度，能覆盖语义相近的表达，缺点是缺少精确匹配的约束、容易在长尾实体上漂。常见做法是两路各取几十到上百条候选，用 RRF 这类与分数量纲无关的方式融合，或者用一个小交叉编码模型对候选做精排。取舍在于延迟预算——精排效果好但贵，所以先粗排把候选压到几十条再精排，是工程上最稳的落点。
2. RAG 的全流程：离线侧是文档解析、按语义或结构切块、生成向量与关键词索引并落库；在线侧是查询改写（多轮对话要先补全指代）、混合召回、去重与重排、按 token 预算拼上下文、生成时要求答案带引用。面试官通常会追问切块策略和召回质量——切块粒度太大噪声多、太小语义不完整，重叠窗口和按标题层级切是比较实用的折中；评估上要分开看召回率和最终回答正确率，否则改错了环节也看不出来。
3. 上下文熔断：本质是给上下文长度和质量各设一道闸。长度上按模型窗口留出回答的余量，超了就按相关度截断或者先做一轮摘要压缩；质量上对召回的分数设阈值，全都低于阈值时不做拼接，直接告诉用户「没有找到依据」，避免模型拿无关片段硬编。再进一步可以做多轮之间的去重和冲突检测，同一事实出现矛盾版本时降级为提示用户确认。熔断的意义是把「答错」换成「不答」，这在面试里是加分项。
4. 检索相关的追问方向：项目讲清楚之后，面试官一般会顺着「为什么用这个而不是那个」往下问，比如为什么混合检索而不是单路、重排模型是自训还是现成、索引更新是实时还是批量、评测集怎么建的。准备时把每个选型的替代方案和代价各想一句话，比背概念有用得多；如果某个模块是团队做的，也要能说清自己负责的边界，说不清边界往往比不会更致命。
5. 加班类问题的答法：这类问题没有标准答案，但最忌讳前后不一致——网申观点题写过的口径和线上面试口述的答案对不上，很容易被追问。稳妥的思路是把它拆成两件事来回答：项目临近上线或者线上出问题时的加班是有必要的，这是团队责任；同时说明自己反对长期靠加班补排期，更愿意先把流程和工具上的重复劳动去掉。先说事实再表态，比直接表忠心或者直接拒绝都更容易被接受。
6. 流程上的观察：这条线的节点比一般校招长，测评、观点题、笔试、技术面、HR 面走完还要等一周多才出结果。技术面不写代码、重点压在项目与检索类原理上，说明岗位真正在意的是「能不能把系统讲明白」；观点题、HR 面复用同一批问题，则说明作答记录是会被交叉比对的，写的时候就要留一份自己的答复要点。