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

在牛客上投简历，被20人小厂给拒了，简历都没过筛😭😭😭。大佬们，求求给一些简历优化建议，推荐再塞个 ai吗(之前有做过很简单的rag)？还有就是我们教研室有一个项目，但是他是主要核心在spark，flink，模型，后端都是统计，增删改查之类的。大佬们，这个推荐我写吗？

Timeline：3.23 一面3.25 二面3.31 三面4.01 HR面4.08 电话oc，转录用评估4.09 leader加微信4.10 offer4.01-4.08这段时间挺煎熬的，看网上都两三天就转录用评估了，一度以为自己横向挂了。虽然这很难，但建议牛u们多向前看，已经面过的是我们改变不了的，不必纠结，保持好心态，继续准备下一场！

第一次真正感受到“技术判断”这四个字，不是在写完代码的时候，而是在一次方案评审前。需求看起来并不复杂，业务要上线一个新能力，时间不算宽裕，但链路很长，涉及多个模块联动。导师把文档丢过来，只说了一句：先别急着写，先把可能出问题的地方找出来。 我最开始也和很多实习生一样，下意识会先看接口、看表结构、看怎么把功能做出来。但越往下梳理，越发现这不是一个“把需求实现”就结束的任务。高并发场景下，任何一个看起来正常的调用路径，都可能在流量起来之后变成瓶颈；任何一个默认重试、超时设置、依赖堆叠，都可能把局部问题放大成全链路抖动。 于是我先没动代码，反而花时间把调用链、异常路径和兜底逻辑一条条画清楚。哪些请求...