Прогноз оттока в крупной компании почти никогда не начинается с модели. Он начинается с трёх недель на feature engineering: аналитик собирает агрегаты по заказам, считает средний чек за 30 дней, добавляет число обращений в поддержку, потом всё это сплющивает в одну плоскую таблицу и только тогда зовёт дата-сайентиста. Через месяц выясняется, что признаки устарели, а половина сигнала потерялась при агрегации.

NVIDIA предлагает выбросить этот конвейер. Её новая модель Kumo Relational делает прогноз прямо по базе данных, с её таблицами, внешними ключами и метками времени, за один forward pass и без дообучения под задачу. Звучит как очередной маркетинговый лозунг про «ИИ без кода», но за ним стоит статья KumoRFM-2 на arXiv, 41 бенчмарк на 15 базах и вполне конкретный результат: впервые few-shot модель обошла обученные с учителем пайплайны на общих реляционных задачах.

Что такое Kumo Relational

Kumo Relational это предобученная foundation-модель для реляционных данных. На вход она получает схему базы и предиктивный запрос, находит в истории похожие примеры и выдаёт ответ: уйдёт ли клиент, сколько товара продастся, окажется ли транзакция мошеннической. Без конструирования признаков, без обучения под каждую задачу и без сведения таблиц в одну.

Разница с обычным ML здесь принципиальная. Классический путь: инженер придумывает агрегаты, обучает XGBoost или нейросеть, настраивает гиперпараметры, разворачивает модель. Путь Kumo: вы пишете запрос вида «предсказать число заказов за 30 дней для каждого пользователя», подключаете базу и получаете прогноз.

Тот же сдвиг, что случился с текстом

Авторы прямо проводят аналогию с NLP. Ещё недавно продакшн означал отдельную модель на каждую задачу, и каждую кормили своим конвейером токенизации, лемматизации и n-грамм. Языковые модели убрали эту прослойку по трём причинам: они точнее, проще в эксплуатации и достаточно гибкие, чтобы на них строить агентов.

С реляционными данными происходит то же самое, и причины те же. Одна предобученная модель заменяет отдельные пайплайны под каждую задачу, а новый прогноз становится запросом, а не проектом на квартал. И третий аргумент, который в статье проговаривают отдельно: агенты умеют читать, писать и рассуждать, а реляционная модель даёт им способность предвидеть. Агент не просто достаёт данные из базы, он отвечает на вопрос, что произойдёт дальше.

Как это работает внутри

Kumo Relational не сплющивает таблицы. Это ключевое архитектурное решение, из которого следует всё остальное. Реальные данные живут в связанных таблицах: пользователи соединены с заказами, заказы с товарами, и всё это меняется во времени. Ручная агрегация в одну строку («средний чек за последние 30 дней») теряет мелкую структуру и стоит человеко-недель.

Вместо этого модель работает с графом сущностей. Для каждого примера она берёт локальный подграф вокруг объекта на определённый момент времени и пару «признаки, целевое значение». Дальше три шага.

Первый, генерация контекста. Задача описывается на Predictive Query Language, декларативном языке, где вы говорите что предсказать, а не как. Для временных задач модель проигрывает исторические состояния базы: сэмплирует подграфы до опорной метки времени, а целевое значение считает по событиям после неё. Модель при этом видит только данные до опорной точки, и это защищает от утечки, которая обычно всплывает уже в продакшене, когда метрики на валидации красивые, а в жизни модель «знает» будущее.

Второй шаг, рассуждение внутри таблицы. Лёгкая сеть обрабатывает каждую таблицу отдельно через внимание по колонкам (связывает значения внутри одной колонки) и внимание по строкам (связывает признаки внутри строки). Она учится отбрасывать шум ещё до того, как он попадёт в общий граф.

Третий шаг, рассуждение между таблицами. Более крупная сеть распределяет эмбеддинги строк по реляционной структуре через графовое внимание по связям первичных и внешних ключей, а затем через cross-sample attention сопоставляет контекстные примеры с предсказываемым объектом. Именно здесь происходит связывание профиля пользователя с историей его транзакций.

