Когда SQL недостаточно

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

Модели решений, которые также называют моделями System One, отвечают на один заданный вопрос структурированным значением: выбирают вариант из списка, выставляют оценку или возвращают вероятность ответа «да» либо «нет». У Jev, представленной TypeSafe AI 15 сентября, к ответу также прилагается показатель уверенности, поэтому его можно сохранить в столбце и использовать в следующих шагах конвейера.

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

Как платформы подключают модели решений

Databricks описала два варианта: запуск проекта SemIf-OpenJev на бессерверных графических ускорителях с вызовом через SQL и функцию ai_query, а также собственную функцию ai_decide. Последняя находится в бета-версии и, по заявлению компании, использует модель, совместимую с API TypeSafe.

Snowflake Decision доступна в режиме закрытого предварительного просмотра через AI_COMPLETE в Cortex AI Functions. Компания утверждает, что модель создана специально для принятия решений и работает внутри периметра безопасности Snowflake. Потхукчи также сообщил о разработке более быстрой версии Snowflake Decision Fast и поддержке моделей решений через Cortex REST API; сроков он не назвал.

Jev можно подключить и непосредственно к SQL-движкам: расширения сообщества добавляют функции для DuckDB и PostgreSQL. Astronomer сообщила, что поддержка Jev появится в будущей версии пакета Airflow common AI provider. Среди описанных сценариев — выбор ветки рабочего процесса по ответу модели, отправка строк с низкой уверенностью на проверку человеком и определение типа сбоя для решения о повторном запуске.

Примеры применения и оценки поставщиков

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

Astronomer сообщила, что использует Snowflake AI_CLASSIFY для распределения примерно 250 000 должностей по категориям. В тесте на 4 000 названий Jev, по данным компании, завершила обработку за 66 секунд и 16 центов; стоимость такой же работы на AI_CLASSIFY оценивалась в 11–21 доллар по прайс-листу.

MotherDuck привела результаты собственного теста на 100 000 новостных статей из открытого набора данных с четырьмя темами: Jev, по заявлению компании, разметила их за 40 секунд за 50 центов с точностью 89%. Для модели OpenAI MotherDuck указала точность 88%, время почти 32 минуты и стоимость 37,58 доллара. Это результаты тестов, опубликованные поставщиками, а не независимое сравнение.

Стартап Southbridge AI сообщил, что использовал Jev для сопоставления доноров и комитетов в финансовых записях избирательных кампаний штата Огайо. В описанном компанией конвейере Jev выполняла основную работу, а другая модель проверяла неуверенные случаи; стартап заявил о снижении расходов на модели на 99,56% относительно передовой модели.

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

Эксперты советуют сравнивать модели решений не только с крупными языковыми моделями, но и с обычными правилами и традиционным машинным обучением. По словам Стефани Уолтер из HyperFRAME Research, выбор должен учитывать точность, трудозатраты на поддержку и совокупную стоимость.

Показатель уверенности помогает решить, какие строки автоматизировать, а какие отправить человеку, но его нужно проверить на собственных данных. Майкл Леоне из Moor Insights & Strategy предупредил: модель может выглядеть уверенной на тестах поставщика и чаще ошибаться на данных заказчика.

Остаётся и вопрос ответственности: кто определяет допустимые ответы — например, команды, которым можно направить обращение, или признаки подозрительной заявки. По мнению Леоне, это бизнес-решение, которое может оказаться скрытым внутри конвейера данных. Поэтому внедрение требует не только настройки модели, но и ясных правил о том, кто задаёт варианты ответа и проверяет результат.