type
status
date
slug
summary
tags
category
icon
password
priority
从组织架构说起
我们先思考下，一个公司组织里，为什么需要 Leader，需要层级？任何一个超过几十人的组织都需要架构设计。这件事如此普遍，以至于我们很少追问：为什么需要组织架构？组织架构本质上在解决什么问题？
表面上看，组织架构是在划分职责、分配资源、明确汇报关系。但如果往下挖一层，会发现一个有趣的视角：一个组织本质上是一个分布式信息处理系统。 外部信息进来，内部处理，输出决策和行动。组织架构定义的，其实是信息如何在这个系统里流动——谁产生信息，谁消费信息，信息经过哪些节点，在哪里被过滤，在哪里被聚合。
当组织只有十几个人时，不需要刻意设计这些。信息自然流动，everyone talks to everyone，共识在茶水间和午餐桌上自然形成。但当组织膨胀到几百人，问题就来了。
这时候你会发现一个硬约束：人的带宽是有限的。一个人一天能深度沟通的人数大约是 5-7 个，能维持有效工作关系的大约是 15-50 个。这不是意志力的问题，是认知带宽的物理极限。当组织规模超过这个阈值，每个人就不可能和所有人保持有效连接。
怎么办？信息的流动必须被设计。必须有规则来决定：这个问题该找谁，这个决策谁来做，这个信息该传给谁。如果没有这套规则，每个人每天光是搞清楚「该和谁对接」就精疲力竭了，更别说干活儿了。
组织架构，就是这套规则的固化。
组织熵减：一个合理的设计
从信息论的角度看，组织架构做的事情可以用一个词概括：熵减。
熵是不确定性的度量。组织架构通过预定义的边界，消除了「谁负责什么」的不确定性。A 场景归 A 团队，B 场景归 B 团队，遇到问题不用想，按图索骥就行。
以推荐算法团队为例。一个大厂的推荐系统可能服务十几个场景：短视频、直播、搜索、商品、广告……如果不做划分，几百个人对着同一坨代码和数据，光是「这行代码谁能改」「这个实验谁来跑」就能吵翻天。
所以自然而然地，组织会按某种维度切开：按业务线分自然推荐和广告推荐，按场景分短视频、直播、搜索，按物料分视频、商品、直播间。每一类形成一个独立的小团队，人和系统权责统一——你负责这个场景的效果，你就控制实现效果所需的一切：数据、算力、技术方案。
这样做的好处是实实在在的。每个人只需要深度理解一个场景而不是所有场景，认知负载变得可控。决策链路变短了，场景内的问题场景内解决，不用层层上报。权责清晰了，效果好是你的功劳，效果差是你的责任，没有扯皮空间。团队内部人少、沟通频繁，容易形成共识，技术方案和业务理解能保持一致。
在相当长的时间里，这套模式运转良好。尤其是在特征工程时代，算法效果很大程度上依赖对业务的深度理解、对特征的精心设计，小团队的专注和深耕恰恰是核心竞争力。
这是一个合理的、甚至必要的设计。
Scaling Law：游戏规则变了
2020 年，OpenAI 发表了一篇论文，揭示了一个简洁但深刻的规律：模型效果与数据量、参数量之间存在可预测的幂律关系。只要数据和参数同步增长，效果就会持续提升，而且这个提升的轨迹是可以预测的。
这个发现被称为 Scaling Law，它解释了 GPT 系列为什么一代比一代强——不是因为架构有多巧妙，而是因为更大的数据、更大的模型、更多的算力。GPT-3 比 GPT-2 强，不是因为想出了什么绝妙的 trick，而是因为参数量从 15 亿涨到了 1750 亿。
后来的故事大家都知道了。GPT-4、Claude、Gemini，大模型军备竞赛全面展开。整个行业突然意识到：原来效果是可以用规模「买」到的。
这对推荐系统意味着什么？
以前，效果来自于人——人对业务的理解，人对特征的精心设计，人对模型的细致调优。人是核心生产要素，数据和算力是辅助。现在，效果来自于规模——数据量和模型参数量。模型自己从海量数据中提取模式，人的 domain knowledge 相对贬值了。
Scaling Law 要的是什么？数据聚合，把跨场景的数据放在一起训练，让模型看到完整的用户画像。算力聚合，集中资源训大模型，突破容量阈值。方案统一，一套架构承载所有场景，共享表示学习。
三个词都是「聚合」，都要求打破边界。
等等，这和组织架构在做的事情，方向好像完全相反？
两种不同的「熵」
没错，这里藏着一个根本性的矛盾。
组织架构要减少的是协调熵——人与人之间协调的不确定性。这是为了适配人的带宽限制，完全合理。Scaling Law 要利用的是数据熵——数据中包含的信息量。数据熵越高，模型能学到的东西越多。这是两种完全不同的「熵」。
问题在于，当组织架构为了降低协调熵而划分边界时，它顺手把数据也切开了。
为什么会这样？因为「权责统一」的逻辑。你负责这个场景的效果，那你就应该控制实现效果所需的资源。数据归你关注，算力归你支配，技术方案你说了算。这套逻辑在管理上无懈可击，但它的副作用是：每个团队只盯着自己那一亩三分地的数据，跨场景的信息流动被切断了。
用户是一个整体。他在短视频、直播、搜索、广告中的行为，是同一个隐变量——“真实偏好”的不同投影。分开建模，每个模型只能看到一个投影，像盲人摸象。联合建模，才能还原完整的用户。组织边界切的是人的职责，但刀落下去的时候，数据和算力也被切开了。
线性假设的崩塌
你可能会想：切开就切开呗，每个团队把自己的部分做好，加起来不就是整体吗？
这正是问题所在。这套逻辑有一个隐含假设：资源价值是线性可分的。10 个团队各 100 卡，约等于 1 个团队 1000 卡。如果这个假设成立，分区确实没有代价。
但 Scaling Law 揭示的现实是：1 个 10B 模型的能力，远超 10 个 1B 模型之和。这不是「好一点」和「差一点」的区别，是质变。
为什么会这样？首先是容量阈值效应。某些复杂模式——比如「用户在工作日通勤时喜欢短视频，周末在家时喜欢直播」这种跨时间、跨场景的关联——需要一定的参数量才能表示。低于这个阈值，模型根本装不下这种模式，不是学得差，是完全学不到。10 个小模型可能都在阈值以下，1 个大模型跨过了阈值，效果天差地别。
其次是表示共享。用户的基础偏好表示，是所有场景都需要的。大模型学一次，所有场景共享。小模型各学各的，每个都要从头学这套基础表示，算力被重复消耗，留给场景特定知识的容量就少了。
还有互信息的问题。跨场景的信息——比如用户在搜索里表达的意图对推荐有多大帮助——是一个整体属性，没法切成两半分给两个模型再拼回来。分开之后，这部分信息在两边都是零。
最后是涌现。某些能力在小模型上完全不存在，规模过了某个阈值后突然冒出来。这是相变，不是渐进提升。组织架构基于线性假设设计，却撞上了超线性的现实。
Consistency：更隐蔽的代价
还有一个更隐蔽但更致命的问题：一致性。当多个团队各自建模时，会发生什么？
用户在短视频刷到一个搞笑视频，切到直播又被推荐同一个创作者的直播间，打开搜索发现热搜还是相关话题。各个场景不知道彼此推了什么，没有人在全局层面协调「用户已经看过了」这件事。用户的感受是：这个系统很蠢，翻来覆去就这点东西。
用户在搜索场景明确表达了「想买一台相机」的意图——这是一个多强的信号！但这个信号没有传递到推荐场景。切到信息流，系统还在根据他三个月前的浏览记录推荐早已不感兴趣的内容。一个场景的高价值信号，在另一个场景完全失效。
同一个用户，在短视频系统里是「二次元爱好者」，在直播系统里是「电商剁手党」，在广告系统里是「价格敏感用户」。三个画像各自有道理，但拼不成一个完整的人。当需要做跨场景决策时，没人知道真正的用户是什么样的。
这不是多样性，是割裂。 多样性是同一个智能体在不同情境下做出不同但协调的决策；割裂是多个互不通信的智能体各自为政。
“人多”是 Consistency 的敌人
为什么会不一致？因为人多。
信息在人之间传递，有三层必然的损耗。编码损耗：脑子里的想法变成说出来的话，必然丢信息。传递损耗：话在人与人之间传递，每一跳都有衰减。解码歧义：同样的话，不同人理解不同，每个人都有自己的背景和隐含假设。
假设每次传递的保真率是 0.9。两个人之间还好，0.9。五个人的链条，保真率就降到 0.66。十个人，0.39。而且组织不是线性链条，是网络，信息要在网络里来回传播、汇聚、再分发。人数增加，一致性指数级下降。
组织架构的分区，本质上是承认这一点：全局一致性不可能，那就退而求其次，保局部一致性。每个小团队内部人少、沟通频繁，能维持一致。但团队之间？放弃了。这是妥协，不是解决。
现在来看模型。一个模型，同样的输入必然给出同样的输出。没有理解歧义，没有传递损耗，没有编码误差。Consistency 是 100%。 这是人做不到的。一百个算法工程师对同一个用户的理解一定有差异——哪怕只是微妙的差异。一个模型对同一个用户的表示，永远一致。
当用一个大模型服务所有场景时，用户在短视频是表示 X，在直播还是表示 X，在广告仍然是表示 X。跨场景的一致性自动获得，不需要开会对齐，不需要写文档同步，不需要任何人协调。模型是完美的一致性机器。
解法：人少但高密度
现在可以把整个逻辑串起来了。
人多，人的带宽有限，需要分区来降低协调熵。分区切断了数据和算力的聚合，阻碍了 Scaling Law。同时，人多导致一致性下降，数据的价值被系统性地折损。两头夹击，效果受限。
反过来呢？人少，协调成本本来就低，不需要复杂的分区。没有分区，数据和算力可以充分聚合，Scaling Law 生效。模型天然 100% 一致，人少了剩下的人之间也容易保持一致。数据价值被充分利用，效果释放。
组织熵减，是「人多」这个病的解药。 Scaling Law 告诉我们：也许从一开始，就不需要那么多人。当病因消失，解药也就不需要了。
终局图景
如果 Scaling Law 充分生效，算法组织会是什么样？
人数会大幅减少，可能是现在的 1/5 甚至 1/10。200 人的团队变成 30-50 人。模型团队会是少数高密度人才，负责统一大模型的研发，控制最大的杠杆。场景团队会变得轻量，更像是「模型的用户」而非「模型的开发者」——通过接口调用模型，做场景特定的轻量调整和业务逻辑。人与人之间的协调会大幅减少，更多是人与模型的接口。标准化程度高，协调成本低。50 人的组织，不需要 500 人组织那套复杂的架构。
这让人想起电力系统的演化。电力普及之前，每个工厂自己建发电机，需要大量电气工程师分布在各处。电力普及之后，发电集中在电厂，工厂只需要「用电」。电气工程师的数量大幅减少，剩下的集中在电厂和电网。模型，正在变成「智能的电力」。
写在最后
组织架构的分区设计，最初是为了让更多人能协作。它是一个合理的、必要的妥协。但 Scaling Law 揭示了一个讽刺的事实：也许从一开始，就不需要那么多人。
分区是为了管理人多带来的复杂度。如果人本来就可以少，复杂度本来就可以低，分区反而成了绊脚石。当模型足够强大，能够承担信息处理的主要职责时，不需要那么多人来理解业务、设计特征、调优模型。人少了，协调成本自然低。协调成本低了，不需要复杂的分区。没有分区，数据和算力可以充分聚合。聚合之后，Scaling Law 的红利才能真正释放。
未来属于：小团队，大模型，高一致性，充分聚合。
组织熵减解决的，终将是一个不再存在的问题。