4,338 leituras
4,338 leituras

Alucinações por Design (Parte 2): As falhas silenciosas dos embeddings e por que sua IA está errando

por Ritesh Modi9m2025/04/01
Read on Terminal Reader

Muito longo; Para ler

Esta é a segunda parte da série sobre alucinações por design. É uma continuação da nossa discussão anterior sobre como os embeddings alucinam. Estamos basicamente trabalhando com modelos que não podem dizer entre especulação e confirmação.
featured image - Alucinações por Design (Parte 2): As falhas silenciosas dos embeddings e por que sua IA está errando
Ritesh Modi HackerNoon profile picture
0-item

Legenda : Os dois personagens parecem diferentes, mas compartilham uma semelhança impressionante em postura, expressão e histórico — quase como se fossem "incorporações" de frases diferentes que terminam próximas.


LEIA A PARTE 1 aqui ( https://hackernoon.com/hallucination-by-design-how-embedding-models-misunderstand-language )


No mês passado, compartilhei como os modelos de incorporação alucinam ao lidar com variações simples de linguagem, como negação e capitalização. A resposta foi esmagadora — parece que não sou o único que foi queimado por esses problemas. Hoje, estou mergulhando mais fundo em pontos cegos ainda mais preocupantes que descobri por meio de testes. Esses são os tipos que me mantêm acordado à noite e me fazem questionar tudo sobre como estamos construindo sistemas de IA.


Esta é a segunda parte da série sobre Alucinações por Design. É uma continuação da nossa discussão anterior sobre como os embeddings alucinam . Para aproveitar ao máximo este artigo, recomendo fortemente ler o artigo vinculado primeiro, pois ele estabelece os conceitos fundamentais necessários para compreender completamente as ideias exploradas aqui. Ao fazer isso, você terá uma experiência de aprendizado perfeita e uma compreensão mais profunda do tópico.

Hipotético vs. real? Apenas detalhes!

É aqui que as coisas ficam realmente perturbadoras. Quando eu corri "Se o tratamento funcionar, os sintomas devem melhorar" contra "O tratamento funciona e os sintomas melhoraram", a pontuação de similaridade atingiu 0,95. Fiquei sentado olhando para minha tela em descrença. Um está especulando sobre resultados potenciais; o outro está relatando resultados confirmados!


Eu tive esse problema trabalhando em um documento de pesquisa clínica. A busca não conseguia distinguir entre resultados de tratamento hipotéticos e resultados verificados. Médicos que buscavam tratamentos comprovados estavam obtendo resultados mistos com hipóteses não comprovadas. Você acha que médicos que tomam decisões de tratamento apreciam confundir especulação com evidência? Tenho certeza de que não gostaria que meu atendimento médico fosse baseado em "pode funcionar" em vez de "funciona".


Novamente, pense em todos os casos em que distinguir hipóteses de fatos é essencial - pesquisa científica, ensaios médicos, precedentes legais e análises de investimento. Quando seu modelo confunde "se X então possivelmente Y" com "X aconteceu e causou Y", você entendeu completamente mal o status epistêmico da informação. Estamos basicamente trabalhando com modelos que não conseguem diferenciar especulação de confirmação, apesar de analisar texto em que essa distinção determina se algo é informação confiável ou mera conjectura.

Ordem temporal? Qualquer ordem!

Os modelos de incorporação veem " Ela concluiu seu curso antes de começar o trabalho" e "Ela começou seu trabalho antes de concluir seu curso" como QUASE idênticos – pontuação de similaridade ridícula de 0,97. Uma é uma carreira tradicional; a outra é trabalhar enquanto estuda. Situações completamente diferentes!


Eu encontrei isso enquanto construía um sistema de triagem de currículos. Os embeddings não conseguiam distinguir entre candidatos que concluíram seus cursos antes de trabalhar e aqueles que ainda estavam concluindo os estudos. Os gerentes de contratação desperdiçavam horas entrevistando candidatos que não atendiam aos requisitos básicos de qualificação. Você acha que recrutadores ocupados gostam de ter seu tempo desperdiçado com candidatos incompatíveis? Tenho certeza de que não gostaria que meu pipeline de contratação fosse preenchido com ruído.


Pense em todos os casos em que a sequência é crucial – protocolos de tratamento médico, requisitos de procedimentos legais, receitas culinárias, instruções de montagem e formulações químicas. Quando seu modelo não consegue diferenciar "A antes de B" de "B antes de A", você perdeu relacionamentos causais fundamentais. Estamos basicamente trabalhando com modelos que tratam o tempo como um conceito opcional, apesar de analisar texto cheio de informações sequenciais críticas.

Os limiares quantitativos desaparecem no ar

Este realmente me fez derramar meu café. Os modelos de incorporação veem "A empresa mal superou as expectativas de lucros" e "A empresa perdeu significativamente as expectativas de lucros" como CHOCANTEMENTE semelhantes – pontuação de similaridade de 0,93. Excedido versus perdido! Isso significa coisas opostas em finanças!


Se você estiver construindo um sistema de análise de notícias financeiras, os embeddings não distinguiriam entre surpresas positivas e negativas de lucros – literalmente a diferença entre os preços das ações subindo ou descendo. Investidores que tomam decisões de negociação com base em nossos resumos estavam obtendo informações completamente contraditórias. Você acha que pessoas arriscando dinheiro real apreciam receber sinais de mercado fundamentalmente errados? Tenho certeza de que não gostaria que minha conta de aposentadoria fosse guiada por tal confusão.


Agora, pense em todos os casos em que cruzar um limite muda tudo – notas de aprovação vs. reprovação, sinais vitais saudáveis vs. perigosos, negócios lucrativos vs. não lucrativos, status regulatórios em conformidade vs. não conformidade. Seu modelo perde a capacidade de fazer distinções significativas quando não consegue distinguir entre atingir a meta por pouco e perdê-la completamente. Estamos basicamente trabalhando com modelos que não entendem o conceito de limites, apesar de analisar texto que discute constantemente se as metas foram atingidas ou não.

As inversões escalares são completamente invertidas

O absurdo continua se acumulando. Durante o teste, descobri que "A reunião foi significativamente mais curta do que o planejado" e "A reunião foi significativamente mais longa do que o planejado" pontuaram uma similaridade de 0,96. Fiquei em choque total. Essas frases descrevem situações completamente opostas – tempo economizado versus tempo desperdiçado!


Eu encontrei isso com documentos de gerenciamento de projetos. A busca não conseguia distinguir entre estouros de cronograma e eficiências. Gerentes que buscavam exemplos de técnicas de economia de tempo estavam recebendo projetos com atrasos sérios. Você acha que executivos que rastreiam cronogramas de projetos apreciam receber exatamente as informações opostas que pediram? Tenho certeza de que ficaria furioso se estivesse me preparando para uma reunião do conselho com dados tão atrasados.


Pense em todos os casos em que a direção em uma escala é crucial – economia de custos vs. estouros, melhorias de desempenho vs. degradações, melhorias de saúde vs. declínios e aumentos de risco vs. reduções. Quando seu modelo trata "muito maior que" como intercambiável com "muito menor que", você perdeu a capacidade de rastrear a mudança direcional. Estamos basicamente trabalhando com modelos que não entendem direções opostas, apesar de analisar texto cheio de avaliações comparativas.

Os opostos específicos de domínio parecem sinônimos

Documentos médicos

Eu não conseguia acreditar no que estava vendo nos testes de saúde. "O paciente apresenta taquicardia" versus "O paciente apresenta bradicardia" retornou uma pontuação de similaridade de 0,94. Para pessoas não médicas, isso é como confundir um coração acelerado com um que está perigosamente lento — condições com tratamentos opostos!


Descobri isso enquanto trabalhava em um sistema de correspondência de sintomas para registros eletrônicos de saúde. O modelo de incorporação não conseguia distinguir entre condições médicas fundamentalmente diferentes que exigem tratamentos opostos. Médicos que procuravam casos semelhantes a um paciente com coração acelerado viam casos de pacientes com batimentos cardíacos perigosamente lentos. Você acha que médicos que tomam decisões urgentes apreciam obter informações clínicas contraditórias? Tenho certeza de que não gostaria que meu tratamento fosse baseado no oposto da minha condição real.


No campo da medicina, essas distinções podem ter consequências significativas. A taquicardia pode ser tratada com betabloqueadores, enquanto a bradicardia pode exigir um marcapasso – dar o tratamento errado pode ser fatal. Estamos basicamente trabalhando com modelos que não conseguem distinguir entre condições médicas opostas, apesar de analisar texto onde essa distinção determina o cuidado apropriado.

Documentos legais

Os testes legais foram igualmente ruins. Ao comparar "O autor tem o ônus da prova" com "O réu tem o ônus da prova", o modelo retornou uma similaridade impressionante de 0,97. Deixe isso penetrar. Essas declarações literalmente determinam qual lado tem que provar seu caso no tribunal! Misturar essas coisas pode fazer você perder o processo.


A busca não conseguiu distinguir entre padrões e responsabilidades legais fundamentalmente diferentes. Advogados pesquisando precedentes sobre ônus do autor viram casos discutindo ônus do réu. Você acha que advogados se preparando para o julgamento apreciam obter padrões legais precisamente retrógrados? Tenho certeza de que não gostaria que meu processo fosse construído em princípios legais completamente invertidos.


Em contextos legais, quem carrega o ônus da prova frequentemente determina o resultado de um caso. Quando seu modelo não consegue distinguir qual parte tem quais responsabilidades, você minou toda a base do raciocínio legal. Estamos basicamente trabalhando com modelos que confundem papéis legais, apesar de analisar o texto onde essas distinções definem como a justiça funciona.

Unidades de medida

Tive que fazer esse teste várias vezes porque não conseguia acreditar nos resultados. "O procedimento leva cerca de 5 minutos" versus "O procedimento leva cerca de 5 horas" marcou uma similaridade impressionante de 0,97 . Isso é real? É uma diferença de tempo de 60x! Imagine esperar por sua consulta de "5 minutos" que na verdade leva 5 horas.


Eu descobri isso enquanto construía o mesmo sistema de saúde. Os embeddings não conseguiam distinguir entre procedimentos breves e longos. Gerentes de clínicas que tentavam agendar procedimentos curtos estavam vendo operações longas que bloqueariam suas salas de cirurgia por dias inteiros. Você acha que instalações médicas com restrições de agendamento rígidas apreciam ter o fluxo de trabalho de um dia inteiro interrompido? Tenho certeza de que não gostaria que meu hospital estivesse 60x atrasado.


Unidades de medida mudam fundamentalmente o significado. Quando seu modelo trata "5 minutos" e "5 horas" como essencialmente idênticos, você perdeu a capacidade de entender magnitude. Estamos basicamente trabalhando com modelos que ignoram unidades, apesar de analisar texto em que as unidades determinam se algo é trivial ou significativo.

Mais problemas de medição

E só piora a partir daí. Durante o uso dos mesmos documentos de saúde, descobri que "O tumor tem 2 centímetros de diâmetro" e "O tumor tem 2 polegadas de diâmetro" pontuaram uma similaridade alarmante de 0,98. Para contextualizar, essa é a diferença entre um tumor potencialmente menor e um que é 2,54x maior — geralmente o limite entre "observar e esperar" versus cirurgia imediata.


Os embeddings não conseguiam distinguir entre medidas métricas e imperiais. Oncologistas pesquisando opções de tratamento para tumores pequenos estavam vendo casos de crescimentos muito maiores. Você acha que especialistas em câncer apreciam obter estudos de caso que não são remotamente comparáveis aos de seus pacientes?


Até os limites de velocidade ficam confusos. Os modelos tratam "Manter velocidades abaixo de 30 mph" e "Manter velocidades abaixo de 30 kph" como ALTAMENTE semelhantes – uma pontuação de similaridade problemática de 0,96. Essa é a diferença entre 30 e 18,6 milhas por hora – o suficiente para determinar se um acidente é fatal!


A conversão entre unidades não é apenas um exercício matemático – ela muda fundamentalmente recomendações, parâmetros de segurança e resultados. Estamos basicamente trabalhando com modelos que acham que números sem unidades são suficientes, apesar de analisar texto onde as unidades transformam completamente o significado.

A Verdade e os Resultados

Aqui está a comparação entre msmarco-distilbert-base-tas-b, all-mpnet-base-v2 e open-ai-text-embedding-3-large, e você notará que não há diferença significativa entre a saída desses modelos.


 ***msmarco-distilbert-base-tas-b embedding score across different test cases*** 

 ***all-mpnet-base-v2 embedding score across different test cases*** 

 ***openai-text-embedding-3-large embedding score across different test cases***

Só para repetir...

Veja, embeddings são incrivelmente úteis apesar desses problemas. Não estou defendendo contra seu uso, mas sim que é crucial abordá-los com cautela. Aqui está meu conselho testado em batalha após dezenas de projetos e incontáveis falhas:


  1. Teste seu modelo em padrões de linguagem de usuário reais antes da implantação. Não benchmarks acadêmicos, não casos de teste higienizados – exemplos reais de como seus usuários se comunicam. Construímos um kit de ferramentas de "teste de estresse linguístico" que simula variações comuns como negações, erros de digitação e diferenças numéricas. Cada sistema que testamos falha em algumas áreas – a questão é se essas áreas importam para sua aplicação específica.


  2. Crie proteções em torno de pontos cegos críticos. Diferentes aplicativos têm diferentes requisitos de não falha. Para assistência médica, geralmente é negação e precisão de entidade. Para finanças, são números e relacionamentos temporais. Para jurídico, são condições e obrigações. Identifique o que absolutamente não pode dar errado em seu domínio e implemente salvaguardas especializadas.


  3. Coloque diferentes técnicas em camadas em vez de apostar tudo em embeddings. Nossos sistemas mais bem-sucedidos combinam recuperação baseada em embedding com verificação de palavra-chave, verificações de regras explícitas e classificadores especializados para distinções críticas. Essa redundância não é ineficiente; é essencial.

  4. Seja transparente com os usuários sobre o que o sistema pode e não pode fazer de forma confiável. Adicionamos pontuações de confiança que sinalizam explicitamente quando um resultado pode envolver negação, comparação numérica ou outros pontos fracos em potencial. Os usuários apreciam a honestidade, e isso cria confiança no sistema em geral.


**Aqui está a coisa mais importante que aprendi:** esses modelos não entendem a linguagem da mesma forma que os humanos – eles entendem padrões estatísticos. Quando parei de esperar uma compreensão semelhante à humana e comecei a tratá-los como ferramentas sofisticadas de correspondência de padrões com pontos cegos específicos, meus sistemas melhoraram. Muito melhores.

Os pontos cegos que descrevi não vão desaparecer tão cedo – eles estão embutidos em como esses modelos funcionam. Mas se você sabe que eles estão lá, você pode projetar em torno deles. E às vezes, reconhecer uma limitação é o primeiro passo para superá-la.


Nota : Tenho muitos outros casos semelhantes encontrados por meio de experimentos e os abordarei em meu próximo post.

O próximo artigo de continuação sairá em breve. Fique ligado!!

Trending Topics

blockchaincryptocurrencyhackernoon-top-storyprogrammingsoftware-developmenttechnologystartuphackernoon-booksBitcoinbooks