🤖 AI

Protecting Private Code in IDE Autocomplete using Differential Privacy

Este artigo demonstra que o treinamento de um modelo de completamento de código Kotlin com Privacidade Diferencial mitiga efetivamente Ataques de Inferência de Membros enquanto mantém uma utilidade alta comparável a modelos não privados, mesmo quando treinado com significativamente menos dados.

Autores originais: Evgeny Grigorenko, David Stanojević, David Ilić, Egor Bogomolov, Kostadin Cvejoski

Publicado 2026-02-02

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Evgeny Grigorenko, David Stanojević, David Ilić, Egor Bogomolov, Kostadin Cvejoski

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

O Problema: O Chef "Atencioso Demais"

Imagine que você contrata um mestre chef (um modelo de IA) para ajudá-lo a cozinhar. Você quer que o chef aprenda com as receitas secretas da sua família para que ele possa sugerir os ingredientes perfeitos para sua próxima refeição. É isso que as ferramentas de codificação modernas fazem: elas aprendem com o código que os desenvolvedores escrevem para sugerir a próxima linha de código.

No entanto, há um risco. Se o chef for bom demais em memorizar, ele pode acidentalmente cuspir a receita secreta da sua família palavra por palavra quando lhe pedirem para cozinhar algo completamente diferente. Pior ainda, um vizinho fofoqueiro (um hacker) pode fazer perguntas específicas ao chef para descobrir: "Ele aprendeu esta receita específica do livro de receitas da minha família ou ele a inventou?". Se o chef puder responder "Sim, definitivamente", o vizinho sabe que seus dados privados foram usados para treiná-lo.

No mundo da codificação, isso é chamado de Memorização e Ataques de Inferência de Membros. O artigo mostra que os modelos de IA padrão são como esses chefs excessivamente atenciosos: eles memorizam trechos de código privados muito bem, criando um vazamento de segurança.

A Solução: O "Espelho Embaçado" (Privacidade Diferencial)

Para corrigir isso, os pesquisadores usaram uma técnica chamada Privacidade Diferencial (DP).

Pense em treinar uma IA como polir um espelho para ver um reflexo claramente.

Sem DP: Você polia o espelho até que ele refletisse peramente cada pequeno detalhe do objeto à frente dele. Se você colocasse um objeto específico e único (um trecho de código privado) na frente dele, o espelho o refletiria perfeitamente. Um hacker pode olhar para o reflexo e dizer: "Aquele foi definitivamente o objeto que eu coloquei ali!".
Com DP: Os pesquisadores adicionam um "spray embaçante" especial ao espelho enquanto o poliam. Esse spray adiciona um pouco de ruído estático ao reflexo. Agora, o espelho ainda mostra a forma geral do objeto (o código ainda funciona bem), mas os detalhes pequenos e únicos são borrados.

Por causa desse "embaçado", mesmo que um hacker pergunte: "Este objeto específico está no espelho?", a resposta do espelho é tão borrada que o hacker não consegue distinguir. Eles são forçados a adivinhar, como se estivessem jogando uma moeda para o alto.

Como Eles Fizeram

A equipe pegou um modelo de IA poderoso (chamado Mellum) que já era bom em escrever código. Em vez de ensiná-lo tudo de novo, eles usaram um atalho inteligente chamado LoRA (Low-Rank Adaptation).

A Analogia: Imagine que a IA é uma biblioteca gigante com bilhões de livros. Em vez de reescrever cada um dos livros para aprender novos segredos, eles apenas adicionaram um pequeno caderno especial na mesa do bibliotecário. Eles treinaram apenas esse pequeno caderno.
Por que isso importa: Como eles treinaram apenas um pequeno caderno, puderam adicionar o "spray embaçante" (ruído) de forma muito mais eficiente sem estragar a capacidade do bibliotecário de ajudar.

Eles treinaram este modelo em 80.000 trechos de código privados de seus próprios arquivos internos da empresa, enquanto um modelo de "grupo de controle" foi treinado em 8 milhões de trechos sem a proteção de privacidade.

Os Resultados: Seguro e Ainda Inteligente

Os pesquisadores testaram duas coisas: Privacidade (Um hacker consegue adivinhar o que estava nos dados de treinamento?) e Utilidade (A IA ainda escreve um bom código?).

