我不是那種會對自己的作品產生強烈依戀的人。當我決定離開 Redis 時，大約是 1620 天前（約 4.44 年），之後我就再也沒有看過原始碼、commit 訊息，或任何與 Redis 相關的東西。偶爾需要用到 Redis 時，我就直接下載下來編譯。只要輸入「make」就行，看到多年之後建置 Redis 依然如此簡單，我感到非常開心。

這種抽離並不是因為我討厭過去的工作。長期下來，我的創造性工作越來越不重要，而「處理專案」這類事務卻越來越多——這是許多程式設計師能夠勝任的轉變，但那並不是我的專長——不過，離開的時候，我其實還是很享受做 Redis 相關的事。然而，我並不認同多數跟我同年齡（我現在 47 歲）的人所抱持的想法：覺得自己還年輕。我想做些新的事情，尤其是寫作。我想多陪陪家人，也想幫助親人。我確實需要休息一下。

然而，在那段「寫作的歲月」裡（順帶一提，我現在仍在寫作），我常常會回來寫程式，藉此在高強度的寫作之間喘口氣（寫作是我發現唯一比寫程式更耗費心力的腦力活動）：我做了幾個嵌入式專案；更深入玩了類神經網路；做了 Telegram 機器人：什麼都碰一點。隨興地 hacking 固然很酷，但長遠來看，我感覺自己缺乏一個真正的目標，而且每一天都越來越強烈地感到，我迫切想重新成為科技圈的一份子。同時，我也看到 Redis 社群正在分化，即使身為局外人，這也讓我有些擔憂。

於是我開始想，或許終究我能在 Redis 生態系中再次扮演某種角色。也許我有能力重塑公司對社群的態度。也許我甚至能幫忙讓 Redis 核心重新成為新開發的主要焦點。基本上，我可以擔任某種「evangelist（技術傳教士）」——我不太喜歡這個職稱，但……你懂我的意思——也就是一方面作為公司與社群之間的橋樑，同時也是能製作程式設計示範、發明並描述新的模式、撰寫關於新舊事物的文件、影片和部落格文章的人。那麼，新東西的設計呢？我可以從實際在外打拚的人們的工作中學習，從他們的困難中萃取精華，並回報設計想法，讓 Redis 得以演進。

在紐約的時光

有一次，我那現在 12 歲的女兒——她是我生命中至關重要的人，用她的聰慧、創造力和愛點亮我的每一天——想在生日時去紐約市走走。我們覺得，對，這畢竟是個好主意，最近我們度過了非常艱難的幾年，那麼，何樂而不為呢？我的女兒現在已經更像個少女，而不只是個孩子了。所以，在紐約時我想：也許現在正是時候，我可以找一份兼職工作。就在不久前，我在一次視訊通話中見到了 Redis 的新執行長 Rowan Trollope（羅恩·特羅洛普）。我感覺我可以和他一起合作，調整公司未來與社群的關係以及程式碼庫的發展方向。於是我寫了一封電子郵件給他說：你覺得我有沒有可能以某種身分回歸？羅恩·特羅洛普對我的提議表示了興趣，我們很快就達成了共識。

關於授權的轉換

人們會追問我*真正*為什麼這麼做，是否除了上面寫的之外還有其他內幕，是否有牽涉到什麼協議，或是一大筆錢；有什麼奇怪或不明朗的地方。但有時候事情就是很無聊：1. 是我主動聯繫公司，而不是相反。2. 我回歸並沒有拿到什麼天價報酬，並不是要利用什麼局勢——就是正常的薪水（不過，先聲明：是的，我跟以前一樣持有 Redis 的股票選擇權，不多也不少）。3. 我對 Redis 更改授權並沒有什麼太大的意見；具體來說，我並不認為與社群的裂痕*真的*是因為這件事。但既然大家一定會問我這個非常重要的問題，不如馬上把實情全部告訴你們。

授權的兩難

我幾乎一輩子都在寫開源軟體。然而，就像我是個無神論者，但看到別人信仰上帝、如果這能幫助他們度過人生的艱難，我仍會感到開心一樣，我也不認為開源是撰寫軟體的唯一方式。當初我在我身為兩位創辦人之一的公司背景下開始開發 Redis 時，我們的軟體程式碼是不公開的（Redis 之所以開源，是因為它被認為不是核心產品的一部分）。我們只是不希望我們的服務被別人抄襲，就這麼簡單。所以在這方面我並不是極端分子——我只在軟體設計上才會極端。

此外，我並不認為開放與授權就只有 OSI 所定義的那樣。我把授權看作是一個光譜，界定你能做與不能做的事。同時，我真的很擔心大型雲端服務供應商已經改變了系統軟體領域的誘因結構。Redis 並不是唯一一個更改授權的專案，它其實是……一大堆專案中的最後一個。我感覺近年來有許多專案甚至根本沒有啟動，就是因為缺乏清晰的潛在商業模式。所以，Redis 的授權轉換並不是我的決定，或許我會選擇不同的授權？我不確定，現在遠離現場多年、又沒有商業壓力，要重新爭辯實在太容易了。但整體而言，我能理解這個選擇。

