我身边的朋友可能知道，国内的疫情让我非常沮丧。 昨天晚上和M兄聊了一会，心情好了一些。M兄的几句话在我脑子里萦绕一宿，醒来时决定记录下来： 疫情对落后地区的人来说尤为痛苦，但是当把直接造成他们痛苦的防控政策打碎后，迎来的是更痛苦的现实。这不是打倒了几个坏人，世界就能变美好的，而是世界本身就是充满痛苦的，挣脱痛苦需要更痛苦更漫长的劳动才行。只有接受了这种设定，才能顶着疫情撸起袖子干。躺下不干情况并不会变好。我现在只盼着自己能尽量不要拖我司后腿，保障手头的一堆项目开展。
引言 出于某些原因，我开始思考在去中心化信息传播的时代，如何准确、全面、及时、广泛、低成本地传达信息，尤其是当信息的发布方拥有权威时。 比如以下的例子： 老师如何发布信息给多个班的学生 商业公司如何宣传自己的多种产品 有关部门如何辟谣 互联网去中心化传播时代的挑战 有人可能会问，既然信息的发布方拥有权威，信息的传递岂不是非常方便？然而情况并非如此。在这一章，我们简要讨论权威信息发布方所面临的挑战。 各大互联网社交平台是当下主要的信息传播渠道。个人、自媒体、组织，都拥有在社交平台发布信息的能力。本文的去中心化，指信息的发布者的去中心化。平台本身虽然还是中心，但首先并不是信息的主要发布者，其次也不是信息的唯一渠道。 我们都说现在信息越来越碎片化。微博有字数限制、视频越来越短。很多人认为人类的大脑可能更容易接受碎片化信息，互联网社交平台为了吸引用户迎合了这种喜好，也进一步加强了这种喜好。我这里有另一个角度，从商业模式出发。 大多数互联网社交平台，其动机其实不是为了帮助用户发布信息，而是为了让用户接收自己发布的广告。可以说用户发布的信息只是卡车，平台发布的广告才是货物，卡车只是为了把货物递送给平台用户。因此这些平台天然抵触大段信息，因为那样就无处插入广告，至少不利于用户接触广告。这些平台天然亲近碎片化的信息，因为广告就是碎片化的，这样可以方便广告混入其中。 权威信息发布方的一些需求和社交平台是不匹配的： 信息发布方需要准确、全面，而我们刚刚已经论证了，社交平台天然抵触大段信息。 信息发布方需要实时发布或者更新信息，然而如果过于频繁推送信息，反而可能引发受众的反感。 信息发布方需要广泛地传播信息，然而社交平台擅长让情绪化、碎片化的信息广泛传达，反而会淹没高质量的信息。 信息发布方需要低成本维护。然而现实中为了触及最广泛的受众，信息发布者需要维护众多平台上信息的准确、全面、及时、一致，还要适应各个平台本身的限制，是非常麻烦的。 当然，权威信息发布方为了吸引关注或者提升好感度，也会有发布碎片化信息的需求。可是这样碎片化的信息，与重要的正式信息混杂在一起，不但显得混乱，而且无法精准投递给不同受众。有时候受众需要的是带感情的信息，正式的信息起不到安抚的作用，甚至会火上浇油。而有时候受众需要的是正式的信息，却发现不知道去哪里获得。 基于以上的原因，权威的信息发布方在互联网去中心化传播时代算是客场作战，有巨大的劣势。 信息堡垒 既然权威信息发布方在社交平台有巨大的劣势，那不如建设好信息中心，发挥中心化的优势。 这种信息中心需要满足以下要求 单一。一个信息中心只服务于一个信息发布方。信息中心由信息发布方完全控制，不受到社交平台的限制，不被其他发布方的信息干扰。 准确。信息中心的信息是信息发布方意志的精准描述。 全面。信息中心需要容纳信息发布方需要发布的所有信息，同时建立信息的互联。信息受众在其中不仅仅可以找到自己需要的信息，也会被引导接触其他相关信息。这就造成了不同信息的交叉传播。 敏捷。信息发布方可以实时更新信息。信息中心并不推送信息，所以也无需担心受众厌烦。 易用。这体现在三个层面。第一，信息受众可以很容易接触到信息中心，不需要账号。第二，在信息中心内部，用户可以轻松通过搜索/分类/标签等方式找到自己需要的信息。第三，信息本身的表达方式是精心准备的，简明易懂，可以有不同的详细度。 我将这种信息中心称之为“信息堡垒”(infortress)。 有些人可能注意到，信息堡垒更多是被动地提供信息，那么如何做到信息的广泛传播呢？ 互联网社交平台提供信息的入口，向用户通知信息的发布并提供链接，也就是将流量引入信息堡垒。信息堡垒也可以提供各个平台账户的信息，引导用户关注，实现平台-堡垒-平台的互联。 当然还有其他办法将流量引入信息堡垒，引入流量嘛，有的是办法。 尽量为信息堡垒建立“最准确最及时最全面的信息来源”的形象，让受众在需要信息时第一反应就是去信息堡垒。 在社交平台上挂链接的不一定要是权威方，如果质量够高，肯定有其他人乐意转发到平台上。 信息堡垒不仅仅是提供干巴的信息，也可以提供更具娱乐性但也有不失权威性的信息（比如专家访谈），使得“逛堡垒”成为有趣的事情，以此吸引受众。 其实有的时候信息堡垒并不需要引入用户，因为在这个低质量信息爆炸的时代，用户有获得高质量信息的需求，会主动寻找高质量信息。信息堡垒只需要做好信息的质量，以及信息的交叉传播就可以了。 值得注意的是，由于不再需要考虑权威性，在社交平台发布的信息也可以更灵活一点，更有感情一点，注重受众的情绪。 一句话总结就是，信息堡垒作为信息源，注重权威，社交平台将流量引入信息堡垒并影响受众情绪，注重传播。信息堡垒与社交平台各司其职，这样的解耦可以解决权威和传播的冲突。 有些组织一味迎合新媒体的潮流，几乎完全放弃了信息堡垒的建设，而把社交平台作为自己的唯一战场，在我看来是比较可惜的错误。 案例 其实现实中就已经很多这样的实践，基于这样的思路也有更多事情可以做。 教学网站。教师尽量把所有的材料都放到教学网站上去。但是学校统一的教学网站和信息堡垒有一定差别，首先是不受教师完全控制，其次是多门课并不方便。我可能更想搭建自己的网站，把我教学和研究需要公开的信息都放上去（给我的其他课程以及研究打广告，这可不就是信息的交叉传播）。学校教学网站可以用于发布成绩等等隐私信息。 个人网站。我已经基本放弃所有的社交平台了，所有的信息发布都在个人网站。由于我不需要吸引受众，我也不会在社交平台介绍这个网站，只会邀请少量好友观看。我发现这样不但更加方便灵活，而且可以让我更系统地组织想法。 商业公司的官方网站。公司虽然有社交平台账号，但是大多只是向用户通知信息的发布和提供链接。有很多公司也会在官方网站上放技术博客和产品文档。这一方面国外的一些公司做的很好，相比而言国内的公司整体差很多，我甚至经常找不到公司的主页，在我看来是值得改进的。 某些部门的官方网站。这方面美国的CDC做的不错，可以借鉴。
我认为“systematic”是非常重要的思想，其重要程度容易被低估。本文旨在记录我的思考，既是对我个人的提醒，也想和小伙伴们交流。 “systematic”的要素 我搜到的systematic的定义是“done or acting according to a fixed plan or system; methodical”。这个定义太简略了，我个人理解有以下要素： vision and roadmap 首先就是要有发展远景和发展规划。我们拿做研究来举例，好的研究者应该要有心中的蓝图，知道自己多年后要实现的终极目标，每一篇文章，应该是这个终极目标的准备工作或者部分结果。我想需要避免的就是“无助于实现长远研究目标的，ad hoc的工作”。 基于这样的原则，我们就可以产生一些价值判断。比如看起来不够硬核的文章。有一些同学会称之为“灌水”，但是在我看来，如果你清楚地知道这个文章的定位是更高的工作的准备，比如就是帮助自己学习某一个新东西，或者训练低年级学生的研究能力，那么这个文章就是值得的。 当然，vision和roadmap也是不断迭代的，它会随着我们得到新的结果/证据，以及外部环境的变化，而不断更新。重要的是一定要有，并且在其指导下工作。 machinery 我想注重“一整套机器”而非“解决孤立的问题”，我可以举几个例子。 第一个例子是数学中的公理化体系，比如基于测度论的概率论。我们从最基本的东西出发，利用已有的结果，去得到更高的结果，这些结果组成了一个巨大的机器。我们不断利用这个机器去得到新的结果，而这些新的结果又会成为机器的一部分。到最后我们可以得到非常nontrivial的结果，如果不是依靠这个机器，这些结果是绝对不可能达成的。事实上历史上有很多例子，为了解决某一个问题（获得某一个结果）而发明了一整套机器，而这套机器不但可以有条不紊地解决这一个问题，还可以解决别的问题。 第二个例子是DeepMind的一些工作。我发现DeepMind还是很重视搭建machinery的。他们的终极目标是AGI，在对某些问题的研究中，他们觉得relational inductive biases within deep learning architectures是关键要素，因此他们造了一套工具，也就是graph networks，而且做得尽可能general而不是限制在某一个问题。为了方便自己未来的实验，他们写了对应的库。再此之后，他们用graph network的同一套工具做了很多应用性的工作，比如traffic prediction, AlphaFold 2等等，而graph network本身也在各种应用中得到进化，比如引入attention。其实我相信这些应用工作都是他们发展的中间结果，他们想利用这些问题帮助他们建造更好的机器。 我们可以总结一下，machinery强调的是，从某一个小问题出发，抽象出核心要素，搭建一整套机器（而不是把目光局限于这一个问题），用这套机器再去解决更多问题，并在解决问题的过程中不断丰富完善这个机器。 scalability and sustainability 现在的风气非常流行抓住风口赚一波，流行短期效益，而轻视发展的规模化和可持续。 在这方面，我要推荐《Software Engineering at Google》这本书。它一定程度上总结了Google的方法论，试图回答how to scale。不仅仅是在技术层面，也包括文化、管理层面，对非软件工程的从业者也有启发。这本书存在本身，也说明Google真的很强调方法论的总结。 methodology 我想注重“方法论”而非“个人经验或灵感”。如果不能总结成方法论，那么个人的经验和灵感就很难迁移，也就很难有scalability和sustainability。所以一定要有“按照方法论的指导去工作，并不断迭代方法论”的意识。 我想从“方法论”的角度，聊一聊今年全国二卷的作文题，也就是《红楼梦》的那个。事实上，我个人认为这个作文题极好，比我当年高考前后的江苏卷风花雪月不知道高到哪里去了，也比某备受吹捧的欧洲国家作文题的辩经不知道高到哪里去了。因为这个题目讨论的就是关于创新与发展的方法论：移用、化用、独创。它非常务实，又非常general，我无比希望有人能在我18岁的时候教我这种方法论。 第一步，移用，简单说就是抄。要抄得心安理得，要抄得大大方方。哪怕抄得很生硬也没有什么不好，毕竟你啥也不懂，抄就是最好的学习。在抄的过程中积累经验，领悟抄的东西的精髓。 第二步，化用。在对抄的东西不断深入的理解中，知道它的优势和局限性，做一些修改，应用到自己的问题里。 第三步，独创。在不断地化用中，结合自身的实际情况，量变产生质变，最后就有了独创。我们从小被教育要独创，轻视移用和化用，但是哪有无源之水，所有的独创都是能找到脉络的，移用和化用是通往独创的最有效途径。闭门造车，或者在虚空中苦苦思考如何创新，是没有意义的。 个人的学习工作是不是这样的？ 企业的技术研发和商业创新是不是这样的？ 国家的政治经济文化军事的发展是不是这样的？ 这是多么general的方法论啊！所以我要吹爆这个题目！ 我打算以后再单独写一篇讨论这个事情。 “systematic”的陷阱 我在这里先罗列一些可能的陷阱，以后有时间再添加。（基于“快速迭代”的原则，我并没有等全部写完再发出来） 1，机械教条与路径依赖，丧失中枢而只剩下无意识的、incremental的优化。这一点我听说Google就有这个倾向。 2，systematic可以帮助、引导思考，但是有些时候也会限制想象。所以我建议two-phase thinking，第一个phase是完全抛弃方法论，天马行空地思考，第二个phase是在框架下思考。两个phase交替进行会比较好。 先到这里了，以后有想法再改。
简介 2021年夏天，在博士毕业之后，我加入了工业界做智能系统相关的工作。原因有很多，其中之一就是我对AlphaGo、GPT-3等等大型智能系统充满好奇。罗马不是一天建成的，绝不可能有一个人从一开始就设计好了所有的架构与细节，大家按照这样的设计写完代码，在大数据集上训练，一次性成功。 如何组织多人，甚至数十上百人，在一年左右的尺度下，成功开发出大型智能系统？ There must be something there. 在工作近一年之后，我渐渐有一些模糊的理解，在这里加以整理记录。对工业界的朋友而言，这些可能是融入血液的常识，但对久处象牙塔的我而言，却是极大的启发。我认为这些是极为重要的“元经验”，是工程开发的“第一性原理”，也是学术界，尤其是应用数学界，应该从工业界学习的东西。 效率的提升 在工作中，始终应该保持"提高工作效率，增加单位时间产出”的意识。这既包括个人工作，也包括团队合作。除了“善用工具、劳逸结合”等等一般意义上的提高效率，软件开发有独特的一面。 有人可能会问，我一个做应用数学的，不是应该更注重灵感吗？解释如下： 应用数学离不开数值实验，灵感也是从信息中来的。快速实验，快速获得反馈。有些实验甚至必须建立在极高的效率之上。 节省时间与脑力，多花在阅读文献，思考，讨论之上。 提高效率不仅仅限于软件开发，比如说教程库与文献库的建设。我个人认为数学和软件工程有非常多的相似性，数学定理的封装与应用，也可以理解成“复用”。 自动化 无聊的工作也会消耗脑力。 尽可能把所有无聊工作自动化，比如一键提交、提醒、处理、下载。会不会浪费时间在工具的搭建呢？不会的，只要我们尽可能复用工具。如下。 复用与基建 复用的动机以及指导原则是： 节省个人和团队的时间。 更重要的，可以逐渐变得更好，最后形成分享的“基建”。 我需要特别解释一下“更好”。这里的更好包括： incrementally更好，比如让某一些代码更加general。 通过封装、嵌套、组合，最后达到指数级的复合增长——这是软件工程的魔法。 不用着急一步到位，一点一点建设，积累下来就是很多工作了。 代码复用 定义好接口 文档(尤其是注释)与范例 尽可能成系统，定期整理 文档复用 比如说，我要给一个人讲一套东西，那我可以写成教程，这样如果有另一个人需要我再讲一遍，我就可以把这个教程给他，而节省了再讲一遍的时间。而如果未来的我，或者另一个人，对这个教程有补充，那就可以变得更好！最后我们可能就有了教程库，甚至一本书。本文就是一个案例。 再比如说，团队一起建设文献库。每一个人记录对新的文献的理解和评价，可以节约文献阅读和搜索的时间。额外的好处是，也加强了沟通。 注意精简而不失信息，以提高信息传递的精度以及阅读效率。关键的地方值得迭代。 项目复用 也就是我下一个项目尽可能是建立在上一个项目的基础之上，我每一个项目也尽可能为后续的项目做好准备。不仅仅是代码复用，文档复用，也有知识与经验的复用。 分布式并行开发 建议所有人学习git。 迭代 这是最有意思的部分。 迭代的动机和指导原则： 在一开始并不知道要做成什么样子，需要依靠对比、反馈来决定后续工作 便于并行开发 提供短期回馈，保持心理健康 测试代码 测试代码可以帮助控制代码质量，同时也是文档和范例（接口是啥，功能是啥，怎么使用）。 标准问题（Benchmark） 我之前低估了benchmark的重要性，毕竟在数学里，好坏是可以推导出来的。但是用标准问题比较好坏，确实要简单快捷很多。更重要的是，便于分布式开发。各个lab一起试图解决某个问题，这不就是分布式开发嘛。 神经网络的迭代 传统的软件开发，可以分模块测试、迭代。神经网络讲究end-to-end，并不容易分模块，那要怎么办呢？ 定义小问题 small dataset small batch size small training steps 在小问题上通过快速迭代找到好的神经网络结构和loss function，几轮小迭代之后，就可以在更大的问题上测试，用稍低的频率迭代。最后上超级大问题。 注意记录结果。按照同事的说法，不一定需要grid正交测试，线性测试是可以的。效果不显著的不要留，但如果复合逻辑，可以keep in mind，之后再试试。 调参对个人而言是一个经验活，但是对组织而言，只要有足够快速的迭代（这又回到了效率的问题），总是可以找到好东西的。 这个文档只是我暂时的记录，以后会继续更新。