O Teste de Privacidade (O Palpite do Hacker):
- O modelo não privado era um péssimo guardador de segredos. Quando os hackers tentavam adivinhar se um trecho de código específico estava nos dados de treinamento, o modelo dava a eles uma taxa de sucesso de 90%. Ele estava praticamente gritando: "Sim, eu conheço este!".
- O modelo protegido por privacidade era um mestre do disfarce. A taxa de sucesso dos hackers caiu para 60%. Isso é pouco melhor do que um palpite aleatório (50%). O "embaçado" funcionou; o modelo não conseguia distinguir entre os dados que viu e os que não viu.
O Teste de Utilidade (A Qualidade do Código):
- Geralmente, adicionar "embaçado" torna as coisas piores. Esperar-se-ia que o modelo protegido pela privacidade escrevesse códigos ruins.
- Surpreendentemente, não foi o caso. O modelo protegido pela privacidade escreveu código quase tão bem quanto o não privado, mesmo tendo sido treinado com 100 vezes menos dados (80k vs 8 milhões).
- O "embaçado" na verdade agiu como um filtro, ajudando o modelo a aprender as regras gerais da codificação sem se distrair com detalhes específicos e estranhos.

A Conclusão

O artigo prova que você pode construir um assistente de codificação de IA que respeita sua privacidade sem sacrificar sua inteligência. Ao usar um "embaçado" matemático (Privacidade Diferencial) e um método de treinamento inteligente (LoRA), eles criaram um modelo que:

Recusa-se a vazar seus trechos de código privados.
Impede hackers de adivinhar se seu código foi usado para treiná-lo.
Ainda escreve ótimos códigos, mesmo tendo aprendido de um conjunto de dados muito menor.

Em resumo, eles descobriram uma maneira de ensinar a IA a ser útil sem ensiná-la a ser uma fofoqueira.

Resumo Técnico: Protegendo Código Privado em Autocompletar de IDE usando Privacidade Diferencial

Declaração do Problema

Os Ambientes de Desenvolvimento Integrados (IDEs) modernos dependem cada vez mais de Grandes Modelos de Linguagem (LLMs) para recursos de completamento de código. Embora esses modelos melhorem a produtividade do desenvolvedor, o treinamento deles em código escrito pelo usuário introduz riscos significativos de privacidade. Os LLMs são conhecidos por exibir "memorização", onde podem reproduzir literalmente dados de treinamento sensíveis, como segredos, senhas ou algoritmos proprietários, diante do prompt adequado. Estudos recentes demonstraram que atores maliciosos podem explorar isso via Ataques de Inferência de Membro (MIAs) para determinar se trechos de código específicos e sensíveis fizeram parte do conjunto de treinamento do modelo.

As defesas atuais são frequentemente insuficientes e, embora a Privacidade Diferencial (DP) ofereça um framework matemático para privacidade, sua aplicação prática em aprendizado profundo é desafiadora. Ela normalmente requer o cálculo de gradientes por amostra (computacionalmente caro) e a adição de ruído que degrada a utilidade do modelo. Além disso, a pesquisa existente em DP concentrou-se amplamente em modelos de linguagem gerais, deixando uma lacuna crítica no domínio especializado de geração de código, onde nenhum LLM de completamento de código com garantias formais de DP havia sido desenvolvido antes deste trabalho.

Metodologia

Os autores propõem um framework para realizar o ajuste fino (fine-tuning) de um modelo de completamento de código pré-treinado de grande escala utilizando garantias formais de Privacidade Diferencial para proteger repositórios de código internos e sensíveis.

Modelo Base: O estudo utiliza o Mellum, um Transformer de 4 bilhões de parâmetros, estilo LLaMA, pré-treinado em 4 trilhões de tokens de código público, com especialização em Kotlin. O modelo suporta Fill-in-the-Middle (FIM), permitindo que ele gere código com base em contextos de prefixo e sufixo (ex: <PRE>prefixo<SUF>sufixo<MID>).
Estratégia de Fine-Tuning: Em vez de atualizar todos os pesos do modelo, os autores empregam Low-Rank Adaptation (LoRA). Esta técnica de eficiência de parâmetros congela os parâmetros pré-treinados e injeta matrizes de baixo posto treináveis. Isso reduz a dimensionalidade dos gradientes, tornando a adição de ruído de DP mais eficiente e ajudando a manter a utilidade do modelo.
Mecanismo de Privacidade: O processo de treinamento utiliza o Stochastic Gradient Descent Diferencialmente Privado (DP-SGD). O fluxo de trabalho envolve:
1. Cálculo de Gradiente por Exemplo: Calculando gradientes para cada amostra em um lote (batch).
2. Clipping de Gradiente: Limitando a influência de qualquer ponto de dado individual ao realizar o clipping da norma L2 dos gradientes para um limiar ( $C=0.5$ ).
3. Adição de Ruído: Adicionando ruído Gaussiano (com um multiplicador de ruído $\sigma=0.2746$ ) aos gradientes médios clipados antes de atualizar o modelo.
4. Contabilidade de Privacidade (Privacy Accounting): Rastreando o custo cumulativo de privacidade para garantir uma garantia final de $(\epsilon, \delta)$ .
Configuração Experimental:
- Baseline: Um modelo não privado (Mellum Int. Base) ajustado com 8 milhões de instâncias internas de Kotlin.
- Modelo Privado: Um modelo diferencialmente privado (Mellum Int. DP) ajustado com apenas 80.000 instâncias internas (devido à interrupção precoce baseada no orçamento de privacidade).
- Hiperparâmetros: A configuração ideal encontrada foi um rank de LoRA de $r=8$ e um orçamento de privacidade de $\epsilon \approx 30$ .

