Миграция Vertica на Trino: как локальная LLM справляется с переводом SQL-витрин

Команда BI-разработчиков коммерческого департамента Авито — Алексей Дубинец и Павел Беспалов — столкнулась с задачей миграции около 65 витрин данных с Vertica на Trino. Витрины представляют собой сложные SQL-скрипты: header управления, временные таблицы, преобразования и обогащение логики. В одной таблице могло быть от 500 до 4000 строк кода. Ручной перевод — долгий и дорогой, а готовых инструментов в открытом доступе не нашлось. Рассматривались SQL Glot и RegExp, но они не давали нужного качества. Облачные LLM использовать нельзя: компания не готова передавать бизнес-логику и внутренние данные наружу, к тому же 5-часовые лимиты быстро исчерпываются. Поэтому выбор пал на локальные модели — они условно бесплатны и работают в контуре компании.

Однако локальные LLM показали серьёзные ограничения. Качество маленьких моделей на порядок хуже облачных: они плохо держат контекст, теряют структуру запроса, пропускают правила из промпта и галлюцинируют. Проблема усугубляется «контекстным гниением» (Context rot): у моделей на 30B moe деградация качества наступает уже на контексте более 30 000 токенов. Полный SQL-код витрины на 2000+ строк может занимать 30 000—40 000 токенов, что превышает рабочий порог. Модель также может путать диалекты: в обучающих данных мало примеров Trino SQL, поэтому она выдает конструкции из других диалектов, так как не умеет сказать «я не знаю».

Инженеры пришли к выводу, что нужна не просто модель, а инженерная система, которая ограничивает область ответственности модели, разбивает задачу на части, сохраняет промежуточные состояния и проверяет результат. Так родился проект на базе DSPy framework. Архитектура — модульный пайплайн с оркестратором, который управляет порядком стадий и записывает metadata.json. Ключевой этап — Split: разбиение SQL на блоки, чтобы уменьшить контекст и сделать каждую итерацию перевода стабильнее. Это позволяет видеть статус каждого блока, хранить версии правок, локализовать ошибки и продолжать работу с нужного места.

Этап Translate обрабатывает каждую часть через compiled DSPy модуль. DSPy — это фреймворк для оптимизации промптов и весов LLM, который позволяет компилировать модули перевода и автоматически подбирать примеры. Проверка результата трансляции — отдельная стадия, где выявляются неявные ошибки, которые модель не замечает. Какие именно модели сработали, авторы не уточняют, но отмечают, что даже слабая локальная модель становится полезной, если правильно организовать процесс вокруг неё.

Проект уже дал результаты: перевод витрин стал воспроизводимым, а не «магическим». В выводах авторы подчеркивают, что это не история про «царь-промпт», а про инженерную обвязку. Дальнейшее развитие — улучшение проверок, возможно, использование более сильных локальных моделей по мере их появления. Для отрасли это показательный кейс: миграция между SQL-диалектами — частая задача, и локальные LLM могут быть решением, если подойти к ним как к инструменту со слабостями, а не как к универсальному решению.