XGBoostをNVIDIAのKumo Relationalに替える前に、答えが分かっている予測1つで試す
NVIDIAは、Kumo Relationalが専用の学習なしでXGBoostを上回ると述べています。同じ顧客と基準日で、運用中の予測を試す4つの手順。
XGBoost(多数の決定木を順に連ねる機械学習ライブラリ)で「30日以内に再購入しない顧客」を予測するモデルは、たいてい人が手で作った集計列、たとえば「30日間の平均注文額」の上で動いています。2026年10月21日、NVIDIAはHugging Face(AIモデルを共有するプラットフォーム)にKumo Relationalを紹介する記事を公開しました。同社は、このモデルが複数テーブルのデータベースから専用の学習なしに直接予測でき、その種のパイプライン(列を作り、学習し、モデルを動かす一連の工程)を上回ると述べています。この数字は、置き換えを話し合う前に、チームがすでに運用している予測を1つ選び、次の4つの手順で試すのが妥当です。
NVIDIAがKumo Relationalについて述べていること
NVIDIAによれば、Kumo Relationalはリレーショナルデータ向けの基盤モデル(foundation model、一度学習しておき多くの用途に使い回すモデル)です。リレーショナルデータとは、外部キーで結ばれた複数のテーブルに入っているデータで、顧客が注文に、注文が商品につながります。同社は、このモデルが事前学習を完全に合成リレーショナルデータだけで行ったと書いています。予測時には最大10,000件の過去の例を文脈として読み、1回の実行で結果を返します。これは文脈内学習(in-context learning)と呼ばれ、課題ごとに再学習するのではなく、予測の瞬間に例を見る方式です。予測したい内容はPQL(Predictive Query Language、予測用クエリ言語)で書きます。NVIDIAのサンプルにある PREDICT COUNT(orders.*, 0, 30, days) FOR EACH users.user_id は、各顧客の今後30日間の注文数を予測する一文です。
同社が示す結果は、事前学習で一度も見せていない15のデータベースにまたがる41のタスクで測ったものです。
- RelBench V1(リレーショナルデータの機械学習向けの共通ベンチマーク)の分類タスクでは、Kumo Relationalは専門家が設計した特徴量を使う勾配ブースティング木(gradient-boosted trees、決定木を順に積み上げる手法)を、平均でほぼ4 AUROCポイント上回ります。AUROCは、離脱する人を残る人より上位に並べられるかを測る指標で、0.5は当て推量、1は完全に正しい並びです。
- SAP SALT(SAPの企業データ向けベンチマーク)では、設計済みの特徴量を使うXGBoostを、そのままの状態で7 MRRポイント、ファインチューニング後は13ポイント上回ります。MRR(mean reciprocal rank、平均逆順位)は、正解が候補リストのk番目にあれば1/kと数えます。
- RelArena-αのリーダーボードについて、NVIDIAはKumo Relationalが1,000サンプルあたり約17秒だと述べています。最高得点のrt-plurelはわずかに高い得点(1,878対1,842)ですが約7,300秒かかり、およそ430倍遅いとのことです。
コードはApache 2.0ライセンス、モデルの重みはOpenMDW License Agreementバージョン1.1の下にあります。実行にはNVIDIAのstructured-data-modelsライブラリを使い、GPU(グラフィックス処理装置、AIモデルを動かすのに使うチップ)が必要です。あるいはNVIDIA NIM(モデルを別のサービスとして動かし、呼び出して使うためのNVIDIAのパッケージ)として動かせます。これらはNVIDIAと論文の著者が公表した結果であり、記事は第三者が独立に再現したとは述べていません。
同社自身が挙げている限界
同じ記事でNVIDIAは、このモデルが意味のある関係と時間的な変化を持つデータ、たとえばユーザー行動で最もよく働くと書いています。学習データが非常に大きいタスクでは、そのタスク専用に学習したモデルのほうがわずかに上回ることがあります。同社の測定では、モデルが読む例が最大10,000件だったためです。予測の手がかりも、限られた回数のテーブル結合の範囲に収まっている必要があるため、同社は関連するいくつかのテーブルに絞ったクエリから始め、徐々に広げることを勧めています。この3点が、下の手順1と手順4を決めます。
自分たちの予測で試す4つの手順
この例の店舗にある顧客テーブルと注文テーブルは、この記事が説明のために作ったものです。4つの手順は、まだどのシステムでも実行されていません。
-
実際の結果が出ている、運用中の予測を1つ選ぶ。 すでにモデルがあり、正解が分かっている課題が必要です。たとえば「日付Tの後30日以内に顧客が購入するか」です。Tの後に30日を超える結果が揃うよう、十分に前の日付を選びます。顧客テーブルと注文テーブルの2つから始めます。
-
まさにその課題のPQLクエリを書く。 上の例なら、前に示したNVIDIAのサンプルの一文が使えます。文脈となる例は、Tより前の期間からだけ集めます。
-
現在のモデルが予測したのと同じ顧客で実行する。 同じ基準日Tと同じ顧客の集合を使います。NVIDIAは2つの実行方法を示しています。
- NVIDIA NIM経由:
pip install 'structured-data-models-client[relational]'でクライアントを入れ、usersテーブルとordersテーブルをpandas DataFrame(Pythonの表形式データ)として手順2のPQLと一緒に渡し、client.predict(...)を呼びます。記事によれば、クライアントが文脈となる例と関連テーブルを自分で集めてNIMにリクエストを送ります。自分のNIMのアドレスはsdm_client.SDMClient(url=...)に入れます。 - GPUのあるマシンでライブラリを直接動かす:
pip install structured-data-modelsの後、sdm.models.KumoRelational(device="cuda")を使います。この場合は文脈用の例のテーブルと予測したい顧客を自分で渡すので、実行前に各テーブルを絞り込み、T以降のタイムスタンプを持つ行が1つもない状態にしてください。
NVIDIAは、同社のツールが将来のデータの漏れを防ぐために基準日より前のデータだけを残すと述べていますが、テーブルを自分で結合する場合は自分で確認する必要があります。返ってくるのは、予測を求めた集合の各user_idに対する予測値1つです。手順4の指標を計算するため、user_idで正解と突き合わせます。NVIDIAのサンプルノートブック:relational.ipynb。
- NVIDIA NIM経由:
-
チームがすでに使っている指標で現在のモデルと比べる。 古いモデルの指標とKumo Relationalの指標を、同じ顧客について2つ記録し、実行時間とGPUのコストも書き留めます。実行する前に、パイプラインを変える価値があると見なす差をチームで決めておきます。Kumo Relationalが同等か下回る場合、または結果が不自然によい場合は、まず手順3に戻り、T以降の行が紛れ込んでいないかを調べます。テーブルに数百万行の学習データがあるなら、NVIDIAが触れているファインチューニング版を試すか、従来のパイプラインを維持します。予測の手がかりがテーブル結合を何回も経た先にあるなら、渡すテーブルを徐々に広げてもう一度実行します。
参考にした情報源
- NVIDIA, “NVIDIA Kumo Relational Outperforms Supervised Machine Learning on Relational Data, No Training Required”(Hugging Face Blog、2026年10月21日):モデルの紹介、RelBench、SAP SALT、RelArena-αでの結果、同社が挙げる限界、実行方法とライセンス。
- NVIDIA, クイックスタートノートブック relational.ipynb(GitHub):structured-data-models-clientでKumo Relationalを動かすサンプルノートブック。Hugging Faceの記事からリンクされています。