"这段代码逻辑没问题，可以合并。" 技术评审会上，几位senior工程师都点了点头。我盯着屏幕上的代码，手指在键盘上悬停了几秒。 "等等……"我在群里打字，"这里在高并发场景下，会不会有线程安全问题？" 会议室安静了两秒。 导师切回代码界面，放大了那段逻辑："说说你的想法。" 我深吸一口气："这个缓存更新操作，如果两个请求同时进来，可能会出现数据不一致。我看了下调用链路，这个接口在大促期间QPS会到5000+，建议加个分布式锁，或者改用CAS操作。" 导师看了我一眼，然后在代码上标注了几处：&q...

…… 标题党了，对不起各位牛爷爷了，请问各位简历有没有要优化的

润色了一下，这个简历还有救吗，春招还能上岸吗😭经历秋招洗礼，感觉运气>>实力

1、为什么引入父子索引，为什么引入 BM25，比例是怎样的，具体流程是什么，有没有 rerank父子索引主要是为了解决 切块后召回准，但是上下文不完整 的问题。如果文档直接按 300～500 token 切成小块做向量检索，确实更容易召回到具体答案，但很容易丢掉原文结构，比如标题、段落关系、表格上下文、前后约束条件。所以会把文档拆成两层：父块：保留完整语义单元，通常是 800～1500 token子块：用于召回，通常是 200～400 token检索时先搜子块，命中后回源到对应父块，再把父块内容喂给大模型。这样既保证召回精度，也保证上下文完整性。引入 BM25 是因为向量检索对语义相似比较敏感...