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

有没有大佬帮忙看看我的简历，我朋友说原本挺有机会进大厂的，现在就甘于在成都11,12k的公司里面，浪费我的竞赛经历了。但我也没招，我投了那么多大厂，几乎都过不了初筛。有朋友说我写的太多了，没有重点，有没有大佬给点建议，我真的还是挺想进大厂的。

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花雪花算法（Snowflake）时钟回拨的核心成因是系统时间倒退（NTP校准、虚拟机恢复、手动调时等），导致新ID时间戳小于历史时间戳，引发ID重复。主流解决方案按从基础到终极分层，兼顾可用性与唯一性，核心策略如下：一、基础方案：等待时钟追平（最常用、生产首选）核心原理检测到回拨时，主动休眠等待系统时间追上历史时间戳，再继续生成ID，零风险保证唯一。实现逻辑记录lastTimestamp（上次生成ID的时间戳）生成新ID时，对比currentTimestamp与lastTime...