百度 前端实习 二面

攒人品中，祝大家都能拿到满意的Offer！1*介绍下你最熟悉的项目和你的贡献2*为什么用bert算语义相似度不好3*你用过ernie吗4*双塔模型和交互模型的优劣5*qlora比lora改进了什么6*int8量化后推理速度一定比fp16快吗？7*了解哪些norm方法，适用什么场景8*了解rmsnorm吗，和ln有什么区别9*让模型学领域知识用继续预训练还是微调10*手撕：mha

1. 如果让你从 0 到 1 设计一个企业级 Agent 平台，你会怎么划分 Planner、Memory、Tool、Knowledge、Runtime、Evaluation 这几个模块？边界怎么定？我一般不会按“大模型功能”来拆，而是按“责任是否稳定”来拆。Planner 只负责决定下一步做什么，不负责真正执行；Tool 只负责把外部能力标准化，不参与推理；Knowledge 负责把文档、结构化数据、权限和索引组织成可检索资产；Memory 只存跨步、跨轮、跨会话还需要被引用的信息；Runtime 负责状态推进、超时、重试、回放和观测；Evaluation 则独立出来，不跟在线链路耦合，因为...

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

拷打了实习的自动化测试还有完整测试的过程linux命令知道哪些堆和栈的区别sql的topN问题mysql的索引的数据结构口述算法题：数组去重嵌套查询和连表查询哪个的效率更高？还有一些不太记得，下周二面