企业官网建设流程全解析

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:99，LR训练会有什么问题？你会怎么处理？"

这个问题的考察点有两个：一是你是否真的理解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. 百度面试常见问题与避坑速查表

我把这次面试和其他朋友的面经里出现的典型问题整理成了一个速查表，附上我的参考思路，方便大家快速过一遍：

另外想专门提醒两点容易被忽略的：

第一，手撕代码时对自己用到的每种数据结构的操作复杂度要心里有数。面试官经常在你写完代码后追问"这个操作时间复杂度是多少""空间能优化吗"，我见过不少同学代码写对了但复杂度分析一塌糊涂，最终评价大打折扣。

第二，简历上写的每一项技能都要能应对"具体讲一下你用它的场景"。比如写了"熟悉Spark"，就一定要能说出一次真实的Spark job里你做了什么优化，是用广播变量避免了shuffle，还是调整了分区数解决了数据倾斜。如果被追问到答不上来，还不如不写，因为这会直接拉低面试官对你整体诚信度的评估。

7. 一些过来人的实在建议

面完这两条线，我最大的感觉是：百度面试的整体质量是高的，每个环节都在考察真东西，没有太多"面试造火箭、工作拧螺丝"的悬浮感。大搜面试官问的海量数据处理和排序架构，确实是搜索工程师日常要面对的问题；度秘面试官问的意图识别和多轮对话，也确实是做语音交互要啃的骨头。

准备这类面试，我的建议是别刷太多偏题怪题，把主线知识吃透比什么都重要。机器学习主线的LR、GBDT、FM、DSSM，NLP主线的分词、NER、意图识别、槽位填充、多轮对话，系统主线的检索架构、倒排索引、级联排序、缓存设计——这些认真过一遍，再配合两三个有深度的项目经验，基本就覆盖了大搜和度秘80%以上的考点。

我个人在实操中比较受用的一个小方法是：每面试完一轮，立刻用手机备忘录把被问到的问题和当时的回答记下来，当天晚上重新整理一遍，把没答好的问题重查资料、重新组织答案。这样每面一轮，下一轮的水位就明显高一点。这次面完全部流程，我的备忘录里多了快一万字的复盘，这些内容比任何面经都值钱，因为它们是切切实实从我自己的思考里长出来的。

最后再分享一个只有经历过才懂的心得：面试不只是公司挑你，也是你挑公司。通过面试过程你能很直观地感受到团队的技术品味和做事的风格。大搜的面试官给我感觉是沉稳、扎实、对系统设计有执念；度秘的面试官则更开放、思维更跳跃、对产品和技术结合有热情。这种判断不该等拿到offer才做，从面试过程里就该有感觉。选择一个和你气质匹配的团队，比选择一个听起来光鲜的名字重要得多。