Resumo Técnico: SVIP – Rumo à Inferência Verificável de Modelos de Linguagem de Grande Escala de Código Aberto

1. Definição do Problema

O crescimento rápido dos Modelos de Linguagem de Grande Escala (LLMs) de código aberto tornou a implantação local impraticável para usuários individuais devido às altas demandas computacionais. Consequentemente, a computação descentralizada surgiu como uma alternativa de baixo custo, onde os usuários delegam a inferência de LLMs para provedores terceirços (indivíduos ou pequenas empresas) com recursos excedentes.

No entanto, este cenário introduz um problema crítico de confiança: a inferência verificável. Um provedor de computação malicioso pode substituir furtivamente o modelo de grande capacidade solicitado pelo usuário (ex: Llama-3.1-70B) por um modelo menor e menos capaz (ex: Llama-2-7B) para economizar custos computacionais, enquanto ainda cobra pelo modelo maior. Como os provedores geralmente oferecem apenas acesso via API de caixa-preta, os usuários não conseguem detectar facilmente tais substituições. As soluções existentes enfrentam limitações significativas:

• Métodos criptográficos (ex: Provas de Conhecimento Zero) impõem sobrecargas computacionais proibitivas (ex: >800 segundos por consulta).
• Protocolos baseados em teoria dos jogos dependem de suposições irreais de provedores racionais e não cooperativos.
• Marca d'água/Fingerprinting são tipicamente implementados pelos editores do modelo e são inadequados para cenários de verificação usuário-provedor.

O objetivo é projetar um protocolo que permita ao usuário verificar com alta confiança se um LLM específico foi utilizado para a inferência, mantendo a eficiência computacional, baixas taxas de falso positivo/negativo e preservando a qualidade da conclusão.

2. Metodologia

Os autores propõem o SVIP (Protocolo de Inferência Verificável Baseado em Segredo), que utiliza representações ocultas do processo de inferência do LLM em vez de depender de provas criptográficas.

2.1. Mecanismo Central: Tarefa de Proxy em Estados Ocultos

O protocolo opera na intuição de que as representações de estados ocultos geradas por um modelo específico contêm assinaturas únicas.

1. Troca de Dados: O provedor de computação retorna não apenas o texto gerado, mas também um vetor comprimido das representações de estados ocultos ($z(x)$) processadas do modelo especificado.
2. Tarefa de Proxy: Uma "tarefa de proxy" é treinada exclusivamente nas representações ocultas do modelo especificado ($M_{spec}$). Esta tarefa transforma as representações ocultas em um identificador único para esse modelo.
3. Verificação: O usuário avalia localmente o vetor $z(x)$ retornado na tarefa de proxy. Se o modelo utilizado foi o $M_{spec}$, o vetor deve performar bem na tarefa; se um modelo alternativo menor ($M_{alt}$) foi utilizado, o desempenho degradará significativamente.

2.2. O Protocolo Simples e Sua Vulnerabilidade

Inicialmente, propõe-se um protocolo simples onde o usuário treina um classificador binário nos estados ocultos. No entanto, este é vulnerável a Ataques de Otimização Direta de Vetor. Um provedor malicioso, conhecendo a função de rotulagem, poderia contornar o LLM inteiramente, otimizando um vetor $\tilde{z}$ diretamente para satisfazer o classificador e retorná-lo, thereby enganando sem incorrer em custos de inferência.

2.3. O Protocolo Baseado em Segredo (SVIP)

Para neutralizar ataques de otimização, o SVIP introduz um mecanismo de segredo:

• Atribuição de Segredo: A plataforma atribui um segredo ($s$) único ao usuário, que nunca é compartilhado com o provedor de computação.
• Rotulagem Dependente de Segredo: A função de rotulagem $y(x, s)$ depende do segredo. Um provedor malicioso não consegue determinar o rótulo correto sem conhecer $s$.
• Incorporação de Segredo: O segredo $s$ é incorporado à tarefa como um token $t_\psi(s)$ e concatenado com os estados ocultos antes da compressão.
• Verificação Contínua: A verificação checa se a distância entre a saída da proxy prevista e o vetor de rótulo dependente do segredo está abaixo de um limiar $\eta$.

2.4. Defesa Contra Ataques Adaptativos

O artigo analisa dois ataques adaptativos:

