脉脉

爱摸鱼的技术负责人

07-03 · 神州

转行面大模型岗，被问项目难点张口就说向量召回准确率低，十个有八个直接被打低分。我是摸鱼CTO老汪，平时上班摸鱼写代码没少踩真坑，反倒当年从后端转大模型应用开发时，第一次面试就栽在这道题上，答得全是培训班模板话术，出来就知道凉了。很多转行的朋友答项目难点，上来就堆技术名词，把教程里的优化手段全背一遍，觉得说得越全越显厉害。站在面试官视角看恰恰相反：真实生产里没有全知全能的解决方案，说得越完美无缺，越像没碰过真实项目的速成选手。真正能拉分的难点回答，从来不是比谁的技术栈堆得多，是比谁的回答更有真实生产的权衡感。别只说技术难点，不说业务背景。很多人上来就讲Embedding效果差、召回不准，全程飘在技术层面。面试官听了只会觉得，你连这个难点为什么重要都讲不清，大概率是凑数编的。正确讲法是先绑死具体业务场景：我当时做企业内部知识库问答，法务岗查合同条款时，跨章节召回经常把附录的免责声明混进正文答案，用户投诉率超30%，这才倒逼我们去优化召回逻辑。别只说优化方案，不说取舍代价。不少人把换模型、加重排、细粒度切片全报一遍，显得问题被完美解决。真实项目里从来没有银弹，每个优化都有成本，全说没代价一听就是背的。可以这么讲：最开始想直接换更大的Embedding模型，结果推理延迟涨了40%，线上接口压测过不了，最后折中用了轻量重排模型，准确率提了18%，延迟只涨5%，是业务能接受的平衡。别只说成功结果，不说遗留问题。很多人结尾必说优化后准确率95%，问题彻底解决。生产环境没有一劳永逸的方案，这么说反而露怯。我自己面试时会主动补一句：到现在极端长文档的切片边界问题还是没彻底解决，只能靠规则兜底，后续打算试父子切片方案，还在排期。还有个最容易忽略的前置坑：别为了显深度，硬造自己没接触过的难点。判断标准很简单：说不出具体报错日志、具体数据指标、具体业务投诉的难点，全是虚的。面试官追问难点，本质不是考你技术有多牛，是看你有没有从头到尾跟过真实项目，有没有解决实际问题的思维。其实转行面大模型岗，大家怕的从来不是项目不够复杂，是怕自己的表达露怯。很多时候不是能力不行，只是没摸透面试官的判断逻辑。我整理了一些大模型面试高频题和生产级项目参考话术，可供参考。祝大家转岗顺利，都能拿到心仪的offer。