Databricks переносить моделі прийняття рішень у SQL: зробити самому чи купити?

Будь-який Head of Data, який розглядає статтю бюджету GenAI на 2026 рік, має двічі прочитати нещодавній пост Databricks. Новий клас «System One» decision-моделей — дешевих і швидких класифікаторів, що обирають із фіксованого набору варіантів, — тепер можна викликати з SQL-комірки проти керованих даних у лейкхаусі. Це згортає робочий процес, який більшість команд наразі делегує стороннім вендорам, в один виклик ai_query, і робить це без необхідності виділяти GPU.

Що відбулося

Нещодавно з'явилася хвиля так званих System One decision-моделей, де флагманом став Jev. Як описує Databricks, це foundation-моделі, налаштовані для продукування добре відкаліброваних рішень із дискретного набору варіантів, тобто вони побудовані для класифікації та маршрутизації, а не для генерації відкритих відповідей. Їх описують як надзвичайно швидкі та дешеві — саме та характеристика, що має значення, коли ви оцінюєте мільйони рядків.

Спільнота відкритого програмного забезпечення відреагувала майже одразу, випустивши open-weight варіанти, зокрема Smelf-open-jev, Laya та Kev. Databricks потім підключила один із них, SemIf-OpenJev, до демонстраційного ноутбука, який класифікує відгуки про готелі як позитивні або негативні на основі даних, що вже знаходяться у лейкхаусі.

Механіка навмисно проста. Користувач імпортує ноутбук, обирає назву моделі та схему, вибирає Serverless GPU та натискає Run All. Ноутбук завантажує файли моделі, реєструє її через Express Deployments і автоматично запускає GPU Model Serving endpoint. Жодного запиту до інфраструктурної команди, жодних нарад із планування потужностей, жодного погодження в Terraform.

Цікава частина — поверхня запитів. Endpoint не зобов'язаний надавати chat-completions API, оскільки ai_query підтримує довільні API кастомних моделей. Це означає, що власний формат запиту SemIf передається без змін, а відповідь повертається у вигляді структурованих стовпців із обраною класифікацією та ймовірностями варіантів. З позиції аналітика decision-модель виглядає як UDF. З позиції платформи — як ще один керований endpoint, що підпорядковується тим самим правилам каталогу, що й усі інші об'єкти у воркспейсі. AI Runtime доповнює картину, дозволяючи командам кастомізувати або донавчати ці моделі на власному корпоративному контексті.

Технічна анатомія

Архітектурний хід тут варто назвати чітко. Databricks взяла дві найскладніші частини запуску open-weight моделі у продакшні — serving-шар та шар виклику — і обгорнула обидві у примітиви, що вже існують у платформі. Model Serving обробляє endpoint. ai_query обробляє виклик. Unity Catalog забезпечує управління навколо обох. Новизна полягає не в моделі, а в маршрутизації.

Уявіть, як виглядало навантаження decision-моделі шість місяців тому. Ви обирали вендора хостованого інференсу, домовлялися про контракт із оплатою за токен, писали batch-задачу, яка витягувала рядки з лейкхаусу, викликала REST endpoint вендора, парсила JSON і записувала результати назад. Десь у цьому пайплайні у вас був менеджер секретів, rate limiter, політика повторних спроб і фінансова розмова про egress. Документація Databricks тепер описує шлях, де модель живе всередині межі управління, а SQL-рушій викликає її напряму, що усуває більшість цього «сантехнічного» коду.

Вивід ймовірностей важливіший за саму класифікацію. Добре відкалібровані ймовірності означають, що подальша логіка може встановлювати пороги на основі впевненості, направляти неоднозначні випадки на ручну перевірку та будувати моніторинг на основі дрейфу розподілу, а не лише точності. Для аналітичної команди, яка вже має dbt-моделі, що продукують ознаки, додавання стовпця рішення стає інкрементальною трансформацією, а не новою підсистемою. Будь-хто, хто веде dbt-проєкт, може уявити цю зміну: виклик моделі стоїть там, де раніше стояв оператор CASE, тільки тепер логіка оператора — навчена.

Serverless GPU — це тихий помічник. Обчислення на вимогу означають, що endpoint не витрачає кошти в режимі очікування, що є тією економічною історією, яка робить System One моделі придатними для широкого розгортання. Класифікатор, який коштує частки цента за рядок і запускається лише тоді, коли виконується запит, — це зовсім інше бюджетне завдання порівняно з виділеним GPU-кластером, розрахованим на пікову пропускну здатність.

Хто програє

