type
Post
status
Published
date
Oct 4, 2026
slug
seen-and-belive
summary
我们招一个有经验的人进来，通常默认他的价值是"做过"：他知道方案，知道坑在哪里，所以能更快把事情做出来。
但仔细想会发现一个问题。换了公司，infra 不一样，数据不一样，业务约束和组织形态也不一样，他以前的实现细节可能 80% 都没法复用。他不可能在新环境里照搬旧方案。
那他凭什么还是能做出来？我的答案是：他未必知道路径，但他见过终点，知道这件事是能做出来的。他见过，所以他相信。
人和人的差距，很多时候不是能力，而是看见和相信。一个人没办法做出他不相信的东西，再强的人也不行。
tags
思考
category
心情随笔
icon
password
priority
3
我们招一个有经验的人进来，通常默认他的价值是"做过"：他知道方案，知道坑在哪里，所以能更快把事情做出来。
但仔细想会发现一个问题。换了公司，infra 不一样，数据不一样，业务约束和组织形态也不一样，他以前的实现细节可能 80% 都没法复用。他不可能在新环境里照搬旧方案。
那他凭什么还是能做出来？我的答案是：他未必知道路径，但他见过终点，知道这件事是能做出来的。他见过，所以他相信。
人和人的差距，很多时候不是能力，而是看见和相信。一个人没办法做出他不相信的东西，再强的人也不行。
见过而相信，相信才能做成
我们讨论过很多次：同样很强的人，差距到底在哪？排除了基本素质外，还有什么界定性的因素。
几年前，到新的工作岗位之后，我发现了很多过去有很大收益但目前还是空白的工作。
笛卡尔积特征。笛卡尔积的想法很朴素：把两个特征交叉成一个新特征，让模型直接记住某种组合的偏好。当时是在初期就获得了巨大的AUC lift，但是跑到后面慢慢转平，甚至转负。把做的同事把经验 share 给了另一个场景，它看到后来 AUC 平就放弃了。我是不信这个邪，解决了一系列问题后，上线看到了巨大的 lift。
一个很强的人接到这个任务，会很认真地做。第一版没涨，他会调；调完还没涨，他会换一种组合方式；再不涨，他会开始分析，然后得出一个听起来非常合理的结论：模型已经能学到这些交叉了，笛卡尔积在这里是冗余的。这个结论有数据、有分析，很难反驳。
回头看，他其实只差一步。见过笛卡尔积做成的人，面对同样的数据，读出来的是另一层意思：不是没用，是还没做对。他会把每一个问题都当成实现问题，一个个去解，直到它出效果。
阿里召回是 I2I 起家的，双塔是后来才做起来的。在阿里，I2I 是地基，所有人都默认它有效，要讨论的只是怎么做得更好。
字节走的是另一条路。很早就是 FM，以向量召回为基础，I2I 在这里一直很难出效果。一个人在字节做 I2I，身边的一切都在告诉他：向量召回才是主路，I2I 做不出来很正常。每一次没有收益，都在印证这个判断。
我当时指导一个人做I2I。当时他没有分配足够大的精力做这个事情，因为他不够相信这么多人没弄出来，就轮到他一个校招生搞出来？可这件事其实不难，他实际按我说的做很快能搞定，但是他拖的太久，最后我自己动手跑了任务，后来顺利 launch 了。
两个例子里，核心问题都不是能力不够。真正的差别是没见过，所以不相信；不相信，就没办法有效地达成。
相信的人遇到困难，会怀疑自己的方法和实现：问题建模的方式不对，数据有问题，训练方法没调好，工程有 bug，或者 scaling 还没到。不相信的人遇到困难，会怀疑方向本身，然后换一个方向。没见过的人连续失败三次，就开始怀疑方向是不是不成立；见过的人连续失败十次，想的往往还是"一定是我哪里还没做对"。前面两个例子，都是在这个分岔口停下来的。
这背后有两层。一层是先验：他相信方向成立的概率更高。另一层更隐蔽：他知道方向正确但还没做对的时候，前期连续失败本来就是大概率事件，所以每次失败对方向的证伪力度很弱。他不只是更乐观，而是更会读证据。
所以两个人表面上在解决同一个技术问题，实际上 search horizon 完全不同。前者搜索几步就退出，后者可以在同一个方向里搜索几十步、几百步。
可以把它写成一条链：
看见 → 相信 → 更长时间地留在正确方向上 → 穿过失败区间 → 做出来
另一个例子，早期做多兴趣、多向量召回时，负责的同学在用类目做 trigger 做多兴趣。我让他去调研 MIND，这件事我自己也没做过，只是见过。他的判断是 MIND 是他方法的子集，而且其他组做 MIND 效果也一般，没必要再试。
我给他讲了一个故事：阿里内部复现 MIND 一开始也没有效果，请作者过去调了一会儿就有效了。他于是重新审视 paper 和字节内的实现，发现了一个惊人的事实：代码实现错了。因为第一个版本就是错的，内部普遍流传的 MIND 在各个业务上都是错的。他实现了正确的版本并做了改进，取得了巨大的收益。
这件事我没什么经验，但我见过，所以相信。那个故事没有告诉他任何方法，只改变了他对失败的归因：从"方法不行"变成了"可能是实现有问题"。
曼哈顿计划之后有个说法：原子弹最大的秘密，是它能被造出来。社招的人带来的经验，很大一部分就是这种存在性证明。我把它叫作关于世界可达性的经验，而不只是解法层面的经验：
- 见过某个规模能做到，某种架构最终可以收敛；
- 知道某些中间阶段的糟糕结果，不意味着路线错了；
- 知道什么时候该怀疑实现，什么时候才该怀疑假设本身。
先相信，再看见
只有一小部分人能把这条链反过来走：先相信，再看见。OneTrans 是我见过最典型的例子。
推荐排序模型过去一直走两条独立的路：一条是用户行为序列建模，一条是特征交叉或主干网络。序列先被编码成向量，再送进特征交叉，中间是一个向量压缩的瓶颈。OneTrans 明确指出了这种 encode-then-interaction 的割裂，并用一个统一的 Transformer 同时做序列建模和特征交叉，再一版一版地用 launch 证明它的价值。
当时最坑的是因为公司的训练框架是在 TF 上魔改的，标准的组件没法用，之前有一个流传的 Transformer 代码实现，很多人用了它来做序列处理。实际它的 LayerNorm 加错了位置，在层数少的时候它问题不大，一旦层数涨上去效果就大打折扣。
除了了这些，还有优化器的匹配问题，Scaling Invariance问题，Attention 探索问题。
在它做成之前，推荐里没有人见过这件事，没有现成的路，也没有人能证明它一定走得通。大多数人是因为看见所以相信，少数人能因为相信而看见。 这种能力更稀缺：在没有任何存在性证明的时候，依然把失败归因到实现，而不是方向。
先相信之所以难，是因为它要对抗的往往不只是技术上的不确定。很多成功的范式，最后都会长成组织架构：精排里有序列组、特征交叉组，整条链路上有召回组、粗排组、精排组。它们最初只是某个阶段最有效的问题拆解方式，做成了，就固化下来，反过来让人以为问题本来就该这样拆。
OneTrans 不是在一个模块里找到更好的解，而是在质疑模块边界本身是不是应该存在。 到 OneTrans-V2，把召回、粗排、精排放进一个统一的建模框架，技术障碍反而未必最难。最难的是去相信，一套被成功反复证明过的拆法，可以被打破。
一个突破最重要的外溢效应，未必是论文里的具体技术。OneTrans 出来以前，很多人面对特征体系、序列建模、不同任务的统一，第一反应可能是：这些东西天然就是不同模块，统一大概会损失效果，或者工程上不可控。一旦有人真的把统一架构做到足够好的规模，行业得到的不只是一份模型架构的配方，而是：原来这个设计空间是存在的。
之后，2026 年腾讯广告算法大赛和 KDD 联办，直接把序列建模与特征交互的统一拿来当赛题。企业内部的人也开始敢于重新审视原来已经固化的模块边界。这时候论文真正改变的已经不是模型架构，而是人的先验。
证明了一次之后，后面其他团队要解决的不再是"这个东西到底能不能成立"，而只是"我们怎么把它做出来"。两个问题只差一句话，对应的却是完全不同的研发效率。
经验耗尽之后，负责相信
到后来，经验是会耗尽的。我的经验早在几年前就用完了。走到前沿之后，这是常态而不是例外：真正在做新东西的人，几乎都处在没见过的状态里，还能输出的只剩下判断和相信。之后我做的事情，很多时候是负责相信。
负责相信是一个真实而沉重的职责。团队可以把失败归因到实现上，是因为有人替他们扛住了方向的不确定性。这份不确定性不会消失，只是集中到了一个人身上。
每一个 OKR 都是跟我核对过的，每一块 GPU 用在哪也是我来分配的，在不确定方向的每一份投入都是一份深重的焦虑。
没有经验托底的相信，最难的是和固执区分开。经验在的时候，相信是被过去校准过的；经验耗尽之后，只能靠别的东西校准：跨领域的类比，第一性原理的推演，过程中那些微弱但方向一致的信号。也要预先想好什么样的证据会让我放弃，这样相信才是一种判断，而不是一种姿态。
存在性证明这么值钱，所以我会在一些很小的场景里，让大家尝试最激进的方案，为的是用最小的成本去印证“相信”。小场景成了，更多的人就看见了；看见了，就会相信。“相信”这样一点点传递下去，最终才能达成全局性的目标。
比经验和能力更重要的，是看见和相信。走到后来，是能不能相信那些还没人见过的东西。