0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Yushi88(使える最新テック)

リレーショナルDBを「グラフ」として読むAI — KumoRFMはなぜ学習なしで予測できるのか

0
Posted at

Kumoが公開した解説記事は、Stanfordの調査を引用しながら、ある顧客が今後90日で注文をやめるかを予測するのに、データサイエンティストは平均12.3時間、878行のコードを費やしてきたと紹介している。米Kumo.aiが開発した KumoRFM(Relational Foundation Model) は、この工程を「PQL(Predictive Query Language)」という1行の問いに置き換える。企業のリレーショナルデータベース(relational database)を入力に取り、タスクごとの再学習をせずに予測を返す基盤モデル(foundation model、汎用の学習済みモデル)だ。2026年6月、NVIDIAがKumo.aiを買収したと報じられ、開発チームはNVIDIAへ合流した。

特徴量エンジニアリングが、密かに捨てていたもの

なぜ12.3時間もかかっていたのか。原因は特徴量エンジニアリング(feature engineering)にある。「過去90日の購入回数」のような変数を人手で設計し、1枚の表に平坦化(flatten)してからモデルに渡す作業だ。タスクが変わるたびにやり直しになるうえ、平坦化の過程で時系列の並びやテーブルのつながり(グラフ構造)という手がかりが失われる。単一テーブル中心のTabPFNと異なり、KumoRFMは外部キー関係を崩さず扱う。

DBを「グラフ」に読み替える――行はノード、外部キーはエッジ

KumoRFMは、リレーショナルDBを グラフ表現(graph representation) に読み替える。エクセルの複数シートを1つに潰さず、シートとつながりをそのまま渡すようなイメージに近い。変換規則は次の3つだ。

  • テーブル はノードの「種類」になる。users と orders は別種のノードとして扱われる。
  • 各行 は1つのノードになる。顧客も注文も、独立したノードだ。
  • 外部キー はノード同士をつなぐエッジになる。orders.user_id が users を指せば、注文ノードと顧客ノードの間にエッジが張られる。

多くのテーブルはタイムスタンプを持つため、「時系列・異種混在グラフ」になり、手がかりが消えずに残る。

「新人に前例を見せる」ように予測する――事前学習とin-context learning

予測を担うのは、GNN(Graph Neural Network、グラフ構造を扱うニューラルネットワーク)にTransformerを組み合わせた Relational Graph Transformer(RGT) だ。「どのテーブルの・いつの・どれだけ近い関係のデータか」を区別できるよう工夫されている。このRGTは あらかじめ学習(pre-train)済み のモデルとしてKumoから提供され、学習はここで完了済みだ。あとは推論時に、対象と似た過去の事例を見せてから問いかけるだけでよい。新しく配属された社員に、似た案件を数件見せて「これならどう判断するか」と聞くイメージに近い。この「事例を見せてその場で判断させる」やり方はLLMの few-shot に近い発想で、KumoRFM自身を作り直す(再学習=fit)必要がない点を zero-shot と呼ぶ。前者は推論時に事例を添える工程を、後者はモデルの再学習をしない点を指す、二段構えの言い方だ。数字を見ても壊れにくい。特徴量を大量に欠落させても性能低下はおよそ6%にとどまり(単一テーブル向けモデルでは約17%低下)、関係を表すエッジを75%取り除いても精度は安定したという。

PQLで1行問う――手動の特徴量エンジニアリングを超えられるか

KumoRFMでは PQL(Predictive Query Language) というSQLに似た言語で、Target(何を予測するか)・Entity(どの行か)・Horizon(いつまでか)の3要素を1行で書く。次の概念コードは、あるユーザーが今後90日間注文をしない(チャーンする)かを問うものだ。users_df・orders_dfは、それぞれ既存の顧客テーブル・注文テーブルをそのまま読み込んだデータフレーム(表形式のデータ)を指す。

import pandas as pd
import kumoai.rfm as rfm

# 認証(APIキーで接続。この時点でもモデルの「学習」は一切行わない)
rfm.init(api_key="YOUR_API_KEY")

# 1. 複数テーブルのリレーショナルDBを、そのままグラフとして登録する
#    → 「テーブル=ノード型・行=ノード・外部キー=エッジ」に対応。
#      from_data がテーブル間の主キー/外部キーを推論してリンクを張る。
graph = rfm.Graph.from_data({
    "users": users_df,     # 顧客テーブル(主キー: user_id)
    "orders": orders_df,   # 注文テーブル(外部キー: user_id で users に接続)
})

# 2. 事前学習済みモデルにグラフを渡す(タスク固有の再学習=fit は無い)
#    → 「in-context learning で学習なしに予測」に対応。
model = rfm.KumoRFM(graph)

