Инженерная миграция БД с помощью локальной LLM: как превратить слабую модель в надежный инструмент

# Инженерная миграция БД с помощью локальной LLM: как превратить слабую модель в надежный инструмент

Команда коммерческого департамента Avito столкнулась с задачей масштабной миграции витрин данных с базы Vertica на движок Trino. Нужно было перевести около 65 витрин, каждая из которых содержала от 500 до 4000 строк сложного SQL-кода. Традиционные методы, такие как использование регулярных выражений или готовых конвертеров вроде SQL Glot, не обеспечивали требуемой точности. Обращение к облачным LLM (Large Language Models) было невозможно из-за политики конфиденциальности данных и ограничений на использование бесплатных лимитов.

Разработчики выбрали путь использования локальных моделей, но быстро поняли, что простого промпта «переведи этот код» недостаточно. Мелкие модели страдают от проблем с контекстом, галлюцинаций и утраты структуры сложных запросов. В итоге команда создала не просто «переводчик», а полноценную инженерную систему, которая позволяет управлять процессом миграции, воспроизводить его и минимизировать ошибки.

*«Мы не нашли модель, которая сама безошибочно переводит Vertica SQL в Trino SQL. Но слабую локальную LLM можно сделать полезной, если не требовать от неё идеального результата с первого раза»,* — отмечали авторы кейса.

Почему «подобрать идеальный промпт» не сработало

Изначальной идеей было предоставить модели полный код витрины и попросить её выполнить перевод. Однако на практике возникла проблема, которую авторы назвали «контекстным гниением» (context rot). Локальные модели, особенно объемом до 30 миллиардов параметров, теряют информацию по мере увеличения количества токенов в запросе. При отправке кода на 2000+ строк (около 30–40 тысяч токенов) модель начинает забывать правила, пропускать фрагменты кода и искажать структуру запроса.

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

Архитектура модульного пайплайна

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

1. Split (Разбиение): Большой код делится на мелкие части. Это снижает нагрузку на контекстное окно модели, позволяет локализовать ошибки и упрощает управление версиями. 2. Translate (Перевод): Отдельные части кода обрабатываются с помощью компилированного модуля DSPy. Здесь же происходит оптимизация промптов на основе изолированных паттернов, а не полных витрин. 3. Pattern_guard: Этап фильтрации через регулярные выражения. Система ищет заведомо запрещенные конструкции Vertica, которые не должны попасть в код Trino. 4. Assemble (Сборка): Финальное соединение обработанных частей. 5. Api_validate: Проверка соблюдения платформенных требований к витринам (проверка заголовков, допустимых объектов). 6. Trino_test: Техническая проверка исполнимости кода в среде Trino. При ошибках модель получает обратную связь и может предложить исправления. 7. Compare: Сравнение итоговых данных с эталонной витриной (копия в Trino). Этот этап проверяет не просто наличие строк, а семантическое сходство ключей, метрик и обработки NULL-значений. 8. Metadata: Вся история процесса, зависимости между шагами и артефакты записываются в файл metadata.json. Это позволяет возобновить работу после сбоя и отслеживать прогресс через дашборд.

DSPy: от шаманства к инженерному циклу

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

Для оценки качества перевода использовалась прокси-метрика, состоящая из трех частей: * LLM-score (60%): Оценка модели-судьи относительно исходного паттерна и эталона. * Validity (20%): Проверка на отсутствие запрещенных синтаксических конструкций. * Exact match (20%): Совпадение текста на основе меры схожести Jaccard.

Эксперименты показали, что попытка заставить модель «подумать» (разрешение reasoning mode) увеличило время работы в 8 раз, но не дало прироста качества перевода. Также выяснилось, что промпты, хорошо работающие с одной моделью (например, Qwen), могут полностью провалиться с другой (Gemma), что требует подхода к настройке каждого инструмента индивидуально.

В итоге была выбрана модель Gemma 4 31b, которая продемонстрировала лучший баланс между качеством перевода, стабильностью контекста и скоростью обработки.

Результаты и перспективы

На момент публикации статьи команда успешно перевела 15 витрин. Время обработки одной витрины сократилось с 3–5 часов до 30–60 минут. Система доказала свою воспроизводимость: она позволяет безопасно возвращаться к прерванным процессам и накапливать историю ошибок.

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

Следующие шаги развития включают расширение датасета типичными ошибками и их исправлениями, а также совершенствование модуля сравнения для более глубокой диагностики расхождений на уровне ключей и метрик.

Таким образом, кейс Avito демонстрирует, что даже ограниченные локальные модели могут стать мощным инструментом в руках инженеров, если их правильно встроить в контролируемую экосистему.