这个问题其实可以用两个著名的思想实验，从技术和哲学两个角度来回答。 第一个是“中文房间”，是一个著名的思维实验。它是由美国哲学家约翰·赛尔在上世纪八十年代设计的。 这个实验是说你想象一个只会说英语的人身处一个房间里，这个房间除了门上有个小窗户，其他地方全都是封闭的。这个人有一本用英语写成的书，里面指示了该如何处理接受到的中文信息，并且用中文进行回复。房间外面的人不停地向房间里塞进用中文写成的问题，房间里那个说英语的人查阅手边的那本指导书将合适的中文回答递出房间。 虽然房间里的人可以和房间外的人对答如流，房间外的人以为房间里作着个懂中文的人，但实际上那个人只会说英语，只是那本包罗万象的指导书太牛逼了。 套在这个问题里，ChatGPT就像那本指导书，如今的技术让人类真的可以造出这样的东西了。ChatGPT巨大的训练语料就意味着这个模型可能阅读过这个世界上相当大比例的文本，不管是书籍、论文还是博客文章，甚至是代码片段，然后给你一种无所不知的感觉，这也是为什么ChatGPT可以有如此令人惊艳效果的原因。作为在屋外的人们，很有可能认为屋里的人有理解能力，甚至有意识。 如果对技术有一定了解就会知道，当给定输入的时候，ChatGPT这样的模型做的最多的就是非常确定性的加减乘除等等数学运算，在某些环节，这些模型会输出一个概率分布，通过在这个输出的分布上进行随机采样，来达到一种丰富、随机应变的效果。 关于生成式模型的输出采样，可以参考我之前的文章：https://zhuanlan.zhihu.com/p/114669778 和https://zhuanlan.zhihu.com/p/115076102。 不夸张的说，如果把这种随机采样换成贪心采样，也就是每次都取概率最大的输出，那这个ChatGPT一下就会从牛逼闪闪变成木讷呆板。所以，从技术角度说，ChatGPT距离自我意识还相当遥远。 另一个词是“图灵测试”。 图灵测试的内容我直接摘抄维基百科 1950年，图灵发表了一篇划时代的论文，文中预言了创造出具有真正智能的机器的可能性。由于注意到“智能”这一概念难以确切定义，他提出了著名的图灵测试：如果一台机器能够与人类展开对话（透过电传设备）而不被辨别出其机器身份，那么称这台机器具有智能。这一简化使得图灵能够令人信服地说明“思考的机器”是可能的。论文中还回答了对这一假说的各种常见质疑。图灵测试是人工智能哲学方面首个严肃的提案。 或者是这样 如果一个人（代号C）使用测试对象皆理解的语言去询问两个他不能看见的对象任意一串问题。对象为：一个是正常思维的人（代号B）、一个是机器（代号A）。如果经过若干询问以后，C不能得出实质的区别来分辨A与B的不同，则此机器A通过图灵测试。 我相信当下的ChatGPT已经非常接近或者已经可以通过图灵测试了。那么从这个角度来说，机器已经相当与能思考，或者说有自我意识了。 我在知乎的原回答

我的想法是剽窃、作弊成灾是会的，但扼杀人类的内容创造力是不会的。 首先人工智能模型造成剽窃、作弊的现象是近几年才出现的新情况，这也是模型水平进步的一个表现。而且，这种模型导致的剽窃和作弊相比于原来的形式还有比较明显的差别。要理解这件事情，还需要稍微了解一下这些模型的训练方法。 以ChatGPT为例，它最重要的一个环节是语言模型的预训练。它所依赖的语言模型是来自OpenAI的GPT-3.5。以他的前身GPT3来说，训练这个模型的数据来源如下 来自https://en.wikipedia.org/wiki/GPT-3#GPT-3.5 从表里可以看到，即使是让普通人觉得已经无所不包的维基百科只占到了训练数据的3%，可见训练一个顶级的语言模型需要多少数据。训练的过程有点像填字游戏，让模型看一小段文本，让它猜测后面接着的文本是什么。是不是有点像人类的背诵？ 而这么巨大的训练语料就意味着这个模型可能阅读过这个世界上相当大比例的文本，不管是书籍、论文还是博客文章，甚至是代码片段，这也是为什么ChatGPT可以有如此令人惊艳效果的原因。它看过的这些文本，最终是形成了一个巨大的概率分布，例如看到“世界”，它会知道后面也许会跟着“杯”或者“地图”，它们有着不同的概率。 所以这种模型的剽窃和作弊是隐性且抽象的，需要人类用问题把模型的知识“钩”出来。虽然稍微不一样的钩子就有可能从模型钩出很不一样的结果，但由于这写结果本质上都符合模型训练时语料的概率分布，所以很有可能就会触发剽窃和抄袭。这确实是一个两难的问题，如果没有这海量的训练数据，就没有令人惊艳的模型，但这么大量的数据要把版权问题搞得清清爽爽也绝不是一件易事。 但对人类创造力的扼杀的担心我觉得大可不必。首先，模型暂时还没有实时进化的能力，ChatGPT的训练数据停留在2021年，它并不知道2022年底中国会突然放开防疫政策，那以此为题材的创作显然与他无缘。 其次，真正的创造欲望和创造力哪会因为创作之后会有人剽窃就减弱？那是一种使命感，是不吐不快的感觉。 大家都知道保护知识产权有利于激发社会创新创造，但近几十年来的开源运动也证明了这不是唯一的路径。在人人为我我为人人的开源软件世界，这种开放反而极大地促进了技术的进步和传播。说不定以后在AI模型领域也会有这样的运动，人们贡献出自己产生的语料供模型学习，然后用适当的license系统保证产出的模型可以被合理、公平地被使用。 我在知乎的原回答