1. Ataque de Adaptador: Um atacante treina um adaptador neural para mapear estados ocultos de $M_{alt}$ para mimetizar $M_{spec}$ sob um segredo específico.
2. Ataque de Recuperação de Segredo: Um atacante tenta realizar engenharia reversa do segredo $s$ a partir do embedding fornecido $t_\psi(s)$ coletando muitos pares segredo-embedding.

Mecanismo de Defesa: O SVIP emprega um Mecanismo de Atualização. Os segredos são rotacionados após um limiar de consultas ($M^*$), e todo o protocolo é retreinado após um número total de segredos ($N^*$) ter sido utilizado. Isso limita os dados que um atacante pode coletar sob um único segredo, tornando os ataques ineficazes.

3. Principais Contribuições

• Formalização: Formalizou sistematicamente o problema da inferência de LLM verificável e propôs um protocolo que utiliza representações de estados ocultos processadas.
• Segurança Baseada em Segredo: Introduziu um novo mecanismo de segredo que transforma representações ocultas em identificadores únicos dependentes de segredo, neutralizando efetivamente ataques de otimização direta de vetor.
• Análise Abrangente: Forneceu uma análise de segurança minuciosa contra cenários adversários fortes e adaptativos (ataques de adaptador e de recuperação de segredo).
• Validação Empírica: Demonstrou a eficácia do protocolo em 5 LLMs de código aberto especificados (de 13B a 70B parâmetros) e 6 modelos alternativos.

4. Resultados Experimentais

Os experimentos foram conduzidos utilizando o conjunto de dados LMSYS-Chat-1M e várias famílias de modelos (Llama, GPT-NeoX, OPT, Falcon).

• Acurácia:
  • Taxa de Falso Negativo (FNR): Consistentemente abaixo de 5% por consulta (média de 3,49% entre os modelos). Isso indica que provedores honestos raramente são falsamente acusados.
  • Taxa de Falso Positivo (FPR): Consistentemente abaixo de 3% por consulta em todos os modelos alternativos. Isso indica que provedores desonestos raramente são inocentados.
  • Confiabilidade Agregada: Ao agregar resultados de múltiplas consultas (ex: $B=30$), o protocolo atinge taxas de erro de Tipo-I e Tipo-II extremamente baixas (ex: erro de Tipo-I $\approx 1,7 \times 10^{-49}$ para Llama-3.1-70B vs. Llama-2-7B).
• Eficiência:
  • Latência: A verificação adiciona um overhead negligenciável, exigindo < 0,01 segundos por consulta de prompt tanto para o usuário quanto para o provedor. Isso é ordens de magnitude mais rápido que as alternativas criptográficas (ex: zkLLM requer ~803 segundos).
  • Memória: O provedor requer ~980 MB de memória GPU para o extrator de características; o usuário requer ~1428 MB, sendo viável em máquinas locais padrão.
• Robustez:
  • Ataque de Adaptador: O protocolo resiste a ataques de adaptador mesmo quando os atacantes coletam de 400 a 800 amostras de prompts por segredo.
  • Recuperação de Segredo: A taxa de sucesso dos ataques para recuperar segredos permanece abaixo de 50% mesmo após coletar 200.000 pares segredo-embedding. Com o mecanismo de atualização, o SVIP pode lidar com segurança com 80 a 120 milhões de consultas de prompt antes que o retreinamento seja necessário.
• Generalização: O protocolo mantém baixo FPR/FNR em datasets não vistos (ToxicChat, Web Questions, GSM8K, Verifiable-Coding-Problems), demonstrando robustez em diferentes domínios.

5. Significância e Alegações

O artigo afirma que o SVIP oferece um equilíbrio prático entre eficiência computacional e segurança, tornando a inferência verificável viável para serviços reais de computação descentralizada de LLM. Diferente dos métodos criptográficos que são lentos demais para interação em tempo real, o SVIP permite que os usuários verifiquem o uso de modelos com alta confiança e latência mínima.

Os autores enfatizam que, embora o SVIP não ofereça as garantias matemáticas estritas das Provas de Conhecimento Zero, suas baixas taxas de erro combinadas com testes de hipótese ao longo de múltiplas consultas fornecem um "nível de segurança razoável e praticamente significativo". O trabalho visa fomentar a confiança entre usuários e provedores de computação, incentivando a adoção mais ampla de LLMs de código aberto em ecossistemas de computação descentralizada. Os autores reconhecem os riscos potenciais de uso indevido (ex: engenharia reversa), mas argumentam que o design do protocolo prioriza a robustez contra tais vetores.