秋招面经-百度NLP算法一面

攒攒人品！有面试过同岗的朋友欢迎评论区交流1*你项目用了rag，讲一下整个rag流程2*介绍一下常见的文本分块方法3*如何对齐查询和文档的语义空间4*详细介绍下对比学习和infonce loss5*温度系数大或者小有什么影响6*为什么现在的大模型都是decoder only结构7*那bert能做生成任务吗？什么场景下可以做8*有哪些peft方法，有什么区别9*进行sft操作的时候基座模型选用chat还是base10*你用的什么框架sft？11*手撕：反转链表

继续来分享下之前的面经~攒人品中1项目拷打2说下你这个rag的流程3如何体现你这个结果好坏的4有遇到什么困难嘛，你这个切分的chunk总数是多少5说下上下文如何保持的6滑动窗口大小怎么权衡的设置为多少7假如遇到模型在回答过程中不断偏离回答中心点怎么解决8实习时候做的ai助手怎么做的9假如要实现知识库动态更新怎么做10你是如何量化检索结果好坏的11说下你理解的召回率和准确率12你测试时候的query怎么设置的，分为哪几13了解mcp和skills嘛14对ai的前沿知识了解的多嘛15es的一些底层架构有了解吗16你对ai的发展怎么看17算法:反转链表

只记录总结了一些没答好的推荐系统用例设计：基础的功能交互：图片封面的尺寸，关键词的截取，后台的一些用户点击，停留时长以及收藏等行为是否正常上报，还有负反馈机制，就是说用户点击“不感兴趣”后是否当前列表会立即移除该内容，最后就是推荐结果和详情的一致性，进入的详情页要和推荐位显示的内容一致算法效果的测试：比如说相关性：是否与用户的搜索内容是强相关的，多样性：推荐的内容对应的tag是否是同一类目，然后还有实时更新：用户在一个地方停流了很久是否后台会出现该信息，然后是推荐列表是否包含一定的低频上线内容特殊场景的测试：用户没有历史行为的反应，没有商品的反应，极端搜索的处理，出来的内容是否符合规定数据和性能的测试：接口的性能，容灾的一个降级，离线和线上的一个对齐接口过慢：首先会去看监控，观察CPU和内存还有网络IO的一些情况，确认是否是硬件资源的瓶颈，接着会去查询慢查询日志，看看数据库的性能能否优化，比如说可以添加索引啊，还有一些sql语句不合理的情况可以处理一下，比如一些嵌套查询可以优化成联表查询，对于一些数据量过大的表可以进行一些分库分表的操作。业务逻辑中可以采用异步的流程，可以看看是否发生了FullGC,以及是否有一些递归导致时间复杂度过高。最后是网络，可以看看Redis是否变慢，队列是否积压，或者请求是否过多，可以适当做一些限流策略面对偶现的bug:面对偶现的bug,需要去差全链路的日志，确认当前的用户环境以及查看输入的参数和环境的快照等等，第二步是尝试利用压力测试去强行复现，找到它偶现的一个规律。算法：最长公共前缀（leetcode 14）ac

继续来分享下之前的面经~欢迎友好讨论，信息共享1讨论项目2什么是GAE3解释deepseek的MLA，分析可能有什么缺点4介绍deepseekV3.2的闪电索引器和可能的缺点5介绍MHC残差连接6什么是多头注意力7口述两个算法题，说出求根号的多重方法（牛顿，梯度下降，二分），二分法求到小数点后k位精度算法复杂度8一个哈希表题目，不是力扣