{}

{titlePrefix}Confusion Matrix (Normalized)

{}

Predicted

{}

{displayPredictedLabels.left}

{displayPredictedLabels.right}

{}

Actual

{displayActualLabels.top}

{showCounts &&

{displayMatrix.tl.count}

}

{formatValue(displayMatrix.tl.pct)}

{showCounts &&

{displayMatrix.tr.count}

}

{formatValue(displayMatrix.tr.pct)}

{}

{displayActualLabels.bottom}

{showCounts &&

{displayMatrix.bl.count}

}

{formatValue(displayMatrix.bl.pct)}

{showCounts &&

{displayMatrix.br.count}

}

{formatValue(displayMatrix.br.pct)}

{}

{displayFormat === "fraction" ? "0.0" : "0%"}

{palette.map((color, idx) =>

)}

{displayFormat === "fraction" ? "1.0" : "100%"}

; }; export const BooleanClassificationReport = ({report, negativeLabel = "Not Advanced", positiveLabel = "Advanced", negativeClass = "False", positiveClass = "True", maxWidth = 520}) => { const parseReport = reportStr => { const lines = reportStr.trim().split('\n').filter(line => line.trim()); const result = { classes: [], accuracy: null, macroAvg: null, weightedAvg: null, totalSupport: null }; for (const line of lines) { const parts = line.trim().split(/\s+/); if (parts[0] === 'precision') continue; if (parts.length >= 5 && !['accuracy', 'macro', 'weighted'].includes(parts[0])) { result.classes.push({ name: parts[0], precision: parseFloat(parts[1]), recall: parseFloat(parts[2]), f1: parseFloat(parts[3]), support: parseInt(parts[4], 10) }); } if (parts[0] === 'accuracy') { result.accuracy = parseFloat(parts[1]); result.totalSupport = parseInt(parts[2], 10); } if (parts[0] === 'macro' && parts[1] === 'avg') { result.macroAvg = { precision: parseFloat(parts[2]), recall: parseFloat(parts[3]), f1: parseFloat(parts[4]), support: parseInt(parts[5], 10) }; } if (parts[0] === 'weighted' && parts[1] === 'avg') { result.weightedAvg = { precision: parseFloat(parts[2]), recall: parseFloat(parts[3]), f1: parseFloat(parts[4]), support: parseInt(parts[5], 10) }; } } return result; }; const parsed = parseReport(report); if (parsed.classes.length < 2) { return

BooleanClassificationReport: Could not parse report. Expected at least 2 classes.

; } const negClass = parsed.classes.find(c => c.name === negativeClass) || parsed.classes[0]; const posClass = parsed.classes.find(c => c.name === positiveClass) || parsed.classes[1]; const tnPlusFp = negClass.support; const tpPlusFn = posClass.support; const tn = Math.round(negClass.recall * tnPlusFp); const fp = tnPlusFp - tn; const tp = Math.round(posClass.recall * tpPlusFn); const fn = tpPlusFn - tp; const tnPct = tn / tnPlusFp * 100; const fpPct = fp / tnPlusFp * 100; const fnPct = fn / tpPlusFn * 100; const tpPct = tp / tpPlusFn * 100; const rowStyle = { borderBottom: "1px solid rgba(148, 163, 184, 0.3)" }; const cellStyle = { padding: "0.5rem 0.125rem" }; const centerCellStyle = { textAlign: "center", padding: "0.5rem 0.125rem" }; return

{} {}

	Precision	Recall	F1-Score
{negativeLabel}	{negClass.precision.toFixed(2)}	{negClass.recall.toFixed(2)}	{negClass.f1.toFixed(2)}
{positiveLabel}	{posClass.precision.toFixed(2)}	{posClass.recall.toFixed(2)}	{posClass.f1.toFixed(2)}

{}

; }; export const DefinitionCard = ({children}) => { return

{children}

; }; export const Scale = ({low, mid, high, lowLabel = "Low", midLabel = "Mid", highLabel = "High", lowDescription, midDescription, highDescription, midColor = "yellow", inverted = false}) => { const lowColor = inverted ? "green" : "red"; const highColor = inverted ? "red" : "green"; const gradientId = inverted ? "greenToRed" : "redToGreen"; return

{low}

{mid &&

{mid}

}

{high}

{lowLabel}

{lowDescription &&

{lowDescription}

}

{mid &&

{midLabel}

{midDescription &&

{midDescription}

}

{highLabel}

{highDescription &&

{highDescription}

}

; }; SQL Efficiency acts as a heuristic query cost analyzer, assessing whether a generated SQL query is structured efficiently or poses an availability risk to the database. ## Metric definition SQL Efficiency — A binary metric that evaluates whether the generated SQL query avoids known performance anti-patterns and resource exhaustion risks. * Type: Binary * 1 (Performant): The query is structured efficiently and poses no obvious availability risk. * 0 (Non-Performant): The query uses known anti-patterns or poses a resource exhaustion risk. This metric assumes the generated SQL is semantically correct and secure. Its primary purpose is to assess query efficiency and identify potential Denial of Service (DoS) risks to downstream databases. Here's a scale that shows the relationship between SQL Efficiency and potential impact on your AI system: Scale is 0-100 and is derived from binary judgments converted into a confidence score. ## Calculation method SQL Efficiency is computed through a comprehensive code review process: One or more evaluation requests are sent to an LLM evaluator to analyze the SQL query for performance anti-patterns. A specialized chain-of-thought prompt guides the model to evaluate the query for efficiency issues including cross-product detection, resource exhaustion risks, index suppression, and structural flaws. The evaluator analyzes the query for known anti-patterns such as Cartesian joins, unbounded recursive CTEs, non-SARGable predicates, inefficient outer join filtering, and correlated subqueries. Based on the evaluation, a binary score is assigned: 1 (Performant) if the query is efficient, or 0 (Non-Performant) if anti-patterns are detected. This metric is computed by prompting an LLM and may require multiple LLM calls to compute, which can impact usage and billing. ## Supported nodes * LLM span Inputs considered (when available): * The generated SQL query (output) * Optional context such as the natural language query * Schema information for understanding table relationships ## What constitutes efficient (1) * **Avoids Anti-Patterns**: No known, statically detectable performance anti-patterns. * **No Resource Exhaustion**: No obvious structures like Cartesian joins or unbounded recursive CTEs. * **Efficient Filtering**: Filters correctly placed (e.g., ON clause for LEFT JOIN conditions). * **Index-Friendly**: Predicates structured to allow index utilization. ## What constitutes inefficient (0) ### Unconstrained Cartesian Joins Multiple tables listed without linking conditions, creating massive data explosions: ```sql theme={null} -- Inefficient: Creates N × M rows SELECT T1.name, T2.dept_name FROM employees AS T1, departments AS T2 -- Efficient: Properly joined SELECT T1.name, T2.dept_name FROM employees AS T1 JOIN departments AS T2 ON T1.dept_id = T2.id ``` ### Unsafe Recursive CTEs Recursive Common Table Expressions without proper termination conditions: ```sql theme={null} -- Inefficient: Resource exhaustion risk WITH RECURSIVE NumberSequence AS ( SELECT 1 as num UNION ALL SELECT num + 1 FROM NumberSequence WHERE num < 100000 ) SELECT * FROM NumberSequence ``` ### Inefficient Outer Join Filtering Placing filters for outer-joined tables in WHERE instead of ON: ```sql theme={null} -- Inefficient: Nullifies LEFT JOIN behavior SELECT T1.dept_name, T2.name FROM departments AS T1 LEFT JOIN employees AS T2 ON T1.id = T2.dept_id WHERE T2.name = 'John' -- Efficient: Filter in ON clause SELECT T1.dept_name, T2.name FROM departments AS T1 LEFT JOIN employees AS T2 ON T1.id = T2.dept_id AND T2.name = 'John' ``` ### Index-Suppressing Predicates (Non-SARGable) Wrapping columns in functions prevents index usage: ```sql theme={null} -- Inefficient: Forces full table scan WHERE YEAR(date_col) = 2023 -- Efficient: Allows index usage WHERE date_col BETWEEN '2023-01-01' AND '2023-12-31' ``` ### Other Anti-Patterns * **SELECT \***: Retrieving all columns when only specific ones are needed * **Correlated Subqueries**: Subqueries referencing outer query columns (N+1 problem) * **Implicit Type Casting**: Comparing mismatched types (e.g., VARCHAR to unquoted integers) * **Misplaced HAVING**: Using HAVING for non-aggregated column filters * **Unnecessary DISTINCT**: Deduplicating already-unique columns * **Inefficient UNION**: Using UNION when UNION ALL suffices ## Example use cases * Pre-flight validation of generated SQL before execution on production databases. * Identifying potential DoS risks in user-facing Text-to-SQL applications. * Training and improving SQL generation models to avoid anti-patterns. * Code review automation for data analytics pipelines. **Example**: A business intelligence platform where users generate ad-hoc queries — SQL Efficiency catches a generated query with a missing JOIN condition that would create a Cartesian product of 10 million rows, preventing a potential database outage. ## Best practices Providing the SQL dialect and schema information helps the evaluator understand dialect-specific anti-patterns and table relationships for optimization analysis. Use alongside SQL Correctness and SQL Adherence for comprehensive validation of generated queries. Use continuous learning via human feedback to tune detection for your specific database patterns. Manually review inefficient queries to understand patterns and improve your SQL generation prompts. ## Performance Benchmarks We evaluated SQL Efficiency against human expert labels on an internal dataset of Text-to-SQL samples using top frontier models. | Model | F1 (True) | | :--------------------- | :-------: | | GPT-4.1 | 0.90 | | GPT-4.1 Mini | 0.87 | | Gemini 3 Flash Preview | 0.87 | | Claude Sonnet 4.5 | 0.83 | ### GPT-4.1 Classification Report Benchmarks based on internal evaluation dataset. Performance may vary by use case. ## Related Resources If you would like to dive deeper or start implementing SQL Efficiency, check out the following resources: ### Examples * [SQL Efficiency Examples](https://app.galileo.ai) - Log in and explore the "SQL Efficiency" Log Stream in the "Preset Metric Examples" Project to see this metric in action. ### Related Concepts * [SQL Adherence](/concepts/metrics/text2sql/sql-adherence) * [SQL Correctness](/concepts/metrics/text2sql/sql-correctness) * [SQL Injection](/concepts/metrics/text2sql/sql-injection)