Привет, Хабр Меня зовут Дмитрий Бабаев, я руководитель R&D GigaCode в Сбере. Сегодня расскажу о том, как мы создавали ИИ‑помощника для программистов задолго до того, как это стало мейнстримом.

Многие компании думают о том, чтобы выпустить собственного ИИ‑помощника для разработчиков. Мы начали делать GigaCode около трех лет назад — ещё до появления Cursor и других популярных сегодня решений.

За это время мы создали целую экосистему решений для разработки — GigaDEV: IDE на основе IntelliJ, платформу Gitverse как аналог GitHub и сам GigaCode.

Философия двух моделей: почему одной недостаточно

Вместо использования «единой модели для всего» мы разработали две специализированные: компактную Inline для мгновенных подсказок и мощную Chat для сложных задач.

Логика простая: когда разработчик нажимает клавишу, он не готов ждать. Каждое нажатие должно вызывать модель, которая генерирует варианты подсказки практически мгновенно. Попробуйте работать с помощником, который «думает» полсекунды на каждый символ, и поймёте, о чём речь.

Inline‑модель обрабатывает всё, что связано с непосредственным редактированием кода: однострочные и многострочные дополнения, написание функций по комментариям, даже прогноз следующей позиции редактирования (Next Edit Prediction). Это то, что превращает IDE из редактора в умного помощника для разработчика.

GigaCode Inline: когда размер не главное

Наша Inline‑модель — это 3 миллиарда параметров и 5 триллионов токенов обучения. Для сравнения: Qwen Coder 2.5 обучали на том же объёме данных но для инициализации использовали NLP модель Qwen 2.5. Мы же, начали с нуля, полностью обучив модель со случайных весов.

Почему не взяли готовые веса от Qwen? Потому что задачи заметно отличаются. NLP‑модели привыкли читать текст слева направо, а нам нужно Fill in the Middle: заполнять пропуски, зная контекст с обеих сторон. Это как разница между чтением книги и решением кроссворда.

Датасет собирали на основе классического The Stack v2, но с добавлением свежих GitHub-репозиториев и OpenCoder annealing corpus. Распределение задач в пре-трейне: 25 % обычного Next Token Prediction, 37,5 % Inline FIM и 37,5 % Multi-line Structure-aware FIM. Последний — это наше ноу-хау.

Главная особенность — Structure-aware FIM вместо line-aware подхода. Вместо заполнения случайных фрагментов мы учили модель генерировать цельные смысловые блоки: функции, циклы, условные конструкции. Качество выросло заметно.

Ещё одним открытием стало то, что даже трёхмиллиардные модели регулярно ошибаются в синтаксисе. Забывают закрыть скобку, путают названия переменных, делают банальные опечатки. Хотя казалось, что такие базовые вещи модель должна освоить в первую очередь. Поэтому мы добавили фазу DPO (Direct Preference Optimization). Как результат — научили модель делать меньше синтаксических ошибок.

Метрики: как измерить «удобство»

Классические метрики типа «exact match» плохо работают для кода: слишком много способов написать одно и то же. Но они засчитывают ответ только при абсолютном совпадении с эталоном, вплоть до каждого пробела и символа. Это для программирования имеет достаточно мало смысла, так как один и тот же алгоритм можно написать десятками разных способов. Exact match признает правильным лишь тот, в котором буква в букву повторяется образец — именно поэтому разработчики всё чаще отказываются от этой метрики.

И в том числе поэтому мы придумали нашу метрику — ClickScore. Она измеряет долю символов, которую разработчику не нужно печатать благодаря подсказкам.

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

Результаты получились интересные: наша Inline 3B с DPO показывает 86,4 % ClickScore на Python против 80,3 % у Qwen2.5-Coder 3B. Более того, мы обгоняем даже Qwen2.5-Coder 7B на Python и Java, несмотря на вдвое меньший размер.

GigaCode Chat: когда нужен интеллект

