僕は自分の仕事に強い執着を抱くタイプではない。Redisを離れると決めたのは約1620日前（約4.44年前）のことだが、それ以来、ソースコードもコミットメッセージも、Redisに関することは一切見てこなかった。たまにRedisが必要になったときは、ただダウンロードしてコンパイルするだけだった。「make」と打つだけで、数年経ってもビルドがあれほどシンプルなままだったのが、とても嬉しかった。

この距離感は、過去の仕事を嫌いになったからではない。長い目で見れば、創造的な作業の比重はどんどん小さくなり、「プロジェクトの運営」的な活動がますます大きくなっていった――多くのプログラマーはその変化に対応できるが、僕にとっては本業ではない――それでも、去るときでさえRedisの仕事自体は楽しんでいた。ただ、僕は同年代の多くの人が抱いている「自分はまだ若い」という感覚を共有していない（今47歳だ）。新しいことをやりたかった、特に執筆を。家族ともっと一緒に過ごし、身近な人たちの力になりたかった。何より、休みが必要だった。

とはいえ「執筆の数年間」（ちなみに今も書き続けている）、激しい執筆の合間の息抜きとして、よくコーディングに戻っていた（執筆は、コーディングよりもはるかに頭を使う唯一の知的活動だと感じている）。組み込みのプロジェクトをいくつかやったり、ニューラルネットワークで遊んだり、Telegramのボットを作ったりと、とにかくいろいろ手を出した。気ままにハックするのは楽しかったが、長い目で見ると、何か本当の目的が欠けている感覚があり、日ごとにテックの世界にまた関わりたいという切迫感が強くなっていった。同時に、外から見ていても、Redisコミュニティが分断されていくのを感じ、少し心配になっていた。

だから、もしかしたら自分はRedisのエコシステムにまた役割を持てるのではないか、と考え始めた。会社のコミュニティに対する姿勢を変えられるかもしれない。Redisコアを再び新機能開発の中心に戻す手助けができるかもしれない。ざっくり言えば、ある種の「エバンジェリスト」（この肩書きはあまり好きではないが……まあ、言いたいことはわかるだろう）として、一方では会社とコミュニティの橋渡しをしつつ、プログラミングのデモを作ったり、新しいパターンを考案して解説したり、新旧の事柄についてドキュメントや動画、ブログ記事を書いたりする。では、新しいものの設計はどうだろう？ 現場の人々の仕事や、その困難から学び、それを蒸留して設計アイデアとしてフィードバックし、Redisを進化させることができるかもしれない。

ニューヨークでの時間

あるとき、今12歳で、僕の人生でかけがえのない存在であり、知性と創造性と愛で日々を照らしてくれる娘が、誕生日にニューヨークを訪れたいと言い出した。最近2年ほど本当に大変な時期があったし、これはいいアイデアだ、せっかくだから行こう、ということになった。娘はもう「子ども」というより「少女」になっている。そこでニューヨークにいる間に、もしかしたら今がちょうどいいタイミングかもしれない、パートタイムの仕事ができるかもしれない、と思った。ごく最近、ビデオ通話でRedisの新しいCEO、Rowan Trollopeに会った。彼となら、コミュニティとの関係やコードベースの方向性といった、会社の未来を調整していけそうな気がした。そこで彼にメールを書いた。「何らかの形で戻ることはできないだろうか？」と。Rowanは僕の提案に興味を示し、すぐに合意に至った。

ライセンス変更について

人はきっと、なぜ僕が*本当に*こうしたのか、上に書いたこと以外に裏話があるのではないか、何か取り決めや大金が絡んでいるのではないか、と詮索するだろう。何か胡散臭いところや、はっきりしないところがあるのではないか、と。だが、物事は時にとても退屈なものだ。1. 会社に連絡したのは僕のほうで、逆ではない。2. 復帰にあたって法外な金をもらっているわけではない。状況を利用しようという話でもない――普通の給与だ（ただし断っておくと、以前と同じようにRedisのストックオプションは持っている。それ以上でもそれ以下でもない）。3. Redisのライセンス変更について、僕は大きな問題を感じていない。特に、コミュニティとの亀裂は*本当のところ*ライセンスが原因ではないと思っている。ただ、この非常に重要な件について人から聞かれるだろうから、今すぐすべて正直に話しておいた方がいい。