作为一个近几年语言模型大潮的经历者谈一谈自己的看法。 ChatGPT is ’not particularly innovative,’ and ’nothing revolutionary’, says Meta’s chief AI scientist 上面一句话是Yann Lecun说的，虽然被网友群嘲柠檬精，但我是比较认同的。我感觉”大模型“确实是一个革命，但ChatGPT更适合作为这场革命阶段性胜利的一个里程碑。而其实这场革命的火种早就已经播下了。 这场革命如果往早了说，我觉得可以追溯到连接主义的诞生。 连接主义(connectionism)，又称为仿生学派或生理学派，其主要原理为神经网络及神经网络间的连接机制与学习算法。 这一学派相信神经网络是实现人工智能的方式，上世纪40年代就出现了。但它的发展历程很曲折，经历过很多高光时刻，也多次陷入低谷 我们先来看一组数据： 人脑是一个极其复杂的器官，由大约1000亿个神经元、大致相同数量的非神经元细胞和数万亿个神经连接组成。 如果你希望要用神经网络来实现人工智能，自然的想法就是神经网络的规模要跟人类大脑相当。也就是说足够”大“会是一个非常朴素的需求，他并不是最近才出现的。 前几天横空出世的AI 爆款产品ChatGPT，可以聊天、写代码、解答难题、写小说，其技术底座正是GPT3.5 大模型，参数量多达1750 亿个。 从上面的数据可以看出，目前牛逼的神经网络参数量已经跟人脑的神经元数量相当了。但了解神经网络的朋友应该会知道，上面所说的GPT3.5的参数量实际上是要跟人脑中的神经连接数进行类比，而不是神经元个数。也就是说目前最牛逼的神经网络容量和我们的脑容量还有数量级的差距。 在当下，大部分人都会相信我们堆更大的模型用更多的数据还能够提高神经网络的能力。于是短短几年间，从BERT的1M参数已经进步到GPT3.5的175B参数。 但在若干年前，这个事情还不是这样，人们想大也大不起来。因为没有找到合适的结构，也没有合适的训练方法，可能硬件也不够给力来让神经网络越大越好这件事成为现实。直到Transformers模型和基于掩码的非监督训练方式出现，事情才发生转机。所以往近了说，这场革命应该归功于这两件事，ChatGPT的祖宗GPT在2018年就出现了。 要说这革命有多大，我感觉目前的结果还是不如前面第一和第二次工业革命大。那两次都是极大地改变了人类的生产方式，丰富了人类的物质生活，实现了例如探索宇宙这样之前无法办到的事情。现在的ChatGPT相比起来还差一些。但是AI4Science领域也有很多激动人心的结果，未来还有很大的潜力。 我在知乎的原回答