Важная деталь: третий этап работает с эмбеддингами строк, а не с каждой ячейкой каждой таблицы. Поэтому стоимость не растёт квадратично, и модель держит большие контексты с глубокими подграфами.

На чём её учили

Публичных реляционных баз, пригодных для предобучения, почти нет: компании не выкладывают свои схемы и связи. Поэтому основу обучающего корпуса составляет синтетика. Генератор построен на подходе PluRel (Kothapalli и соавторы, ICML 2026), который расширяет табличные генераторы до полноценных реляционных баз в три этапа: сначала схема, потом связи внешних ключей с реалистичной кластеризацией строк, потом значения колонок из структурных причинных моделей с временными трендами и зависимостями между таблицами.

Генерация дешёвая, поэтому объём данных фактически неограничен. Авторы отдельно отмечают, что loss при предобучении падает по степенному закону по мере добавления синтетических баз, и прирост переносится на реальные базы. Предобучение идёт стадиями, от одиночных таблиц к всё более сложным структурам.

Ещё одно отличие от первой версии: информация о задаче подаётся как можно раньше. Из-за этого модель точнее выбирает релевантные колонки и лучше держится на зашумлённых данных.

Результаты в цифрах

Оценка шла на 41 бенчмарке из 15 реляционных баз: RelBench V1 и V2, SAP SALT, 4DBInfer. Домены разные, от электронной коммерции и медицины до enterprise и академических данных. Ни одну из этих баз модель не видела при предобучении.

На классификационных задачах RelBench V1 Kumo Relational обходит градиентный бустинг на экспертных признаках почти на 4 пункта AUROC в среднем. На корпоративном бенчмарке SAP SALT она превосходит большие ансамбли AutoGluon на 8% по mean reciprocal rank, а после дообучения отрыв растёт до 16%. Против XGBoost на сконструированных признаках: плюс 7 пунктов MRR сразу из коробки и плюс 13 после fine-tuning. В статье формулировка аккуратнее: до 8% лучше supervised и foundation-подходов.

Отдельная метрика, которая важна для продакшена, это скорость. На лидерборде RelArena-α модель держится на границе Парето по точности и затратам: примерно в 430 раз быстрее rtl-plurel при сопоставимом качестве. В абсолютных величинах kumo-engine обрабатывает более 500 млрд строк через memory-mapped ввод-вывод на скорости до 5 ГБ/с.

Где она держится, а где ломается

Устойчивость проверяли отдельно, и цифры здесь говорят больше, чем заголовочные проценты. Модель работает, когда в качестве контекста доступно всего 0,2% обучающих данных. Она остаётся стабильной, когда из базы удаляют до 75% связей внешних ключей. И почти не деградирует, когда в таблицы добавляют шумные колонки.

Ограничения авторы перечисляют честно, и на них стоит смотреть внимательнее, чем на рекорды. Лучше всего модель работает на данных с осмысленными связями и временной динамикой, то есть на поведении пользователей во времени. На задачах с очень большими обучающими наборами task-specific supervised модель всё ещё может выиграть. И предиктивный сигнал должен достигаться за ограниченное число переходов по связям: если нужная закономерность лежит в шестом джойне, контекст её может не собрать.

Из этого следует практическое правило. Kumo Relational это не замена любой модели, а замена тому классу задач, где сейчас мучаются с агрегатами по связанным таблицам: отток, спрос, фрод, риск, рекомендации. Там, где данных мало и структура бедная, выигрыш будет скромным.

Что это меняет для команд

Экономика здесь меняется сильнее, чем кажется. Прогноз перестаёт быть проектом с отдельным этапом feature engineering и превращается в запрос к базе. Для компании это означает, что задачи, которые раньше откладывали из-за цены, становятся доступными: не только отток по ключевым клиентам, но и прогноз по десятку второстепенных сегментов, на которые никогда не хватало людей.

Для инженеров это сдвиг роли. Меньше времени на сборку признаков, больше на постановку задачи и проверку того, что модель вообще имеет право предсказывать. Последнее важнее, чем выглядит: если сигнал течёт во времени, а метка времени выставлена неаккуратно, никакая архитектура не спасёт.

