Text-to-SQL ломается не из-за модели. Он ломается из-за схемы
Многие считают, что проблема в LLM или в неудачном промпте. На практике всё проще: модель не видит правильные связи между таблицами.
Вот пример. Запрос вроде «какие издатели получили выплаты выше 5000». Векторный поиск подтянет publisher и royalty_ledger. Всё звучит логично. Но он пропустит vendor_agreement, то есть таблицу, которая как раз и соединяет их между собой.
В итоге SQL выглядит корректным. Но возвращает ноль строк.
Это системный недостаток всех решений на embeddings. Они ищут по смыслу, но не понимают структуру базы данных.
Рабочий подход другой. Схему нужно воспринимать как граф.
Таблицы в нём выступают узлами. Foreign keys выступают связями. Запрос решается не поиском похожих слов, а обходом графа и поиском join-пути.
Именно по такому принципу работает QueryWeaver.
Он строит граф базы и при запросе сам находит весь путь, включая промежуточные таблицы. Даже если это цепочка из нескольких шагов.
На практике это выглядит так. В тесте с базой на 60 таблиц он разобрал 5-шаговый запрос через цепочку superpower → capability_matrix → stakeholder_registry → resource_requisition → budget_allocation.
Векторный поиск увидел только начало и конец. Всё между ними он потерял, потому что “stakeholder” никак не связан по смыслу с “superpower”.
Для графа это не проблема. Он просто находит единственный путь между сущностями.
И это меняет всё.
Проект open-source, его можно развернуть у себя и наконец получить text-to-SQL, который действительно работает.