Авито перевела 65 витрин данных с Vertica на Trino: локальные LLM справились без облака

Алексей Дубинец и Павел Беспалов из коммерческого департамента Авито описали проект миграции SQL-витрин между двумя базами данных. Каждая витрина содержала от 500 до 4000 строк кода с временными таблицами, преобразованиями и бизнес-логикой. Ручной перевод был дорогим и нестабильным, существующие инструменты вроде SQL Glot и регулярных выражений задачу не решали, а облачные LLM требовали передачи внутренних данных компании наружу и быстро упирались в лимиты.

Почему нельзя просто скормить SQL модели целиком?

Первая попытка выглядела логично: загрузить весь SQL-файл в локальную LLM с промптом (текстовой инструкцией для модели) «переведи из Vertica в Trino без ошибок». Результат оказался непригодным.

Проблема называется «контекстное гниение» (context rot). Модели с открытыми весами размером около 30 миллиардов параметров начинают терять качество уже после 30 тысяч токенов (условных единиц текста, примерно 20 тысяч слов). Модель забывает правила из промпта, теряет структуру запроса и подставляет синтаксис из других диалектов SQL.

Дело в самом принципе работы: LLM выбирает наиболее вероятный ответ из нескольких вариантов. У неё нет варианта «я не знаю». Если в обучающих данных мало примеров Trino SQL, модель выдаст похожий, но неверный синтаксис из другого диалекта. Это и есть галлюцинация (когда ИИ уверенно выдумывает то, чего не было).

Модульный конвейер вместо одного промпта

Команда Авито перестала искать «идеальный промпт» и построила инженерную систему из десяти стадий. Вот ключевые:

• Split. Большой SQL-файл разбивается на мелкие блоки. Каждый блок переводится отдельно, что уменьшает контекст и снижает вероятность галлюцинаций. Это решение, по словам авторов, задало ритм всего процесса.
• Translate. Перевод каждого блока через скомпилированный модуль DSPy. Даже на небольшом фрагменте простого кода модель вносила до 9 правок.
• Pattern guard. После перевода regexp-фильтр отлавливает заведомо запрещённые конструкции Vertica, которые модель могла пропустить. Набор паттернов хранится в отдельном файле и легко расширяется.
• Assemble. Сборка итогового файла из последних версий всех частей.
• Api validate. Проверка платформенных правил и применение известных сценариев исправлений.
• Trino test. Запуск SQL в Trino с возможным циклом автоматических исправлений.
• Compare. Сверка результата с эталонной витриной.
• Finalize. Перенос результата в папку готовых или на ручную доработку.

Отдельно стоит упомянуть формат: модуль форматирования через sqlfluff авторы отключили по умолчанию, потому что он вносил больше проблем, чем решал.

Метаданные как память системы

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

Именно метаданные превратили перевод из одноразового сеанса с LLM в воспроизводимый процесс. Можно увидеть статус каждого блока, продолжить работу с нужного места, локализовать ошибку.

Что делать с этим прямо сейчас?

Автору Дзена и копирайтеру. Принцип «разбей задачу на мелкие части и проверяй каждую» работает и с текстами. Если вы генерируете длинные статьи через локальные LLM, отправляйте не весь план разом, а по разделам. Это снизит количество галлюцинаций и упростит проверку.

Маркетологу и аналитику. Если в вашей компании есть SQL-витрины и стоит задача миграции, подход Авито показывает, что это можно автоматизировать без передачи бизнес-логики в облако. Локальные LLM решают вопрос конфиденциальности.

Предпринимателю в РФ. Локальные LLM доступны без ограничений и не зависят от зарубежных сервисов. Модели с открытыми весами (open weights) можно развернуть на своих серверах. Из российских альтернатив для текстовых задач есть YandexGPT и GigaChat, но для специализированной работы с кодом команда Авито использовала именно локальную модель на собственной инфраструктуре.

Главный вывод из опыта Авито прост и применим далеко за пределами SQL: локальные LLM становятся полезными не тогда, когда вы находите правильный промпт, а когда перестаёте ждать от модели универсальности и выстраиваете процесс, который компенсирует её слабости.