写点什么

谷歌搅乱了 Python 社区?!20 多年的核心开发被逼离职,连 Python 之父都能被判定违规

  • 2024-09-15
    北京
  • 本文字数:7628 字

    阅读完需:约 25 分钟

大小:3.66M时长:21:18
谷歌搅乱了 Python 社区?!20多年的核心开发被逼离职,连 Python 之父都能被判定违规

核心开发人员突遭停职后,Python 社区陷入一片混乱

近日,Python 指导委员(SC)会突然公布一项处理意见,引发相关社区陷入一片混乱。处理意见称,将对某位未透露姓名的 Python 核心开发人员执行为期三个月的停职。

 

面对层层谜团,Tim Peters 主动承认他就是其中提到的开发人员,这也印证了不少社区成员的猜测。Peters 从 Python 立项早期就参与其中,曾负责过一系列重要工作,同时也是 PEP 20(《Python 之禅》)的作者。此番停职是因为其违反了项目行为准则,而这正源自 6 月中旬围绕 Python 软件基金会(PSF)章程开展的一系列颇具争议的变更讨论。

 


公告地址:https://policies.python.org/python.org/code-of-conduct/

 

不仅是 Peters 因违反社区准则被停职,就连著有“终身仁慈独裁者”的 Python 创立者 Guido van Rossum 的一篇文章也因违反 Python 社区准则而被删除。

 

这两次事件在 Python 社区中引起了激烈的反响。对于这两位为 Pyhon 语言做出过杰出贡献的开发者,社区中人难免感到意难平。

 

Hacker News 平台上的用户也对现在的 Python 社区文化展开了积极评论。有一些声音质疑所谓的“指导委员会”到底是谁,为什么他们的影响力比基本上创建了 Python 语言和 Python 社区的两个人更大?

 

据悉,Python 社区中指导委员会(Steering Council),它是 7 种治理方案中最晚被提出,但却最被采纳的一个,最终经过投票成为了社区里新的治理方案。该治理方案以 5 人组成的指导委员会作为最高决策层,并允许在必要的时候,将决策权委派给其它团队或开发者代表。

 

指导委员会拥有至高的权力,但它的行事原则是:通过设定一系列的基础性的、清晰的、灵活的、轻量的规则及流程,来“指导”社区的治理工作。

 

指导委员会可以直接行使某些权力,例如批准或驳回 PEP、更新项目的行为守则、跟软件基金会一同管理项目资产等等,然而,过分行驶权力的方式并不受鼓励。指导委员会与其它治理提案的关键区别就在于,它将扮演规则制定者的角色,指导、引导以及协调社区工作,只有在关键时候,才会行使最终的裁决权。指导委员会的职能是:

 

  • 维护 Python 语言及 CPython 解释器的质量与稳定性

  • 尽可能使做贡献是便利的、包容的与可持续的

  • 巩固核心团队与 Python 软件基金会的关系

  • 为 PEP 建立恰当的决策流程

  • 为贡献者与核心团队寻求共识

  • 当其它所有方法都失败时扮演“最终裁决法庭”的角色

 

这个治理模式是借鉴自 Django 项目。

 

指导委员会的固定成员是 5 人,且最多允许两人来自同一家企业。换届频率是每个 Python 发行版本。成员可连任。支持不信任投票(即弹劾)。

 

第一届当选的成员包括:

 

  • Barry Warsaw:自 1995 年起成为核心开发者之一,荣获 2014 年的弗兰克·威利森纪念奖。

  • Brett Cannon:自 2003 年起成为核心开发者之一,荣获 2016 年的弗兰克·威利森纪念奖。曾担任 Python 软件基金会的执行副主席。

  • Carol Willing:Python 核心开发者,Jupyter 核心开发者及 Jupyter 的指导委员会成员。自由职业,兴趣在于科研及教育项目。

  • Guido van Rossum:Python 的创始人,被称为“Python 之父”,长期领导 Python 社区的发展。

  • Nick Coghlan:自 2005 年起成为核心开发者之一。

 

而现在的指导委员会成员包括:

 

  • Gregory P. Smith:Python 生态系统的领导者、CPython 的核心贡献者,曾在谷歌的语言、优化和库团队工作。但据一位谷歌前员工透露,Gregory P. Smith 当时在谷歌主要从事行政工作,这位前员工也猜测他就是 Tim Peters 的事件的主要煽动者。

 


