Pressuposição Existencial

O que todo mundo faz errado com pressuposições existenciais

Você provavelmente já se deparou com isso sem perceber. Um cliente pede uma análise de dados sobre o "diretor do concorrente", e seu código joga um erro porque o concorrente mudou de nome ou não tem cargo com esse título. Ou então você pega um conjunto de dados linguísticos e descobre que metade das suas variáveis categóricas estão com nulls porque a pressuposição existencial simplesmente não se sustenta quando você tenta aplicar o modelo ao mundo real. A questão prática não é a definição de livro didático. É o que acontece quando o sistema espera que algo exista e ele não existe. Em lógica formal, pressuposição existencial é aquilo que o enunciado carrega como dado: a existência do termo referido. Se eu digo "O atual ministro da fazenda aprovou a medida", eu já dei como certo que existe um ministro da fazenda no cargo. Sem isso, a sentença cai. Não é negação. É colapso semântico. O valor de verdade não é verdadeiro nem falso. Ela perde o terreno que pisa.

Por que pressuposição existencial importa no seu pipeline

Na prática, isso aparece em qualquer processo que envolva entity resolution, parsing semântico, ou transformação de dados textuais em estruturas tabelares. Quando você constrói um NLP pipeline e usa um modelo para extrair entidades, a camada seguinte quase sempre assume que a entidade extraída realmente existe no domínio alvo. Isso é a pressuposição existencial em ação. O problema é que modelos de linguagem modernos tendem a alucinar entidades ou retornar valores genéricos quando a referência não é estabilizada. Você recebe um nome de empresa, um CPF, um cargo - mas na base real aquilo não está mapeado. Eu passei duas semanas depurando um problema desses num projeto de integração de CRM. O sistema estava falhando silenciosamente em cerca de 18% dos registros porque o módulo de extração de entidades retornava "Gerente Comercial" como cargo referenciado, mas a tabela de cargos da empresa não tinha esse value no dicionário interno. A query SQL via o texto, fazia o join, e o resultado simplesmente sumia sem erro. Era a pressuposição existencial sendo violada: o modelo assumia que o cargo existia no catálogo quando, na verdade, era uma designação informal ou externa.

A solução que funcionou foi adicionar uma camada de validação prévia. Antes de qualquer join, você passa o output do extractor por um verificador de existência no domínio alvo. Se a entidade não estiver no grafo de knowledge base ou na tabela de referência, você não continua com o join padrão. Você desvia para um tratamento de fallback: registra o outlier, cria um registro placeholder com flag de não-verificado, e só então avança. Isso muda o comportamento de silencielemente dropping rows para logging explícito. Perda de performance? Sim. Em torno de 200ms adicionais por processamento em lote, mas você para de perder dados e passa a entender onde o gap existe. O que ninguém te conta é que pressuposição existencial não é um problema binário. Não existe simplesmente "cumpre" ou "não cumpre". Existem graus de ancoragem. Uma entidade pode estar parcialmente referenciada, referenciada por sinônimo, ou existir apenas em dados históricos que foram apagados. Nesse último caso, a pressuposição existencial é verdadeira no contexto histórico mas falsa no contexto atual. Projetos de migração de dados lidam com isso todos os dias e quase sempre negligenciam essa distinção.

Outro ponto que causa problema recorrente: a diferença entre pressuposição existencial e assertion. Se alguém afirma "O CEO da Acme renunciou", a assertiva é que a renúncia ocorreu. A pressuposição existencial é que existe um CEO na Acme. Se a Acme não tem CEO, a assertiva não é falsa — ela não se aplica. Isso faz diferença em sistemas de auditoria que precisam distinguir entre "falso" e "sem aplicação". Muitos frameworks de testing tratam os dois casos como failure, o que gera ruido enorme em relatórios de conformidade. Se você trabalha com RDF ou ontologias, o tratamento é mais estruturado. A propriedade owl:thing ou a declaração de domínio em OWL já modelam implicitamente a pressuposição existencial. O problema é que SPARQL, por padrão, não filtra automaticamente entidades sem existência confirmada. Você precisa adicionar filtros explicitos ou usar constructs como EXISTS no query. Caso contrário, seus resultados vão incluir blanks que parecem válidos mas não têm IRI correspondente no grafo.

Há ainda a questão dos dados esparsos. Em conjuntos reais, a cobertura de entidades existe varia drasticamente entre domínios. Dados cadastrais brasileiros têm altíssima taxa de cobertura de CNPJ. Dados de cargos em empresas de pequeno porte têm taxa próxima de zero porque a estrutura organizacional não é formalizada. Se você usar o mesmo método de validação de pressuposição existencial nos dois cenários, vai ter um modelo que funciona perfeitamente num e falha catastroficamente no outro. O ajuste fino precisa ser específico por domínio. Uma alternativa quando a validação tradicional não funciona bem é adotar um modelo probabilístico de existência. Em vez de booleano, você calcula a probabilidade de a entidade existir com base em fontes cruzadas. Isso resolve parte do problema de entidades parcialmente referenciadas, mas introduz complexidade adicional e depende criticamente da qualidade das fontes. Eu tentei implementar isso num projeto com dados abertos do setor público. O ganho foi marginal — cerca de 3% de redução nos falsos nulos — mas o custo de manutenção do motor probabilístico compensou por pouco. Vale a pena apenas em escala grande, acima de 50 mil registros diários processados.

O essencial é tratar pressuposição existencial como uma verificação ativa, não como algo que o sistema resolve sozinho. Ferramentas de type checking estático em linguagens como Haskell ou TypeScript ajudam, mas elas verificam existência de tipo, não existência de instância no domínio. A camada semântica continua sendo o ponto cego da maioria dos pipelines.