1. 写在前面为什么是百度大搜和度秘最近面完了百度的两个核心团队一个是大搜搜索业务线一个是度秘智能语音交互感触挺深。这两条线在百度的位置都很特殊——大搜是起家业务技术和业务沉淀最厚度秘是AI落地的窗口代表了百度押注的未来方向。一个偏传统但极致的搜索技术一个偏前沿且复杂的人机交互面试节奏、考察重点甚至面试官风格都有明显差异写出来供准备百度的朋友参考。不管你是刚准备找实习的在校生还是工作几年想跳槽的工程师这篇面经都适用。我会尽量把每轮面试问到的真实问题、我当时怎么答的、事后复盘觉得哪里能答得更好都摊开来讲。面试这种东西光看题目列表没用关键是要理解面试官在考察什么维度——算法功底、工程能力、业务 sense 还是沟通表达不同类型的题目对应不同的应对策略。需要提前说明的是任何面经都有时效性百度不同部门、不同面试官差异也很大。我这篇记录的是我这次的实际经历不代表每次面试都会这样但考察的方向和底层逻辑是稳定的把这些吃透了即使遇到其他题目也能淡定应对。2. 两条业务线的前期功课你至少要懂到什么程度2.1 百度大搜到底在做什么投简历之前我得先把大搜这两个字搞清楚。百度大搜不只是你看到那个搜索框背后是完整的搜索链路爬虫抓取、网页反作弊、索引构建、Query理解、相关性计算、排序模型、搜索结果页的端上体验优化。面试前至少要能把这几个环节串起来知道每个环节的核心技术挑战是什么。以排序为例搜索排序不是简单的相关性高就排前面而是要综合相关性、时效性、权威性、用户体验、商业诉求等多重因素。传统时期用的是LR逻辑回归加人工特征后来演变成GBDT、LambdaMART这些树模型再到现在主流的深度排序模型DSSM、Transformer-based的语义匹配模型每一步演进都有明确的技术逻辑。面试官如果问为什么从LR换成GBDT本质上是在考察你对特征非线性和组合特征的理解——LR只能做线性加权特征之间需要手动做交叉才能表达非线性关系而GBDT天然能自动挖掘特征组合省掉了大量人工特征工程的工作。另外搜索引擎是典型的超大流量、超低延迟的系统这个约束条件决定了你设计的方案必须务实。纯深度模型效果好但耗时高所以业界常见的做法是级联架构先做粗排轻量模型从一万条粗筛到几百条再做精排复杂模型几百条精排到几十条最后做重排处理多样性、去重、品牌约束等。面试中提到这些细节面试官会觉得你真的理解搜索而不是只背了概念。2.2 度秘的技术栈和产品形态度秘是百度的话筒耳朵和嘴巴——它接的是语音交互这条链路唤醒、语音识别ASR、自然语言理解NLU、对话管理DM、自然语言生成NLG、语音合成TTS其中还穿插着云端技能调度和内容服务对接。度秘的面试会明显更偏NLP和对话系统。你需要对任务型对话的经典架构有清晰的认知用户说的话怎么映射到意图和槽位多轮对话状态怎么跟踪和更新对话策略怎么决定回复内容。举个例子帮我订一张明天早上从北京到上海的高铁票这句话意图是订火车票槽位有出发城市北京、到达城市上海、日期明天、时间段早上这些怎么通过意图识别和槽位填充模型抽取出来是度秘面试绕不开的问题。此外度秘面试官特别爱问交互体验不好的场景你会怎么优化这个后面我详细展开。度秘面对的是真实用户、真实流量用户说话有噪音、有口音、有省略、有指代从北京到上海上一轮说了这一轮可能就说那后天呢这种多轮指代消解问题比单轮理解难一个量级。2.3 简历和项目准备的核心原则我得先说一个很多人踩的坑简历上写的项目一定是你能从为什么做、怎么做、遇到什么问题、最终效果、还有哪些优化空间五个维度完整讲清楚的项目。面试官基本都会从简历项目切入如果你的项目是自己实际做的这一轮是送分题如果只是挂名或者年久失修记不清细节这一轮就变成了送命题。我还做了一个小准备把简历里每个项目可能被追问的问题提前列了一个清单全都写了一遍模拟答案。写的过程中会发现很多之前没想清楚的细节比如你这个模型AUC提升0.03具体是在什么数据集上测的离线指标涨了线上有验证吗这些问题如果不提前准备面试现场很容易卡壳。3. 百度大搜面试全流程复盘3.1 第一轮代码与数据结构——基本功速写大搜第一轮是标准的算法coding面1小时内两道题。我遇到的第一道是实现 LRU 缓存第二道是给你一个日志文件的数据流如何实时统计 TopK 热搜词。LRU缓存这道题属于高频题中的高频题考察点是数据结构组合使用哈希表加双向链表哈希表保证O(1)查找双向链表保证O(1)插入和删除两者配合就能实现get和put都是O(1)的缓存淘汰策略。我平时练习时就直接背了模板现场10分钟内写完写完后面试官让我画一下链表节点在get和put操作时的指针变化我画完他点了点头。实时TopK这个题更有意思。我第一反应是维护一个小顶堆堆大小为K新元素进来如果比堆顶大就替换并调整堆这样时间复杂度和空间复杂度都在可控范围。面试官追问如果数据流非常非常大单机内存装不下怎么办我答了哈希分片到多台机器每台机器算局部TopK再归并全局TopK的分布式思路他又追问如果K也很大呢我想了一下说可以用Count-Min Sketch这种概率性数据结构先做频率估计再配合堆或者分段计数牺牲一定的准确率换内存空间。这道题告诉我一个规律大搜这种场景对海量数据处理是有执念的毕竟搜索引擎面对的就是PB级别的网页数据。面试官后面其实就是想听分布式和概率数据结构这两个方向的思路你哪怕没有深度实现过能把原理和取舍讲清楚也能过关。注意写代码的时候一定要边写边说思路不要闷头敲完才解释。面试官要观察的是你的思维过程不是只要一个AC结果。我习惯先写注释框架明确每个函数的输入输出和边界条件再填代码这样既显得有条理也能避免自己写着写着忘记初始意图。3.2 第二轮机器学习基础——从公式到业务第二轮考察机器学习面试官是从简历里我做过的一个CTR预估项目切入的问得很深。他先问Logistic Regression的损失函数是什么我答了交叉熵损失并写出公式和梯度推导。接着他问了一个非常典型的题如果训练数据里正负样本比例是1:99LR训练会有什么问题你会怎么处理这个问题的考察点有两个一是你是否真的理解LR在类别不平衡下的行为——模型会偏向预测多数类因为总损失被多数类主导导致预测概率整体偏低二是处理方案是否落地——常见做法有负样本下采样、正样本过采样、修改损失函数权重但每种方法都有代价。我当时补充了一个搜索场景的实际细节在搜索场景里后验负反馈数据其实很多是曝光未点击这里存在严重的position bias就是排在前面的天然容易获得点击排在后面的即使相关也可能没被点。所以简单的下采样会导致偏差放大业界常用做法是引入位置特征在线推断时把位置特征固定为某个基准值。他还问了GBDT和随机森林的区别。这类送分题反而容易答飘关键是答出本质随机森林是bagging并行训练多棵树降低方差GBDT是boosting串行训练每棵树拟合前一棵的负梯度残差近似降低偏差。另外GBDT的树通常很浅叶子数少因为每棵树只负责修正一部分残差所以弱学习器之间是互补关系而随机森林的树追求多样性每棵树都尽量训充分。最后我补了一句操作经验GBDT对异常值敏感因为拟合残差会被异常样本主导所以预处理时要做异常值截断随机森林则不敏感这个细节面试官明显比较满意。3.3 第三轮综合系统设计——如何设计一个垂直搜索系统这一轮是压力最大的。面试官给了我一个场景假设要为百度内部的员工知识库设计一个垂直搜索系统数据量大概几千万篇文档要求实时索引更新和搜索延迟在几百毫秒以内你会怎么做架构和排序方案拿到这种题千万不要慌没让你真造一个搜索引擎而是考察你的架构思维和取舍能力。我先从整体链路拆文档入库、解析、分词、构建倒排索引查询侧做Query分析、召回、排序、结果呈现。召回阶段用倒排索引加BM25打分先筛出一批候选排序阶段如果预算够再加一个基于语义匹配的模型做精排比如用BERT对Query和Doc做交互式匹配但BERT太慢工程上常用的方案是召回阶段用DSSM双塔模型做向量召回精排再用交叉模型。面试官追了很多细节倒排索引怎么压缩我答了常用的是前向编码和后缀压缩的组合再加跳表加速合并。索引更新的实时性怎么做我用了个比较稳妥的方案全量索引定期重建放慢的冷路径增量索引实时写入走热路径查询时合并两个索引的结果等增量积累到一定规模再和全量做merge。这也是一般搜索系统的经典双索引方案。他还问了如果文档量扩大到现在的10倍你的方案哪里会先扛不住。这个问题本质上是考你对自己方案的瓶颈是否有感知。我说内存索引会不会撑爆——所以要分层存储热数据在内存、冷数据在磁盘排序计算会成为瓶颈——所以要用级联架构先粗排再用高成本模型单机并发不够——所以需要分片和副本分片解决容量问题副本解决吞吐问题。面试官听完笑着说了句你还挺懂搜索引擎的这一轮基本算是稳住了。3.4 第四轮经理面——业务理解和软素质到了经理面已经不太问技术细节了更多是考察综合判断力和业务思维。面试官问了一个让我印象很深的问题如果百度大搜的搜索点击率下降了3%你会从哪些方向排查这个问题其实没有标准答案考察的是系统性思维。我从三个层面拆解第一是数据层先确认点击率下降是真实的还是统计口径变化造成的检查埋点、日志解析、去重逻辑有没有变更第二是链路层从上到下排查——是不是有大量坏流量爬虫、恶意点击、Query分布是否变化、搜索结果有没有出现大面积低质甚至空白页、排序模型有没有灰度过新版本、广告占比是不是提高了挤压了自然结果第三是产品层是不是页面改版导致用户视觉焦点变了、是不是某个大事件密集发生导致热搜类Query集中从而稀释了正常点击。面试官对第三个层面的回答明显更感兴趣因为前两层是常规排查路径第三层体现的是你具备业务视角。这个回答思路后来我用在了多个面试里效果都不错。4. 度秘面试全流程复盘4.1 第一轮NLP基础——中文分词和意图理解的里子度秘第一轮就没有考纯算法题了直接上NLP。第一个问题是中文分词你了解哪些算法自己实现过分词器吗。中文分词是NLP最基础也最经典的问题。我讲了三个主流流派基于词典的最大匹配法简单但无法处理未登录词、基于统计的HMM/CRF方法把分词看成序列标注问题需要标注数据训练、基于神经网络的BiLSTM-CRF方法目前效果最好但需要大量数据。我还特意提了一个工程实践中的点在搜索场景里分词并不是越准越好而是要跟索引和匹配策略配合考虑——有些Query切成粗粒度反而匹配效果更好比如机器学习整词匹配优于切成机器和学习两个词分别去匹配因为后者可能召回大量不相关结果。第二个问题开始深入度秘的场景了度秘收到了用户一句话我想听周杰伦的歌请设计一个完整的处理流程。我从ASR的结果开始说首先判断是否有唤醒词和语音识别的置信度然后是NLU模块做领域分类——这句话属于音乐领域接着做意图识别——播放歌曲再做槽位填充——歌手是周杰伦音乐类型是歌如果缺少必要槽位比如没说具体哪首歌就需要通过对话策略反问用户来澄清。4.2 第二轮对话系统深度——多轮对话的坑第二轮直接上了多轮对话面试官设计了一个场景连续追问用户说帮我订明天去上海的高铁票然后又补了一句不改成后天系统怎么理解这次修改这道题非常妙因为它考察的是多轮对话最核心的难题——指代消解和槽位更新。用户在第二句话里只说了不改成后天没有明确说改什么但系统要能从上下文推断出是修改出发日期。经典的实现方案包括基于规则的指代消解就是把当前轮输入和上一轮的槽位做对齐识别出后天这种时间实体应该替换到哪个槽位、基于特征的判别式方法、基于深度学习的端到端方法把上下文编码成向量再和当前输入做attention融合。对话状态跟踪DST是这里的核心概念。典型的做法是用一个状态表示数据结构记录所有槽位的值每来一轮对话模型要判断这句话是否更新某些槽位。工业界比较实用的方案是逐槽位分类对每个槽位训练一个二分类器判断当前轮是否有该槽位的新值有就更新没有就沿用上一轮的值。我回答中还补了一个工程细节真实场景里用户经常说约后天下午三点而后天是一个相对时间描述系统需要根据当前日期计算成绝对日期存储否则跨天对话就会出现状态错乱。这种细节你说出来面试官就知道你做过真实项目不是纸上谈兵。4.3 第三轮工程实现——召回、排序和对话策略的落地度秘第三轮偏工程系统设计问了一个实际很多的功能如何设计一个百科类知识问答技能用户问珠穆朗玛峰有多高系统要在几百毫秒内给出答案。我的方案分为两大块检索和回答生成。检索部分给知识库文档建索引对Query做改写和扩展召回相关段落然后做一个段落级的排序模型把最相关的段落挑出来。回答生成部分有两个路线抽取式——直接从段落里抽取包含答案的片段生成式——用预训练模型生成答案。在问答领域我倾向于先用抽取式因为可控性和准确率更高生成式容易产生幻觉hallucination也就是模型自信地编造出一个不存在的答案。在知识问答这种对准确性要求极高的场景里幻觉问题非常致命。面试官紧接着问用户如果问珠穆朗玛峰在哪一年被首次登顶你的纯检索方案可能检索不到精确答案怎么办我答这种情况需要叠加知识图谱的能力把问题转成结构化查询。先做实体识别——珠穆朗玛峰再识别关系——首次登顶时间然后去知识图谱里查珠穆朗玛峰这个实体关联的首次登顶时间属性。这就是知识图谱问答KBQA的经典思路。我把这两个方案各自适用的场景说得比较清楚之后面试官露出了你确实理解这块的表情。4.4 第四轮部门负责人面——AI产品观和团队匹配度度秘的第四轮是部门负责人更多聊的是对AI产品的理解和职业规划。他问我你觉得度秘和小爱同学、天猫精灵这些语音助手的本质区别是什么。这个问题让我有点意外因为听起来像产品经理面试题但仔细一想这恰恰是考察你是否有全局视野。我从技术路线和产品定位两个角度回答了技术路线上度秘更强调全双工交互和对话式搜索的能力它能串联百度的搜索和知识图谱答问题的深度和广度有优势产品定位上度秘想成为一个通用的智能助手入口而不是绑定特定硬件的控制中心。面试官又追问了一句那你怎么看待语音交互的未来这个问题我诚实说了自己的观察语音交互在封闭场景车载、智能家居已经比较成熟但在开放场景还有很大的问题——噪音环境下识别率、复杂语义理解准确率、用户使用习惯培养这些都需要长期投入。我不太会说漂亮话但这个比较务实的回答面试官反而认可了。5. 两场面试的横向对比别把同一套准备拿去面所有部门5.1 技术栈侧重完全不同大搜和度秘虽然都在百度但面试风格差异肉眼可见。大搜偏经典机器学习加海量数据工程考点相对固定——LR、GBDT、排序、倒排索引、分布式计算面试官会反复把问题落到数据量大了怎么办延迟要求高了怎么办这些工程约束上。度秘偏NLP和对话系统考点集中在序列标注、意图识别、槽位填充、多轮对话、知识问答上面试官更关注你如何处理歧义和不完美的用户输入。我在准备度秘的时候额外过了一遍BERT和它的变体比如ERNIE因为度秘这种场景对语义理解要求高预训练模型肯定是重点话题。面试官也确实问了ERNIE和BERT的区别我答了ERNIE在预训练阶段引入了知识增强的mask策略不仅mask字词还mask实体和短语让模型能更好地建模先验知识在中文任务上更占优势。5.2 面试轮次的节奏差异大搜的整体节奏是算法题开路机器学习理论跟上系统设计压轴经理面收尾。度秘则是NLP基础开路对话系统深入技能设计压轴负责人面收尾。前者更看重能不能写、能不能算后者更看重能不能理解语言、能不能设计交互。两种面试风格对候选人的要求不同大搜要求算法功底硬、工程素养高度秘要求NLP基础扎实、语言直觉好。准备的时候要有侧重点别用一套模板硬套。5.3 现场发挥的一些共性心得两个团队面试中我都踩过或避开了一些坑总结下来有这样几点第一回答技术问题时一定要先给结论再展开细节面试官一天面很多人你讲三分钟才到重点他会走神第二遇到不会的题不要直接说不会先把相关的、你确定的部分说出来再表达这部分我没有实际经验但我理解大概是……面试官会觉得你至少思路在线第三反问环节一定要问有价值的问题比如团队目前在排序模型上用的是双塔还是交叉模型度秘在多轮对话上自研和用大模型的边界在哪里这些问题会让面试官觉得你是有深度思考的候选人而不是来刷个面经的。6. 百度面试常见问题与避坑速查表我把这次面试和其他朋友的面经里出现的典型问题整理成了一个速查表附上我的参考思路方便大家快速过一遍问题参考思路踩坑提醒LR损失函数推导写出交叉熵损失求梯度说明为什么用交叉熵而不是MSE别只背公式要能解释梯度下降的更新表达式样本不平衡怎么办负采样、权重调整、评估指标用AUC/GAUC别只说换数据集要结合场景说trade-offGBDT和RF区别bagging降方差、boosting降偏差串行与并行从数学直觉解释别只背名词倒排索引怎么存储词典倒排列表压缩编码跳表加速合并只答倒排索引四个字等于没答多轮对话槽位怎么跟踪逐槽位分类更新相对时间转绝对时间别忘了指代消解和省略恢复实体识别怎么做BiLSTM-CRF或BERTCRF标注数据是关键要提未登录词和长尾实体的问题召回和排序的架构粗排召回精排的级联设计要说明为什么不能一步到位知识问答幻觉问题优先抽取式知识图谱校准生成式可控性差别盲目吹生成式要谈落地风险系统延迟怎么优化缓存、量化、蒸馏、级联、并行计算要定量估算别只写方向业务指标下降排查数据口径→链路排查→产品变更→外部因素要有层次千万别上来就怀疑模型另外想专门提醒两点容易被忽略的第一手撕代码时对自己用到的每种数据结构的操作复杂度要心里有数。面试官经常在你写完代码后追问这个操作时间复杂度是多少空间能优化吗我见过不少同学代码写对了但复杂度分析一塌糊涂最终评价大打折扣。第二简历上写的每一项技能都要能应对具体讲一下你用它的场景。比如写了熟悉Spark就一定要能说出一次真实的Spark job里你做了什么优化是用广播变量避免了shuffle还是调整了分区数解决了数据倾斜。如果被追问到答不上来还不如不写因为这会直接拉低面试官对你整体诚信度的评估。7. 一些过来人的实在建议面完这两条线我最大的感觉是百度面试的整体质量是高的每个环节都在考察真东西没有太多面试造火箭、工作拧螺丝的悬浮感。大搜面试官问的海量数据处理和排序架构确实是搜索工程师日常要面对的问题度秘面试官问的意图识别和多轮对话也确实是做语音交互要啃的骨头。准备这类面试我的建议是别刷太多偏题怪题把主线知识吃透比什么都重要。机器学习主线的LR、GBDT、FM、DSSMNLP主线的分词、NER、意图识别、槽位填充、多轮对话系统主线的检索架构、倒排索引、级联排序、缓存设计——这些认真过一遍再配合两三个有深度的项目经验基本就覆盖了大搜和度秘80%以上的考点。我个人在实操中比较受用的一个小方法是每面试完一轮立刻用手机备忘录把被问到的问题和当时的回答记下来当天晚上重新整理一遍把没答好的问题重查资料、重新组织答案。这样每面一轮下一轮的水位就明显高一点。这次面完全部流程我的备忘录里多了快一万字的复盘这些内容比任何面经都值钱因为它们是切切实实从我自己的思考里长出来的。最后再分享一个只有经历过才懂的心得面试不只是公司挑你也是你挑公司。通过面试过程你能很直观地感受到团队的技术品味和做事的风格。大搜的面试官给我感觉是沉稳、扎实、对系统设计有执念度秘的面试官则更开放、思维更跳跃、对产品和技术结合有热情。这种判断不该等拿到offer才做从面试过程里就该有感觉。选择一个和你气质匹配的团队比选择一个听起来光鲜的名字重要得多。
百度大搜与度秘面经：搜索与对话系统核心技术复盘
1. 写在前面为什么是百度大搜和度秘最近面完了百度的两个核心团队一个是大搜搜索业务线一个是度秘智能语音交互感触挺深。这两条线在百度的位置都很特殊——大搜是起家业务技术和业务沉淀最厚度秘是AI落地的窗口代表了百度押注的未来方向。一个偏传统但极致的搜索技术一个偏前沿且复杂的人机交互面试节奏、考察重点甚至面试官风格都有明显差异写出来供准备百度的朋友参考。不管你是刚准备找实习的在校生还是工作几年想跳槽的工程师这篇面经都适用。我会尽量把每轮面试问到的真实问题、我当时怎么答的、事后复盘觉得哪里能答得更好都摊开来讲。面试这种东西光看题目列表没用关键是要理解面试官在考察什么维度——算法功底、工程能力、业务 sense 还是沟通表达不同类型的题目对应不同的应对策略。需要提前说明的是任何面经都有时效性百度不同部门、不同面试官差异也很大。我这篇记录的是我这次的实际经历不代表每次面试都会这样但考察的方向和底层逻辑是稳定的把这些吃透了即使遇到其他题目也能淡定应对。2. 两条业务线的前期功课你至少要懂到什么程度2.1 百度大搜到底在做什么投简历之前我得先把大搜这两个字搞清楚。百度大搜不只是你看到那个搜索框背后是完整的搜索链路爬虫抓取、网页反作弊、索引构建、Query理解、相关性计算、排序模型、搜索结果页的端上体验优化。面试前至少要能把这几个环节串起来知道每个环节的核心技术挑战是什么。以排序为例搜索排序不是简单的相关性高就排前面而是要综合相关性、时效性、权威性、用户体验、商业诉求等多重因素。传统时期用的是LR逻辑回归加人工特征后来演变成GBDT、LambdaMART这些树模型再到现在主流的深度排序模型DSSM、Transformer-based的语义匹配模型每一步演进都有明确的技术逻辑。面试官如果问为什么从LR换成GBDT本质上是在考察你对特征非线性和组合特征的理解——LR只能做线性加权特征之间需要手动做交叉才能表达非线性关系而GBDT天然能自动挖掘特征组合省掉了大量人工特征工程的工作。另外搜索引擎是典型的超大流量、超低延迟的系统这个约束条件决定了你设计的方案必须务实。纯深度模型效果好但耗时高所以业界常见的做法是级联架构先做粗排轻量模型从一万条粗筛到几百条再做精排复杂模型几百条精排到几十条最后做重排处理多样性、去重、品牌约束等。面试中提到这些细节面试官会觉得你真的理解搜索而不是只背了概念。2.2 度秘的技术栈和产品形态度秘是百度的话筒耳朵和嘴巴——它接的是语音交互这条链路唤醒、语音识别ASR、自然语言理解NLU、对话管理DM、自然语言生成NLG、语音合成TTS其中还穿插着云端技能调度和内容服务对接。度秘的面试会明显更偏NLP和对话系统。你需要对任务型对话的经典架构有清晰的认知用户说的话怎么映射到意图和槽位多轮对话状态怎么跟踪和更新对话策略怎么决定回复内容。举个例子帮我订一张明天早上从北京到上海的高铁票这句话意图是订火车票槽位有出发城市北京、到达城市上海、日期明天、时间段早上这些怎么通过意图识别和槽位填充模型抽取出来是度秘面试绕不开的问题。此外度秘面试官特别爱问交互体验不好的场景你会怎么优化这个后面我详细展开。度秘面对的是真实用户、真实流量用户说话有噪音、有口音、有省略、有指代从北京到上海上一轮说了这一轮可能就说那后天呢这种多轮指代消解问题比单轮理解难一个量级。2.3 简历和项目准备的核心原则我得先说一个很多人踩的坑简历上写的项目一定是你能从为什么做、怎么做、遇到什么问题、最终效果、还有哪些优化空间五个维度完整讲清楚的项目。面试官基本都会从简历项目切入如果你的项目是自己实际做的这一轮是送分题如果只是挂名或者年久失修记不清细节这一轮就变成了送命题。我还做了一个小准备把简历里每个项目可能被追问的问题提前列了一个清单全都写了一遍模拟答案。写的过程中会发现很多之前没想清楚的细节比如你这个模型AUC提升0.03具体是在什么数据集上测的离线指标涨了线上有验证吗这些问题如果不提前准备面试现场很容易卡壳。3. 百度大搜面试全流程复盘3.1 第一轮代码与数据结构——基本功速写大搜第一轮是标准的算法coding面1小时内两道题。我遇到的第一道是实现 LRU 缓存第二道是给你一个日志文件的数据流如何实时统计 TopK 热搜词。LRU缓存这道题属于高频题中的高频题考察点是数据结构组合使用哈希表加双向链表哈希表保证O(1)查找双向链表保证O(1)插入和删除两者配合就能实现get和put都是O(1)的缓存淘汰策略。我平时练习时就直接背了模板现场10分钟内写完写完后面试官让我画一下链表节点在get和put操作时的指针变化我画完他点了点头。实时TopK这个题更有意思。我第一反应是维护一个小顶堆堆大小为K新元素进来如果比堆顶大就替换并调整堆这样时间复杂度和空间复杂度都在可控范围。面试官追问如果数据流非常非常大单机内存装不下怎么办我答了哈希分片到多台机器每台机器算局部TopK再归并全局TopK的分布式思路他又追问如果K也很大呢我想了一下说可以用Count-Min Sketch这种概率性数据结构先做频率估计再配合堆或者分段计数牺牲一定的准确率换内存空间。这道题告诉我一个规律大搜这种场景对海量数据处理是有执念的毕竟搜索引擎面对的就是PB级别的网页数据。面试官后面其实就是想听分布式和概率数据结构这两个方向的思路你哪怕没有深度实现过能把原理和取舍讲清楚也能过关。注意写代码的时候一定要边写边说思路不要闷头敲完才解释。面试官要观察的是你的思维过程不是只要一个AC结果。我习惯先写注释框架明确每个函数的输入输出和边界条件再填代码这样既显得有条理也能避免自己写着写着忘记初始意图。3.2 第二轮机器学习基础——从公式到业务第二轮考察机器学习面试官是从简历里我做过的一个CTR预估项目切入的问得很深。他先问Logistic Regression的损失函数是什么我答了交叉熵损失并写出公式和梯度推导。接着他问了一个非常典型的题如果训练数据里正负样本比例是1:99LR训练会有什么问题你会怎么处理这个问题的考察点有两个一是你是否真的理解LR在类别不平衡下的行为——模型会偏向预测多数类因为总损失被多数类主导导致预测概率整体偏低二是处理方案是否落地——常见做法有负样本下采样、正样本过采样、修改损失函数权重但每种方法都有代价。我当时补充了一个搜索场景的实际细节在搜索场景里后验负反馈数据其实很多是曝光未点击这里存在严重的position bias就是排在前面的天然容易获得点击排在后面的即使相关也可能没被点。所以简单的下采样会导致偏差放大业界常用做法是引入位置特征在线推断时把位置特征固定为某个基准值。他还问了GBDT和随机森林的区别。这类送分题反而容易答飘关键是答出本质随机森林是bagging并行训练多棵树降低方差GBDT是boosting串行训练每棵树拟合前一棵的负梯度残差近似降低偏差。另外GBDT的树通常很浅叶子数少因为每棵树只负责修正一部分残差所以弱学习器之间是互补关系而随机森林的树追求多样性每棵树都尽量训充分。最后我补了一句操作经验GBDT对异常值敏感因为拟合残差会被异常样本主导所以预处理时要做异常值截断随机森林则不敏感这个细节面试官明显比较满意。3.3 第三轮综合系统设计——如何设计一个垂直搜索系统这一轮是压力最大的。面试官给了我一个场景假设要为百度内部的员工知识库设计一个垂直搜索系统数据量大概几千万篇文档要求实时索引更新和搜索延迟在几百毫秒以内你会怎么做架构和排序方案拿到这种题千万不要慌没让你真造一个搜索引擎而是考察你的架构思维和取舍能力。我先从整体链路拆文档入库、解析、分词、构建倒排索引查询侧做Query分析、召回、排序、结果呈现。召回阶段用倒排索引加BM25打分先筛出一批候选排序阶段如果预算够再加一个基于语义匹配的模型做精排比如用BERT对Query和Doc做交互式匹配但BERT太慢工程上常用的方案是召回阶段用DSSM双塔模型做向量召回精排再用交叉模型。面试官追了很多细节倒排索引怎么压缩我答了常用的是前向编码和后缀压缩的组合再加跳表加速合并。索引更新的实时性怎么做我用了个比较稳妥的方案全量索引定期重建放慢的冷路径增量索引实时写入走热路径查询时合并两个索引的结果等增量积累到一定规模再和全量做merge。这也是一般搜索系统的经典双索引方案。他还问了如果文档量扩大到现在的10倍你的方案哪里会先扛不住。这个问题本质上是考你对自己方案的瓶颈是否有感知。我说内存索引会不会撑爆——所以要分层存储热数据在内存、冷数据在磁盘排序计算会成为瓶颈——所以要用级联架构先粗排再用高成本模型单机并发不够——所以需要分片和副本分片解决容量问题副本解决吞吐问题。面试官听完笑着说了句你还挺懂搜索引擎的这一轮基本算是稳住了。3.4 第四轮经理面——业务理解和软素质到了经理面已经不太问技术细节了更多是考察综合判断力和业务思维。面试官问了一个让我印象很深的问题如果百度大搜的搜索点击率下降了3%你会从哪些方向排查这个问题其实没有标准答案考察的是系统性思维。我从三个层面拆解第一是数据层先确认点击率下降是真实的还是统计口径变化造成的检查埋点、日志解析、去重逻辑有没有变更第二是链路层从上到下排查——是不是有大量坏流量爬虫、恶意点击、Query分布是否变化、搜索结果有没有出现大面积低质甚至空白页、排序模型有没有灰度过新版本、广告占比是不是提高了挤压了自然结果第三是产品层是不是页面改版导致用户视觉焦点变了、是不是某个大事件密集发生导致热搜类Query集中从而稀释了正常点击。面试官对第三个层面的回答明显更感兴趣因为前两层是常规排查路径第三层体现的是你具备业务视角。这个回答思路后来我用在了多个面试里效果都不错。4. 度秘面试全流程复盘4.1 第一轮NLP基础——中文分词和意图理解的里子度秘第一轮就没有考纯算法题了直接上NLP。第一个问题是中文分词你了解哪些算法自己实现过分词器吗。中文分词是NLP最基础也最经典的问题。我讲了三个主流流派基于词典的最大匹配法简单但无法处理未登录词、基于统计的HMM/CRF方法把分词看成序列标注问题需要标注数据训练、基于神经网络的BiLSTM-CRF方法目前效果最好但需要大量数据。我还特意提了一个工程实践中的点在搜索场景里分词并不是越准越好而是要跟索引和匹配策略配合考虑——有些Query切成粗粒度反而匹配效果更好比如机器学习整词匹配优于切成机器和学习两个词分别去匹配因为后者可能召回大量不相关结果。第二个问题开始深入度秘的场景了度秘收到了用户一句话我想听周杰伦的歌请设计一个完整的处理流程。我从ASR的结果开始说首先判断是否有唤醒词和语音识别的置信度然后是NLU模块做领域分类——这句话属于音乐领域接着做意图识别——播放歌曲再做槽位填充——歌手是周杰伦音乐类型是歌如果缺少必要槽位比如没说具体哪首歌就需要通过对话策略反问用户来澄清。4.2 第二轮对话系统深度——多轮对话的坑第二轮直接上了多轮对话面试官设计了一个场景连续追问用户说帮我订明天去上海的高铁票然后又补了一句不改成后天系统怎么理解这次修改这道题非常妙因为它考察的是多轮对话最核心的难题——指代消解和槽位更新。用户在第二句话里只说了不改成后天没有明确说改什么但系统要能从上下文推断出是修改出发日期。经典的实现方案包括基于规则的指代消解就是把当前轮输入和上一轮的槽位做对齐识别出后天这种时间实体应该替换到哪个槽位、基于特征的判别式方法、基于深度学习的端到端方法把上下文编码成向量再和当前输入做attention融合。对话状态跟踪DST是这里的核心概念。典型的做法是用一个状态表示数据结构记录所有槽位的值每来一轮对话模型要判断这句话是否更新某些槽位。工业界比较实用的方案是逐槽位分类对每个槽位训练一个二分类器判断当前轮是否有该槽位的新值有就更新没有就沿用上一轮的值。我回答中还补了一个工程细节真实场景里用户经常说约后天下午三点而后天是一个相对时间描述系统需要根据当前日期计算成绝对日期存储否则跨天对话就会出现状态错乱。这种细节你说出来面试官就知道你做过真实项目不是纸上谈兵。4.3 第三轮工程实现——召回、排序和对话策略的落地度秘第三轮偏工程系统设计问了一个实际很多的功能如何设计一个百科类知识问答技能用户问珠穆朗玛峰有多高系统要在几百毫秒内给出答案。我的方案分为两大块检索和回答生成。检索部分给知识库文档建索引对Query做改写和扩展召回相关段落然后做一个段落级的排序模型把最相关的段落挑出来。回答生成部分有两个路线抽取式——直接从段落里抽取包含答案的片段生成式——用预训练模型生成答案。在问答领域我倾向于先用抽取式因为可控性和准确率更高生成式容易产生幻觉hallucination也就是模型自信地编造出一个不存在的答案。在知识问答这种对准确性要求极高的场景里幻觉问题非常致命。面试官紧接着问用户如果问珠穆朗玛峰在哪一年被首次登顶你的纯检索方案可能检索不到精确答案怎么办我答这种情况需要叠加知识图谱的能力把问题转成结构化查询。先做实体识别——珠穆朗玛峰再识别关系——首次登顶时间然后去知识图谱里查珠穆朗玛峰这个实体关联的首次登顶时间属性。这就是知识图谱问答KBQA的经典思路。我把这两个方案各自适用的场景说得比较清楚之后面试官露出了你确实理解这块的表情。4.4 第四轮部门负责人面——AI产品观和团队匹配度度秘的第四轮是部门负责人更多聊的是对AI产品的理解和职业规划。他问我你觉得度秘和小爱同学、天猫精灵这些语音助手的本质区别是什么。这个问题让我有点意外因为听起来像产品经理面试题但仔细一想这恰恰是考察你是否有全局视野。我从技术路线和产品定位两个角度回答了技术路线上度秘更强调全双工交互和对话式搜索的能力它能串联百度的搜索和知识图谱答问题的深度和广度有优势产品定位上度秘想成为一个通用的智能助手入口而不是绑定特定硬件的控制中心。面试官又追问了一句那你怎么看待语音交互的未来这个问题我诚实说了自己的观察语音交互在封闭场景车载、智能家居已经比较成熟但在开放场景还有很大的问题——噪音环境下识别率、复杂语义理解准确率、用户使用习惯培养这些都需要长期投入。我不太会说漂亮话但这个比较务实的回答面试官反而认可了。5. 两场面试的横向对比别把同一套准备拿去面所有部门5.1 技术栈侧重完全不同大搜和度秘虽然都在百度但面试风格差异肉眼可见。大搜偏经典机器学习加海量数据工程考点相对固定——LR、GBDT、排序、倒排索引、分布式计算面试官会反复把问题落到数据量大了怎么办延迟要求高了怎么办这些工程约束上。度秘偏NLP和对话系统考点集中在序列标注、意图识别、槽位填充、多轮对话、知识问答上面试官更关注你如何处理歧义和不完美的用户输入。我在准备度秘的时候额外过了一遍BERT和它的变体比如ERNIE因为度秘这种场景对语义理解要求高预训练模型肯定是重点话题。面试官也确实问了ERNIE和BERT的区别我答了ERNIE在预训练阶段引入了知识增强的mask策略不仅mask字词还mask实体和短语让模型能更好地建模先验知识在中文任务上更占优势。5.2 面试轮次的节奏差异大搜的整体节奏是算法题开路机器学习理论跟上系统设计压轴经理面收尾。度秘则是NLP基础开路对话系统深入技能设计压轴负责人面收尾。前者更看重能不能写、能不能算后者更看重能不能理解语言、能不能设计交互。两种面试风格对候选人的要求不同大搜要求算法功底硬、工程素养高度秘要求NLP基础扎实、语言直觉好。准备的时候要有侧重点别用一套模板硬套。5.3 现场发挥的一些共性心得两个团队面试中我都踩过或避开了一些坑总结下来有这样几点第一回答技术问题时一定要先给结论再展开细节面试官一天面很多人你讲三分钟才到重点他会走神第二遇到不会的题不要直接说不会先把相关的、你确定的部分说出来再表达这部分我没有实际经验但我理解大概是……面试官会觉得你至少思路在线第三反问环节一定要问有价值的问题比如团队目前在排序模型上用的是双塔还是交叉模型度秘在多轮对话上自研和用大模型的边界在哪里这些问题会让面试官觉得你是有深度思考的候选人而不是来刷个面经的。6. 百度面试常见问题与避坑速查表我把这次面试和其他朋友的面经里出现的典型问题整理成了一个速查表附上我的参考思路方便大家快速过一遍问题参考思路踩坑提醒LR损失函数推导写出交叉熵损失求梯度说明为什么用交叉熵而不是MSE别只背公式要能解释梯度下降的更新表达式样本不平衡怎么办负采样、权重调整、评估指标用AUC/GAUC别只说换数据集要结合场景说trade-offGBDT和RF区别bagging降方差、boosting降偏差串行与并行从数学直觉解释别只背名词倒排索引怎么存储词典倒排列表压缩编码跳表加速合并只答倒排索引四个字等于没答多轮对话槽位怎么跟踪逐槽位分类更新相对时间转绝对时间别忘了指代消解和省略恢复实体识别怎么做BiLSTM-CRF或BERTCRF标注数据是关键要提未登录词和长尾实体的问题召回和排序的架构粗排召回精排的级联设计要说明为什么不能一步到位知识问答幻觉问题优先抽取式知识图谱校准生成式可控性差别盲目吹生成式要谈落地风险系统延迟怎么优化缓存、量化、蒸馏、级联、并行计算要定量估算别只写方向业务指标下降排查数据口径→链路排查→产品变更→外部因素要有层次千万别上来就怀疑模型另外想专门提醒两点容易被忽略的第一手撕代码时对自己用到的每种数据结构的操作复杂度要心里有数。面试官经常在你写完代码后追问这个操作时间复杂度是多少空间能优化吗我见过不少同学代码写对了但复杂度分析一塌糊涂最终评价大打折扣。第二简历上写的每一项技能都要能应对具体讲一下你用它的场景。比如写了熟悉Spark就一定要能说出一次真实的Spark job里你做了什么优化是用广播变量避免了shuffle还是调整了分区数解决了数据倾斜。如果被追问到答不上来还不如不写因为这会直接拉低面试官对你整体诚信度的评估。7. 一些过来人的实在建议面完这两条线我最大的感觉是百度面试的整体质量是高的每个环节都在考察真东西没有太多面试造火箭、工作拧螺丝的悬浮感。大搜面试官问的海量数据处理和排序架构确实是搜索工程师日常要面对的问题度秘面试官问的意图识别和多轮对话也确实是做语音交互要啃的骨头。准备这类面试我的建议是别刷太多偏题怪题把主线知识吃透比什么都重要。机器学习主线的LR、GBDT、FM、DSSMNLP主线的分词、NER、意图识别、槽位填充、多轮对话系统主线的检索架构、倒排索引、级联排序、缓存设计——这些认真过一遍再配合两三个有深度的项目经验基本就覆盖了大搜和度秘80%以上的考点。我个人在实操中比较受用的一个小方法是每面试完一轮立刻用手机备忘录把被问到的问题和当时的回答记下来当天晚上重新整理一遍把没答好的问题重查资料、重新组织答案。这样每面一轮下一轮的水位就明显高一点。这次面完全部流程我的备忘录里多了快一万字的复盘这些内容比任何面经都值钱因为它们是切切实实从我自己的思考里长出来的。最后再分享一个只有经历过才懂的心得面试不只是公司挑你也是你挑公司。通过面试过程你能很直观地感受到团队的技术品味和做事的风格。大搜的面试官给我感觉是沉稳、扎实、对系统设计有执念度秘的面试官则更开放、思维更跳跃、对产品和技术结合有热情。这种判断不该等拿到offer才做从面试过程里就该有感觉。选择一个和你气质匹配的团队比选择一个听起来光鲜的名字重要得多。