Gregory P. Smith

 

  • Emily Morehouse:Python 核心开发者、软件开发公司 Cuttlesoft 的联合创始人兼工程总监。

 


 Emily Morehouse

 

  • Pablo Galindo Salgado:Python 核心开发者、指导委员会成员以及 Python 3.10 和 3.11 版本的发布经理。

 


 Pablo Galindo Salgado

 

  • Barry Warsaw:Python 核心开发者,深耕 Python 语言长达 30 年。今年刚入职英伟达公司,担任开源 Python 生态系统首席系统软件工程师。

 


 Barry Warsaw

 

  • Thomas Wouter:Python 生态系统的领导者,20 多年 Python 开发经验,过去曾担任 Python 软件基金会的董事,Python 3.12 和 3.13 的发布经理。 他曾是谷歌的一名软件工程师,是维护 CPython 和内部 Python 基础架构的团队的一员。

 

这五位指导委员会成员中,有两位成员来自于谷歌,所以有 Hacker News 用户发表评论认为,他们把谷歌内部严格的审查制度带到了社区中:

 

“这就是当今谷歌员工掌权时发生的事情。他们已经习惯了谷歌的审查制度被强行塞进他们的喉咙,以至于他们到哪都认为这样做是很正常的。”

 

也有声音认为,Python 社区走到如今的地步,核心问题是技术人员和管理者之间在理念上有着不可调和的矛盾:

 

“这个世界并不公平。无论人们是谁,他们的命运都是由政治力量决定的。

 

多年来,我看到一些非常挑剔的人,甚至挑剔的团队被集体解雇,然后被不那么好的人取代。世界继续前进。产品和项目会遭受一段时间的打击,很多时候甚至会完全消亡。但这就是当权者想要的,他们也可以接受。

 

我的经验告诉我,除非现在更换整个领导层,否则 Tim 在那里不会得到多少尊重(即使他回来了)。我可以告诉你,其他人也会受到同样程度的不尊重和公然侮辱。一旦出现了有毒的管理/领导层,你唯一的选择就是离开,去其他尊重他人的地方工作。

 

我确信他们的基金会赚了很多钱。他们必须以某种方式出现才能继续赚更多的钱。当涉及到大笔资金时,他们不会关心谁是重要的或他们有多重要,他们很可能会赚大钱

 

这是大多数科技公司政治等级制度的标准演进弧线。一旦产品成功,利润源源不断。管理层接管。决定不再需要工程师,不尊重员工。赶走优秀人才。毒害整个文化,继续榨取更多钱财。最终,这种制度消亡,他们去下一家公司榨取下一磅肉。”

 

而更多 Hacker News 用户则担心 Python 语言正在走下坡路,这样对于很多基于 Python 语言来构建的项目来说简直是灭顶之灾,并建议人们选择一种更安全的语言:

 

“读到这些让我真的很担心长期支持任何基于 Python 构建的东西。这给人一种自我毁灭的垂死社区的印象。与 Rust 和 Go 相比,Python 会消亡吗?在代码完成领域,新语言似乎是一个安全的选择,比如是 Rust。”

 

为什么开发者会有如此多的不满和担忧,从 Tim Peters 被辞退事件似乎可以窥探出一些端倪。

完整事件回溯

条款变更争议

拟议的章程变更显然是在非公开的 PSF 邮件列表(psf-vote)上进行,但相关内容几乎同时被发布到了 Python 论坛的 PSF 频道当中。三项变更中只有一项在论坛上引发了大量讨论,内容为改变 PSF 研究员因违反行为准则而遭免职的具体方式。所谓 PSF 研究员同样属于社区成员,他们“凭借对于 Python、社区乃至更广泛的 Python 生态系统的非凡贡献和影响”而倍受尊敬。

 

提案公告的重点在于免除研究员身份。原则上讲,研究员将获得终身 PSF 成员资格,但变更后的条款约定“一旦违反基金会任何书面政策,特别是我们的行为准则”,那么任何 PSF 成员均可被免职。提案的措辞甚至不要求 PSF 成员(包括全体研究员)以三分之二多数同意来免除成员,而只需要 PSF 董事会的多数票赞成。根据 7 月中旬发布的公告内容所指出,对于章程的所有三项变更均轻松通过,只是存在争议的修改条款获得的支持率明显低于其他两项。

 

Peters 等人提出的主要反对理由,是认为设置的简单多数这一门槛太低;曾有 12 年董事会成员经历的 Peters 主张,既然几乎所有董事会决议都要求一致通过,那么在罢免研究员方面同样要求董事会成员一致通过(或者至少三分之二通过)才是合理的。会议对这项变更展开了多个角度的长时间讨论,也涉及到为何部分成员认为简单多数票可能并不合适,特别是在无力阻止未来 PSF 董事会内部出现某些恶意倾向的情况。其他人则认为这样的预期太过极端。

 

在讨论过程中,有相当多的人支持这项变更,但反对(或者至少是质疑)变更者则一直在积极发帖游说。最终董事会成员 Christopher Neugebauer 敲下定音一锤,称对于拟议变更做出任何修改都涉及组织问题,因此增加通过票数的提议需要等到一年后的下届董事会选举期间再行讨论。

 

其实人们似乎都同意应当有一种方法允许董事会罢免研究员;即使没有此番变更,董事会也会利用其现有权力将其他类型的成员除名,只是研究员一直拥有自己的“免死金牌”。部分讨论参与者认为绝对多数(例如三分之二)的主意可能更好,但可以通过之后的修正案来解决;目前,最好有一种方法既能够罢免行为不端的研究员,又不必在全体 PSF 成员中进行公开投票。整个对话持续了大约两周,相当帖子多达 175 个,内容虽然普遍较长但讨论氛围仍相当友好,并没有激发宣泄性或者被愤怒情绪主导的互喷。而且这种分歧也没什么特别,毕竟多年以来不管是在邮件列表还是其他地方,Python 社区中从来不乏这样的公开争论。

 

Peters 一直是该主题讨论的积极参与者,可能是过于热心,他开始在另开一帖讨论关于 PSF 董事会就这些变更收到的法律建议及相关想法。讨论内容相当庞杂,经常会朝着多个方向发展,其中不少则迅速偏离主题。也有些帖子被读者们标记,导致其被 Discourse 论坛软件暂时隐藏,这反过来又导致人们抱怨说反对意见受到了压制。最终,一位版主将讨论调为慢速模式,希望能引导讨论重新回归正轨。

 

在讨论的最后阶段,Neugebauer 发布了董事会的常见问题解答,具体回应了讨论中提出的各种问题。虽然没有、也不适合把话挑明,但从常见问题解答的内容来看,人们似乎隐隐感到董事会正在考虑要开除掉一部分研究员。讨论中有一股暗流开始涌动,矛头指向那些通过研究员身份与 PSF 挂钩、可能来自非 Python 领域且违反了行为准则的成员。指导委员会成员 Thomas Wouters 表示,他已经看到“有充分证明表明,实际上部分研究员一再藐视行为准则。”在另一个“案例中”,Alan Vezina 也概述了一种违反行为准则的场景,虽然细节源自假设,但“同样基于真实事件”。

指导委员会声明

7 月 11 日,在关于拟议变更的讨论逐渐平息之后,Gregory P. Smith 发布了一份指导委员会声明,题为《期待 Python 领域的沟通更具包容性》。文章称在此番讨论当中:

 

……我们目睹了一些令人不安且不专业的对话,涉及多位知名人士。这些评论导致社区内的许多成员彼此疏远,也妨碍了其他人加入并成为 Python 未来生态的一部分。

 

接下来列举的,则是一系列明显直接针对 Peters 的事例。实际上,第三条提到的“抵制软行为审核”明显就在 Peters 身上刚刚发生过,只是没有成功。根据 Peters 本人在随后帖子中的说明,有人私下联系他并对其行为进行质询,但他并不认可这些投诉。发布的这份声明似乎是指导委员会在施以“反击”,对 Peters 在“讨论行为准则的过程中”拒不配合的行为表示警告,称一意孤行将面临后果。从回复来看,Peters 也对此表示认可。

 

除了对指导委员会要求他自查发帖表示抵制之外,文章列出的另外两个例子则不是特别令人信服,至少 Peters 本人和其他回复者对此并不认可。第一条是“在举例中提及性骚扰,轻视职场性骚扰培训”,这里显然指的是他发布的一篇谴责职场性骚扰处理方式的帖子。这但这种说法跟第二个例子中“使用表情符号和措辞的方式,可能会被不同的人误解甚至形成完全相反的理解”相矛盾,因为 Peters 在前面的帖子中确实使用了“眨眼”表情符号——这个表情符号经常出现在他的帖子中,代表一种反讽或者说“懂的都懂”的态度。问题的真正关键,很可能包含在第二个例子的余下部分中:

 

在发帖时请注意,你的受众是一个更加广泛且多样化的专业社区,而不再是几十年前由一小群内部人士发展而来的 Python 生态。一些曾在过往很常见的不当沟通方式,可能在当下引发不适宜的争议。

 

可以想见,Peters 再次长篇大论对文章做出回应;不少其他社区成员同样积极跟帖,表示既理解指导委员会的立场、也支持 Peters 的观点。指导委员会在措辞问题上明显吃了个瘪,选择的例子没能给自己的立场带来任何助益。然而,委员会和整个 Python 社区明显下定了改变旧习气的决心。有人认为之前的那些习惯正在阻止更多人加入项目,而指导委员会则成为阻止这种情况的最终仲裁方。Peters 可能对此也没有太大异议,毕竟他自己就是这些旧习气的典型代表。

 

但从深层分析,人们对于行为准则及其落地方式同样存在着普遍分歧。指导委员会在声明中指出:

 

当有人抱怨你之前说的话有问题时,请学会倾听。这不是在寻求辩论,而是一种源自痛苦感受的表达。这时候不妨先停下来,反思一下到底发生了什么。

 

但 Peters 和其他人则担心,在缺乏“理性人”这一基本前提的情况下,这样的倾向性很容易歪向另一个极端。Peters 指出,有“好几位 PSF 成员”都担心行为准则会毁掉自己的职业生涯,因为这可能阻止他们充分参与到项目中来。与此同时,对于此类投诉也应该有双向的沟通渠道。“当有人发现指导委员会的行为或者言论越界时,也同样是一种源自痛苦感受的表达。”

 

Smith 表示,声明中列出的例子都直接来自社区成员的投诉:

 

他们不需要向任何人解释,他们对于某些事物的解释为什么跟你不同。最重要的是要意识到每个人都有自己的解释角度。正确的做法应该是相信他们、接受不同观点,并从中吸取教训。别总试图告诉对方他们错了。

 

他还表示,那些面临行为准则处罚的人对于这种情况负有全部责任。因为单单一次投诉不太可能导致被从项目中除名;相反,只有反复出现“不尊重行为”,再加上被指出问题时无法或者不愿意“学习和改进”才会面临罢免。虽然该声明并非针对特定一人,但 Peters 明显“是其中重要的一环”,指导委员会甚至私下联系他讨论过此事。

 

而 Peters 的态度也很坚决,他感谢指导委员会能跟他主动联系,但他并不认同对方的观点:

 

最初表达的担忧是我“对性骚扰问题不够严肃”。我回答说,任何理性人都不会这样理解我的表达。委员会方面没有回复,而是接下来直接发表了一篇公开帖子,并在其中将措施修改为我“轻视职场性骚扰培训”。这同样是一种令人难以置信的解读,只是比之前的说法稍微好了一点点。

 

……我决定放弃,因为一旦健康网已成,那我再怎么辩驳都是徒劳。就像一个人决定要生气,那怒火也就随之而来。

 

Brendan Barnwell 则担心,根据“审核团队/指导委员会/PSF 董事会的评论基调”,整个决策流程基本可以总结为:“如果 A 做了某事,而 B 认为这令人反感,那么 A 必须自动(或者默认)接受自己错了。”他表示,这在很大程度上是在歪曲“尊重不同观点和经验”的行为准则。有时候,所谓“受到冒犯”的 B 也需要重新考虑自己的理解到底对不对。

 

与 Barnwell 一样,另外几位社区成员也抱怨指导委员会声明中举的例子非常牵强,大家看了之后仍然不知道该怎么避免此类问题。Karl Knechtel、Chris McDonough(与 Peters 一样身为 PSF 研究员)和用户“Paddy3118”还特别讨论了其中的措辞问题。Smith 给出的解释是指导委员会认为声明中不宜讲得太具体,但人们普遍认为这里举的措辞例子根本不值一驳。

突遭停职

总而言之,虽然 Peters 收到了好几次不同的警告,但他并没有改变自己的行为。他继续发帖,开始可能引发争议的讨论,并参与了两个关于成员退出 Python 讨论论坛的话题。总而言之,他基本依然我行我素。其中一篇“我要离开”的帖子来自前 PSF 主席、董事会成员兼名誉研究员 Steve Holden,另一篇则来自 Knechtel。后面这篇帖子成功让 Knechtel 本人被论坛无限期封禁,但不知是 Knechtel 本人还是版主进行了编辑,目前帖子内容有点难以理解。几乎在同一时间,同样被论坛无限期封禁的前董事会成员 David Mertz 也许是被 Knechtel 的遭遇激起了冲动情绪,主动放弃了自己的 PSF 研究员身份。

 

因此在持续关注事态走向的人们看来,指导委员会于 8 月 7 日暂停 Peters 核心开发者资格三个月的结果似乎并不令人意外。该公告由 Wouters 发布,主要引用了行为准则工作组的建议,建议中具体列出了十条内容。可以想见,这些内容不太可能说服那些认为 Peters 遭受到不公对待的成员——实际情况甚至恰恰相反,公告中并没有特别提及 Peters,只是在第一条中明确提到“过度讨论章程变更(截至版主关闭讨论时,参与主题下总计 177 篇帖子中的 47 篇),这造成了一种恐惧、不确定及怀疑的氛围,引发其他社区成员做出越来越激烈的情绪化反应。”这份清单在很大程度上成为一道分水岭:一部分人对其表示赞同,而另一部分人则出于种种原因认为其有失偏颇。

 

指导委员会成员 Emily Morehouse 指出,关于对特定行为准则的违反判断往往非常困难,声明中的清单仅用于介绍违规行为:

 

这不是社区第一次在缺少特定事件或判断的前提下对违规行为定性。在我看来,行为清单并非导致停职的个别极端行为集合,而是在尝试总结出一种共通性质的沟通模式,这种沟通模式已经越界并对我们社区中的多位成员造成了伤害。

 

……对于一般违规行为,我也希望能有一种方法可以向整个社区勾勒出事件的全貌,但这对上报问题的人和被停职的人来说都不公平。我已经听到对此的反馈意见,很多成员都希望我们未来的项目沟通和运作流程能够有所改进。

 

在各种帖子(包括其他未被提及的帖子)中,人们也表达了对审核制度的担忧。这些担忧的具体表现包括发新帖抗议,还有向版主群发送私信,其中不少的语气也不太友好——甚至直接就是赤裸裸的辱骂。这使得版主对于批评意见很敏感,反而加剧了对此类帖子的审核力度,这又进一步导致更多人认为审核过度问题正在失控。另外,不少社区成员本来就认为审核是 Python 世界中当权者(包括指导委员会和 PSF 董事会)的管辖工具,因此在章程变更讨论之类存在争议的帖子中发起审核,只会延续这种互相攻讦的恶性循环。

 

对任何社区来说,审核都是一项艰巨而且吃力不讨好的工作。尝试对人类不当行为划定严格的边界永远充满了风险,往往导致版主总是在一部分受众眼中被视为“错误”。归根结底,Peters 必须意识到他的沟通风格在 Python 世界中并不受欢迎,而摆在面前的只有两条路:要么调整沟通方式,要么退出走人。后一条路肯定是我们不希望看到的,毕竟他的大部分发帖都实用、有趣且有所帮助,或者是其中一些优点的随机组合,并不至于越过、甚至都没有贴近过任何行为“边界”。

 

不过就目前的情况看,Peters 在三个月的停职期后能否重新回归还是个未知数。在以往的案例中,被停职者需要向指导委员会提出复职申请。而对于像他这种身处争议中心的人,申请恐怕没那么容易得到通过。甚至已经有人开始做好 Peters 彻底离去的心理准备。Serhiy Storchaka 曾询问是否可以联系 Peters 寻求技术方面的帮助,Wouters 则暗示称不鼓励这样做;Storchaka 为此还专门强调,他并不是想绕过指导委员会的决定,只是咨询能否继续通过 GitHub 与 Peters 合作。与此同时,在关于指导委员会选举投票系统的变更讨论帖中,Guido van Rossum 表示他认识的投票系统专家被封禁了:“也许我们可以等到他三个月禁令到期之后,再向他寻求建议?”

 

目前尚不清楚这一切将导致怎样的结果,我们也将持续关注事态发展。总而言之,相信很多人都希望曾一手打造 Timsort 等产品的 Peters,能够顺利回归他 30 多年前协助建立的这片繁荣社区。

 

参考链接:

https://lwn.net/SubscriberLink/988894/337f36ff39e6342f/

https://chrismcdonough.substack.com/p/the-shameful-defenestration-of-tim

https://news.ycombinator.com/item?id=41385546

 

2024-09-15 14:0011759
用户头像
李冬梅 加V:busulishang4668

发布了 939 篇内容, 共 531.3 次阅读, 收获喜欢 1102 次。

关注

评论

发布
暂无评论
发现更多内容

挑战海量数据:基于Apache DolphinScheduler对千亿级数据应用实践

白鲸开源

大数据任务调度 任务调度 dophinscheduler 大数据调度

SchedulX V1.7.0更新,规格压测、成本洞察等重磅功能发布!

星汉未来

云原生 降本增效 星汉未来

技术解读:现代化工具链在大规模 C++ 项目中的运用 | 龙蜥技术

OpenAnolis小助手

c++ 开源 龙蜥技术 优化技术 ThinLTO

阿里高工携18位架构师耗时两个月整合1000页的Java岗面试八股文

程序知音

Java 架构 java面试 后端技术 Java面试八股文

企业集成方案

久歌

企业架构 企业集成

公司合同管理软件有哪些?

优秀

合同管理软件

明道云伙伴大会2022/秋,免费门票限量领

明道云

低代码 零代码 aPaaS

融云 uni-app 原生插件,生态丰富、高效集成

融云 RongCloud

sdk 集成 uri app

IT人士必须警惕这9个信号:说明你的IT架构很糟糕

雨果

数据管理工具 数据服务平台

5分钟,带你创建一个智能电梯检测器模型

华为云开发者联盟

物联网 华为云 iotda 智慧电梯 企业号十月 PK 榜

别按部就班的背面试题了!吃透这份Java面试核心知识手册,大环境不好Offer也能拿到手软!

Java全栈架构师

程序员 面试 程序人生 架构师 Java后端

驱动企业数字化转型 低代码平台需要具备哪些能力?

力软低代码开发平台

阿里云块存储团队卓越工程实践

阿里技术

经验分享 语言 & 开发

如何使用华为云IoT平台实现远程控制无人机,资深物联网从业者手把书一步一步教你!

wljslmz

物联网 IoT 无人机 华为云 10月月更

【Nacos源码之配置管理 十】客户端长轮询监听服务端变更数据

石臻臻的杂货铺

nacos 10月月更

用了这个API协作调试工具,忘记了postman

Liam

Postman 接口调试 开放api API接口 API调试

十大 CI/CD 安全风险(二)

SEAL安全

DevOps CI/CD DevSecOps CI/CD管道 软件供应链安全

数字化转型案例解读:德意志银行数字化转型背后的故事

雨果

数字化转型

Flowable 任务如何认领,回退?

江南一点雨

Java springboot workflow flowable JavaEE

网易数帆数据治理2.0实践分享

网易数帆

大数据 数据中台 数据治理 数据质量 企业号十月 PK 榜

【Nacos源码之配置管理 十一】服务端LongPollingService推送变更数据到客户端

石臻臻的杂货铺

nacos 10月月更

Python进阶(十二)浅谈python中的方法

No Silver Bullet

Python 方法 10月月更

Gartner:被CIO们忽略的7个颠覆性趋势

雨果

CIO

专利解析|混合缓存技术在元年多维库中的应用

元年技术洞察

数据分析 多维数据库

爆火的RPA尚在初期阶段,拥挤的赛道厂商如何突围?

ToB行业头条

有人想用开源工具DBT取代 SQL,你同意吗?

雨果

sql

String、StringBuffer、StringBuilder的区别

zarmnosaj

10月月更

什么是深度学习?人工智能能影响未来的特点之一

Finovy Cloud

人工智能 深度学习

JFrog Xray 与 Amazon Security Hub 集成

亚马逊云科技 (Amazon Web Services)

安全 DevSecOps

什么是数字体验平台(DXP)?

Baklib

客户体验 数字体验

向量数据库是如何检索的?基于 Feder 的 IVF_FLAT 可视化实现

Zilliz

人工智能 可视化 向量检索 anns 以图搜图

谷歌搅乱了 Python 社区?!20多年的核心开发被逼离职,连 Python 之父都能被判定违规_编程语言_李冬梅_InfoQ精选文章