💬 NLP

Disentangling Ambiguity from Instability in Large Language Models: A Clinical Text-to-SQL Case Study

Este artigo apresenta o CLUES, um framework que desmembra a ambiguidade de entrada da instabilidade do modelo em Text-to-SQL clínico ao decompor a incerteza semântica em pontuações distintas, permitindo, assim, intervenções direcionadas e uma triagem de erros mais eficiente em comparação aos métodos existentes.

Autores originais: Angelo Ziletti, Leonardo D'Ambrosi

Publicado 2026-07-09

📖 7 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Angelo Ziletti, Leonardo D'Ambrosi

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você é um detetive tentando resolver um mistério usando um assistente de IA superinteligente. Você faz uma pergunta sobre uma enorme biblioteca de registros médicos, como: "Quantos pacientes acima de 18 anos têm dermatite atópica?". A IA pode responder com uma consulta SQL (uma linguagem especial para perguntar ao banco de dados) e uma resposta. Mas aqui está o detalhe: às vezes a IA erra, e às vezes ela erra por dois motivos muito diferentes.

O artigo "Disentangling Ambiguity from Instability in Large Language Models" introduz uma nova ferramenta de detetive chamada CLUES. Sua principal função é descobrir por que a IA está confusa. É a própria pergunta que é um enigma com múltiplos significados (Ambiguidade)? Ou a IA está apenas tendo um dia ruim e agindo de forma instável (Instabilidade)?

Os Dois Tipos de Confusão

Pense no cérebro da IA como uma cozinha.

1. O Problema da Ambiguidade (O Enigma)
Imagine que você pede ao chef: "Faça um sanduíche para mim".

Interpretação A: "Faça um sanduíche de peru sem maionese."
Interpretação B: "Faça um sanduíche de presunto com queijo extra."
Se o chef fizer ambos e você receber dois sanduíches diferentes, isso é Ambiguidade. O problema não foi a habilidade culinária do chef; foi que o seu pedido foi vago. No mundo médico, perguntar "Quantos pacientes acima de 18 anos?" é complicado. "Acima de 18" significa a idade agora ou a idade no momento do primeiro diagnóstico? Se a IA adivinhar o significado errado, ela dará a resposta errada. O artigo sugere que, quando isso acontece, a solução é perguntar ao humano: "Ei, você quis dizer a idade agora ou a idade no diagnóstico?".

2. O Problema da Instabilidade (O Chef Jittery/Instável)
Agora, imagine que você dê um pedido cristalino ao chef: "Faça um sanduíche de peru sem maionese".

Tentativa 1: Um sanduíche de peru perfeito.
Tentativa 2: Um sanduíche de peru queimado.
Tentativa 3: Um sanduíche de peru com maionese (ops!).
Aqui, o pedido era perfeito, mas o chef está agindo de forma instável. Isso é Instabilidade. A IA está confusa sobre suas próprias regras internas ou apenas tendo um erro técnico. O artigo sugere que, quando isso acontece, você não deve pedir esclarecimentos ao humano; você deve sinalizar a resposta para um humano conferir ou corrigir o treinamento da IA.

O Jeito Antigo vs. O Jeito CLUES

Antes deste artigo, os pesquisadores usavam uma pontuação única (chamada Kernel Language Entropy ou KLE) para medir o quão "bagunçadas" estavam as respostas da IA.

O Jeito Antigo: Se a IA desse cinco respostas diferentes, a pontuação subia. Mas a pontuação antiga não conseguia dizer o porquê. Era porque a pergunta era um enigma ou porque a IA estava falhando? Era como um alarme de incêndio que apenas grita "Fogo!" sem dizer se é um incêndio real ou apenas torrada queimada.
O Argumento do Artigo: Os autores argumentam explicitamente contra o uso de apenas uma pontuação. Eles dizem que você deve separar os dois tipos de confusão para saber o que fazer a seguir.

Como o CLUES Funciona: O Gráfico Mágico

Os autores construíram um framework chamado CLUES (Conditional Language Uncertainty via Entropy and Schur). Eles tratam o processo de pensamento da IA como um show de duas etapas:

Etapa 1 (A Interpretação): A IA adivinha o que a pergunta poderia significar. Ela escreve algumas versões diferentes da pergunta.
Etapa 2 (A Resposta): Para cada versão da pergunta, a IA tenta respondê-la várias vezes.

Para medir a confusão, eles desenham um grande mapa (um "grafo bipartido semântico").

Um lado do mapa tem as Perguntas (Interpretações).
O outro lado tem as Respostas.
Eles as conectam com linhas. Se duas perguntas são semelhantes, a linha é grossa. Se duas respostas são semelhantes, a linha é grossa.