ライセンスのジレンマ

僕は人生のほぼすべてでオープンソースソフトウェアを書いてきた。それでも、僕は無神論者だが、神を信じることが人々の困難を生き抜く助けになるなら、それを見て嬉しく思うのと同じように、オープンソースだけがソフトウェアを書く唯一の方法だとは思っていない。Redisの開発を始めたとき、それは僕が二人の創業者の一人だった会社の中でのことだったが、その会社ではソフトウェアのコードは非公開にしていた（Redisはコアプロダクトではないとみなされたためオープンにされた）。単純に、自分たちのサービスを他者にコピーされたくなかったのだ。だからこの点で僕は原理主義者ではない――原理主義的なのはソフトウェア設計についてだけだ。

さらに、オープンさやライセンスがOSIの言うことだけだとは思っていない。ライセンスとは、何ができて何ができないかというスペクトルのことだと見ている。同時に、大手クラウドプロバイダーがシステムソフトウェアの領域におけるインセンティブを変えてしまったことを、本当に懸念している。ライセンスを変更したのはRedisだけではない、むしろ大きな山の中で最後の一つだった……というのが実情だ。ここ数年、明確なビジネスモデルの見込みがないために、そもそも始まらなかったプロジェクトがたくさんあるという感覚もある。Redisのライセンス変更は僕の決定ではなく、もし自分なら別のライセンスを選んでいただろうか？ 正直わからない。何年も現場から離れ、ビジネス上のプレッシャーもない今、後からあれこれ論じ直すのは簡単すぎる。ただ、全体的にはその選択は理解できる。

さらに、新しいRedisのライセンスを読めば、確かにBSDではないが、Redisをサービスとして販売しない限り、基本的に以前と非常に似た形で、似た自由度をもって使える（つまり、Redisを改変したり、再配布したり、営利企業で商用利用したりといったことを、依然として無料でできるということだ）。*さらに*、望むなら今でもRedisをサービスとして販売することすらできる。ただし、その場合はすべてのオーケストレーションシステムを同じライセンスで公開しなければならない（誰も実際にはやらないだろうが、これはこのライセンスのコピーレフト的なアプローチを示している）。ライセンスの文言は、SaaSに関する部分の変更を除けば、ほぼAGPLと同じだ。だからOSI承認ではないのか？ 確かにそうだが、SSPLをクローズドなライセンスと呼ぶことには違和感がある。

君はこう言うだろう（その声が聞こえる）：本当の問題は、企業がOSSプロジェクトの方向性を支配していることだ！ 結局、利害は企業寄りになり、ユーザーベースからは離れていく、と。企業の直接的な関与が（外部のスポンサーシップを除けば）ゼロのプロジェクトがたくさんあることには感謝しているが、でも、こういうことだ。多くの大規模プロジェクトでは、むしろ企業の関与が、正しい道から逸れていくプロセスを遅らせることもあるのだ。Redisの場合は、確実にそうだった。

ソフトウェアのロビン・フッド

ここで少し過去に飛んで、Redisの初期の頃に戻ってみよう。

Redisが人気を集め始めたとき、僕はそれに携わり続ける方法を見つけたいと思っていた。VMwareが僕の仕事をスポンサーすると申し出る前のことだ。ビジネスモデルというアイデアをもてあそび始めたのだが、さて何だったと思う？ それはRedisの運用を何らかの形で手助けするような、クローズドソースのプロダクトという形だったのだ。（驚くことに、このアイデアに関連するリポジトリの一つは今もオンラインで、*15*年前のコミットが残っている：https://github.com/antirez/redis-tools）