我感觉问题中的两个选项并不是互斥的，而且所谓被AI支配的开始甚至都不是一个合格的选项，为什么这个开始是ChatGPT，不是计算机的发明，甚至是二极管的发明呢？但是我认为说ChatGPT是“解放生产力的机会”还是比较靠谱的。 它解放生产力的能力已经被大量的报道了，以剧本创作为例，假如你有一个绝妙的故事创意，你可以让ChatGPT快速地帮你产生好几个版本的剧本。这种机器辅助的模式可以极大地增加内容生产的效率。 但ChatGPT并不是一个可以自主创作的人工智能，它是一个以对话机器人的形式呈现的算法模型。就像是一个从不主动说话，但几乎有问必答，且学富五车的人。要把它的知识或者创造力激发出来，需要有适合它的问题。而我一直觉得提问题是一个比回答问题更有难度、更体现创意的事情。还是以前面的剧本创作为例，正是因为你有了一个绝妙的故事创意，ChatGPT才能在此基础上写出一个好的剧本，你在这个创作中的贡献是无可替代的。 以此展开，人类创作者还有很多能力是ChatGPT目前不具有的，例如ChatGPT没有情绪。他不会因失恋而难过，也没法因为看到一个漂亮的风景而开心。但很多时候，情绪才是创作的源头。 也就是说，ChatGPT是一个次时代的工具，但创作的主动权，仍然在使用它的人类手上。或者可以说，ChatGPT只会作，而不会创。在内容生产领域如果说真的会被AI支配，我认为应该是被善于使用这种次时代工具的人支配。这也是我们大家可以在其中寻找的机会。如果一个人能够快速获取大量优质的prompt（也就是给ChatGPT的问题），那确实可以在内容生产这个行当里获得远高于一般人的经济回报。但我认为，在内容或者说创意行业，几乎不可能有个体或组织可以达到“支配”行业的程度。这是一个非常分散、个性化的行当，受众的喜好五花八门，萝卜青菜都有人爱。即使好莱坞再强，世界上的其他地方还是可以拍出叫好叫座的电影。 反过来看，今天ChatGPT可以做的事情有多少是真正的创作呢？回答一些答案明确的问题？完成一些格式相对固定的文案？写一个常见功能代码？AI是面镜子，可以让人类反思到底哪些工作是真正的创意工作。当基于统计的模型（ChatGPT也是基于统计的模型）可以把一个问题解决得差不离，那它的创意属性基本上就消失殆尽了。 我在知乎的原回答

2022年Q4，在项目里接触了一些跟召回相关的工作，但坦白讲做的比较匆忙。整好最近在家带娃，空余时间比较系统地学习了一下，这篇小作文做个总结。 本文总结的算法都有一个共同的发端，就是大名鼎鼎的协同滤波（collaborative filtering，CF）算法。这个协同只看字面也看不出个所以然，维基百科的解释如下 协同过滤（collaborative filtering）是一种在推荐系统中广泛使用的技术。 该技术通过分析用户或者事物之间的相似性（“协同”），来预测用户可能感兴趣的内容并将此内容推荐给用户。 经典CF 最早的CF算法是user CF。这种算法包含两个主要步骤 对于当前用户，在所有用户中寻找与他最相似的一些用户 用相似用户对item的评价来作为当前用户对item的评价 我做的几个召回渠道也是基于CF的。如果把这个技术用在召回里，就是对于当前user，返回在与之相似的用户中受欢迎的item。这里面用户相似度的评价方式比较重要，例如通过计算两个用户交互过item的Jaccard距离来作为相似度。这种做法在用户集合很大时计算复杂度相当高。在早期的系统里，item的数量可能远远少于用户的数量，并且用户的相似度会随着用户行为的变化而变化。所以有人提出在item与item之间直接计算相似度，这种相似度相对稳定，离线计算好一个相似度关系表之后在线可以直接使用，这样就可以避免相似用户计算这个耗时的步骤，这种做法称为item CF。 矩阵分解 Matrix Factorization 上面的经典CF算法实际是个间接推荐的方法，人们发现可以从用户和item的交互历史中得到用户和item的关系，从而进行直接推荐。基本的思路是将user-item交互矩阵近似为user矩阵和item矩阵的乘积。具体来说，若用户数为N，item数为M，则交互矩阵为N*M，希望把它近似为N*K和M*K两个矩阵的乘积。K可以远小于N和M，这样相似度的计算复杂度将比jaccard大大降低。实际上也就是获得了K维的user和item的embedding。交互矩阵通常是0,1矩阵（称为implicit feedback data），上面的操作实际上要让有交互的user和item embedding之间的点积接近1，没有交互的embedding点积远离1。 以下图为例，我们获得了4个用户和5部电影的交互矩阵，右边是矩阵分解之后的结果。左边4*2的矩阵为用户矩阵，在一个二维空间对用户进行表征，上面5*2的矩阵是电影矩阵，在同一个二维空间对电影进行表征。右边的大矩阵是这两个矩阵相乘的结果，和左侧0,1矩阵是比较接近但不完全一致的（毕竟降维了）。对于一个user未交互过的item，我们可以拿user的embedding和item embedding做点积来预测用户发生交互的概率。 {: .align-center style=“width:80%”} Matrix Factorization示意图 {: .align-caption style=“text-align:center;font-size:smaller”} 这个算法实际上优化的是下面这个目标 $$ \min_{U \in \mathbb R^{m \times d},\ V \in \mathbb R^{n \times d}} |A - U V^T|_F^2. $$ 学过数值分析的话会知道矩阵分解有一些经典算法，例如SVD。但这个交互矩阵A实在是太稀疏且太大了，经典算法比较难处理，因此实用的损失函数是这样 $$ \min_{U \in \mathbb R^{m \times d},\ V \in \mathbb R^{n \times d}} \sum_{(i, j) \in \text{obs}} (A_{ij} - \langle U_{i}, V_{j} \rangle)^2 + w_0 \sum_{(i, j) \not \in \text{obs}} (\langle U_i, V_j\rangle)^2....