再者，如果你讀過新的 Redis 授權，的確，它不是 BSD，但基本上只要你不是把 Redis 當作服務來販售，你就可以用跟以前非常相似的方式、享有相似的自由來使用它（我的意思是，你仍然可以修改 Redis、重新散布它、在你的營利公司中商業性地使用 Redis，免費使用，等等）。你*甚至*仍然可以把 Redis 當作服務來販售，如果你願意的話，只要你把所有的 orchestration systems（編排系統）都以同樣的授權釋出（這大概沒有人會真的這麼做，但這顯示了該授權的 copyleft（著佐權）作法）。授權條文本身幾乎跟 AGPL 一樣，只針對 SAAS（軟體即服務）相關的部分做了修改。所以，沒有通過 OSI 認可？是的，但我不太認同把 SSPL 稱為封閉授權。

你會說（我聽得到你的聲音）：真正的問題是有公司在掌控開源專案的方向！所以最終利益會越來越向公司靠攏，而越來越背離使用者群。我很感激外面有許多專案完全沒有公司的直接介入（頂多只有外部贊助），但你知道嗎？在許多大型專案中，公司的介入實際上反而減緩了這種偏離正軌的過程。在 Redis 的案例中，這正是發生的事。

軟體界的羅賓漢

讓我們回到過去，回到 Redis 最早的日子。

當 Redis 開始變得受歡迎時，我想找個方法繼續投入其中。這是在 VMware 提議贊助我的工作之前。我開始構思商業模式，猜猜怎麼著？那是以某種封閉原始碼產品的形式，某種程度上幫助人們運行 Redis。（令人驚訝的是，與這個想法相關的其中一個儲存庫至今仍在線上，顯示著 *15* 年前的 commit：https://github.com/antirez/redis-tools）

我當時打算嘗試某種 open core（開放核心）模式；我還記得我曾想過把新程式碼的 BSD 授權延後六個月釋出，以便為付費用戶創造某種優勢。現在回想，我不認為自己會那麼混蛋、去跟使用者玩什麼奇怪的把戲，但若不是靠 VMware，後來更廣泛地靠 Redis Labs，我也無法成為那個該死的開源軟體界的羅賓漢——被一家公司給予優渥的報酬，而目的不是為了公司本身的利益，而只是為了實現 Redis 社群的最大利益。我很確定，這比自己擁有一家公司還要更好的安排。

VMware，以及後來的 Redis Labs，付費支持的不只是我。如果你快速看一下儲存庫的貢獻紀錄，會看到歷來貢獻第二多的是 Oran Agra（奧蘭·阿格拉）（Redis），接著是 Pieter Noordhuis（彼得·諾德海斯）（VMware），依此類推。

所以基本上我認為，12 年來專注於使用者群所撰寫的 BSD 程式碼，是一筆很划算的交易，也是值得開心的事。而此刻對我而言，最重要的是，與社群的裂痕並不在於授權，至少主要不在於授權。事實上，新的授權反而能解決其中一部分問題：現在已經沒有誘因只把核心丟在維護模式，然後把新開發都放進模組裡。有了新的授權，雲端供應商就不能只是把 Redis 的程式碼庫剪下貼上拿去販售，卻完全不分享收益（這真的要求太多嗎？如果當初這麼做，或許就能避免你最近看到的所有授權轉換，不只是 Redis）。有了新的授權，焦點就能重新回到 Redis 核心，讓全世界的開發者手上擁有嶄新、令人興奮的功能。讓數十位獲得良好報酬的人，在 GitHub 儲存庫中推送實用、文件完善的變更。這也是我想幫公司做到的事情之一，我會盡力去做。我們需要讓授權的轉換對使用者群和功能產生正面的效果：這就是我的想法。

關於 AI、LLMs（大型語言模型）與 vector indexing（向量索引）

不過還有更多：Redis 開始對發展 vector capabilities（向量能力）產生興趣，整體而言也想支援你能用 AI 做的那類程式設計。現在，我每天都會看 Hacker News，看到大量技術人員討厭 AI 和新的發展。我也看到很多人甚至不在乎要深入嘗試最新的模型（提示：Claude AI 根本是獨一檔的存在），卻還是把它們貶為有點無用。對我來說則不同。我一直都很熱愛類神經網路。我在 2003 年寫了我的第一個 NN 函式庫，當時完全被這個概念的強大與酷炫所震撼。而現在，在 2024 年底，我終於在這個領域看到了驚人的成果，幾年前看起來像科幻小說的事情現在已經成為可能：最近 Claude AI 是我的思考／編輯／寫程式夥伴。我能完成的比過去多得多。我常常因為 AI 而做*更多的工作*，但我做得更好。最近我為一家義大利出版社寫了一篇科幻短篇小說，多虧 Claude 對其中部分內容的批評，我重寫了結局，產出了一部好得多的作品（我沒有讓 Claude 幫我寫故事或情節中的任何一行：善用 AI 並不是讓機器去做你能做得更好的事）。

