T-Bank mejoró la calidad de AI Code Completion con un filtro y eliminó sugerencias innecesarias

T-Bank compartió cómo reconstruyó su AI Code Completion interno para 7.500 desarrolladores e incrementó la proporción de sugerencias aceptadas sin cambiar el modelo de generación principal. En lugar de otro intento de hacer el autocompletado "más inteligente", el equipo añadió un filtro separado que decide si mostrar una sugerencia o no.

Dónde Estaba el Límite

El servicio de autocompletado de código de T-Bank ya funciona en producción desde hace varios años y lo utilizan diariamente casi todos los desarrolladores internos—aproximadamente 7.500 usuarios únicos. La métrica básica, Tasa de Aceptación, se mantuvo durante mucho tiempo alrededor del 20%: aproximadamente una de cada cinco sugerencias era aceptada, las demás se ignoraban.

El equipo intentó alargar las sugerencias, cambiar la estrategia de generación y expandir el número de lugares para mostrar sugerencias, pero esto generó más ruido. Cuanto más activamente sugería el sistema, más frecuentemente los desarrolladores veían continuaciones inútiles y más débil se volvía su confianza en el producto. Esto condujo a una hipótesis diferente: el problema podría no ser solo la calidad de la generación, sino la ausencia de un mecanismo separado para determinar exactamente cuándo una sugerencia debe ocultarse.

El equipo notó un efecto comportamental importante: si el ruido disminuía, los usuarios comenzaban a presionar Tab con más disposición y daban más oportunidades incluso a propuestas no obvias. Según la evaluación interna, cada punto porcentual adicional de Tasa de Aceptación agregaba con el tiempo aproximadamente 2% al número de aceptaciones. Pero había un límite comercial estricto: el filtro no debía eliminar inmediatamente más del 5% de las sugerencias ya aceptadas.

Cómo Construyeron el Filtro

El primer paso fue un baseline rápido con CatBoost. El modelo se entrenó como un clasificador binario: aceptar la sugerencia o no. Utilizaron solo aquellas características que podían calcularse en tiempo real sin almacenar el historial de solicitudes: IDE, lenguaje de programación, posición del cursor, tipo de sugerencia, tamaño del prefijo y sufijo.

Incluso esta variante simple dio aproximadamente +2,3 puntos porcentuales a la Tasa de Aceptación offline y confirmó que la tarea tenía una señal fuerte. Luego, el equipo pasó a un filtro de texto basado en Qwen2.5-Coder 1.

5B. Los modelos más grandes no cabían dentro de las restricciones de producción: el objetivo de 30 solicitudes por segundo en una única Nvidia A100 y latencia p90 no superior a 50 ms. Así que eligieron un compromiso: lo suficientemente compacto para inferencia, pero aún adaptado para código.

Para evitar que el modelo confundiera el contexto del archivo con la sugerencia en sí, la entrada tuvo que estructurarse rigurosamente y ajustarse no para generación, sino para clasificación.

• Reemplazaron la cabeza de generación con clasificación binaria
• Etiquetaron contexto para prefijo, línea, respuesta y sufijo
• Codificaron IDE, lenguaje y posición del cursor con tokens especiales
• En la etapa final, añadieron fine-tuning, LoRA y focal loss por el desbalance de clases

Este pipeline mejoró la calidad por pasos: después de la estructuración rigurosa, la ganancia creció a aproximadamente +3,9 p.p., después de añadir tokens especiales—a +5,1 p.p., y el fine-tuning completo llevó el resultado offline a +6,8 p.p. Lo más importante resultó ser no solo el fine-tuning, sino cómo se empaquetó la entrada: el modelo comenzó a distinguir mejor dónde estaba el contexto del archivo y dónde estaba la sugerencia a evaluar, en lugar de reescribir.

Qué Se Rompió en Producción

En pruebas sintéticas todo se veía excelente, pero una ejecución de sombra rápidamente enfrió las expectativas. La simple conversión del modelo a ONNX casi triplicó el rendimiento y redujo el tiempo de respuesta a aproximadamente 30 ms, pero en tráfico real, la latencia en picos volvió a dispararse a 90 ms. La causa resultó no ser el modelo en sí, sino el perfil de carga: en producción llegaban ráfagas de solicitudes casi simultáneas, que no estaban presentes en las pruebas. El problema se resolvió a través de Triton y batching dinámico con un tamaño de lote pequeño y tiempo de espera corto en la cola.

"Offline es necesario, pero la ejecución de sombra es el único lugar

donde comienza la realidad."

Después de esto, se descubrió una segunda capa de problemas: el filtro resultó ser demasiado agresivo. Para mantener el pico de sugerencias aceptadas dentro del 5%, el umbral tuvo que reentrenarse en una ventana semanal de datos en lugar de unos pocos días. Luego, encima de la LLM, se añadió otro CatBoost, que recibió la puntuación del modelo principal, características tabulares y señales históricas como el intervalo entre solicitudes y cambios en la longitud del prefijo.

Para esto, el estado del usuario se almacenó en Redis. En el camino, el equipo encontró un error de ingeniería típico: parte de las características en producción se calculaban en bytes y parte en caracteres. Después de alinear la lógica, una prueba A/B mostró 4,7% de tráfico descartado y +5,2 p.

p. en la Tasa de Aceptación sin sesgos por lenguaje e IDE.

Qué Significa Esto

El caso de T-Bank muestra bien que la siguiente mejora de calidad en herramientas de IA no siempre proviene de un nuevo modelo grande. A veces, una capa de decisión separada que permanece callada en el momento correcto produce un mayor efecto. Para productos con alta frecuencia de uso, esto también es una cuestión de confianza: si eliminas sugerencias innecesarias, los usuarios no solo se molestan menos, sino que con el tiempo más frecuentemente aceptan opciones útiles. A la escala de miles de desarrolladores, esto rápidamente se convierte en ahorros notables de tiempo.