僕はオープンコア的なアプローチを試そうとしていたし、新しいコードのBSDライセンス適用を6か月遅らせることで、有料ユーザーに何らかの優位性を持たせようかとも考えていたのを覚えている。今となっては、ユーザーを相手に嫌な奴になって変な駆け引きをするとは思わないが、VMwareのおかげ、そして後にさらに本格的にRedis Labsのおかげでなれたような存在にはなれなかっただろう。つまり、企業から十分な報酬を得ながら、その企業の利益のためではなく、ひたすらRedisコミュニティの最善の利益のためだけに働くという、オープンソースソフトウェアのいわばロビン・フッドのような存在だ。これは自分の会社を持つよりも良い形だと、確信している。

VMware、そして後のRedis Labsが支払っていたのは、僕に対してだけではない。リポジトリのコントリビューション履歴をざっと見れば、歴代2位のコントリビューターがOran Agra（Redis）で、次がPieter Noordhuis（VMware）といった具合に続いているのがわかる。

だから基本的に、ユーザーベースだけに焦点を当てて書かれた12年間のBSDコードというのは良い取引だったと思うし、それは喜ぶべきことだ。そして今の僕にとって最も重要なのは、コミュニティとの亀裂はライセンスの問題ではない、少なくとも主にはそうではないということだ。むしろ新しいライセンスは、その一部を解決しうる。コアをただメンテナンスモードに置いたまま、新機能をモジュールにだけ入れるというインセンティブが、もはやなくなるからだ。新しいライセンスのもとでは、クラウドプロバイダーはもはやRedisのコードベースを切り貼りして、収益分配なしに販売することはできない（これは本当に求めすぎだったのだろうか？ これがあれば、Redisだけでなく、最近見られたライセンス変更のすべてを防げたかもしれない）。新しいライセンスによって、スポットライトは再びRedisコアに戻り、世界中の開発者の手に、新しくエキサイティングな機能が渡る。GitHubリポジトリで、十分な報酬を得た何十人もの人々が、有用でよく文書化された変更をプッシュする。僕が会社を手助けしたいことの一つもそこにあり、精一杯やるつもりだ。ライセンス変更がユーザーベースと機能に良い影響をもたらすようにする必要がある――それが僕の考えだ。

AI、LLM、そしてベクトルインデックスについて

だが、話はそれだけではない。Redisはベクトル機能の開発や、広く言えばAIでできるようなプログラミングをサポートすることに関心を寄せ始めている。僕は毎日のようにHacker Newsを読んでいるが、AIやその新しい展開を嫌う技術者が非常に多いのを目にする。利用可能な最新モデルをまともに深く試そうともせず（ヒント：Claude AIは別格だ）、それでも「たいして役に立たない」と切り捨てる人もたくさん見かける。僕にとっては違う。僕はずっとニューラルネットワークが大好きだった。初めてNNライブラリを書いたのは2003年で、そのコンセプトがいかに強力でクールかということに完全に衝撃を受けた。そして今、2024年末になって、ようやくこの分野で信じられない成果を目の当たりにしている。数年前にはSFのように思えたことが、今では可能になっているのだ。最近、Claude AIは僕の思考や編集、コーディングのパートナーだ。以前よりもはるかに多くのことを成し遂げられるようになった。AIのおかげで*より多くの仕事*をこなすことも多いが、より良い仕事をしている。最近、イタリアの出版社向けにSFの短編を書いたときも、Claudeが部分的に批評してくれたおかげで結末を書き直し、はるかに良い作品にすることができた（物語やプロットのたった一行すらClaudeには書かせていない。AIの素晴らしい使い方は、機械に自分より上手くできることをやらせることではないのだ）。

