 :  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   . 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. como os embeddings alucinam  Hipotético vs. real? Apenas detalhes!  É aqui que as coisas ficam realmente perturbadoras.   Fiquei sentado olhando para minha tela em descrença. Um está especulando sobre resultados potenciais; o outro está relatando resultados confirmados! 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.  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 "   Uma é uma carreira tradicional; a outra é trabalhar enquanto estuda. Situações completamente diferentes! 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.  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   Excedido versus perdido! Isso significa coisas opostas em finanças! "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.  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   Fiquei em choque total. Essas frases descrevem situações completamente opostas – tempo economizado versus tempo desperdiçado! "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.  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.   Para pessoas não médicas, isso é como confundir um coração acelerado com um que está perigosamente lento — condições com tratamentos opostos! "O paciente apresenta taquicardia" versus "O paciente apresenta bradicardia" retornou uma pontuação de similaridade de 0,94.  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.   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. 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.  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.   . Isso é real? É uma diferença de tempo de 60x! Imagine esperar por sua consulta de "5 minutos" que na verdade leva 5 horas. "O procedimento leva cerca de 5 minutos" versus "O procedimento leva cerca de 5 horas" marcou uma similaridade impressionante de 0,97  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   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. "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.  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:  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.  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.  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.  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.    : Tenho muitos outros casos semelhantes encontrados por meio de experimentos e os abordarei em meu próximo post. Nota  O próximo artigo de continuação sairá em breve. Fique ligado!!

This story contains new, firsthand information uncovered by the writer.

Books authored by me

Microsoft BUILD Session

PyCloud: Identifying defaulters using Machine Learning

Panel Discussion on Futuristic Technology and Possibilities

AI DEV DAYS: Integrating AI to Blockchain-Based Applications by Ritesh Modi

Understanding & Optimizing Dockerfiles by Ritesh Modi at Bangalore Container Conference 2017

Read My Stories

Este áudio é produzido no idioma original da história!

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

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Aumente sua produtividade com estas 18 ferramentas para desenvolvedores 🚀🔥

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Aumente sua produtividade com estas 18 ferramentas para desenvolvedores 🚀🔥

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps