我不是那种会对自己的作品产生强烈依恋的人。大约1620天前（约4.44年）决定离开Redis后，我就再也没有看过Redis的源代码、提交记录或任何与之相关的东西。偶尔需要用到Redis时，我只是下载下来编译一下。敲一下“make”，看到多年过去构建Redis依然如此简单，我就感到很开心。

这种抽离并非因为我厌恶过去的工作。长远来看，我的创造性工作越来越不重要，而“打理项目”方面的事务却越来越多——很多程序员能够适应这种转变，但这并不是我擅长的事——不过，离开的时候我依然享受做Redis相关的工作。只是，我并不认同大多数与我同龄人（我现在47岁）所持的看法：觉得自己还年轻。我想做些新的事情，尤其是写作。我想多陪陪家人，帮帮亲人。我确实需要休息一下。

不过，在“写作的几年里”（顺便说一句，我现在仍在写作），我也时常会回去写代码，把它当作高强度写作间隙的休息方式（写作是我发现的唯一一种比编程要费神得多的脑力活动）：我做了几个嵌入式项目，多玩了玩神经网络，做了些Telegram机器人，什么都尝试了一点。随性地捣鼓很有意思，但时间一长，我感觉自己缺少一个真正的目标，每天都更迫切地想要重新投身于技术世界。与此同时，我也看到Redis社区正在分裂，即便作为一个旁观者，这也让我有些担忧。

于是我开始想，或许我可以在Redis生态中重新扮演一个角色。也许我能够重塑公司对待社区的态度。甚至或许我还能帮助让Redis核心重新成为新功能开发的主要焦点。基本上，我可以做某种“布道者”（我不太喜欢这个称呼，不过……你懂我的意思），一方面在公司和社区之间架起桥梁，另一方面也能做编程演示、发明并阐述新的模式，为新旧功能撰写文档、视频和博客文章。那么，新功能的设计呢？我可以从一线人们的实践和他们遇到的困难中学习，提炼总结，再将设计思路反馈回去，推动Redis的发展。

在纽约的时光

有段时间，我那现在12岁的女儿——她是我生命中至关重要的人，用她的聪慧、创造力和爱照亮了我的每一天——想在生日时去纽约看看。我们觉得，是啊，这主意不错，反正最近几年我们经历了几段非常艰难的时光，为什么不呢？我的女儿如今已经更像是个少女，而不只是个孩子了。于是在纽约时我想：也许现在正是时候，我可以找一份兼职。就在不久前，我通过视频通话见了Redis的新任CEO Rowan Trollope。我感觉我可以和他一起，调整公司与社区关系的未来走向以及代码库的发展方向。于是我给他写了封邮件问：你觉得我有没有可能以某种身份回归？Rowan对我的提议表现出了兴趣，我们很快就达成了共识。

关于许可变更

人们会追问我*到底*为什么这么做，背后是否还有上文之外的故事，是否有某种协议，或是一大笔钱，是否有蹊跷或不明之处。但有时候事情就是很平淡：1. 是我主动联系的公司，而不是相反。2. 我回归并没有拿到离谱的报酬，不是为了利用某种局面——就是正常的薪水（不过要声明一下：是的，我和以前一样持有Redis的股票期权，不多也不少）。3. 我对Redis更换许可证并没有太大意见；具体来说，我并不认为与社区的分裂*真的*是因为这件事。但既然大家会问起这个非常重要的问题，还是立刻把真相全部告诉你们比较好。

许可的两难

我几乎一生都在写开源软件。然而，就像我是个无神论者，却依然会为看到别人信仰上帝而感到高兴——如果这能帮助他们度过人生的艰难——我也不认为开源是编写软件的唯一方式。当初我在自己作为两位创始人之一的公司里开始开发Redis时，我们的软件代码是闭源的（Redis之所以开源，是因为它被认为不属于核心产品）。我们只是不想让别人抄袭我们的服务，就这么简单。所以在这方面我不是极端主义者——我只在软件设计上才算极端。

而且，我不认为开放和许可仅仅就是OSI所定义的那样。我把许可看作一个关于你能做什么、不能做什么的光谱。同时，我真的很担忧大型云服务商已经改变了系统软件领域的激励机制。Redis不是唯一一个更换许可证的项目，实际上它是……一大堆项目中最后一个这么做的。我感觉近年来许多项目甚至根本没有启动，就是因为缺乏清晰的潜在商业模式。所以，Redis更换许可证不是我的决定，也许我会选择不同的许可证？我不确定，现在远离一线多年、又没有商业压力，再去翻旧账太容易了。但总的来说，我能理解这个选择。

而且，如果你读过新的Redis许可证，当然，它不是BSD，但基本上只要你不是把Redis作为服务来出售，你就能以与以往非常相似的方式、享有相似的自由来使用它（我的意思是，你仍然可以修改Redis、再分发，在你的营利性公司里免费商用等等）。你*甚至*仍然可以把Redis作为服务来卖，只要你把所有的编排系统都以同样的许可证开源（这大概没人会真的去做，但这体现了该许可证的copyleft思路）。许可证的措辞几乎与AGPL相同，只是针对SaaS部分做了修改。所以，没有得到OSI认可？是的，但我很难把SSPL称作闭源许可证。

你会说（我能听见）：真正的问题是有公司在控制开源项目的方向！这样一来，利益最终会越来越向公司倾斜，而越来越偏离用户群体。我很感激外面有许多完全没有公司直接参与（除了外部赞助）的项目，但话说回来，你知道吗？在许多大型项目中，公司的参与实际上减缓了这种偏离正轨的过程。在Redis的案例中，肯定就是如此。

软件界的罗宾汉

让我们回到过去，回到Redis最初的日子。

当Redis开始流行起来时，我想找一种能继续全职投入其中的方式。那还是在VMware提出赞助我的工作之前。我开始琢磨商业模式，猜猜是什么？是以闭源产品的形式，多少能在某些方面帮助人们运行Redis。（令人惊讶的是，与这个想法相关的一个仓库至今仍在线，还能看到*15*年前的提交记录：https://github.com/antirez/redis-tools）

我当时打算尝试某种开放核心模式；我还记得曾想过把新代码的BSD许可延迟六个月，以此为付费用户创造某种优势。现在我不认为自己会那么刻薄、去跟用户玩什么花样，但如果没有VMware，之后更主要的是Redis Labs的资助，我也不可能成为后来的样子：一个开源软件界该死的罗宾汉——拿着公司优厚的报酬，却不是为了公司的利益，而是只为Redis社区的最佳利益服务。我确信，这比自己开一家公司要好得多。

VMware，后来的Redis Labs，资助的不仅仅是我。如果你快速浏览一下仓库的贡献历史，会看到历史贡献第二的是Oran Agra（Redis），然后是Pieter Noordhuis（VMware），以此类推。

所以基本上我认为，12年里只专注于用户群体、用BSD许可证编写的代码，是一笔很划算的交易，也是值得高兴的事。而现在对我来说最重要的是，与社区的分裂并非关于许可，至少主要不是因为许可。实际上，新的许可证反而能解决其中的一部分问题：现在已经没有动力再把核心丢进维护模式、把新功能都塞进模块里了。有了新许可证，云服务商不能再直接复制粘贴Redis代码库拿去售卖却不进行任何收入分成（这要求真的过分吗？如果当初能这样，或许就能避免近来你看到的所有许可证变更，而不仅仅是Redis）。有了新许可证，焦点可以重新回到Redis核心上，让全世界的开发者都能用上新的、令人兴奋的功能。让几十位获得合理报酬的人，在GitHub仓库中推送有用且文档完善的改动。这也是我想帮助公司实现的事情之一，我会尽力去做。我们需要让这次许可变更对用户群体和功能产生积极的影响：这就是我的想法。

关于AI、大语言模型与向量索引

但还有更多：Redis正开始关注向量能力的发展，以及更广义上对AI相关编程的支持。现在，我每天都会看Hacker News，看到大量技术人员不喜欢AI和这些新进展。我也看到很多人甚至懒得去深入尝试最新的模型（提示：Claude AI独树一帜），却依然将其贬为有点没用。对我来说则不同。我一直热爱神经网络。我在2003年就写了自己的第一个神经网络库，当时就被这个概念的强大与酷炫深深震撼。而现在，到了2024年底，我终于在这个领域看到了惊人的成果，几年前还像是科幻小说的东西如今已成为现实：最近Claude AI成了我的思考/编辑/编程伙伴。我能完成比过去多得多的事情。我常常因为AI而*做更多的工作*，但也做得更好。最近我为一家意大利出版社写了一篇科幻短篇，多亏Claude对其中部分内容的批评，我重写了结尾，作品也变得好多了（我没有让Claude写故事或情节中的任何一行：对AI的绝佳运用，不是让机器去做你能做得更好的事）。

昨天我需要评估对向量做8位量化后点积计算能快多少；我告诉Claude我需要一个按特定方式设计的基准测试，两分钟后我就能测试、修改它，并判断这是否值得。基本上，AI没有取代我，而是加速了我，或是通过对我工作的反馈让我变得更好。我相信（不管RAG有多流行，它未必是主要应用，也不一定最具未来性或最有用，因为模型的上下文正变得越来越大，很快主流模型的注意力机制可能就会达到线性复杂度），抱歉有些跑题了，我是想说，我相信学得的嵌入会长久存在，而向量搜索属于Redis，原因有几个：首先因为向量索引就是数据结构，尤其是很慢的数据结构，而这类数据结构在内存中可以表现得非常好。还有，因为我觉得我找到了暴露它们的完美API。

在设计Redis的过程中，我一直表现出一些矛盾的倾向。我总是准备对某些看似与项目完美契合的东西说“不”（比如命名Lua脚本、哈希字段过期——顺便说一句，这两者现在都已是Redis的一部分），但与此同时，我又加入了Lua脚本能力——当时看起来简直疯了，Redis里放个解释器？！——还有看似格格不入的发布/订阅功能，然后是streams，甚至还有计算机科学教科书里根本不存在的合成数据结构，比如有序集合。因为对我而言，新功能是否适合Redis取决于两点：用例，以及与内部设计的契合度。在我看来，Redis是给程序员的乐高，而不是一个“产品”。

向量集合

所以最近我开始思考，有序集合或许可以启发一种新的数据类型，其中的分数实际上是一个向量。在与Rowan洽谈期间，我开始撰写设计文档，然后着手为这种新数据结构实现一个概念验证，从零开始重写HNSW（而不是使用现成的库，因为我想对每个细节都进行调优），用Redis的方式来做，嗯，我不确定最终会如何，目前仍处于编码的早期阶段，但如果这个提案被接受，或许我又会开始贡献代码了。我实现的这个模块（之后会合并进核心——目前为了简单起见先做成模块）实现了直接操作嵌入的新命令。我就先给你看一点作为预告：

VSIM top_1000_movies_imdb ELE "The Matrix"  WITHSCORES
 1) "The Matrix"
 2) "0.9999999403953552"
 3) "Ex Machina"
 4) "0.8680362105369568"
 5) "Akira"
 6) "0.8635441958904266"
 7) "District 9"
 8) "0.8631418347358704"
 9) "The Martian"
10) "0.8608670234680176"
11) "The Bourne Ultimatum"
12) "0.8599717319011688"
13) "The Bourne Supremacy"
14) "0.8591427505016327"
15) "Blade Runner"
16) "0.8585404753684998"
17) "Metropolis"
18) "0.8572960793972015"
19) "Inception"
20) "0.8521313071250916"

所以你有了VSIM、VADD、VCARD，所有显而易见的命令。这完全就是有序集合的思路，只不过分数是多维的（嵌入！），匹配方式是K近邻。你觉得怎么样？当然，除此之外还有许多实现上的技巧来让它更高效。但目前还只是概念验证代码，让我再多打磨一下。我正在实现多线程、降维、量化以及更多功能。说实话，挺有意思的。

如你所见，这里没有提到混合搜索这个关于向量数据库的最新流行词。这又是Redis的方式：让开发者拥有主动权，自行权衡取舍——毕竟他们最清楚自己在建模什么。每个键对应一个向量索引，就像程序员们过去用有序集合所做的那样，他们会发明出有趣的拆分策略、新的模式、Lua脚本、各种模式以及建模用例所需的一切。

当然，通常关联的条目可能是一个小字符串或文档ID，但也没什么能阻止它变得更复杂、带有可供后续过滤的元数据（不过我会克制一下）。我只是觉得，许多用例其实并不需要复杂的服务端过滤，通过预先对数据分区就能建模。

让我非常感兴趣的是，可能会加入一个STORE选项，将结果存入一个有序集合而不是直接返回给用户，分数当然就是相似度。所有这些对效率、可扩展性、使用脚本的能力等方面也会产生复杂而有趣的影响：我希望在接下来的几周和几个月里有机会和大家多聊聊这些。

好了，好了：回到这篇博文的主题。但也许上面的这些才是*真正的*重点——拥有令人兴奋的新想法。

所以，我回来了 🙂

说了这么多，就是想说，我回来了。我想现在正是向多年来做出贡献的整个Redis社区郑重道谢的好时机。回头见，希望这段旅程还能再添上些什么。

附言：我在BlueSky上很活跃，如果你想关注这一切的进展。https://bsky.app/profile/antirez.bsky.social