校招 未知部门 / 后端开发 / 多轮

[面试日期] 2026-08-26 [面试时长] 未知
[学校背景] 北京理工大学 | 985 [学历背景] 本科
[发布人] 面试之星官方收录
<h2>分享|4年经验面百度智能客服,三轮技术面全过,薪资没谈拢</h2> <p>先交代背景:普通本科,Java后端,4年经验,上一家是某二线互联网公司,负责过智能客服系统的开发和优化。</p><p>百度智能客服业务是AI落地的重点方向,面试三轮技术面全过了,结果HR面薪资没谈拢,又重新投了另一个部门才OC。</p><p><strong>📌 第一阶段:一面差点挂(6月)</strong></p><p><strong>一面(60分钟)——差点挂</strong></p><p><strong>1️⃣ 项目深挖:你负责的智能客服系统,日请求量多少?QPS多少?怎么保证回答的准确率?</strong></p><p></p><p>💡 <strong>思路参考</strong>:4年经验的面试,面试官默认你负责过核心系统。日均请求100万,峰值QPS约300。智能客服涉及意图识别、知识库检索、大模型生成、答案校验四个核心链路。准确率靠三层保障——意图识别模型(准确率92%)、RAG检索(召回率85%)、答案校验(规则过滤+人工审核兜底)。重点说<strong>你作为负责人是怎么设计的,不是只参与了</strong>。</p><p><strong>2️⃣ 追问:“如果用户问了知识库没有的问题,系统怎么处理?”</strong></p><p></p><p>💡 <strong>思路参考</strong>:知识库未覆盖的问题走大模型生成(但需要做幻觉检测和事实校验)。同时记录未覆盖的问题到待补充知识库,运营人员定期审核补充。兜底方案是转人工客服。核心是<strong>用户体验优先+持续迭代</strong>。4年经验要能说出<strong>未覆盖问题的分类策略</strong>——按问题类型分优先级,高频问题优先补充。</p><p><strong>3️⃣ 追问:“如果大模型回答出现了幻觉,怎么发现和处理?”</strong></p><p></p><p>💡 <strong>思路参考</strong>:幻觉检测用三套方案——事实一致性校验(回答中的事实与检索到的文档对比)、忠实度检测(回答是否凭空捏造)、可验证性检测(关键信息能否溯源到源文档)。发现幻觉后走降级——返回“正在为您转接人工客服”的兜底话术,同时记录幻觉案例用于模型迭代。</p><p><strong>4️⃣ JVM调优:CMS GC的调优参数和适用场景</strong></p><p></p><p>💡 <strong>思路参考</strong>:CMS适合堆内存4-8GB、对停顿时间敏感的场景。核心参数:<code>-XX:+UseConcMarkSweepGC</code>、<code>-XX:CMSInitiatingOccupancyFraction=75</code>(触发CMS的堆占用阈值)、<code>-XX:+UseCMSInitiatingOccupancyOnly</code>(固定使用设定的阈值)。说一个真实调优案例:智能客服系统大促期间接口RT抖动,调低CMS触发阈值从75%到65%,提前触发GC减少停顿。</p><p><strong>5️⃣ 手撕:实现一个支持分布式限流的方案(令牌桶)</strong></p><p></p><p>💡 <strong>思路参考</strong>:用Redis + Lua脚本实现令牌桶——每个请求扣一个令牌,桶容量和速率通过参数配置,Lua脚本保证原子性。核心难点:<strong>为什么用Redis不用本地限流</strong>(多节点要共享限流状态、避免单节点流量不均导致限流失效)、<strong>令牌的补充策略</strong>(定时补充或每次请求时计算应补充的令牌数)。</p><p>一面面完感觉一般,项目答得还行,等了三天,过了。</p><p><strong>📌 第二阶段:二面三面全过了(7月)</strong></p><p><strong>二面(60分钟)——过了</strong></p><p><strong>1️⃣ 系统设计:设计一个支持百万级日活的智能客服系统</strong></p><p></p><p>💡 <strong>思路参考</strong>:分层架构——接入层(网关+鉴权+限流)、业务层(意图识别+知识库检索+大模型生成+答案校验)、数据层(向量数据库存知识库、Redis存会话状态、MySQL存日志和反馈)。核心难点:<strong>检索的实时性</strong>(向量检索要在100ms内完成,用HNSW索引)、<strong>大模型调用的成本控制</strong>(缓存高频问题答案、简单问题走规则引擎)。4年经验要能说出<strong>缓存策略的设计</strong>——高频问题缓存到Redis,TTL设置1天,定时刷新。</p><p><strong>2️⃣ 追问:“向量检索的召回率不高,怎么优化?”</strong></p><p></p><p>💡 <strong>思路参考</strong>:从三个维度优化——索引侧(分块策略优化,按语义完整性分块,重叠窗口)、检索侧(混合检索:稠密向量+稀疏关键词+重排序模型)、查询侧(Query改写+HyDE)。重点说出<strong>优化前后的数据对比</strong>——召回率从78%提升到85%。</p><p><strong>3️⃣ 线上大规模故障排查</strong></p><p></p><p>💡 <strong>思路参考</strong>:说一个真实的P0级事故。某次大模型API调用超时,导致智能客服大量返回超时错误。排查过程:看监控大盘确认故障范围→查大模型API调用日志(发现超时率从1%飙升到30%)→联系大模型服务方(发现对方在做模型升级)→紧急降级到规则引擎(返回预设答案)→恢复。事后复盘:没有做API调用的熔断和降级、没有备用的模型服务商。</p><p><strong>三面(交叉面,70分钟)——过了</strong></p><p><strong>1️⃣ 系统设计:设计一个AIGC内容审核系统</strong></p><p></p><p>💡 <strong>思路参考</strong>:用户生成内容→敏感词过滤(布隆过滤器+正则)→大模型安全检测(违规内容识别)→人工抽审核验。核心难点:<strong>实时性</strong>(审核要在1秒内完成,否则影响用户体验)、<strong>准确性</strong>(误杀率&lt;1%、漏杀率&lt;0.1%)、<strong>可解释性</strong>(审核结果要有明确的违规原因)。4年经验要能说出<strong>分层审核的策略</strong>——简单内容走规则引擎(毫秒级)、复杂内容走大模型检测(百毫秒级)、高风险内容走人工审核(秒级)。</p><p><strong>2️⃣ 追问:“如果审核系统挂了,怎么保证内容安全?”</strong></p><p></p><p>💡 <strong>思路参考</strong>:审核系统挂了走降级——先放行但标记为待审核(牺牲部分安全性保可用性),同时触发告警通知运维介入。事后对降级期间的内容进行补审。核心是<strong>可用性优先+事后补偿</strong>。</p><p><strong>HR面(30分钟)——挂了</strong></p><p>期望薪资报了30%涨幅,HR说“这个岗位预算有限,只能给到15%涨幅”。没谈拢,挂了。</p><p><strong>📌 第三阶段:重新投递,四面终于OC(8月)</strong></p><p>挂了之后重新投了另一个部门(AI平台方向),这次HR面先问薪资范围再报期望。最终OC。</p><p><strong>📌 声明</strong></p><blockquote><p><em>以上思路参考来自 </em><strong><code><em>&quot;面题鸭🦆&quot;</em></code></strong><em> 各岗位专属考题的考点方向</em></p></blockquote><p><strong>📝 复盘</strong></p><p>百度智能客服社招4年经验的面试,考的是三件事:</p><ol><li>能不能独立设计AI系统(智能客服、AIGC审核、向量检索)</li><li>线上出事了能不能扛住(大模型API故障、降级方案)</li><li>能不能讲清楚为什么(每个技术选型都有明确的理由和取舍)</li></ol><p><strong>🎯 后来怎么调整的?</strong></p><p>HR面挂了之后复盘发现,技术准备没问题,但HR面完全没策略,薪资谈判一上来就报期望涨幅,没给自己留余地。</p><p>后来在 <strong><code>&quot;面题鸭🦆&quot;</code></strong> 上刷了一遍智能客服方向的JD专属出题,系统设计、向量检索、大模型降级这些方向覆盖得很全。每面一家之前针对性刷一遍,面试时心里有底很多。</p><p></p><p></p><a>#我的求职进度条#</a><a>#聊聊Agent开发#</a><a>#这场面试拉爆了#</a><a>#掌握什么AI技能,会为你的求职大大加分#</a>
AI 推荐面试题