Semantic validation SQL vs NL-запрос
Как проверить, что сгенерированный SQL возвращает именно то, что пользователь попросил на человеческом языке?
Короткий ответ
Нужно привести NL-запрос и SQL к сопоставимому структурному виду: intent, metrics, dimensions, filters, joins, grouping, ordering и time range.
Полный разбор
Один практичный путь - строить промежуточное представление. Из пользовательского запроса извлекаем intent: какие сущности нужны, какая метрика, какие измерения, фильтры, период, сортировка и лимит. SQL парсим в AST и извлекаем те же поля: SELECT, WHERE, GROUP BY, JOIN, ORDER BY, LIMIT.
Дальше сравниваем структуры: например, пользователь просил sales volume, а SQL выбирает price; просил клиентов за месяц, а SQL фильтрует по дате заказа без timezone; просил top sellers, а SQL не сортирует по нужной метрике.
LLM может помочь как semantic judge, но лучше просить structured verdict: matched fields, missing constraints, suspicious joins, ambiguity. Для критичных запросов нужны regression examples и golden SQL или хотя бы expected plan.
Теория
Это задача semantic equivalence, а не только text similarity. SQL может быть синтаксически корректным и все равно отвечать на другой вопрос.
Типичные ошибки
- Сравнивать NL и SQL строково.
- Не проверять агрегаты, grouping и time filters.
- Не обрабатывать неоднозначность пользовательского запроса.
Как отвечать на собеседовании
- Скажи "SQL AST" и "intermediate representation".
- Приведи пример несовпадения: price vs sales volume.