🔗 Text2SQL в аналитике: как мы научили ИИ понимать бизнес-запросы без посредников

В этой статье 🖤 описывают, как внедряли Text2SQL, какие модели использовали и обрисовали общую проблематику, реализуя у себя.

Для решения простых задач используется аналитика (быстрая выгрузка, метрика в срезе и др.). Конечно, большую часть данных можно получить из имеющейся отчетности, но что, если нужно ответ узнать сразу? Вместо того, чтобы лезть по сотням дашбордов, где периодически данные могут не биться (так как сборка осуществляется по-разному).

Пишете в бота: «Средний чек Москва, 2025 vs 2024, динамика в%» → Через 15 секунд получаете точный ответ с трендом.

❓ Как выглядит пайплайн? (упрощение).

1. Запрос пользователя, промпт с описанием таблицы 2. Text2SQL (LLM) 3. Определение типа визуализации. 4. Бекенд -> БД (забрать данные) 5. Чат

Я начал потихоньку реализовывать эту логику на имеющихся витринах, но столкнулся с тем, что периодически модель может галлюцинировать (как это указано в статье, выдавая несуществующие колонки), ну и возникают дополнительные сложности, о которых ниже.

😜 В качестве MVP предлагается собрать одну витрину. В примере X5 — это табличка с > млрд. строк и ~150 колонок.

Наша цель — не просто построить вопросно-ответную систему, а создать полноценного ассистента, который учитывает контекст и историю диалога. Например, если после первого запроса пользователь пишет: «А сгруппируй не по кластерам, а по магазинам», нам необходимо объединить предыдущие сообщения с новым уточнением. Для этого мы получаем историю из backend, определяем, является ли текущий запрос продолжением, и, если да — формируем краткое суммарное описание диалога. В противном случае передаём исходный запрос без изменений.

🍪🍪 Основные вызовы при решении задачи:

1. Написать логику сборки метрик 2. Учитывать контекст предыдущих сообщений 3. Обработка естественного языка и неоднозначных формулировок 4. Борьба с галлюцинациями 5. Оптимизация скорости и ресурсов 6. Работа с большими схемами данных 7. Интерпретация результата 8. Валидация качества работы модели. В качестве метрики использовали (LLM + EX) / 2 для сравнения нескольких моделей.

🐸 Метрика для оценки качества (LLM + EX) / 2

Метрика рассчитывается через попарное сравнение отсортированных колонок. У этого подхода есть ограничения: если, например, модель вывела долю вместо процента — получим False Negative. Если пользователь сформулировал общий запрос, допускающий несколько корректных SQL-вариантов, то результат также будет считаться ошибкой.

LLM. Совпадает ли сгенерированный SQL с эталонным по логике запроса. EX (Execution Accuracy). Совпадает ли результат выполнения запроса (таблица/агрегация) с заранее написанным ответом.

🐸 Результаты моделей:

DeepSeek R1 (0.765) — лидер по совокупному качеству: наиболее точные и осмысленные SQL-запросы. Qwen 2.5-72B (0.425) — уверенное второе место, компромисс между качеством и ресурсами. SQLCoder-8B (0.185) — слабый результат: частые галлюцинации и ошибки исполнения.

В итоге команда X5 остановилась на Qwen 2.5-72B.

✈️ Дальнейшие планы:

1. Поддержка нескольких таблиц 2. Поддержка запросов с джойнами 3. Внедрение классификации запросов пользователей по сложности 4. Дообучение собственной модели 5. Замена LLM на более лёгкие модели 6. Работа с произвольными Excel-файлами 7. Schema-linking на основе RAG’a

✏️ Дополнительные комментарии

Также, при выборе модели, подходящей под использование на том или ином шаге мы учитываем сложность задачи - например, для перевода технических названий колонок на русский язык с учетом контекста запроса мы выбрали использование более легковесной модели: Qwen3-4B, чтобы ускорить работу системы. Для сложных этапов как, например, генерация SQL, мы используем модели побольше.

Кайф, когда такие вещи реально разгружают аналитику от рутины и освобождают время на исследования и развитие продукта

🔗 За полной статьей сюда, дублирую ссылку.

Ставьте 🐳****, если понравилась статья (ну и конечно, если ждете сборник методов по 🆎)