Вообще, забавно, как много людей, столкнувшись с чем-то вроде "напиши-ка мне SQL-запрос", ощущают внутренний протест — будто бы их зовут в спортзал после тяжёлой пятницы. Понимаю, сам когда-то пялился в схемы, как мышь на глобус, и думал: а нельзя ли это всё как-то… ну, проще? Без этой всей магии SELECT, JOIN, FROM и прочих SQL-мантр, которые будто специально придуманы, чтобы отпугивать новичков (или делать вид, что мы, старички, что-то такое умеем, за что платят чуть больше минималки).
В 2025-м, к счастью, стало появляться всё больше инструментов, которые превращают загадку SQL-запросов в нечто более дружелюбное. Один из таких — QueryWeaver. Он вроде бы только начал мелькать в чатах энтузиастов, но, похоже, скоро его будут обсуждать в кофейнях под окнами серверных. Почему? Давай разбираться, без формализма и лишних реверансов.
"А зачем вообще Text2SQL?" — риторический вопрос
Если ты хоть раз писал SQL-запрос по схеме, где табличек больше трёх, а связей между ними больше, чем любимых сериалов в твиттер-ленте, ты знаешь, что это почти квест. Один не туда поставленный INNER JOIN — и всё, результат уходит в бесконечность, как тост на корпоративе.
Text2SQL — штука простая в идее, сложная в реализации. Ты пишешь: "Покажи мне всех клиентов, у которых нет заказов за последний месяц", а инструмент уже сам колдует над схемой, строит связи и выдаёт тебе готовый запрос. Красота! Только вот у большинства таких решений были нюансы: то схема не учитывается, то вопросы можно задавать только строго определённым образом, то поддержка современных SQL-диалектов условная, то всё держится на закрытых API. А иногда — всё сразу.
QueryWeaver: не просто переводчик, а чуть ли не шаман
QueryWeaver вышел на сцену не как ещё один переводчик с "человеческого" на SQL, а как нечто более гибкое — своего рода "плетельщик запросов" (название, кстати, абсолютно в точку).
Что сразу цепляет — это подход к схеме данных. Большинство Text2SQL-движков пытаются натянуть схему на внутренний формат, обычно что-то табличное, линейное, без нюансов связей. А QueryWeaver идёт другим путём: он строит граф-подобное представление схемы. Это, конечно, не совсем тот граф, что во всяких NoSQL, но близко: таблицы и связи становятся узлами и рёбрами в "мысленном" графе.
Зачем это вообще нужно? Ну вот смотри: обычная реляционная база, десяток таблиц, у каждой куча связей, многие опциональные, часть — вообще циклические. Если смотреть на это как на граф, связи проще визуализировать, легче находить "кратчайшие пути" между сущностями, проще объяснять нейросети, как запросить то или иное поле. В итоге, когда ты спрашиваешь QueryWeaver что-то вроде "Покажи мне имена сотрудников, у которых больше трёх проектов", движок не шарахается между таблицами, а спокойно находит нужный путь по графу — и строит запрос, который действительно работает.
Кратко о главном: как это вообще работает?
В двух словах:
- Получаешь схему — QueryWeaver "съедает" описание базы, превращает его в свой внутренний граф.
- Пишешь обычный вопрос — на английском (или на другом поддерживаемом языке, если появится).
- QueryWeaver анализирует вопрос, находит в графе нужные узлы, строит запрос, который отражает суть вопроса.
- Готово — ты получаешь SQL, который можно запускать хоть в консоли, хоть через ORM, хоть в BI-системе.
Но это, конечно, упрощённая картина. Под капотом там кипит своя жизнь: сложная логика маппинга, работа с разными SQL-диалектами, и (что не менее важно) защита от всяких дурацких или небезопасных запросов.
Model Context Protocol — зачем это вообще и кому нужно?
Тут мы подходим к тому, что отличает QueryWeaver от других "похожих". Большинство Text2SQL тулов — это либо обёртки вокруг LLM (вроде, ну ты понял, той известной нейросети, про которую все шутят в мемах), либо просто коробочные решения "скачай и страдай".
А QueryWeaver поддерживает Model Context Protocol. По-простому, это такой стандарт общения между твоим приложением и инструментом, который позволяет не просто слать запросы, а управлять контекстом модели через HTTP-эндпоинты. Что это даёт? Ну, как минимум, возможность динамически загружать схемы, менять настройки, запускать разные пайплайны обработки — прямо на лету, через API.
Если говорить совсем приземлённо — ты можешь разворачивать QueryWeaver хоть как отдельный сервис в микросервисной архитектуре, хоть как вспомогательный инструмент для своего SQL-ассистента, хоть интегрировать его в no-code платформу. Протокол открытый, описан, всё по-взрослому.
Кому, когда и зачем это всё?
Лирический вопрос. Прямо сейчас инструмент больше всего подходит:
— Тестировщикам, которым надо быстро проверить, как работает их база, не копаясь в таблицах вручную
— Программистам, которые строят свои BI-системы и хотят дать пользователям "умный поиск"
— Авторам внутренних чат-ботов, где нужен поиск по данным без знания SQL
— Стартапам, которые не могут себе позволить дорогой закрытый продукт, но хотят Text2SQL прямо сейчас
— Всем, кто хотя бы раз бился лбом о "где тут join, а где подзапрос" — реально, берёшь и пробуешь
Минусы? Конечно, не без них
Буду честен — идеальных решений не бывает, и QueryWeaver не исключение. Самое очевидное: всё ещё идёт активная разработка. То есть если ты хочешь развернуть его "в прод" в банке, придётся поиграть в бета-тестера и потыкать API, иногда подкручивая под себя.
Второе — не волшебник, если схема описана очень криво, связи теряются или не отражают реальные отношения в базе, чудес не будет. Но это, кажется, честно: даже люди с таким не справляются.
Ну и, наконец, да, иногда генерация запроса может занять чуть больше времени, чем если бы ты сам писал руками. Но в большинстве задач выигрываешь на этапе "понять, что вообще спросить", а не на этапе "писать всё вручную".
Как развернуть и что дальше?
Всё просто — проект на GitHub, ставится на любую систему, где есть Python 3.10+ (хотя, лучше свежие версии, как всегда), поддерживает запуск на web, можно воткнуть хоть в облако, хоть на локалку. Официальный способ: клонируешь, ставишь зависимости, читаешь README (да, он на нормальном английском), запускаешь сервис — дальше работаешь с HTTP API, либо используешь готовый клиент.
Можно интегрировать с чем угодно — от внутренней панели для аналитика до корпоративного чат-бота (или что там сейчас модно). Архитектура гибкая, документация открыта, коммьюнити растёт.
К чему всё это?
В 2024 году уже не модно страдать от SQL-запросов. Модно быстро и просто получать нужные данные, не пялясь в документацию сутками. QueryWeaver — как раз из той породы инструментов, которые делают жизнь проще, не превращая тебя в мага баз данных. Может, со временем он и станет стандартом для всех, кто не хочет больше бояться слова JOIN.
Советую просто попробовать. А вдруг он закроет твой личный "SQL-боль"? В общем, если хочешь пощупать — все дороги ведут на их GitHub:
QueryWeaver на GitHub:
github.com/FalkorDB/QueryWeaver