В современных компаниях корпоративные хранилища данных (Data Warehouse) играют критически важную роль, обеспечивая централизованное хранение и обработку больших объёмов информации. Данные поступают из разнообразных источников: операционных систем, CRM, ERP, IoT-устройств, веб-аналитики, мобильных приложений и других платформ, отражая все аспекты деятельности организации. На основе этой информации компании формируют разного рода отчётность, отслеживают ключевые показатели эффективности (KPI), оптимизируют бизнес-процессы, прогнозируют рыночные тенденции и принимают стратегические решения.

Эффективная работа с хранилищем невозможна без участия бизнес- и системных аналитиков, которые проектируют структуры данных, очищают и объединяют информацию, адаптируя решения под меняющиеся задачи. С ростом объёмов данных и требований к скорости анализа даже опытные команды сталкиваются с вызовами. Рутинные операции — проектирование схем, поиск таблиц, проверка качества данных — требуют не только технических навыков, но и глубокого понимания бизнес-контекста. Большую часть времени занимает написание и оптимизация SQL-запросов, что становится «узким местом» в условиях динамично меняющихся требований.

Ошибки в SQL-запросах или недостаточное знание структуры данных приводит к потерям времени и снижению точности аналитики. Для решения этих проблем на помощь приходят технологии на основе больших языковых моделей (LLM), таких как GigaChat, GPT, BERT или DeepSeek. Обученные на исторических данных и журналах запросов, они способны автоматизировать подбор таблиц, JOIN-условий и шаблонов SQL. 

Я покажу на примере, как системные аналитики могут использовать настроенные LLM для упрощения написания SQL-запросов. Основная гипотеза состоит в том, что если адаптировать модель на специфических для определённого хранилища данных запросах, то можно рекомендовать таблицы, JOIN-условия и даже целые фрагменты запросов, основываясь на предыдущем опыте (журналах) и текущих потребностях. 

Подход к решению

Давайте используем большие языковые модели (LLM), которые предварительно обучены на обширных текстовых данных и способны генерировать текстовые последовательности. Однако стандартные LLM изначально не адаптированы для работы с конкретными хранилищами данных. Поэтому ключевым шагом является их дообучение (тонкая настройка, fine-tuning) на специфических данных и примерах запросов. Дообучение модели состоит из нескольких этапов:

• Подготовка данных. Сбор (генерация) журналов SQL-запросов к хранилищу за определённый период. Эти журналы содержат реальные примеры запросов, в том числе часто используемые таблицы, JOIN-условия и фрагменты кода. Изучение схемы базы данных позволяет выявить наиболее востребованные таблицы и индексы и связи между ними.

• Тонкая настройка модели. Использование подготовленных данных и специализированных методик для дообучения LLM. На этом этапе модель учится «понимать» специфику хранилища данных и может предлагать релевантные рекомендации.

• Оценка результатов модели. Применение метрик качества генерации текста.

Для генерации журналов SQL-запросов использовалась упрощённая модель данных (см. структуру в репозитории), созданная вручную и не имеющая практической применимости. Она представляет собой структуру, состоящую из 50 связанных между собой таблиц. Хотя эта модель не отражает реальных бизнес-процессов, она позволяет протестировать работу LLM в условиях «игрушечного» примера.

На основе модели мы сгенерировали  SQL-журналы (5000 примеров), содержащие примеры запросов, которые могли бы быть выполнены в реальной аналитической системе, но без использования реальных данных. Работает код следующим образом: 

• Читает описание таблиц, столбцов и связей между ними из Excel-файла (например, названия таблиц, типы данных колонок).

• Случайно выбирает таблицы и связи между ними.

• Добавляет условия фильтрации (WHERE), соответствующие типу данных (например, для чисел — сравнения, для дат — диапазоны).

• Формирует JOIN-условия на основе связей между таблицами:

  

• Разделяет каждый запрос на две части: «вопрос» (начало запроса) и «ответ» (продолжение), чтобы имитировать обучение модели «вопрос-ответ». Например:

  

Выбор языковой модели важен для успешного решения задачи генерации SQL-запросов, так как он напрямую влияет на качество, эффективность и применимость результатов. В первую очередь SQL имеет строгие правила построения запросов (например, использование ключевых слов, правильное расположение условий, соблюдение порядка операций). LLM, ориентированная на обработку естественного языка, может не справиться с этими требованиями. Также SQL-запросы зависят от определённой структуры базы данных (таблиц, столбцов, связей). Языковая модель должна уметь анализировать контекст и предлагать корректные JOIN-условия, фильтры и агрегации.

