T-Bank melhorou a qualidade do AI Code Completion com um filtro e removeu sugestões desnecessárias

Т-Банк рассказал, как переделал внутренний AI Code Completion для 7,5 тысячи разработчиков и поднял долю принятых подсказок, не меняя основную модель генерации. Вместо очередной попытки сделать комплишен «умнее» команда добавила отдельный фильтр, который решает, показывать ли подсказку вообще.

Где был потолок

Сервис автодополнения кода в Т-Банке уже несколько лет работает в проде и ежедневно используется почти всей внутренней разработкой — это около 7,5 тысячи уникальных пользователей. Базовая метрика, Acceptance Rate, долго держалась возле 20%: примерно каждая пятая подсказка принималась, остальные игнорировались. Команда пробовала удлинять подсказки, менять стратегию генерации и расширять число мест показа, но это давало все больше шума.

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

По внутренней оценке, каждый дополнительный процентный пункт AR со временем добавлял около 2% к числу принятий. Но был жесткий бизнес-лимит: фильтр не должен был моментально «съесть» больше 5% уже принимаемых подсказок.

Из чего собрали фильтр Первым шагом стал быстрый baseline на CatBoost.

Модель обучили как бинарный классификатор: принять подсказку или нет. Взяли только те признаки, которые можно посчитать в реальном времени без хранения истории запросов: IDE, язык программирования, позицию курсора, тип подсказки, размер префикса и суффикса. Даже такой простой вариант дал на офлайне около +2,3 п.

п. к Acceptance Rate и подтвердил, что в задаче действительно есть сильный сигнал. Дальше команда перешла к текстовому фильтру на базе Qwen2.

5-Coder 1.5B. Более крупные модели не укладывались в продовые ограничения: целевые 30 запросов в секунду на одной Nvidia A100 и p90 latency не выше 50 мс.

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

• Генерационную голову заменили на бинарную классификацию Контекст разметили тегами для префикса, строки, ответа и суффикса IDE, язык и позицию курсора закодировали специальными токенами * На финальном этапе добавили fine-tuning, LoRA и focal loss из-за дисбаланса классов Такой пайплайн сдвигал качество ступенчато: после строгой структуры прирост вырос примерно до +3,9 п. п., после добавления специальных токенов — до +5,1 п. п., а полноценный fine-tuning довел офлайн-результат до +6,8 п. п. Самым важным оказалось не только дообучение, но и то, как именно упакован вход: модель начала лучше различать, где контекст файла, а где подсказка, которую нужно оценить, а не переписать.

Что сломалось в проде

На синтетических тестах все выглядело отлично, но теневой запуск быстро остудил ожидания. Простая конвертация модели в ONNX почти утроила пропускную способность и снизила время ответа примерно до 30 мс, однако на реальном трафике latency в пиках снова улетала к 90 мс. Причина оказалась не в самой модели, а в профиле нагрузки: в проде приходили пачки почти одновременных запросов, которых не было в тестах. Проблему сняли через Triton и динамический батчинг с небольшим размером пакета и коротким ожиданием в очереди.

«Офлайн нужен, но теневое — единственное место, где начинается реальность.»

После этого вскрылся второй слой проблем: фильтр получился слишком агрессивным. Чтобы удержать выброс принятых подсказок в пределах 5%, порог пришлось переобучать уже на недельном окне данных, а не на нескольких днях. Затем поверх LLM добавили еще один CatBoost, который получил скор основной модели, табличные признаки и исторические сигналы вроде интервала между запросами и изменения длины префикса. Для этого состояние пользователя хранили в Redis. По пути команда поймала типичную инженерную ошибку: часть фич в проде считалась в байтах, а часть — в символах. После выравнивания логики A/B-тест показал 4,7% отброшенного трафика и +5,2 п. п. к Acceptance Rate без перекосов по языкам и IDE.

Что это значит

Кейс Т-Банка хорошо показывает, что следующий прирост качества в AI-инструментах не всегда дает новая большая модель. Иногда больший эффект приносит отдельный слой принятия решения, который вовремя молчит. Для продуктов с высокой частотой использования это еще и вопрос доверия: если убрать лишние подсказки, пользователи не только реже раздражаются, но и со временем чаще принимают полезные варианты. На масштабе тысяч разработчиков это быстро превращается в заметную экономию времени.