T-Bank a amélioré la qualité d'AI Code Completion grâce à un filtre et a supprimé les suggestions inutiles

T-Bank a partagé comment il a reconstruit son AI Code Completion interne pour 7.500 développeurs et a augmenté la proportion de suggestions acceptées sans modifier le modèle de génération principal. Au lieu d'une nouvelle tentative de rendre la complétion « plus intelligente », l'équipe a ajouté un filtre séparé qui décide si afficher une suggestion ou non.

Où Était le Plafond

Le service d'autocomplétion de code de T-Bank fonctionne en production depuis plusieurs années et est utilisé quotidiennement par presque toute l'équipe de développement interne—environ 7.500 utilisateurs uniques. La métrique de base, Taux d'Acceptation, s'est longtemps maintenue 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 modifier la stratégie de génération et d'élargir le nombre d'endroits pour afficher les suggestions, mais cela générait plus de bruit. Plus le système suggérait activement, plus souvent les développeurs voyaient des continuations inutiles et plus faible devenait la confiance envers le produit. Cela a conduit à une hypothèse différente : le problème pouvait ne pas être seulement la qualité de la génération, mais l'absence d'un mécanisme séparé pour déterminer exactement quand une suggestion devrait être cachée.

L'équipe a remarqué un effet comportemental important : si le bruit diminuait, les utilisateurs commençaient à appuyer sur Tab plus volontiers et donnaient plus de chances même à des propositions non évidentes. Selon l'évaluation interne, chaque point de pourcentage supplémentaire du Taux d'Acceptation ajoutait au fil du temps environ 2% au nombre d'acceptations. Mais il y avait une limite commerciale stricte : le filtre ne devait pas éliminer immédiatement plus de 5% des suggestions déjà acceptées.

Comment Ils Ont Construit le Filtre

La première étape a été un baseline rapide sur CatBoost. Le modèle a été entraîné comme un classificateur binaire : accepter la suggestion ou non. Ils ont utilisé uniquement les caractéristiques qui pouvaient être calculées en temps réel sans stocker l'historique des requêtes : IDE, langage de programmation, position du curseur, type de suggestion, taille du préfixe et du suffixe.

Même cette variante simple a donné environ +2,3 points de pourcentage au Taux d'Acceptation hors ligne et a confirmé que la tâche avait un signal fort. Ensuite, l'équipe est passée à un filtre textuel basé sur Qwen2.5-Coder 1.

5B. Les modèles plus grands ne rentraient pas dans les contraintes de production : l'objectif de 30 requêtes par seconde sur une seule Nvidia A100 et une latence p90 non supérieure à 50 ms. Ils ont donc choisi un compromis : assez compact pour l'inférence, mais toujours adapté au code.

Pour empêcher le modèle de confondre le contexte du fichier avec la suggestion elle-même, l'entrée devait être strictement structurée et affinée non pour la génération, mais pour la classification.

• Remplacé la tête de génération par une classification binaire
• Étiqueté le contexte pour le préfixe, la ligne, la réponse et le suffixe
• Codé l'IDE, le langage et la position du curseur avec des tokens spéciaux
• À l'étape finale, ajouté le fine-tuning, LoRA et focal loss en raison du déséquilibre des classes

Ce pipeline a amélioré la qualité par étapes : après la structuration stricte, le gain a augmenté à environ +3,9 p.p., après l'ajout de tokens spéciaux—à +5,1 p.p., et le fine-tuning complet a porté le résultat hors ligne à +6,8 p.p. Le plus important s'est avéré être non seulement le fine-tuning, mais comment l'entrée a été emballée : le modèle a commencé à mieux distinguer où se trouvait le contexte du fichier et où se trouvait la suggestion à évaluer, plutôt que de la réécrire.

Ce Qui s'Est Cassé en Production

Sur les tests synthétiques, tout semblait excellent, mais une exécution fantôme a rapidement refroidi les attentes. La simple conversion du modèle en ONNX a presque triplé le débit et réduit le temps de réponse à environ 30 ms, mais sur le trafic réel, la latence aux pics s'est à nouveau envolée à 90 ms. La cause s'est avérée ne pas être le modèle lui-même, mais le profil de charge : en production, des rafales de requêtes presque simultanées arrivaient, ce qui n'était pas présent dans les tests. Le problème a été résolu via Triton et le batching dynamique avec une petite taille de lot et un court temps d'attente en queue.

« L'offline est nécessaire, mais l'exécution fantôme est le seul

endroit où la réalité commence. »

Après cela, une deuxième couche de problèmes a été découverte : le filtre s'est avéré être trop agressif. Pour maintenir le pic de suggestions acceptées à moins de 5%, le seuil a dû être réentraîné sur une fenêtre de données hebdomadaire plutôt que sur quelques jours. Ensuite, au-dessus de la LLM, un autre CatBoost a été ajouté, qui a reçu le score du modèle principal, des caractéristiques tabulaires et des signaux historiques comme l'intervalle entre les requêtes et les changements de longueur du préfixe.

Pour cela, l'état de l'utilisateur a été stocké dans Redis. En chemin, l'équipe a attrapé une erreur d'ingénierie typique : une partie des caractéristiques en production était calculée en octets et une partie en caractères. Après l'alignement de la logique, un test A/B a montré 4,7% de trafic rejeté et +5,2 p.

p. au Taux d'Acceptation sans biais par langage et IDE.

Ce Que Cela Signifie

Le cas de T-Bank montre bien que la prochaine amélioration de qualité dans les outils d'IA ne vient pas toujours d'un nouveau grand modèle. Parfois, une couche de décision séparée qui reste silencieuse au bon moment apporte un plus grand effet. Pour les produits à haute fréquence d'utilisation, c'est aussi une question de confiance : si vous supprimez les suggestions inutiles, les utilisateurs non seulement s'agacent moins, mais au fil du temps acceptent plus souvent les options utiles. À l'échelle de milliers de développeurs, cela se transforme rapidement en économies de temps notables.