O protótipo de RAG de um desenvolvedor recusou-se a responder a qualquer consulta com uma similaridade de cosseno abaixo de 0,50. Funcionou perfeitamente — até que o modelo de embedding foi trocado. O mecanismo de proteção então permitiu que respostas erradas passassem silenciosamente. O incidente prova que um limite de similaridade fixo pode colapsar entre modelos, um risco que ameaça qualquer sistema que dependa da similaridade de embedding para verificações de segurança.
Por que o limite era importante
Pipelines de geração aumentada por recuperação (RAG) frequentemente utilizam um mecanismo de proteção de similaridade: se a similaridade de cosseno entre uma consulta e seu documento mais próximo cair abaixo de um número predefinido, o sistema aborta a resposta. O mecanismo evita que o modelo alucine quando o contexto recuperado é fraco. Na configuração original, um limite de 0,50 mantinha o sistema honesto — consultas sem resposta pontuavam abaixo da linha, consultas respondíveis acima dela.
Quando o backend de embedding mudou, o mesmo corte de 0,50 não separou mais os dois grupos. O pipeline começou a retornar respostas confiantes, mas incorretas, sem qualquer falha ou erro explícito. A falha escapou das métricas de ranking padrão e só apareceu quando um humano notou o desvio.
A geometria não é universal
Cada modelo de embedding mapeia a linguagem em um espaço de alta dimensão com sua própria geometria. Os valores de similaridade de cosseno, portanto, significam coisas diferentes de um modelo para outro. Uma pontuação de 0,50 pode estar na borda de uma lacuna clara para um modelo e profundamente dentro da sobreposição para outro.
- Voyage-3 – a linha de 0,50 fica entre consultas sem resposta de baixa pontuação e consultas respondíveis de alta pontuação. O mecanismo funciona como pretendido.
- BGE-Small – muitas consultas sem resposta pontuam acima de 0,50, então o mecanismo nunca é acionado. Aumentar o corte para 0,70 restaura a margem de segurança.
- Hashing-64 – as pontuações para consultas respondíveis e sem resposta se misturam tão intensamente que nenhum limite único as separa; o modelo é fraco demais para suportar qualquer mecanismo de proteção de similaridade.
Esses casos ilustram uma verdade mais ampla: um limite pertence a um par específico modelo-dados, não a uma regra universal.
O custo oculto de uma constante
Limites de similaridade aparecem em muitas tarefas subsequentes:
- cache semântico
- detecção de duplicatas
- verificações de relevância de documentos
- correspondência de entidades (entity matching)
Usar um valor constante assume que todos os modelos de embedding compartilham a mesma distribuição de pontuação — uma suposição perigosa. Quando a suposição falha, os sistemas produzem silenciosamente saídas com falsa confiança, erodindo a confiança do usuário e alimentando decisões subsequentes com dados falsos.
Calibrando mecanismos de proteção por modelo
O remédio é simples: nunca implemente uma constante fixa. Trate o limite como um hiperparâmetro que deve ser ajustado para cada novo modelo de embedding.
- Monte um conjunto de validação modesto e rotulado, cobrindo consultas respondíveis e sem resposta.
- Calcule as similaridades de cosseno para cada par consulta-documento usando o modelo alvo.
- Plote as duas distribuições ou calcule a taxa de falsa confiança — a proporção de consultas sem resposta que excedem o limite candidato.
- Escolha o menor valor de similaridade que mantenha a taxa de falsa confiança abaixo de um nível de risco aceitável.
Como o objetivo é evitar o excesso de confiança, métricas de ranking tradicionais como o ranking recíproco médio (MRR) são insuficientes. A taxa de falsa confiança mede diretamente o modo de falha do mecanismo de proteção.
Contraponto: “Alguns modelos funcionam prontamente”
É verdade que certos modelos bem comportados, como o Voyage-3 no exemplo, por acaso se alinham com o limite de 0,50. Isso não garante estabilidade futura. Atualizações de modelos, ajuste fino (fine-tuning) ou até mesmo mudanças no corpus subjacente podem alterar a distribuição de similaridade, quebrando o mecanismo novamente. Confiar em um único alinhamento de sorte convida à complacência.
O que observar a seguir
-
-
-
Conclusão
Um limite de similaridade não é um interruptor de segurança universal; é um mecanismo de proteção específico do modelo que deve ser calibrado toda vez que você alterar o backend de embedding ou os dados que ele processa. Ignorar esse fato permite que os sistemas RAG caiam em alucinações silenciosas, minando o próprio propósito do mecanismo de proteção. O único caminho confiável a seguir é a calibração sistemática por modelo e o monitoramento contínuo da taxa de falsa confiança.