精度混在型ベクトルデータベース「Chimera-VDB」を発明
── mdxを活用して機械学習向けストレージアーキテクチャーの研究をされているそうですね。
中村：ストレージとはデータの保管庫です。パソコンのハードディスクなどはストレージデバイスと呼ばれます。機械学習などの大規模な計算に用いられるストレージは、多数のストレージデバイスを結合して一つの大きなシステムにしたもので、「ストレージシステム」と呼ばれます。パソコン用に比べて容量が大きいだけでなく、求められる性能も異なります。特に機械学習の研究開発は日進月歩で、ストレージに求められる性能や要件も日々変化しています。私たちが今、開発を進めている「Chimera（キメラ）-VDB」は、ここ数年で急速に主流となったRAG（Retrieval-Augmented Generation）という機械学習分野での新しい応用手法の課題を解決するためのストレージ技術です。
── RAGとはどのような手法ですか。
中村：機械学習の一種である大規模言語モデル（LLM）は、インターネット上などに公開されている膨大な情報を学習して、さまざまな質問に答えることができます。ただし、例えば「わが社のB部で経理業務に詳しい社員は誰か？」といった質問には通常は答えられません。そのような社内情報は一般には公開されておらず、LLMは学習していないからです。
そこで、企業の人材や社内規程などの社内情報、業界の専門知識といったドメイン情報（特定分野の知識）をLLMに追加学習させる、「ファインチューニング」という手法が使われてきました。しかし、その学習には多大なコストと時間がかかります。
RAGは、ユーザーがLLMに質問をするたびに、質問に関連性の高い情報をデータベースから探し出し、LLMに提供する手法です。回答に必要なドメイン情報をRAGがLLMに“入れ知恵”し、LLMはその情報をもとに推論して回答するのです図1。
このRAGにはLLMにドメイン情報を追加学習させるコストや時間がかからないという利点があります。一方で、RAG用のデータベースでは、質問に関連する情報を検索するための索引情報（インデックス）が大量に生成されてしまい、ストレージ容量を圧迫するという課題があります。
図1 RAGとベクトルデータベースの役割
── RAG用のデータベースでは、なぜ索引情報が膨大になってしまうのですか。
中村：RAG用のデータベースは「ベクトルデータベース（VDB）」と呼ばれます図2。ユーザーの質問に関連性の高い情報を効率良く検索するために、情報同士の意味の近さ（類似度）を計算します。そのために、文章（自然言語）を分析し、文中に含まれる意味を「埋め込みベクトル」として数値化します。埋め込みベクトルでは、類似度の高い情報ほど近い位置に、類似度の低い情報ほど離れた位置にマッピングされます。例えば、「研究室では、……」と「……が、東北大学である。」は類似度が高く、それらと「パンケーキとは、……」は類似度が低くなります。こうした情報を、意味の近いものは近くに、意味の異なるものは遠くに配置して保存したものがベクトルデータベースです。
図2 RAG用のベクトルデータベース
中村：この埋め込みベクトルが索引情報となります。索引は1個当たり1000次元程度の数値データで構成されており、情報量が非常に大きくなります。それらの埋め込みベクトルを効率的に検索する方法として、「HNSW（Hierarchical Navigable Small World）」という技術が知られています。HNSWでは階層構造がつくられ、上層から下層へと検索を進めることで、必要な情報を探し出します。
例えば、社内B部の名簿を検索する場合を単純化して説明しましょう図3。上層L2には、社内規程や人に関する情報など、さまざまな情報の索引があります。その中から人に関する情報を選んで中層L1に下ると、そこには社内名簿や顧客名簿などがあります。さらに社内名簿を選んで下層L0へ下ると、A部・B部・C部の名簿があり、そこからB部の名簿にたどり着きます。ただし実際には、今述べたように各層がきれいに分類されているわけではありません。分かりやすさのために、あえて正確性を崩してデフォルメした説明をしています。
既存のベクトルデータベースは、典型的な例では全ての索引が1個当たり32ビット×1024次元の情報量を持つため、ドメイン情報が増えるにつれて索引情報の総量が増大します。名簿や社内規程などの情報本体よりも索引情報の方が大きくなり、ストレージ容量を圧迫してしまいます。これがRAGにおける大きな課題の一つです。
上層の索引は高精度、下層は低精度にしてストレージ容量を削減
── 索引情報が膨大となる課題をどのように解決したのですか。
中村：上層や中層の索引は1次元を32ビットの高精度のままにして、下層L0は1次元を16ビットや8ビットと低精度にすることで、ストレージ容量を削減します。それが私たちの提唱した「精度混在型ベクトルデータベース（Chimera-VDB）」です図3。
図3 精度混在型ベクトルデータベースの概念図
中村：B部の名簿を検索する場合、上層や中層の高精度な索引情報によって下層の社内名簿の領域まで正確にたどり着くことができます。そうすれば、A部・B部・C部の名簿の中からB部を選ぶ段階では、低精度の索引情報でも検索精度への影響は小さいと考えられます。
索引の個数は変えずに、下層では索引1個当たりの情報量を減らすのです。それでも目的の情報を探し出す精度が保たれるかどうか、私たちはmdxを用いた実験で、Chimera-VDBの有効性を検証しました。その実験結果の一例が図4です。
縦軸は、目的の情報を検索できたかどうかを示す再現率（正解率）です。100回検索して100回とも正解ならば100％＝1.0です。横軸はベクトルデータベースのストレージ容量で、右から左へと容量を減らしていきます。
索引1個当たりの情報量（精度）を各階層で変えない既存手法では、32ビットから8ビットへとストレージ容量を4分の1に削減すると、正解率が0.8（80％）と下がってしまいます。100回検索すると20回は間違えるようになったのです。一方、Chimera-VDBの異なる二つの手法（LB・HB）を実験したところ、4分の1に容量を削減しても正解率は90％以上となり、ほとんど低下しませんでした。
図4 mdxを用いたChimera-VDBの実験結果の一例
研究室の立ち上げと発展を支えたmdx
── なぜmdxを選んだのですか。
中村：私は20年ほど民間企業でストレージの研究開発を進め、2022年10月に東北大学に研究室を立ち上げました。当初は必要な計算環境が整っていませんでした。そこで、mdxを利用することにしました。企業にいたころは、自社で保有する計算機や民間クラウドを利用していましたが、mdxはそれらと同等の性能を備えており、利用コストが格段にリーズナブルです。mdxを利用することで、研究室の立ち上げ当初から研究を本格的に始めることができました。その後、メンバーが増えて計算資源を拡充する必要がありました。ハードウエアの調達には設置スペースの確保やさまざまな手続きが必要で、利用開始までに時間がかかります。一方、mdxならば利用メンバーの登録や資源量の増減を短時間かつ容易に行うことができるため、実際に使うかどうかをあまり気にせず、必要に応じて柔軟に利用できるので大変助かっています。
ストレージの新技術で機械学習の研究を進展させる
── 次に、複数のGPU計算機を効率良く使うためのストレージ研究について紹介してください。
根本：機械学習の研究は主にGPU計算機によって行われます。しかし、その需要に対してGPU計算機が不足しているのが現状です。1台のGPU計算機を使える時間も限られています。そこで近年は、ストレージを活用して広域のデータ共有を行うことにより複数のGPU計算機を利用するのが一般的になっています。空いているGPU計算機を渡り歩きながら計算をするのです。この広域のデータ共有に「オブジェクトストレージ」と呼ばれるクラウドストレージが使われます。例えば、一方のGPU計算機で途中まで計算した中間状態のデータをオブジェクトストレージに保存し、もう一方のGPU計算機でそのデータを取得して続きの計算を行う、といった使い方をします図5。
図5 複数のGPU計算機間でデータを受け渡すイメージ
根本：データのやりとりはインターネットを介して行います。機械学習では容量の大きなデータを扱うので、そのデータをGPU計算機からオブジェクトストレージにアップロードするには、かなりの時間がかかります。ところが現状では、アップロードが終わるまで次の計算に進めない仕組みです。オブジェクトストレージから保存完了の信号を受け取るまで、GPU計算機を使えない“待ち時間”となっているのです。私は、その待ち時間をなくして、GPU計算機を効率的に使えるようにする研究を、mdxを活用して始めました。
まずプログラムを書き直し、データのアップロード処理をシステムの裏側で並行して実行できるようにしました（非同期化）。これにより、アップロード処理の完了を待たずにGPU計算機で次の計算を進められるようになり、待ち時間を削減しました。
ただし、非同期化すると、データのアップロード処理が完了したかどうかをGPU計算機側では確認できません。そのため、データ保存完了を保証する仕組みの実現が新たな課題となっています。例えば、もう一方のGPU計算機は、中間状態のデータのオブジェクトストレージへの保存が完了したことを確認してから、そのデータを読み込んで続きの計算を始める、といった仕組みが必要なのです。そのための実験を、mdxを使って進めているところです。
── mdxの使い勝手はいかがですか。
根本：私はmdxのようなクラウド環境や仮想マシンの構築に関する知識はなかったのですが、mdxのテンプレートを使うことで、容易に実験を始めることができました。実験中にストレージの容量やGPUの数が足りなくなりそうな場合でも、パソコン画面を操作するだけで、計算資源をすぐに拡張できる点もとても便利です。
── ストレージ研究の魅力はどのような点でしょうか。
根本：複数のGPU計算機を効率良く使うためのストレージシステムを、できるだけ少ない計算資源で実現するためのアイデアを考え出すところが面白いですね。そのアイデアの有効性をすぐにmdxによる実験で検証して、改良していくことができます。
GPU計算機の不足は世界共通の課題です。大量のデータを複数のGPU計算機の間で受け渡して効率良く学習できるストレージシステムを構築できれば、機械学習の研究が大きく発展するきっかけとなるはずです。
今までにないストレージの仕組みを考え出しそれをmdxで検証しながら研究を進めています。
── 根本京次郎 氏
Chimera-VDBの実用化を企業と進める
── 最後に、Chimera-VDB研究の今後の展望をお教えください。
中村：Chimera-VDBの着想を得て、1年足らずでその有効性を確かめることができました。その検証実験は全てmdx上で完結できました。これほどスムーズに研究が進展したのも、mdxのおかげです。2026年度から、その研究成果に興味を持った民間企業と共同研究を始めています。
これまでは、RAGとベクトルデータベースによる実験で、Chimera-VDBによってストレージ容量を減らしても、質問に関連性の高いドメイン情報を見つけ出す正解率は、ほとんど下がらないことを実証できました。
次のステップでは、LLMと組み合わせた実験を計画しています。ストレージ容量を削減したChimera-VDBが検索したドメイン情報をLLMに提供した場合と、既存手法で検索したドメイン情報をLLMに提供した場合の回答を比較することで、Chimera-VDBの有効性をさらに検証し、実用化へとつなげていきたいと考えています。
mdxを活用することで、研究室の立ち上げから発展に合わせて計算資源を拡張して研究成果を生み出してきました。
── 中村隆喜 氏
取材・構成：立山 晃／フォトンクリエイト
撮影：吉田 号／STUDIO CAC
中村 隆喜 氏
根本 京次郎 氏
