1、自我介绍2、讲一下你做过的一个最有代表性的项目3、RAG 里 chunk 怎么切，为什么这是个关键点chunk 切分会直接影响召回质量和最终回答质量。因为向量检索不是按整篇文档检，而是按切分后的片段检。如果切得太长，一个 chunk 里会混入很多无关信息，虽然语义覆盖大，但相似度不一定集中，模型拿到后也不容易抓住重点。如果切得太短，单个 chunk 虽然很纯，但上下文不完整，容易导致召回回来的内容缺少关键信息。实际做的时候一般会根据文档类型来定。像制度文档、说明文档，可以按标题、段落、语义边界切；如果是 FAQ 或问答对，本身就天然适合按条切。通常还会设置 overlap，避免一个关键信息...

恐怖如斯

28届985本，科班，一直走的是本科就业的路子，学习Go后端，曾经还因为周围人卷保研而自己早已踏上了“正确的道路”而沾沾自喜。现在大二下，工程和算法能力还可以，但保研基本无望，也不想考研。愈发觉得自己所谓“正确的道路”可能并不是多么明智，AI以惊人的速度进化，一年之后或者两年之后，后端还存在吗？大部分的工作是否都和AI算法之类的强相关呢，但这又是一个需要研究生以上学历、需要卷论文的方向，本科就业者基本碰不到。自己的本科学历会不会在后端工作一两年就被“降本增效”了，或者是到了大三大四根本找不到对口的工作了？抱歉，可能我有点想到哪说到哪了，我不知道自己是不是在杞人忧天，现在有点迷茫，希望各位已经进入业界的大佬能够给我指条明路，谢谢！

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