昨天我需要評估把我的向量做 8 位元 quantization（量化）後，dot product（內積）運算能快多少；我告訴 Claude 我需要一個以特定方式設計的 benchmark（基準測試），兩分鐘後我就能測試它、修改它，並了解是否值得這麼做。基本上，AI 並沒有取代我，AI 加速了我，或透過對我工作的回饋讓我變得更好。而我相信（無論 RAG（檢索增強生成）的熱門程度如何，它未必是主要的應用，也不一定是最具未來性或最有用的，因為模型的 context 正變得越來越大，而且很快熱門模型的 attention 也許就會具備線性複雜度），抱歉離題了，我想說的是，我相信 learned embeddings（學習式嵌入）會留下來，而 vector search（向量搜尋）屬於 Redis 有幾個原因：首先是因為 vector indexes（向量索引）就是資料結構，特別是運算緩慢的資料結構，而這類資料結構在記憶體中運作得非常好。再來，是因為我認為我找到了最完美的 API 來呈現它們。

在設計 Redis 的過程中，我總是表現出一些矛盾的傾向。我總是準備好對某些看起來非常適合這個專案的東西說「不」（像是 named Lua scripts、hash fields expires，這兩者現在都是 Redis 的一部分，順帶一提），但同時我卻加入了 Lua scripting 能力——當時看起來簡直是瘋了，在 Redis 裡放一個直譯器？！——還有 Pub/Sub 能力，那看起來也格格不入，然後是 streams，還有甚至在電腦科學教科書裡不存在的合成資料結構，像是 sorted sets（有序集合）。因為對我而言，新功能是否適合放進 Redis，取決於兩件事：使用情境與內部設計的契合度。對我來說，Redis 是給程式設計師的樂高，而不是一個「產品」。

Vector sets（向量集合）

所以最近我開始思考，sorted sets 或許能啟發一種新的資料型別，其中 score 實際上是一個 vector。而在我與羅恩·特羅洛普洽談的同時，我開始撰寫一份設計文件，接著開始實作這個新資料結構的概念驗證，從頭重新實作 HNSWs（階層式可導航小世界）（而不是使用現有的函式庫，因為我想微調每一個細節），用 Redis 的方式，然後……我不確定這會如何收尾，我仍處於編碼的早期階段，但或許如果這個提案被接受，我可能會再次貢獻程式碼。我實作的模組（之後會合併到核心中——目前只是為了簡單起見先做成模組）實作了直接操作 embeddings（嵌入）全新指令。我先只給你們看一點作為預告：

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，所有顯而易見的東西。這完全就是 sorted sets 的概念，只是 score 是多維度的（embeddings！）並且是 K-NN 匹配。你覺得如何？當然，除此之外還有許多實作上的技巧來讓事情更有效率。但目前這還只是概念驗證的程式碼，讓我再多做一點。我正在實作 threading（多執行緒）、dimensionality reduction（降維）、quantization 等等，還有很多東西。老實說，相當有趣。

如你所見，這裡完全沒有提到 hybrid search（混合搜尋），這個關於 vector stores（向量資料庫）的近期流行詞彙。這又是 Redis 的風格：讓開發者保有主導權，自行決定取捨：畢竟他們才知道自己在建模什麼。每個 key 都有一個 vector index，就像程式設計師過去能用 sorted sets 做到的那樣，他們將會發明有趣的分割策略、新的結構描述、Lua 腳本、模式以及建模其使用情境所需的一切。

不過，雖然相關聯的項目通常可能只是一個小字串或一個文件 ID，但也沒有什麼能阻止它變得更複雜，帶有之後可以篩選的 metadata（中繼資料）（但我會忍住不這麼做）。我只是感覺，許多使用情境其實並不需要複雜的伺服器端篩選，透過預先對資料做分割就能建模。

我非常感興趣的是，未來可能加入的 STORE 選項，可以把結果儲存到一個 sorted set 中，而不是回傳給使用者，其中 score 當然就是相似度。這一切對於效率、可擴展性、使用腳本的能力等方面，也都有複雜而有趣的影響：我希望在接下來的幾週、幾個月內有機會能多談談這些。

好吧，好吧：回到這篇部落格文章的重點。但或許上面的內容才是*真正的*重點，擁有令人興奮的新想法。

所以，我回來了 🙂

說了這麼多，就是想說，我回來了。我想現在正是向多年來有所貢獻的整個 Redis 社群致上深深謝意的正確時機。期待再相見，希望這段旅程還能再增添些什麼。

附註：我在 BlueSky 上很活躍，如果你想追蹤這一切的後續發展。https://bsky.app/profile/antirez.bsky.social