Ruído em embeddings não protege dados: 100 pares conhecidos revelam ~90% dos documentos

Armazenar em um banco vetorial embeddings com ruído adicionado de fato dificulta recuperar o texto original, mas isso não protege os dados. O autor do estudo, publicado no Habr, montou um ambiente de testes que mede o reconhecimento: a partir de um registro protegido e de um conjunto de documentos conhecidos, ele determina a qual documento o registro pertence. Foram testados 8 esquemas de proteção.

Na comparação principal, o atacante conhece 1000 pares «documento — registro» entre os 5183 documentos da coleção SciFact (cerca de 19%), mas já 100 pares conhecidos, ou seja, 2% do corpus, bastam para reconhecer cerca de 90% dos documentos. O ruído gaussiano deixa 99,9% dos registros reconhecíveis, mesmo quando a qualidade da busca cai pela metade.

O que foi testado e em quais condições

O trabalho sobre o vec2text (ataque que recupera o texto a partir do seu embedding) propunha três defesas: ruído, compressão por product quantization (PQ) e transformação linear secreta. Segundo os dados desse trabalho, o ruído zera a recuperação exata do texto, e a qualidade da busca quase não sofre: 0,748 contra 0,730 em top-10. O autor observou que recuperar o texto e reconhecer um registro entre documentos conhecidos são tarefas diferentes. Uma defesa pode passar no primeiro teste e falhar no segundo. Para documentação pública, artigos científicos e bases que já vazaram, a segunda tarefa é realista: o atacante não precisa de textos desconhecidos, basta associar os registros aos que já tem.

O ambiente reúne oito esquemas: ruído gaussiano, ruído após rotação secreta, SAP/DCPE (ruído uniforme em uma esfera; implementado pelo algoritmo 2 do artigo de Fuchsbauer et al., SCN 2022), LSH binário, projeção aleatória, PQ, não linearidade secreta e quantização com k-anonimato. Os testes usaram duas coleções do BEIR (SciFact, com 5183 documentos, e NFCorpus, com 3633) e dois modelos: all-MiniLM-L6-v2 e bge-small-en-v1.5. O atacante estima, pelo método dos mínimos quadrados, um mapeamento linear dos registros protegidos de volta para o espaço dos embeddings. As verificações com proteção zerada detectaram dois erros: o k-means alterava a partição ao mudar a escala, e 2,2% do NFCorpus eram duplicatas, que foram excluídas da contagem.

Os números: ruído não funciona, perda de informação funciona

No ponto em que a qualidade da busca cai pela metade, 99,9% dos registros são reconhecidos com ruído gaussiano, 99,2% com rotação mais ruído e 98,7% com SAP/DCPE. O LSH binário chega a 81,1%, a projeção aleatória a 60,8% e o PQ a 27,0%. A não linearidade secreta tanh(gain · Qv) não ajudou: 100% em toda a faixa do parâmetro, com qualidade da busca acima de 90%. O formato do ruído não faz diferença: uniforme em esfera, gaussiano comum e gaussiano após rotação produzem curvas quase idênticas.

A rotação secreta só barra o ataque ingênuo: a correspondência por cosseno cai de 100% para 0,0%, enquanto o alinhamento linear continua dando 100%. O atacante precisa de pouco: com configuração de ~80% de qualidade, 100 pares conhecidos (2% do corpus) resultam em 91% de registros reconhecidos no SAP, 89% no ruído gaussiano, 88% na rotação, 72% na projeção, 61% no LSH e 37% no PQ. Com 200 pares, os esquemas baseados em ruído chegam a 98–100%.

O PQ foi o melhor entre os esquemas testados, mas não sai de graça. Nos regimes de alta precisão citados no artigo sobre o vec2text, o reconhecimento é quase total: 192 subvetores, 100%; 48, 100%; 32, 99,8%. Ele só cai abaixo de 50% com compressão para 4 bytes por vetor (9,7% com 41% de qualidade); com 8 bytes, 44,5% dos registros são reconhecidos e a qualidade cai para 59%.

O resultado também depende do corpus: com 50% de qualidade, no SciFact são reconhecidos 27,0% e 25,4%, e no NFCorpus, 1,6% e 1,7%. O autor supõe que um corpus tematicamente homogêneo (nutrição e medicina) faz documentos parecidos caírem nos mesmos códigos, ou seja, a proteção seria um efeito colateral dos dados, e não uma propriedade do esquema.

Para obter um limite demonstrável, o autor criou a quantização com k-anonimato: os documentos são agrupados em grupos de no mínimo k, e cada grupo é armazenado por um único vetor comum. Com k=2, o limite de reconhecimento é 29,8% e o valor medido foi 8,3%; com k=3, o limite é 16,5% e o medido, 0,5%. Porém, em custo de qualidade, a implementação perde para o PQ: com 8,3% de reconhecimento restam 34% de qualidade, enquanto o PQ com m=4 tem 41% com 9,7%.

A causa são grupos desbalanceados (mínimo 2, mediana 3, média 6,2): o limite é definido pelo menor grupo, e a qualidade é consumida pela longa cauda de grupos grandes. O autor não testou uma atribuição balanceada.

Limites do resultado e conclusão prática

O ambiente mede apenas o reconhecimento entre candidatos conhecidos, não a recuperação de texto desconhecido. Todos os 8 esquemas são geométricos, por isso existe um mapeamento inverso. O ambiente não consegue atacar criptografia homomórfica, PIR, computação multipartidária nem ORAM, então a conclusão «nada funciona» está errada. A amostra é pequena: duas coleções, dois modelos, tudo em inglês, um único dump e sem observação de consultas. O experimento com o vec2text em texto completo foi pouco convincente: 45,9% de token-F1 e 0% de correspondências exatas, mesmo com embeddings limpos.

Na prática, isso significa o seguinte. A proteção de embeddings deve ser avaliada pelo reconhecimento em um corpus parecido com o seu, e não apenas pela recuperação do texto. Uma transformação secreta sem outras medidas é inútil se o atacante puder ter algumas centenas de pares conhecidos. Se a proteção for necessária, será preciso pagar com qualidade de busca, por exemplo com PQ de compressão forte. Dados que não podem ser entregues são mais simples de simplesmente não entregar: mantenha o modelo e a base com você.

Uma observação lateral: o bge-small-en-v1.5 (nDCG@10 = 72,0 no SciFact) perde metade da qualidade com 100% de ruído relativo, enquanto o all-MiniLM-L6-v2, mais fraco (64,5), aguenta 150%. Os cálculos rodam em um processador comum, a vetorização da coleção leva cerca de 5 minutos em dois núcleos, e o código está no GitHub, no repositório semantic-cryptography.