家里蹲一年找工作Day28

我还记得24年研究RAG的时候，压根没有想到，后来技术的发展，大模型的上下文能长成现在这个样，而且随着技术进一步发展，其实Memory的加入确实能让Agent的上下文能力变得很强，但真当面试时如果被问到这个问题，你得清楚，其实是一个非常典型的面试陷阱。（我准备的答案在文末）为什么这么说？如果你跟风回答“会”，面试官很容易判断你缺乏工程落地经验，也没有真正考虑过成本问题。但如果你回答“不会”，面试官往往又会继续追问：既然不会，那现在模型拼命把上下文窗口做到几百万Token，难道方向错了吗？RAG还有存在的必要吗？你会觉得，这道题似乎怎么回答都不对：说“会”，显得外行；说“不会”，又像是在否定技术...

秋招0offer，估计简历有问题   

学java第六天，效率太慢了把游戏删了我再玩是sb

1. 介绍一下你做过的最有挑战性的项目，遇到了什么技术难点，是如何解决的？我之前参与过一个电商订单系统的开发。最大的挑战是在促销活动期间，订单量暴增导致系统响应变慢，甚至出现超卖问题。技术难点主要有三个：高并发下的库存扣减：最初使用的是先查询库存再更新的方式，存在并发问题。我们改用了乐观锁方案，在更新时加上版本号判断，同时在数据库层面使用UPDATE ... WHERE stock > 0的原子操作，确保不会超卖。数据库压力过大：引入了Redis缓存热点商品库存，使用Lua脚本保证扣减的原子性。同时对订单表做了分库分表，按用户ID哈希分散到不同的数据库实例。消息堆积问题：订单创建后需要发...