# 3. 「予測したいこと」を PQL で1行だけ問う
#    user_id=42 が今後90日で注文0件=チャーンするか?
query = "PREDICT COUNT(orders.*, 0, 90, days) = 0 FOR users.user_id=42"

# 4. その場で予測が返る(結果は pandas DataFrame)
result = model.predict(query)
print(result)

print(result)を実行すると、user_id=42についてチャーンする確率を含む1行のデータフレームが返る。PREDICT COUNT(...) = 0 の集約条件を書き替えるだけで、チャーン予測は需要予測やレコメンドに切り替わる。特徴量を設計し直す工程が「問い方を変える」だけに縮む。精度は、Kumoの自己申告ではなく公開ベンチマークの数字で確認できる。RelBench(7つのDB・30タスクの公開ベンチ)のAUROC(予測精度を示す指標。RelBenchの表記に合わせた0〜100スケール。数値が大きいほど良い)は、人手の特徴量エンジニアリング+LightGBMが62.44だったのに対し、KumoRFMは学習なし(zero-shot)で76.71、微調整で81.14まで伸びる。従来手法を、KumoRFMは1つも学習せずに上回った。

3000万人のレコメンドを支える現場――DoorDashの本番運用

米フードデリバリー大手DoorDashは、3000万人規模のユーザーに対するレコメンドの改善にKumoRFMを用いており、エンゲージメントを1.8%高めたという。この数字はKumoの自社公表値で、Forbesによれば独立した第三者検証は限定的だ。前節のRelBenchはKumo・Stanford自身のベンチマークで、この数値自体は裏付けない。PQLの問い方自体は、DoorDashほどの規模でなくても同じように使えると考えられる。

使う前に押さえること、そして自社のDBに問いたいこと

KumoRFMの核心は、DBをグラフに変換し、事前学習済みモデルでin-context learningを行い、PQLの1行で問う――この3点に集約できる。ただしKumoのドキュメントは、予測には主キー・外部キー・タイムスタンプが揃っている必要があり、未来の情報が紛れ込む データリーク(data leakage) を避ける設計だと説明する。裏を返せば、スキーマの品質が予測の質を左右するということだ。コスト・セキュリティ・接続方法は本稿の参照資料だけでは確認できず、公式ドキュメントで確認してほしい。「特徴量エンジニアリングに12時間」だった構築が、「DBに1行問う」に近づく――基盤モデルの考え方が、テキストや画像を越えて企業のリレーショナルデータに届き始めた一例だ。自社のDBに、いま何を問いたいだろうか。

参考文献

  1. Kumo.ai 公式ブログ - Introducing KumoRFM: A Foundation Model for Relational Data - https://kumo.ai/company/news/kumo-relational-foundation-model/
  2. Kumo.ai - Predictive Modeling(RelBench AUROC・特徴量エンジニアリングの工数・海外実例) - https://kumo.ai/resources/learn/predictive-modeling/
  3. Kumo.ai Docs - Querying RFM(PQL: Target×Entity×Horizon・構文・クエリ例) - https://kumo.ai/docs/rfm/querying-rfm.md
  4. Kumo.ai Docs - Setup / SDK Getting Started(rfm.init・Graph.from_data・KumoRFM・predict) - https://kumo.ai/docs/rfm/sdk-getting-started.md
  5. Kumo.ai Docs - Setup Graph(LocalTable・stype・primary key/foreign key・link) - https://kumo.ai/docs/rfm/graph-creation.md
  6. Kumo.ai Docs - Introduction(pre-trained relational foundation model / no training required) - https://kumo.ai/docs/rfm/introduction.md
  7. The New Stack - Kumo AI's Foundation Models for Relational Data - https://thenewstack.io/kumo-ai-foundation-models/
  8. arXiv - Relational Graph Transformer(ICLR 2026) - https://arxiv.org/pdf/2505.10960
  9. arXiv - KumoRFM-2: Scaling Foundation Models for Relational Learning(頑健性の数値) - https://arxiv.org/pdf/2604.12596
  10. Forbes - NVIDIA Buys Kumo AI To Take Foundation Models To Enterprise Data(買収・独立検証への留保) - https://www.forbes.com/sites/janakirammsv/2026/06/10/nvidia-buys-kumo-ai-to-take-foundation-models-to-enterprise-data/
  11. Prior Labs - TabPFN(表データ向け基盤モデル・SAPによる買収の業界文脈) - https://priorlabs.ai/tabpfn
  12. Kumo.ai Docs - Which datasets should I use for my predictive query?(データリーク・時間アンカリング・スキーマ要件) - https://kumo.ai/docs/troubleshooting/which-datasets-should-i-use-for-my-predictive-query/
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?