Есть и обратная сторона, о которой в релизе не пишут. «Без обучения» не значит «без контроля»: предобученная модель на синтетике приходит с неявными представлениями о том, как устроены базы, и эти представления могут не совпадать с вашей схемой. Проверять придётся не только метрики, но и то, на какие связи модель опирается.

Как попробовать

Код открыт под Apache 2.0, веса под лицензией OpenMDW 1.1. Модель лежит на Hugging Face (на момент публикации около 2,78 тыс. загрузок), код в репозитории NVIDIA structured-data-models, клиент отдельно, есть вариант развёртывания как NVIDIA NIM. Минимальный запуск выглядит так: поставить пакет structured-data-models, загрузить веса с Hub при первом обращении и передать в модель контекстную таблицу, запрос и связанные таблицы.

Для запросов есть два уровня. В коде вы собираете тензоры таблиц и передаёте связанные таблицы явно. Через NIM пишете запрос на PQL, например «предсказать количество заказов за 30 дней для каждого пользователя», и клиент сам материализует контекст.

Что проверить перед пилотом

Первое, на что стоит посмотреть, это метки времени. Вся конструкция с опорными точками держится на том, что события в базе датированы честно. Если статус заказа обновляется задним числом, а дата создания записи совпадает с датой правки, модель получит будущее в контексте и покажет красивые цифры на валидации.

Второе, длина связей. Авторы прямо пишут, что сигнал должен достигаться за ограниченное число переходов. Прежде чем радоваться, пройдите путь от целевого объекта до самого дальнего признака, который считаете важным. Если это пять-шесть джойнов через промежуточные таблицы, часть информации модель просто не соберёт, и разница с текущим пайплайном будет выглядеть как провал метода, хотя это ограничение постановки.

Третье, объём размеченных данных. Чем больше у вас исторических примеров с известным исходом, тем сильнее будут конкурировать обычные supervised-модели. Kumo выигрывает за счёт переноса из предобучения, и её преимущество тает там, где данных достаточно для полноценного обучения с нуля. Поэтому пилот логично ставить на сегменте, где разметки мало, а гипотез много.

И последнее, стоимость инференса. Пятьсот миллиардов строк и память на 5 ГБ/с выглядят впечатляюще, но это про пропускную способность, а не про цену одного прогноза. Для пакетных сценариев раз в сутки вопрос не встанет, а для онлайн-предсказаний на каждый клик считать придётся отдельно.

FAQ

Чем это отличается от табличных foundation-моделей вроде TabPFN?

Табличные модели работают с одной плоской таблицей. Всё, что находится в связанных таблицах, им приходится предварительно агрегировать в признаки. Kumo Relational сохраняет структуру базы: внешние ключи, связи, временную согласованность. Именно поэтому она обходит пайплайны на экспертных признаках, а не только «сырые» табличные бейзлайны.

Нужно ли строить хранилище или переносить данные?

Нет. Модель подключается к базе или хранилищу и читает данные на месте, в памяти, через коннекторы или через kumo-engine для очень больших объёмов. Сведение таблиц в одну и вычисление агрегатов не требуется.

Заменит ли это XGBoost на практике?

Не полностью. На задачах с большим объёмом размеченных данных обученный с учителем бустинг может остаться сильнее. Kumo выигрывает там, где нужны быстрые прогнозы по связанным таблицам и где на отдельную модель под каждую задачу не хватает людей. Разумный сценарий на 2026 год: Kumo как базовый прогноз и supervised как уточнение на самых важных задачах.

Итог

Kumo Relational показывает, что реляционные данные перестают быть вотчиной ручного feature engineering. Предобученная модель на синтетике, графовое внимание по связям и in-context обучение дают результат, который на 41 бенчмарке обходит supervised-подходы, включая AutoGluon, и делает это без обучения под задачу. Ограничения у метода есть, и они честно описаны: связи должны быть информативными, сигнал должен лежать близко, а на больших размеченных наборах конкуренты ещё огрызаются.

Если у вас есть база с историей заказов и оттоком, самый дешёвый способ проверить тезис на своём материале: взять один сегмент, собрать PQL-запрос и сравнить с текущим пайплайном. Расхождение в процентах MRR скажет о вашей задаче больше, чем любой бенчмарк.