Kак мы разработали новую модель автодополнения кода в GigaCode

Привет, Хабр! Меня зовут Дмитрий Бабаев, я руковожу R&D в GigaCode — это ИИ‑ассистент для разработчиков от Сбера. Сегодня расскажу про очередной этап развития наших кодовых моделей. Недавно мы выпустили новую версию inline‑модели автодополнения кода (code completion). Это первая в мире MoE‑модель, созданная специально для этой задачи, мы полностью разработали и обучили её с нуля.

Зачем нужна inline-модель и что в ней нового

Inline-модель – это классическая подсказка в IDE, но на основе LLM. Она работает прямо в редакторе: анализирует код до и после позиции курсора и предлагает продолжение. Подсказка может быть однострочной (модель генерирует продолжение кода до завершения строки) или многострочной (в этом случае модель предлагает вставить логически целостный блок кода из нескольких строк — это может быть присваивание, тело цикла, тело оператора if или функции, и так далее). В отличие от статических автодополнений, LLM умнее: учитывает контекст, генерирует вставки на том же логическом уровне, что и окружающий код, и даже может «перепрыгивать» между местами редактирования в режиме Next Edit Prediction (это у нас на подходе).

Новая версия — Inline 4.0. Это модель на 13 миллиардов параметров с архитектурой Mixture of Experts (MoE), по архитектуре близкая к DeepSeek. Общий размер относительно большой, но на инференсе активируется только 3 миллиарда параметров. В каждом слое роутер выбирает только 6 «экспертов» из 24, в дополнение к двум статичным «экспертам». Исходя из списка выбранных экспертов, модель может реализовывать различные паттерны написания кода: один на Python с динамической типизацией, другой на Java с OOP, и так далее.

Почему это хороший способ создания модели автодополнений:

• Скорость. Модель работает на одной GPU без задержек. Разработчик нажимает клавишу, и подсказка появляется мгновенно. Не нужно ждать заметное время, как, например, с монолитными 30B-моделями.

• Эффективность. Модель лучше справляется с разнообразием кода (языки, API, алгоритмы, стили программирования).

• Фокус на узкой задаче. Мы обучили модель с нуля. В процессе обучения она увидела 4 триллиона токенов кода (сам обучающий датасет претрейна «весит» 1 триллион токенов). По объёму это сопоставимо с топовыми моделями, но мы сосредоточились именно на completion.

Мы не делаем универсальную инструктивную модель (чат-бот, как, например, QWEN-Coder), а специализированную под автодополнение, что позволяет превзойти модели общего назначения.

Ключевые особенности обучения

Модели для кода обычно обучают на задаче Fill-In-the-Middle (FIM). Как это выглядит: дают префикс (код до курсора и над курсором), суффикс (код под курсором), а модель восстанавливает середину. Мы улучшили это двумя способами:

1. Structured FIM. Генерируем датасет так, чтобы разрывы были только по границам логических структур кода. Не в середине блока, не в выражении, а только целыми единицами (тело функции, цикла, класса). Это предотвращает появление «обрезанного» кода и повышает качество генерации. Мы не учим модель восстанавливать код с произвольными краями, и это позволяет ей лучше проявить себя в генерации целостных блоков кода, что и требуется разработчику.

2. Post-train DPO (Direct Preference Optimization). После фазы предварительного обучения мы дообучаем модель выбирать варианты с правильным синтаксисом. Оказалось, что даже лучшие модели часто забывают кавычки, скобки или генерируют некомпилируемый код. DPO «сдвигает» модель в правильную сторону, и в результате количество ошибок сокращается в 2-4 раза.

Эти подходы помогли нам обогнать open source-конкурентов.

Бенчмарки

Мы тестировали модель на разных сценариях: single-line (одна строка), multi-line (блоки, функции), синтаксис и длинный контекст (код из репозитория). Сравнивали с моделями, которые умеют работать в FIM-режиме (не все LLM это могут, например, DeepSeek без специального дообучения совсем не сможет работать в таком режиме). Давайте посмотрим результаты на бенчмарках.

Однострочное автодополнение (single-line)

Здесь модель предлагает продолжение строки в FIM-режиме (Fill-In-the-Middle: контекст сверху + снизу).

*CC CS (Code Completion Click Score) — доля символов, не требующих ручного ввода. Рассчитывается итеративно: если символ не совпадает, то добавляется в input и генерируется заново.

Наша модель лидирует по всем представленным языкам, обходя даже 30B‑конкурента. Прирост по сравнению с предыдущей версией — 1-2 %, но это тысячи сэкономленных символов на проекте.

Многострочное автодополнение (multi-line)

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

*RealCode SG/FG: случайный блок или целая функция; SAFIM: алгоритмические блоки (Codeforces), выражения, API-вызовы.

Тут наша модель сопоставима с альтернативными, доступными в open source, но дешевле для инференса. Прирост по сравнению с нашей предыдущей моделью Inline3.1 — до 8-12 % в ключевых метриках.

Синтаксические ошибки

Одна из главных проблем сode completion на основе LLM — это генерация некомпилируемого кода (незакрытые скобки, неверный синтаксис).

Inline 4.0 ошибается в 2-4 раза реже, чем конкуренты. Это значит, что 93 % сгенерированного кода валидно и компилируемо, то есть почти не требует дополнительных правок от человека.

Автодополнение с контекстом (ExecRepoBench)

Важно для учёта кода из других файлов репозитория.

Здесь лидируют две версии наших моделей, предыдущая (v3.1) даже немного лучше новой версии.

Итоги

Преимущества нашей модели:

1. Эффективность для inference: в 4,5 раза больше параметров, но та же скорость с подсказками в режиме реального времени.

2. Качество: меньше ошибок, лучше учёт контекста, почти нет синтаксических ошибок.

3. Для бизнеса: команды пишут быстрее и, как следствие, снижают time-to-market.

Попробуйте GigaCode по ссылке — будем рады отзывам в комментариях! Если есть вопросы — пишите, обсудим

Благодарности

Огромный вклад в создание модели внесли Алексей Куталев, Дарья Воронцова и Роман Родионов.