Что такое NVIDIA Kumo Relational и какой интент она закрывает
NVIDIA Kumo Relational (в arXiv-статье модель называется KumoRFM-2) делает прогнозы по корпоративным реляционным базам за один forward pass. Ей не нужно обучение под конкретную задачу, ручной feature engineering и «уплощение» таблиц. Прогнозный запрос может касаться оттока, спроса или фрода, а ответ строится прямо по связанным таблицам. Анонс NVIDIA описывает модель как предобученную реляционную фундаментальную модель.
Механика опирается на in-context learning. На инференсе модель собирает до 10 000 исторических примеров как контекст, учитывает структуру таблиц, внешние ключи и временные метки и выдаёт прогноз за один forward pass. Веса не обновляются. Модель нативно работает с одной или несколькими связанными таблицами и сохраняет временную согласованность.
Практическая разница с привычным пайплайном в подготовке. Не нужно собирать плоскую витрину, генерировать целевую переменную и обучать отдельную supervised-модель под каждую задачу. Запросы формулируются на Predictive Query Language (PQL). Модель доступна в open-source GPU-native библиотеке structured-data-models под Apache 2.0 и как NVIDIA NIM; NVIDIA заявляет масштаб 500+ млрд строк. Тот же анонс приводит цифры бенчмарков, но это результаты вендора и авторов статьи, а не независимый аудит.
Чем Kumo Relational отличается от градиентного бустинга и relational deep learning
Три подхода решают одну задачу разными способами.
| Подход | Данные | Обучение | Постановка задачи |
|---|---|---|---|
| Градиентный бустинг | Плоская витрина, ручные признаки и агрегаты | Отдельная supervised-модель под задачу | Код пайплайна, фичи, целевая переменная |
| Relational deep learning | Связанные таблицы как граф | Supervised-обучение под задачу | Пайплайн и обучение |
| Kumo Relational | Связанные таблицы как есть, без уплощения | Предобученная модель, in-context learning или fine-tuning | PQL |
Градиентный бустинг силён, когда плоская витрина уже собрана и признаки проверены. Relational deep learning учитывает связи, но остаётся supervised-подходом под конкретную задачу. Kumo Relational переносит акцент на предобученную модель: внешние ключи и временные метки учитываются нативно, а порог входа снижается до формулировки запроса.
Как устроена модель: внимание внутри таблиц и по связям между ними
Реляционная специфика начинается с того, что модель учится не на одной таблице, а на базе. В arXiv-статье авторы описывают предобучение KumoRFM-2 по четырём осям: строки и столбцы на уровне отдельной таблицы, внешние ключи и cross-sample на уровне базы. arXiv 2604.12596. На уровне идеи внимание работает в двух плоскостях: внутри таблицы, по строкам и столбцам, и между таблицами, по переходам через внешние ключи.
Это объясняет, почему модели не нужно «уплощать» схему. Строки задают объекты, столбцы - их атрибуты, внешние ключи - связи, временные метки - порядок событий. KumoRFM-2 внедряет информацию о задаче как можно раньше; авторы связывают это с более точным отбором релевантных столбцов и устойчивостью к шуму. Точную схему слоёв и масок внимания стоит смотреть в arXiv: в анонсе NVIDIA детали не раскрыты.
Предшественник KumoRFM-1 работал с небольшими in-memory датасетами. KumoRFM-2 рассчитана на реляционные датасеты миллиардного масштаба. Статья arXiv описывает этот переход как ключевое отличие второй версии. Миллиардный масштаб меняет требования к инфраструктуре: это отдельная история про хранение, подготовку данных и инференс, а не смена одной библиотеки.
In-context learning на инференсе: что происходит при одном forward pass
Один forward pass не означает, что модель заранее знает вашу базу. Она получает контекст из истории: до 10 000 примеров, структуру таблиц, внешние ключи и временные метки. Веса не меняются, поэтому адаптация идёт без обучения под задачу. KumoRFM-2 поддерживает in-context learning и fine-tuning: второй режим применяют, когда требуется максимум точности на конкретной задаче.
- Приходит прогнозный запрос на PQL.
- Модель собирает до 10 000 исторических примеров как контекст.
- Учитывает структуру таблиц, внешние ключи и временные метки.
- Выдаёт прогноз за один forward pass без обновления весов.
Predictive Query Language: как формулируется прогнозный вопрос
PQL даёт простой интерфейс для прогнозных вопросов. NVIDIA отмечает, что модель рассчитана на вызовы агентами: агент может задать вопрос и получить прогноз, не собирая отдельный ML-пайплайн. Синтаксис и примеры запросов стоит смотреть в документации structured-data-models: в анонсе полного описания нет.
Что показывают бенчмарки: RelBench, SAP SALT и 4DBInfer
NVIDIA и авторы arXiv-статьи приводят результаты на 41 задаче из 15 баз: RelBench V1/V2, SAP SALT и 4DBInfer. arXiv 2604.12596. На классификационных задачах RelBench V1 модель обходит градиентный бустинг на экспертных признаках в среднем почти на 4 пункта AUROC. На SAP SALT - на 8% по MRR над ансамблями AutoGluon и до 16% после fine-tuning; над XGBoost на инженерных признаках - на 7 пунктов MRR «из коробки» и на 13 пунктов после fine-tuning. Анонс NVIDIA. По совокупности 41 бенчмарка авторы заявляют превосходство над supervised и фундаментальными подходами до 8%, включая cold start и зашумлённые данные.
Как читать эти цифры: MRR, AUROC и что они значат на практике
AUROC (area under the ROC curve) показывает, насколько хорошо модель разделяет классы: 0,5 - случайное угадывание, 1 - идеальное разделение. MRR (mean reciprocal rank) оценивает ранжирование и учитывает позицию правильного ответа: чем выше в списке стоит верный вариант, тем больше вклад. Прирост в пунктах MRR или AUROC не равен приросту в деньгах. Для бизнес-эффекта нужен пересчёт через свою воронку, стоимость ошибок и пропускную способность команды.
Все цифры выше - результаты NVIDIA и авторов на конкретных бенчмарках. Независимого воспроизведения в доступных материалах нет. Перенос на произвольную корпоративную базу не гарантирован: схема, качество истории и распределение данных могут изменить картину.
Практические сценарии: отток, спрос, фрод и агентские workflow
Отток. Сигнал обычно размазан по клиентам, подпискам, платежам, обращениям в поддержку и событиям в продукте. Плоская витрина с агрегатами съедает часть истории, а ручные признаки быстро устаревают. Kumo Relational читает связанные таблицы и временные метки, поэтому прогнозный запрос можно ставить по той же схеме, в которой живут данные.
Спрос. Заказы, остатки, промо и календарь лежат в разных таблицах. Прогноз по одной плоской выгрузке теряет часть контекста: например, влияние промо на конкретный склад. Реляционная модель может работать с несколькими связанными таблицами, поэтому задачу проще ставить ближе к исходной схеме.
Фрод. Транзакции, аккаунты, устройства и история операций связаны между собой. Сигнал часто появляется в переходах по этим связям, а не в одном столбце. Модель, которая учитывает внешние ключи, получает шанс увидеть такие зависимости без ручного конструирования признаков.
Агентский workflow. Аналитик или агент формулирует вопрос на PQL, модель возвращает прогноз, следующий шаг использует ответ: письмо клиенту, ручная проверка транзакции, пополнение склада. NVIDIA отдельно подчёркивает, что модель рассчитана на вызовы агентами. Кейсы клиентов и цифры проектов в материалах не приводятся, поэтому сценарии стоит проверять на своей задаче.
Как попробовать: structured-data-models, NVIDIA NIM и требования к инфраструктуре
Два пути доступа: open-source GPU-native библиотека structured-data-models под Apache 2.0 и NVIDIA NIM. Библиотека рассчитана на GPU, а заявленный масштаб доходит до 500+ млрд строк. В материалах нет требований к VRAM, версии CUDA и цен, поэтому перед пилотом эти параметры нужно уточнить в документации и у поставщика инфраструктуры.
Пилот на своей базе: с чего начать без переписывания пайплайна
Проверка на своей базе важнее, чем цифры из arXiv. Бенчмарки не гарантируют перенос на конкретную схему.
- Выберите одну задачу, где уже есть baseline на XGBoost или AutoGluon и известна метрика. Перед сравнением полезно освежить чек-лист по оценке новых AI-моделей.
- Сформулируйте ту же задачу на PQL по исходной схеме БД.
- Сравните на своей временной разбивке, а не на случайном сплите.
- Если in-context результата не хватает, проверьте fine-tuning и посчитайте, сколько данных и времени он требует.
- Зафиксируйте стоимость инференса, сопровождения и обновления модели.
Перед запуском уточните в документации: какие СУБД поддерживаются, как библиотека подключается к базе, какие режимы доступны, какие GPU нужны. Эти детали не стоит додумывать по бенчмаркам.
Ограничения: где supervised-модели всё ещё выигрывают
На очень больших обучающих наборах task-specific supervised-модели всё ещё могут выигрывать. Kumo Relational сильна в few-shot и cold start, но это не отменяет преимущества обученной модели, когда истории много и задача стабильна. Прогнозный сигнал должен достигаться за ограниченное число переходов по связям. Если нужная информация лежит глубоко в графе таблиц, преимущество размывается.
Масштаб 500+ млрд строк - заявление вендора. Миллиардный масштаб требует отдельной инфраструктуры: хранения, подготовки данных и контроля стоимости инференса. В материалах нет независимого подтверждения этих цифр. Fine-tuning возвращает часть сложностей, от которых модель обещала избавить: нужно готовить данные, следить за переобучением и поддерживать версии модели.
Когда fine-tuning обязателен, а когда хватает in-context learning
In-context learning - быстрый старт. Модель не обновляет веса, поэтому пилот можно провести без обучения и сбора большой обучающей выборки. Fine-tuning нужен, когда без него точности не хватает. На SAP SALT разрыв с XGBoost на инженерных признаках составляет 7 пунктов MRR «из коробки» и 13 пунктов после fine-tuning. Это осознанный трейд-офф: выше точность, выше требования к данным и сопровождению.
Кому стоит смотреть на реляционные фундаментальные модели
Реляционные фундаментальные модели интересны командам, у которых несколько связанных таблиц и поток прогнозных задач: отток, спрос, фрод, приоритизация лидов. Если под каждую задачу приходится собирать витрину и обучать отдельную модель, предобученная реляционная модель может сократить путь до первого результата. Отдельный интерес - агентские workflow: PQL даёт агенту понятный интерфейс для прогнозного вопроса.
Командам с одной крупной задачей и большим накопленным обучающим набором рано отказываться от проверенного бустинга. Сначала стоит сравнить подходы на своей временной разбивке. Направление реляционных фундаментальных моделей стоит держать в поле зрения: NVIDIA развивает и open-source библиотеку, и NIM, а PQL упрощает вызов модели из агентов. Проверка на своей задаче остаётся обязательным шагом.