最近ChatGPT火了，而且火出圈了。好多不是做技术的朋友都开始关注甚至转发相关文章。从广为流传的一些例子看，ChatGPT确实做出了让大家眼前一亮的效果。聊天机器人搞了这么些年，也终于有了一个让大家都比较认可的产品。 {: .align-center style=“width:80%”} ChatGPT的结果令人惊艳 {: .align-caption style=“text-align:center;font-size:smaller”} 小迷思 前几天几个小伙伴聊天，说起ChatGPT和OpenAI，纷纷感叹为什么国内没有这样的创新公司和突破性产品涌现。几个大厂的研究院，比如阿里达摩院、字节AI Lab虽然成果也很多，但跟deepmind、OpenAI比起来差距还是很大。其实ChatGPT背后的东西并不是有多难，但为什么做出来的是他们？ 今天在知乎上发现也有类似的问题，还挺火的。不少回答都从大环境的角度分析，有说我们还穷的，有说国内资源和人才不匹配的。这些固然对，但作为个体我们也可以从自己身上找找原因。前几天看到一个做AI架构的大佬在朋友圈感叹，18年就在某大厂实现了500块GPU并行训练transformer，但大家都不知道这东西能干嘛。所以有的时候并不全是资源不到位的问题。我不禁想起了马老师“因为相信，所以看见”的观点，我感觉就是差在这个境界上。从学校毕业五年多了，我感觉这也是自己目前比较大的一个问题，我们有把事情做好的能力，但却缺少真正相信且原意长期坚持的东西。 ChatGPT背后的技术 还是聊回技术。ChatGPT还没有公开的论文，根据OpenAI的博客，基本上使用的技术和他们在今年早些时候公布的InstructGPT差不多。 We trained this model using Reinforcement Learning from Human Feedback (RLHF), using the same methods as InstructGPT, but with slight differences in the data collection setup. {: .align-center style=“width:80%”} ChatGPT训练流程 {: .align-caption style=“text-align:center;font-size:smaller”} 上面是ChatGPT博客上的训练流程图，下面是早先InstructGPT论文里的训练流程图，嗯，可以说是一模一样，比较大的差别是基础语言模型从GPT3升级到了GPT3.5。 {: .align-center style=“width:80%”} InstructGPT训练流程 {: .align-caption style=“text-align:center;font-size:smaller”} InstructGPT的介绍还有图例，更容易讲清楚ChatGPT是如何训练的。这个模型的训练分为3个步骤： 从预训练语言模型出发，用标注者产生的数据fine tune一个根据提示（prompt）生成答案的模型，这一步称为SFT 用上一步训练的模型生成大量的答案，每一个prompt都生成多组，并让标注者对这些答案进行排序。用这样获得的数据训练一个奖励模型（Reward Model，RM）。这个模型会作为后续强化学习环节的世界模型。 强化学习训练。这一步有点左右互搏的意思，用RM模型作为世界模型，SFT之后的生成模型做agent，进行训练，让生成模型尽可能地在RM模型那里拿到高分。这一步使用的算法也来自OpenAI，为2017年发布的PPO算法。 {: .align-center style=“width:80%”} 强化学习基本流程 {: .align-caption style=“text-align:center;font-size:smaller”} 我对强化学习并不熟悉，只是稍微看了下PPO的介绍，这个算法的目标函数可以用下面的公式来概括，这个目标函数包含了三个部分，第一部分是标准的强化学习目标，即在reward model那得高分；第二部分是PPO的创新点，即KL惩罚，目的是让强化学习的每一步都不要更新太多（新模型和老模型的KL散度要小）；第三部分是针对语言模型精调新加的，为了防止语言模型在精调的时候退化，他们在精调时把语言模型loss也加了进来。三个部分通过两个超参数β和γ进行调节。...

