一个做了六年推荐的朋友去了股份行的金融科技子公司。半年后聊天，他说现在每天想的问题变了：以前是怎么把点击率再提零点几个点，现在是怎么降低那批“本来能还款却被拒掉”的人的比例。
他说这句话的时候没有抱怨的意思，更像在陈述一个事实。但我听得出来，这件事对他的吸引力，和当年做推荐时不太一样。
目标函数换了
互联网算法优化的是点击、停留、转化、时长。银行算法优化的是坏账、误杀、合规、稳定性。两边都在做机器学习，但评价一个模型好不好的标准，几乎不重叠。
这不是“低配”。把银行叫成互联网的低配版，是拿一套目标函数去衡量另一套，结论必然是错的。银行的约束更多，而且很多约束不能被打折：模型拒掉一个客户，要有理由；理由要能被业务、风控、审计和监管看懂；出了问题要能追溯。
所以刚从互联网过去的人，常有两种感受。
一种是“技术扶贫”。数据标准还在补，特征平台刚起步，模型监控靠人盯，很多在互联网早就标准化的事情要重新做一遍。短时间内做不出漂亮的模型，因为地基还没铺完。
另一种是“戴着镣铐跳舞”。一次小流量实验在互联网可以当天回滚，在银行可能要先过数据申请、合规评估、模型评审、灰度验证、生产变更。每一步都有它的道理，但加起来就是慢。
这两种感受都是真的。不过它们描述的其实是评价体系错位，不是技术贬值。
还有一层误解是岗位本身。很多人听到“金融算法”就想到量化，实际上银行里绝大多数算法岗不碰交易。信贷审批、反欺诈、客户分层、营销响应、金融文本解析、合规审查，这些才是主战场。真正做高频和策略的，更多在券商、基金、资管，门槛和知识结构又是另一套。
银行的目标函数里还有一层是“不被注意到的正确”。互联网喜欢讲增长故事，银行更在意不出事。一个模型把坏账率压下去，但如果它拒绝了一批本该通过的客户，这批人不会出现在增长报表里，只会出现在客诉和监管投诉里。所以做银行算法，很多时候是在优化一个看不见的损失，而不是创造一个看得见的增量。
这也解释了为什么银行对“新方法”的态度更慢。不是不知道 Transformer，也不是没人试过，而是新方法要先进评审、再进灰度、再经过几个月的表现期，才能证明它不比旧方法差。这个周期对做惯了快速迭代的人是一种折磨，但它也筛掉了很多经不起时间检验的东西。
监管是另一个常被低估的变量。模型上线不是终点，监管检查会看变量清单、拒绝理由、样本偏差、模型变更记录。很多在互联网属于“工程细节”的东西，在这里是合规材料。写文档的时间可能和写模型的时间一样多，这一点在转岗之前最好想清楚。
岗位名字也很容易误导。数据挖掘、智能风控、量化分析、模型开发，在不同银行可能对应完全不同的工作。有的偏策略，有的偏平台，有的其实是取数和报表。看 JD 的时候，我会直接找三个词：样本、特征、上线。三个都出现，才说明这个岗位真的在建模。
还有一类岗位在增长：监管科技和合规相关的模型。反洗钱、交易监测、制裁名单匹配，这些场景对召回和解释的要求都很高，技术更新反而慢。喜欢稳定、愿意深挖规则的人，可能比追新模型的人更适合。
技术在，只是被约束包住
银行里的算法岗位比外界想的宽。风控评分、反欺诈、反洗钱、客户分层、营销响应、智能客服、研报和合同解析、知识库问答，都在招人。
技术栈也有重叠：Python、SQL、Spark、特征工程、树模型、深度学习、图算法，都要用。区别在使用重心。
风控和授信场景里，逻辑回归、评分卡、XGBoost 这类模型仍然是主力。不是因为不会深度模型，是因为要回答“为什么拒绝这个人”“哪个变量让风险升高”“这个模型对某类客群有没有异常偏差”。可解释、可监控、可复核，在这个场景里比 AUC 多零点零一重要。
深度学习更多出现在文本、客服、票据、研报这些非结构化场景。那边对透明度的要求没有那么硬，对效果和工程吞吐的要求更高。
真正需要重新学的不是框架，是口径。逾期怎么定义，观察期和表现期怎么切，坏账率按哪个分母算，通过率变化会不会影响样本分布。这些东西写不进简历，但决定了模型能不能用。
一个反欺诈模型，压力也不只是召回。拦得多，误杀就多，客诉和人工复核成本跟着涨；拦得少，资金损失上来。这个平衡没有通用解，只能和业务一起定。它和推荐系统里“多推一条少推一条”的感觉完全不同。
从互联网迁过去，比较顺的落点是反欺诈、运营增长、金融文本。这三类和推荐、广告、风控建模的工作方式接近：都要做特征、跑模型、上线、监控。风控和投研更偏业务科学，得先懂口径；量化则是另一条路，别混在一起准备。
长期看，银行里的成长路径大概三条。一条是往深里走，做风控、反欺诈、图模型、文本，成为某个场景里说得上话的人。一条是往管理走，带数据、模型、工程和业务的协同。还有一条更少见，变成业务和模型之间的翻译者，既看得懂特征和评估，也看得懂资产质量和风险政策。越往后，单点算法能力越不值钱，把问题拆清楚、把结果讲明白的能力越值钱。
面试也会问得不一样。互联网面试问怎么把指标做上去，银行面试更常问怎么保证它不掉下来：坏样本怎么定义，时间窗怎么切，模型上线后怎么监控，为什么这个变量可以用、那个不能用。答得好不好，不取决于模型多新，取决于有没有在真实链路上待过。
流程一般是技术面、业务面、HR 面。技术面不一定难，业务面反而更分人，因为它会顺着简历里的项目追口径。HR 面看稳定性和动机，答“想换个稳定的环境”通常不如答“想在一个更长的周期里做风险类问题”。前者听起来像退，后者听起来像选。
简历也一样。把“点击率预测”改成“营销响应预测”，把“异常账号识别”改成“交易反欺诈”，不是换词，是换叙事：从增长语言换成风险语言。做过什么不是重点，能迁移什么才是。
学历和年限是另一道现实门槛。社招里硕士更常见，三年以上经验也更稳，因为这些岗位默认候选人能独立做需求澄清、样本定义、特征、迭代和复盘。互联网背景不是劣势，反作弊、用户画像、增长建模都能迁移，但要在简历里换成银行听得懂的指标：识别率、误杀率、审批效率、坏账变化。
如果没做过金融，也不必硬编。准备一个完整的风控或反欺诈案例，把标签定义、时间窗、特征、模型、评估、上线监控走一遍，比背十个算法名有用。面试官通常能听出来哪些是真做过的，哪些只是看过。
从推荐转风控，最难迁移的不是模型，是因果。推荐可以靠相关性吃饭，风控不行。一个变量和违约相关，不代表动它就能降低违约。比如某个渠道的客户坏账高，是因为渠道本身差，还是因为渠道吸引了某类人，处理方式完全不同。银行里很多讨论最后都会落到“这个变量能不能干预”，这是推荐背景的人最容易忽略的一层。
模型评审也是一道具体的门槛。评审会上，业务会问这个模型怎么用，风控会问漏判的代价，合规会问变量是否可解释，技术会问上线之后怎么监控。一个人如果只会讲 AUC 和特征重要性，很难把这些问题的答案串起来。我见过技术很强的人卡在这里，不是模型不好，是讲不清它在流程里的位置。
还有一个迁移优势常被低估：互联网出身的人通常更会做实验。银行很多环节没有条件做随机对照，但可以做时间上的前后对比、同客群的匹配对比、逐步放量。能把一个不完美的实验设计讲清楚，比硬套互联网的 A/B 测试更有用。
工程能力在银行反而更容易显出差距。很多团队的数据链路还是批处理，特征靠存储过程，模型靠脚本调度。一个会写干净管道、会做版本管理、会把训练和推理拆开的人，能很快改善团队的交付方式。这种改善不一定是算法上的突破，但它的可见度很高，也更容易被记住。
面试最后的反问环节，我会问团队最近一次模型回滚是因为什么。这个问题比“团队氛围怎么样”有用得多，因为它能听出团队有没有真实的监控、有没有复盘习惯，以及负责人愿不愿意讲自己的问题。
薪资要拆开看
银行算法岗的薪资不能只看“银行”两个字。机构类型、城市、部门，三个变量就能拉开很大差距。总行科技、金融科技子公司、信用卡中心、分行科技、消费金融公司，是五种不同的定价逻辑。
还有一个容易忽略的差别是归属。总行科技、子公司、外包驻场，可能做的是同一件事，但权限、数据范围、晋升路径完全不同。同一个岗位名字，背后可能是核心团队，也可能是支持岗。这个信息在 JD 里通常看不出来，得在面试里问。
结构也不一样。互联网的总包常把股票、签字费、绩效奖金算进去，弹性大，波动也大。银行更强调固定工资、年终、补贴和福利，看起来稳，但年终和绩效往往受部门预算和个人评级影响，不是每月稳定到账。
谈的时候我会把固定和浮动分开问：年终奖的发放区间是多少，绩效系数怎么分布，试用期打几折，补贴算不算进总包。问得越细，对方越不容易用一个模糊的“三十多万”糊过去。
所以比较的时候，我建议拆成四块：固定现金、浮动奖金、长期权益、工作强度。只比月薪会误判，只比总包也会误判，因为总包里的构成决定了它的确定性。
薪资之外，银行的隐性福利也要算。补充公积金、企业年金、补充医疗、食堂、班车、低息贷款，这些项目的价值因人而异。对准备买房的人，公积金和低息贷款的权重很高；对单身、通勤远的人，食堂和班车可能更重要。把这些都折成现金很麻烦，但只比月薪会漏掉一大块。
还有一个现实是，银行的薪资增长更依赖职级晋升，而不是每年普调。互联网可以通过跳槽快速抬升，银行内部的晋升周期更长，名额也更受组织架构限制。所以进去之前要问清楚：这个岗位的上一级是什么，平均多久能到，最近两年有没有人真的升上去。没有答案的话，稳定性可能只是稳定地不涨。
稳定性也不是免费的。它对应的代价是上限、速度和选择权。一个人在银行待了五年，收入可能很稳，但市场对他的定价也会慢慢固定在一个范围内。这不是坏事，只是要提前接受。最怕的是一边享受稳定，一边抱怨没有爆发，这两种东西本来就很难同时要。
比较 offer 的时候，我会做一个很笨的动作：把两家公司的薪酬、通勤、加班、晋升、业务前景分别写下来，然后给每一项打一个权重。权重不是拍脑袋，是问自己未来两年最在意什么。写完之后，答案通常很清楚。这个方法不能消除不确定性，但能防止我被某一个数字带着走。
还有一点：银行的口头 offer 到书面 offer 之间，可能隔很久。审批链条长，预算可能变，编制可能冻结。所以在拿到书面文件之前，我不会拒掉其他机会。这不是不信任，是流程本身的不确定性。
有一个说法我觉得比较准确：互联网算法的上限更高，银行算法的曲线更稳。
上限高意味着用波动去换。业务调整、组织变动、绩效周期，任何一个都可能让收入掉下来。曲线稳意味着放弃了那部分弹性，换现金流可预期和行业周期对冲。
这笔交换值不值，取决于现在的基数。如果已经在核心业务线、收入还在上升期，去银行大概率是降速；如果所在业务边缘化、绩效不确定、长期在补坑，银行的稳定现金流可能反而是改善。
城市也会改变结论。总部集中的城市岗位密度高，选择多，但生活成本也高；研发中心分布更广的城市，上限低一些，稳定性和生活质量是另一套算法。这个部分没有统一答案，只能按自己的情况算。
还有一种情况容易被忽略：银行内部不同岗位的差距，比银行和互联网之间的差距更大。同样是算法岗，做核心风控的和做报表支持的，能接触的数据、能上线的东西、两年后能讲的故事，完全不是一回事。所以问“银行值不值”这个问题本身就太粗，应该问的是“这个部门、这个业务、这个汇报线值不值”。
我不建议把它当退路
如果动机是“互联网卷不动了”，银行大概率会让人失望。
流程摩擦也是一种消耗，而且它的反馈比加班更慢。加班至少知道自己累，流程卡住时甚至不知道该怪谁。抱着逃离的心态进去，第一年通常最难熬。
我觉得更适合的情况是：做过风控、反欺诈、增长建模，或者擅长特征工程和模型解释，并且愿意花时间学业务口径。这类人的迁移成本低，过去之后能比较快找到位置。
不太适合的情况也很清楚：追技术密度、追快速晋升、收入高度依赖股票期权、对流程天然抵触。这四种人进去之后，摩擦会大于收获。
还有一个现实：银行的晋升更依赖长期可信的交付，而不是一个爆款项目。跨部门做出来的结果，个人贡献很难显性化。这不是坏事，但它确实会改变一个人评估自己成长的方式。
我还想补一个不太浪漫的判断：银行内部的技术分化正在变大。总行和子公司里，真正做模型、做平台、做数据的团队，和做报表、做支持、做运维的团队，日常内容差得很远。前者能积累可迁移的能力，后者更容易被流程同化。同一个“金融科技”标签下面，可能是两种职业。
所以面试时我更在意三件事：团队有没有自己的数据权限，模型有没有真实的上线场景，负责人是不是懂技术。三个都有，哪怕薪资低一点，也值得考虑；三个都没有，稳定性再好，两年后可能只是多了一份很长的流程经验。这三个问题也适用于互联网，只是在银行里，答案更容易被流程和层级掩盖，需要多问一层。
我朋友那批人里，也有人去了之后不适应。最常见的原因不是技术，是节奏。以前一周能上线的东西，现在要等一个月；以前可以自己决定实验，现在要层层审批。有的人能接受这种交换，有的人不能。能不能接受，和能力强不强没关系，和性格与阶段有关。
我也见过反向的例子。有人在银行待了三年，把风控链路和数据口径摸透，再跳回互联网做金融业务，反而成了稀缺的人。路径不是单向的，关键是这几年有没有积累可迁移的东西。
有一个判断标准我觉得比薪资更准：愿不愿意把 KPI 从“模型指标提升多少”改成“业务风险或经营结果改善多少”。愿意，这算一次能力扩展；不愿意，那些审批和解释就会变成纯粹的成本。
我也不觉得银行是终点。它更像一个把技术能力和业务理解绑在一起的训练场。有人在这里找到了长期做风险的兴趣，有人待了两年发现自己还是喜欢高频反馈，又回去了。两种都正常。重要的是知道自己为什么来，以及什么时候该走。
如果让我给自己列三个决策问题，大概是：这个岗位的数据我能不能碰到，模型能不能上线，两年后我能不能讲出一个完整的金融场景故事。三个里有两个是否定的，那薪资再稳也不值得。
我朋友现在偶尔还会跟我聊推荐系统的新东西，语气像在看一个自己曾经住过的城市。他说不后悔，但也没打算回去。
我自己还没走到那一步。所以这篇写的都是观察，不是结论。这件事的答案大概取决于未来两年想要什么，而这个答案，我每年都在改，可能还会改得更频繁。
评论