T-Bank améliore son AI Code Completion grâce à un filtre qui supprime les suggestions inutiles

T-Bank a expliqué comment elle a refondu son AI Code Completion interne, utilisé par 7 500 développeurs, et augmenté la part de suggestions acceptées sans toucher au modèle principal de génération. Plutôt que de tenter une nouvelle fois de rendre la complétion « plus intelligente », l'équipe a ajouté un filtre distinct qui décide s'il faut afficher la suggestion.

Où était le plafond

Le service d'autocomplétion de code de T-Bank tourne en production depuis plusieurs années et sert chaque jour presque tous les développeurs internes, soit environ 7 500 utilisateurs uniques. La métrique de base, l'Acceptance Rate, est longtemps restée autour de 20 % : environ une suggestion sur cinq était acceptée, les autres étaient ignorées.

L'équipe a essayé d'allonger les suggestions, de changer la stratégie de génération et de multiplier les endroits d'affichage, mais cela n'a fait qu'ajouter du bruit. Plus le système suggérait, plus les développeurs voyaient de suites inutiles, et plus leur confiance dans le produit s'érodait.

D'où une autre hypothèse : le problème pouvait venir non seulement de la qualité de la génération, mais aussi de l'absence d'une décision distincte sur le moment où il faut masquer la suggestion.

L'équipe a constaté un effet comportemental important : quand il y a moins de déchets, les utilisateurs appuient plus volontiers sur Tab et laissent leur chance même à des propositions peu évidentes. Selon l'estimation interne, chaque point de pourcentage supplémentaire d'AR ajoutait avec le temps environ 2 % au nombre d'acceptations. Mais il existait une limite métier stricte : le filtre ne devait pas « avaler » d'emblée plus de 5 % des suggestions déjà acceptées.

Comment le filtre a été construit

La première étape a été un baseline rapide avec CatBoost. Le modèle a été entraîné comme un classifieur binaire : accepter la suggestion ou non. Seules des variables calculables en temps réel, sans stocker l'historique des requêtes, ont été retenues : IDE, langage de programmation, position du curseur, type de suggestion, taille du préfixe et du suffixe. Même cette version simple a apporté environ +2,3 points d'Acceptance Rate en offline et confirmé la présence d'un signal fort dans la tâche.

L'équipe est ensuite passée à un filtre textuel fondé sur Qwen2.5-Coder 1.5B. Les modèles plus gros ne respectaient pas les contraintes de production : objectif de 30 requêtes par seconde sur une seule Nvidia A100 et latence p90 de 50 ms maximum. Elle a donc opté pour un compromis : assez compact pour l'inférence, tout en restant spécialisé dans le code. Pour éviter que le modèle ne confonde le contexte du fichier avec la suggestion elle-même, il a fallu structurer strictement l'entrée et réentraîner le modèle pour la classification, non plus pour la génération.

• La tête de génération a été remplacée par une classification binaire
• Le contexte a été balisé par des tags pour le préfixe, la ligne, la réponse et le suffixe
• L'IDE, le langage et la position du curseur ont été encodés par des tokens spéciaux
• À l'étape finale, fine-tuning, LoRA et focal loss ont été ajoutés pour gérer le déséquilibre des classes

Ce pipeline a fait progresser la qualité par paliers : avec la structure stricte, le gain est monté à environ +3,9 points ; avec les tokens spéciaux, à +5,1 points ; et le fine-tuning complet a porté le résultat offline à +6,8 points. Le plus important n'a pas été seulement le réentraînement, mais la manière de présenter l'entrée : le modèle a mieux distingué le contexte du fichier de la suggestion qu'il fallait évaluer, et non réécrire.

Ce qui a coincé en production

Sur les tests synthétiques, tout semblait parfait, mais le lancement en mode fantôme a vite refroidi les attentes. La simple conversion du modèle en ONNX a presque triplé le débit et ramené le temps de réponse à environ 30 ms, mais sur le trafic réel, la latence aux heures de pointe remontait à 90 ms. La cause n'était pas le modèle, mais le profil de charge : la production recevait des rafales de requêtes quasi simultanées, absentes des tests. Le problème a été réglé avec Triton et un batching dynamique, avec une petite taille de lot et une courte attente en file.

« L'offline est nécessaire, mais le mode fantôme est le seul endroit

où la réalité commence. »

Une seconde couche de problèmes est ensuite apparue : le filtre était trop agressif. Pour contenir à 5 % la perte de suggestions acceptées, il a fallu réentraîner le seuil sur une fenêtre de données hebdomadaire plutôt que sur quelques jours. L'équipe a alors ajouté au-dessus du LLM un second CatBoost, alimenté par le score du modèle principal, des variables tabulaires et des signaux historiques comme l'intervalle entre requêtes et la variation de longueur du préfixe. L'état de l'utilisateur était pour cela stocké dans Redis.

En chemin, l'équipe a repéré une erreur d'ingénierie classique : une partie des features était calculée en octets en production, et l'autre en caractères. Après harmonisation de la logique, le test A/B a montré 4,7 % de trafic écarté et +5,2 points d'Acceptance Rate, sans déséquilibre selon les langages ni les IDE.

Ce que cela signifie

Le cas de T-Bank montre que le prochain gain de qualité des outils d'IA ne vient pas toujours d'un nouveau grand modèle. Parfois, un effet plus important vient d'une couche de décision distincte, qui sait se taire au bon moment. Pour les produits très fréquemment utilisés, c'est aussi une question de confiance : en supprimant les suggestions superflues, on irrite moins les utilisateurs et, avec le temps, ils acceptent plus souvent les options utiles. À l'échelle de milliers de développeurs, cela se traduit vite par un gain de temps notable.