@yibie: https://x.com/yibie/status/2104217838953087098
Summary
This article introduces how to use SQL on the Databricks platform to run the open-source decision model SemIf-OpenJev, enabling batch processing by calling the model without data leaving the platform.
View Cached Full Text
Cached at: 09/27/26, 03:26 PM
Running Open-Jev with SQL on Databricks
Author: Cyrus Cowley, Tejas Sundaresan, Hanlin Tang, Anshul Gupta, Julia Powell (Databricks)
In short: Open-source decision models can now run on a managed platform, callable directly via SQL, without your data ever leaving your governed environment.
I. Why This Matters
The open-source decision model space has been buzzing lately—from SemIf-OpenJev to Laya to Kev, there’s been a steady stream of open-weight releases.
But these models only unlock their true power when they can access large datasets.
And “accessing large datasets” is precisely what data platforms are built for. So the path laid out by Databricks connects three key components:
- Open-source decision models (they’re using SemIf-OpenJev)
- Governed enterprise data
- SQL, the interface everyone already knows
II. Three Steps to Start
They’ve packaged an importable Notebook. Getting started takes just three steps:
- Select the model name/schema
- Choose Serverless GPU
- Click “Run All”
This Notebook uses Databricks AI Runtime to provide serverless, on-demand GPU compute—no need to set up or manage GPU infrastructure yourself.
It performs three tasks:
- Downloads the model files for SemIf-OpenJev
- Logs and registers the model using Express Deployments
- Automatically creates a GPU Model Serving endpoint
At this point, you have an open-source classifier running behind a managed endpoint, ready to be called from applications or directly via SQL.
III. Key Insight: The Endpoint Doesn’t Need to Expose a Standard Chat Interface
This is, in my view, the most important sentence in the entire piece:
A useful aspect of this setup is that the endpoint does not need to expose a standard chat-completions interface.
Databricks’ ai_query supports arbitrary custom model APIs. This means you can send SemIf’s structured request format directly from SQL.
This implies you don’t have to alter the model’s interface to accommodate the platform. Decision model interfaces were never chat-based, and this platform accepts that.
The result: you can apply the model to evaluation data already residing in Databricks, and retrieve the selected classifications and option probabilities as structured columns.
IV. My Assessment
The value here isn’t just “Databricks launched a feature”—it’s the pattern it demonstrates.
Previous articles we wrote on using decision models mostly stopped at the “how to make the model give a judgment” stage—how to construct prompts, read logprobs, normalize probabilities.
What this adds is the crucial next step: once the judgment is made, how do you use it?
The answer it provides is “turn it into a SQL function that can run on an entire table.” This form transforms a decision model from “a service you call” into “an operator you write into your query.”
Three concrete benefits:
- Data stays within the platform. The model runs alongside your data, rather than sending data out and fetching results back—this is decisive for enterprises with compliance requirements.
- Naturally suited for batch scenarios. Decision models are cheap, fast, and deterministic (a property we’ve repeatedly highlighted). These three traits together are exactly what’s needed to “run the same judgment on millions of rows.”
- Replaceable. Because the endpoint accepts any custom API, swapping SemIf-OpenJev for another open-source decision model requires no changes to the SQL.
One boundary to note: this is a vendor blog, primarily guiding you to use their platform. The Notebook and endpoint creation steps are tied to Databricks.
However, the pattern it demonstrates is transferable: if your decision model can be called as a SQL function, it can integrate into existing data pipelines, rather than being siloed in another service waiting to be integrated.
Links:
- Original: https://www.databricks.com/blog/running-open-jev-sql-databricks
- SemIf-OpenJev Repository: https://github.com/TheoLeeCJ/SemIf-OpenJev
- Databricks ai_query Documentation: https://docs.databricks.com/aws/en/sql/language-manual/functions/ai_query
- Companion Notebook: https://docs.databricks.com/aws/en/notebooks/source/machine-learning/serve-semif-decision-models.html
#Jev #Databricks #SQL
Similar Articles
@yibie: https://x.com/yibie/status/2102913925843161297
This article provides a detailed guide on using the Jev AI model cost-effectively through batch queries and its stateful billing mechanism, with specific configurations and code examples.
MiniLake Is a Local Databricks API Emulator with SQL, Delta Lake and Spark
MiniLake 是一个开源的本地 Databricks API 模拟器,提供真实的 SQL 执行(DuckDB)、真实的 Delta Lake 文件和真实运行的 Spark 作业,可在无云账号、无 API key 的情况下驱动 databricks-sdk、CLI、Terraform、Asset Bundles 及 MCP 智能体。
@yibie: https://x.com/yibie/status/2104076142500069608
This article demonstrates how to convert GLM-5.3-Flash into a Jev-style System 1 decision model, achieving typed decisions through a single forward pass. Benchmark tests show that it performs comparably to specialized models in terms of accuracy and speed.
@yibie: https://x.com/yibie/status/2102913383888465958
Together AI has open-sourced a complete recipe, allowing you to fine-tune your own Jev classification model for just $17, and has released a new model based on Qwen3.5 4B.
@yibie: https://x.com/yibie/status/2102914640707567798
This article tests the application of the Jev model in RAG retrieval, evaluating its effects on accelerating retrieval and reducing costs. Results show advantages in reranking and judging answerability.