昨日も、ベクトルの8ビット量子化で内積の計算がどれだけ速くなるかを評価する必要があった。Claudeに特定のやり方で設計したベンチマークが必要だと伝えたら、2分後にはそれをテストし、修正し、それがやる価値があるかどうかを理解できた。基本的に、AIは僕を置き換えたのではなく、僕を加速させたり、仕事へのフィードバックで僕を向上させたりしたのだ。そして僕はこう信じている（RAGの人気とは関係なく、それは必ずしも主要なアプリケーションでも、最も将来性がある、あるいは有用なものでもない。モデルのコンテキストはどんどん大きくなっており、やがて普及しているモデルのアテンションは線形の計算量になるかもしれないのだから――脱線してすまない）、言いたかったのは、学習された埋め込みは定着するだろうし、ベクトル検索はいくつかの理由でRedisに属するものだということだ。第一に、ベクトルインデックスはデータ構造であり、とりわけ遅いデータ構造であり、そのようなデータ構造はインメモリで非常によく機能するからだ。そして、僕はそれらを公開するのに完璧なAPIを見つけたと思うからでもある。

Redisの設計に携わっていた間、僕はいつも矛盾した傾向を示してきた。プロジェクトにぴったり合うように見えるある種のものに対しては、いつでも「ノー」と言う用意があった（名前付きLuaスクリプトやハッシュフィールドの有効期限など――ちなみに今ではどちらもRedisの一部になっている）が、同時に、Luaスクリプティング機能――当時は正気かと思われた、Redisの中にインタプリタだって？――や、場違いに見えたPub/Sub機能、さらにはストリーム、そしてソート済みセットのような計算機科学の教科書には存在しない合成的なデータ構造まで追加してきた。僕にとって、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近傍（K-NN）マッチを行うというものだ。どう思うだろうか？ もちろん、その上に効率化のための実装上の工夫もいろいろある。ただ今はまだ概念実証のコードなので、もう少し取り組ませてほしい。スレッディングや次元削減、量子化など、さらに多くのことを実装しているところだ。正直、とても楽しい。

お気づきの通り、最近のベクトルストアに関するバズワードであるハイブリッド検索については触れていない。これもまたRedisらしいやり方だ。開発者に役割を持たせ、トレードオフを自分で決めさせる。結局、自分が何をモデル化しているのかを一番よく知っているのは彼らなのだから。キーごとに一つのベクトルインデックスがあり、プログラマーがソート済みセットでやってきたように、彼らは面白い分割戦略や新しいスキーマ、Luaスクリプト、パターンなど、ユースケースをモデル化するために必要なあらゆるものを考案するだろう。

とはいえ、通常、関連付けられるアイテムは小さな文字列やドキュメントIDになるだろうが、それが後でフィルタリング可能なメタデータを持つ、より複雑なものであることを妨げるものは何もない（ただ、そこは僕はこらえるつもりだ）。多くのユースケースでは、複雑なサーバーサイドのフィルタリングは実際には必要なく、データを事前にパーティショニングすることでモデル化できるという感覚を、僕は持っている。

僕が大きな関心を持って見ているのは、結果をユーザーに返すのではなくソート済みセットに格納するという、STOREオプションの追加の可能性だ。もちろん、スコアは類似度になる。これらすべては、効率性やスケーラビリティ、スクリプティングの利用可能性などにも、複雑で興味深い影響を与える。今後数週間から数か月のうちに、このことについてもっと話す機会が持てることを願っている。

おっと、話をこのブログ投稿の本題に戻そう。だが、もしかすると上記のことこそが*本当の*要点なのかもしれない。ワクワクするような新しいアイデアがあるということ自体が。

というわけで、戻ってきました 🙂

要するに、僕は戻ってきたということだ。今こそ、これまでRedisコミュニティが成し遂げてきたことに、大きな感謝を伝えるべき時だと思う。また会おう、この旅にまだ付け加えられることがあると願っている。

P.S. BlueSkyで活動しているので、もしこうした動きを追いたければフォローしてほしい。https://bsky.app/profile/antirez.bsky.social