Resumo
A detecção de alucinações em código gerado por IA admite hoje duas grandes famílias de aproximações: as que verificam contra uma fonte de verdade externa (determinísticas) e as que inferem a probabilidade de erro mediante modelos (generativas). Este artigo revisa ambas a partir da literatura recente e de experiências publicadas na DEV Community, e situa o caso concreto da verificação de pacotes e APIs de Python contra PyPI. A conclusão provisória é que nenhuma família cobre o problema completo: as determinísticas oferecem evidência objetiva mas um alcance delimitado; as generativas ampliam a cobertura mas introduzem incerteza. A escolha depende do tipo de erro que se queira capturar e do custo que se esteja disposto a assumir.
1. O problema: três falhas com o mesmo nome
Saurav Bhattacharya sustenta em um artigo recente que a detecção de alucinações é um problema de instrumentação, não de qualidade do modelo. Seu argumento central é que, em sistemas com agentes, a palavra “alucinação” agrupa pelo menos três falhas distintas:
-
Fuga paramétrica: o agente responde a partir de sua memória de treinamento em lugar de usar o resultado da ferramenta que lhe foi fornecida. A resposta pode estar correta, mas o é por acaso, não porque esteja fundamentada.
-
Fundamentação fabricada: o agente cita uma fonte, um identificador ou um número que não aparece no contexto recuperado. É o caso mais perigoso porque tem a aparência de uma afirmação documentada.
-
Síntese não suportada: cada fato individual está no contexto, mas a conclusão que o agente extrai não se segue da fonte.
A implicação prática é que essas três falhas requerem detectores distintos. Um único “score de alucinação” que as misture produz um número que ninguém consegue interpretar.
2. A crítica aos métodos generativos
O mesmo artigo aponta uma fraqueza conhecida dos detectores baseados em modelos: a auto-consistência (amostrar várias vezes e verificar se as respostas coincidem) detecta alucinações instáveis, mas falha com as estáveis. Se um agente reproduz sistematicamente o mesmo dado errado de sua memória paramétrica, as amostras coincidem e o detector reporta alta confiança. O modelo é reprodutivelmente incorreto, e a consistência era o sinal.
A literatura acadêmica respalda essa cautela. Um estudo sobre métodos de análise estática para alucinações de bibliotecas aponta que as ferramentas de inferência de tipos, como Pyright, são mais confiáveis do que o julgamento de um LLM na detecção de erros de importação e de tipo. O mesmo trabalho reconhece, todavia, que a análise estática tem limites: as operações de fluxo de dados e de controle são as vias mais promissoras para ampliar sua cobertura, mas os tipos podem mutar durante a execução e escapar à detecção.
3. A proposta determinística: verificar contra a fonte
A alternativa que Bhattacharya defende é mecânica e explicável: extrair as afirmações verificáveis do output e verificá-las contra o texto que o agente realmente recuperou. O requisito é conservar esse texto (o rastreamento de execução); sem ele, qualquer verificação é um palpite.
No domínio do código, essa ideia se materializou de várias formas. A ferramenta libhallubench avalia a geração de código de LLM contra um benchmark de bibliotecas inexistentes, usando a lista de pacotes de PyPI como fonte de verdade. O projeto vibe-check detecta padrões típicos de código gerado por IA, incluindo os imports inventados, mediante correspondência de padrões, sem recorrer a modelos nem a serviços na nuvem. Um artigo da mesma comunidade descreve como ESLint e TypeScript não detectam um import inventado porque o linter valida sintaxe, não a existência do pacote no registro, e o compilador de tipos apenas verifica tipos se existem definições instaladas, que não podem ser instaladas para um pacote que não existe.
Neste panorama, a verificação de pacotes e APIs de Python contra o wheel real de PyPI situa-se na tradição determinística: não infere, verifica pertencimento a um conjunto. A vantagem é que não requer instalar o pacote nem executar o código analisado; a limitação é que cobre apenas a existência de símbolos, não a correção de seu uso.
4. A proposta generativa: detectar spans com modelos treinados
A família generativa avançou de forma notável. LettuceDetect v2 é um detector treinado sobre um benchmark unificado de 74.285 exemplos etiquetados no nível de span, que abrange código, saídas de ferramentas e documentos. O modelo generativo (Qwen 3.5-2B) retorna os spans alucinados como JSON estruturado, tipificados por categoria (contradição, adição não suportada, referência fabricada) e subcategoria (entidade, temporal, numérico, identificador, atributo). No conjunto de teste unificado, atinge 0,689 span-F1; em respostas de agentes de código, 0,602.
A vantagem desse enfoque é a cobertura: detecta erros que um verificador de existência não consegue capturar, como uma condição lógica incorreta ou um valor numérico equivocado. A limitação é a inerente a todo modelo probabilístico: não oferece uma explicação determinística e seu rendimento varia conforme o domínio e a fonte de fundamentação.
5. O vazio que nenhum cobre: lógica e recursos
A taxonomia de CodeHalu, citada na documentação do projeto que nos ocupa, distingue quatro categorias: nomenclatura, mapeamento, recursos e lógica. Os verificadores determinísticos contra registros cobrem razoavelmente as duas primeiras. As duas últimas ficam fora de seu alcance por definição: requerem analisar o fluxo de dados, as condições ou a complexidade algorítmica, não apenas a existência de um símbolo.
A literatura confirma esse limite. Uma análise das falhas estruturais em código gerado conclui que a maioria delas escapa ao type checking, aos testes e à análise estática de segurança. Outro trabalho descreve o caso de uma função de desconto cujos tipos estão corretos mas cuja semântica é errônea porque a unidade da porcentagem não coincide com a que usa o resto do código: o compilador não consegue detectá-lo porque os tipos se encaixam.
Os detectores generativos como LettuceDetect v2 tentam cobrir parte desse vazio, mas não oferecem garantias determinísticas. A lacuna entre “o símbolo existe” e “o código faz o que deve” segue sendo, em boa medida, um problema aberto.
6. Considerações para o design de um detector
A partir do anterior, podem ser extraídas algumas observações provisórias:
A verificação determinística é barata e explicável. Verificar a existência de um pacote ou de uma função contra um registro não requer executar o código do usuário nem instalar dependências. O custo é delimitado e o resultado é uma pertença a um conjunto, não uma probabilidade.
A cobertura determinística é necessariamente parcial. Limita-se aos erros que podem ser expressos como uma verificação de pertença ou de assinatura. Os erros de lógica, de fluxo de dados ou de complexidade ficam de fora.
Os métodos generativos ampliam a cobertura mas introduzem incerteza. Seu rendimento depende do benchmark de treinamento e não oferecem uma explicação determinística da falha.
A combinação é plausível. Um detector determinístico para a existência de símbolos e um detector generativo ou semântico para a lógica poderiam cobrir camadas complementares. A questão aberta é como integrá-los sem que a incerteza do segundo contamine a confiabilidade do primeiro.
7. Limitações desta análise
Este texto baseia-se em uma revisão não sistemática de literatura e de artigos da comunidade. Não foi realizada uma avaliação empírica comparativa dos enfoques descritos. As cifras citadas provêm dos trabalhos originais e não foram replicadas no contexto específico da verificação de pacotes de Python. A taxonomia de CodeHalu foi utilizada como marco descritivo, não como benchmark validado nesta análise.
Referências
-
Bhattacharya, S. (2026). Hallucination Is Not a Vibe: How to Actually Detect Ungrounded Claims in Agent Output. DEV Community.
-
libhallubench (2026). PyPI.
-
5 Code Smells Only AI Creates (And How to Detect Them). DEV Community.
-
ESLint can’t catch this: 5 failure modes unique to AI-generated code. DEV Community.
-
LettuceDetect v2 in Semantic Router: Generative Hallucination Detection as a vLLM Endpoint. GitHub.
-
KRLabsOrg. LettuceDetect. GitHub.
-
The verification gap in agent-written code: what actually breaks. GitHub.
-
The Patchwork Problem in LLM-Generated Code. arXiv.
-
For mitigation, we use three metrics. OpenReview.