百度大搜和度秘面经先说下背景。去年秋招我把目标锁定在百度投递时同时选了“大搜索”和“度秘”两个方向后来都走完了面试流程也拿到了其中之一的录用意向。回头看这段经历最大的感受是这两个部门虽然同属一家公司面试风格和考察重点差异比我想象中大得多。如果你正在准备百度相关岗位或者对搜索引擎、对话式AI这两个方向感兴趣这篇面经希望能帮你少走一些弯路。先说结论大搜的面试更像“系统设计机器学习基础”的综合体检度秘则更偏“NLP技术栈对话交互理解”。两类面试都绕不开手撕代码但考察的题型侧重点完全不同。下面我按投递节奏、两边的核心技术考察、手撕环节、以及一些容易被忽略的细节来展开。1. 投递前的目标拆解搜索和对话本质是两种不同的技术栈我先花点时间说清楚为什么要把这两个部门分开准备。很多人投简历时是“看到百度就投了”但大搜和度秘对候选人的画像要求差异非常大提前想清楚能让准备效率翻倍。搜索的本质是“从海量信息里选出最相关的Top K结果”。这意味着核心链路永远围绕召回、排序、相关性判别这三个环节打转。面试官问你的问题不管包装成什么样最终都会落到你如何从千万级文档里快速找到候选集合你如何让排序模型理解“用户搜苹果到底是想要手机还是水果”你如何权衡相关性、时效性、权威性这些冲突的信号度秘的本质则是“理解人的意图并用自然语言完成多轮交互”。它面对的不是静态文档而是高度口语化、信息残缺、指代频繁的对话流。用户说“帮我订个明天下午的会议室”“不还是改到三点吧”这句话里包含了意图切换、槽位修改、时间指代解析而且要在几百毫秒内完成理解并返回动作。面试官关注的是你对NLU、对话管理、知识问答这些技术点的掌握深度而不是你背了多少篇Transformer论文。我见过不少候选人用同一份简历和同一套自我介绍去面这两个部门结果在大搜被问倒排序特征在度秘被追着问多轮对话的槽位填充——不是说这些知识不该懂而是你没有围绕目标岗位做“技术叙事”的重构。面试官想看到的是你对这个方向有完整的认知框架而不是会背几个模型名字。另外要提醒一句投递时间点也是有讲究的。百度秋招通常7月底8月初就开放大搜这种核心部门简历筛选和笔试安排都很早拖到9月中旬再投坑位会少很多。我当时的节奏是6月定方向、7月打磨简历和项目、8月初系统一开放就投8月底约到了第一次面试。如果你现在才开始准备也别慌但速度要提上来。2. 大搜面试的“三件套”检索链路、排序模型、海量数据工程大搜的面试我经历了三面每面的侧重点其实很清晰一面考察基础算法和数据结构的工程应用二面重点考察搜索排序和机器学习三面则偏向系统设计和综合视野。下面按考察权重逐个拆解。2.1 一面倒排索引不是背概念而是推导过程一面开场很直接自我介绍还没说完面试官就问了一个经典问题“给我讲讲倒排索引以及它如何支持查询。”这个问题表面上简单但面试官的追问很细。你光说“倒排索引是词到文档的映射”是过不了关的。他接着会问分词后的term怎么处理大小写、停用词、近义词文档ID怎么压缩词典用什么数据结构存储哈希还是B树两个term的posting list怎么求交集是用跳表、位图还是自适应的策略我当时是从“正排表到倒排表的构建过程”开始讲的然后提到对posting list做差值编码和varint压缩来节省内存再说到多term查询时可以用跳表提高合并效率。面试官对压缩这段明显更有兴趣追问了“如果posting list很长但两个list交集很少跳表还合适吗”这类边界问题。这里我踩过一个小坑一开始我直接回答“用跳表合并”没有先分析数据分布。面试官提醒了一句“你要先判断场景再选数据结构”我才意识到他考察的不是你有没有听过跳表而是你有没有真正做过检索系统、会不会根据term频率做策略选择。建议大家准备时多想想“数据长什么样”和“算法怎么适配数据”而不是单纯背数据结构定义。一面还考了一道手写题要求在有序数组里做二分查找变体——找到第一个大于等于目标值的位置。题目本身不难但面试官盯着看你的边界条件处理。这类题没有什么捷径就是平时写代码时养成“用例子走查边界”的习惯。我习惯在while循环里写死l和r的更新逻辑每次都在纸上先画一个小数组走一遍。2.2 二面排序模型从LR到深度模型的演进为什么要这么走二面是压力最大的一轮围绕排序模型整整聊了四十分钟。面试官先问了一个很开放的题“如果你来设计搜索排序模型第一步会怎么做”这里要注意面试官想要的不是“我直接上BERT”而是完整的思考链路。我的回答思路分了几步先定义什么样的结果是好结果用点击率、停留时长、跳回率这些指标刻画然后确定特征体系包括query端特征、doc端特征、query-doc匹配特征接着考虑训练样本怎么来是用搜索日志里的点击数据还是人工标注最后才是模型选型。说到模型选型面试官就顺理成章地问了“为什么搜索排序早期用LR后来换成了GBDT再后来又转向深度模型”。我当时的理解是LR的可解释性好、训练快非常适合做大规模特征的baselineGBDT能自动发现特征之间的非线性组合关系本质上是让模型来替代人工特征交叉深度模型的优势则是可以端到端学习语义匹配不用强依赖人工构造的匹配信号。面试官接着追问了一句“那深度模型解决了GBDT什么问题”——这个问题的关键点是“表征学习”和“泛化”。GBDT虽然有非线性但面对大规模稀疏特征时还是要靠特征工程去打组合DNN则可以把query和doc都映射到稠密向量空间用向量距离度量相关性对于没见过的query-doc组合也能给出合理预估。我举了一个例子高幂特征“query包含苹果且doc页面包含iPhone”这种组合GBDT需要数据里出现过才能学到而深度模型可以通过embedding的泛化能力直接捕捉语义相关性。这一轮里还有一道让我印象深刻的题“搜索日志里收集到的点击样本直接用会有什么问题”这个问题考察的是Position Bias。搜索结果排在前面的天然更容易被点击如果直接把这些样本喂给模型模型学到的是“位置越靠前越相关”而不是真正的相关性。常见的解法是引入位置特征作为bias项或者用TrustRank、DCTR这类方法做纠偏。面试到这里基本能看出他考察的不只是你会不会用模型而是你了不了解真实系统的脏活累活。2.3 三面如果让你设计一个搜索系统怎么把链路串起来三面风格完全不同面试官没有问具体的算法题而是抛了一个大框架“给我讲讲一个有工业界可用性的搜索系统从用户输入query到最终返回结果你会在每一层做什么。”这个问题看着唬人其实是考察你有没有全局视野。我按链路拆开回答首先query理解层做分词、纠错、意图识别和query改写然后是召回层用倒排索引配合向量召回做多路召回兼顾精确匹配和语义泛化接着是粗排用轻量模型从几万个候选里筛出几百个再做精排用复杂模型打分最后是重排处理多样性、品牌约束、商业结果混排等问题。三面面试官听了没有追问细节而是问了一个偏理念的问题“粗排和精排的模型差距为什么不可以消除如果算力足够为什么还要分两层”我的理解是粗排面对的候选集数量级太大必须用更轻量的模型才能满足延迟约束而且粗排的目标是“别把好结果漏掉”精度要求比精排低一档两者在工业界是成本和效果的权衡。即便算力无限我们也会主动做分层因为系统设计永远是“在最贵的环节上做最精细的决策”。现在回想三面其实已经不太关注我“会什么”了更多是看我的技术表达能不能支撑起一个完整的系统叙事。如果你也想投大搜建议提前把“一整套搜索链路”从头到尾过一遍不用每个模块都深入但要做到每个环节都能说出“解决什么问题、有没有替代方案”的程度。3. 度秘面试的“对话叙事”从NLU到多轮管理问的就是“你怎么让人听懂”相比大搜的重系统工程度秘的面试更聚焦在NLP的各个技术环节。三轮面试基本覆盖了NLU、对话状态管理、生成与检索式回复、知识问答这几块而且面试官明显更在意你对语言问题的直觉理解。3.1 一面意图识别和槽位填充是联合建模不是两个独立任务一面开场就问了一个我刚接触对话系统时经常搞混的问题“意图识别和槽位提取为什么要做成联合模型而不是分别训练两个模型”说实话这个问题如果你只从“效果更好”这个角度回答会显得很单薄。我的理解是意图和槽位之间存在强依赖关系用户说“帮我订一张明天去上海的机票”“订机票”这个意图决定了“明天”是出发时间、“上海”是目的地反过来“上海”这个槽位又强化了“订机票”的意图判断。分开建模会丢失这种交互信息而Joint Model可以在特征层面共享语义表示让两个任务互相增强。接着面试官让我在白板上画一个基于BERT的Joint NLU模型结构。我用的是经典的做法BERT编码后[CLS]位置的向量接一个softmax做意图分类其余token位置接序列标注层做槽位填充。面试官追了一句“如果让你在线上部署BERT的延迟太高怎么办”这算是个典型的工业落地问题。我的回答是几个方向并行蒸馏一个更小的模型、只对意图置信度低的query跑完整模型、把高频query的结果做缓存。这些都是工业界常见的降延迟手段。一面还考察了序列标注的基础。面试官问到“BIO标注里为什么需要B和I两种标签”我解释这是为了区分槽位的边界比如“北京市朝阳区”里“北京”和“朝阳区”两个实体没有B/I就无法判断“市”到底属于哪个实体。这类问题看似基础但能看出你是不是真的做过标注数据的清洗和转换。3.2 二面多轮对话的状态管理怎么处理“改个时间”这种指代二面是整个度秘面试里含金量最高的一轮因为面试官抛了一个非常具体的场景“用户先说‘帮我订明天下午三点的会议室’紧接着又说‘改成四点吧’。你觉得系统需要做什么才能在第二轮正确理解”这个问题一出来我知道他想要的是对话状态追踪DST的思路。我拆成几步回答第一轮要解析出“订会议室”这个意图以及“明天”“下午三点”这些槽位第二轮出现“改成四点”系统要识别出这是一个修改动作而不是新的独立意图接着要找到“四点”替代的是哪个槽位——这里需要结合对话历史和语义判断“四点”是一个时间应该覆盖“下午三点”这个已有的时间槽位最后还要把更新后的状态维护起来传给后续策略模块决定怎么回复。面试官追问“如果用户说‘那还是原来的时间吧’呢”这里考察的是槽位回退slot carry-over/rollback系统需要支持恢复历史槽位值。我提到可以将每一轮对话的完整状态都存成快照遇到回退类表达时直接恢复某个历史快照同时备注“这种方案在复杂场景需要考虑用户是回退一步还是回到最初”面试官表示认可。这一轮里我还被问到了“对话生成是检索式好还是生成式好”。我的观点是两者都有不可替代的场景检索式适合知识性问答因为答案可以被人工审核安全可控生成式适合开放域的闲聊表达更灵活但容易生成“正确的废话”或者事实错误。工业界常见做法是用生成式做候选、检索式做过滤或者反过来把两者融合起来。这种“没有标准答案但从工程角度权衡”的回答方式在对话系统的面试中比站队某一个方案更受欢迎。3.3 三面知识问答的实体链接与图推理偶尔还来一道数学题三面开始前我以为是纯粹的聊天面结果面试官还是问了一道偏研究的问题“知识库问答KBQA里让系统回答‘周杰伦的妻子的生日是什么时候’需要哪些关键步骤”我按KBQA的经典流程回答先是实体链接把“周杰伦”映射到知识库中的某个实体节点然后是关系识别识别出“妻子”和“生日”是两跳关系不是一跳接着在知识图谱上做路径搜索和推理找到目标节点最后组织成自然语言回答。面试官顺着追问“实体链接里的指代消解怎么做”我举了“他老婆”这种代词如何在对话上下文中找到指代对象的例子结合了前一轮多轮对话的知识。这轮里还有一道让我意外的小题“给你一组英文单词找出出现次数最多的前K个内存有限怎么办。”这是大搜那边风格的问题出现在度秘三面里提醒我基础算法能力是所有方向都绕不开的只是出现概率和高低不同。这道题我用的方法是哈希统计小顶堆维护TopK内存不够就分片到多台机器上做MapReduce式的统计再合并。说实话这种题没有太多技巧平时多刷几道TopK变体基本都能从容应对。4. 手撕代码的真实题单高频题型和“面试官到底在看什么”两个部门加起来我手写了大概六道题。这里把我遇到的题整理一下也给一个准备的优先级参考。4.1 高频题型回顾大搜三轮里手写了三道风格偏数据结构与经典算法有序数组中找到第一个不小于目标值的位置二分查找变体考察边界条件和循环不变量。大文件里统计词频并找出Top K个词考察哈希堆以及内存受限时的分治思路。给定一个只包含括号的字符串判断括号是否合法并找出最长合法子串长度考察栈和动态规划。度秘三轮里手写了三道风格明显更偏字符串处理和NLP相关字符串编辑距离Levenshtein Distance这题在对话系统里真的很常见因为涉及query纠错和相似度度量。实现一个简单的Trie树支持插入和前缀查询这是词典、实体匹配的基础结构。给定一个句子按空格切分后逆序输出考察边界处理和O(N)原地操作。度秘的面试官在手写Trie树时额外问了一个问题“如果让你对几亿个query做前缀提示Trie树会不会爆内存”这是典型的“算法题系统设计”结合模式。我回答可以用压缩前缀树Radix Tree减少节点数或者用有限状态自动机做更紧凑的编码再多就考虑分片存储。面试官说“能想到压缩节点就还不错”说明手写题本身不是全部你如何展示对生产环境约束的理解才是加分项。4.2 面试官看的是什么不是AC而是你的思考过程我经历过几次面试后总结手撕代码环节里面试官真正在意的是三件事。第一你拿到题之后会不会先停顿思考。直接上手写代码的人看似自信但经常写到一半才发现有bug。我更习惯先说“我先想几个例子把问题定义清楚”然后在白板上画一两个输入输出明确边界条件再开始写。这个习惯让我在“字符串逆序”那道题上快速发现了空字符串和尾随空格的问题。第二你写代码的时候是“背模板”还是“理解逻辑”。比如编辑距离那题如果你能说出“dp[i][j]表示A前i个字符到B前j个字符的最小编辑距离”然后把状态转移方程推导一遍面试官基本不会再看你的代码细节。反过来如果你写对了代码但说不清状态的含义面试官会怀疑你是背过的。第三写完代码之后你会不会主动测试。我有一道TopK题写完后又手动走了一个小case发现自己的堆调整逻辑里有个边界没处理好当场改了。这个主动走查的动作比写对代码本身更让面试官加分。5. 两条线的区别对比投递前你需要做的选择与准备想同时准备两个方向的朋友建议先做一个简单的SWOT式分析别把精力平均分配。这里用表格对比一下我在两个方向上的真实感受。对比维度大搜度秘核心考察点检索、排序、CTR预估、海量数据工程NLU、多轮对话、知识问答、文本生成算法题风格数据结构、TopK、海量数据处理字符串处理、Trie树、编辑距离、序列标注系统设计题完整搜索链路、缓存、分层架构对话状态管理、bot架构、延迟优化面试官风格更偏工程爱追问边界条件更偏算法与产品感爱讲场景推荐背景有搜索/推荐/广告经验系统工程能力强NLP/深度学习理论扎实对对话交互有热情我个人的建议是如果你时间有限选定一个主攻方向另一个作为背书和广度加分项。我当时主攻的是搜索方向但因为在项目里做过一个简单的对话FAQ机器人所以投度秘时也能勉强衔接得上。真实面试里我没有被要求同时回答两个方向的高难度问题因为每轮面试官都清楚你的目标岗位。5.1 简历上怎么同时体现两个方向的匹配度这一点很容易被忽略。我在简历里放了两段项目一个偏搜索相关性排序一个偏对话意图识别。针对大搜的面试我重点讲搜索那段的特征设计和评估指标对话项目只用一句话带过针对度秘的面试我把对话项目放在前面详细展开多轮状态的建模细节搜索项目则简化为“对用户query的理解经验”。这不是造假而是面试沟通的“叙事重构”——你希望面试官在有限时间内关注你哪些能力就应该用简历的排列顺序和讲解篇幅来引导。上面试官角度想他们每天面很多人候选人如果一上来就讲一堆项目信息密度高但重点不突出反而很难留下印象。所以我建议在简历里为每个项目写一个“一句话核心亮点”比如“在一个月内用BERT联合模型将意图识别准确率从89%提升到93%”这样当你介绍项目时面试官能快速抓住你想表达的重点。5.2 复盘工具我把每轮面试都做成了“错题本”准备面试时我建了一个在线表格记录每轮面试被问到的所有问题、我的回答思路、以及“如果让我重新答我会怎么改”。这样做有两点好处。第一能发现自己反复被追问的薄弱点。比如我前两次面试都在“Position Bias的解决方案”上被问倒了复盘后我专门写了一段标准回答后续再遇到这类问题就不慌了。第二能形成一份自己的“面经素材库”。每次面试前翻一遍能快速唤起记忆节省大量重新准备时间。这种方法尤其适合跨度大的方向。我在大搜面完记录的“模型分层意义”在后面度秘聊对话系统时竟然也用上了——因为对话系统同样有意图识别的粗排和精排之分。不同方向之间的知识迁移是常有的事关键是你要有一套自己的知识框架去连接它们。6. 容易被忽视的细节流程节奏、反问环节和心态管理最后聊几个非技术但实际影响面试结果的因素。整个流程的节奏大概是这样大搜的一面到三面间隔很短基本每隔三到四天就会收到下一轮通知三面之后等了大约一周才有HR联系度秘的流程也类似但二面之后隔了更久。每一轮面试结束后我一般会在当天晚上把问题整理到错题本里不然隔几天就忘干净了。如果你等了一段时间没有反馈不用太焦虑大厂面试流程涉及多个部门的协调时间不稳定太正常了。反问环节是很多人没有充分利用的部分。我一般会根据面试轮次选择不同的问题一面问“这个岗位日常接触最多的技术栈是什么”想了解实际工作内容二面三面问“团队目前最大的技术挑战是什么”或者“业务上接下来一到两年的方向”这类偏业务的问题能展示你的思考深度。不要问“我表现的怎么样”这种让面试官尴尬的问题也尽量避免“有什么培训机制吗”这种过于关注个人福利的问题。好的反问是“基于你已有的了解对业务或技术提出一个新的问题”比如“搜索排序里对冷门query的低频词我很好奇你们是怎么做泛化的”这种问题能让面试官觉得你已经在思考实际场景了。心态上我想说一个真实体会不要把每一轮都当成“考试”而是当成一次“跟同行闲聊”的机会。我表现最好的两轮面试都是在调整好心态、把面试官当成可以学习的前辈之后。技术面里遇到不会的问题很正常面试官也不是期待你全都会。他更在意的是你被问倒之后的表现——是慌张地东拉西扯还是坦诚说“这个我没有深入研究过”然后从已知的基础知识出发尝试给出推理。我在二面被问到对话生成的评估指标时确实没有系统学过BLEU之外的指标就直接说“BLEU我知道但针对对话这种开放域问题我理解BLEU的评价效度不高具体有什么更好的指标我不太了解”面试官反而点头说“你能意识到BLEU的局限说明你真的思考过”。6.1 项目深挖面试官问题永远比你说的更细无论大搜还是度秘面试官都会花一部分时间深挖简历里的项目。这里的核心法则是你写在简历上的每一项指标、每一个技术选型都要准备好被追问“为什么”和“如果不这样做会怎样”。比如我在项目里写到“用BERT提升语义匹配的AUC”面试官就问“你有算过BERT上线比以前模型慢多少吗线上是怎么优化的”我当时因为只做了离线实验回答得有些含糊。复盘后我明白简历里每一句话都可能暴露出你的项目到底做到了哪一层做过的和“了解过的”在面试官追问下很快就露馅。建议大家在投递前把简历上的每个项目都按“技术方案-结果-暴露的问题-如果重做会怎么改”四个维度写一遍底稿面试时就能从容不少。6.2 知识迁移搜索和对话的交叉点往往是加分区域我在面试后期发现一个有意思的现象大搜和度秘虽然考察重点不同但两者的交叉部分越来越多。搜索里的query理解本质上就是一个NLU任务对话式搜索、AI智能助手本质上又是搜索和对话的结合。面试官在你的回答里听到你能把两个领域的知识打通通常会是加分项。比如在度秘二面我提到“多轮对话的槽位追踪”顺带聊了一句“这跟搜索里的查询改写有相似之处都是为了理解用户当前真正想要什么”面试官就多问了些搜索改写的方法。在大搜三面也提到“语义向量召回”时我补充说“这种向量化的思路在对话检索里也常见”面试官点了点头。当然这里要注意别讲得太刻意自然地带一句“这个思路我在另一个项目里也用过”就好。最后再分享一个实用的小技巧准备面试时把自己当成面试官给你的目标岗位设计一套“完美的面试问题”然后自己试着用最简洁的方式回答一遍。这套问题最好包括这个岗位解决什么业务问题核心技术链路是什么当前的瓶颈可能在哪里如果你入职了你最有信心促成的改进是什么我当时就是用这个方法快速构建了对两个方向的结构化认知投递后心里踏实很多。希望这篇面经对你的百度和度秘之旅有帮助也祝你能把面试当成一次高质量的同行交流享受这个过程。
百度大搜与度秘面经：搜索与对话AI技术栈全解析
百度大搜和度秘面经先说下背景。去年秋招我把目标锁定在百度投递时同时选了“大搜索”和“度秘”两个方向后来都走完了面试流程也拿到了其中之一的录用意向。回头看这段经历最大的感受是这两个部门虽然同属一家公司面试风格和考察重点差异比我想象中大得多。如果你正在准备百度相关岗位或者对搜索引擎、对话式AI这两个方向感兴趣这篇面经希望能帮你少走一些弯路。先说结论大搜的面试更像“系统设计机器学习基础”的综合体检度秘则更偏“NLP技术栈对话交互理解”。两类面试都绕不开手撕代码但考察的题型侧重点完全不同。下面我按投递节奏、两边的核心技术考察、手撕环节、以及一些容易被忽略的细节来展开。1. 投递前的目标拆解搜索和对话本质是两种不同的技术栈我先花点时间说清楚为什么要把这两个部门分开准备。很多人投简历时是“看到百度就投了”但大搜和度秘对候选人的画像要求差异非常大提前想清楚能让准备效率翻倍。搜索的本质是“从海量信息里选出最相关的Top K结果”。这意味着核心链路永远围绕召回、排序、相关性判别这三个环节打转。面试官问你的问题不管包装成什么样最终都会落到你如何从千万级文档里快速找到候选集合你如何让排序模型理解“用户搜苹果到底是想要手机还是水果”你如何权衡相关性、时效性、权威性这些冲突的信号度秘的本质则是“理解人的意图并用自然语言完成多轮交互”。它面对的不是静态文档而是高度口语化、信息残缺、指代频繁的对话流。用户说“帮我订个明天下午的会议室”“不还是改到三点吧”这句话里包含了意图切换、槽位修改、时间指代解析而且要在几百毫秒内完成理解并返回动作。面试官关注的是你对NLU、对话管理、知识问答这些技术点的掌握深度而不是你背了多少篇Transformer论文。我见过不少候选人用同一份简历和同一套自我介绍去面这两个部门结果在大搜被问倒排序特征在度秘被追着问多轮对话的槽位填充——不是说这些知识不该懂而是你没有围绕目标岗位做“技术叙事”的重构。面试官想看到的是你对这个方向有完整的认知框架而不是会背几个模型名字。另外要提醒一句投递时间点也是有讲究的。百度秋招通常7月底8月初就开放大搜这种核心部门简历筛选和笔试安排都很早拖到9月中旬再投坑位会少很多。我当时的节奏是6月定方向、7月打磨简历和项目、8月初系统一开放就投8月底约到了第一次面试。如果你现在才开始准备也别慌但速度要提上来。2. 大搜面试的“三件套”检索链路、排序模型、海量数据工程大搜的面试我经历了三面每面的侧重点其实很清晰一面考察基础算法和数据结构的工程应用二面重点考察搜索排序和机器学习三面则偏向系统设计和综合视野。下面按考察权重逐个拆解。2.1 一面倒排索引不是背概念而是推导过程一面开场很直接自我介绍还没说完面试官就问了一个经典问题“给我讲讲倒排索引以及它如何支持查询。”这个问题表面上简单但面试官的追问很细。你光说“倒排索引是词到文档的映射”是过不了关的。他接着会问分词后的term怎么处理大小写、停用词、近义词文档ID怎么压缩词典用什么数据结构存储哈希还是B树两个term的posting list怎么求交集是用跳表、位图还是自适应的策略我当时是从“正排表到倒排表的构建过程”开始讲的然后提到对posting list做差值编码和varint压缩来节省内存再说到多term查询时可以用跳表提高合并效率。面试官对压缩这段明显更有兴趣追问了“如果posting list很长但两个list交集很少跳表还合适吗”这类边界问题。这里我踩过一个小坑一开始我直接回答“用跳表合并”没有先分析数据分布。面试官提醒了一句“你要先判断场景再选数据结构”我才意识到他考察的不是你有没有听过跳表而是你有没有真正做过检索系统、会不会根据term频率做策略选择。建议大家准备时多想想“数据长什么样”和“算法怎么适配数据”而不是单纯背数据结构定义。一面还考了一道手写题要求在有序数组里做二分查找变体——找到第一个大于等于目标值的位置。题目本身不难但面试官盯着看你的边界条件处理。这类题没有什么捷径就是平时写代码时养成“用例子走查边界”的习惯。我习惯在while循环里写死l和r的更新逻辑每次都在纸上先画一个小数组走一遍。2.2 二面排序模型从LR到深度模型的演进为什么要这么走二面是压力最大的一轮围绕排序模型整整聊了四十分钟。面试官先问了一个很开放的题“如果你来设计搜索排序模型第一步会怎么做”这里要注意面试官想要的不是“我直接上BERT”而是完整的思考链路。我的回答思路分了几步先定义什么样的结果是好结果用点击率、停留时长、跳回率这些指标刻画然后确定特征体系包括query端特征、doc端特征、query-doc匹配特征接着考虑训练样本怎么来是用搜索日志里的点击数据还是人工标注最后才是模型选型。说到模型选型面试官就顺理成章地问了“为什么搜索排序早期用LR后来换成了GBDT再后来又转向深度模型”。我当时的理解是LR的可解释性好、训练快非常适合做大规模特征的baselineGBDT能自动发现特征之间的非线性组合关系本质上是让模型来替代人工特征交叉深度模型的优势则是可以端到端学习语义匹配不用强依赖人工构造的匹配信号。面试官接着追问了一句“那深度模型解决了GBDT什么问题”——这个问题的关键点是“表征学习”和“泛化”。GBDT虽然有非线性但面对大规模稀疏特征时还是要靠特征工程去打组合DNN则可以把query和doc都映射到稠密向量空间用向量距离度量相关性对于没见过的query-doc组合也能给出合理预估。我举了一个例子高幂特征“query包含苹果且doc页面包含iPhone”这种组合GBDT需要数据里出现过才能学到而深度模型可以通过embedding的泛化能力直接捕捉语义相关性。这一轮里还有一道让我印象深刻的题“搜索日志里收集到的点击样本直接用会有什么问题”这个问题考察的是Position Bias。搜索结果排在前面的天然更容易被点击如果直接把这些样本喂给模型模型学到的是“位置越靠前越相关”而不是真正的相关性。常见的解法是引入位置特征作为bias项或者用TrustRank、DCTR这类方法做纠偏。面试到这里基本能看出他考察的不只是你会不会用模型而是你了不了解真实系统的脏活累活。2.3 三面如果让你设计一个搜索系统怎么把链路串起来三面风格完全不同面试官没有问具体的算法题而是抛了一个大框架“给我讲讲一个有工业界可用性的搜索系统从用户输入query到最终返回结果你会在每一层做什么。”这个问题看着唬人其实是考察你有没有全局视野。我按链路拆开回答首先query理解层做分词、纠错、意图识别和query改写然后是召回层用倒排索引配合向量召回做多路召回兼顾精确匹配和语义泛化接着是粗排用轻量模型从几万个候选里筛出几百个再做精排用复杂模型打分最后是重排处理多样性、品牌约束、商业结果混排等问题。三面面试官听了没有追问细节而是问了一个偏理念的问题“粗排和精排的模型差距为什么不可以消除如果算力足够为什么还要分两层”我的理解是粗排面对的候选集数量级太大必须用更轻量的模型才能满足延迟约束而且粗排的目标是“别把好结果漏掉”精度要求比精排低一档两者在工业界是成本和效果的权衡。即便算力无限我们也会主动做分层因为系统设计永远是“在最贵的环节上做最精细的决策”。现在回想三面其实已经不太关注我“会什么”了更多是看我的技术表达能不能支撑起一个完整的系统叙事。如果你也想投大搜建议提前把“一整套搜索链路”从头到尾过一遍不用每个模块都深入但要做到每个环节都能说出“解决什么问题、有没有替代方案”的程度。3. 度秘面试的“对话叙事”从NLU到多轮管理问的就是“你怎么让人听懂”相比大搜的重系统工程度秘的面试更聚焦在NLP的各个技术环节。三轮面试基本覆盖了NLU、对话状态管理、生成与检索式回复、知识问答这几块而且面试官明显更在意你对语言问题的直觉理解。3.1 一面意图识别和槽位填充是联合建模不是两个独立任务一面开场就问了一个我刚接触对话系统时经常搞混的问题“意图识别和槽位提取为什么要做成联合模型而不是分别训练两个模型”说实话这个问题如果你只从“效果更好”这个角度回答会显得很单薄。我的理解是意图和槽位之间存在强依赖关系用户说“帮我订一张明天去上海的机票”“订机票”这个意图决定了“明天”是出发时间、“上海”是目的地反过来“上海”这个槽位又强化了“订机票”的意图判断。分开建模会丢失这种交互信息而Joint Model可以在特征层面共享语义表示让两个任务互相增强。接着面试官让我在白板上画一个基于BERT的Joint NLU模型结构。我用的是经典的做法BERT编码后[CLS]位置的向量接一个softmax做意图分类其余token位置接序列标注层做槽位填充。面试官追了一句“如果让你在线上部署BERT的延迟太高怎么办”这算是个典型的工业落地问题。我的回答是几个方向并行蒸馏一个更小的模型、只对意图置信度低的query跑完整模型、把高频query的结果做缓存。这些都是工业界常见的降延迟手段。一面还考察了序列标注的基础。面试官问到“BIO标注里为什么需要B和I两种标签”我解释这是为了区分槽位的边界比如“北京市朝阳区”里“北京”和“朝阳区”两个实体没有B/I就无法判断“市”到底属于哪个实体。这类问题看似基础但能看出你是不是真的做过标注数据的清洗和转换。3.2 二面多轮对话的状态管理怎么处理“改个时间”这种指代二面是整个度秘面试里含金量最高的一轮因为面试官抛了一个非常具体的场景“用户先说‘帮我订明天下午三点的会议室’紧接着又说‘改成四点吧’。你觉得系统需要做什么才能在第二轮正确理解”这个问题一出来我知道他想要的是对话状态追踪DST的思路。我拆成几步回答第一轮要解析出“订会议室”这个意图以及“明天”“下午三点”这些槽位第二轮出现“改成四点”系统要识别出这是一个修改动作而不是新的独立意图接着要找到“四点”替代的是哪个槽位——这里需要结合对话历史和语义判断“四点”是一个时间应该覆盖“下午三点”这个已有的时间槽位最后还要把更新后的状态维护起来传给后续策略模块决定怎么回复。面试官追问“如果用户说‘那还是原来的时间吧’呢”这里考察的是槽位回退slot carry-over/rollback系统需要支持恢复历史槽位值。我提到可以将每一轮对话的完整状态都存成快照遇到回退类表达时直接恢复某个历史快照同时备注“这种方案在复杂场景需要考虑用户是回退一步还是回到最初”面试官表示认可。这一轮里我还被问到了“对话生成是检索式好还是生成式好”。我的观点是两者都有不可替代的场景检索式适合知识性问答因为答案可以被人工审核安全可控生成式适合开放域的闲聊表达更灵活但容易生成“正确的废话”或者事实错误。工业界常见做法是用生成式做候选、检索式做过滤或者反过来把两者融合起来。这种“没有标准答案但从工程角度权衡”的回答方式在对话系统的面试中比站队某一个方案更受欢迎。3.3 三面知识问答的实体链接与图推理偶尔还来一道数学题三面开始前我以为是纯粹的聊天面结果面试官还是问了一道偏研究的问题“知识库问答KBQA里让系统回答‘周杰伦的妻子的生日是什么时候’需要哪些关键步骤”我按KBQA的经典流程回答先是实体链接把“周杰伦”映射到知识库中的某个实体节点然后是关系识别识别出“妻子”和“生日”是两跳关系不是一跳接着在知识图谱上做路径搜索和推理找到目标节点最后组织成自然语言回答。面试官顺着追问“实体链接里的指代消解怎么做”我举了“他老婆”这种代词如何在对话上下文中找到指代对象的例子结合了前一轮多轮对话的知识。这轮里还有一道让我意外的小题“给你一组英文单词找出出现次数最多的前K个内存有限怎么办。”这是大搜那边风格的问题出现在度秘三面里提醒我基础算法能力是所有方向都绕不开的只是出现概率和高低不同。这道题我用的方法是哈希统计小顶堆维护TopK内存不够就分片到多台机器上做MapReduce式的统计再合并。说实话这种题没有太多技巧平时多刷几道TopK变体基本都能从容应对。4. 手撕代码的真实题单高频题型和“面试官到底在看什么”两个部门加起来我手写了大概六道题。这里把我遇到的题整理一下也给一个准备的优先级参考。4.1 高频题型回顾大搜三轮里手写了三道风格偏数据结构与经典算法有序数组中找到第一个不小于目标值的位置二分查找变体考察边界条件和循环不变量。大文件里统计词频并找出Top K个词考察哈希堆以及内存受限时的分治思路。给定一个只包含括号的字符串判断括号是否合法并找出最长合法子串长度考察栈和动态规划。度秘三轮里手写了三道风格明显更偏字符串处理和NLP相关字符串编辑距离Levenshtein Distance这题在对话系统里真的很常见因为涉及query纠错和相似度度量。实现一个简单的Trie树支持插入和前缀查询这是词典、实体匹配的基础结构。给定一个句子按空格切分后逆序输出考察边界处理和O(N)原地操作。度秘的面试官在手写Trie树时额外问了一个问题“如果让你对几亿个query做前缀提示Trie树会不会爆内存”这是典型的“算法题系统设计”结合模式。我回答可以用压缩前缀树Radix Tree减少节点数或者用有限状态自动机做更紧凑的编码再多就考虑分片存储。面试官说“能想到压缩节点就还不错”说明手写题本身不是全部你如何展示对生产环境约束的理解才是加分项。4.2 面试官看的是什么不是AC而是你的思考过程我经历过几次面试后总结手撕代码环节里面试官真正在意的是三件事。第一你拿到题之后会不会先停顿思考。直接上手写代码的人看似自信但经常写到一半才发现有bug。我更习惯先说“我先想几个例子把问题定义清楚”然后在白板上画一两个输入输出明确边界条件再开始写。这个习惯让我在“字符串逆序”那道题上快速发现了空字符串和尾随空格的问题。第二你写代码的时候是“背模板”还是“理解逻辑”。比如编辑距离那题如果你能说出“dp[i][j]表示A前i个字符到B前j个字符的最小编辑距离”然后把状态转移方程推导一遍面试官基本不会再看你的代码细节。反过来如果你写对了代码但说不清状态的含义面试官会怀疑你是背过的。第三写完代码之后你会不会主动测试。我有一道TopK题写完后又手动走了一个小case发现自己的堆调整逻辑里有个边界没处理好当场改了。这个主动走查的动作比写对代码本身更让面试官加分。5. 两条线的区别对比投递前你需要做的选择与准备想同时准备两个方向的朋友建议先做一个简单的SWOT式分析别把精力平均分配。这里用表格对比一下我在两个方向上的真实感受。对比维度大搜度秘核心考察点检索、排序、CTR预估、海量数据工程NLU、多轮对话、知识问答、文本生成算法题风格数据结构、TopK、海量数据处理字符串处理、Trie树、编辑距离、序列标注系统设计题完整搜索链路、缓存、分层架构对话状态管理、bot架构、延迟优化面试官风格更偏工程爱追问边界条件更偏算法与产品感爱讲场景推荐背景有搜索/推荐/广告经验系统工程能力强NLP/深度学习理论扎实对对话交互有热情我个人的建议是如果你时间有限选定一个主攻方向另一个作为背书和广度加分项。我当时主攻的是搜索方向但因为在项目里做过一个简单的对话FAQ机器人所以投度秘时也能勉强衔接得上。真实面试里我没有被要求同时回答两个方向的高难度问题因为每轮面试官都清楚你的目标岗位。5.1 简历上怎么同时体现两个方向的匹配度这一点很容易被忽略。我在简历里放了两段项目一个偏搜索相关性排序一个偏对话意图识别。针对大搜的面试我重点讲搜索那段的特征设计和评估指标对话项目只用一句话带过针对度秘的面试我把对话项目放在前面详细展开多轮状态的建模细节搜索项目则简化为“对用户query的理解经验”。这不是造假而是面试沟通的“叙事重构”——你希望面试官在有限时间内关注你哪些能力就应该用简历的排列顺序和讲解篇幅来引导。上面试官角度想他们每天面很多人候选人如果一上来就讲一堆项目信息密度高但重点不突出反而很难留下印象。所以我建议在简历里为每个项目写一个“一句话核心亮点”比如“在一个月内用BERT联合模型将意图识别准确率从89%提升到93%”这样当你介绍项目时面试官能快速抓住你想表达的重点。5.2 复盘工具我把每轮面试都做成了“错题本”准备面试时我建了一个在线表格记录每轮面试被问到的所有问题、我的回答思路、以及“如果让我重新答我会怎么改”。这样做有两点好处。第一能发现自己反复被追问的薄弱点。比如我前两次面试都在“Position Bias的解决方案”上被问倒了复盘后我专门写了一段标准回答后续再遇到这类问题就不慌了。第二能形成一份自己的“面经素材库”。每次面试前翻一遍能快速唤起记忆节省大量重新准备时间。这种方法尤其适合跨度大的方向。我在大搜面完记录的“模型分层意义”在后面度秘聊对话系统时竟然也用上了——因为对话系统同样有意图识别的粗排和精排之分。不同方向之间的知识迁移是常有的事关键是你要有一套自己的知识框架去连接它们。6. 容易被忽视的细节流程节奏、反问环节和心态管理最后聊几个非技术但实际影响面试结果的因素。整个流程的节奏大概是这样大搜的一面到三面间隔很短基本每隔三到四天就会收到下一轮通知三面之后等了大约一周才有HR联系度秘的流程也类似但二面之后隔了更久。每一轮面试结束后我一般会在当天晚上把问题整理到错题本里不然隔几天就忘干净了。如果你等了一段时间没有反馈不用太焦虑大厂面试流程涉及多个部门的协调时间不稳定太正常了。反问环节是很多人没有充分利用的部分。我一般会根据面试轮次选择不同的问题一面问“这个岗位日常接触最多的技术栈是什么”想了解实际工作内容二面三面问“团队目前最大的技术挑战是什么”或者“业务上接下来一到两年的方向”这类偏业务的问题能展示你的思考深度。不要问“我表现的怎么样”这种让面试官尴尬的问题也尽量避免“有什么培训机制吗”这种过于关注个人福利的问题。好的反问是“基于你已有的了解对业务或技术提出一个新的问题”比如“搜索排序里对冷门query的低频词我很好奇你们是怎么做泛化的”这种问题能让面试官觉得你已经在思考实际场景了。心态上我想说一个真实体会不要把每一轮都当成“考试”而是当成一次“跟同行闲聊”的机会。我表现最好的两轮面试都是在调整好心态、把面试官当成可以学习的前辈之后。技术面里遇到不会的问题很正常面试官也不是期待你全都会。他更在意的是你被问倒之后的表现——是慌张地东拉西扯还是坦诚说“这个我没有深入研究过”然后从已知的基础知识出发尝试给出推理。我在二面被问到对话生成的评估指标时确实没有系统学过BLEU之外的指标就直接说“BLEU我知道但针对对话这种开放域问题我理解BLEU的评价效度不高具体有什么更好的指标我不太了解”面试官反而点头说“你能意识到BLEU的局限说明你真的思考过”。6.1 项目深挖面试官问题永远比你说的更细无论大搜还是度秘面试官都会花一部分时间深挖简历里的项目。这里的核心法则是你写在简历上的每一项指标、每一个技术选型都要准备好被追问“为什么”和“如果不这样做会怎样”。比如我在项目里写到“用BERT提升语义匹配的AUC”面试官就问“你有算过BERT上线比以前模型慢多少吗线上是怎么优化的”我当时因为只做了离线实验回答得有些含糊。复盘后我明白简历里每一句话都可能暴露出你的项目到底做到了哪一层做过的和“了解过的”在面试官追问下很快就露馅。建议大家在投递前把简历上的每个项目都按“技术方案-结果-暴露的问题-如果重做会怎么改”四个维度写一遍底稿面试时就能从容不少。6.2 知识迁移搜索和对话的交叉点往往是加分区域我在面试后期发现一个有意思的现象大搜和度秘虽然考察重点不同但两者的交叉部分越来越多。搜索里的query理解本质上就是一个NLU任务对话式搜索、AI智能助手本质上又是搜索和对话的结合。面试官在你的回答里听到你能把两个领域的知识打通通常会是加分项。比如在度秘二面我提到“多轮对话的槽位追踪”顺带聊了一句“这跟搜索里的查询改写有相似之处都是为了理解用户当前真正想要什么”面试官就多问了些搜索改写的方法。在大搜三面也提到“语义向量召回”时我补充说“这种向量化的思路在对话检索里也常见”面试官点了点头。当然这里要注意别讲得太刻意自然地带一句“这个思路我在另一个项目里也用过”就好。最后再分享一个实用的小技巧准备面试时把自己当成面试官给你的目标岗位设计一套“完美的面试问题”然后自己试着用最简洁的方式回答一遍。这套问题最好包括这个岗位解决什么业务问题核心技术链路是什么当前的瓶颈可能在哪里如果你入职了你最有信心促成的改进是什么我当时就是用这个方法快速构建了对两个方向的结构化认知投递后心里踏实很多。希望这篇面经对你的百度和度秘之旅有帮助也祝你能把面试当成一次高质量的同行交流享受这个过程。