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

Любой руководитель направления данных, изучающий статью расходов на GenAI в 2026 году, должен прочитать недавний пост Databricks дважды. Новый класс «System One» — дешёвые и быстрые классификаторы, выбирающие из фиксированного набора вариантов, — теперь можно вызывать прямо из SQL-ячейки, работая с данными в управляемом лейкхаусе. Это сводит процесс, который большинство команд сейчас отдаёт сторонним вендорам, к единственному вызову ai_query — и при этом не требует предоставления GPU ни от кого.

Что произошло

На выходных появилась волна так называемых System One моделей принятия решений, флагманом среди которых стал Jev. Как описывает Databricks, это фундаментальные модели, настроенные на выдачу хорошо откалиброванных решений из дискретного набора вариантов — они созданы для классификации и маршрутизации, а не для генерации произвольного текста. Их характеризуют как чрезвычайно быстрые и дешёвые, и именно это свойство имеет значение при скоринге миллионов строк.

Сообщество open source отреагировало практически мгновенно, выпустив 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 формат запросов проходит без изменений, а ответ возвращается в виде структурированных столбцов, содержащих выбранную классификацию и вероятности вариантов. С точки зрения аналитика, модель принятия решений выглядит как UDF. С точки зрения платформы — как ещё один управляемый endpoint, подчинённый тем же правилам каталога, что и любой другой объект в воркспейсе. AI Runtime дополняет картину, позволяя командам кастомизировать или дообучать эти модели на основе корпоративного контекста.

Техническая архитектура

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

Вспомните, как выглядела рабочая нагрузка с моделью принятия решений полгода назад. Вы выбирали вендора хостируемого инференса, договаривались о контракте с оплатой за токен, писали батч-джоб, который вытаскивал строки из лейкхауса, вызывал REST endpoint вендора, парсил JSON и записывал результаты обратно. Где-то в этом пайплайне были менеджер секретов, ограничитель запросов, политика повторных попыток и финансовые переговоры о стоимости исходящего трафика. Документация Databricks теперь описывает путь, при котором модель живёт внутри периметра управления, а SQL-движок вызывает её напрямую — это стирает большую часть этой инфраструктурной «сантехники».

Вывод вероятностей важнее классификации. Хорошо откалиброванные вероятности означают, что нижестоящая логика может применять пороговые значения по уверенности, направлять неоднозначные случаи на ревью к людям и выстраивать мониторинг дрейфа распределения, а не просто точности. Для аналитической команды, у которой уже есть dbt-модели, генерирующие признаки, добавление столбца с решением становится инкрементальной трансформацией, а не новой подсистемой. Любой, кто ведёт dbt-проект, легко представит эти изменения: вызов модели занимает место, где раньше был оператор CASE, только теперь логика выбора — обученная.

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

Кто окажется в проигрыше

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

CFO любого финтех-стартапа серии B или iGaming-оператора, использующего управляемые системы принятия решений, должен на этой неделе задать своему VP Engineering конкретный вопрос: какая часть наших текущих расходов на инференс приходится на рабочие нагрузки, которые можно выразить как «выбрать один из N вариантов для строки в нашем хранилище»? Если ответ — больше четверти счёта, разговор о продлении с текущим вендором в 2026 году принял другой оборот, а инициатива переходит к команде платформы, которая может прототипировать альтернативу в ноутбуке.

Вторая уязвимая группа — внутренние ML-платформенные команды, чьей задачей было создание собственной инфраструктуры обслуживания. Математика «строить vs. покупать» меняется, когда сторона «купить» в балансе перестаёт означать сторонний SaaS и начинает означать функцию, включённую в существующий контракт на хранилище данных. Роли Head of Platform, выстроенные вокруг обслуживания моделей на базе Kubernetes, окажутся перед необходимостью обосновывать сложность, которую serverless endpoint устранил.

Третья уязвимая группа — команды по комплаенсу и юридические отделы регулируемых операторов, потративших Q3 на переговоры о соглашениях об обработке данных с внешними вендорами инференса. Запуск модели на управляемых данных лейкхауса означает, что вопрос о DPA в значительной мере снимается, поскольку данные не покидают доверенный периметр. Это победа для главного юрисконсульта и повод для отдела закупок вернуться к файлам, которые считались закрытыми.

План действий для дата-команд

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

Далее запустите импортируемый ноутбук на реальной рабочей нагрузке, а не на демонстрационном датасете. Выберите задачу классификации, для которой у вас уже есть проверенный ground truth, прогоните SemIf-OpenJev по ней и сравните распределения вероятностей с выводом вашего текущего вендора. Калибровка — это то место, где эти модели либо оправдывают себя, либо нет. Вам нужен этот ответ до продления контракта с вендором, а не после.

В-третьих, включите в дорожную карту на Q1 дообучение через AI Runtime. Open-weight модели из коробки справятся с типовыми случаями, но дифференцированные победы придут от адаптации модели к вашей таксономии, вашим граничным случаям и вашему регуляторному словарю. Команды, которые относятся к этому как к развёртыванию в один клик, получат результаты уровня «одного клика». Команды, которые закладывают бюджет на дообучение, получат обоснованную точность на рабочих нагрузках, которые действительно важны.

Наконец, пересмотрите модель управления. Endpoint модели, вызываемый из SQL, — это новый вид объекта в каталоге, и история аудита того, кто вызывал какую модель для каких строк, должна быть чётко прописана до того, как об этом спросит аудитор. Лучше написать эту политику в этом квартале, чем дорабатывать её в авральном режиме под дедлайн.

Ключевые выводы

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