Então, eles usam um truque matemático sofisticado chamado complemento de Schur (imagine como um filtro matemático que subtrai a "confusão da pergunta" da "confusão total").

O Resultado: Eles obtêm dois números separados:
- $H_I$ (Pontuação de Ambiguidade): O quanto as perguntas diferem entre si.
- $H_{R|I}$ (Pontuação de Instabilidade): O quanto as respostas diferem mesmo quando a pergunta é fixa.

O Que os Números Dizem

A equipe testou isso em dois tipos de enigmas:

Trivia Geral: Eles usaram 300 perguntas do AmbigQA e 300 do SituatedQA.
- Descobriram que a nova Pontuação de Instabilidade ( $H_{R|I}$ ) foi muito melhor em prever quando a IA falharia do que a pontuação única antiga.
- Por exemplo, no modelo KimiK2, a pontuação antiga previu a falha com uma precisão (AUROC) de 0,663, mas a nova pontuação CLUES saltou para 0,770.
- Eles também notaram que, se tentassem apenas subtrair as pontuações (um método "ingênuo"), o resultado falhava miseravelmente, dando números negativos 37% a 60% das vezes. Isso provou que o truque matemático complexo deles era necessário.
Registros Médicos (O Caso Real): Eles testaram isso em um conjunto de dados clínico de Text-to-SQL com 2.180 perguntas.
- Aqui, a nova pontuação foi ainda melhor. A pontuação antiga tinha uma precisão de 0,600, enquanto o CLUES atingiu 0,762.
- Eles descobriram que a pontuação de "Instabilidade" foi especialmente boa em detectar quando a IA estava apenas oscilando/instável.

A Estratégia de "Regime": Ordenando a Bagunça

O artigo sugere classificar cada pergunta em um de quatro "Regimes" baseados nas duas pontuações:

Regime I (Confiante): Baixa Ambiguidade, Baixa Instabilidade. -> Responda automaticamente.
Regime II (Ambiguidade): Alta Ambiguidade, Baixa Instabilidade. -> Peça esclarecimentos ao humano.
Regime III (Instabilidade): Baixa Ambiguidade, Alta Instabilidade. -> Sinalize para revisão humana.
Regime IV (Composto): Alta Ambiguidade, Alta Instabilidade. -> Faça ambos!

Essa classificação é um divisor de águas para a eficiência. Em seu teste de implantação, eles descobriram que o Regime IV (a zona de alto risco e bagunçada) continha 51% de todos os erros, embora detivesse apenas 25% do total de perguntas.

A Conclusão: Se você enviar apenas os 25% de perguntas problemáticas para um humano verificar, você captura metade de todos os erros! Isso é duas vezes mais eficiente do que verificar perguntas aleatórias.

Quão Seguros Eles Estão?

Os autores estão bastante confiantes em seus resultados, mas são cuidadosos para não exagerar a natureza de suas descobertas.

Eles demonstraram e validaram a eficácia do framework através de evidências empíricas em conjuntos de dados específicos (AmbigQA, SituatedQA e seu benchmark clínico), em vez de fornecer uma prova matemática teórica das equações subjacentes.
Eles mediram a melhoria em configurações semelhantes ao mundo real, mostrando que a nova pontuação é consistentemente melhor em detectar falhas.
No entanto, admitem que em uma implantação real onde os erros são raros (apenas cerca de 4,4% das perguntas estavam erradas em seu teste), o sistema ainda não é perfeito. É uma ótima ferramenta de "triagem" (classificação), mas não resolve todos os problemas automaticamente.
Eles também observam uma limitação: o sistema precisa gerar múltiplas interpretações primeiro, o que consome mais poder computacional. Se a IA que gera as interpretações for ruim, todo o sistema pode ficar confuso.

A Conclusão Final

O artigo não afirma ter "resolvido" a incerteza da IA. Em vez disso, sugere que, ao usar um processo de duas etapas e um filtro matemático especial (o complemento de Schur), podemos finalmente distinguir entre uma pergunta confusa e um erro da IA. Isso nos permite parar de adivinhar e começar a tomar a ação correta: pedir ajuda quando a pergunta é vaga, ou conferir o trabalho quando a IA está agindo de forma instável. É um passo para tornar os médicos e pesquisadores de IA mais seguros e confiáveis.

Resumo Técnico: Desvendando a Ambiguidade da Instabilidade em Grandes Modelos de Linguagem

Declaração do Problema

