22.04.2026 11:32
🖥 Text-to-SQL ломается не из-за модели.
🖥 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, который реально работает.
https://github.com/FalkorDB/QueryWeaver
Большинство думает, что проблема в 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, который реально работает.
https://github.com/FalkorDB/QueryWeaver