Поэтому использование модели, изначально ориентированной на генерацию кода, позволяет лучше учитывать особенности и обеспечивать более точные результаты. DeepSeek Coder — это специализированная языковая модель, разработанная для задач, связанных с программированием и генерацией кода. Она обучена на большом объёме данных, включающем в себя исходный код на различных языках программирования (например, Python, Java, SQL), и понимает синтаксис, структуру и логику программного кода.Модель доступна на платформе Hugging Face. 

Традиционный подход к тонкой настройке модели, при котором обновляются все параметры, становится неэффективным и ресурсоёмким из-за огромного размера современных LLM. Это делает полное дообучение дорогим, трудоёмким и зачастую непрактичным. Взамен был разработан метод параметро-эффективного обучения (Parameter-Efficient Fine-Tuning, PEFT), который позволяет оптимизировать производительность моделей, значительно снижая затраты на процессорного времени и памяти.

Эффективность fine-tuning языковых моделей объясняется их низкой внутренней размерностью — способностью адаптироваться к новым задачам, меняя лишь небольшую часть параметров. Методы, учитывающие внутреннюю размерность модели, позволяют сократить затраты на тонкую настройку.

PEFT — это техника тонкой настройки предобученных языковых моделей, которая сосредоточена на обучении лишь небольшой части параметров, оставляя основную массу весов модели неизменной. Идея заключается в том, чтобы адаптировать модель под конкретные задачи, обучая только небольшое подмножество параметров, в то время как большая часть модели остаётся замороженной. Этот подход обеспечивает высокую эффективность при минимальных затратах ресурсов. Преимущества PEFT:

• Обучение ограничено небольшим подмножеством параметров, что значительно ускоряет процесс.

• Тонкая настройка только части параметров уменьшает нагрузку на оборудование и сокращает затраты на хранение данных.

• Заморозка большинства параметров помогает избежать переобучения модели под новые данные.

• PEFT минимизирует эффект катастрофического забывания, позволяя модели адаптироваться к новым задачам без потери ранее приобретённых навыков.

• Контрольные точки, созданные с помощью PEFT, занимают меньше места, что упрощает их развёртывание и перенос на другие устройства.

Популярные методы PEFT:

• LoRA (Low-Rank Adaptation): использует низкоранговые матрицы для аппроксимации изменений весов модели.

• Adapter Modules: добавляет небольшие нейронные сети (адаптеры) между слоями модели.

• Prefix Tuning: добавляет обучаемые «префиксы» к скрытым состояниям модели.

• Prompt Tuning: модифицирует входные данные добавлением обучаемых «промптов».

• BitFit: обучает только смещения (bias) в параметрах модели, оставляя веса неизменными.

В своей работе мы использовали метод LoRA, который позволяет обучать только небольшое количество параметров, используя низкоранговые аппроксимации для изменения весов модели. Это значительно снижает требования к памяти и ускоряет обучение, сохраняя при этом высокую производительность модели. Кратко, пусть исходный вес слоя — матрица . LoRA добавляет декомпозицию низкого ранга: , где:

• — обучаемые матрицы ();

• — адаптация с рангом .

Таким образом, вместо обновления всех параметров матрицы метод LoRA требует оптимизации только параметров, содержащихся в матрицах и . Это существенно уменьшает количество обучаемых параметров. Для используемой LLM оптимизация на стадии настройки составила более 94 % (обучаемые 786 432 вместо 1 347 258 368 параметров).

Метрика ROUGE-L-SQL (Recall-Oriented Understudy for Gisting Evaluation — Longest Common Subsequence for SQL) адаптирует классический подход ROUGE-L для оценки структурной и семантической близости сгенерированных SQL-запросов к эталонным. Метрика основана на вычислении наибольшей общей подпоследовательности (Longest Common Subsequence, LCS) между SQL-запросами. В отличие от стандартных текстовых метрик, ROUGE-L-SQL учитывает синтаксические особенности SQL, включая:

• иерархию операторов (SELECT, JOIN, WHERE);

• контекстные зависимости между таблицами и полями;

• условия фильтрации и агрегации.

Для корректного сравнения SQL-запросов мы предварительно разделили их на логические единицы (ключевые слова SQL (например, SELECT, FROM, WHERE), идентификаторы (имена таблиц и столбцов), операторы (=, <, >), знаки пунктуации (;, ,, (, )), и др.) и токенизирировали. Этот процесс обеспечивает унифицированное представление запросов, независимо от их форматирования (например, регистр символов или пробелы).

Наибольшая общая подпоследовательность (LCS) — это последовательность токенов, которая встречается в обоих запросах в том же порядке, но не обязательно подряд. Формально, для двух последовательностей токенов и LCS определяется как:

