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.
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.
The SQL in `output` returns the same result set as `expected` for the request in `input`, ignoring formatting and aliasing.
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.
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.
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.
What to send
score 0–1 (p of the good outcome), label “nn% yes”, confidence |p − 0.5| × 2, probabilities yes/no, passed at 0.5.
{
"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"
}Not equivalent: aggregate in WHERE is invalid; p(equivalent) should be low.
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.
Accuracy is the share of items the evaluator got right.
Precision is the share of predicted positives that were really positive; recall is the share of real positives the evaluator caught; F1 is their harmonic mean, which is only high when both are.
The Brier score measures probability quality: the mean squared difference between a predicted probability and what actually happened (1 or 0).
- 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.