《The Cathedral & the Bazaar》 By：Eric Steven Raymond, 1997 基础版本：https://github.com/crazyangelo/Cathedral-and-Bazaar 基础版译注：原始版本為 1999 年 5 月 5 日，由謝志昌所翻譯；英文最新版為 2002 年 8 月 2 日的 3.0 版，由於內容更動處不少，因此逐一更新；翻譯以語句通順達意為主要考量，難免與英文版的字詞有所不同，為求盡善盡美，以 CC 授權釋出，希望各方同好自由修改散佈。 本版译注：将繁体字改成简体，并修正了一些词汇表达 第一章 教堂与市集 Linux 打破了许多软件发展的传统，这个世界级的操作系统在五年前（1991 年）仅仅靠着如丝般的网际网路，神奇地联合了散布在全世界数以千计兼职的玩家们来发展它，谁曾料到会发生这样的事情呢？ 我当然也没料到，Linux 出现在我电脑萤幕是在 1993 年初，当时我埋首于 UNIX 及开放性原始码的软件发展已有十年，1980 年代中期，我是 GNU 专案首批的贡献者之一，我写过许多开放性原始码的软件放到网路上供人使用，也曾独立或协同发展好几个程序（nethack，Emacs 的 VC 和 GUD 功能，xlife，…等等），这些程序到今天仍广泛地为人所用，我想我知道这是怎么办到的。 GNU 是自由软件基金会（Free Software Fundation）的一个专案，目标是发展出 UNIX 上所有程序的自由版本，Emacs 是自由软件基会发展出来的一支程序，可做文字编辑器，提供写程序的整合发展环境，用来读电子邮件，新闻群组，甚至浏览网页。更详细的资讯请参考 http://www.gnu.org。 ―― 译注。 Linux 扭转了许多我认为我已知道的观念。多年来我一直宣扬使用小工具集、快速原型发展及程序进化的 UNIX 福音。但我也相信对于有一定复杂度的程序必需使用集中和有经验的方法来开发，我相信最重要的软件（操作系统以及庞大的工具程序如 Emacs）必须如建造一座教堂般，由个别的高手或一小群专家在光辉的孤立中小心翼翼地精雕细琢，时机未到之前，不会释出测试版。 Linus Torvald[^2] 的软件发展风格（尽早并经常发表新版本，授权每一件作者可以委托的事，不拒绝几乎到混乱程度的程序）的出现如同一个惊奇，没有令人肃然起敬的教堂，甚至 Linux 的同好们似乎组成了一个有不同流程和不同方式的大市集（Linux 的档案服务站台就是它适切的象征，每个人都服从着自由的规则），以这个风格发展出来的 Linux 既一致又稳定，表面上看来真是一连串的奇迹。...