A implementação de Grandes Modelos de Linguagem (LLMs) para aplicações clínicas de Text-to-SQL enfrenta uma barreira crítica: o risco de gerar consultas sintaticamente corretas, mas semanticamente errôneas. Um desafio primário é a ambiguidade latente, onde consultas de entrada contêm incertezas implícitas (ex: "pacientes com mais de 18 anos" referindo-se à idade no diagnóstico vs. idade atual) que alteram significamente os resultados, mas não são evidentes para o usuário.

Os métodos atuais de quantificação de incerteza, como a Entropia de Linguagem de Kernel (KLE), fornecem um único escore para medir a diversidade de saída. No entanto, essa abordagem confunde dois tipos de incerteza fundamentalmente distintos:

Ambiguidade de Entrada (tipo Aleatória): Diversidade decorrente da ambiguidade inerente à consulta do usuário, que legitimamente gera múltiplas interpretações válidas.
Instabilidade do Modelo (tipo Epistêmica): Diversidade decorrente da inconsistência interna do modelo ou da falta de conhecimento ao processar uma única interpretação clara.

Essa confusão impede o deployment eficaz do sistema. Uma alta ambiguidade deve disparar um diálogo de esclarecimento com o usuário, enquanto uma alta instabilidade deve sinalizar a consulta para revisão humana. Métodos existentes não conseguem distinguir esses regimes, impedindo intervenções direcionadas.

Metodologia: O Framework CLUES

Os autores propõem o CLUES (Conditional Language Uncertainty via Entropy and Schur), um framework que modela o Text-to-SQL como um processo generativo de dois estágios para decompor a incerteza semântica.

1. Processo Generativo de Dois Estágios

O sistema é formalizado como:

Estágio de Interpretação: O sistema gera $N$ interpretações semânticas distintas ( $I = \{I_1, ..., I_N\}$ ) representando leituras plausíveis da consulta original.
Estágio de Geração: Para cada interpretação $I_n$ , o sistema gera $M$ consultas SQL candidatas e respostas correspondentes ( $R_n = \{R_{n,1}, ..., R_{n,M}\}$ ).
Esta estrutura cria uma relação bipartida onde a diversidade entre interpretações representa ambiguidade, e a diversidade dentro de uma única interpretação representa instabilidade.

2. Construção de Grafo Semântico Bipartido

Uma função de similaridade $k(\cdot, \cdot)$ é usada para construir uma matriz de adjacência ponderada $W$ , estruturada como um grafo bipartido:
$W = \begin{pmatrix} W_{II} & W_{IR} \\ W_{RI} & W_{RR} \end{pmatrix}$

$W_{II}$ : Codifica a similaridade semântica entre interpretações.
$W_{RR}$ : Codifica a similaridade semântica entre todas as respostas geradas.
$W_{IR}/W_{RI}$ : Matrizes de atribuição binária ligando as respostas às suas interpretações pai.

Um kernel de difusão de calor ( $K_\tau = e^{-\tau L}$ ) é aplicado para suavizar essas similaridades, onde $\tau$ controla a granularidade do agrupamento.

3. Decomposição via Complemento de Schur

A inovação central é a decomposição da incerteza total em um Escore de Ambiguidade ( $H_I$ ) e um Escore de Instabilidade ( $H_{R|I}$ ).

Ambiguidade ( $H_I$ ): Calculada como a entropia da matriz de interpretação $W_{II}$ usando o framework KLE.
Instabilidade ( $H_{R|I}$ ): Definida como a entropia condicional dos resultados dados as interpretações. Os autores rejeitam a abordagem de subtração ingênua ( $H_{R,I} - H_I$ ) porque ela viola a regra da cadeia para a entropia de von Neumann em matrizes de densidade de kernel de calor e frequentemente resulta em valores negativos.
Solução pelo Complemento de Schur: Em vez da subtração, o framework calcula a estrutura de similaridade condicional diretamente:
$S = W_{RR} - W_{RI}(W_{II} + \epsilon I)^{-1}W_{IR}$
A matriz $S$ representa a similaridade residual nas respostas que não pode ser explicada pela estrutura de interpretação. A entropia de $S$ produz $H_{R|I}$ . Esta abordagem garante escores não negativos e isola matematicamente a inconsistência interna do sistema.

4. Regimes de Incerteza

O framework define quatro regimes operacionais baseados em limiares para $H_I$ e $H_{R|I}$ :

Regime I (Confiante): Baixa ambiguidade, baixa instabilidade $\rightarrow$ Resposta automática.
Regime II (Ambiguidade): Alta ambiguidade, baixa instabilidade $\rightarrow$ Disparar diálogo de esclarecimento.
Regime III (Instabilidade): Baixa ambiguidade, alta instabilidade $\rightarrow$ Sinalizar para revisão humana.
Regime IV (Composto): Alta ambiguidade, alta instabilidade $\rightarrow$ Esclarecimento + Revisão.