,где: 

•  — подпоследовательность и , и ;

•  — длина ;

• максимум берётся по всем возможным общим подпоследовательностям и .

На основе LCS вычисляются три ключевые метрики: precision (P, измеряет долю токенов сгенерированного запроса, которые совпадают с токенами эталонного запрос), recall (R,измеряет долю токенов эталонного запроса, которые совпадают с токенами сгенерированного запроса) и F1-score (F1, представляет собой гармоническое среднее между precision и recall):

, где — длина сгенерированного запроса;

, где — длина эталонного запроса;

, если ; — в противном случае.

Дополнительной метрикой оценки качества модели может служить комбинация алгоритма сравнения абстрактных синтаксических деревьев (AST) и расстояния Левенштейна. Алгоритм сравнения AST в классе позволяет оценить структурную схожесть SQL-запросов, игнорируя поверхностные различия (алиасы, литералы, форматирование). Расстояние Левенштейна оценивает разницу между строками, представляющими структуры AST, то есть первым шагом SQL-запросы нормализуются (удаляются алиасы, заменяются литералы), преобразуются в AST-формат, затем определяется большая длина между двумя запросами (D) и расстояние Левенштейна (L). Схожесть (S) рассчитывается по формуле: .

Полный процесс обучения (три цикла) с использованием двух GPU Tesla T4 15 Гб занял около 86 минут с финальным ROUGE-L-SQL = 0,4497. В качестве тестового промта использовали часть случайного запроса (iput). Полученный результат (output) соединили с промтом и использовали для поиска сгенеренного ранее SQL-запроса по принципу максимальной похожести (AST-similarity). 

Заключение

Использование LLM для рекомендации SQL-запросов демонстрирует определённый потенциал в оптимизации работы аналитиков. Проведённое исследование показало, что тонкая настройка моделей на специфических данных хранилища позволяет эффективно генерировать структуры запросов, JOIN-условия и фильтры.  

Практическая значимость работы заключается в демонстрации возможности интеграции LLM в процессы системного анализа, особенно для задач с повторяющимися паттернами. Однако исследование имеет ограничения: использованная модель данных была искусственной, что может не полностью отражать сложность реальных хранилищ.  

Для получения более точных и значимых результатов необходимо провести:  

• Тестирование на реальных данных с учётом бизнес-контекста.  

• Эксперименты с другими архитектурами LLM и методами PEFT.  

• Разработку метрик, учитывающих не только синтаксическую, но и семантическую корректность запросов (например, через верификацию результатов выполнения).  

Внедрение подобных решений способно снизить нагрузку на аналитиков и минимизировать риски, связанные с человеческим фактором, что особенно актуально в условиях растущих объёмов данных.

Список используемых источников

• Scaling Down to Scale Up: A Guide to Parameter-Efficient Fine-Tuning - https://arxiv.org/pdf/2303.15647 

• INTRINSIC DIMENSIONALITY EXPLAINS THE EFFECTIVENESS OF LANGUAGE MODEL FINE-TUNING - https://arxiv.org/pdf/2012.13255 

• Instruction Tuning for Large Language Models: A Survey - https://arxiv.org/pdf/2308.10792 

• LORA: LOW-RANK ADAPTATION OF LARGE LANGUAGE MODELS - https://arxiv.org/pdf/2106.09685 

• DeepSeek LLM Scaling Open-Source Language Models with Longtermism - https://arxiv.org/pdf/2401.02954 

• Parameter-Efficient Fine-Tuning for Large Models: A Comprehensive Survey - https://arxiv.org/pdf/2403.14608 

• Abstract Syntax Tree for Programming Language Understanding and Representation: How Far Are We? - https://arxiv.org/pdf/2312.00413 

• ASTormer: An AST Structure-aware Transformer Decoder for Text-to-SQL - https://arxiv.org/pdf/2310.18662 

• SELF-INSTRUCT: Aligning Language Models with Self-Generated Instructions - https://arxiv.org/pdf/2212.10560 

• Don’t Stop Pretraining: Adapt Language Models to Domains and Tasks - https://arxiv.org/pdf/2004.10964 

• Lifelong Pretraining: Continually Adapting Language Models to Emerging Corpora - https://arxiv.org/pdf/2110.08534 

• Continual Pre-Training of Large Language Models: How to (re)warm your model? - https://arxiv.org/pdf/2308.04014 

Николай Абрамов, участник профессионального сообщества Сбера DWH/BigData. Профессиональное сообщество отвечает за развитие компетенций в таких направлениях как экосистема Hadoop, PostgreSQL, GreenPlum, а также BI инструментах Qlik, Apache SuperSet и др.