第五章 有多少眼球驯服了复杂度 可以很明显地观察到市集模式极大地加速了除错与程序演化。另一件可以清楚明白的是，在微观上，开发者与测试者的每天活动中，市集模式如何与为何可以达到这样的成果。在本章（初版完成三年后，依据开发者多次亲身体验过的洞察力），我们将仔细的检查它的实际机制。非技术性倾向的读者可以略过这一章，直接跳到下一章去。 一个关键点是，为何没有源代码意识的使用者所报告的错不会太有用。没有源代码意识的使用者倾向报告表面上的问题，他们把自己的使用环境视为理所当然，所以他们会忽视重要的背景资料，报告错误时很少会包括可信赖的过程。 这里的问题是测试者与开发者对问题的视角不同，测试者由外向内看，开发者由内向外看。在封闭源代码的体系中，两者只会固守自己的角度谈论事情，因而对另一方深深的失望。 开源的体系则打破这条界线，使测试者与开发者可以站在同样的角度来讨论事情，这有高效多了。实践中，这将有巨大的差异，一者是只报告表象的症状，一者是以开发者那种以源代码为基础的角度来看问题。 大部分的时候，大多数的bug是可以由描述开发层级的特征来除错的，即使是不完整的描述。当一个 beta 测试者告诉你在那一行代码有边界的问题时，或告诉你在 X、Y 跟 Z 的情形下，有个变量有问题，指出有问题的代码通常就足够找出问题并修正它。 因此，对于 beta 测试者与核心开发者来说，有源代码意识的人对于双方都可以强化沟通与合作。换句话说，核心开发者的时间被节省了，即使是在有很多共同开发者的情形下。 另一个开源方式的特征是节省开发者的时间，而这是典型开源项目的沟通结构。上面我使用了「核心开发者」（core developer）这个字来区别项目核心（project core，通常很小；一个开发者是常见的，一到三个开发者则是很典型的）与项目圈（project halo）的 beta 测试者跟贡献者（通常有数百个）。 传统软件开发组织的根本问题是「Brooks法则」︰在落后的项目，增加越多程序员会使得项目更落后。一般的状况下，「Brooks法则」的预测是，随着开发者的人数增加，复杂度与沟通成本随着人数的平方上升，而完成的工作却只成线性上升。 「Brooks法则」依据的经验是，bug会在由不同的人编写的代码的接口上大量出现，而沟通损耗会随着项目参与人数的升高而升高。因此，问题的规模会随着开发者间的沟通路径而呈现平方上升。（精确的说，是 N x （N-1）/2，N 是开发者的数目。） 「Brooks法则」的分析建立在一个隐藏的假设基础上︰项目的沟通结构必须是完全图（complete graph），每个人都可以跟每个人沟通。但是在开源的项目中，开发者在有效平行分割的子项目中彼此很少互动；程序更改与bug报告是透过核心团体来处理的，只有在这样的小团体中，「Brooks法则」的分析才成立1。 还有其它原因让源代码层级的bug报告变得有效率。事实是一个错误常常会有许多可能的症状，取决于使用的的使用状况与使用环境。这些错误是一些复杂与微妙的bug（像是内存管理错误或视窗的随意中断），也是最难被发现或靠静态分析来捕捉的，这在长期的开发中造成最多的问题。 当一个测试者发出一个尝试性的源代码层级的多症状bug报告（例如，我看来在第 1250 行代码有个窗口在做讯号处理，或你在哪里把那个缓存清空），可能会给开发者一个关键的线索来发现半打的症状，这些开发者通常因为太靠近底层代码而无法发现这样的问题。在这种案例中，很难找出可从外部看见的不正确动作是从哪个bug引起的，甚至是不可能的 ―― 但是透过经常发布，就不需要知道了。其他的合作者会迅速找出bug是否已被修正。在很多案例中，导致不正常动作的源代码层级bug将被移除，甚至在还没有被报告之前就被移除。 复杂的多症状错误，通常有很多从表面症状来的方式可以找出真正的bug。这种能让测试者与开发者找出问题的方式，可能与开发环境有关，也可能会随着时间而有无法预期的变化。实际上，当测试者或开发者追踪一个症状时，都是在程序空间的一个集合中「半随机」（semi-random）取样。bug越微妙复杂，越难找出相关的样本。 对于简单与容易复现的bug，重点在于「半」（semi）而非在「随机」（random）；debug技巧、对程序与架构的熟练都是关键。但对于复杂的bug来说，重点就是「随机」（random），这时人多比人少好 ―― 即使这些少数人是平均技巧较高的。 如果从表面的症状找出bug的难度大，像是一些无法从表面症状预测的，上述的结果会进一步增强。单一的开发者可能会以一个困难的方式来做第一次尝试，但其实也可以从简单的方式达到同样的结果。另一方面，假如很多人随着频繁的版本一起测试，可能就会有一个人可以用最简单的方式找到bug，节省了大量的时间。项目管理者将会发现，随着新版本发布，许多人一起用各种复杂方法追踪同一个bug的时代将会过去，尤其是在众人浪费太多时间之前2。 第六章 今花非昨花？ 由 Linus 行为的研究中，我们得到了一个能解释他为什么成功的理论，所以我想要在我的新项目（当然不如 Linux 内核程序复杂和雄心勃勃）中来测试这个理论。 但我做的第一件事情是大力重组和简化 popclient 的程序，Carl Harris 的实现非常扎实，可是却像许多的 C 程序员一样，含括了一种不必要的复杂，他以代码为主，数据结构为辅，因此代码看起来漂亮，但数据结构却很特殊，甚至可以说是丑陋的（至少以这位老资格 Lisp 高手的高标准而言）。 然而，我重写程序除了改良原来代码和数据结构的设计外，还有其他目的，就是把它发展到我可以完全了解，否则负责修补你不懂的程序是一件很无趣的事。 项目进行的第一个月，我简单地依循着 Carl 原来基本设计的用意，第一个重大的改变是我加入 IMAP 协议的支持，我重构原来处理协议的程序，改成一个较为通用的驱动程序再加上三个驱动它的方法表（即 POP2，POP3 和 IMAP）。这个改变阐释了一个广义的原则，特别在像 C 这种先天上未提供动态类型的程序语言，程序员们最好谨记在心︰ 格言9︰聪明的数据结构配上笨拙的代码要比相反的组合好。3 Brooks 在《人月神话》的第九章中也说︰「光给我看你的代码，而不给我看它用的数据结构，我会一头雾水。给我看你程序的数据结构，我通常不需要再看你的代码，因为已经够明白了4。」...