Principais Contribuições

Framework CLUES: Um método agnóstico ao modelo para decompor a incerteza semântica em ambiguidade e instabilidade condicional usando o complemento de Schur de um grafo semântico bipartido.
Dataset Clínico e Procedimento: Um procedimento de interpretação-geração para questões epidemiológicas e um benchmark de Text-to-SQL clínico apresentando múltiplas interpretações válidas para consultas conhecidas.
Validação Empírica: Evidência demonstrando que o $H_{R|I}$ melhora a previsão de falhas em relação ao estado da arte KLE ( $H_R$ ) e permite a triagem de erros eficaz por meio de roteamento baseado em regimes.

Resultados Experimentais

QA de Domínio Aberto (AmbigQA & SituatedQA)

Usando interpretações de padrão ouro, o CLUES foi avaliado em cinco LLMs de fronteira.

Previsão de Falhas: O escore de instabilidade $H_{R|I}$ superou consistentemente o baseline $H_R$ na previsão de falhas (melhorias de AUROC de +0,074 a +0,077 nos dados agregados).
Discriminação de Regimes: Entre as consultas com alta diversidade de saída (alto $H_R$ ), aquelas com baixa instabilidade ( $H_{R|I}$ ) tiveram precisão significativamente maior do que aquelas com alta instabilidade. Por exemplo, no SituatedQA, a precisão caiu de 46,8% (Regime A) para 13,3% (Regime B), uma diferença estatisticamente significativa (razão de chances ~5,7).
Falha da Subtração Ingênua: A abordagem de subtração ingênua ( $\tilde{H}_{R|I}$ ) resultou em valores negativos em 37–60% dos casos e teve desempenho próximo ao acaso, validando a necessidade do complemento de Schur.

Text-to-SQL Clínico (Interpretações Conhecidas)

Avaliado em um dataset derivado de EHRSQL e EpiAskKB com 2.180 instâncias de consulta-modelo.

Desempenho: O $H_{R|I}$ alcançou um AUROC agrupado de 0,762 comparado a 0,600 para o $H_R$ (p < $10^{-10}$ ).
Robustez: O escore de instabilidade permaneceu estável através de diferentes parâmetros de kernel de calor ( $\tau \in [2, 20]$ ), enquanto o baseline $H_R$ degradou significativamente em $\tau$ mais altos.
Sensibilidade de Temperatura: Temperaturas de amostragem moderadas (T=1.0–1.5) produziram os sinais de instabilidade mais fortes, sugerindo que uma maior diversidade expõe a instabilidade latente do modelo.

Configuração de Deployment (Interpretações Geradas)

Em um cenário de produção, onde as interpretações são geradas on-the-fly (não fornecidas como rótulos de ouro):

Precisão: Os modelos alcançaram alta precisão (84–100%), resultando em erros esparsos (taxa de erro de 4,4%).
Eficiência de Regime: Embora o AUROC de escore único não tenha sido significativamente diferente entre $H_R$ e $H_{R|I}$ neste regime esparso, a análise de regime provou valiosa. O Regime IV (Alta Ambiguidade + Alta Instabilidade) continha 51% de todos os erros, enquanto cobria apenas 25% das consultas.
Roteamento: Uma estratégia que roteia apenas o Regime IV para revisão humana capturaria metade de todas as falhas revisando apenas um quarto das consultas, dobrando a eficiência em relação à seleção aleatória.

Significância e Alegações

O artigo afirma que o CLUES fornece uma decomposição diagnóstica indisponível de métricas de escore único. Ao distinguir entre ambiguidade de entrada e instabilidade do modelo, o framework permite intervenções direcionadas:

Esclarecimento para consultas de alta ambiguidade.
Revisão Humana para consultas de alta instabilidade.

Os autores enfatizam que essa distinção é operacionalmente crítica para domínios de segurança crítica, como o acesso a EHR clínico, onde resultados "plausíveis, porém incorretos" representam riscos significativos. O framework é projetado para ser agnóstico ao modelo, exigindo apenas amostragem de saída, e oferece uma abordagem matemática fundamentada para a incerteza que evita as armadilhas da subtração de entropia ingênua.

Os autores notam modestamente limitações, incluindo o custo computacional de múltiplas chamadas de LLM por consulta e a dependência da qualidade das interpretações geradas. Eles também reconhecem que, em configurações de deployment de alta precisão, a taxa de erro esparsa limita o poder discriminativo de sinais de incerteza refinados, embora o roteamento baseado em regimes ainda ofereça ganhos de eficiência sobre a seleção aleatória.