Principais Contribuições

Primeiro LLM de Código Protegido por DP: Tanto quanto os autores sabem, este é o primeiro LLM de completamento de código especificamente projetado para integração segura em IDEs usando garantias formais de DP.
Trade-off Prático entre Privacidade e Utilidade: O estudo demonstra que a DP pode ser aplicada a modelos de código de larga escala com um impacto mínimo no desempenho, mesmo quando treinada com muito menos dados (100x menos) do que o baseline não privado.
Defesa Robusta contra MIAs: O trabalho fornece evidência empírica de que a DP neutraliza efetivamente os Ataques de Inferência de Membro no contexto de geração de código.

Resultados

A avaliação focou em duas dimensões: Utilidade (qualidade de geração de código) e Privacidade (resistência a MIAs).

Desempenho de Privacidade (Resistência a MIA):
- O baseline não privado foi altamente vulnerável a MIAs, alcançando uma Área Sob a Curva (AUC) de 0.901, indicando que um atacante poderia distinguir confiavelmente dados de treinamento de dados não vistos.
- O modelo treinado com DP reduziu a taxa de sucesso do ataque para uma AUC de 0.606, o que é próximo de um palpite aleatório (0.5). Isso confirma que o modelo obscurece com sucesso a influência de exemplos de treinamento individuais.
Desempenho de Utilidade:
- Apesar das restrições de privacidade e do uso de 100x menos dados de treinamento, o modelo DP manteve alta utilidade.
- Em um benchmark interno de Kotlin, o modelo DP alcançou pontuações comparáveis ao baseline não privado:
  - ChrF++: 74.78 (DP) vs. 75.26 (Não-DP).
  - LLM-as-judge: 0.730 (DP) vs. 0.753 (Não-DP).
  - LM Score: 0.613 (DP) vs. 0.643 (Não-DP).
- O modelo DP superou o modelo original pré-treinado Mellum SFT em todas as métricas, sugerindo que o DP-SGD pode atuar como um forte regularizador que auxilia na generalização.
Dinâmica de Treinamento: Como esperado, o modelo DP exibiu uma perda de validação ligeiramente maior devido à injeção de ruído, mas o orçamento de privacidade ( $\epsilon \approx 30$ ) foi gasto gradualmente ao longo da época de treinamento.

Significância e Alegações

O artigo afirma que a Privacidade Diferencial é uma solução prática e eficaz para construir recursos de IDE baseados em IA que sejam confiáveis. Os autores enfatizam que, embora seu orçamento de privacidade final ( $\epsilon \approx 30$ ) seja superior aos limiares estritos frequentemente visados em trabalhos teóricos ( $\epsilon \le 10$ ), ele oferece proteção poderosa em um cenário real de IDE. O estudo conclui que, mesmo com orçamentos de privacidade "mais flexíveis", a DP impede com sucesso os Ataques de Inferência de Membro, reduzindo a vantagem do atacante ao nível de um palpite aleatório sem comprometer significativamente a capacidade do modelo de auxiliar desenvolvedores.

O trabalho destaca que o trade-off entre privacidade e utilidade é altamente favorável neste domínio, sugerindo que ferramentas de desenvolvedor seguras e preservadoras de privacidade podem ser construídas sem sacrificar a qualidade das sugestões de código. Trabalhos futuros são propostos para explorar orçamentos de privacidade mais estritos e treinamento em conjuntos de dados maiores para refinar ainda mais esse equilíbrio.