百度提前批一面（百度云 8.25）

1. 你之前接触过的中间件里，挑一个最熟的讲讲它的核心设计，重点说为什么要这样设计如果讲消息队列，比较容易拉开差距的不是背概念，而是把吞吐、可靠性、顺序性和扩展性之间的取舍讲清楚。比如一套高吞吐 MQ 通常会采用顺序写磁盘、分区模型、批量发送、批量拉取和零拷贝来提升吞吐，但这么设计以后，消费顺序只能在单分区内严格保证，跨分区顺序就必须交给业务自己兜底。再比如可靠性不是简单开个副本就完事了，生产端要考虑重试和幂等，Broker 要考虑刷盘和副本同步策略，消费端还要考虑重复消费和位点提交时机。真正难的是理解这些机制不是孤立存在的，而是围绕吞吐、延迟、可恢复性一起做平衡。2. 软件工程里的设计原则你...

总时长35分钟，无手撕，感觉遇到KPI面了，唉35分钟一直在问实习，八股就问了下面的1.redis与数据库的缓存一致性2.redis的zset数据结构3.redis的两个持久化机制4.分布式cap理论5.什么时候ap，什么时候cp6.进程线程协程问怎么没手撕，说一面撕过了，业务是应用宝游戏商城，后面过了还有一面技术面，问面试表现，说挺顺的，可以再关注一下运维数据，然后问转go有难度嘛，就结束了

秋招没有大满败，最终收到节子的offer。

1. 自我介绍2. RAG 怎么优化，评估时你会看哪些指标RAG 的优化一般不能只盯着生成端，很多问题其实出在检索阶段。常见优化思路包括 query rewrite、chunk 切分策略调整、混合召回、重排序、上下文压缩和引用约束。比如文档切得太碎，召回会有信息断裂；切得太长，又容易把无关信息一起带进来，生成端会受污染。真正线上效果好的 RAG，通常不是“某个 embedding 更强”，而是检索、排序、上下文组织和回答约束配合得比较好。评估时我一般拆成两层。第一层看检索，比如 Recall@k、MRR、HitRate，看相关证据能不能被捞上来；第二层看生成，比如答案正确率、faithfuln...