Найбільш вразлива категорія — це середній прошарок AI-вендорів, що продають хостовані endpoint'и для класифікації та маршрутизації. Якщо основна цінність вашого продукту — це REST API перед файнтюнованим класифікатором, а дані вашого клієнта вже знаходяться в Databricks або Snowflake, тертя вашої інтеграції щойно перетворилося на конкурентний тягар. CFO покупця помітить, що те саме навантаження виконується всередині наявного контракту на лейкхаус без нового замовлення на оплату.

CFO будь-якого fintech-стартапу серії B або iGaming-оператора, що використовує managed decisioning, цього тижня має поставити своєму VP Engineering конкретне запитання: яка частина наших поточних витрат на інференс стосується навантажень, що можна виразити як «обрати один із N варіантів для рядка в нашому сховищі». Якщо відповідь — більше чверті рахунку, розмова про поновлення контракту з поточним вендором у 2026 році набула іншої форми, а право ухвалення рішення переходить до платформної команди, яка може прототипувати альтернативу в ноутбуці.

Друга вразлива категорія — внутрішні ML platform-команди, чиїм завданням було розгортання власної serving-інфраструктури. Математика «зробити чи купити» змінюється, коли «купити» перестає означати сторонній SaaS і починає означати функцію, вбудовану в наявний контракт на data warehouse. Керівники платформних команд, що побудовані навколо serving-інфраструктури на базі Kubernetes, опиняться перед необхідністю виправдовувати складність, яку serverless endpoint просто усунув.

Третя вразлива категорія — compliance- та юридичні команди регульованих операторів, які витратили третій квартал на переговори про угоди про обробку даних із зовнішніми вендорами інференсу. Запуск моделі на керованих даних лейкхаусу означає, що питання DPA здебільшого зникає, оскільки дані ніколи не покидають межу довіри. Це перемога для головного юриста та привід для відділу закупівель переглянути файли, які вважалися закритими.

Стратегія для data-команд

Почніть з інвентаризації. Витягніть витрати на зовнішній інференс за останні дев'яносто днів і позначте кожне навантаження як генеративне (розгорнутий вивід) або рішення (обрати один із N). Категорія «рішення» — ваш список кандидатів для міграції. Усе, що звертається до хостованого класифікатора для аналізу тональності, визначення намірів, маршрутизації, тріажу шахрайства або модерації контенту, належить до цього списку.

Далі запустіть імпортований ноутбук на реальному навантаженні, а не на демонстраційному наборі даних. Оберіть задачу класифікації, де ви вже знаєте правильні відповіді, запустіть над нею SemIf-OpenJev і порівняйте розподіли ймовірностей із виводом вашого поточного вендора. Калібрування — це те, де ці моделі або виправдовують себе, або ні, і ви хочете отримати цю відповідь до поновлення контракту з вендором, а не після.

По-третє, включіть AI Runtime post-training до дорожньої карти на перший квартал. Open-weight моделі «з коробки» впораються з типовими випадками, але диференційований виграш приходить від налаштування моделі під вашу таксономію, ваші граничні випадки та ваш регуляторний словник. Команди, що сприймають це як розгортання в один клік, отримають результати рівня одного кліку. Команди, що закладуть бюджет на post-training, отримають обґрунтовану точність на навантаженнях, що дійсно мають значення.

Насамкінець, перегляньте свою модель управління. Endpoint моделі, що викликається з SQL, — це новий тип об'єкта в каталозі, і story аудиту щодо того, хто яку модель викликав проти яких рядків, має бути чітко визначена до того, як аудитор поставить запитання. Краще написати цю політику цього кварталу, ніж адаптувати її в авральному режимі.

Ключові висновки

• System One decision-моделі, такі як Jev та їхні open-weight варіанти (Smelf-open-jev, Laya, Kev), зводять задачі класифікації до SQL-примітиву в Databricks через ai_query.
• Serverless GPU разом із Express Deployments усуває інфраструктурні та MLOps-витрати, які робили власний serving невизначеним питанням «зробити чи купити».
• Структурований вивід, включно з ймовірностями варіантів, означає, що подальша аналітика може встановлювати пороги на основі впевненості, а не просто приймати мітку.
• Вендори хостованої класифікації стикаються з тиском при поновленні контрактів, оскільки керовані дані лейкхаусу переносять інференс всередину наявної контрактної межі.
• Команди, що оцінюють розгортання decision-моделей, мають тепер запитати себе, чи є їхні поточні витрати на зовнішній інференс виправданими порівняно з навантаженням, що може виконуватися нативно у їхньому сховищі.