T-Bank mejora su AI Code Completion con un filtro que elimina sugerencias innecesarias

T-Bank explicó cómo rediseñó su AI Code Completion interno para 7500 desarrolladores y aumentó la proporción de sugerencias aceptadas sin cambiar el modelo principal de generación. En lugar de intentar otra vez que el completado fuera «más inteligente», el equipo añadió un filtro independiente que decide si se muestra la sugerencia.

Dónde estaba el techo

El servicio de autocompletado de código de T-Bank lleva varios años en producción y lo usa a diario casi todo el desarrollo interno: unos 7500 usuarios únicos. La métrica básica, Acceptance Rate, se mantuvo mucho tiempo en torno al 20%: aproximadamente una de cada cinco sugerencias se aceptaba y el resto se ignoraba.

El equipo probó a alargar las sugerencias, cambiar la estrategia de generación y ampliar los lugares donde aparecen, pero eso solo generó más ruido. Cuanto más sugería el sistema, más a menudo los desarrolladores veían continuaciones inútiles y menor era su confianza en el producto.

De ahí surgió otra hipótesis: el problema podía estar no solo en la calidad de la generación, sino en la falta de una decisión independiente sobre cuándo ocultar la sugerencia.

El equipo observó un efecto de comportamiento importante: cuando hay menos basura, los usuarios pulsan Tab con más ganas y dan una oportunidad incluso a propuestas poco obvias. Según la estimación interna, cada punto porcentual adicional de AR sumaba con el tiempo en torno a un 2% más de aceptaciones. Pero había un límite de negocio estricto: el filtro no podía «comerse» de golpe más del 5% de las sugerencias que ya se aceptaban.

De qué se compone el filtro

El primer paso fue un baseline rápido con CatBoost. El modelo se entrenó como clasificador binario: aceptar la sugerencia o no. Se usaron solo rasgos calculables en tiempo real sin almacenar el historial de peticiones: IDE, lenguaje de programación, posición del cursor, tipo de sugerencia y tamaño del prefijo y del sufijo. Incluso esta versión sencilla aportó cerca de +2,3 p. p. de Acceptance Rate offline y confirmó que la tarea contiene una señal fuerte.

Después, el equipo pasó a un filtro de texto basado en Qwen2.5-Coder 1.5B. Los modelos mayores no cumplían las restricciones de producción: el objetivo era 30 peticiones por segundo en una sola Nvidia A100 y una latencia p90 no superior a 50 ms. Por eso eligieron una solución de compromiso: lo bastante compacta para la inferencia, pero aún especializada en código. Para que el modelo no confundiera el contexto del archivo con la propia sugerencia, hubo que estructurar la entrada de forma rígida y reentrenarlo para clasificar, no para generar.

• La cabeza de generación se sustituyó por una de clasificación binaria
• El contexto se marcó con etiquetas para prefijo, línea, respuesta y sufijo
• El IDE, el lenguaje y la posición del cursor se codificaron con tokens especiales
• En la fase final se añadieron fine-tuning, LoRA y focal loss por el desequilibrio de clases

Este pipeline mejoró la calidad por escalones: con la estructura estricta la ganancia subió hasta cerca de +3,9 p. p., con los tokens especiales hasta +5,1 p. p., y el fine-tuning completo llevó el resultado offline a +6,8 p. p. Lo más importante no fue solo el reentrenamiento, sino cómo se empaqueta la entrada: el modelo empezó a distinguir mejor el contexto del archivo de la sugerencia que debía evaluar, no reescribir.

Qué falló en producción

En las pruebas sintéticas todo parecía excelente, pero el lanzamiento en sombra enfrió pronto las expectativas. La simple conversión del modelo a ONNX casi triplicó el rendimiento y redujo el tiempo de respuesta a unos 30 ms, pero con tráfico real la latencia en los picos volvía a dispararse hasta 90 ms. La causa no estaba en el modelo, sino en el perfil de carga: en producción llegaban ráfagas de peticiones casi simultáneas que no existían en las pruebas. El problema se resolvió con Triton y batching dinámico, con un tamaño de lote pequeño y una espera corta en la cola.

«Lo offline hace falta, pero el modo sombra es el único lugar donde

empieza la realidad.»

Después apareció una segunda capa de problemas: el filtro resultó demasiado agresivo. Para mantener dentro del 5% la pérdida de sugerencias aceptadas, hubo que reentrenar el umbral con una ventana semanal de datos en lugar de unos pocos días. Luego se añadió sobre el LLM otro CatBoost, que recibía la puntuación del modelo principal, rasgos tabulares y señales históricas como el intervalo entre peticiones y el cambio de longitud del prefijo. Para ello, el estado del usuario se guardó en Redis.

Por el camino, el equipo detectó un error de ingeniería típico: parte de las features en producción se calculaban en bytes y parte en caracteres. Tras alinear la lógica, el test A/B mostró un 4,7% de tráfico descartado y +5,2 p. p. de Acceptance Rate, sin sesgos por lenguajes ni IDE.

Qué significa

El caso de T-Bank muestra que la siguiente mejora de calidad en las herramientas de IA no siempre llega con un nuevo modelo grande. A veces el mayor efecto lo logra una capa de decisión independiente que sabe callar a tiempo. En productos de uso muy frecuente es además una cuestión de confianza: si se eliminan las sugerencias sobrantes, los usuarios no solo se irritan menos, sino que con el tiempo aceptan más a menudo las opciones útiles. A escala de miles de desarrolladores, esto se traduce rápidamente en un ahorro de tiempo apreciable.