第九章 由 Fetchmail 学到的一些经验 在我们回头讨论一般软件工程的议题前，由 fetchmail 得来的一些特殊教训值得深思。 Fetchmail 配置文件（rc file）的语法包括可有可无的关键字，这些如「噪音」般的字眼会被语法分析程序忽略，这些字的加入，使得配置文件的语法和英文很接近，和传统中简洁的「关键字 ―― 设定值」配对表示法（把噪音字去掉就可以得到）比较起来，要来得容易阅读。 这个教训开始于某一个夜晚的实验，我注意到配置文件中的宣告语法可以组成一个迷你的祈使语言。（这也是为什么我把原来 popclient 中的关键字 server 改成 poll）。 对我而言，如果把这个祈使语言弄得更像英文，那会让 fetchmail 更易于使用，虽然我现在信服如 Emacs、HTML 及许多数据库引擎制定出来的模范语言，在正常情况下我也不那么迷英文的语法。 传统的程序员喜欢非常精确而简洁的配置语法，不希望有任何冗余在其中，这是因为早期的电脑计算资源昂贵而遗留下来的观念，他们认为语法分析的过程要节约计算资源，并要尽可能的简单。英文的语句大约有百分之五十的冗余，所以不利于做为配置语法。 但这并非我在正常的情况下不用英文语法的原因，我在此提及是为了推翻像英文的语法不适合作配置语法的论点，当中央处理器和内存都变得便宜时，配置语法的简洁已不再是我们的目标，现在的情况是︰一个电脑语言中符合人性易于使用的重要性已超过节约电脑的计算资源。 然而还是有好几个地方要小心，其中之一是语法分析过程变得比较复杂的代价 ―― 你不会想把这个特点（使用像英文的配置语法）变成程序错误的来源及使用者的疑惑处。另一个是当我们要订出一个像英文的语言时，通常需要做些修改，表面上看起来修改过后的语法可重组出自然语言，但可能也会因修改过以致于和传统的配置语法一样，令人感到疑惑。（我们可以在许多所谓的第四代程序语言和商业用的数据库查询语言看到这个现象） Fetchmail 的控制语法看起来免除了这个问题，因为我严格地限制控制语法的范围，它不是一个以通用为目的的语言，它简单并不很复杂，所以在极小的英文子集和真正的控制语言之间的相混处很少，我认为这里还有一个更广义的教训︰ 格言16︰当你设计的语言没有一处是 Turing-complete，你可以采用比较平易的语法。 另有一个教训是关于含糊的保密性，有一些 fetchmail 的使用者要我修改程序，以把经保密处理的凭证储存于配置文件内，这样一来，偷窥者就没办法看到真正的密码了。 我并没有这么做，因为这个做法并不能达到真正的安全，能拿到读取你配置文件权限的人，也能以你的身份执行 fetchmail ―― 如果你的密码经保密处理存在配置文件中，他们可以由 fetchmail 中取得解码程序来得到你真正的密码。 如果我把程序改成可以在 fetchmail 的配置文件中储存保密的密码，那会给认为这并不难的人们对保密性的错误观念。一般的守则应该是: 格言17︰一个保密系统是否安全依存于它隐藏的秘密，注意不要有「虚拟秘密」。1 第十章 市集模式必要的条件 早先看过这篇文章的书评家和试读者都提出同样的问题，那就是以市集模式发展软件，获得成功的先决条件为何？包括项目领导人的资格，代码到什么样的程度，才对社群发布并开始成立协同发展团队。 相当明显的，任何人无法以市集模式建立软件基础2，但是可以用市集模式来测试，debug，改进软件，在一个项目的起始点很难运用市集模式，Linus 没试过，我也没有。项目初始的协同发展团队需要有一些东西可以测试，可以执行。 当你开始召募项目团队时，你必须能提出大致合理的保证，你的程序不需要运作得很好，它可以暴力，有错，不完整，及注释贫乏，只要它可以使潜在的协同开发者相信，这个程序在可预见的未来大有可为。 Linux 和 fetchmail 公开发布时都具有强健及吸引人的设计，许多人认为这和我所报告的市集模式有所不同，并以为这样的设计很重要，甚至进一步做出一个他们的结论 ―― 高度的设计直觉和聪明是一个项目领导人不可或缺的特质。 但是 Linus 的设计由 UNIX 而来，我的设计由原先的 popclient 而来（虽然它后来改变甚大，比例上说来还超过 Linux），所以市集模式项目的领导人或协调者真的需要格外的设计技巧？或者能提升别人的设计技巧呢？ 我想对于项目协调者是否能做出耀眼的设计并不重要，最重要的是协调者是否能认知别人在设计上的好点子。 Linux 和 fetchmail 都证明了这件事，Linus 这位仁兄如同之前所讨论的，他并不是伟大的创新设计师，但他展现了另一种卓越的技巧，即认同别人好的设计点子，且将这些好的设计整合到 Linux 的核心中。而我之前描述过 fetchmail 最有力的设计（藉 SMTP 转发邮件）也来自他人。...