Chat-модель размером 32 миллиарда параметров — это специализированный инструмент, предназначенный для сложных задач. Редактирование выделенных блоков, генерация тестов, объяснение кода, проверка, работа в режиме агента с целыми проектами — всё, что требует глубокого понимания контекста.

Сначала за основу мы взяли Qwen Coder, но делали полный alignment самостоятельно — SFT и DPO. Плюс 150 миллиардов токенов на адаптацию к русскому языку, потому что наша первая версия GigaChat не очень дружила с кодом.

Сейчас перешли на GigaChat-2 в качестве основы — он заметно лучше понимает код, и нам больше не нужна фаза русификации.

DPO делали на проверяемых задачах: генерация кода по описанию из CodeForces и создание Unit‑тестов.

LiveCodeBench: динамический бенчмарк против переобучения

Также для оценки качества модели в генерации кода мы использовали один из наиболее часто используемых современных бенчмарков — LiveCodeBench. Его особенность в том, что его регулярно обновляют свежими задачами с соревнований по программированию. Это решает проблему контаминации, когда модели «видели» задачи во время обучения.

График деградации ряда других бенчмарков имеет один общий недостаток: как только выходят новые модели, качество решения «старых» задач у них растёт по не до конца понятным причинам. А на свежих задачах качество растет в существенно меньшей степени.

Наша Chat-модель  показывает в бенчмарках результаты на уровне Qwen2.5 Coder 32B: 30,7 % против 30,1 % на LiveCodeBench. Но в генерации тестов мы выделяемся уже сильнее — 23,8 % против 11,9 %. Тут нам помогла DPO фаза пост-обучения.

Время рассуждающих моделей

Многое изменилось с появлением reasoning-моделей (будем называть их рассуждающими). Qwen 3 с поддержкой цепочек рассуждений показал двукратный рост качества: 65,7 % против 31,3 % в обычном режиме. Такие результаты заметно отличались от привычно ожидаемых плавных улучшений качества.

До рассуждающих моделей наша система уверенно превосходила Qwen Coder, особенно на сложных задачах. Но с появлением рассуждающих моделей положение дел сильно изменилось. В настоящий момент  мы активно работаем над нашей собственной рассуждающей моделью и первые результаты обнадёживают: 50,7 % на LiveCodeBench против 30,7 % у предыдущей версии. Догоняем и планируем перегнать.

Испытание реальностью: SWE Bench

SWE Bench — это один из наиболее объективных тестов для пишущих код LLM. Он берёт реальные issue(проблемы) из популярных GitHub-репозиториев: Django, NumPy, SciPy и других, а модель должна понять проблему, найти нужное место в кодовой базе и предложить корректное решение, которое пройдёт существующие тесты.

Здесь наша модель показывает 21.33% в связке с Agentless pipeline и RAG — результат близкий к GPT-4 (32 %), но пока отстающий от лидеров. Интересно, что DeepSeek R1 с рассуждениями показывает 26 % — хороший результат, но не сильно выделяющийся..

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

Что дальше: планы и амбиции

Мы планируем открыть исходный код inline‑модели — пусть сообщество использует наши наработки. Основные выводы которые мы сделали: особая важность structured training для FIM‑задач, необходимость post‑training даже для специализированных кодовых моделей и революционная роль рассуждающих архитектур в современных системах генерации кода.

Конкуренция в сфере ИИ‑помощников для кода становится только выше — каждый месяц появляются новые игроки. Но мы не сидели сложа руки, а параллельно со всеми накапливали как теоретический, так и практический опыт с применением в бизнесе.

В итоге у нас получилась система, которая в некоторых аспектах превосходит доступные open source решения в своей весовой категории. И это только начало.

Кстати, мы активно нанимаем в команду. Если вам интересно создавать ИИ‑ассистентов разработчика и поработать в одной из лучших ML‑команд в России — пишите нашим рекрутерам.

P. S. Если у кого есть вопросы по техническим подробностям — спрашивайте в комментариях.