Модель поверх вашей базы: прогноз без обучения, временные ряды и поиск внутри Postgres

NVIDIA выложила модель, которая делает прогнозы по реляционной базе без обучения под задачу, IBM собрала четыре модели временных рядов в один ансамбль, а TigerData открыла библиотеку поиска внутри PostgreSQL. Общая мысль: данные компании уже лежат в базе, и вопросы «что будет дальше» и «что было тогда» можно задавать к ним напрямую. Для владельца бизнеса порог для прогноза спроса или оттока опустился до одной базы с историей.

Что вышло

NVIDIA 21 октября в блоге Hugging Face представила Kumo Relational. Модель читает таблицы, внешние ключи и временные метки и отвечает на предсказательный запрос, например кто из клиентов уйдёт или сколько единиц продастся. Без обучения под задачу и без ручной сборки признаков. На 41 задаче из 15 баз она обошла обученные модели и пайплайны на градиентном бустинге. Для прогноза модель берёт только события до контрольной даты, чтобы не подсматривать в будущее. Код и веса открыты.

IBM Research 22 октября там же описала ансамбль Granite для временных рядов. Четыре предобученные модели с разной архитектурой дают прогноз, а рецепт объединяет их в медиану и квантили. По умолчанию все четыре модели имеют равное влияние, ничего не дообучается. Квантили 0,1 и 0,9 дают интервал с номинальным покрытием 80 %. Проверяли на 97 конфигурациях GIFT-Eval без дообучения.

TigerData 20 октября открыла searchgres.js: библиотеку на TypeScript под Apache-2.0: один запрос к PostgreSQL совмещает поиск по словам BM25, поиск по векторам и фильтры по иерархии, метаданным и времени. Пример из статьи: оператор электростанции выделяет на графике полчаса, когда мощность упала, и спрашивает «это было запланировано». Поиск находит диспетчерское указание и запись смены по этому блоку и времени. Фильтры применяются до ранжирования, поэтому нужная запись не выпадает из первой двадцатки.

Через два дня, 22 октября, та же команда рассказала, как строила три системы памяти для своего Slack-агента. Список фактов оказался слишком бедным. Общий граф знаний со свободным доступом к SQL оказался слишком свободным: агенты тратили десятки ходов на механику базы вместо задачи. Дерево на расширении ltree дало каждой записи место и понятный набор операций. Самая выразительная система оказалась не самой полезной.

Weaviate 14 октября описала PathSeer, алгоритм фильтрованного векторного поиска из статьи SIGMOD 2026 от Университета Цинхуа. В реализации авторов пропускная способность в 1,2–13,5 раза выше обычного HNSW при recall 90 %, а в Weaviate 1.40 стратегия переключается на существующем индексе без перестройки.

Зачем это бизнесу

Возьмём прокат автомобилей с историей бронирований за два года в базе. Вопрос владельца: сколько машин какого класса будут простаивать в ноябре и стоит ли брать ещё две на сезон. Модель вроде Kumo Relational обещает ответ по той же базе за запрос, а ансамбль временных рядов даёт диапазон спроса по дням, с интервалом вместо одной цифры.

Второй вопрос из серии «что было тогда»: клиент спорит, что ему в марте обещали другую цену. Если переписка, записи звонков и заметки менеджеров лежат в одной базе с временем и привязкой к брони, поиск по словам и смыслу с фильтром по клиенту и месяцу находит нужную фразу за секунды. Вывод: главное условие здесь история в базе, со временем и связями между таблицами. Новая база для этого не нужна.

Как это у меня

Весной 2023 года я сделал для консалтинговой компании в Лондоне финансовую панель с нуля. Мы забирали данные по акциям из Morningstar API, добавляли новости и передавали всё в ChatGPT. По каждой компании складывалась сводная таблица с предположительной оценкой того, куда может пойти акция. Гарантированным прогнозом и инвестиционной рекомендацией это не было. С той панели я усвоил: модель поверх данных отвечает в формате таблицы, а решает человек.

У PDR-компании в США с 2023 года данные лежат в MariaDB на своём сервере: звонки с AI-разбором, лиды, заказы, 15 показателей leaderboard по каждому сотруднику. Вопрос «что будет с потоком лидов в следующем месяце» к этой базе можно задать уже сейчас. Kumo Relational и ансамбль Granite я не запускал; проверил бы их на истории лидов с 2023 года против прогноза по прошлому году. Если выигрыша нет, модель не нужна.

Что я бы сделал

Начал бы с проверки базы: есть ли у событий время, связаны ли таблицы ключами, не затирается ли история при обновлении записи. Без этого ни прогноз, ни поиск не работают.

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

Поиск по истории делал бы в той же базе, с фильтрами по клиенту и времени. Отдельное хранилище под векторы завёл бы, только когда упрусь в производительность.

Память агента, если она понадобится, начинал бы с дерева и фильтров, как в третьей попытке TigerData, и не давал бы агенту свободный SQL.

Связанные материалы

Про проверку результата модели: AI в обработке данных: извлечение и проверка. Подход: Python для документов, данных и повторяемой обработки и автоматизация таблиц и бизнес-отчётность. Кейсы: финансовая панель в Google Sheets, консалтинговая компания в Лондоне и сервисная команда и конверсия на 30 %. Из обзоропо той же теме: три решения в базе, о которых жалеют позже, AI решает, человек подтверждает и как я выбираю между своей моделью и API. Раньше: гибридный поиск и токенизация и граф знаний или векторный RAG. Если история вашей компании уже лежит в базе, расскажите, какой вопрос к ней первый. Обсудить задачу.