本文同样适合没有技术背景的朋友阅读 遥想若干年前，今日头条和后来的抖音横空出世的时候，到处都可以看到关于他们推荐算法的讨论，个性化推荐对业务的重要性也被捧上了天。最近一年多，也算是亲身参与了一些推荐相关的项目，在实操之后，对这件事情也有一些自己的理解。 开门见山，我认为好的推荐系统，或者说个性化系统有三层特点，从底向上分别是： 有丰富的让用户感兴趣的物料 用户能够发现并表达兴趣 用户表达兴趣后能推荐高相关性的物料 就像一作金字塔。 1 首先是【有丰富的让用户感兴趣的物料】，这实际上是所有推荐系统的基础：物料要丰富且高质量。物料就是要推荐的东西，电商应用里是商品，内容应用里视频、图文，社区应用是达人，各不相同。如果物料不丰富，那实际上没有推荐的必要，小卖部一般没有导购，有啥东西一目了然。物料如果质量不高，那后面的工作也很难做，用户很难在这种系统中留存下来，也就会导致推荐系统的另一个重要燃料用户行为数据的不足。这块一般和算法没什么关系，但实际确是重中之重。大的生态系统治理其实更像经济学问题，解决的是供给和需求的关系。 {: .align-center style=“width:80%”} 京东平台在2015年就有两千多万件商品了，为推荐提供了舞台 {: .align-caption style=“text-align:center;font-size:smaller”} 2 接下来是【用户能够发现并表达兴趣】，这层开始跟算法有了一些关系，但更多还是通过产品和工程来解决。换比较专业的说法就是怎么做冷启动和试探。最理想的方法是把冷启动转变成热启动，例如说一个头条老用户来看抖音，好了，你在头条喜欢看啥我先给你看啥，大概率会比随机给你看点东西好。所以字节的产品矩阵在这方面就可以发挥很大的作用。但一般公司没这条件，那就只好尽量去挖可以用的先验信号，比如用户的地点、安装的app，甚至去爬其他的社交网络平台。 如果这条路走不通，那就只好试探了，产品没做好的话大概率是自身生态里什么热门就给你试探什么，这里总归是要碰点壁的。所以大部分产品上来会让你选一下你感兴趣的话题或者分类，作为用户，这时候可以直接点告诉他们，让这些系统更好地为自己服务。 {: .align-center style=“width:50%”} 常见的兴趣选择界面，让用户直接表达兴趣，顺利留存下来 {: .align-caption style=“text-align:center;font-size:smaller”} 还有些重要的用户表达兴趣的渠道，例如搜索。当一个系统的物料特别丰富，例如淘宝，什么东西都有，此时就很难试探，因为这个试探空间太大了。但好在买东西通常有目的性的，通常电商平台有50%的成交是搜索贡献的，用户会通过搜索功能来告诉平台自己想要什么。 所以一个好产品一定要打通各种用户表达兴趣的渠道，尽量避免瞎猜。 3 最后才是【用户表达兴趣后能推荐高相关性的物料】，也就是常说的推荐算法解决的问题。作为塔尖，它似乎吸引了最多的目光。举刚才搜索的例子，用户搜索“杯子”，ta已经表达了兴趣，你如果给他展示一堆碗，那肯定无法促成消费。 这方面算法很多，比较常见的比如各种协同滤波（买了杯子的人还会买啥？）以及现在流行的各种序列建模（每个月都买米这个月应该也会买米）等等。当系统往大了发展，我感觉工程的重要性又会超过算法：这么多的用户行为怎么存？这么多的训练数据怎么跑？虽然每年新结构、新网络层出不穷，但实际上常用的还是那几个经典的。以Criteo数据集为例，多年下来各种模型迭代导致的auc提升不到3个百分点（但不是说3%不重要，以大公司的体量还是很可观的）。但实际上推荐系统的发展早已不是这个数据集可以追踪的了，因为各个大公司特征、用户的规模早就不是这样了。 {: .align-center style=“width:80%”} Criteo数据集近年来的auc指标 {: .align-caption style=“text-align:center;font-size:smaller”} 前不久Tik Tok放出了他们推荐系统的论文，大量篇幅是在讲基础设施pipeline，模型部分这是个多年前的DeepFM。 小结 我感觉三个层次大致对应了【生意】-【产品】-【技术】，在这个互联网纷纷裁员的寒冬回过头看，确实这三个层次都出现了不同程度的停滞。不过一个时代过去总会有一个新的时代来临，技术应该是这三个里面停滞现象比较低的，相信在不久的将来就会有新的增长点。 以上就是我的一些想法，欢迎大家讨论。