jevautoevalsbooleanmirrors autoevals.Sql

SQL

SQL judges whether two queries are semantically equivalent, meaning they return the same result set for the request, ignoring aliasing, formatting and column order. It mirrors autoevals Sql and returns the probability of equivalence.

Run this example in the console 1 jev question · answered inside one request
how it works // frame by frame

What the evaluator does

Jev reads the request, the candidate query and the reference query and returns p(equivalent). It reasons about joins, predicates and aggregation rather than string similarity.

frame 1/4 · the state
state
inputCustomers with more than 5 orders.
output… WHERE COUNT(*) > 5 GROUP BY customer_id
expected… GROUP BY customer_id HAVING COUNT(*) > 5
question → jev

The SQL in `output` returns the same result set as `expected` for the request in `input`, ignoring formatting and aliasing.

p(yes)
12%
noyes
different resultsconfidence |p − 0.5| × 2 = 76%the 0.5 line is yours to move
exactly what jev is asked

The question, verbatim

This is the question the API sends for the example below, generated from the same code path the playground and API use. Jev sees the request fields as state and returns a probability for each outcome. Nothing is generated, so there is nothing to parse.

eqnoul · p(yes)

The SQL query in `output` returns the same result set as the SQL query in `expected` for the request in `input`, ignoring formatting, aliasing, and column order.

when to use it

Reach for it when

  • Text-to-SQL evaluation where many correct queries exist.
  • Regression tests for query generators after a schema or prompt change.

Not the right tool when

  • You can execute both queries against a database; execution match is the gold standard.
  • Queries touch tables the reference does not; equivalence is undefined.

Watch out for

  • Subtle predicates (BETWEEN inclusivity, LEFT vs INNER JOIN, HAVING vs WHERE) are exactly where judges fail; the jeval benchmark tracks this category for that reason.
  • Provide the schema in `input` when column semantics matter.
inputs and example

What to send

required fields
outputexpected
optional fields
input
in suites
CorrectnessEverything
result shape

score 0–1 (p of the good outcome), label “nn% yes”, confidence |p − 0.5| × 2, probabilities yes/no, passed at 0.5.

POST /api/v1/evaluateopen in console
{
  "evaluators": [
    "sql"
  ],
  "input": "Customers with more than 5 orders.",
  "output": "SELECT customer_id FROM orders WHERE COUNT(*) > 5 GROUP BY customer_id",
  "expected": "SELECT customer_id FROM orders GROUP BY customer_id HAVING COUNT(*) > 5"
}
expected

Not equivalent: aggregate in WHERE is invalid; p(equivalent) should be low.

rolling it up

Aggregate with

One result per item is a fact; a dataset of them is a metric. These are the aggregations that fit this evaluator's output shape.

related evaluators
questions people ask
Does the SQL evaluator run the queries?
No. It judges semantic equivalence from the query text. If you can execute both, prefer an execution match and use this as a fast pre-check.