在Hacker News上讨论。针对昨天关于Anthropic的Scion抄袭Mononoke的帖子，我收到了许多问题和关注点。这是我的后续回覆，回答主要问题。这确实是一次抄袭。我的帖子试图尽可能客观，考虑到我所知道的情况，尤其是对Mononoke的相似性主要是无意的，缺乏信誉是由于没有尽职调查。然而，在发布帖子后，我私下收到了确认，Scion故意而公然地抄袭了Mononoke，尤其是在人员重叠方面。这绝不是无意间的致敬。我对此有一种直觉，但由于我当时了解的情况，不敢这么说。相似性远不仅仅是派生数据的概念。一些人指出派生数据仅是索引，这是一个众所周知的概念。我想澄清的是，派生数据只是最显著的相似之处。其实相似之处要更深，包括整个数据模型，以及围绕它建立的许多结构。以下是Anthropic对Scion变更集的描述：Anthropic对Scion变更集的描述。Mononoke有相同的概念；我们称之为Bonsai变更集。在2022年的Oxide材料中，我是这样描述它们的：我描述Mononoke的Bonsai变更集。它们完全相同。甚至“Scion”这个名字也逆转了“Bonsai”的音节，并去掉了“B”！这可能是巧合，也可能不是。关于派生数据，我还想提请注意正在构建的索引类型，例如用于归责的索引。需要这样做是Bonsai数据模型的自然结果，因此需要构建索引并不令人惊讶；我提到的术语和框架之间的明显相似性确实是因为我们在我在Meta的源控制团队工作时是这样思考的。另一组相似之处体现在服务器端API中，用于执行版本控制查询和变更。这在Mononoke中已实现，但我相信在Mononoke之前的其他系统也有，所以我不会声称这是新颖的。但是如果你做的就是让Claude关注Mononoke并要求它重建，那你可能会设计出非常相似的东西。Bonsai数据模型是非常特立独行的。我想强调的是，源控制领域的主流认知是类似Git的数据模型。构建一个写前日志式的Merkle DAG在2018年相较于其他人所做的事情是非常远离的，并且需要解决几个困难的问题，比如如何执行服务器端的重基（根据我所知，这是Mononoke中的几个新算法之一）。在2018年我领导团队设计和实施该模型时，我个人必须向Meta的几个管理层说明这一点。跳级讨论系统的数据模型是非常罕见的。Bonsai数据模型也是极其成功的。到现在，几乎十年过去了，模型已经被大大扩展，且仍然在持续运行。构建它的团队努力仍然是我职业生涯中最自豪的成就之一。鉴于人员重叠，Scion团队绝对不可能不知道这些。（这也是他们合理抄袭的原因！）这引出了我的下一个观点：问题在于归属，而非抄袭。我在我的原始帖子中提到过这一点，但我完全愿意接受好点子被复制。我对于序列号被意外移除不满意，对于故意移除更是完全不满意。仅仅将“艰难获得的经验”归功于Sapling是不够的。几个人指出Mononoke是Sapling生态系统的一部分。这里的问题在于Sapling可以意味着VCS客户端（sl，最初是从hg分支出来的）或整个系统。如果你以前在Meta的源控制团队工作过，你绝对知道这两者的区别。而且，相似性远远超出了“艰难获得的经验”。Lore VCS可以声称获得了Mononoke的灵感，但它也在多个方面有所不同。Scion与Mononoke的相似度远超过此，单单将“艰难获得的经验”归功于Sapling（甚至不是Mononoke）是不诚实的。（而且，具体来说，我期待Scion变更集部分提到Bonsai变更集，即它们所抄袭的内容。）这使得Anthropic的成就显得大大不那么令人印象深刻。任何一个将分布式系统投入生产的人都知道，在生产过程中往往会出现多少问题。“我们的LLM构建了这个东西，投入生产，并在5个月内处理了所有相关挑战”是一个比“Meta的源控制团队花了10年时间构建和生产化这个系统，而我们能够指向我们的LLM并重建”更为引人注目的叙述。