T-Bank melhora o AI Code Completion com um filtro que elimina sugestões desnecessárias

O T-Bank contou como reformulou seu AI Code Completion interno para 7,5 mil desenvolvedores e elevou a proporção de sugestões aceitas sem mudar o modelo principal de geração. Em vez de mais uma tentativa de deixar o completion «mais inteligente», a equipe adicionou um filtro separado que decide se a sugestão deve ser exibida.

Onde estava o teto

O serviço de autocompletar código do T-Bank está em produção há vários anos e é usado diariamente por quase todo o time interno de desenvolvimento, cerca de 7,5 mil usuários únicos. A métrica básica, o Acceptance Rate, ficou por muito tempo em torno de 20%: aproximadamente uma em cada cinco sugestões era aceita, e as demais eram ignoradas.

A equipe tentou alongar as sugestões, mudar a estratégia de geração e ampliar os pontos de exibição, mas isso só gerou mais ruído. Quanto mais o sistema sugeria, mais os desenvolvedores viam continuações inúteis e menor ficava a confiança no produto.

Daí surgiu outra hipótese: o problema poderia estar não só na qualidade da geração, mas também na ausência de uma decisão separada sobre quando esconder a sugestão.

A equipe notou um efeito comportamental importante: com menos lixo, os usuários apertam Tab com mais disposição e dão chance até a sugestões pouco óbvias. Pela estimativa interna, cada ponto percentual adicional de AR acrescentava, com o tempo, cerca de 2% ao número de aceitações. Mas havia um limite de negócio rígido: o filtro não podia «engolir» de imediato mais de 5% das sugestões que já eram aceitas.

Como o filtro foi montado

O primeiro passo foi um baseline rápido com CatBoost. O modelo foi treinado como classificador binário: aceitar a sugestão ou não. Usaram apenas atributos calculáveis em tempo real, sem guardar histórico de requisições: IDE, linguagem de programação, posição do cursor, tipo de sugestão e tamanho do prefixo e do sufixo. Mesmo essa versão simples rendeu cerca de +2,3 p.p. de Acceptance Rate offline e confirmou que há um sinal forte na tarefa.

Em seguida, a equipe passou a um filtro textual baseado no Qwen2.5-Coder 1.5B. Modelos maiores não cabiam nas restrições de produção: meta de 30 requisições por segundo em uma única Nvidia A100 e latência p90 de no máximo 50 ms. Por isso escolheram uma solução de compromisso: compacta o bastante para inferência, mas ainda voltada a código. Para que o modelo não confundisse o contexto do arquivo com a própria sugestão, foi preciso estruturar a entrada de forma rígida e refinar o treino para classificação, não para geração.

• A cabeça de geração foi substituída por classificação binária
• O contexto foi marcado com tags para prefixo, linha, resposta e sufixo
• IDE, linguagem e posição do cursor foram codificados com tokens especiais
• Na etapa final, entraram fine-tuning, LoRA e focal loss por causa do desbalanceamento de classes

Esse pipeline melhorou a qualidade em degraus: com a estrutura rígida o ganho subiu para cerca de +3,9 p.p., com os tokens especiais para +5,1 p.p., e o fine-tuning completo levou o resultado offline a +6,8 p.p. O mais importante não foi só o treino adicional, mas a forma de empacotar a entrada: o modelo passou a distinguir melhor o contexto do arquivo da sugestão que deveria avaliar, e não reescrever.

O que quebrou em produção

Nos testes sintéticos tudo parecia ótimo, mas o lançamento em sombra logo esfriou as expectativas. A simples conversão do modelo para ONNX quase triplicou a vazão e reduziu o tempo de resposta para cerca de 30 ms, porém, com tráfego real, a latência nos picos voltava a disparar para 90 ms. A causa não estava no modelo, e sim no perfil de carga: em produção chegavam rajadas de requisições quase simultâneas que não existiam nos testes. O problema foi resolvido com Triton e batching dinâmico, com lote pequeno e espera curta na fila.

«O offline é necessário, mas o modo sombra é o único lugar onde a

realidade começa.»

Depois apareceu uma segunda camada de problemas: o filtro ficou agressivo demais. Para manter a perda de sugestões aceitas dentro de 5%, o limiar teve de ser retreinado com uma janela semanal de dados, e não de alguns dias. Em seguida, foi adicionado sobre o LLM mais um CatBoost, que recebia o score do modelo principal, atributos tabulares e sinais históricos, como o intervalo entre requisições e a variação do tamanho do prefixo. Para isso, o estado do usuário foi guardado no Redis.

No caminho, a equipe pegou um erro de engenharia clássico: parte das features em produção era calculada em bytes e parte em caracteres. Depois de alinhar a lógica, o teste A/B mostrou 4,7% do tráfego descartado e +5,2 p.p. de Acceptance Rate, sem distorções por linguagem ou IDE.

O que isso significa

O caso do T-Bank mostra que o próximo ganho de qualidade em ferramentas de IA nem sempre vem de um novo modelo grande. Às vezes, o maior efeito vem de uma camada de decisão separada que sabe ficar em silêncio na hora certa. Para produtos de uso muito frequente, é também uma questão de confiança: sem sugestões em excesso, os usuários não só se irritam menos, como, com o tempo, aceitam mais as opções úteis. Na escala de milhares de desenvolvedores, isso rapidamente se traduz em uma economia de tempo perceptível.